1This is gccint.info, produced by makeinfo version 6.5 from gccint.texi. 2 3Copyright (C) 1988-2021 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-2021 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 11.2.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 than 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 [{ target 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 compiler to crash 4420.................................... 4421 4422'{ dg-ice COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }' 4423 Expect the compiler to crash with an internal compiler error and 4424 return a nonzero exit status if the conditions (which are the same 4425 as for 'dg-skip-if') are met. Used for tests that test bugs that 4426 have not been fixed yet. 4427 44287.2.1.7 Expect the test executable to fail 4429.......................................... 4430 4431'{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }' 4432 Expect the test executable to return a nonzero exit status if the 4433 conditions (which are the same as for 'dg-skip-if') are met. 4434 44357.2.1.8 Verify compiler messages 4436................................ 4437 4438Where LINE is an accepted argument for these commands, a value of '0' 4439can be used if there is no line associated with the message. 4440 4441'{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4442 This DejaGnu directive appears on a source line that is expected to 4443 get an error message, or else specifies the source line associated 4444 with the message. If there is no message for that line or if the 4445 text of that message is not matched by REGEXP then the check fails 4446 and COMMENT is included in the 'FAIL' message. The check does not 4447 look for the string 'error' unless it is part of REGEXP. 4448 4449'{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4450 This DejaGnu directive appears on a source line that is expected to 4451 get a warning message, or else specifies the source line associated 4452 with the message. If there is no message for that line or if the 4453 text of that message is not matched by REGEXP then the check fails 4454 and COMMENT is included in the 'FAIL' message. The check does not 4455 look for the string 'warning' unless it is part of REGEXP. 4456 4457'{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4458 The line is expected to get a message other than an error or 4459 warning. If there is no message for that line or if the text of 4460 that message is not matched by REGEXP then the check fails and 4461 COMMENT is included in the 'FAIL' message. 4462 4463'{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4464 This DejaGnu directive appears on a source line that should not get 4465 a message matching REGEXP, or else specifies the source line 4466 associated with the bogus message. It is usually used with 'xfail' 4467 to indicate that the message is a known problem for a particular 4468 set of targets. 4469 4470'{ dg-line LINENUMVAR }' 4471 This DejaGnu directive sets the variable LINENUMVAR to the line 4472 number of the source line. The variable LINENUMVAR can then be 4473 used in subsequent 'dg-error', 'dg-warning', 'dg-message' and 4474 'dg-bogus' directives. For example: 4475 4476 int a; /* { dg-line first_def_a } */ 4477 float a; /* { dg-error "conflicting types of" } */ 4478 /* { dg-message "previous declaration of" "" { target *-*-* } first_def_a } */ 4479 4480'{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }' 4481 This DejaGnu directive indicates that the test is expected to fail 4482 due to compiler messages that are not handled by 'dg-error', 4483 'dg-warning' or 'dg-bogus'. For this directive 'xfail' has the 4484 same effect as 'target'. 4485 4486'{ dg-prune-output REGEXP }' 4487 Prune messages matching REGEXP from the test output. 4488 44897.2.1.9 Verify output of the test executable 4490............................................ 4491 4492'{ dg-output REGEXP [{ target/xfail SELECTOR }] }' 4493 This DejaGnu directive compares REGEXP to the combined output that 4494 the test executable writes to 'stdout' and 'stderr'. 4495 44967.2.1.10 Specify environment variables for a test 4497................................................. 4498 4499'{ dg-set-compiler-env-var VAR_NAME "VAR_VALUE" }' 4500 Specify that the environment variable VAR_NAME needs to be set to 4501 VAR_VALUE before invoking the compiler on the test file. 4502 4503'{ dg-set-target-env-var VAR_NAME "VAR_VALUE" }' 4504 Specify that the environment variable VAR_NAME needs to be set to 4505 VAR_VALUE before execution of the program created by the test. 4506 45077.2.1.11 Specify additional files for a test 4508............................................ 4509 4510'{ dg-additional-files "FILELIST" }' 4511 Specify additional files, other than source files, that must be 4512 copied to the system where the compiler runs. 4513 4514'{ dg-additional-sources "FILELIST" }' 4515 Specify additional source files to appear in the compile line 4516 following the main test file. 4517 45187.2.1.12 Add checks at the end of a test 4519........................................ 4520 4521'{ dg-final { LOCAL-DIRECTIVE } }' 4522 This DejaGnu directive is placed within a comment anywhere in the 4523 source file and is processed after the test has been compiled and 4524 run. Multiple 'dg-final' commands are processed in the order in 4525 which they appear in the source file. *Note Final Actions::, for a 4526 list of directives that can be used within 'dg-final'. 4527 4528 4529File: gccint.info, Node: Selectors, Next: Effective-Target Keywords, Prev: Directives, Up: Test Directives 4530 45317.2.2 Selecting targets to which a test applies 4532----------------------------------------------- 4533 4534Several test directives include SELECTORs to limit the targets for which 4535a test is run or to declare that a test is expected to fail on 4536particular targets. 4537 4538 A selector is: 4539 * one or more target triplets, possibly including wildcard 4540 characters; use '*-*-*' to match any target 4541 * a single effective-target keyword (*note Effective-Target 4542 Keywords::) 4543 * a logical expression 4544 4545 Depending on the context, the selector specifies whether a test is 4546skipped and reported as unsupported or is expected to fail. A context 4547that allows either 'target' or 'xfail' also allows '{ target SELECTOR1 4548xfail SELECTOR2 }' to skip the test for targets that don't match 4549SELECTOR1 and the test to fail for targets that match SELECTOR2. 4550 4551 A selector expression appears within curly braces and uses a single 4552logical operator: one of '!', '&&', or '||'. An operand is another 4553selector expression, an effective-target keyword, a single target 4554triplet, or a list of target triplets within quotes or curly braces. 4555For example: 4556 4557 { target { ! "hppa*-*-* ia64*-*-*" } } 4558 { target { powerpc*-*-* && lp64 } } 4559 { xfail { lp64 || vect_no_align } } 4560 4561 4562File: gccint.info, Node: Effective-Target Keywords, Next: Add Options, Prev: Selectors, Up: Test Directives 4563 45647.2.3 Keywords describing target attributes 4565------------------------------------------- 4566 4567Effective-target keywords identify sets of targets that support 4568particular functionality. They are used to limit tests to be run only 4569for particular targets, or to specify that particular sets of targets 4570are expected to fail some tests. 4571 4572 Effective-target keywords are defined in 'lib/target-supports.exp' in 4573the GCC testsuite, with the exception of those that are documented as 4574being local to a particular test directory. 4575 4576 The 'effective target' takes into account all of the compiler options 4577with which the test will be compiled, including the multilib options. 4578By convention, keywords ending in '_nocache' can also include options 4579specified for the particular test in an earlier 'dg-options' or 4580'dg-add-options' directive. 4581 45827.2.3.1 Endianness 4583.................. 4584 4585'be' 4586 Target uses big-endian memory order for multi-byte and multi-word 4587 data. 4588 4589'le' 4590 Target uses little-endian memory order for multi-byte and 4591 multi-word data. 4592 45937.2.3.2 Data type sizes 4594....................... 4595 4596'ilp32' 4597 Target has 32-bit 'int', 'long', and pointers. 4598 4599'lp64' 4600 Target has 32-bit 'int', 64-bit 'long' and pointers. 4601 4602'llp64' 4603 Target has 32-bit 'int' and 'long', 64-bit 'long long' and 4604 pointers. 4605 4606'double64' 4607 Target has 64-bit 'double'. 4608 4609'double64plus' 4610 Target has 'double' that is 64 bits or longer. 4611 4612'longdouble128' 4613 Target has 128-bit 'long double'. 4614 4615'int32plus' 4616 Target has 'int' that is at 32 bits or longer. 4617 4618'int16' 4619 Target has 'int' that is 16 bits or shorter. 4620 4621'longlong64' 4622 Target has 64-bit 'long long'. 4623 4624'long_neq_int' 4625 Target has 'int' and 'long' with different sizes. 4626 4627'short_eq_int' 4628 Target has 'short' and 'int' with the same size. 4629 4630'ptr_eq_short' 4631 Target has pointers ('void *') and 'short' with the same size. 4632 4633'int_eq_float' 4634 Target has 'int' and 'float' with the same size. 4635 4636'ptr_eq_long' 4637 Target has pointers ('void *') and 'long' with the same size. 4638 4639'large_double' 4640 Target supports 'double' that is longer than 'float'. 4641 4642'large_long_double' 4643 Target supports 'long double' that is longer than 'double'. 4644 4645'ptr32plus' 4646 Target has pointers that are 32 bits or longer. 4647 4648'size20plus' 4649 Target has a 20-bit or larger address space, so supports at least 4650 16-bit array and structure sizes. 4651 4652'size24plus' 4653 Target has a 24-bit or larger address space, so supports at least 4654 20-bit array and structure sizes. 4655 4656'size32plus' 4657 Target has a 32-bit or larger address space, so supports at least 4658 24-bit array and structure sizes. 4659 4660'4byte_wchar_t' 4661 Target has 'wchar_t' that is at least 4 bytes. 4662 4663'floatN' 4664 Target has the '_FloatN' type. 4665 4666'floatNx' 4667 Target has the '_FloatNx' type. 4668 4669'floatN_runtime' 4670 Target has the '_FloatN' type, including runtime support for any 4671 options added with 'dg-add-options'. 4672 4673'floatNx_runtime' 4674 Target has the '_FloatNx' type, including runtime support for any 4675 options added with 'dg-add-options'. 4676 4677'floatn_nx_runtime' 4678 Target has runtime support for any options added with 4679 'dg-add-options' for any '_FloatN' or '_FloatNx' type. 4680 4681'inf' 4682 Target supports floating point infinite ('inf') for type 'double'. 4683 4684'inff' 4685 Target supports floating point infinite ('inf') for type 'float'. 4686 46877.2.3.3 Fortran-specific attributes 4688................................... 4689 4690'fortran_integer_16' 4691 Target supports Fortran 'integer' that is 16 bytes or longer. 4692 4693'fortran_real_10' 4694 Target supports Fortran 'real' that is 10 bytes or longer. 4695 4696'fortran_real_16' 4697 Target supports Fortran 'real' that is 16 bytes or longer. 4698 4699'fortran_large_int' 4700 Target supports Fortran 'integer' kinds larger than 'integer(8)'. 4701 4702'fortran_large_real' 4703 Target supports Fortran 'real' kinds larger than 'real(8)'. 4704 47057.2.3.4 Vector-specific attributes 4706.................................. 4707 4708'vect_align_stack_vars' 4709 The target's ABI allows stack variables to be aligned to the 4710 preferred vector alignment. 4711 4712'vect_avg_qi' 4713 Target supports both signed and unsigned averaging operations on 4714 vectors of bytes. 4715 4716'vect_mulhrs_hi' 4717 Target supports both signed and unsigned 4718 multiply-high-with-round-and-scale operations on vectors of 4719 half-words. 4720 4721'vect_sdiv_pow2_si' 4722 Target supports signed division by constant power-of-2 operations 4723 on vectors of 4-byte integers. 4724 4725'vect_condition' 4726 Target supports vector conditional operations. 4727 4728'vect_cond_mixed' 4729 Target supports vector conditional operations where comparison 4730 operands have different type from the value operands. 4731 4732'vect_double' 4733 Target supports hardware vectors of 'double'. 4734 4735'vect_double_cond_arith' 4736 Target supports conditional addition, subtraction, multiplication, 4737 division, minimum and maximum on vectors of 'double', via the 4738 'cond_' optabs. 4739 4740'vect_element_align_preferred' 4741 The target's preferred vector alignment is the same as the element 4742 alignment. 4743 4744'vect_float' 4745 Target supports hardware vectors of 'float' when 4746 '-funsafe-math-optimizations' is in effect. 4747 4748'vect_float_strict' 4749 Target supports hardware vectors of 'float' when 4750 '-funsafe-math-optimizations' is not in effect. This implies 4751 'vect_float'. 4752 4753'vect_int' 4754 Target supports hardware vectors of 'int'. 4755 4756'vect_long' 4757 Target supports hardware vectors of 'long'. 4758 4759'vect_long_long' 4760 Target supports hardware vectors of 'long long'. 4761 4762'vect_check_ptrs' 4763 Target supports the 'check_raw_ptrs' and 'check_war_ptrs' optabs on 4764 vectors. 4765 4766'vect_fully_masked' 4767 Target supports fully-masked (also known as fully-predicated) 4768 loops, so that vector loops can handle partial as well as full 4769 vectors. 4770 4771'vect_masked_load' 4772 Target supports vector masked loads. 4773 4774'vect_masked_store' 4775 Target supports vector masked stores. 4776 4777'vect_scatter_store' 4778 Target supports vector scatter stores. 4779 4780'vect_aligned_arrays' 4781 Target aligns arrays to vector alignment boundary. 4782 4783'vect_hw_misalign' 4784 Target supports a vector misalign access. 4785 4786'vect_no_align' 4787 Target does not support a vector alignment mechanism. 4788 4789'vect_peeling_profitable' 4790 Target might require to peel loops for alignment purposes. 4791 4792'vect_no_int_min_max' 4793 Target does not support a vector min and max instruction on 'int'. 4794 4795'vect_no_int_add' 4796 Target does not support a vector add instruction on 'int'. 4797 4798'vect_no_bitwise' 4799 Target does not support vector bitwise instructions. 4800 4801'vect_bool_cmp' 4802 Target supports comparison of 'bool' vectors for at least one 4803 vector length. 4804 4805'vect_char_add' 4806 Target supports addition of 'char' vectors for at least one vector 4807 length. 4808 4809'vect_char_mult' 4810 Target supports 'vector char' multiplication. 4811 4812'vect_short_mult' 4813 Target supports 'vector short' multiplication. 4814 4815'vect_int_mult' 4816 Target supports 'vector int' multiplication. 4817 4818'vect_long_mult' 4819 Target supports 64 bit 'vector long' multiplication. 4820 4821'vect_extract_even_odd' 4822 Target supports vector even/odd element extraction. 4823 4824'vect_extract_even_odd_wide' 4825 Target supports vector even/odd element extraction of vectors with 4826 elements 'SImode' or larger. 4827 4828'vect_interleave' 4829 Target supports vector interleaving. 4830 4831'vect_strided' 4832 Target supports vector interleaving and extract even/odd. 4833 4834'vect_strided_wide' 4835 Target supports vector interleaving and extract even/odd for wide 4836 element types. 4837 4838'vect_perm' 4839 Target supports vector permutation. 4840 4841'vect_perm_byte' 4842 Target supports permutation of vectors with 8-bit elements. 4843 4844'vect_perm_short' 4845 Target supports permutation of vectors with 16-bit elements. 4846 4847'vect_perm3_byte' 4848 Target supports permutation of vectors with 8-bit elements, and for 4849 the default vector length it is possible to permute: 4850 { a0, a1, a2, b0, b1, b2, ... } 4851 to: 4852 { a0, a0, a0, b0, b0, b0, ... } 4853 { a1, a1, a1, b1, b1, b1, ... } 4854 { a2, a2, a2, b2, b2, b2, ... } 4855 using only two-vector permutes, regardless of how long the sequence 4856 is. 4857 4858'vect_perm3_int' 4859 Like 'vect_perm3_byte', but for 32-bit elements. 4860 4861'vect_perm3_short' 4862 Like 'vect_perm3_byte', but for 16-bit elements. 4863 4864'vect_shift' 4865 Target supports a hardware vector shift operation. 4866 4867'vect_unaligned_possible' 4868 Target prefers vectors to have an alignment greater than element 4869 alignment, but also allows unaligned vector accesses in some 4870 circumstances. 4871 4872'vect_variable_length' 4873 Target has variable-length vectors. 4874 4875'vect_widen_sum_hi_to_si' 4876 Target supports a vector widening summation of 'short' operands 4877 into 'int' results, or can promote (unpack) from 'short' to 'int'. 4878 4879'vect_widen_sum_qi_to_hi' 4880 Target supports a vector widening summation of 'char' operands into 4881 'short' results, or can promote (unpack) from 'char' to 'short'. 4882 4883'vect_widen_sum_qi_to_si' 4884 Target supports a vector widening summation of 'char' operands into 4885 'int' results. 4886 4887'vect_widen_mult_qi_to_hi' 4888 Target supports a vector widening multiplication of 'char' operands 4889 into 'short' results, or can promote (unpack) from 'char' to 4890 'short' and perform non-widening multiplication of 'short'. 4891 4892'vect_widen_mult_hi_to_si' 4893 Target supports a vector widening multiplication of 'short' 4894 operands into 'int' results, or can promote (unpack) from 'short' 4895 to 'int' and perform non-widening multiplication of 'int'. 4896 4897'vect_widen_mult_si_to_di_pattern' 4898 Target supports a vector widening multiplication of 'int' operands 4899 into 'long' results. 4900 4901'vect_sdot_qi' 4902 Target supports a vector dot-product of 'signed char'. 4903 4904'vect_udot_qi' 4905 Target supports a vector dot-product of 'unsigned char'. 4906 4907'vect_sdot_hi' 4908 Target supports a vector dot-product of 'signed short'. 4909 4910'vect_udot_hi' 4911 Target supports a vector dot-product of 'unsigned short'. 4912 4913'vect_pack_trunc' 4914 Target supports a vector demotion (packing) of 'short' to 'char' 4915 and from 'int' to 'short' using modulo arithmetic. 4916 4917'vect_unpack' 4918 Target supports a vector promotion (unpacking) of 'char' to 'short' 4919 and from 'char' to 'int'. 4920 4921'vect_intfloat_cvt' 4922 Target supports conversion from 'signed int' to 'float'. 4923 4924'vect_uintfloat_cvt' 4925 Target supports conversion from 'unsigned int' to 'float'. 4926 4927'vect_floatint_cvt' 4928 Target supports conversion from 'float' to 'signed int'. 4929 4930'vect_floatuint_cvt' 4931 Target supports conversion from 'float' to 'unsigned int'. 4932 4933'vect_intdouble_cvt' 4934 Target supports conversion from 'signed int' to 'double'. 4935 4936'vect_doubleint_cvt' 4937 Target supports conversion from 'double' to 'signed int'. 4938 4939'vect_max_reduc' 4940 Target supports max reduction for vectors. 4941 4942'vect_sizes_16B_8B' 4943 Target supports 16- and 8-bytes vectors. 4944 4945'vect_sizes_32B_16B' 4946 Target supports 32- and 16-bytes vectors. 4947 4948'vect_logical_reduc' 4949 Target supports AND, IOR and XOR reduction on vectors. 4950 4951'vect_fold_extract_last' 4952 Target supports the 'fold_extract_last' optab. 4953 4954'vect_len_load_store' 4955 Target supports the 'len_load' and 'len_store' optabs. 4956 4957'vect_partial_vectors_usage_1' 4958 Target supports loop vectorization with partial vectors and 4959 'vect-partial-vector-usage' is set to 1. 4960 4961'vect_partial_vectors_usage_2' 4962 Target supports loop vectorization with partial vectors and 4963 'vect-partial-vector-usage' is set to 2. 4964 4965'vect_partial_vectors' 4966 Target supports loop vectorization with partial vectors and 4967 'vect-partial-vector-usage' is nonzero. 4968 49697.2.3.5 Thread Local Storage attributes 4970....................................... 4971 4972'tls' 4973 Target supports thread-local storage. 4974 4975'tls_native' 4976 Target supports native (rather than emulated) thread-local storage. 4977 4978'tls_runtime' 4979 Test system supports executing TLS executables. 4980 49817.2.3.6 Decimal floating point attributes 4982......................................... 4983 4984'dfp' 4985 Targets supports compiling decimal floating point extension to C. 4986 4987'dfp_nocache' 4988 Including the options used to compile this particular test, the 4989 target supports compiling decimal floating point extension to C. 4990 4991'dfprt' 4992 Test system can execute decimal floating point tests. 4993 4994'dfprt_nocache' 4995 Including the options used to compile this particular test, the 4996 test system can execute decimal floating point tests. 4997 4998'hard_dfp' 4999 Target generates decimal floating point instructions with current 5000 options. 5001 50027.2.3.7 ARM-specific attributes 5003............................... 5004 5005'arm32' 5006 ARM target generates 32-bit code. 5007 5008'arm_little_endian' 5009 ARM target that generates little-endian code. 5010 5011'arm_eabi' 5012 ARM target adheres to the ABI for the ARM Architecture. 5013 5014'arm_fp_ok' 5015 ARM target defines '__ARM_FP' using '-mfloat-abi=softfp' or 5016 equivalent options. Some multilibs may be incompatible with these 5017 options. 5018 5019'arm_fp_dp_ok' 5020 ARM target defines '__ARM_FP' with double-precision support using 5021 '-mfloat-abi=softfp' or equivalent options. Some multilibs may be 5022 incompatible with these options. 5023 5024'arm_hf_eabi' 5025 ARM target adheres to the VFP and Advanced SIMD Register Arguments 5026 variant of the ABI for the ARM Architecture (as selected with 5027 '-mfloat-abi=hard'). 5028 5029'arm_softfloat' 5030 ARM target uses emulated floating point operations. 5031 5032'arm_hard_vfp_ok' 5033 ARM target supports '-mfpu=vfp -mfloat-abi=hard'. Some multilibs 5034 may be incompatible with these options. 5035 5036'arm_iwmmxt_ok' 5037 ARM target supports '-mcpu=iwmmxt'. Some multilibs may be 5038 incompatible with this option. 5039 5040'arm_neon' 5041 ARM target supports generating NEON instructions. 5042 5043'arm_tune_string_ops_prefer_neon' 5044 Test CPU tune supports inlining string operations with NEON 5045 instructions. 5046 5047'arm_neon_hw' 5048 Test system supports executing NEON instructions. 5049 5050'arm_neonv2_hw' 5051 Test system supports executing NEON v2 instructions. 5052 5053'arm_neon_ok' 5054 ARM Target supports '-mfpu=neon -mfloat-abi=softfp' or compatible 5055 options. Some multilibs may be incompatible with these options. 5056 5057'arm_neon_ok_no_float_abi' 5058 ARM Target supports NEON with '-mfpu=neon', but without any 5059 -mfloat-abi= option. Some multilibs may be incompatible with this 5060 option. 5061 5062'arm_neonv2_ok' 5063 ARM Target supports '-mfpu=neon-vfpv4 -mfloat-abi=softfp' or 5064 compatible options. Some multilibs may be incompatible with these 5065 options. 5066 5067'arm_fp16_ok' 5068 Target supports options to generate VFP half-precision 5069 floating-point instructions. Some multilibs may be incompatible 5070 with these options. This test is valid for ARM only. 5071 5072'arm_fp16_hw' 5073 Target supports executing VFP half-precision floating-point 5074 instructions. This test is valid for ARM only. 5075 5076'arm_neon_fp16_ok' 5077 ARM Target supports '-mfpu=neon-fp16 -mfloat-abi=softfp' or 5078 compatible options, including '-mfp16-format=ieee' if necessary to 5079 obtain the '__fp16' type. Some multilibs may be incompatible with 5080 these options. 5081 5082'arm_neon_fp16_hw' 5083 Test system supports executing Neon half-precision float 5084 instructions. (Implies previous.) 5085 5086'arm_fp16_alternative_ok' 5087 ARM target supports the ARM FP16 alternative format. Some 5088 multilibs may be incompatible with the options needed. 5089 5090'arm_fp16_none_ok' 5091 ARM target supports specifying none as the ARM FP16 format. 5092 5093'arm_thumb1_ok' 5094 ARM target generates Thumb-1 code for '-mthumb'. 5095 5096'arm_thumb2_ok' 5097 ARM target generates Thumb-2 code for '-mthumb'. 5098 5099'arm_nothumb' 5100 ARM target that is not using Thumb. 5101 5102'arm_vfp_ok' 5103 ARM target supports '-mfpu=vfp -mfloat-abi=softfp'. Some multilibs 5104 may be incompatible with these options. 5105 5106'arm_vfp3_ok' 5107 ARM target supports '-mfpu=vfp3 -mfloat-abi=softfp'. Some 5108 multilibs may be incompatible with these options. 5109 5110'arm_arch_v8a_hard_ok' 5111 The compiler is targeting 'arm*-*-*' and can compile and assemble 5112 code using the options '-march=armv8-a -mfpu=neon-fp-armv8 5113 -mfloat-abi=hard'. This is not enough to guarantee that linking 5114 works. 5115 5116'arm_arch_v8a_hard_multilib' 5117 The compiler is targeting 'arm*-*-*' and can build programs using 5118 the options '-march=armv8-a -mfpu=neon-fp-armv8 -mfloat-abi=hard'. 5119 The target can also run the resulting binaries. 5120 5121'arm_v8_vfp_ok' 5122 ARM target supports '-mfpu=fp-armv8 -mfloat-abi=softfp'. Some 5123 multilibs may be incompatible with these options. 5124 5125'arm_v8_neon_ok' 5126 ARM target supports '-mfpu=neon-fp-armv8 -mfloat-abi=softfp'. Some 5127 multilibs may be incompatible with these options. 5128 5129'arm_v8_1a_neon_ok' 5130 ARM target supports options to generate ARMv8.1-A Adv.SIMD 5131 instructions. Some multilibs may be incompatible with these 5132 options. 5133 5134'arm_v8_1a_neon_hw' 5135 ARM target supports executing ARMv8.1-A Adv.SIMD instructions. 5136 Some multilibs may be incompatible with the options needed. 5137 Implies arm_v8_1a_neon_ok. 5138 5139'arm_acq_rel' 5140 ARM target supports acquire-release instructions. 5141 5142'arm_v8_2a_fp16_scalar_ok' 5143 ARM target supports options to generate instructions for ARMv8.2-A 5144 and scalar instructions from the FP16 extension. Some multilibs 5145 may be incompatible with these options. 5146 5147'arm_v8_2a_fp16_scalar_hw' 5148 ARM target supports executing instructions for ARMv8.2-A and scalar 5149 instructions from the FP16 extension. Some multilibs may be 5150 incompatible with these options. Implies arm_v8_2a_fp16_neon_ok. 5151 5152'arm_v8_2a_fp16_neon_ok' 5153 ARM target supports options to generate instructions from ARMv8.2-A 5154 with the FP16 extension. Some multilibs may be incompatible with 5155 these options. Implies arm_v8_2a_fp16_scalar_ok. 5156 5157'arm_v8_2a_fp16_neon_hw' 5158 ARM target supports executing instructions from ARMv8.2-A with the 5159 FP16 extension. Some multilibs may be incompatible with these 5160 options. Implies arm_v8_2a_fp16_neon_ok and 5161 arm_v8_2a_fp16_scalar_hw. 5162 5163'arm_v8_2a_dotprod_neon_ok' 5164 ARM target supports options to generate instructions from ARMv8.2-A 5165 with the Dot Product extension. Some multilibs may be incompatible 5166 with these options. 5167 5168'arm_v8_2a_dotprod_neon_hw' 5169 ARM target supports executing instructions from ARMv8.2-A with the 5170 Dot Product extension. Some multilibs may be incompatible with 5171 these options. Implies arm_v8_2a_dotprod_neon_ok. 5172 5173'arm_fp16fml_neon_ok' 5174 ARM target supports extensions to generate the 'VFMAL' and 'VFMLS' 5175 half-precision floating-point instructions available from ARMv8.2-A 5176 and onwards. Some multilibs may be incompatible with these 5177 options. 5178 5179'arm_v8_2a_bf16_neon_ok' 5180 ARM target supports options to generate instructions from ARMv8.2-A 5181 with the BFloat16 extension (bf16). Some multilibs may be 5182 incompatible with these options. 5183 5184'arm_v8_2a_i8mm_ok' 5185 ARM target supports options to generate instructions from ARMv8.2-A 5186 with the 8-Bit Integer Matrix Multiply extension (i8mm). Some 5187 multilibs may be incompatible with these options. 5188 5189'arm_v8_1m_mve_ok' 5190 ARM target supports options to generate instructions from ARMv8.1-M 5191 with the M-Profile Vector Extension (MVE). Some multilibs may be 5192 incompatible with these options. 5193 5194'arm_v8_1m_mve_fp_ok' 5195 ARM target supports options to generate instructions from ARMv8.1-M 5196 with the Half-precision floating-point instructions (HP), 5197 Floating-point Extension (FP) along with M-Profile Vector Extension 5198 (MVE). Some multilibs may be incompatible with these options. 5199 5200'arm_mve_hw' 5201 Test system supports executing MVE instructions. 5202 5203'arm_v8m_main_cde' 5204 ARM target supports options to generate instructions from ARMv8-M 5205 with the Custom Datapath Extension (CDE). Some multilibs may be 5206 incompatible with these options. 5207 5208'arm_v8m_main_cde_fp' 5209 ARM target supports options to generate instructions from ARMv8-M 5210 with the Custom Datapath Extension (CDE) and floating-point (VFP). 5211 Some multilibs may be incompatible with these options. 5212 5213'arm_v8_1m_main_cde_mve' 5214 ARM target supports options to generate instructions from ARMv8.1-M 5215 with the Custom Datapath Extension (CDE) and M-Profile Vector 5216 Extension (MVE). Some multilibs may be incompatible with these 5217 options. 5218 5219'arm_prefer_ldrd_strd' 5220 ARM target prefers 'LDRD' and 'STRD' instructions over 'LDM' and 5221 'STM' instructions. 5222 5223'arm_thumb1_movt_ok' 5224 ARM target generates Thumb-1 code for '-mthumb' with 'MOVW' and 5225 'MOVT' instructions available. 5226 5227'arm_thumb1_cbz_ok' 5228 ARM target generates Thumb-1 code for '-mthumb' with 'CBZ' and 5229 'CBNZ' instructions available. 5230 5231'arm_divmod_simode' 5232 ARM target for which divmod transform is disabled, if it supports 5233 hardware div instruction. 5234 5235'arm_cmse_ok' 5236 ARM target supports ARMv8-M Security Extensions, enabled by the 5237 '-mcmse' option. 5238 5239'arm_coproc1_ok' 5240 ARM target supports the following coprocessor instructions: 'CDP', 5241 'LDC', 'STC', 'MCR' and 'MRC'. 5242 5243'arm_coproc2_ok' 5244 ARM target supports all the coprocessor instructions also listed as 5245 supported in *note arm_coproc1_ok:: in addition to the following: 5246 'CDP2', 'LDC2', 'LDC2l', 'STC2', 'STC2l', 'MCR2' and 'MRC2'. 5247 5248'arm_coproc3_ok' 5249 ARM target supports all the coprocessor instructions also listed as 5250 supported in *note arm_coproc2_ok:: in addition the following: 5251 'MCRR' and 'MRRC'. 5252 5253'arm_coproc4_ok' 5254 ARM target supports all the coprocessor instructions also listed as 5255 supported in *note arm_coproc3_ok:: in addition the following: 5256 'MCRR2' and 'MRRC2'. 5257 5258'arm_simd32_ok' 5259 ARM Target supports options suitable for accessing the SIMD32 5260 intrinsics from 'arm_acle.h'. Some multilibs may be incompatible 5261 with these options. 5262 5263'arm_qbit_ok' 5264 ARM Target supports options suitable for accessing the Q-bit 5265 manipulation intrinsics from 'arm_acle.h'. Some multilibs may be 5266 incompatible with these options. 5267 5268'arm_dsp_ok' 5269 ARM Target supports options suitable for accessing the DSP 5270 intrinsics from 'arm_acle.h'. Some multilibs may be incompatible 5271 with these options. 5272 5273'arm_softfp_ok' 5274 ARM target supports the '-mfloat-abi=softfp' option. 5275 5276'arm_hard_ok' 5277 ARM target supports the '-mfloat-abi=hard' option. 5278 5279'arm_v8_1_lob_ok' 5280 ARM Target supports executing the Armv8.1-M Mainline Low Overhead 5281 Loop instructions 'DLS' and 'LE'. Some multilibs may be 5282 incompatible with these options. 5283 5284'arm_thumb2_no_arm_v8_1_lob' 5285 ARM target where Thumb-2 is used without options but does not 5286 support executing the Armv8.1-M Mainline Low Overhead Loop 5287 instructions 'DLS' and 'LE'. 5288 5289'arm_thumb2_ok_no_arm_v8_1_lob' 5290 ARM target generates Thumb-2 code for '-mthumb' but does not 5291 support executing the Armv8.1-M Mainline Low Overhead Loop 5292 instructions 'DLS' and 'LE'. 5293 52947.2.3.8 AArch64-specific attributes 5295................................... 5296 5297'aarch64_asm_<ext>_ok' 5298 AArch64 assembler supports the architecture extension 'ext' via the 5299 '.arch_extension' pseudo-op. 5300'aarch64_tiny' 5301 AArch64 target which generates instruction sequences for tiny 5302 memory model. 5303'aarch64_small' 5304 AArch64 target which generates instruction sequences for small 5305 memory model. 5306'aarch64_large' 5307 AArch64 target which generates instruction sequences for large 5308 memory model. 5309'aarch64_little_endian' 5310 AArch64 target which generates instruction sequences for little 5311 endian. 5312'aarch64_big_endian' 5313 AArch64 target which generates instruction sequences for big 5314 endian. 5315'aarch64_small_fpic' 5316 Binutils installed on test system supports relocation types 5317 required by -fpic for AArch64 small memory model. 5318'aarch64_sve_hw' 5319 AArch64 target that is able to generate and execute SVE code 5320 (regardless of whether it does so by default). 5321'aarch64_sve128_hw' 5322'aarch64_sve256_hw' 5323'aarch64_sve512_hw' 5324'aarch64_sve1024_hw' 5325'aarch64_sve2048_hw' 5326 Like 'aarch64_sve_hw', but also test for an exact hardware vector 5327 length. 5328 5329'aarch64_fjcvtzs_hw' 5330 AArch64 target that is able to generate and execute armv8.3-a 5331 FJCVTZS instruction. 5332 53337.2.3.9 MIPS-specific attributes 5334................................ 5335 5336'mips64' 5337 MIPS target supports 64-bit instructions. 5338 5339'nomips16' 5340 MIPS target does not produce MIPS16 code. 5341 5342'mips16_attribute' 5343 MIPS target can generate MIPS16 code. 5344 5345'mips_loongson' 5346 MIPS target is a Loongson-2E or -2F target using an ABI that 5347 supports the Loongson vector modes. 5348 5349'mips_msa' 5350 MIPS target supports '-mmsa', MIPS SIMD Architecture (MSA). 5351 5352'mips_newabi_large_long_double' 5353 MIPS target supports 'long double' larger than 'double' when using 5354 the new ABI. 5355 5356'mpaired_single' 5357 MIPS target supports '-mpaired-single'. 5358 53597.2.3.10 MSP430-specific attributes 5360................................... 5361 5362'msp430_small' 5363 MSP430 target has the small memory model enabled ('-msmall'). 5364 5365'msp430_large' 5366 MSP430 target has the large memory model enabled ('-mlarge'). 5367 53687.2.3.11 PowerPC-specific attributes 5369.................................... 5370 5371'dfp_hw' 5372 PowerPC target supports executing hardware DFP instructions. 5373 5374'p8vector_hw' 5375 PowerPC target supports executing VSX instructions (ISA 2.07). 5376 5377'powerpc64' 5378 Test system supports executing 64-bit instructions. 5379 5380'powerpc_altivec' 5381 PowerPC target supports AltiVec. 5382 5383'powerpc_altivec_ok' 5384 PowerPC target supports '-maltivec'. 5385 5386'powerpc_eabi_ok' 5387 PowerPC target supports '-meabi'. 5388 5389'powerpc_elfv2' 5390 PowerPC target supports '-mabi=elfv2'. 5391 5392'powerpc_fprs' 5393 PowerPC target supports floating-point registers. 5394 5395'powerpc_hard_double' 5396 PowerPC target supports hardware double-precision floating-point. 5397 5398'powerpc_htm_ok' 5399 PowerPC target supports '-mhtm' 5400 5401'powerpc_p8vector_ok' 5402 PowerPC target supports '-mpower8-vector' 5403 5404'powerpc_popcntb_ok' 5405 PowerPC target supports the 'popcntb' instruction, indicating that 5406 this target supports '-mcpu=power5'. 5407 5408'powerpc_ppu_ok' 5409 PowerPC target supports '-mcpu=cell'. 5410 5411'powerpc_spe' 5412 PowerPC target supports PowerPC SPE. 5413 5414'powerpc_spe_nocache' 5415 Including the options used to compile this particular test, the 5416 PowerPC target supports PowerPC SPE. 5417 5418'powerpc_spu' 5419 PowerPC target supports PowerPC SPU. 5420 5421'powerpc_vsx_ok' 5422 PowerPC target supports '-mvsx'. 5423 5424'powerpc_405_nocache' 5425 Including the options used to compile this particular test, the 5426 PowerPC target supports PowerPC 405. 5427 5428'ppc_recip_hw' 5429 PowerPC target supports executing reciprocal estimate instructions. 5430 5431'vmx_hw' 5432 PowerPC target supports executing AltiVec instructions. 5433 5434'vsx_hw' 5435 PowerPC target supports executing VSX instructions (ISA 2.06). 5436 5437'has_arch_pwr5' 5438 PowerPC target pre-defines macro _ARCH_PWR5 which means the '-mcpu' 5439 setting is Power5 or later. 5440 5441'has_arch_pwr6' 5442 PowerPC target pre-defines macro _ARCH_PWR6 which means the '-mcpu' 5443 setting is Power6 or later. 5444 5445'has_arch_pwr7' 5446 PowerPC target pre-defines macro _ARCH_PWR7 which means the '-mcpu' 5447 setting is Power7 or later. 5448 5449'has_arch_pwr8' 5450 PowerPC target pre-defines macro _ARCH_PWR8 which means the '-mcpu' 5451 setting is Power8 or later. 5452 5453'has_arch_pwr9' 5454 PowerPC target pre-defines macro _ARCH_PWR9 which means the '-mcpu' 5455 setting is Power9 or later. 5456 54577.2.3.12 Other hardware attributes 5458.................................. 5459 5460'autoincdec' 5461 Target supports autoincrement/decrement addressing. 5462 5463'avx' 5464 Target supports compiling 'avx' instructions. 5465 5466'avx_runtime' 5467 Target supports the execution of 'avx' instructions. 5468 5469'avx2' 5470 Target supports compiling 'avx2' instructions. 5471 5472'avx2_runtime' 5473 Target supports the execution of 'avx2' instructions. 5474 5475'avxvnni' 5476 Target supports the execution of 'avxvnni' instructions. 5477 5478'avx512f' 5479 Target supports compiling 'avx512f' instructions. 5480 5481'avx512f_runtime' 5482 Target supports the execution of 'avx512f' instructions. 5483 5484'avx512vp2intersect' 5485 Target supports the execution of 'avx512vp2intersect' instructions. 5486 5487'amx_tile' 5488 Target supports the execution of 'amx-tile' instructions. 5489 5490'amx_int8' 5491 Target supports the execution of 'amx-int8' instructions. 5492 5493'amx_bf16' 5494 Target supports the execution of 'amx-bf16' instructions. 5495 5496'cell_hw' 5497 Test system can execute AltiVec and Cell PPU instructions. 5498 5499'coldfire_fpu' 5500 Target uses a ColdFire FPU. 5501 5502'divmod' 5503 Target supporting hardware divmod insn or divmod libcall. 5504 5505'divmod_simode' 5506 Target supporting hardware divmod insn or divmod libcall for 5507 SImode. 5508 5509'hard_float' 5510 Target supports FPU instructions. 5511 5512'non_strict_align' 5513 Target does not require strict alignment. 5514 5515'pie_copyreloc' 5516 The x86-64 target linker supports PIE with copy reloc. 5517 5518'rdrand' 5519 Target supports x86 'rdrand' instruction. 5520 5521'sqrt_insn' 5522 Target has a square root instruction that the compiler can 5523 generate. 5524 5525'sse' 5526 Target supports compiling 'sse' instructions. 5527 5528'sse_runtime' 5529 Target supports the execution of 'sse' instructions. 5530 5531'sse2' 5532 Target supports compiling 'sse2' instructions. 5533 5534'sse2_runtime' 5535 Target supports the execution of 'sse2' instructions. 5536 5537'sync_char_short' 5538 Target supports atomic operations on 'char' and 'short'. 5539 5540'sync_int_long' 5541 Target supports atomic operations on 'int' and 'long'. 5542 5543'ultrasparc_hw' 5544 Test environment appears to run executables on a simulator that 5545 accepts only 'EM_SPARC' executables and chokes on 'EM_SPARC32PLUS' 5546 or 'EM_SPARCV9' executables. 5547 5548'vect_cmdline_needed' 5549 Target requires a command line argument to enable a SIMD 5550 instruction set. 5551 5552'xorsign' 5553 Target supports the xorsign optab expansion. 5554 55557.2.3.13 Environment attributes 5556............................... 5557 5558'c' 5559 The language for the compiler under test is C. 5560 5561'c++' 5562 The language for the compiler under test is C++. 5563 5564'c99_runtime' 5565 Target provides a full C99 runtime. 5566 5567'correct_iso_cpp_string_wchar_protos' 5568 Target 'string.h' and 'wchar.h' headers provide C++ required 5569 overloads for 'strchr' etc. functions. 5570 5571'd_runtime' 5572 Target provides the D runtime. 5573 5574'd_runtime_has_std_library' 5575 Target provides the D standard library (Phobos). 5576 5577'dummy_wcsftime' 5578 Target uses a dummy 'wcsftime' function that always returns zero. 5579 5580'fd_truncate' 5581 Target can truncate a file from a file descriptor, as used by 5582 'libgfortran/io/unix.c:fd_truncate'; i.e. 'ftruncate' or 'chsize'. 5583 5584'fenv' 5585 Target provides 'fenv.h' include file. 5586 5587'fenv_exceptions' 5588 Target supports 'fenv.h' with all the standard IEEE exceptions and 5589 floating-point exceptions are raised by arithmetic operations. 5590 5591'fenv_exceptions_dfp' 5592 Target supports 'fenv.h' with all the standard IEEE exceptions and 5593 floating-point exceptions are raised by arithmetic operations for 5594 decimal floating point. 5595 5596'fileio' 5597 Target offers such file I/O library functions as 'fopen', 'fclose', 5598 'tmpnam', and 'remove'. This is a link-time requirement for the 5599 presence of the functions in the library; even if they fail at 5600 runtime, the requirement is still regarded as satisfied. 5601 5602'freestanding' 5603 Target is 'freestanding' as defined in section 4 of the C99 5604 standard. Effectively, it is a target which supports no extra 5605 headers or libraries other than what is considered essential. 5606 5607'gettimeofday' 5608 Target supports 'gettimeofday'. 5609 5610'init_priority' 5611 Target supports constructors with initialization priority 5612 arguments. 5613 5614'inttypes_types' 5615 Target has the basic signed and unsigned types in 'inttypes.h'. 5616 This is for tests that GCC's notions of these types agree with 5617 those in the header, as some systems have only 'inttypes.h'. 5618 5619'lax_strtofp' 5620 Target might have errors of a few ULP in string to floating-point 5621 conversion functions and overflow is not always detected correctly 5622 by those functions. 5623 5624'mempcpy' 5625 Target provides 'mempcpy' function. 5626 5627'mmap' 5628 Target supports 'mmap'. 5629 5630'newlib' 5631 Target supports Newlib. 5632 5633'newlib_nano_io' 5634 GCC was configured with '--enable-newlib-nano-formatted-io', which 5635 reduces the code size of Newlib formatted I/O functions. 5636 5637'pow10' 5638 Target provides 'pow10' function. 5639 5640'pthread' 5641 Target can compile using 'pthread.h' with no errors or warnings. 5642 5643'pthread_h' 5644 Target has 'pthread.h'. 5645 5646'run_expensive_tests' 5647 Expensive testcases (usually those that consume excessive amounts 5648 of CPU time) should be run on this target. This can be enabled by 5649 setting the 'GCC_TEST_RUN_EXPENSIVE' environment variable to a 5650 non-empty string. 5651 5652'simulator' 5653 Test system runs executables on a simulator (i.e. slowly) rather 5654 than hardware (i.e. fast). 5655 5656'signal' 5657 Target has 'signal.h'. 5658 5659'stabs' 5660 Target supports the stabs debugging format. 5661 5662'stdint_types' 5663 Target has the basic signed and unsigned C types in 'stdint.h'. 5664 This will be obsolete when GCC ensures a working 'stdint.h' for all 5665 targets. 5666 5667'stdint_types_mbig_endian' 5668 Target accepts the option '-mbig-endian' and 'stdint.h' can be 5669 included without error when '-mbig-endian' is passed. 5670 5671'stpcpy' 5672 Target provides 'stpcpy' function. 5673 5674'sysconf' 5675 Target supports 'sysconf'. 5676 5677'trampolines' 5678 Target supports trampolines. 5679 5680'uclibc' 5681 Target supports uClibc. 5682 5683'unwrapped' 5684 Target does not use a status wrapper. 5685 5686'vxworks_kernel' 5687 Target is a VxWorks kernel. 5688 5689'vxworks_rtp' 5690 Target is a VxWorks RTP. 5691 5692'wchar' 5693 Target supports wide characters. 5694 56957.2.3.14 Other attributes 5696......................... 5697 5698'R_flag_in_section' 5699 Target supports the 'R' flag in .section directive in assembly 5700 inputs. 5701 5702'automatic_stack_alignment' 5703 Target supports automatic stack alignment. 5704 5705'branch_cost' 5706 Target supports '-branch-cost=N'. 5707 5708'cxa_atexit' 5709 Target uses '__cxa_atexit'. 5710 5711'default_packed' 5712 Target has packed layout of structure members by default. 5713 5714'exceptions' 5715 Target supports exceptions. 5716 5717'exceptions_enabled' 5718 Target supports exceptions and they are enabled in the current 5719 testing configuration. 5720 5721'fgraphite' 5722 Target supports Graphite optimizations. 5723 5724'fixed_point' 5725 Target supports fixed-point extension to C. 5726 5727'fopenacc' 5728 Target supports OpenACC via '-fopenacc'. 5729 5730'fopenmp' 5731 Target supports OpenMP via '-fopenmp'. 5732 5733'fpic' 5734 Target supports '-fpic' and '-fPIC'. 5735 5736'freorder' 5737 Target supports '-freorder-blocks-and-partition'. 5738 5739'fstack_protector' 5740 Target supports '-fstack-protector'. 5741 5742'gas' 5743 Target uses GNU 'as'. 5744 5745'gc_sections' 5746 Target supports '--gc-sections'. 5747 5748'gld' 5749 Target uses GNU 'ld'. 5750 5751'keeps_null_pointer_checks' 5752 Target keeps null pointer checks, either due to the use of 5753 '-fno-delete-null-pointer-checks' or hardwired into the target. 5754 5755'llvm_binutils' 5756 Target is using an LLVM assembler and/or linker, instead of GNU 5757 Binutils. 5758 5759'lra' 5760 Target supports local register allocator (LRA). 5761 5762'lto' 5763 Compiler has been configured to support link-time optimization 5764 (LTO). 5765 5766'lto_incremental' 5767 Compiler and linker support link-time optimization relocatable 5768 linking with '-r' and '-flto' options. 5769 5770'naked_functions' 5771 Target supports the 'naked' function attribute. 5772 5773'named_sections' 5774 Target supports named sections. 5775 5776'natural_alignment_32' 5777 Target uses natural alignment (aligned to type size) for types of 5778 32 bits or less. 5779 5780'target_natural_alignment_64' 5781 Target uses natural alignment (aligned to type size) for types of 5782 64 bits or less. 5783 5784'noinit' 5785 Target supports the 'noinit' variable attribute. 5786 5787'nonpic' 5788 Target does not generate PIC by default. 5789 5790'o_flag_in_section' 5791 Target supports the 'o' flag in .section directive in assembly 5792 inputs. 5793 5794'offload_gcn' 5795 Target has been configured for OpenACC/OpenMP offloading on AMD 5796 GCN. 5797 5798'persistent' 5799 Target supports the 'persistent' variable attribute. 5800 5801'pie_enabled' 5802 Target generates PIE by default. 5803 5804'pcc_bitfield_type_matters' 5805 Target defines 'PCC_BITFIELD_TYPE_MATTERS'. 5806 5807'pe_aligned_commons' 5808 Target supports '-mpe-aligned-commons'. 5809 5810'pie' 5811 Target supports '-pie', '-fpie' and '-fPIE'. 5812 5813'rdynamic' 5814 Target supports '-rdynamic'. 5815 5816'scalar_all_fma' 5817 Target supports all four fused multiply-add optabs for both 'float' 5818 and 'double'. These optabs are: 'fma_optab', 'fms_optab', 5819 'fnma_optab' and 'fnms_optab'. 5820 5821'section_anchors' 5822 Target supports section anchors. 5823 5824'short_enums' 5825 Target defaults to short enums. 5826 5827'stack_size' 5828 Target has limited stack size. The stack size limit can be 5829 obtained using the STACK_SIZE macro defined by *note 5830 'dg-add-options' feature 'stack_size': stack_size_ao. 5831 5832'static' 5833 Target supports '-static'. 5834 5835'static_libgfortran' 5836 Target supports statically linking 'libgfortran'. 5837 5838'string_merging' 5839 Target supports merging string constants at link time. 5840 5841'ucn' 5842 Target supports compiling and assembling UCN. 5843 5844'ucn_nocache' 5845 Including the options used to compile this particular test, the 5846 target supports compiling and assembling UCN. 5847 5848'unaligned_stack' 5849 Target does not guarantee that its 'STACK_BOUNDARY' is greater than 5850 or equal to the required vector alignment. 5851 5852'vector_alignment_reachable' 5853 Vector alignment is reachable for types of 32 bits or less. 5854 5855'vector_alignment_reachable_for_64bit' 5856 Vector alignment is reachable for types of 64 bits or less. 5857 5858'wchar_t_char16_t_compatible' 5859 Target supports 'wchar_t' that is compatible with 'char16_t'. 5860 5861'wchar_t_char32_t_compatible' 5862 Target supports 'wchar_t' that is compatible with 'char32_t'. 5863 5864'comdat_group' 5865 Target uses comdat groups. 5866 5867'indirect_calls' 5868 Target supports indirect calls, i.e. calls where the target is not 5869 constant. 5870 5871'lgccjit' 5872 Target supports -lgccjit, i.e. libgccjit.so can be linked into jit 5873 tests. 5874 58757.2.3.15 Local to tests in 'gcc.target/i386' 5876............................................ 5877 5878'3dnow' 5879 Target supports compiling '3dnow' instructions. 5880 5881'aes' 5882 Target supports compiling 'aes' instructions. 5883 5884'fma4' 5885 Target supports compiling 'fma4' instructions. 5886 5887'mfentry' 5888 Target supports the '-mfentry' option that alters the position of 5889 profiling calls such that they precede the prologue. 5890 5891'ms_hook_prologue' 5892 Target supports attribute 'ms_hook_prologue'. 5893 5894'pclmul' 5895 Target supports compiling 'pclmul' instructions. 5896 5897'sse3' 5898 Target supports compiling 'sse3' instructions. 5899 5900'sse4' 5901 Target supports compiling 'sse4' instructions. 5902 5903'sse4a' 5904 Target supports compiling 'sse4a' instructions. 5905 5906'ssse3' 5907 Target supports compiling 'ssse3' instructions. 5908 5909'vaes' 5910 Target supports compiling 'vaes' instructions. 5911 5912'vpclmul' 5913 Target supports compiling 'vpclmul' instructions. 5914 5915'xop' 5916 Target supports compiling 'xop' instructions. 5917 59187.2.3.16 Local to tests in 'gcc.test-framework' 5919............................................... 5920 5921'no' 5922 Always returns 0. 5923 5924'yes' 5925 Always returns 1. 5926 5927 5928File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives 5929 59307.2.4 Features for 'dg-add-options' 5931----------------------------------- 5932 5933The supported values of FEATURE for directive 'dg-add-options' are: 5934 5935'arm_fp' 5936 '__ARM_FP' definition. Only ARM targets support this feature, and 5937 only then in certain modes; see the *note arm_fp_ok effective 5938 target keyword: arm_fp_ok. 5939 5940'arm_fp_dp' 5941 '__ARM_FP' definition with double-precision support. Only ARM 5942 targets support this feature, and only then in certain modes; see 5943 the *note arm_fp_dp_ok effective target keyword: arm_fp_dp_ok. 5944 5945'arm_neon' 5946 NEON support. Only ARM targets support this feature, and only then 5947 in certain modes; see the *note arm_neon_ok effective target 5948 keyword: arm_neon_ok. 5949 5950'arm_fp16' 5951 VFP half-precision floating point support. This does not select 5952 the FP16 format; for that, use *note arm_fp16_ieee: arm_fp16_ieee. 5953 or *note arm_fp16_alternative: arm_fp16_alternative. instead. This 5954 feature is only supported by ARM targets and then only in certain 5955 modes; see the *note arm_fp16_ok effective target keyword: 5956 arm_fp16_ok. 5957 5958'arm_fp16_ieee' 5959 ARM IEEE 754-2008 format VFP half-precision floating point support. 5960 This feature is only supported by ARM targets and then only in 5961 certain modes; see the *note arm_fp16_ok effective target keyword: 5962 arm_fp16_ok. 5963 5964'arm_fp16_alternative' 5965 ARM Alternative format VFP half-precision floating point support. 5966 This feature is only supported by ARM targets and then only in 5967 certain modes; see the *note arm_fp16_ok effective target keyword: 5968 arm_fp16_ok. 5969 5970'arm_neon_fp16' 5971 NEON and half-precision floating point support. Only ARM targets 5972 support this feature, and only then in certain modes; see the *note 5973 arm_neon_fp16_ok effective target keyword: arm_neon_fp16_ok. 5974 5975'arm_vfp3' 5976 arm vfp3 floating point support; see the *note arm_vfp3_ok 5977 effective target keyword: arm_vfp3_ok. 5978 5979'arm_arch_v8a_hard' 5980 Add options for ARMv8-A and the hard-float variant of the AAPCS, if 5981 this is supported by the compiler; see the *note 5982 arm_arch_v8a_hard_ok: arm_arch_v8a_hard_ok. effective target 5983 keyword. 5984 5985'arm_v8_1a_neon' 5986 Add options for ARMv8.1-A with Adv.SIMD support, if this is 5987 supported by the target; see the *note arm_v8_1a_neon_ok: 5988 arm_v8_1a_neon_ok. effective target keyword. 5989 5990'arm_v8_2a_fp16_scalar' 5991 Add options for ARMv8.2-A with scalar FP16 support, if this is 5992 supported by the target; see the *note arm_v8_2a_fp16_scalar_ok: 5993 arm_v8_2a_fp16_scalar_ok. effective target keyword. 5994 5995'arm_v8_2a_fp16_neon' 5996 Add options for ARMv8.2-A with Adv.SIMD FP16 support, if this is 5997 supported by the target; see the *note arm_v8_2a_fp16_neon_ok: 5998 arm_v8_2a_fp16_neon_ok. effective target keyword. 5999 6000'arm_v8_2a_dotprod_neon' 6001 Add options for ARMv8.2-A with Adv.SIMD Dot Product support, if 6002 this is supported by the target; see the *note 6003 arm_v8_2a_dotprod_neon_ok:: effective target keyword. 6004 6005'arm_fp16fml_neon' 6006 Add options to enable generation of the 'VFMAL' and 'VFMSL' 6007 instructions, if this is supported by the target; see the *note 6008 arm_fp16fml_neon_ok:: effective target keyword. 6009 6010'arm_dsp' 6011 Add options for ARM DSP intrinsics support, if this is supported by 6012 the target; see the *note arm_dsp_ok effective target keyword: 6013 arm_dsp_ok. 6014 6015'bind_pic_locally' 6016 Add the target-specific flags needed to enable functions to bind 6017 locally when using pic/PIC passes in the testsuite. 6018 6019'floatN' 6020 Add the target-specific flags needed to use the '_FloatN' type. 6021 6022'floatNx' 6023 Add the target-specific flags needed to use the '_FloatNx' type. 6024 6025'ieee' 6026 Add the target-specific flags needed to enable full IEEE compliance 6027 mode. 6028 6029'mips16_attribute' 6030 'mips16' function attributes. Only MIPS targets support this 6031 feature, and only then in certain modes. 6032 6033'stack_size' 6034 Add the flags needed to define macro STACK_SIZE and set it to the 6035 stack size limit associated with the *note 'stack_size' effective 6036 target: stack_size_et. 6037 6038'sqrt_insn' 6039 Add the target-specific flags needed to enable hardware square root 6040 instructions, if any. 6041 6042'tls' 6043 Add the target-specific flags needed to use thread-local storage. 6044 6045 6046File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives 6047 60487.2.5 Variants of 'dg-require-SUPPORT' 6049-------------------------------------- 6050 6051A few of the 'dg-require' directives take arguments. 6052 6053'dg-require-iconv CODESET' 6054 Skip the test if the target does not support iconv. CODESET is the 6055 codeset to convert to. 6056 6057'dg-require-profiling PROFOPT' 6058 Skip the test if the target does not support profiling with option 6059 PROFOPT. 6060 6061'dg-require-stack-check CHECK' 6062 Skip the test if the target does not support the '-fstack-check' 6063 option. If CHECK is '""', support for '-fstack-check' is checked, 6064 for '-fstack-check=("CHECK")' otherwise. 6065 6066'dg-require-stack-size SIZE' 6067 Skip the test if the target does not support a stack size of SIZE. 6068 6069'dg-require-visibility VIS' 6070 Skip the test if the target does not support the 'visibility' 6071 attribute. If VIS is '""', support for 'visibility("hidden")' is 6072 checked, for 'visibility("VIS")' otherwise. 6073 6074 The original 'dg-require' directives were defined before there was 6075support for effective-target keywords. The directives that do not take 6076arguments could be replaced with effective-target keywords. 6077 6078'dg-require-alias ""' 6079 Skip the test if the target does not support the 'alias' attribute. 6080 6081'dg-require-ascii-locale ""' 6082 Skip the test if the host does not support an ASCII locale. 6083 6084'dg-require-compat-dfp ""' 6085 Skip this test unless both compilers in a 'compat' testsuite 6086 support decimal floating point. 6087 6088'dg-require-cxa-atexit ""' 6089 Skip the test if the target does not support '__cxa_atexit'. This 6090 is equivalent to 'dg-require-effective-target cxa_atexit'. 6091 6092'dg-require-dll ""' 6093 Skip the test if the target does not support DLL attributes. 6094 6095'dg-require-dot ""' 6096 Skip the test if the host does not have 'dot'. 6097 6098'dg-require-fork ""' 6099 Skip the test if the target does not support 'fork'. 6100 6101'dg-require-gc-sections ""' 6102 Skip the test if the target's linker does not support the 6103 '--gc-sections' flags. This is equivalent to 6104 'dg-require-effective-target gc-sections'. 6105 6106'dg-require-host-local ""' 6107 Skip the test if the host is remote, rather than the same as the 6108 build system. Some tests are incompatible with DejaGnu's handling 6109 of remote hosts, which involves copying the source file to the host 6110 and compiling it with a relative path and "'-o a.out'". 6111 6112'dg-require-mkfifo ""' 6113 Skip the test if the target does not support 'mkfifo'. 6114 6115'dg-require-named-sections ""' 6116 Skip the test is the target does not support named sections. This 6117 is equivalent to 'dg-require-effective-target named_sections'. 6118 6119'dg-require-weak ""' 6120 Skip the test if the target does not support weak symbols. 6121 6122'dg-require-weak-override ""' 6123 Skip the test if the target does not support overriding weak 6124 symbols. 6125 6126 6127File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives 6128 61297.2.6 Commands for use in 'dg-final' 6130------------------------------------ 6131 6132The GCC testsuite defines the following directives to be used within 6133'dg-final'. 6134 61357.2.6.1 Scan a particular file 6136.............................. 6137 6138'scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 6139 Passes if REGEXP matches text in FILENAME. 6140'scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 6141 Passes if REGEXP does not match text in FILENAME. 6142'scan-module MODULE REGEXP [{ target/xfail SELECTOR }]' 6143 Passes if REGEXP matches in Fortran module MODULE. 6144'dg-check-dot FILENAME' 6145 Passes if FILENAME is a valid '.dot' file (by running 'dot -Tpng' 6146 on it, and verifying the exit code is 0). 6147 61487.2.6.2 Scan the assembly output 6149................................ 6150 6151'scan-assembler REGEX [{ target/xfail SELECTOR }]' 6152 Passes if REGEX matches text in the test's assembler output. 6153 6154'scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 6155 Passes if REGEX does not match text in the test's assembler output. 6156 6157'scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 6158 Passes if REGEX is matched exactly NUM times in the test's 6159 assembler output. 6160 6161'scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 6162 Passes if REGEX matches text in the test's demangled assembler 6163 output. 6164 6165'scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 6166 Passes if REGEX does not match text in the test's demangled 6167 assembler output. 6168 6169'scan-assembler-symbol-section FUNCTIONS SECTION [{ target/xfail SELECTOR }]' 6170 Passes if FUNCTIONS are all in SECTION. The caller needs to allow 6171 for 'USER_LABEL_PREFIX' and different section name conventions. 6172 6173'scan-symbol-section FILENAME FUNCTIONS SECTION [{ target/xfail SELECTOR }]' 6174 Passes if FUNCTIONS are all in SECTIONin FILENAME. The same 6175 caveats as for 'scan-assembler-symbol-section' apply. 6176 6177'scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 6178 Passes if SYMBOL is defined as a hidden symbol in the test's 6179 assembly output. 6180 6181'scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 6182 Passes if SYMBOL is not defined as a hidden symbol in the test's 6183 assembly output. 6184 6185'check-function-bodies PREFIX TERMINATOR [OPTIONS [{ target/xfail SELECTOR }]]' 6186 Looks through the source file for comments that give the expected 6187 assembly output for selected functions. Each line of expected 6188 output starts with the prefix string PREFIX and the expected output 6189 for a function as a whole is followed by a line that starts with 6190 the string TERMINATOR. Specifying an empty terminator is 6191 equivalent to specifying '"*/"'. 6192 6193 OPTIONS, if specified, is a list of regular expressions, each of 6194 which matches a full command-line option. A non-empty list 6195 prevents the test from running unless all of the given options are 6196 present on the command line. This can help if a source file is 6197 compiled both with and without optimization, since it is rarely 6198 useful to check the full function body for unoptimized code. 6199 6200 The first line of the expected output for a function FN has the 6201 form: 6202 6203 PREFIX FN: [{ target/xfail SELECTOR }] 6204 6205 Subsequent lines of the expected output also start with PREFIX. In 6206 both cases, whitespace after PREFIX is not significant. 6207 6208 The test discards assembly directives such as '.cfi_startproc' and 6209 local label definitions such as '.LFB0' from the compiler's 6210 assembly output. It then matches the result against the expected 6211 output for a function as a single regular expression. This means 6212 that later lines can use backslashes to refer back to '(...)' 6213 captures on earlier lines. For example: 6214 6215 /* { dg-final { check-function-bodies "**" "" "-DCHECK_ASM" } } */ 6216 ... 6217 /* 6218 ** add_w0_s8_m: 6219 ** mov (z[0-9]+\.b), w0 6220 ** add z0\.b, p0/m, z0\.b, \1 6221 ** ret 6222 */ 6223 svint8_t add_w0_s8_m (...) { ... } 6224 ... 6225 /* 6226 ** add_b0_s8_m: 6227 ** mov (z[0-9]+\.b), b0 6228 ** add z1\.b, p0/m, z1\.b, \1 6229 ** ret 6230 */ 6231 svint8_t add_b0_s8_m (...) { ... } 6232 6233 checks whether the implementations of 'add_w0_s8_m' and 6234 'add_b0_s8_m' match the regular expressions given. The test only 6235 runs when '-DCHECK_ASM' is passed on the command line. 6236 6237 It is possible to create non-capturing multi-line regular 6238 expression groups of the form '(A|B|...)' by putting the '(', '|' 6239 and ')' on separate lines (each still using PREFIX). For example: 6240 6241 /* 6242 ** cmple_f16_tied: 6243 ** ( 6244 ** fcmge p0\.h, p0/z, z1\.h, z0\.h 6245 ** | 6246 ** fcmle p0\.h, p0/z, z0\.h, z1\.h 6247 ** ) 6248 ** ret 6249 */ 6250 svbool_t cmple_f16_tied (...) { ... } 6251 6252 checks whether 'cmple_f16_tied' is implemented by the 'fcmge' 6253 instruction followed by 'ret' or by the 'fcmle' instruction 6254 followed by 'ret'. The test is still a single regular rexpression. 6255 6256 A line containing just: 6257 6258 PREFIX ... 6259 6260 stands for zero or more unmatched lines; the whitespace after 6261 PREFIX is again not significant. 6262 62637.2.6.3 Scan optimization dump files 6264.................................... 6265 6266These commands are available for KIND of 'tree', 'ltrans-tree', 6267'offload-tree', 'rtl', 'offload-rtl', 'ipa', and 'wpa-ipa'. 6268 6269'scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 6270 Passes if REGEX matches text in the dump file with suffix SUFFIX. 6271 6272'scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 6273 Passes if REGEX does not match text in the dump file with suffix 6274 SUFFIX. 6275 6276'scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 6277 Passes if REGEX is found exactly NUM times in the dump file with 6278 suffix SUFFIX. 6279 6280'scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 6281 Passes if REGEX matches demangled text in the dump file with suffix 6282 SUFFIX. 6283 6284'scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 6285 Passes if REGEX does not match demangled text in the dump file with 6286 suffix SUFFIX. 6287 6288 The SUFFIX argument which describes the dump file to be scanned may 6289contain a glob pattern that must expand to exactly one file name. This 6290is useful if, e.g., different pass instances are executed depending on 6291torture testing command-line flags, producing dump files whose names 6292differ only in their pass instance number suffix. For example, to scan 6293instances 1, 2, 3 of a tree pass "mypass" for occurrences of the string 6294"code has been optimized", use: 6295 /* { dg-options "-fdump-tree-mypass" } */ 6296 /* { dg-final { scan-tree-dump "code has been optimized" "mypass\[1-3\]" } } */ 6297 62987.2.6.4 Check for output files 6299.............................. 6300 6301'output-exists [{ target/xfail SELECTOR }]' 6302 Passes if compiler output file exists. 6303 6304'output-exists-not [{ target/xfail SELECTOR }]' 6305 Passes if compiler output file does not exist. 6306 6307'scan-symbol REGEXP [{ target/xfail SELECTOR }]' 6308 Passes if the pattern is present in the final executable. 6309 6310'scan-symbol-not REGEXP [{ target/xfail SELECTOR }]' 6311 Passes if the pattern is absent from the final executable. 6312 63137.2.6.5 Checks for 'gcov' tests 6314............................... 6315 6316'run-gcov SOURCEFILE' 6317 Check line counts in 'gcov' tests. 6318 6319'run-gcov [branches] [calls] { OPTS SOURCEFILE }' 6320 Check branch and/or call counts, in addition to line counts, in 6321 'gcov' tests. 6322 6323'run-gcov-pytest { SOURCEFILE PYTEST_FILE }' 6324 Check output of 'gcov' intermediate format with a pytest script. 6325 63267.2.6.6 Clean up generated test files 6327..................................... 6328 6329Usually the test-framework removes files that were generated during 6330testing. If a testcase, for example, uses any dumping mechanism to 6331inspect a passes dump file, the testsuite recognized the dump option 6332passed to the tool and schedules a final cleanup to remove these files. 6333 6334 There are, however, following additional cleanup directives that can be 6335used to annotate a testcase "manually". 6336'cleanup-coverage-files' 6337 Removes coverage data files generated for this test. 6338 6339'cleanup-modules "LIST-OF-EXTRA-MODULES"' 6340 Removes Fortran module files generated for this test, excluding the 6341 module names listed in keep-modules. Cleaning up module files is 6342 usually done automatically by the testsuite by looking at the 6343 source files and removing the modules after the test has been 6344 executed. 6345 module MoD1 6346 end module MoD1 6347 module Mod2 6348 end module Mod2 6349 module moD3 6350 end module moD3 6351 module mod4 6352 end module mod4 6353 ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant 6354 ! { dg-final { keep-modules "mod3 mod4" } } 6355 6356'keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"' 6357 Whitespace separated list of module names that should not be 6358 deleted by cleanup-modules. If the list of modules is empty, all 6359 modules defined in this file are kept. 6360 module maybe_unneeded 6361 end module maybe_unneeded 6362 module keep1 6363 end module keep1 6364 module keep2 6365 end module keep2 6366 ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two 6367 ! { dg-final { keep-modules "" } } ! keep all 6368 6369'dg-keep-saved-temps "LIST-OF-SUFFIXES-NOT-TO-DELETE"' 6370 Whitespace separated list of suffixes that should not be deleted 6371 automatically in a testcase that uses '-save-temps'. 6372 // { dg-options "-save-temps -fpch-preprocess -I." } 6373 int main() { return 0; } 6374 // { dg-keep-saved-temps ".s" } ! just keep assembler file 6375 // { dg-keep-saved-temps ".s" ".i" } ! ... and .i 6376 // { dg-keep-saved-temps ".ii" ".o" } ! or just .ii and .o 6377 6378'cleanup-profile-file' 6379 Removes profiling files generated for this test. 6380 6381 6382File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 6383 63847.3 Ada Language Testsuites 6385=========================== 6386 6387The Ada testsuite includes executable tests from the ACATS testsuite, 6388publicly available at <http://www.ada-auth.org/acats.html>. 6389 6390 These tests are integrated in the GCC testsuite in the 'ada/acats' 6391directory, and enabled automatically when running 'make check', assuming 6392the Ada language has been enabled when configuring GCC. 6393 6394 You can also run the Ada testsuite independently, using 'make 6395check-ada', or run a subset of the tests by specifying which chapter to 6396run, e.g.: 6397 6398 $ make check-ada CHAPTERS="c3 c9" 6399 6400 The tests are organized by directory, each directory corresponding to a 6401chapter of the Ada Reference Manual. So for example, 'c9' corresponds 6402to chapter 9, which deals with tasking features of the language. 6403 6404 The tests are run using two 'sh' scripts: 'run_acats' and 'run_all.sh'. 6405To run the tests using a simulator or a cross target, see the small 6406customization section at the top of 'run_all.sh'. 6407 6408 These tests are run using the build tree: they can be run without doing 6409a 'make install'. 6410 6411 6412File: gccint.info, Node: C Tests, Next: LTO Testing, Prev: Ada Tests, Up: Testsuites 6413 64147.4 C Language Testsuites 6415========================= 6416 6417GCC contains the following C language testsuites, in the 'gcc/testsuite' 6418directory: 6419 6420'gcc.dg' 6421 This contains tests of particular features of the C compiler, using 6422 the more modern 'dg' harness. Correctness tests for various 6423 compiler features should go here if possible. 6424 6425 Magic comments determine whether the file is preprocessed, 6426 compiled, linked or run. In these tests, error and warning message 6427 texts are compared against expected texts or regular expressions 6428 given in comments. These tests are run with the options '-ansi 6429 -pedantic' unless other options are given in the test. Except as 6430 noted below they are not run with multiple optimization options. 6431'gcc.dg/compat' 6432 This subdirectory contains tests for binary compatibility using 6433 'lib/compat.exp', which in turn uses the language-independent 6434 support (*note Support for testing binary compatibility: compat 6435 Testing.). 6436'gcc.dg/cpp' 6437 This subdirectory contains tests of the preprocessor. 6438'gcc.dg/debug' 6439 This subdirectory contains tests for debug formats. Tests in this 6440 subdirectory are run for each debug format that the compiler 6441 supports. 6442'gcc.dg/format' 6443 This subdirectory contains tests of the '-Wformat' format checking. 6444 Tests in this directory are run with and without '-DWIDE'. 6445'gcc.dg/noncompile' 6446 This subdirectory contains tests of code that should not compile 6447 and does not need any special compilation options. They are run 6448 with multiple optimization options, since sometimes invalid code 6449 crashes the compiler with optimization. 6450'gcc.dg/special' 6451 FIXME: describe this. 6452 6453'gcc.c-torture' 6454 This contains particular code fragments which have historically 6455 broken easily. These tests are run with multiple optimization 6456 options, so tests for features which only break at some 6457 optimization levels belong here. This also contains tests to check 6458 that certain optimizations occur. It might be worthwhile to 6459 separate the correctness tests cleanly from the code quality tests, 6460 but it hasn't been done yet. 6461 6462'gcc.c-torture/compat' 6463 FIXME: describe this. 6464 6465 This directory should probably not be used for new tests. 6466'gcc.c-torture/compile' 6467 This testsuite contains test cases that should compile, but do not 6468 need to link or run. These test cases are compiled with several 6469 different combinations of optimization options. All warnings are 6470 disabled for these test cases, so this directory is not suitable if 6471 you wish to test for the presence or absence of compiler warnings. 6472 While special options can be set, and tests disabled on specific 6473 platforms, by the use of '.x' files, mostly these test cases should 6474 not contain platform dependencies. FIXME: discuss how defines such 6475 as 'STACK_SIZE' are used. 6476'gcc.c-torture/execute' 6477 This testsuite contains test cases that should compile, link and 6478 run; otherwise the same comments as for 'gcc.c-torture/compile' 6479 apply. 6480'gcc.c-torture/execute/ieee' 6481 This contains tests which are specific to IEEE floating point. 6482'gcc.c-torture/unsorted' 6483 FIXME: describe this. 6484 6485 This directory should probably not be used for new tests. 6486'gcc.misc-tests' 6487 This directory contains C tests that require special handling. 6488 Some of these tests have individual expect files, and others share 6489 special-purpose expect files: 6490 6491 'bprob*.c' 6492 Test '-fbranch-probabilities' using 6493 'gcc.misc-tests/bprob.exp', which in turn uses the generic, 6494 language-independent framework (*note Support for testing 6495 profile-directed optimizations: profopt Testing.). 6496 6497 'gcov*.c' 6498 Test 'gcov' output using 'gcov.exp', which in turn uses the 6499 language-independent support (*note Support for testing gcov: 6500 gcov Testing.). 6501 6502 'i386-pf-*.c' 6503 Test i386-specific support for data prefetch using 6504 'i386-prefetch.exp'. 6505 6506'gcc.test-framework' 6507 'dg-*.c' 6508 Test the testsuite itself using 6509 'gcc.test-framework/test-framework.exp'. 6510 6511 FIXME: merge in 'testsuite/README.gcc' and discuss the format of test 6512cases and magic comments more. 6513 6514 6515File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: C Tests, Up: Testsuites 6516 65177.5 Support for testing link-time optimizations 6518=============================================== 6519 6520Tests for link-time optimizations usually require multiple source files 6521that are compiled separately, perhaps with different sets of options. 6522There are several special-purpose test directives used for these tests. 6523 6524'{ dg-lto-do DO-WHAT-KEYWORD }' 6525 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 6526 is executed. It is one of: 6527 6528 'assemble' 6529 Compile with '-c' to produce a relocatable object file. 6530 'link' 6531 Compile, assemble, and link to produce an executable file. 6532 'run' 6533 Produce and run an executable file, which is expected to 6534 return an exit code of 0. 6535 6536 The default is 'assemble'. That can be overridden for a set of 6537 tests by redefining 'dg-do-what-default' within the '.exp' file for 6538 those tests. 6539 6540 Unlike 'dg-do', 'dg-lto-do' does not support an optional 'target' 6541 or 'xfail' list. Use 'dg-skip-if', 'dg-xfail-if', or 6542 'dg-xfail-run-if'. 6543 6544'{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}' 6545 This directive provides a list of one or more sets of compiler 6546 options to override LTO_OPTIONS. Each test will be compiled and 6547 run with each of these sets of options. 6548 6549'{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}' 6550 This directive adds OPTIONS to the linker options used. 6551 6552'{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}' 6553 This directive removes OPTIONS from the set of linker options used. 6554 6555 6556File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites 6557 65587.6 Support for testing 'gcov' 6559============================== 6560 6561Language-independent support for testing 'gcov', and for checking that 6562branch profiling produces expected values, is provided by the expect 6563file 'lib/gcov.exp'. 'gcov' tests also rely on procedures in 6564'lib/gcc-dg.exp' to compile and run the test program. A typical 'gcov' 6565test contains the following DejaGnu commands within comments: 6566 6567 { dg-options "--coverage" } 6568 { dg-do run { target native } } 6569 { dg-final { run-gcov sourcefile } } 6570 6571 Checks of 'gcov' output can include line counts, branch percentages, 6572and call return percentages. All of these checks are requested via 6573commands that appear in comments in the test's source file. Commands to 6574check line counts are processed by default. Commands to check branch 6575percentages and call return percentages are processed if the 'run-gcov' 6576command has arguments 'branches' or 'calls', respectively. For example, 6577the following specifies checking both, as well as passing '-b' to 6578'gcov': 6579 6580 { dg-final { run-gcov branches calls { -b sourcefile } } } 6581 6582 A line count command appears within a comment on the source line that 6583is expected to get the specified count and has the form 'count(CNT)'. A 6584test should only check line counts for lines that will get the same 6585count for any architecture. 6586 6587 Commands to check branch percentages ('branch') and call return 6588percentages ('returns') are very similar to each other. A beginning 6589command appears on or before the first of a range of lines that will 6590report the percentage, and the ending command follows that range of 6591lines. The beginning command can include a list of percentages, all of 6592which are expected to be found within the range. A range is terminated 6593by the next command of the same kind. A command 'branch(end)' or 6594'returns(end)' marks the end of a range without starting a new one. For 6595example: 6596 6597 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 6598 /* branch(end) */ 6599 foo (i, j); 6600 6601 For a call return percentage, the value specified is the percentage of 6602calls reported to return. For a branch percentage, the value is either 6603the expected percentage or 100 minus that value, since the direction of 6604a branch can differ depending on the target or the optimization level. 6605 6606 Not all branches and calls need to be checked. A test should not check 6607for branches that might be optimized away or replaced with predicated 6608instructions. Don't check for calls inserted by the compiler or ones 6609that might be inlined or optimized away. 6610 6611 A single test can check for combinations of line counts, branch 6612percentages, and call return percentages. The command to check a line 6613count must appear on the line that will report that count, but commands 6614to check branch percentages and call return percentages can bracket the 6615lines that report them. 6616 6617 6618File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 6619 66207.7 Support for testing profile-directed optimizations 6621====================================================== 6622 6623The file 'profopt.exp' provides language-independent support for 6624checking correct execution of a test built with profile-directed 6625optimization. This testing requires that a test program be built and 6626executed twice. The first time it is compiled to generate profile data, 6627and the second time it is compiled to use the data that was generated 6628during the first execution. The second execution is to verify that the 6629test produces the expected results. 6630 6631 To check that the optimization actually generated better code, a test 6632can be built and run a third time with normal optimizations to verify 6633that the performance is better with the profile-directed optimizations. 6634'profopt.exp' has the beginnings of this kind of support. 6635 6636 'profopt.exp' provides generic support for profile-directed 6637optimizations. Each set of tests that uses it provides information 6638about a specific optimization: 6639 6640'tool' 6641 tool being tested, e.g., 'gcc' 6642 6643'profile_option' 6644 options used to generate profile data 6645 6646'feedback_option' 6647 options used to optimize using that profile data 6648 6649'prof_ext' 6650 suffix of profile data files 6651 6652'PROFOPT_OPTIONS' 6653 list of options with which to run each test, similar to the lists 6654 for torture tests 6655 6656'{ dg-final-generate { LOCAL-DIRECTIVE } }' 6657 This directive is similar to 'dg-final', but the LOCAL-DIRECTIVE is 6658 run after the generation of profile data. 6659 6660'{ dg-final-use { LOCAL-DIRECTIVE } }' 6661 The LOCAL-DIRECTIVE is run after the profile data have been used. 6662 6663 6664File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites 6665 66667.8 Support for testing binary compatibility 6667============================================ 6668 6669The file 'compat.exp' provides language-independent support for binary 6670compatibility testing. It supports testing interoperability of two 6671compilers that follow the same ABI, or of multiple sets of compiler 6672options that should not affect binary compatibility. It is intended to 6673be used for testsuites that complement ABI testsuites. 6674 6675 A test supported by this framework has three parts, each in a separate 6676source file: a main program and two pieces that interact with each other 6677to split up the functionality being tested. 6678 6679'TESTNAME_main.SUFFIX' 6680 Contains the main program, which calls a function in file 6681 'TESTNAME_x.SUFFIX'. 6682 6683'TESTNAME_x.SUFFIX' 6684 Contains at least one call to a function in 'TESTNAME_y.SUFFIX'. 6685 6686'TESTNAME_y.SUFFIX' 6687 Shares data with, or gets arguments from, 'TESTNAME_x.SUFFIX'. 6688 6689 Within each test, the main program and one functional piece are 6690compiled by the GCC under test. The other piece can be compiled by an 6691alternate compiler. If no alternate compiler is specified, then all 6692three source files are all compiled by the GCC under test. You can 6693specify pairs of sets of compiler options. The first element of such a 6694pair specifies options used with the GCC under test, and the second 6695element of the pair specifies options used with the alternate compiler. 6696Each test is compiled with each pair of options. 6697 6698 'compat.exp' defines default pairs of compiler options. These can be 6699overridden by defining the environment variable 'COMPAT_OPTIONS' as: 6700 6701 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 6702 ...[list {TSTN} {ALTN}]]" 6703 6704 where TSTI and ALTI are lists of options, with TSTI used by the 6705compiler under test and ALTI used by the alternate compiler. For 6706example, with '[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 6707the test is first built with '-g -O0' by the compiler under test and 6708with '-O3' by the alternate compiler. The test is built a second time 6709using '-fpic' by the compiler under test and '-fPIC -O2' by the 6710alternate compiler. 6711 6712 An alternate compiler is specified by defining an environment variable 6713to be the full pathname of an installed compiler; for C define 6714'ALT_CC_UNDER_TEST', and for C++ define 'ALT_CXX_UNDER_TEST'. These 6715will be written to the 'site.exp' file used by DejaGnu. The default is 6716to build each test with the compiler under test using the first of each 6717pair of compiler options from 'COMPAT_OPTIONS'. When 6718'ALT_CC_UNDER_TEST' or 'ALT_CXX_UNDER_TEST' is 'same', each test is 6719built using the compiler under test but with combinations of the options 6720from 'COMPAT_OPTIONS'. 6721 6722 To run only the C++ compatibility suite using the compiler under test 6723and another version of GCC using specific compiler options, do the 6724following from 'OBJDIR/gcc': 6725 6726 rm site.exp 6727 make -k \ 6728 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 6729 COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \ 6730 check-c++ \ 6731 RUNTESTFLAGS="compat.exp" 6732 6733 A test that fails when the source files are compiled with different 6734compilers, but passes when the files are compiled with the same 6735compiler, demonstrates incompatibility of the generated code or runtime 6736support. A test that fails for the alternate compiler but passes for 6737the compiler under test probably tests for a bug that was fixed in the 6738compiler under test but is present in the alternate compiler. 6739 6740 The binary compatibility tests support a small number of test framework 6741commands that appear within comments in a test file. 6742 6743'dg-require-*' 6744 These commands can be used in 'TESTNAME_main.SUFFIX' to skip the 6745 test if specific support is not available on the target. 6746 6747'dg-options' 6748 The specified options are used for compiling this particular source 6749 file, appended to the options from 'COMPAT_OPTIONS'. When this 6750 command appears in 'TESTNAME_main.SUFFIX' the options are also used 6751 to link the test program. 6752 6753'dg-xfail-if' 6754 This command can be used in a secondary source file to specify that 6755 compilation is expected to fail for particular options on 6756 particular targets. 6757 6758 6759File: gccint.info, Node: Torture Tests, Next: GIMPLE Tests, Prev: compat Testing, Up: Testsuites 6760 67617.9 Support for torture testing using multiple options 6762====================================================== 6763 6764Throughout the compiler testsuite there are several directories whose 6765tests are run multiple times, each with a different set of options. 6766These are known as torture tests. 'lib/torture-options.exp' defines 6767procedures to set up these lists: 6768 6769'torture-init' 6770 Initialize use of torture lists. 6771'set-torture-options' 6772 Set lists of torture options to use for tests with and without 6773 loops. Optionally combine a set of torture options with a set of 6774 other options, as is done with Objective-C runtime options. 6775'torture-finish' 6776 Finalize use of torture lists. 6777 6778 The '.exp' file for a set of tests that use torture options must 6779include calls to these three procedures if: 6780 6781 * It calls 'gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS. 6782 6783 * It calls ${TOOL}'-torture' or ${TOOL}'-torture-execute', where TOOL 6784 is 'c', 'fortran', or 'objc'. 6785 6786 * It calls 'dg-pch'. 6787 6788 It is not necessary for a '.exp' file that calls 'gcc-dg-runtest' to 6789call the torture procedures if the tests should use the list in 6790DG_TORTURE_OPTIONS defined in 'gcc-dg.exp'. 6791 6792 Most uses of torture options can override the default lists by defining 6793TORTURE_OPTIONS or add to the default list by defining 6794ADDITIONAL_TORTURE_OPTIONS. Define these in a '.dejagnurc' file or add 6795them to the 'site.exp' file; for example 6796 6797 set ADDITIONAL_TORTURE_OPTIONS [list \ 6798 { -O2 -ftree-loop-linear } \ 6799 { -O2 -fpeel-loops } ] 6800 6801 6802File: gccint.info, Node: GIMPLE Tests, Next: RTL Tests, Prev: Torture Tests, Up: Testsuites 6803 68047.10 Support for testing GIMPLE passes 6805====================================== 6806 6807As of gcc 7, C functions can be tagged with '__GIMPLE' to indicate that 6808the function body will be GIMPLE, rather than C. The compiler requires 6809the option '-fgimple' to enable this functionality. For example: 6810 6811 /* { dg-do compile } */ 6812 /* { dg-options "-O -fgimple" } */ 6813 6814 void __GIMPLE (startwith ("dse2")) foo () 6815 { 6816 int a; 6817 6818 bb_2: 6819 if (a > 4) 6820 goto bb_3; 6821 else 6822 goto bb_4; 6823 6824 bb_3: 6825 a_2 = 10; 6826 goto bb_5; 6827 6828 bb_4: 6829 a_3 = 20; 6830 6831 bb_5: 6832 a_1 = __PHI (bb_3: a_2, bb_4: a_3); 6833 a_4 = a_1 + 4; 6834 6835 return; 6836 } 6837 6838 The 'startwith' argument indicates at which pass to begin. 6839 6840 Use the dump modifier '-gimple' (e.g. '-fdump-tree-all-gimple') to make 6841tree dumps more closely follow the format accepted by the GIMPLE parser. 6842 6843 Example DejaGnu tests of GIMPLE can be seen in the source tree at 6844'gcc/testsuite/gcc.dg/gimplefe-*.c'. 6845 6846 The '__GIMPLE' parser is integrated with the C tokenizer and 6847preprocessor, so it should be possible to use macros to build out test 6848coverage. 6849 6850 6851File: gccint.info, Node: RTL Tests, Prev: GIMPLE Tests, Up: Testsuites 6852 68537.11 Support for testing RTL passes 6854=================================== 6855 6856As of gcc 7, C functions can be tagged with '__RTL' to indicate that the 6857function body will be RTL, rather than C. For example: 6858 6859 double __RTL (startwith ("ira")) test (struct foo *f, const struct bar *b) 6860 { 6861 (function "test" 6862 [...snip; various directives go in here...] 6863 ) ;; function "test" 6864 } 6865 6866 The 'startwith' argument indicates at which pass to begin. 6867 6868 The parser expects the RTL body to be in the format emitted by this 6869dumping function: 6870 6871 DEBUG_FUNCTION void 6872 print_rtx_function (FILE *outfile, function *fn, bool compact); 6873 6874 when "compact" is true. So you can capture RTL in the correct format 6875from the debugger using: 6876 6877 (gdb) print_rtx_function (stderr, cfun, true); 6878 6879 and copy and paste the output into the body of the C function. 6880 6881 Example DejaGnu tests of RTL can be seen in the source tree under 6882'gcc/testsuite/gcc.dg/rtl'. 6883 6884 The '__RTL' parser is not integrated with the C tokenizer or 6885preprocessor, and works simply by reading the relevant lines within the 6886braces. In particular, the RTL body must be on separate lines from the 6887enclosing braces, and the preprocessor is not usable within it. 6888 6889 6890File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top 6891 68928 Option specification files 6893**************************** 6894 6895Most GCC command-line options are described by special option definition 6896files, the names of which conventionally end in '.opt'. This chapter 6897describes the format of these files. 6898 6899* Menu: 6900 6901* Option file format:: The general layout of the files 6902* Option properties:: Supported option properties 6903 6904 6905File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 6906 69078.1 Option file format 6908====================== 6909 6910Option files are a simple list of records in which each field occupies 6911its own line and in which the records themselves are separated by blank 6912lines. Comments may appear on their own line anywhere within the file 6913and are preceded by semicolons. Whitespace is allowed before the 6914semicolon. 6915 6916 The files can contain the following types of record: 6917 6918 * A language definition record. These records have two fields: the 6919 string 'Language' and the name of the language. Once a language 6920 has been declared in this way, it can be used as an option 6921 property. *Note Option properties::. 6922 6923 * A target specific save record to save additional information. 6924 These records have two fields: the string 'TargetSave', and a 6925 declaration type to go in the 'cl_target_option' structure. 6926 6927 * A variable record to define a variable used to store option 6928 information. These records have two fields: the string 'Variable', 6929 and a declaration of the type and name of the variable, optionally 6930 with an initializer (but without any trailing ';'). These records 6931 may be used for variables used for many options where declaring the 6932 initializer in a single option definition record, or duplicating it 6933 in many records, would be inappropriate, or for variables set in 6934 option handlers rather than referenced by 'Var' properties. 6935 6936 * A variable record to define a variable used to store option 6937 information. These records have two fields: the string 6938 'TargetVariable', and a declaration of the type and name of the 6939 variable, optionally with an initializer (but without any trailing 6940 ';'). 'TargetVariable' is a combination of 'Variable' and 6941 'TargetSave' records in that the variable is defined in the 6942 'gcc_options' structure, but these variables are also stored in the 6943 'cl_target_option' structure. The variables are saved in the 6944 target save code and restored in the target restore code. 6945 6946 * A variable record to record any additional files that the 6947 'options.h' file should include. This is useful to provide 6948 enumeration or structure definitions needed for target variables. 6949 These records have two fields: the string 'HeaderInclude' and the 6950 name of the include file. 6951 6952 * A variable record to record any additional files that the 6953 'options.c' or 'options-save.c' file should include. This is 6954 useful to provide inline functions needed for target variables 6955 and/or '#ifdef' sequences to properly set up the initialization. 6956 These records have two fields: the string 'SourceInclude' and the 6957 name of the include file. 6958 6959 * An enumeration record to define a set of strings that may be used 6960 as arguments to an option or options. These records have three 6961 fields: the string 'Enum', a space-separated list of properties and 6962 help text used to describe the set of strings in '--help' output. 6963 Properties use the same format as option properties; the following 6964 are valid: 6965 'Name(NAME)' 6966 This property is required; NAME must be a name (suitable for 6967 use in C identifiers) used to identify the set of strings in 6968 'Enum' option properties. 6969 6970 'Type(TYPE)' 6971 This property is required; TYPE is the C type for variables 6972 set by options using this enumeration together with 'Var'. 6973 6974 'UnknownError(MESSAGE)' 6975 The message MESSAGE will be used as an error message if the 6976 argument is invalid; for enumerations without 'UnknownError', 6977 a generic error message is used. MESSAGE should contain a 6978 single '%qs' format, which will be used to format the invalid 6979 argument. 6980 6981 * An enumeration value record to define one of the strings in a set 6982 given in an 'Enum' record. These records have two fields: the 6983 string 'EnumValue' and a space-separated list of properties. 6984 Properties use the same format as option properties; the following 6985 are valid: 6986 'Enum(NAME)' 6987 This property is required; NAME says which 'Enum' record this 6988 'EnumValue' record corresponds to. 6989 6990 'String(STRING)' 6991 This property is required; STRING is the string option 6992 argument being described by this record. 6993 6994 'Value(VALUE)' 6995 This property is required; it says what value (representable 6996 as 'int') should be used for the given string. 6997 6998 'Canonical' 6999 This property is optional. If present, it says the present 7000 string is the canonical one among all those with the given 7001 value. Other strings yielding that value will be mapped to 7002 this one so specs do not need to handle them. 7003 7004 'DriverOnly' 7005 This property is optional. If present, the present string 7006 will only be accepted by the driver. This is used for cases 7007 such as '-march=native' that are processed by the driver so 7008 that 'gcc -v' shows how the options chosen depended on the 7009 system on which the compiler was run. 7010 7011 * An option definition record. These records have the following 7012 fields: 7013 1. the name of the option, with the leading "-" removed 7014 2. a space-separated list of option properties (*note Option 7015 properties::) 7016 3. the help text to use for '--help' (omitted if the second field 7017 contains the 'Undocumented' property). 7018 7019 By default, all options beginning with "f", "W" or "m" are 7020 implicitly assumed to take a "no-" form. This form should not be 7021 listed separately. If an option beginning with one of these 7022 letters does not have a "no-" form, you can use the 7023 'RejectNegative' property to reject it. 7024 7025 The help text is automatically line-wrapped before being displayed. 7026 Normally the name of the option is printed on the left-hand side of 7027 the output and the help text is printed on the right. However, if 7028 the help text contains a tab character, the text to the left of the 7029 tab is used instead of the option's name and the text to the right 7030 of the tab forms the help text. This allows you to elaborate on 7031 what type of argument the option takes. 7032 7033 * A target mask record. These records have one field of the form 7034 'Mask(X)'. The options-processing script will automatically 7035 allocate a bit in 'target_flags' (*note Run-time Target::) for each 7036 mask name X and set the macro 'MASK_X' to the appropriate bitmask. 7037 It will also declare a 'TARGET_X' macro that has the value 1 when 7038 bit 'MASK_X' is set and 0 otherwise. 7039 7040 They are primarily intended to declare target masks that are not 7041 associated with user options, either because these masks represent 7042 internal switches or because the options are not available on all 7043 configurations and yet the masks always need to be defined. 7044 7045 7046File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 7047 70488.2 Option properties 7049===================== 7050 7051The second field of an option record can specify any of the following 7052properties. When an option takes an argument, it is enclosed in 7053parentheses following the option property name. The parser that handles 7054option files is quite simplistic, and will be tricked by any nested 7055parentheses within the argument text itself; in this case, the entire 7056option argument can be wrapped in curly braces within the parentheses to 7057demarcate it, e.g.: 7058 7059 Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)}) 7060 7061'Common' 7062 The option is available for all languages and targets. 7063 7064'Target' 7065 The option is available for all languages but is target-specific. 7066 7067'Driver' 7068 The option is handled by the compiler driver using code not shared 7069 with the compilers proper ('cc1' etc.). 7070 7071'LANGUAGE' 7072 The option is available when compiling for the given language. 7073 7074 It is possible to specify several different languages for the same 7075 option. Each LANGUAGE must have been declared by an earlier 7076 'Language' record. *Note Option file format::. 7077 7078'RejectDriver' 7079 The option is only handled by the compilers proper ('cc1' etc.) and 7080 should not be accepted by the driver. 7081 7082'RejectNegative' 7083 The option does not have a "no-" form. All options beginning with 7084 "f", "W" or "m" are assumed to have a "no-" form unless this 7085 property is used. 7086 7087'Negative(OTHERNAME)' 7088 The option will turn off another option OTHERNAME, which is the 7089 option name with the leading "-" removed. This chain action will 7090 propagate through the 'Negative' property of the option to be 7091 turned off. The driver will prune options, removing those that are 7092 turned off by some later option. This pruning is not done for 7093 options with 'Joined' or 'JoinedOrMissing' properties, unless the 7094 options have either 'RejectNegative' property or the 'Negative' 7095 property mentions an option other than itself. 7096 7097 As a consequence, if you have a group of mutually-exclusive 7098 options, their 'Negative' properties should form a circular chain. 7099 For example, if options '-A', '-B' and '-C' are mutually exclusive, 7100 their respective 'Negative' properties should be 'Negative(B)', 7101 'Negative(C)' and 'Negative(A)'. 7102 7103'Joined' 7104'Separate' 7105 The option takes a mandatory argument. 'Joined' indicates that the 7106 option and argument can be included in the same 'argv' entry (as 7107 with '-mflush-func=NAME', for example). 'Separate' indicates that 7108 the option and argument can be separate 'argv' entries (as with 7109 '-o'). An option is allowed to have both of these properties. 7110 7111'JoinedOrMissing' 7112 The option takes an optional argument. If the argument is given, 7113 it will be part of the same 'argv' entry as the option itself. 7114 7115 This property cannot be used alongside 'Joined' or 'Separate'. 7116 7117'MissingArgError(MESSAGE)' 7118 For an option marked 'Joined' or 'Separate', the message MESSAGE 7119 will be used as an error message if the mandatory argument is 7120 missing; for options without 'MissingArgError', a generic error 7121 message is used. MESSAGE should contain a single '%qs' format, 7122 which will be used to format the name of the option passed. 7123 7124'Args(N)' 7125 For an option marked 'Separate', indicate that it takes N 7126 arguments. The default is 1. 7127 7128'UInteger' 7129 The option's argument is a non-negative integer consisting of 7130 either decimal or hexadecimal digits interpreted as 'int'. 7131 Hexadecimal integers may optionally start with the '0x' or '0X' 7132 prefix. The option parser validates and converts the argument 7133 before passing it to the relevant option handler. 'UInteger' 7134 should also be used with options like '-falign-loops' where both 7135 '-falign-loops' and '-falign-loops'=N are supported to make sure 7136 the saved options are given a full integer. Positive values of the 7137 argument in excess of 'INT_MAX' wrap around zero. 7138 7139'Host_Wide_Int' 7140 The option's argument is a non-negative integer consisting of 7141 either decimal or hexadecimal digits interpreted as the widest 7142 integer type on the host. As with an 'UInteger' argument, 7143 hexadecimal integers may optionally start with the '0x' or '0X' 7144 prefix. The option parser validates and converts the argument 7145 before passing it to the relevant option handler. 'Host_Wide_Int' 7146 should be used with options that need to accept very large values. 7147 Positive values of the argument in excess of 'HOST_WIDE_INT_M1U' 7148 are assigned 'HOST_WIDE_INT_M1U'. 7149 7150'IntegerRange(N, M)' 7151 The options's arguments are integers of type 'int'. The option's 7152 parser validates that the value of an option integer argument is 7153 within the closed range [N, M]. 7154 7155'ByteSize' 7156 A property applicable only to 'UInteger' or 'Host_Wide_Int' 7157 arguments. The option's integer argument is interpreted as if in 7158 infinite precision using saturation arithmetic in the corresponding 7159 type. The argument may be followed by a 'byte-size' suffix 7160 designating a multiple of bytes such as 'kB' and 'KiB' for kilobyte 7161 and kibibyte, respectively, 'MB' and 'MiB' for megabyte and 7162 mebibyte, 'GB' and 'GiB' for gigabyte and gigibyte, and so on. 7163 'ByteSize' should be used for with options that take a very large 7164 argument representing a size in bytes, such as '-Wlarger-than='. 7165 7166'ToLower' 7167 The option's argument should be converted to lowercase as part of 7168 putting it in canonical form, and before comparing with the strings 7169 indicated by any 'Enum' property. 7170 7171'NoDriverArg' 7172 For an option marked 'Separate', the option only takes an argument 7173 in the compiler proper, not in the driver. This is for 7174 compatibility with existing options that are used both directly and 7175 via '-Wp,'; new options should not have this property. 7176 7177'Var(VAR)' 7178 The state of this option should be stored in variable VAR (actually 7179 a macro for 'global_options.x_VAR'). The way that the state is 7180 stored depends on the type of option: 7181 7182'WarnRemoved' 7183 The option is removed and every usage of such option will result in 7184 a warning. We use it option backward compatibility. 7185 7186'Var(VAR, SET)' 7187 The option controls an integer variable VAR and is active when VAR 7188 equals SET. The option parser will set VAR to SET when the 7189 positive form of the option is used and '!SET' when the "no-" form 7190 is used. 7191 7192 VAR is declared in the same way as for the single-argument form 7193 described above. 7194 7195 * If the option uses the 'Mask' or 'InverseMask' properties, VAR 7196 is the integer variable that contains the mask. 7197 7198 * If the option is a normal on/off switch, VAR is an integer 7199 variable that is nonzero when the option is enabled. The 7200 options parser will set the variable to 1 when the positive 7201 form of the option is used and 0 when the "no-" form is used. 7202 7203 * If the option takes an argument and has the 'UInteger' 7204 property, VAR is an integer variable that stores the value of 7205 the argument. 7206 7207 * If the option takes an argument and has the 'Enum' property, 7208 VAR is a variable (type given in the 'Type' property of the 7209 'Enum' record whose 'Name' property has the same argument as 7210 the 'Enum' property of this option) that stores the value of 7211 the argument. 7212 7213 * If the option has the 'Defer' property, VAR is a pointer to a 7214 'VEC(cl_deferred_option,heap)' that stores the option for 7215 later processing. (VAR is declared with type 'void *' and 7216 needs to be cast to 'VEC(cl_deferred_option,heap)' before 7217 use.) 7218 7219 * Otherwise, if the option takes an argument, VAR is a pointer 7220 to the argument string. The pointer will be null if the 7221 argument is optional and wasn't given. 7222 7223 The option-processing script will usually zero-initialize VAR. You 7224 can modify this behavior using 'Init'. 7225 7226'Init(VALUE)' 7227 The variable specified by the 'Var' property should be statically 7228 initialized to VALUE. If more than one option using the same 7229 variable specifies 'Init', all must specify the same initializer. 7230 7231'Mask(NAME)' 7232 The option is associated with a bit in the 'target_flags' variable 7233 (*note Run-time Target::) and is active when that bit is set. You 7234 may also specify 'Var' to select a variable other than 7235 'target_flags'. 7236 7237 The options-processing script will automatically allocate a unique 7238 bit for the option. If the option is attached to 'target_flags', 7239 the script will set the macro 'MASK_NAME' to the appropriate 7240 bitmask. It will also declare a 'TARGET_NAME' macro that has the 7241 value 1 when the option is active and 0 otherwise. If you use 7242 'Var' to attach the option to a different variable, the bitmask 7243 macro with be called 'OPTION_MASK_NAME'. 7244 7245'InverseMask(OTHERNAME)' 7246'InverseMask(OTHERNAME, THISNAME)' 7247 The option is the inverse of another option that has the 7248 'Mask(OTHERNAME)' property. If THISNAME is given, the 7249 options-processing script will declare a 'TARGET_THISNAME' macro 7250 that is 1 when the option is active and 0 otherwise. 7251 7252'Enum(NAME)' 7253 The option's argument is a string from the set of strings 7254 associated with the corresponding 'Enum' record. The string is 7255 checked and converted to the integer specified in the corresponding 7256 'EnumValue' record before being passed to option handlers. 7257 7258'Defer' 7259 The option should be stored in a vector, specified with 'Var', for 7260 later processing. 7261 7262'Alias(OPT)' 7263'Alias(OPT, ARG)' 7264'Alias(OPT, POSARG, NEGARG)' 7265 The option is an alias for '-OPT' (or the negative form of that 7266 option, depending on 'NegativeAlias'). In the first form, any 7267 argument passed to the alias is considered to be passed to '-OPT', 7268 and '-OPT' is considered to be negated if the alias is used in 7269 negated form. In the second form, the alias may not be negated or 7270 have an argument, and POSARG is considered to be passed as an 7271 argument to '-OPT'. In the third form, the alias may not have an 7272 argument, if the alias is used in the positive form then POSARG is 7273 considered to be passed to '-OPT', and if the alias is used in the 7274 negative form then NEGARG is considered to be passed to '-OPT'. 7275 7276 Aliases should not specify 'Var' or 'Mask' or 'UInteger'. Aliases 7277 should normally specify the same languages as the target of the 7278 alias; the flags on the target will be used to determine any 7279 diagnostic for use of an option for the wrong language, while those 7280 on the alias will be used to identify what command-line text is the 7281 option and what text is any argument to that option. 7282 7283 When an 'Alias' definition is used for an option, driver specs do 7284 not need to handle it and no 'OPT_' enumeration value is defined 7285 for it; only the canonical form of the option will be seen in those 7286 places. 7287 7288'NegativeAlias' 7289 For an option marked with 'Alias(OPT)', the option is considered to 7290 be an alias for the positive form of '-OPT' if negated and for the 7291 negative form of '-OPT' if not negated. 'NegativeAlias' may not be 7292 used with the forms of 'Alias' taking more than one argument. 7293 7294'Ignore' 7295 This option is ignored apart from printing any warning specified 7296 using 'Warn'. The option will not be seen by specs and no 'OPT_' 7297 enumeration value is defined for it. 7298 7299'SeparateAlias' 7300 For an option marked with 'Joined', 'Separate' and 'Alias', the 7301 option only acts as an alias when passed a separate argument; with 7302 a joined argument it acts as a normal option, with an 'OPT_' 7303 enumeration value. This is for compatibility with the Java '-d' 7304 option and should not be used for new options. 7305 7306'Warn(MESSAGE)' 7307 If this option is used, output the warning MESSAGE. MESSAGE is a 7308 format string, either taking a single operand with a '%qs' format 7309 which is the option name, or not taking any operands, which is 7310 passed to the 'warning' function. If an alias is marked 'Warn', 7311 the target of the alias must not also be marked 'Warn'. 7312 7313'Warning' 7314 This is a warning option and should be shown as such in '--help' 7315 output. This flag does not currently affect anything other than 7316 '--help'. 7317 7318'Optimization' 7319 This is an optimization option. It should be shown as such in 7320 '--help' output, and any associated variable named using 'Var' 7321 should be saved and restored when the optimization level is changed 7322 with 'optimize' attributes. 7323 7324'PerFunction' 7325 This is an option that can be overridden on a per-function basis. 7326 'Optimization' implies 'PerFunction', but options that do not 7327 affect executable code generation may use this flag instead, so 7328 that the option is not taken into account in ways that might affect 7329 executable code generation. 7330 7331'Param' 7332 This is an option that is a parameter. 7333 7334'Undocumented' 7335 The option is deliberately missing documentation and should not be 7336 included in the '--help' output. 7337 7338'Condition(COND)' 7339 The option should only be accepted if preprocessor condition COND 7340 is true. Note that any C declarations associated with the option 7341 will be present even if COND is false; COND simply controls whether 7342 the option is accepted and whether it is printed in the '--help' 7343 output. 7344 7345'Save' 7346 Build the 'cl_target_option' structure to hold a copy of the 7347 option, add the functions 'cl_target_option_save' and 7348 'cl_target_option_restore' to save and restore the options. 7349 7350'SetByCombined' 7351 The option may also be set by a combined option such as 7352 '-ffast-math'. This causes the 'gcc_options' struct to have a 7353 field 'frontend_set_NAME', where 'NAME' is the name of the field 7354 holding the value of this option (without the leading 'x_'). This 7355 gives the front end a way to indicate that the value has been set 7356 explicitly and should not be changed by the combined option. For 7357 example, some front ends use this to prevent '-ffast-math' and 7358 '-fno-fast-math' from changing the value of '-fmath-errno' for 7359 languages that do not use 'errno'. 7360 7361'EnabledBy(OPT)' 7362'EnabledBy(OPT || OPT2)' 7363'EnabledBy(OPT && OPT2)' 7364 If not explicitly set, the option is set to the value of '-OPT'; 7365 multiple options can be given, separated by '||'. The third form 7366 using '&&' specifies that the option is only set if both OPT and 7367 OPT2 are set. The options OPT and OPT2 must have the 'Common' 7368 property; otherwise, use 'LangEnabledBy'. 7369 7370'LangEnabledBy(LANGUAGE, OPT)' 7371'LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)' 7372 When compiling for the given language, the option is set to the 7373 value of '-OPT', if not explicitly set. OPT can be also a list of 7374 '||' separated options. In the second form, if OPT is used in the 7375 positive form then POSARG is considered to be passed to the option, 7376 and if OPT is used in the negative form then NEGARG is considered 7377 to be passed to the option. It is possible to specify several 7378 different languages. Each LANGUAGE must have been declared by an 7379 earlier 'Language' record. *Note Option file format::. 7380 7381'NoDWARFRecord' 7382 The option is omitted from the producer string written by 7383 '-grecord-gcc-switches'. 7384 7385'PchIgnore' 7386 Even if this is a target option, this option will not be recorded / 7387 compared to determine if a precompiled header file matches. 7388 7389'CPP(VAR)' 7390 The state of this option should be kept in sync with the 7391 preprocessor option VAR. If this property is set, then properties 7392 'Var' and 'Init' must be set as well. 7393 7394'CppReason(CPP_W_ENUM)' 7395 This warning option corresponds to 'cpplib.h' warning reason code 7396 CPP_W_ENUM. This should only be used for warning options of the 7397 C-family front-ends. 7398 7399 7400File: gccint.info, Node: Passes, Next: poly_int, Prev: Options, Up: Top 7401 74029 Passes and Files of the Compiler 7403********************************** 7404 7405This chapter is dedicated to giving an overview of the optimization and 7406code generation passes of the compiler. In the process, it describes 7407some of the language front end interface, though this description is no 7408where near complete. 7409 7410* Menu: 7411 7412* Parsing pass:: The language front end turns text into bits. 7413* Gimplification pass:: The bits are turned into something we can optimize. 7414* Pass manager:: Sequencing the optimization passes. 7415* IPA passes:: Inter-procedural optimizations. 7416* Tree SSA passes:: Optimizations on a high-level representation. 7417* RTL passes:: Optimizations on a low-level representation. 7418* Optimization info:: Dumping optimization information from passes. 7419 7420 7421File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes 7422 74239.1 Parsing pass 7424================ 7425 7426The language front end is invoked only once, via 7427'lang_hooks.parse_file', to parse the entire input. The language front 7428end may use any intermediate language representation deemed appropriate. 7429The C front end uses GENERIC trees (*note GENERIC::), plus a double 7430handful of language specific tree codes defined in 'c-common.def'. The 7431Fortran front end uses a completely different private representation. 7432 7433 At some point the front end must translate the representation used in 7434the front end to a representation understood by the language-independent 7435portions of the compiler. Current practice takes one of two forms. The 7436C front end manually invokes the gimplifier (*note GIMPLE::) on each 7437function, and uses the gimplifier callbacks to convert the 7438language-specific tree nodes directly to GIMPLE before passing the 7439function off to be compiled. The Fortran front end converts from a 7440private representation to GENERIC, which is later lowered to GIMPLE when 7441the function is compiled. Which route to choose probably depends on how 7442well GENERIC (plus extensions) can be made to match up with the source 7443language and necessary parsing data structures. 7444 7445 BUG: Gimplification must occur before nested function lowering, and 7446nested function lowering must be done by the front end before passing 7447the data off to cgraph. 7448 7449 TODO: Cgraph should control nested function lowering. It would only be 7450invoked when it is certain that the outer-most function is used. 7451 7452 TODO: Cgraph needs a gimplify_function callback. It should be invoked 7453when (1) it is certain that the function is used, (2) warning flags 7454specified by the user require some amount of compilation in order to 7455honor, (3) the language indicates that semantic analysis is not complete 7456until gimplification occurs. Hum... this sounds overly complicated. 7457Perhaps we should just have the front end gimplify always; in most cases 7458it's only one function call. 7459 7460 The front end needs to pass all function definitions and top level 7461declarations off to the middle-end so that they can be compiled and 7462emitted to the object file. For a simple procedural language, it is 7463usually most convenient to do this as each top level declaration or 7464definition is seen. There is also a distinction to be made between 7465generating functional code and generating complete debug information. 7466The only thing that is absolutely required for functional code is that 7467function and data _definitions_ be passed to the middle-end. For 7468complete debug information, function, data and type declarations should 7469all be passed as well. 7470 7471 In any case, the front end needs each complete top-level function or 7472data declaration, and each data definition should be passed to 7473'rest_of_decl_compilation'. Each complete type definition should be 7474passed to 'rest_of_type_compilation'. Each function definition should 7475be passed to 'cgraph_finalize_function'. 7476 7477 TODO: I know rest_of_compilation currently has all sorts of RTL 7478generation semantics. I plan to move all code generation bits (both 7479Tree and RTL) to compile_function. Should we hide cgraph from the front 7480ends and move back to rest_of_compilation as the official interface? 7481Possibly we should rename all three interfaces such that the names match 7482in some meaningful way and that is more descriptive than "rest_of". 7483 7484 The middle-end will, at its option, emit the function and data 7485definitions immediately or queue them for later processing. 7486 7487 7488File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes 7489 74909.2 Gimplification pass 7491======================= 7492 7493"Gimplification" is a whimsical term for the process of converting the 7494intermediate representation of a function into the GIMPLE language 7495(*note GIMPLE::). The term stuck, and so words like "gimplification", 7496"gimplify", "gimplifier" and the like are sprinkled throughout this 7497section of code. 7498 7499 While a front end may certainly choose to generate GIMPLE directly if 7500it chooses, this can be a moderately complex process unless the 7501intermediate language used by the front end is already fairly simple. 7502Usually it is easier to generate GENERIC trees plus extensions and let 7503the language-independent gimplifier do most of the work. 7504 7505 The main entry point to this pass is 'gimplify_function_tree' located 7506in 'gimplify.c'. From here we process the entire function gimplifying 7507each statement in turn. The main workhorse for this pass is 7508'gimplify_expr'. Approximately everything passes through here at least 7509once, and it is from here that we invoke the 'lang_hooks.gimplify_expr' 7510callback. 7511 7512 The callback should examine the expression in question and return 7513'GS_UNHANDLED' if the expression is not a language specific construct 7514that requires attention. Otherwise it should alter the expression in 7515some way to such that forward progress is made toward producing valid 7516GIMPLE. If the callback is certain that the transformation is complete 7517and the expression is valid GIMPLE, it should return 'GS_ALL_DONE'. 7518Otherwise it should return 'GS_OK', which will cause the expression to 7519be processed again. If the callback encounters an error during the 7520transformation (because the front end is relying on the gimplification 7521process to finish semantic checks), it should return 'GS_ERROR'. 7522 7523 7524File: gccint.info, Node: Pass manager, Next: IPA passes, Prev: Gimplification pass, Up: Passes 7525 75269.3 Pass manager 7527================ 7528 7529The pass manager is located in 'passes.c', 'tree-optimize.c' and 7530'tree-pass.h'. It processes passes as described in 'passes.def'. Its 7531job is to run all of the individual passes in the correct order, and 7532take care of standard bookkeeping that applies to every pass. 7533 7534 The theory of operation is that each pass defines a structure that 7535represents everything we need to know about that pass--when it should be 7536run, how it should be run, what intermediate language form or 7537on-the-side data structures it needs. We register the pass to be run in 7538some particular order, and the pass manager arranges for everything to 7539happen in the correct order. 7540 7541 The actuality doesn't completely live up to the theory at present. 7542Command-line switches and 'timevar_id_t' enumerations must still be 7543defined elsewhere. The pass manager validates constraints but does not 7544attempt to (re-)generate data structures or lower intermediate language 7545form based on the requirements of the next pass. Nevertheless, what is 7546present is useful, and a far sight better than nothing at all. 7547 7548 Each pass should have a unique name. Each pass may have its own dump 7549file (for GCC debugging purposes). Passes with a name starting with a 7550star do not dump anything. Sometimes passes are supposed to share a 7551dump file / option name. To still give these unique names, you can use 7552a prefix that is delimited by a space from the part that is used for the 7553dump file / option name. E.g. When the pass name is "ud dce", the name 7554used for dump file/options is "dce". 7555 7556 TODO: describe the global variables set up by the pass manager, and a 7557brief description of how a new pass should use it. I need to look at 7558what info RTL passes use first... 7559 7560 7561File: gccint.info, Node: IPA passes, Next: Tree SSA passes, Prev: Pass manager, Up: Passes 7562 75639.4 Inter-procedural optimization passes 7564======================================== 7565 7566The inter-procedural optimization (IPA) passes use call graph 7567information to perform transformations across function boundaries. IPA 7568is a critical part of link-time optimization (LTO) and whole-program 7569(WHOPR) optimization, and these passes are structured with the needs of 7570LTO and WHOPR in mind by dividing their operations into stages. For 7571detailed discussion of the LTO/WHOPR IPA pass stages and interfaces, see 7572*note IPA::. 7573 7574 The following briefly describes the inter-procedural optimization (IPA) 7575passes, which are split into small IPA passes, regular IPA passes, and 7576late IPA passes, according to the LTO/WHOPR processing model. 7577 7578* Menu: 7579 7580* Small IPA passes:: 7581* Regular IPA passes:: 7582* Late IPA passes:: 7583 7584 7585File: gccint.info, Node: Small IPA passes, Next: Regular IPA passes, Up: IPA passes 7586 75879.4.1 Small IPA passes 7588---------------------- 7589 7590A small IPA pass is a pass derived from 'simple_ipa_opt_pass'. As 7591described in *note IPA::, it does everything at once and defines only 7592the _Execute_ stage. During this stage it accesses and modifies the 7593function bodies. No 'generate_summary', 'read_summary', or 7594'write_summary' hooks are defined. 7595 7596 * IPA free lang data 7597 7598 This pass frees resources that are used by the front end but are 7599 not needed once it is done. It is located in 'tree.c' and is 7600 described by 'pass_ipa_free_lang_data'. 7601 7602 * IPA function and variable visibility 7603 7604 This is a local function pass handling visibilities of all symbols. 7605 This happens before LTO streaming, so '-fwhole-program' should be 7606 ignored at this level. It is located in 'ipa-visibility.c' and is 7607 described by 'pass_ipa_function_and_variable_visibility'. 7608 7609 * IPA remove symbols 7610 7611 This pass performs reachability analysis and reclaims all 7612 unreachable nodes. It is located in 'passes.c' and is described by 7613 'pass_ipa_remove_symbols'. 7614 7615 * IPA OpenACC 7616 7617 This is a pass group for OpenACC processing. It is located in 7618 'tree-ssa-loop.c' and is described by 'pass_ipa_oacc'. 7619 7620 * IPA points-to analysis 7621 7622 This is a tree-based points-to analysis pass. The idea behind this 7623 analyzer is to generate set constraints from the program, then 7624 solve the resulting constraints in order to generate the points-to 7625 sets. It is located in 'tree-ssa-structalias.c' and is described 7626 by 'pass_ipa_pta'. 7627 7628 * IPA OpenACC kernels 7629 7630 This is a pass group for processing OpenACC kernels regions. It is 7631 a subpass of the IPA OpenACC pass group that runs on offloaded 7632 functions containing OpenACC kernels loops. It is located in 7633 'tree-ssa-loop.c' and is described by 'pass_ipa_oacc_kernels'. 7634 7635 * Target clone 7636 7637 This is a pass for parsing functions with multiple target 7638 attributes. It is located in 'multiple_target.c' and is described 7639 by 'pass_target_clone'. 7640 7641 * IPA auto profile 7642 7643 This pass uses AutoFDO profiling data to annotate the control flow 7644 graph. It is located in 'auto-profile.c' and is described by 7645 'pass_ipa_auto_profile'. 7646 7647 * IPA tree profile 7648 7649 This pass does profiling for all functions in the call graph. It 7650 calculates branch probabilities and basic block execution counts. 7651 It is located in 'tree-profile.c' and is described by 7652 'pass_ipa_tree_profile'. 7653 7654 * IPA free function summary 7655 7656 This pass is a small IPA pass when argument 'small_p' is true. It 7657 releases inline function summaries and call summaries. It is 7658 located in 'ipa-fnsummary.c' and is described by 7659 'pass_ipa_free_free_fn_summary'. 7660 7661 * IPA increase alignment 7662 7663 This pass increases the alignment of global arrays to improve 7664 vectorization. It is located in 'tree-vectorizer.c' and is 7665 described by 'pass_ipa_increase_alignment'. 7666 7667 * IPA transactional memory 7668 7669 This pass is for transactional memory support. It is located in 7670 'trans-mem.c' and is described by 'pass_ipa_tm'. 7671 7672 * IPA lower emulated TLS 7673 7674 This pass lowers thread-local storage (TLS) operations to emulation 7675 functions provided by libgcc. It is located in 'tree-emutls.c' and 7676 is described by 'pass_ipa_lower_emutls'. 7677 7678 7679File: gccint.info, Node: Regular IPA passes, Next: Late IPA passes, Prev: Small IPA passes, Up: IPA passes 7680 76819.4.2 Regular IPA passes 7682------------------------ 7683 7684A regular IPA pass is a pass derived from 'ipa_opt_pass_d' that is 7685executed in WHOPR compilation. Regular IPA passes may have summary 7686hooks implemented in any of the LGEN, WPA or LTRANS stages (*note 7687IPA::). 7688 7689 * IPA whole program visibility 7690 7691 This pass performs various optimizations involving symbol 7692 visibility with '-fwhole-program', including symbol privatization, 7693 discovering local functions, and dismantling comdat groups. It is 7694 located in 'ipa-visibility.c' and is described by 7695 'pass_ipa_whole_program_visibility'. 7696 7697 * IPA profile 7698 7699 The IPA profile pass propagates profiling frequencies across the 7700 call graph. It is located in 'ipa-profile.c' and is described by 7701 'pass_ipa_profile'. 7702 7703 * IPA identical code folding 7704 7705 This is the inter-procedural identical code folding pass. The goal 7706 of this transformation is to discover functions and read-only 7707 variables that have exactly the same semantics. It is located in 7708 'ipa-icf.c' and is described by 'pass_ipa_icf'. 7709 7710 * IPA devirtualization 7711 7712 This pass performs speculative devirtualization based on the type 7713 inheritance graph. When a polymorphic call has only one likely 7714 target in the unit, it is turned into a speculative call. It is 7715 located in 'ipa-devirt.c' and is described by 'pass_ipa_devirt'. 7716 7717 * IPA constant propagation 7718 7719 The goal of this pass is to discover functions that are always 7720 invoked with some arguments with the same known constant values and 7721 to modify the functions accordingly. It can also do partial 7722 specialization and type-based devirtualization. It is located in 7723 'ipa-cp.c' and is described by 'pass_ipa_cp'. 7724 7725 * IPA scalar replacement of aggregates 7726 7727 This pass can replace an aggregate parameter with a set of other 7728 parameters representing part of the original, turning those passed 7729 by reference into new ones which pass the value directly. It also 7730 removes unused function return values and unused function 7731 parameters. This pass is located in 'ipa-sra.c' and is described 7732 by 'pass_ipa_sra'. 7733 7734 * IPA constructor/destructor merge 7735 7736 This pass merges multiple constructors and destructors for static 7737 objects into single functions. It's only run at LTO time unless 7738 the target doesn't support constructors and destructors natively. 7739 The pass is located in 'ipa.c' and is described by 7740 'pass_ipa_cdtor_merge'. 7741 7742 * IPA function summary 7743 7744 This pass provides function analysis for inter-procedural passes. 7745 It collects estimates of function body size, execution time, and 7746 frame size for each function. It also estimates information about 7747 function calls: call statement size, time and how often the 7748 parameters change for each call. It is located in 7749 'ipa-fnsummary.c' and is described by 'pass_ipa_fn_summary'. 7750 7751 * IPA inline 7752 7753 The IPA inline pass handles function inlining with whole-program 7754 knowledge. Small functions that are candidates for inlining are 7755 ordered in increasing badness, bounded by unit growth parameters. 7756 Unreachable functions are removed from the call graph. Functions 7757 called once and not exported from the unit are inlined. This pass 7758 is located in 'ipa-inline.c' and is described by 'pass_ipa_inline'. 7759 7760 * IPA pure/const analysis 7761 7762 This pass marks functions as being either const ('TREE_READONLY') 7763 or pure ('DECL_PURE_P'). The per-function information is produced 7764 by 'pure_const_generate_summary', then the global information is 7765 computed by performing a transitive closure over the call graph. 7766 It is located in 'ipa-pure-const.c' and is described by 7767 'pass_ipa_pure_const'. 7768 7769 * IPA free function summary 7770 7771 This pass is a regular IPA pass when argument 'small_p' is false. 7772 It releases inline function summaries and call summaries. It is 7773 located in 'ipa-fnsummary.c' and is described by 7774 'pass_ipa_free_fn_summary'. 7775 7776 * IPA reference 7777 7778 This pass gathers information about how variables whose scope is 7779 confined to the compilation unit are used. It is located in 7780 'ipa-reference.c' and is described by 'pass_ipa_reference'. 7781 7782 * IPA single use 7783 7784 This pass checks whether variables are used by a single function. 7785 It is located in 'ipa.c' and is described by 'pass_ipa_single_use'. 7786 7787 * IPA comdats 7788 7789 This pass looks for static symbols that are used exclusively within 7790 one comdat group, and moves them into that comdat group. It is 7791 located in 'ipa-comdats.c' and is described by 'pass_ipa_comdats'. 7792 7793 7794File: gccint.info, Node: Late IPA passes, Prev: Regular IPA passes, Up: IPA passes 7795 77969.4.3 Late IPA passes 7797--------------------- 7798 7799Late IPA passes are simple IPA passes executed after the regular passes. 7800In WHOPR mode the passes are executed after partitioning and thus see 7801just parts of the compiled unit. 7802 7803 * Materialize all clones 7804 7805 Once all functions from compilation unit are in memory, produce all 7806 clones and update all calls. It is located in 'ipa.c' and is 7807 described by 'pass_materialize_all_clones'. 7808 7809 * IPA points-to analysis 7810 7811 Points-to analysis; this is the same as the points-to-analysis pass 7812 run with the small IPA passes (*note Small IPA passes::). 7813 7814 * OpenMP simd clone 7815 7816 This is the OpenMP constructs' SIMD clone pass. It creates the 7817 appropriate SIMD clones for functions tagged as elemental SIMD 7818 functions. It is located in 'omp-simd-clone.c' and is described by 7819 'pass_omp_simd_clone'. 7820 7821 7822File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: IPA passes, Up: Passes 7823 78249.5 Tree SSA passes 7825=================== 7826 7827The following briefly describes the Tree optimization passes that are 7828run after gimplification and what source files they are located in. 7829 7830 * Remove useless statements 7831 7832 This pass is an extremely simple sweep across the gimple code in 7833 which we identify obviously dead code and remove it. Here we do 7834 things like simplify 'if' statements with constant conditions, 7835 remove exception handling constructs surrounding code that 7836 obviously cannot throw, remove lexical bindings that contain no 7837 variables, and other assorted simplistic cleanups. The idea is to 7838 get rid of the obvious stuff quickly rather than wait until later 7839 when it's more work to get rid of it. This pass is located in 7840 'tree-cfg.c' and described by 'pass_remove_useless_stmts'. 7841 7842 * OpenMP lowering 7843 7844 If OpenMP generation ('-fopenmp') is enabled, this pass lowers 7845 OpenMP constructs into GIMPLE. 7846 7847 Lowering of OpenMP constructs involves creating replacement 7848 expressions for local variables that have been mapped using data 7849 sharing clauses, exposing the control flow of most synchronization 7850 directives and adding region markers to facilitate the creation of 7851 the control flow graph. The pass is located in 'omp-low.c' and is 7852 described by 'pass_lower_omp'. 7853 7854 * OpenMP expansion 7855 7856 If OpenMP generation ('-fopenmp') is enabled, this pass expands 7857 parallel regions into their own functions to be invoked by the 7858 thread library. The pass is located in 'omp-low.c' and is 7859 described by 'pass_expand_omp'. 7860 7861 * Lower control flow 7862 7863 This pass flattens 'if' statements ('COND_EXPR') and moves lexical 7864 bindings ('BIND_EXPR') out of line. After this pass, all 'if' 7865 statements will have exactly two 'goto' statements in its 'then' 7866 and 'else' arms. Lexical binding information for each statement 7867 will be found in 'TREE_BLOCK' rather than being inferred from its 7868 position under a 'BIND_EXPR'. This pass is found in 'gimple-low.c' 7869 and is described by 'pass_lower_cf'. 7870 7871 * Lower exception handling control flow 7872 7873 This pass decomposes high-level exception handling constructs 7874 ('TRY_FINALLY_EXPR' and 'TRY_CATCH_EXPR') into a form that 7875 explicitly represents the control flow involved. After this pass, 7876 'lookup_stmt_eh_region' will return a non-negative number for any 7877 statement that may have EH control flow semantics; examine 7878 'tree_can_throw_internal' or 'tree_can_throw_external' for exact 7879 semantics. Exact control flow may be extracted from 7880 'foreach_reachable_handler'. The EH region nesting tree is defined 7881 in 'except.h' and built in 'except.c'. The lowering pass itself is 7882 in 'tree-eh.c' and is described by 'pass_lower_eh'. 7883 7884 * Build the control flow graph 7885 7886 This pass decomposes a function into basic blocks and creates all 7887 of the edges that connect them. It is located in 'tree-cfg.c' and 7888 is described by 'pass_build_cfg'. 7889 7890 * Find all referenced variables 7891 7892 This pass walks the entire function and collects an array of all 7893 variables referenced in the function, 'referenced_vars'. The index 7894 at which a variable is found in the array is used as a UID for the 7895 variable within this function. This data is needed by the SSA 7896 rewriting routines. The pass is located in 'tree-dfa.c' and is 7897 described by 'pass_referenced_vars'. 7898 7899 * Enter static single assignment form 7900 7901 This pass rewrites the function such that it is in SSA form. After 7902 this pass, all 'is_gimple_reg' variables will be referenced by 7903 'SSA_NAME', and all occurrences of other variables will be 7904 annotated with 'VDEFS' and 'VUSES'; PHI nodes will have been 7905 inserted as necessary for each basic block. This pass is located 7906 in 'tree-ssa.c' and is described by 'pass_build_ssa'. 7907 7908 * Warn for uninitialized variables 7909 7910 This pass scans the function for uses of 'SSA_NAME's that are fed 7911 by default definition. For non-parameter variables, such uses are 7912 uninitialized. The pass is run twice, before and after 7913 optimization (if turned on). In the first pass we only warn for 7914 uses that are positively uninitialized; in the second pass we warn 7915 for uses that are possibly uninitialized. The pass is located in 7916 'tree-ssa.c' and is defined by 'pass_early_warn_uninitialized' and 7917 'pass_late_warn_uninitialized'. 7918 7919 * Dead code elimination 7920 7921 This pass scans the function for statements without side effects 7922 whose result is unused. It does not do memory life analysis, so 7923 any value that is stored in memory is considered used. The pass is 7924 run multiple times throughout the optimization process. It is 7925 located in 'tree-ssa-dce.c' and is described by 'pass_dce'. 7926 7927 * Dominator optimizations 7928 7929 This pass performs trivial dominator-based copy and constant 7930 propagation, expression simplification, and jump threading. It is 7931 run multiple times throughout the optimization process. It is 7932 located in 'tree-ssa-dom.c' and is described by 'pass_dominator'. 7933 7934 * Forward propagation of single-use variables 7935 7936 This pass attempts to remove redundant computation by substituting 7937 variables that are used once into the expression that uses them and 7938 seeing if the result can be simplified. It is located in 7939 'tree-ssa-forwprop.c' and is described by 'pass_forwprop'. 7940 7941 * Copy Renaming 7942 7943 This pass attempts to change the name of compiler temporaries 7944 involved in copy operations such that SSA->normal can coalesce the 7945 copy away. When compiler temporaries are copies of user variables, 7946 it also renames the compiler temporary to the user variable 7947 resulting in better use of user symbols. It is located in 7948 'tree-ssa-copyrename.c' and is described by 'pass_copyrename'. 7949 7950 * PHI node optimizations 7951 7952 This pass recognizes forms of PHI inputs that can be represented as 7953 conditional expressions and rewrites them into straight line code. 7954 It is located in 'tree-ssa-phiopt.c' and is described by 7955 'pass_phiopt'. 7956 7957 * May-alias optimization 7958 7959 This pass performs a flow sensitive SSA-based points-to analysis. 7960 The resulting may-alias, must-alias, and escape analysis 7961 information is used to promote variables from in-memory addressable 7962 objects to non-aliased variables that can be renamed into SSA form. 7963 We also update the 'VDEF'/'VUSE' memory tags for non-renameable 7964 aggregates so that we get fewer false kills. The pass is located 7965 in 'tree-ssa-alias.c' and is described by 'pass_may_alias'. 7966 7967 Interprocedural points-to information is located in 7968 'tree-ssa-structalias.c' and described by 'pass_ipa_pta'. 7969 7970 * Profiling 7971 7972 This pass instruments the function in order to collect runtime 7973 block and value profiling data. Such data may be fed back into the 7974 compiler on a subsequent run so as to allow optimization based on 7975 expected execution frequencies. The pass is located in 7976 'tree-profile.c' and is described by 'pass_ipa_tree_profile'. 7977 7978 * Static profile estimation 7979 7980 This pass implements series of heuristics to guess propababilities 7981 of branches. The resulting predictions are turned into edge 7982 profile by propagating branches across the control flow graphs. 7983 The pass is located in 'tree-profile.c' and is described by 7984 'pass_profile'. 7985 7986 * Lower complex arithmetic 7987 7988 This pass rewrites complex arithmetic operations into their 7989 component scalar arithmetic operations. The pass is located in 7990 'tree-complex.c' and is described by 'pass_lower_complex'. 7991 7992 * Scalar replacement of aggregates 7993 7994 This pass rewrites suitable non-aliased local aggregate variables 7995 into a set of scalar variables. The resulting scalar variables are 7996 rewritten into SSA form, which allows subsequent optimization 7997 passes to do a significantly better job with them. The pass is 7998 located in 'tree-sra.c' and is described by 'pass_sra'. 7999 8000 * Dead store elimination 8001 8002 This pass eliminates stores to memory that are subsequently 8003 overwritten by another store, without any intervening loads. The 8004 pass is located in 'tree-ssa-dse.c' and is described by 'pass_dse'. 8005 8006 * Tail recursion elimination 8007 8008 This pass transforms tail recursion into a loop. It is located in 8009 'tree-tailcall.c' and is described by 'pass_tail_recursion'. 8010 8011 * Forward store motion 8012 8013 This pass sinks stores and assignments down the flowgraph closer to 8014 their use point. The pass is located in 'tree-ssa-sink.c' and is 8015 described by 'pass_sink_code'. 8016 8017 * Partial redundancy elimination 8018 8019 This pass eliminates partially redundant computations, as well as 8020 performing load motion. The pass is located in 'tree-ssa-pre.c' 8021 and is described by 'pass_pre'. 8022 8023 Just before partial redundancy elimination, if 8024 '-funsafe-math-optimizations' is on, GCC tries to convert divisions 8025 to multiplications by the reciprocal. The pass is located in 8026 'tree-ssa-math-opts.c' and is described by 'pass_cse_reciprocal'. 8027 8028 * Full redundancy elimination 8029 8030 This is a simpler form of PRE that only eliminates redundancies 8031 that occur on all paths. It is located in 'tree-ssa-pre.c' and 8032 described by 'pass_fre'. 8033 8034 * Loop optimization 8035 8036 The main driver of the pass is placed in 'tree-ssa-loop.c' and 8037 described by 'pass_loop'. 8038 8039 The optimizations performed by this pass are: 8040 8041 Loop invariant motion. This pass moves only invariants that would 8042 be hard to handle on RTL level (function calls, operations that 8043 expand to nontrivial sequences of insns). With '-funswitch-loops' 8044 it also moves operands of conditions that are invariant out of the 8045 loop, so that we can use just trivial invariantness analysis in 8046 loop unswitching. The pass also includes store motion. The pass 8047 is implemented in 'tree-ssa-loop-im.c'. 8048 8049 Canonical induction variable creation. This pass creates a simple 8050 counter for number of iterations of the loop and replaces the exit 8051 condition of the loop using it, in case when a complicated analysis 8052 is necessary to determine the number of iterations. Later 8053 optimizations then may determine the number easily. The pass is 8054 implemented in 'tree-ssa-loop-ivcanon.c'. 8055 8056 Induction variable optimizations. This pass performs standard 8057 induction variable optimizations, including strength reduction, 8058 induction variable merging and induction variable elimination. The 8059 pass is implemented in 'tree-ssa-loop-ivopts.c'. 8060 8061 Loop unswitching. This pass moves the conditional jumps that are 8062 invariant out of the loops. To achieve this, a duplicate of the 8063 loop is created for each possible outcome of conditional jump(s). 8064 The pass is implemented in 'tree-ssa-loop-unswitch.c'. 8065 8066 Loop splitting. If a loop contains a conditional statement that is 8067 always true for one part of the iteration space and false for the 8068 other this pass splits the loop into two, one dealing with one side 8069 the other only with the other, thereby removing one inner-loop 8070 conditional. The pass is implemented in 'tree-ssa-loop-split.c'. 8071 8072 The optimizations also use various utility functions contained in 8073 'tree-ssa-loop-manip.c', 'cfgloop.c', 'cfgloopanal.c' and 8074 'cfgloopmanip.c'. 8075 8076 Vectorization. This pass transforms loops to operate on vector 8077 types instead of scalar types. Data parallelism across loop 8078 iterations is exploited to group data elements from consecutive 8079 iterations into a vector and operate on them in parallel. 8080 Depending on available target support the loop is conceptually 8081 unrolled by a factor 'VF' (vectorization factor), which is the 8082 number of elements operated upon in parallel in each iteration, and 8083 the 'VF' copies of each scalar operation are fused to form a vector 8084 operation. Additional loop transformations such as peeling and 8085 versioning may take place to align the number of iterations, and to 8086 align the memory accesses in the loop. The pass is implemented in 8087 'tree-vectorizer.c' (the main driver), 'tree-vect-loop.c' and 8088 'tree-vect-loop-manip.c' (loop specific parts and general loop 8089 utilities), 'tree-vect-slp' (loop-aware SLP functionality), 8090 'tree-vect-stmts.c', 'tree-vect-data-refs.c' and 8091 'tree-vect-slp-patterns.c' containing the SLP pattern matcher. 8092 Analysis of data references is in 'tree-data-ref.c'. 8093 8094 SLP Vectorization. This pass performs vectorization of 8095 straight-line code. The pass is implemented in 'tree-vectorizer.c' 8096 (the main driver), 'tree-vect-slp.c', 'tree-vect-stmts.c' and 8097 'tree-vect-data-refs.c'. 8098 8099 Autoparallelization. This pass splits the loop iteration space to 8100 run into several threads. The pass is implemented in 8101 'tree-parloops.c'. 8102 8103 Graphite is a loop transformation framework based on the polyhedral 8104 model. Graphite stands for Gimple Represented as Polyhedra. The 8105 internals of this infrastructure are documented in 8106 <http://gcc.gnu.org/wiki/Graphite>. The passes working on this 8107 representation are implemented in the various 'graphite-*' files. 8108 8109 * Tree level if-conversion for vectorizer 8110 8111 This pass applies if-conversion to simple loops to help vectorizer. 8112 We identify if convertible loops, if-convert statements and merge 8113 basic blocks in one big block. The idea is to present loop in such 8114 form so that vectorizer can have one to one mapping between 8115 statements and available vector operations. This pass is located 8116 in 'tree-if-conv.c' and is described by 'pass_if_conversion'. 8117 8118 * Conditional constant propagation 8119 8120 This pass relaxes a lattice of values in order to identify those 8121 that must be constant even in the presence of conditional branches. 8122 The pass is located in 'tree-ssa-ccp.c' and is described by 8123 'pass_ccp'. 8124 8125 A related pass that works on memory loads and stores, and not just 8126 register values, is located in 'tree-ssa-ccp.c' and described by 8127 'pass_store_ccp'. 8128 8129 * Conditional copy propagation 8130 8131 This is similar to constant propagation but the lattice of values 8132 is the "copy-of" relation. It eliminates redundant copies from the 8133 code. The pass is located in 'tree-ssa-copy.c' and described by 8134 'pass_copy_prop'. 8135 8136 A related pass that works on memory copies, and not just register 8137 copies, is located in 'tree-ssa-copy.c' and described by 8138 'pass_store_copy_prop'. 8139 8140 * Value range propagation 8141 8142 This transformation is similar to constant propagation but instead 8143 of propagating single constant values, it propagates known value 8144 ranges. The implementation is based on Patterson's range 8145 propagation algorithm (Accurate Static Branch Prediction by Value 8146 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 8147 Patterson's algorithm, this implementation does not propagate 8148 branch probabilities nor it uses more than a single range per SSA 8149 name. This means that the current implementation cannot be used 8150 for branch prediction (though adapting it would not be difficult). 8151 The pass is located in 'tree-vrp.c' and is described by 'pass_vrp'. 8152 8153 * Folding built-in functions 8154 8155 This pass simplifies built-in functions, as applicable, with 8156 constant arguments or with inferable string lengths. It is located 8157 in 'tree-ssa-ccp.c' and is described by 'pass_fold_builtins'. 8158 8159 * Split critical edges 8160 8161 This pass identifies critical edges and inserts empty basic blocks 8162 such that the edge is no longer critical. The pass is located in 8163 'tree-cfg.c' and is described by 'pass_split_crit_edges'. 8164 8165 * Control dependence dead code elimination 8166 8167 This pass is a stronger form of dead code elimination that can 8168 eliminate unnecessary control flow statements. It is located in 8169 'tree-ssa-dce.c' and is described by 'pass_cd_dce'. 8170 8171 * Tail call elimination 8172 8173 This pass identifies function calls that may be rewritten into 8174 jumps. No code transformation is actually applied here, but the 8175 data and control flow problem is solved. The code transformation 8176 requires target support, and so is delayed until RTL. In the 8177 meantime 'CALL_EXPR_TAILCALL' is set indicating the possibility. 8178 The pass is located in 'tree-tailcall.c' and is described by 8179 'pass_tail_calls'. The RTL transformation is handled by 8180 'fixup_tail_calls' in 'calls.c'. 8181 8182 * Warn for function return without value 8183 8184 For non-void functions, this pass locates return statements that do 8185 not specify a value and issues a warning. Such a statement may 8186 have been injected by falling off the end of the function. This 8187 pass is run last so that we have as much time as possible to prove 8188 that the statement is not reachable. It is located in 'tree-cfg.c' 8189 and is described by 'pass_warn_function_return'. 8190 8191 * Leave static single assignment form 8192 8193 This pass rewrites the function such that it is in normal form. At 8194 the same time, we eliminate as many single-use temporaries as 8195 possible, so the intermediate language is no longer GIMPLE, but 8196 GENERIC. The pass is located in 'tree-outof-ssa.c' and is 8197 described by 'pass_del_ssa'. 8198 8199 * Merge PHI nodes that feed into one another 8200 8201 This is part of the CFG cleanup passes. It attempts to join PHI 8202 nodes from a forwarder CFG block into another block with PHI nodes. 8203 The pass is located in 'tree-cfgcleanup.c' and is described by 8204 'pass_merge_phi'. 8205 8206 * Return value optimization 8207 8208 If a function always returns the same local variable, and that 8209 local variable is an aggregate type, then the variable is replaced 8210 with the return value for the function (i.e., the function's 8211 DECL_RESULT). This is equivalent to the C++ named return value 8212 optimization applied to GIMPLE. The pass is located in 8213 'tree-nrv.c' and is described by 'pass_nrv'. 8214 8215 * Return slot optimization 8216 8217 If a function returns a memory object and is called as 'var = 8218 foo()', this pass tries to change the call so that the address of 8219 'var' is sent to the caller to avoid an extra memory copy. This 8220 pass is located in 'tree-nrv.c' and is described by 8221 'pass_return_slot'. 8222 8223 * Optimize calls to '__builtin_object_size' 8224 8225 This is a propagation pass similar to CCP that tries to remove 8226 calls to '__builtin_object_size' when the size of the object can be 8227 computed at compile-time. This pass is located in 8228 'tree-object-size.c' and is described by 'pass_object_sizes'. 8229 8230 * Loop invariant motion 8231 8232 This pass removes expensive loop-invariant computations out of 8233 loops. The pass is located in 'tree-ssa-loop.c' and described by 8234 'pass_lim'. 8235 8236 * Loop nest optimizations 8237 8238 This is a family of loop transformations that works on loop nests. 8239 It includes loop interchange, scaling, skewing and reversal and 8240 they are all geared to the optimization of data locality in array 8241 traversals and the removal of dependencies that hamper 8242 optimizations such as loop parallelization and vectorization. The 8243 pass is located in 'tree-loop-linear.c' and described by 8244 'pass_linear_transform'. 8245 8246 * Removal of empty loops 8247 8248 This pass removes loops with no code in them. The pass is located 8249 in 'tree-ssa-loop-ivcanon.c' and described by 'pass_empty_loop'. 8250 8251 * Unrolling of small loops 8252 8253 This pass completely unrolls loops with few iterations. The pass 8254 is located in 'tree-ssa-loop-ivcanon.c' and described by 8255 'pass_complete_unroll'. 8256 8257 * Predictive commoning 8258 8259 This pass makes the code reuse the computations from the previous 8260 iterations of the loops, especially loads and stores to memory. It 8261 does so by storing the values of these computations to a bank of 8262 temporary variables that are rotated at the end of loop. To avoid 8263 the need for this rotation, the loop is then unrolled and the 8264 copies of the loop body are rewritten to use the appropriate 8265 version of the temporary variable. This pass is located in 8266 'tree-predcom.c' and described by 'pass_predcom'. 8267 8268 * Array prefetching 8269 8270 This pass issues prefetch instructions for array references inside 8271 loops. The pass is located in 'tree-ssa-loop-prefetch.c' and 8272 described by 'pass_loop_prefetch'. 8273 8274 * Reassociation 8275 8276 This pass rewrites arithmetic expressions to enable optimizations 8277 that operate on them, like redundancy elimination and 8278 vectorization. The pass is located in 'tree-ssa-reassoc.c' and 8279 described by 'pass_reassoc'. 8280 8281 * Optimization of 'stdarg' functions 8282 8283 This pass tries to avoid the saving of register arguments into the 8284 stack on entry to 'stdarg' functions. If the function doesn't use 8285 any 'va_start' macros, no registers need to be saved. If 8286 'va_start' macros are used, the 'va_list' variables don't escape 8287 the function, it is only necessary to save registers that will be 8288 used in 'va_arg' macros. For instance, if 'va_arg' is only used 8289 with integral types in the function, floating point registers don't 8290 need to be saved. This pass is located in 'tree-stdarg.c' and 8291 described by 'pass_stdarg'. 8292 8293 8294File: gccint.info, Node: RTL passes, Next: Optimization info, Prev: Tree SSA passes, Up: Passes 8295 82969.6 RTL passes 8297============== 8298 8299The following briefly describes the RTL generation and optimization 8300passes that are run after the Tree optimization passes. 8301 8302 * RTL generation 8303 8304 The source files for RTL generation include 'stmt.c', 'calls.c', 8305 'expr.c', 'explow.c', 'expmed.c', 'function.c', 'optabs.c' and 8306 'emit-rtl.c'. Also, the file 'insn-emit.c', generated from the 8307 machine description by the program 'genemit', is used in this pass. 8308 The header file 'expr.h' is used for communication within this 8309 pass. 8310 8311 The header files 'insn-flags.h' and 'insn-codes.h', generated from 8312 the machine description by the programs 'genflags' and 'gencodes', 8313 tell this pass which standard names are available for use and which 8314 patterns correspond to them. 8315 8316 * Generation of exception landing pads 8317 8318 This pass generates the glue that handles communication between the 8319 exception handling library routines and the exception handlers 8320 within the function. Entry points in the function that are invoked 8321 by the exception handling library are called "landing pads". The 8322 code for this pass is located in 'except.c'. 8323 8324 * Control flow graph cleanup 8325 8326 This pass removes unreachable code, simplifies jumps to next, jumps 8327 to jump, jumps across jumps, etc. The pass is run multiple times. 8328 For historical reasons, it is occasionally referred to as the "jump 8329 optimization pass". The bulk of the code for this pass is in 8330 'cfgcleanup.c', and there are support routines in 'cfgrtl.c' and 8331 'jump.c'. 8332 8333 * Forward propagation of single-def values 8334 8335 This pass attempts to remove redundant computation by substituting 8336 variables that come from a single definition, and seeing if the 8337 result can be simplified. It performs copy propagation and 8338 addressing mode selection. The pass is run twice, with values 8339 being propagated into loops only on the second run. The code is 8340 located in 'fwprop.c'. 8341 8342 * Common subexpression elimination 8343 8344 This pass removes redundant computation within basic blocks, and 8345 optimizes addressing modes based on cost. The pass is run twice. 8346 The code for this pass is located in 'cse.c'. 8347 8348 * Global common subexpression elimination 8349 8350 This pass performs two different types of GCSE depending on whether 8351 you are optimizing for size or not (LCM based GCSE tends to 8352 increase code size for a gain in speed, while Morel-Renvoise based 8353 GCSE does not). When optimizing for size, GCSE is done using 8354 Morel-Renvoise Partial Redundancy Elimination, with the exception 8355 that it does not try to move invariants out of loops--that is left 8356 to the loop optimization pass. If MR PRE GCSE is done, code 8357 hoisting (aka unification) is also done, as well as load motion. 8358 If you are optimizing for speed, LCM (lazy code motion) based GCSE 8359 is done. LCM is based on the work of Knoop, Ruthing, and Steffen. 8360 LCM based GCSE also does loop invariant code motion. We also 8361 perform load and store motion when optimizing for speed. 8362 Regardless of which type of GCSE is used, the GCSE pass also 8363 performs global constant and copy propagation. The source file for 8364 this pass is 'gcse.c', and the LCM routines are in 'lcm.c'. 8365 8366 * Loop optimization 8367 8368 This pass performs several loop related optimizations. The source 8369 files 'cfgloopanal.c' and 'cfgloopmanip.c' contain generic loop 8370 analysis and manipulation code. Initialization and finalization of 8371 loop structures is handled by 'loop-init.c'. A loop invariant 8372 motion pass is implemented in 'loop-invariant.c'. Basic block 8373 level optimizations--unrolling, and peeling loops-- are implemented 8374 in 'loop-unroll.c'. Replacing of the exit condition of loops by 8375 special machine-dependent instructions is handled by 8376 'loop-doloop.c'. 8377 8378 * Jump bypassing 8379 8380 This pass is an aggressive form of GCSE that transforms the control 8381 flow graph of a function by propagating constants into conditional 8382 branch instructions. The source file for this pass is 'gcse.c'. 8383 8384 * If conversion 8385 8386 This pass attempts to replace conditional branches and surrounding 8387 assignments with arithmetic, boolean value producing comparison 8388 instructions, and conditional move instructions. In the very last 8389 invocation after reload/LRA, it will generate predicated 8390 instructions when supported by the target. The code is located in 8391 'ifcvt.c'. 8392 8393 * Web construction 8394 8395 This pass splits independent uses of each pseudo-register. This 8396 can improve effect of the other transformation, such as CSE or 8397 register allocation. The code for this pass is located in 'web.c'. 8398 8399 * Instruction combination 8400 8401 This pass attempts to combine groups of two or three instructions 8402 that are related by data flow into single instructions. It 8403 combines the RTL expressions for the instructions by substitution, 8404 simplifies the result using algebra, and then attempts to match the 8405 result against the machine description. The code is located in 8406 'combine.c'. 8407 8408 * Mode switching optimization 8409 8410 This pass looks for instructions that require the processor to be 8411 in a specific "mode" and minimizes the number of mode changes 8412 required to satisfy all users. What these modes are, and what they 8413 apply to are completely target-specific. The code for this pass is 8414 located in 'mode-switching.c'. 8415 8416 * Modulo scheduling 8417 8418 This pass looks at innermost loops and reorders their instructions 8419 by overlapping different iterations. Modulo scheduling is 8420 performed immediately before instruction scheduling. The code for 8421 this pass is located in 'modulo-sched.c'. 8422 8423 * Instruction scheduling 8424 8425 This pass looks for instructions whose output will not be available 8426 by the time that it is used in subsequent instructions. Memory 8427 loads and floating point instructions often have this behavior on 8428 RISC machines. It re-orders instructions within a basic block to 8429 try to separate the definition and use of items that otherwise 8430 would cause pipeline stalls. This pass is performed twice, before 8431 and after register allocation. The code for this pass is located 8432 in 'haifa-sched.c', 'sched-deps.c', 'sched-ebb.c', 'sched-rgn.c' 8433 and 'sched-vis.c'. 8434 8435 * Register allocation 8436 8437 These passes make sure that all occurrences of pseudo registers are 8438 eliminated, either by allocating them to a hard register, replacing 8439 them by an equivalent expression (e.g. a constant) or by placing 8440 them on the stack. This is done in several subpasses: 8441 8442 * The integrated register allocator (IRA). It is called 8443 integrated because coalescing, register live range splitting, 8444 and hard register preferencing are done on-the-fly during 8445 coloring. It also has better integration with the reload/LRA 8446 pass. Pseudo-registers spilled by the allocator or the 8447 reload/LRA have still a chance to get hard-registers if the 8448 reload/LRA evicts some pseudo-registers from hard-registers. 8449 The allocator helps to choose better pseudos for spilling 8450 based on their live ranges and to coalesce stack slots 8451 allocated for the spilled pseudo-registers. IRA is a regional 8452 register allocator which is transformed into Chaitin-Briggs 8453 allocator if there is one region. By default, IRA chooses 8454 regions using register pressure but the user can force it to 8455 use one region or regions corresponding to all loops. 8456 8457 Source files of the allocator are 'ira.c', 'ira-build.c', 8458 'ira-costs.c', 'ira-conflicts.c', 'ira-color.c', 'ira-emit.c', 8459 'ira-lives', plus header files 'ira.h' and 'ira-int.h' used 8460 for the communication between the allocator and the rest of 8461 the compiler and between the IRA files. 8462 8463 * Reloading. This pass renumbers pseudo registers with the 8464 hardware registers numbers they were allocated. Pseudo 8465 registers that did not get hard registers are replaced with 8466 stack slots. Then it finds instructions that are invalid 8467 because a value has failed to end up in a register, or has 8468 ended up in a register of the wrong kind. It fixes up these 8469 instructions by reloading the problematical values temporarily 8470 into registers. Additional instructions are generated to do 8471 the copying. 8472 8473 The reload pass also optionally eliminates the frame pointer 8474 and inserts instructions to save and restore call-clobbered 8475 registers around calls. 8476 8477 Source files are 'reload.c' and 'reload1.c', plus the header 8478 'reload.h' used for communication between them. 8479 8480 * This pass is a modern replacement of the reload pass. Source 8481 files are 'lra.c', 'lra-assign.c', 'lra-coalesce.c', 8482 'lra-constraints.c', 'lra-eliminations.c', 'lra-lives.c', 8483 'lra-remat.c', 'lra-spills.c', the header 'lra-int.h' used for 8484 communication between them, and the header 'lra.h' used for 8485 communication between LRA and the rest of compiler. 8486 8487 Unlike the reload pass, intermediate LRA decisions are 8488 reflected in RTL as much as possible. This reduces the number 8489 of target-dependent macros and hooks, leaving instruction 8490 constraints as the primary source of control. 8491 8492 LRA is run on targets for which TARGET_LRA_P returns true. 8493 8494 * Basic block reordering 8495 8496 This pass implements profile guided code positioning. If profile 8497 information is not available, various types of static analysis are 8498 performed to make the predictions normally coming from the profile 8499 feedback (IE execution frequency, branch probability, etc). It is 8500 implemented in the file 'bb-reorder.c', and the various prediction 8501 routines are in 'predict.c'. 8502 8503 * Variable tracking 8504 8505 This pass computes where the variables are stored at each position 8506 in code and generates notes describing the variable locations to 8507 RTL code. The location lists are then generated according to these 8508 notes to debug information if the debugging information format 8509 supports location lists. The code is located in 'var-tracking.c'. 8510 8511 * Delayed branch scheduling 8512 8513 This optional pass attempts to find instructions that can go into 8514 the delay slots of other instructions, usually jumps and calls. 8515 The code for this pass is located in 'reorg.c'. 8516 8517 * Branch shortening 8518 8519 On many RISC machines, branch instructions have a limited range. 8520 Thus, longer sequences of instructions must be used for long 8521 branches. In this pass, the compiler figures out what how far each 8522 instruction will be from each other instruction, and therefore 8523 whether the usual instructions, or the longer sequences, must be 8524 used for each branch. The code for this pass is located in 8525 'final.c'. 8526 8527 * Register-to-stack conversion 8528 8529 Conversion from usage of some hard registers to usage of a register 8530 stack may be done at this point. Currently, this is supported only 8531 for the floating-point registers of the Intel 80387 coprocessor. 8532 The code for this pass is located in 'reg-stack.c'. 8533 8534 * Final 8535 8536 This pass outputs the assembler code for the function. The source 8537 files are 'final.c' plus 'insn-output.c'; the latter is generated 8538 automatically from the machine description by the tool 'genoutput'. 8539 The header file 'conditions.h' is used for communication between 8540 these files. 8541 8542 * Debugging information output 8543 8544 This is run after final because it must output the stack slot 8545 offsets for pseudo registers that did not get hard registers. 8546 Source files are 'dbxout.c' for DBX symbol table format, 8547 'dwarfout.c' for DWARF symbol table format, files 'dwarf2out.c' and 8548 'dwarf2asm.c' for DWARF2 symbol table format, and 'vmsdbgout.c' for 8549 VMS debug symbol table format. 8550 8551 8552File: gccint.info, Node: Optimization info, Prev: RTL passes, Up: Passes 8553 85549.7 Optimization info 8555===================== 8556 8557This section is describes dump infrastructure which is common to both 8558pass dumps as well as optimization dumps. The goal for this 8559infrastructure is to provide both gcc developers and users detailed 8560information about various compiler transformations and optimizations. 8561 8562* Menu: 8563 8564* Dump setup:: Setup of optimization dumps. 8565* Optimization groups:: Groups made up of optimization passes. 8566* Dump files and streams:: Dump output file names and streams. 8567* Dump output verbosity:: How much information to dump. 8568* Dump types:: Various types of dump functions. 8569* Dump examples:: Sample usage. 8570 8571 8572File: gccint.info, Node: Dump setup, Next: Optimization groups, Up: Optimization info 8573 85749.7.1 Dump setup 8575---------------- 8576 8577A dump_manager class is defined in 'dumpfile.h'. Various passes 8578register dumping pass-specific information via 'dump_register' in 8579'passes.c'. During the registration, an optimization pass can select 8580its optimization group (*note Optimization groups::). After that 8581optimization information corresponding to the entire group (presumably 8582from multiple passes) can be output via command-line switches. Note 8583that if a pass does not fit into any of the pre-defined groups, it can 8584select 'OPTGROUP_NONE'. 8585 8586 Note that in general, a pass need not know its dump output file name, 8587whether certain flags are enabled, etc. However, for legacy reasons, 8588passes could also call 'dump_begin' which returns a stream in case the 8589particular pass has optimization dumps enabled. A pass could call 8590'dump_end' when the dump has ended. These methods should go away once 8591all the passes are converted to use the new dump infrastructure. 8592 8593 The recommended way to setup the dump output is via 'dump_start' and 8594'dump_end'. 8595 8596 8597File: gccint.info, Node: Optimization groups, Next: Dump files and streams, Prev: Dump setup, Up: Optimization info 8598 85999.7.2 Optimization groups 8600------------------------- 8601 8602The optimization passes are grouped into several categories. Currently 8603defined categories in 'dumpfile.h' are 8604 8605'OPTGROUP_IPA' 8606 IPA optimization passes. Enabled by '-ipa' 8607 8608'OPTGROUP_LOOP' 8609 Loop optimization passes. Enabled by '-loop'. 8610 8611'OPTGROUP_INLINE' 8612 Inlining passes. Enabled by '-inline'. 8613 8614'OPTGROUP_OMP' 8615 OMP (Offloading and Multi Processing) passes. Enabled by '-omp'. 8616 8617'OPTGROUP_VEC' 8618 Vectorization passes. Enabled by '-vec'. 8619 8620'OPTGROUP_OTHER' 8621 All other optimization passes which do not fall into one of the 8622 above. 8623 8624'OPTGROUP_ALL' 8625 All optimization passes. Enabled by '-optall'. 8626 8627 By using groups a user could selectively enable optimization 8628information only for a group of passes. By default, the optimization 8629information for all the passes is dumped. 8630 8631 8632File: gccint.info, Node: Dump files and streams, Next: Dump output verbosity, Prev: Optimization groups, Up: Optimization info 8633 86349.7.3 Dump files and streams 8635---------------------------- 8636 8637There are two separate output streams available for outputting 8638optimization information from passes. Note that both these streams 8639accept 'stderr' and 'stdout' as valid streams and thus it is possible to 8640dump output to standard output or error. This is specially handy for 8641outputting all available information in a single file by redirecting 8642'stderr'. 8643 8644'pstream' 8645 This stream is for pass-specific dump output. For example, 8646 '-fdump-tree-vect=foo.v' dumps tree vectorization pass output into 8647 the given file name 'foo.v'. If the file name is not provided, the 8648 default file name is based on the source file and pass number. 8649 Note that one could also use special file names 'stdout' and 8650 'stderr' for dumping to standard output and standard error 8651 respectively. 8652 8653'alt_stream' 8654 This steam is used for printing optimization specific output in 8655 response to the '-fopt-info'. Again a file name can be given. If 8656 the file name is not given, it defaults to 'stderr'. 8657 8658 8659File: gccint.info, Node: Dump output verbosity, Next: Dump types, Prev: Dump files and streams, Up: Optimization info 8660 86619.7.4 Dump output verbosity 8662--------------------------- 8663 8664The dump verbosity has the following options 8665 8666'optimized' 8667 Print information when an optimization is successfully applied. It 8668 is up to a pass to decide which information is relevant. For 8669 example, the vectorizer passes print the source location of loops 8670 which got successfully vectorized. 8671 8672'missed' 8673 Print information about missed optimizations. Individual passes 8674 control which information to include in the output. For example, 8675 8676 gcc -O2 -ftree-vectorize -fopt-info-vec-missed 8677 8678 will print information about missed optimization opportunities from 8679 vectorization passes on stderr. 8680 8681'note' 8682 Print verbose information about optimizations, such as certain 8683 transformations, more detailed messages about decisions etc. 8684 8685'all' 8686 Print detailed optimization information. This includes OPTIMIZED, 8687 MISSED, and NOTE. 8688 8689 8690File: gccint.info, Node: Dump types, Next: Dump examples, Prev: Dump output verbosity, Up: Optimization info 8691 86929.7.5 Dump types 8693---------------- 8694 8695'dump_printf' 8696 8697 This is a generic method for doing formatted output. It takes an 8698 additional argument 'dump_kind' which signifies the type of dump. 8699 This method outputs information only when the dumps are enabled for 8700 this particular 'dump_kind'. Note that the caller doesn't need to 8701 know if the particular dump is enabled or not, or even the file 8702 name. The caller only needs to decide which dump output 8703 information is relevant, and under what conditions. This 8704 determines the associated flags. 8705 8706 Consider the following example from 'loop-unroll.c' where an 8707 informative message about a loop (along with its location) is 8708 printed when any of the following flags is enabled 8709 8710 - optimization messages 8711 - RTL dumps 8712 - detailed dumps 8713 8714 int report_flags = MSG_OPTIMIZED_LOCATIONS | TDF_RTL | TDF_DETAILS; 8715 dump_printf_loc (report_flags, insn, 8716 "loop turned into non-loop; it never loops.\n"); 8717 8718'dump_basic_block' 8719 Output basic block. 8720'dump_generic_expr' 8721 Output generic expression. 8722'dump_gimple_stmt' 8723 Output gimple statement. 8724 8725 Note that the above methods also have variants prefixed with 8726 '_loc', such as 'dump_printf_loc', which are similar except they 8727 also output the source location information. The '_loc' variants 8728 take a 'const dump_location_t &'. This class can be constructed 8729 from a 'gimple *' or from a 'rtx_insn *', and so callers can pass a 8730 'gimple *' or a 'rtx_insn *' as the '_loc' argument. The 8731 'dump_location_t' constructor will extract the source location from 8732 the statement or instruction, along with the profile count, and the 8733 location in GCC's own source code (or the plugin) from which the 8734 dump call was emitted. Only the source location is currently used. 8735 There is also a 'dump_user_location_t' class, capturing the source 8736 location and profile count, but not the dump emission location, so 8737 that locations in the user's code can be passed around. This can 8738 also be constructed from a 'gimple *' and from a 'rtx_insn *', and 8739 it too can be passed as the '_loc' argument. 8740 8741 8742File: gccint.info, Node: Dump examples, Prev: Dump types, Up: Optimization info 8743 87449.7.6 Dump examples 8745------------------- 8746 8747 gcc -O3 -fopt-info-missed=missed.all 8748 8749 outputs missed optimization report from all the passes into 8750'missed.all'. 8751 8752 As another example, 8753 gcc -O3 -fopt-info-inline-optimized-missed=inline.txt 8754 8755 will output information about missed optimizations as well as optimized 8756locations from all the inlining passes into 'inline.txt'. 8757 8758 If the FILENAME is provided, then the dumps from all the applicable 8759optimizations are concatenated into the 'filename'. Otherwise the dump 8760is output onto 'stderr'. If OPTIONS is omitted, it defaults to 8761'optimized-optall', which means dump all information about successful 8762optimizations from all the passes. In the following example, the 8763optimization information is output on to 'stderr'. 8764 8765 gcc -O3 -fopt-info 8766 8767 Note that '-fopt-info-vec-missed' behaves the same as 8768'-fopt-info-missed-vec'. The order of the optimization group names and 8769message types listed after '-fopt-info' does not matter. 8770 8771 As another example, consider 8772 8773 gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt 8774 8775 Here the two output file names 'vec.miss' and 'loop.opt' are in 8776conflict since only one output file is allowed. In this case, only the 8777first option takes effect and the subsequent options are ignored. Thus 8778only the 'vec.miss' is produced which containts dumps from the 8779vectorizer about missed opportunities. 8780 8781 8782File: gccint.info, Node: poly_int, Next: GENERIC, Prev: Passes, Up: Top 8783 878410 Sizes and offsets as runtime invariants 8785****************************************** 8786 8787GCC allows the size of a hardware register to be a runtime invariant 8788rather than a compile-time constant. This in turn means that various 8789sizes and offsets must also be runtime invariants rather than 8790compile-time constants, such as: 8791 8792 * the size of a general 'machine_mode' (*note Machine Modes::); 8793 8794 * the size of a spill slot; 8795 8796 * the offset of something within a stack frame; 8797 8798 * the number of elements in a vector; 8799 8800 * the size and offset of a 'mem' rtx (*note Regs and Memory::); and 8801 8802 * the byte offset in a 'subreg' rtx (*note Regs and Memory::). 8803 8804 The motivating example is the Arm SVE ISA, whose vector registers can 8805be any multiple of 128 bits between 128 and 2048 inclusive. The 8806compiler normally produces code that works for all SVE register sizes, 8807with the actual size only being known at runtime. 8808 8809 GCC's main representation of such runtime invariants is the 'poly_int' 8810class. This chapter describes what 'poly_int' does, lists the available 8811operations, and gives some general usage guidelines. 8812 8813* Menu: 8814 8815* Overview of poly_int:: 8816* Consequences of using poly_int:: 8817* Comparisons involving poly_int:: 8818* Arithmetic on poly_ints:: 8819* Alignment of poly_ints:: 8820* Computing bounds on poly_ints:: 8821* Converting poly_ints:: 8822* Miscellaneous poly_int routines:: 8823* Guidelines for using poly_int:: 8824 8825 8826File: gccint.info, Node: Overview of poly_int, Next: Consequences of using poly_int, Up: poly_int 8827 882810.1 Overview of 'poly_int' 8829=========================== 8830 8831We define indeterminates X1, ..., XN whose values are only known at 8832runtime and use polynomials of the form: 8833 8834 C0 + C1 * X1 + ... + CN * XN 8835 8836 to represent a size or offset whose value might depend on some of these 8837indeterminates. The coefficients C0, ..., CN are always known at 8838compile time, with the C0 term being the "constant" part that does not 8839depend on any runtime value. 8840 8841 GCC uses the 'poly_int' class to represent these coefficients. The 8842class has two template parameters: the first specifies the number of 8843coefficients (N + 1) and the second specifies the type of the 8844coefficients. For example, 'poly_int<2, unsigned short>' represents a 8845polynomial with two coefficients (and thus one indeterminate), with each 8846coefficient having type 'unsigned short'. When N is 0, the class 8847degenerates to a single compile-time constant C0. 8848 8849 The number of coefficients needed for compilation is a fixed property 8850of each target and is specified by the configuration macro 8851'NUM_POLY_INT_COEFFS'. The default value is 1, since most targets do 8852not have such runtime invariants. Targets that need a different value 8853should '#define' the macro in their 'CPU-modes.def' file. *Note Back 8854End::. 8855 8856 'poly_int' makes the simplifying requirement that each indeterminate 8857must be a nonnegative integer. An indeterminate value of 0 should 8858usually represent the minimum possible runtime value, with C0 specifying 8859the value in that case. 8860 8861 For example, when targetting the Arm SVE ISA, the single indeterminate 8862represents the number of 128-bit blocks in a vector _beyond the minimum 8863length of 128 bits_. Thus the number of 64-bit doublewords in a vector 8864is 2 + 2 * X1. If an aggregate has a single SVE vector and 16 8865additional bytes, its total size is 32 + 16 * X1 bytes. 8866 8867 The header file 'poly-int-types.h' provides typedefs for the most 8868common forms of 'poly_int', all having 'NUM_POLY_INT_COEFFS' 8869coefficients: 8870 8871'poly_uint16' 8872 a 'poly_int' with 'unsigned short' coefficients. 8873 8874'poly_int64' 8875 a 'poly_int' with 'HOST_WIDE_INT' coefficients. 8876 8877'poly_uint64' 8878 a 'poly_int' with 'unsigned HOST_WIDE_INT' coefficients. 8879 8880'poly_offset_int' 8881 a 'poly_int' with 'offset_int' coefficients. 8882 8883'poly_wide_int' 8884 a 'poly_int' with 'wide_int' coefficients. 8885 8886'poly_widest_int' 8887 a 'poly_int' with 'widest_int' coefficients. 8888 8889 Since the main purpose of 'poly_int' is to represent sizes and offsets, 8890the last two typedefs are only rarely used. 8891 8892 8893File: gccint.info, Node: Consequences of using poly_int, Next: Comparisons involving poly_int, Prev: Overview of poly_int, Up: poly_int 8894 889510.2 Consequences of using 'poly_int' 8896===================================== 8897 8898The two main consequences of using polynomial sizes and offsets are 8899that: 8900 8901 * there is no total ordering between the values at compile time, and 8902 8903 * some operations might yield results that cannot be expressed as a 8904 'poly_int'. 8905 8906 For example, if X is a runtime invariant, we cannot tell at compile 8907time whether: 8908 8909 3 + 4X <= 1 + 5X 8910 8911 since the condition is false when X <= 1 and true when X >= 2. 8912 8913 Similarly, 'poly_int' cannot represent the result of: 8914 8915 (3 + 4X) * (1 + 5X) 8916 8917 since it cannot (and in practice does not need to) store powers greater 8918than one. It also cannot represent the result of: 8919 8920 (3 + 4X) / (1 + 5X) 8921 8922 The following sections describe how we deal with these restrictions. 8923 8924 As described earlier, a 'poly_int<1, T>' has no indeterminates and so 8925degenerates to a compile-time constant of type T. It would be possible 8926in that case to do all normal arithmetic on the T, and to compare the T 8927using the normal C++ operators. We deliberately prevent 8928target-independent code from doing this, since the compiler needs to 8929support other 'poly_int<N, T>' as well, regardless of the current 8930target's 'NUM_POLY_INT_COEFFS'. 8931 8932 However, it would be very artificial to force target-specific code to 8933follow these restrictions if the target has no runtime indeterminates. 8934There is therefore an implicit conversion from 'poly_int<1, T>' to T 8935when compiling target-specific translation units. 8936 8937 8938File: gccint.info, Node: Comparisons involving poly_int, Next: Arithmetic on poly_ints, Prev: Consequences of using poly_int, Up: poly_int 8939 894010.3 Comparisons involving 'poly_int' 8941===================================== 8942 8943In general we need to compare sizes and offsets in two situations: those 8944in which the values need to be ordered, and those in which the values 8945can be unordered. More loosely, the distinction is often between values 8946that have a definite link (usually because they refer to the same 8947underlying register or memory location) and values that have no definite 8948link. An example of the former is the relationship between the inner 8949and outer sizes of a subreg, where we must know at compile time whether 8950the subreg is paradoxical, partial, or complete. An example of the 8951latter is alias analysis: we might want to check whether two arbitrary 8952memory references overlap. 8953 8954 Referring back to the examples in the previous section, it makes sense 8955to ask whether a memory reference of size '3 + 4X' overlaps one of size 8956'1 + 5X', but it does not make sense to have a subreg in which the outer 8957mode has '3 + 4X' bytes and the inner mode has '1 + 5X' bytes (or vice 8958versa). Such subregs are always invalid and should trigger an internal 8959compiler error if formed. 8960 8961 The underlying operators are the same in both cases, but the 8962distinction affects how they are used. 8963 8964* Menu: 8965 8966* Comparison functions for poly_int:: 8967* Properties of the poly_int comparisons:: 8968* Comparing potentially-unordered poly_ints:: 8969* Comparing ordered poly_ints:: 8970* Checking for a poly_int marker value:: 8971* Range checks on poly_ints:: 8972* Sorting poly_ints:: 8973 8974 8975File: gccint.info, Node: Comparison functions for poly_int, Next: Properties of the poly_int comparisons, Up: Comparisons involving poly_int 8976 897710.3.1 Comparison functions for 'poly_int' 8978------------------------------------------ 8979 8980'poly_int' provides the following routines for checking whether a 8981particular condition "may be" (might be) true: 8982 8983 maybe_lt maybe_le maybe_eq maybe_ge maybe_gt 8984 maybe_ne 8985 8986 The functions have their natural meaning: 8987 8988'maybe_lt(A, B)' 8989 Return true if A might be less than B. 8990 8991'maybe_le(A, B)' 8992 Return true if A might be less than or equal to B. 8993 8994'maybe_eq(A, B)' 8995 Return true if A might be equal to B. 8996 8997'maybe_ne(A, B)' 8998 Return true if A might not be equal to B. 8999 9000'maybe_ge(A, B)' 9001 Return true if A might be greater than or equal to B. 9002 9003'maybe_gt(A, B)' 9004 Return true if A might be greater than B. 9005 9006 For readability, 'poly_int' also provides "known" inverses of these 9007functions: 9008 9009 known_lt (A, B) == !maybe_ge (A, B) 9010 known_le (A, B) == !maybe_gt (A, B) 9011 known_eq (A, B) == !maybe_ne (A, B) 9012 known_ge (A, B) == !maybe_lt (A, B) 9013 known_gt (A, B) == !maybe_le (A, B) 9014 known_ne (A, B) == !maybe_eq (A, B) 9015 9016 9017File: 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 9018 901910.3.2 Properties of the 'poly_int' comparisons 9020----------------------------------------------- 9021 9022All "maybe" relations except 'maybe_ne' are transitive, so for example: 9023 9024 maybe_lt (A, B) && maybe_lt (B, C) implies maybe_lt (A, C) 9025 9026 for all A, B and C. 'maybe_lt', 'maybe_gt' and 'maybe_ne' are 9027irreflexive, so for example: 9028 9029 !maybe_lt (A, A) 9030 9031 is true for all A. 'maybe_le', 'maybe_eq' and 'maybe_ge' are 9032reflexive, so for example: 9033 9034 maybe_le (A, A) 9035 9036 is true for all A. 'maybe_eq' and 'maybe_ne' are symmetric, so: 9037 9038 maybe_eq (A, B) == maybe_eq (B, A) 9039 maybe_ne (A, B) == maybe_ne (B, A) 9040 9041 for all A and B. In addition: 9042 9043 maybe_le (A, B) == maybe_lt (A, B) || maybe_eq (A, B) 9044 maybe_ge (A, B) == maybe_gt (A, B) || maybe_eq (A, B) 9045 maybe_lt (A, B) == maybe_gt (B, A) 9046 maybe_le (A, B) == maybe_ge (B, A) 9047 9048 However: 9049 9050 maybe_le (A, B) && maybe_le (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)] 9051 maybe_ge (A, B) && maybe_ge (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)] 9052 9053 One example is again 'A == 3 + 4X' and 'B == 1 + 5X', where 'maybe_le 9054(A, B)', 'maybe_ge (A, B)' and 'maybe_ne (A, B)' all hold. 'maybe_le' 9055and 'maybe_ge' are therefore not antisymetric and do not form a partial 9056order. 9057 9058 From the above, it follows that: 9059 9060 * All "known" relations except 'known_ne' are transitive. 9061 9062 * 'known_lt', 'known_ne' and 'known_gt' are irreflexive. 9063 9064 * 'known_le', 'known_eq' and 'known_ge' are reflexive. 9065 9066 Also: 9067 9068 known_lt (A, B) == known_gt (B, A) 9069 known_le (A, B) == known_ge (B, A) 9070 known_lt (A, B) implies !known_lt (B, A) [asymmetry] 9071 known_gt (A, B) implies !known_gt (B, A) 9072 known_le (A, B) && known_le (B, A) == known_eq (A, B) [== !maybe_ne (A, B)] 9073 known_ge (A, B) && known_ge (B, A) == known_eq (A, B) [== !maybe_ne (A, B)] 9074 9075 'known_le' and 'known_ge' are therefore antisymmetric and are partial 9076orders. However: 9077 9078 known_le (A, B) does not imply known_lt (A, B) || known_eq (A, B) 9079 known_ge (A, B) does not imply known_gt (A, B) || known_eq (A, B) 9080 9081 For example, 'known_le (4, 4 + 4X)' holds because the runtime 9082indeterminate X is a nonnegative integer, but neither 'known_lt (4, 4 + 90834X)' nor 'known_eq (4, 4 + 4X)' hold. 9084 9085 9086File: 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 9087 908810.3.3 Comparing potentially-unordered 'poly_int's 9089-------------------------------------------------- 9090 9091In cases where there is no definite link between two 'poly_int's, we can 9092usually make a conservatively-correct assumption. For example, the 9093conservative assumption for alias analysis is that two references 9094_might_ alias. 9095 9096 One way of checking whether [BEGIN1, END1) might overlap [BEGIN2, END2) 9097using the 'poly_int' comparisons is: 9098 9099 maybe_gt (END1, BEGIN2) && maybe_gt (END2, BEGIN1) 9100 9101 and another (equivalent) way is: 9102 9103 !(known_le (END1, BEGIN2) || known_le (END2, BEGIN1)) 9104 9105 However, in this particular example, it is better to use the range 9106helper functions instead. *Note Range checks on poly_ints::. 9107 9108 9109File: 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 9110 911110.3.4 Comparing ordered 'poly_int's 9112------------------------------------ 9113 9114In cases where there is a definite link between two 'poly_int's, such as 9115the outer and inner sizes of subregs, we usually require the sizes to be 9116ordered by the 'known_le' partial order. 'poly_int' provides the 9117following utility functions for ordered values: 9118 9119'ordered_p (A, B)' 9120 Return true if A and B are ordered by the 'known_le' partial order. 9121 9122'ordered_min (A, B)' 9123 Assert that A and B are ordered by 'known_le' and return the 9124 minimum of the two. When using this function, please add a comment 9125 explaining why the values are known to be ordered. 9126 9127'ordered_max (A, B)' 9128 Assert that A and B are ordered by 'known_le' and return the 9129 maximum of the two. When using this function, please add a comment 9130 explaining why the values are known to be ordered. 9131 9132 For example, if a subreg has an outer mode of size OUTER and an inner 9133mode of size INNER: 9134 9135 * the subreg is complete if known_eq (INNER, OUTER) 9136 9137 * otherwise, the subreg is paradoxical if known_le (INNER, OUTER) 9138 9139 * otherwise, the subreg is partial if known_le (OUTER, INNER) 9140 9141 * otherwise, the subreg is ill-formed 9142 9143 Thus the subreg is only valid if 'ordered_p (OUTER, INNER)' is true. 9144If this condition is already known to be true then: 9145 9146 * the subreg is complete if known_eq (INNER, OUTER) 9147 9148 * the subreg is paradoxical if maybe_lt (INNER, OUTER) 9149 9150 * the subreg is partial if maybe_lt (OUTER, INNER) 9151 9152 with the three conditions being mutually exclusive. 9153 9154 Code that checks whether a subreg is valid would therefore generally 9155check whether 'ordered_p' holds (in addition to whatever other checks 9156are required for subreg validity). Code that is dealing with existing 9157subregs can assert that 'ordered_p' holds and use either of the 9158classifications above. 9159 9160 9161File: 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 9162 916310.3.5 Checking for a 'poly_int' marker value 9164--------------------------------------------- 9165 9166It is sometimes useful to have a special "marker value" that is not 9167meant to be taken literally. For example, some code uses a size of -1 9168to represent an unknown size, rather than having to carry around a 9169separate boolean to say whether the size is known. 9170 9171 The best way of checking whether something is a marker value is 9172'known_eq'. Conversely the best way of checking whether something is 9173_not_ a marker value is 'maybe_ne'. 9174 9175 Thus in the size example just mentioned, 'known_eq (size, -1)' would 9176check for an unknown size and 'maybe_ne (size, -1)' would check for a 9177known size. 9178 9179 9180File: 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 9181 918210.3.6 Range checks on 'poly_int's 9183---------------------------------- 9184 9185As well as the core comparisons (*note Comparison functions for 9186poly_int::), 'poly_int' provides utilities for various kinds of range 9187check. In each case the range is represented by a start position and a 9188size rather than a start position and an end position; this is because 9189the former is used much more often than the latter in GCC. Also, the 9190sizes can be -1 (or all ones for unsigned sizes) to indicate a range 9191with a known start position but an unknown size. All other sizes must 9192be nonnegative. A range of size 0 does not contain anything or overlap 9193anything. 9194 9195'known_size_p (SIZE)' 9196 Return true if SIZE represents a known range size, false if it is 9197 -1 or all ones (for signed and unsigned types respectively). 9198 9199'ranges_maybe_overlap_p (POS1, SIZE1, POS2, SIZE2)' 9200 Return true if the range described by POS1 and SIZE1 _might_ 9201 overlap the range described by POS2 and SIZE2 (in other words, 9202 return true if we cannot prove that the ranges are disjoint). 9203 9204'ranges_known_overlap_p (POS1, SIZE1, POS2, SIZE2)' 9205 Return true if the range described by POS1 and SIZE1 is known to 9206 overlap the range described by POS2 and SIZE2. 9207 9208'known_subrange_p (POS1, SIZE1, POS2, SIZE2)' 9209 Return true if the range described by POS1 and SIZE1 is known to be 9210 contained in the range described by POS2 and SIZE2. 9211 9212'maybe_in_range_p (VALUE, POS, SIZE)' 9213 Return true if VALUE _might_ be in the range described by POS and 9214 SIZE (in other words, return true if we cannot prove that VALUE is 9215 outside that range). 9216 9217'known_in_range_p (VALUE, POS, SIZE)' 9218 Return true if VALUE is known to be in the range described by POS 9219 and SIZE. 9220 9221'endpoint_representable_p (POS, SIZE)' 9222 Return true if the range described by POS and SIZE is open-ended or 9223 if the endpoint (POS + SIZE) is representable in the same type as 9224 POS and SIZE. The function returns false if adding SIZE to POS 9225 makes conceptual sense but could overflow. 9226 9227 There is also a 'poly_int' version of the 'IN_RANGE_P' macro: 9228 9229'coeffs_in_range_p (X, LOWER, UPPER)' 9230 Return true if every coefficient of X is in the inclusive range 9231 [LOWER, UPPER]. This function can be useful when testing whether 9232 an operation would cause the values of coefficients to overflow. 9233 9234 Note that the function does not indicate whether X itself is in the 9235 given range. X can be either a constant or a 'poly_int'. 9236 9237 9238File: gccint.info, Node: Sorting poly_ints, Prev: Range checks on poly_ints, Up: Comparisons involving poly_int 9239 924010.3.7 Sorting 'poly_int's 9241-------------------------- 9242 9243'poly_int' provides the following routine for sorting: 9244 9245'compare_sizes_for_sort (A, B)' 9246 Compare A and B in reverse lexicographical order (that is, compare 9247 the highest-indexed coefficients first). This can be useful when 9248 sorting data structures, since it has the effect of separating 9249 constant and non-constant values. If all values are nonnegative, 9250 the constant values come first. 9251 9252 Note that the values do not necessarily end up in numerical order. 9253 For example, '1 + 1X' would come after '100' in the sort order, but 9254 may well be less than '100' at run time. 9255 9256 9257File: gccint.info, Node: Arithmetic on poly_ints, Next: Alignment of poly_ints, Prev: Comparisons involving poly_int, Up: poly_int 9258 925910.4 Arithmetic on 'poly_int's 9260============================== 9261 9262Addition, subtraction, negation and bit inversion all work normally for 9263'poly_int's. Multiplication by a constant multiplier and left shifting 9264by a constant shift amount also work normally. General multiplication 9265of two 'poly_int's is not supported and is not useful in practice. 9266 9267 Other operations are only conditionally supported: the operation might 9268succeed or might fail, depending on the inputs. 9269 9270 This section describes both types of operation. 9271 9272* Menu: 9273 9274* Using poly_int with C++ arithmetic operators:: 9275* wi arithmetic on poly_ints:: 9276* Division of poly_ints:: 9277* Other poly_int arithmetic:: 9278 9279 9280File: gccint.info, Node: Using poly_int with C++ arithmetic operators, Next: wi arithmetic on poly_ints, Up: Arithmetic on poly_ints 9281 928210.4.1 Using 'poly_int' with C++ arithmetic operators 9283----------------------------------------------------- 9284 9285The following C++ expressions are supported, where P1 and P2 are 9286'poly_int's and where C1 and C2 are scalars: 9287 9288 -P1 9289 ~P1 9290 9291 P1 + P2 9292 P1 + C2 9293 C1 + P2 9294 9295 P1 - P2 9296 P1 - C2 9297 C1 - P2 9298 9299 C1 * P2 9300 P1 * C2 9301 9302 P1 << C2 9303 9304 P1 += P2 9305 P1 += C2 9306 9307 P1 -= P2 9308 P1 -= C2 9309 9310 P1 *= C2 9311 P1 <<= C2 9312 9313 These arithmetic operations handle integer ranks in a similar way to 9314C++. The main difference is that every coefficient narrower than 9315'HOST_WIDE_INT' promotes to 'HOST_WIDE_INT', whereas in C++ everything 9316narrower than 'int' promotes to 'int'. For example: 9317 9318 poly_uint16 + int -> poly_int64 9319 unsigned int + poly_uint16 -> poly_int64 9320 poly_int64 + int -> poly_int64 9321 poly_int32 + poly_uint64 -> poly_uint64 9322 uint64 + poly_int64 -> poly_uint64 9323 poly_offset_int + int32 -> poly_offset_int 9324 offset_int + poly_uint16 -> poly_offset_int 9325 9326 In the first two examples, both coefficients are narrower than 9327'HOST_WIDE_INT', so the result has coefficients of type 'HOST_WIDE_INT'. 9328In the other examples, the coefficient with the highest rank "wins". 9329 9330 If one of the operands is 'wide_int' or 'poly_wide_int', the rules are 9331the same as for 'wide_int' arithmetic. 9332 9333 9334File: 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 9335 933610.4.2 'wi' arithmetic on 'poly_int's 9337------------------------------------- 9338 9339As well as the C++ operators, 'poly_int' supports the following 'wi' 9340routines: 9341 9342 wi::neg (P1, &OVERFLOW) 9343 9344 wi::add (P1, P2) 9345 wi::add (P1, C2) 9346 wi::add (C1, P1) 9347 wi::add (P1, P2, SIGN, &OVERFLOW) 9348 9349 wi::sub (P1, P2) 9350 wi::sub (P1, C2) 9351 wi::sub (C1, P1) 9352 wi::sub (P1, P2, SIGN, &OVERFLOW) 9353 9354 wi::mul (P1, C2) 9355 wi::mul (C1, P1) 9356 wi::mul (P1, C2, SIGN, &OVERFLOW) 9357 9358 wi::lshift (P1, C2) 9359 9360 These routines just check whether overflow occurs on any individual 9361coefficient; it is not possible to know at compile time whether the 9362final runtime value would overflow. 9363 9364 9365File: gccint.info, Node: Division of poly_ints, Next: Other poly_int arithmetic, Prev: wi arithmetic on poly_ints, Up: Arithmetic on poly_ints 9366 936710.4.3 Division of 'poly_int's 9368------------------------------ 9369 9370Division of 'poly_int's is possible for certain inputs. The functions 9371for division return true if the operation is possible and in most cases 9372return the results by pointer. The routines are: 9373 9374'multiple_p (A, B)' 9375'multiple_p (A, B, "IENT)' 9376 Return true if A is an exact multiple of B, storing the result in 9377 QUOTIENT if so. There are overloads for various combinations of 9378 polynomial and constant A, B and QUOTIENT. 9379 9380'constant_multiple_p (A, B)' 9381'constant_multiple_p (A, B, "IENT)' 9382 Like 'multiple_p', but also test whether the multiple is a 9383 compile-time constant. 9384 9385'can_div_trunc_p (A, B, "IENT)' 9386'can_div_trunc_p (A, B, "IENT, &REMAINDER)' 9387 Return true if we can calculate 'trunc (A / B)' at compile time, 9388 storing the result in QUOTIENT and REMAINDER if so. 9389 9390'can_div_away_from_zero_p (A, B, "IENT)' 9391 Return true if we can calculate 'A / B' at compile time, rounding 9392 away from zero. Store the result in QUOTIENT if so. 9393 9394 Note that this is true if and only if 'can_div_trunc_p' is true. 9395 The only difference is in the rounding of the result. 9396 9397 There is also an asserting form of division: 9398 9399'exact_div (A, B)' 9400 Assert that A is a multiple of B and return 'A / B'. The result is 9401 a 'poly_int' if A is a 'poly_int'. 9402 9403 9404File: gccint.info, Node: Other poly_int arithmetic, Prev: Division of poly_ints, Up: Arithmetic on poly_ints 9405 940610.4.4 Other 'poly_int' arithmetic 9407---------------------------------- 9408 9409There are tentative routines for other operations besides division: 9410 9411'can_ior_p (A, B, &RESULT)' 9412 Return true if we can calculate 'A | B' at compile time, storing 9413 the result in RESULT if so. 9414 9415 Also, ANDs with a value '(1 << Y) - 1' or its inverse can be treated as 9416alignment operations. *Note Alignment of poly_ints::. 9417 9418 In addition, the following miscellaneous routines are available: 9419 9420'coeff_gcd (A)' 9421 Return the greatest common divisor of all nonzero coefficients in 9422 A, or zero if A is known to be zero. 9423 9424'common_multiple (A, B)' 9425 Return a value that is a multiple of both A and B, where one value 9426 is a 'poly_int' and the other is a scalar. The result will be the 9427 least common multiple for some indeterminate values but not 9428 necessarily for all. 9429 9430'force_common_multiple (A, B)' 9431 Return a value that is a multiple of both 'poly_int' A and 9432 'poly_int' B, asserting that such a value exists. The result will 9433 be the least common multiple for some indeterminate values but not 9434 necessarily for all. 9435 9436 When using this routine, please add a comment explaining why the 9437 assertion is known to hold. 9438 9439 Please add any other operations that you find to be useful. 9440 9441 9442File: gccint.info, Node: Alignment of poly_ints, Next: Computing bounds on poly_ints, Prev: Arithmetic on poly_ints, Up: poly_int 9443 944410.5 Alignment of 'poly_int's 9445============================= 9446 9447'poly_int' provides various routines for aligning values and for 9448querying misalignments. In each case the alignment must be a power of 94492. 9450 9451'can_align_p (VALUE, ALIGN)' 9452 Return true if we can align VALUE up or down to the nearest 9453 multiple of ALIGN at compile time. The answer is the same for both 9454 directions. 9455 9456'can_align_down (VALUE, ALIGN, &ALIGNED)' 9457 Return true if 'can_align_p'; if so, set ALIGNED to the greatest 9458 aligned value that is less than or equal to VALUE. 9459 9460'can_align_up (VALUE, ALIGN, &ALIGNED)' 9461 Return true if 'can_align_p'; if so, set ALIGNED to the lowest 9462 aligned value that is greater than or equal to VALUE. 9463 9464'known_equal_after_align_down (A, B, ALIGN)' 9465 Return true if we can align A and B down to the nearest ALIGN 9466 boundary at compile time and if the two results are equal. 9467 9468'known_equal_after_align_up (A, B, ALIGN)' 9469 Return true if we can align A and B up to the nearest ALIGN 9470 boundary at compile time and if the two results are equal. 9471 9472'aligned_lower_bound (VALUE, ALIGN)' 9473 Return a result that is no greater than VALUE and that is aligned 9474 to ALIGN. The result will the closest aligned value for some 9475 indeterminate values but not necessarily for all. 9476 9477 For example, suppose we are allocating an object of SIZE bytes in a 9478 downward-growing stack whose current limit is given by LIMIT. If 9479 the object requires ALIGN bytes of alignment, the new stack limit 9480 is given by: 9481 9482 aligned_lower_bound (LIMIT - SIZE, ALIGN) 9483 9484'aligned_upper_bound (VALUE, ALIGN)' 9485 Likewise return a result that is no less than VALUE and that is 9486 aligned to ALIGN. This is the routine that would be used for 9487 upward-growing stacks in the scenario just described. 9488 9489'known_misalignment (VALUE, ALIGN, &MISALIGN)' 9490 Return true if we can calculate the misalignment of VALUE with 9491 respect to ALIGN at compile time, storing the result in MISALIGN if 9492 so. 9493 9494'known_alignment (VALUE)' 9495 Return the minimum alignment that VALUE is known to have (in other 9496 words, the largest alignment that can be guaranteed whatever the 9497 values of the indeterminates turn out to be). Return 0 if VALUE is 9498 known to be 0. 9499 9500'force_align_down (VALUE, ALIGN)' 9501 Assert that VALUE can be aligned down to ALIGN at compile time and 9502 return the result. When using this routine, please add a comment 9503 explaining why the assertion is known to hold. 9504 9505'force_align_up (VALUE, ALIGN)' 9506 Likewise, but aligning up. 9507 9508'force_align_down_and_div (VALUE, ALIGN)' 9509 Divide the result of 'force_align_down' by ALIGN. Again, please 9510 add a comment explaining why the assertion in 'force_align_down' is 9511 known to hold. 9512 9513'force_align_up_and_div (VALUE, ALIGN)' 9514 Likewise for 'force_align_up'. 9515 9516'force_get_misalignment (VALUE, ALIGN)' 9517 Assert that we can calculate the misalignment of VALUE with respect 9518 to ALIGN at compile time and return the misalignment. When using 9519 this function, please add a comment explaining why the assertion is 9520 known to hold. 9521 9522 9523File: gccint.info, Node: Computing bounds on poly_ints, Next: Converting poly_ints, Prev: Alignment of poly_ints, Up: poly_int 9524 952510.6 Computing bounds on 'poly_int's 9526==================================== 9527 9528'poly_int' also provides routines for calculating lower and upper 9529bounds: 9530 9531'constant_lower_bound (A)' 9532 Assert that A is nonnegative and return the smallest value it can 9533 have. 9534 9535'constant_lower_bound_with_limit (A, B)' 9536 Return the least value A can have, given that the context in which 9537 A appears guarantees that the answer is no less than B. In other 9538 words, the caller is asserting that A is greater than or equal to B 9539 even if 'known_ge (A, B)' doesn't hold. 9540 9541'constant_upper_bound_with_limit (A, B)' 9542 Return the greatest value A can have, given that the context in 9543 which A appears guarantees that the answer is no greater than B. 9544 In other words, the caller is asserting that A is less than or 9545 equal to B even if 'known_le (A, B)' doesn't hold. 9546 9547'lower_bound (A, B)' 9548 Return a value that is always less than or equal to both A and B. 9549 It will be the greatest such value for some indeterminate values 9550 but necessarily for all. 9551 9552'upper_bound (A, B)' 9553 Return a value that is always greater than or equal to both A and 9554 B. It will be the least such value for some indeterminate values 9555 but necessarily for all. 9556 9557 9558File: gccint.info, Node: Converting poly_ints, Next: Miscellaneous poly_int routines, Prev: Computing bounds on poly_ints, Up: poly_int 9559 956010.7 Converting 'poly_int's 9561=========================== 9562 9563A 'poly_int<N, T>' can be constructed from up to N individual T 9564coefficients, with the remaining coefficients being implicitly zero. In 9565particular, this means that every 'poly_int<N, T>' can be constructed 9566from a single scalar T, or something compatible with T. 9567 9568 Also, a 'poly_int<N, T>' can be constructed from a 'poly_int<N, U>' if 9569T can be constructed from U. 9570 9571 The following functions provide other forms of conversion, or test 9572whether such a conversion would succeed. 9573 9574'VALUE.is_constant ()' 9575 Return true if 'poly_int' VALUE is a compile-time constant. 9576 9577'VALUE.is_constant (&C1)' 9578 Return true if 'poly_int' VALUE is a compile-time constant, storing 9579 it in C1 if so. C1 must be able to hold all constant values of 9580 VALUE without loss of precision. 9581 9582'VALUE.to_constant ()' 9583 Assert that VALUE is a compile-time constant and return its value. 9584 When using this function, please add a comment explaining why the 9585 condition is known to hold (for example, because an earlier phase 9586 of analysis rejected non-constants). 9587 9588'VALUE.to_shwi (&P2)' 9589 Return true if 'poly_int<N, T>' VALUE can be represented without 9590 loss of precision as a 'poly_int<N, 'HOST_WIDE_INT'>', storing it 9591 in that form in P2 if so. 9592 9593'VALUE.to_uhwi (&P2)' 9594 Return true if 'poly_int<N, T>' VALUE can be represented without 9595 loss of precision as a 'poly_int<N, 'unsigned HOST_WIDE_INT'>', 9596 storing it in that form in P2 if so. 9597 9598'VALUE.force_shwi ()' 9599 Forcibly convert each coefficient of 'poly_int<N, T>' VALUE to 9600 'HOST_WIDE_INT', truncating any that are out of range. Return the 9601 result as a 'poly_int<N, 'HOST_WIDE_INT'>'. 9602 9603'VALUE.force_uhwi ()' 9604 Forcibly convert each coefficient of 'poly_int<N, T>' VALUE to 9605 'unsigned HOST_WIDE_INT', truncating any that are out of range. 9606 Return the result as a 'poly_int<N, 'unsigned HOST_WIDE_INT'>'. 9607 9608'wi::shwi (VALUE, PRECISION)' 9609 Return a 'poly_int' with the same value as VALUE, but with the 9610 coefficients converted from 'HOST_WIDE_INT' to 'wide_int'. 9611 PRECISION specifies the precision of the 'wide_int' cofficients; if 9612 this is wider than a 'HOST_WIDE_INT', the coefficients of VALUE 9613 will be sign-extended to fit. 9614 9615'wi::uhwi (VALUE, PRECISION)' 9616 Like 'wi::shwi', except that VALUE has coefficients of type 9617 'unsigned HOST_WIDE_INT'. If PRECISION is wider than a 9618 'HOST_WIDE_INT', the coefficients of VALUE will be zero-extended to 9619 fit. 9620 9621'wi::sext (VALUE, PRECISION)' 9622 Return a 'poly_int' of the same type as VALUE, sign-extending every 9623 coefficient from the low PRECISION bits. This in effect applies 9624 'wi::sext' to each coefficient individually. 9625 9626'wi::zext (VALUE, PRECISION)' 9627 Like 'wi::sext', but for zero extension. 9628 9629'poly_wide_int::from (VALUE, PRECISION, SIGN)' 9630 Convert VALUE to a 'poly_wide_int' in which each coefficient has 9631 PRECISION bits. Extend the coefficients according to SIGN if the 9632 coefficients have fewer bits. 9633 9634'poly_offset_int::from (VALUE, SIGN)' 9635 Convert VALUE to a 'poly_offset_int', extending its coefficients 9636 according to SIGN if they have fewer bits than 'offset_int'. 9637 9638'poly_widest_int::from (VALUE, SIGN)' 9639 Convert VALUE to a 'poly_widest_int', extending its coefficients 9640 according to SIGN if they have fewer bits than 'widest_int'. 9641 9642 9643File: gccint.info, Node: Miscellaneous poly_int routines, Next: Guidelines for using poly_int, Prev: Converting poly_ints, Up: poly_int 9644 964510.8 Miscellaneous 'poly_int' routines 9646====================================== 9647 9648'print_dec (VALUE, FILE, SIGN)' 9649'print_dec (VALUE, FILE)' 9650 Print VALUE to FILE as a decimal value, interpreting the 9651 coefficients according to SIGN. The final argument is optional if 9652 VALUE has an inherent sign; for example, 'poly_int64' values print 9653 as signed by default and 'poly_uint64' values print as unsigned by 9654 default. 9655 9656 This is a simply a 'poly_int' version of a wide-int routine. 9657 9658 9659File: gccint.info, Node: Guidelines for using poly_int, Prev: Miscellaneous poly_int routines, Up: poly_int 9660 966110.9 Guidelines for using 'poly_int' 9662==================================== 9663 9664One of the main design goals of 'poly_int' was to make it easy to write 9665target-independent code that handles variable-sized registers even when 9666the current target has fixed-sized registers. There are two aspects to 9667this: 9668 9669 * The set of 'poly_int' operations should be complete enough that the 9670 question in most cases becomes "Can we do this operation on these 9671 particular 'poly_int' values? If not, bail out" rather than "Are 9672 these 'poly_int' values constant? If so, do the operation, 9673 otherwise bail out". 9674 9675 * If target-independent code compiles and runs correctly on a target 9676 with one value of 'NUM_POLY_INT_COEFFS', and if the code does not 9677 use asserting functions like 'to_constant', it is reasonable to 9678 assume that the code also works on targets with other values of 9679 'NUM_POLY_INT_COEFFS'. There is no need to check this during 9680 everyday development. 9681 9682 So the general principle is: if target-independent code is dealing with 9683a 'poly_int' value, it is better to operate on it as a 'poly_int' if at 9684all possible, choosing conservatively-correct behavior if a particular 9685operation fails. For example, the following code handles an index 'pos' 9686into a sequence of vectors that each have 'nunits' elements: 9687 9688 /* Calculate which vector contains the result, and which lane of 9689 that vector we need. */ 9690 if (!can_div_trunc_p (pos, nunits, &vec_entry, &vec_index)) 9691 { 9692 if (dump_enabled_p ()) 9693 dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, 9694 "Cannot determine which vector holds the" 9695 " final result.\n"); 9696 return false; 9697 } 9698 9699 However, there are some contexts in which operating on a 'poly_int' is 9700not possible or does not make sense. One example is when handling 9701static initializers, since no current target supports the concept of a 9702variable-length static initializer. In these situations, a reasonable 9703fallback is: 9704 9705 if (POLY_VALUE.is_constant (&CONST_VALUE)) 9706 { 9707 ... 9708 /* Operate on CONST_VALUE. */ 9709 ... 9710 } 9711 else 9712 { 9713 ... 9714 /* Conservatively correct fallback. */ 9715 ... 9716 } 9717 9718 'poly_int' also provides some asserting functions like 'to_constant'. 9719Please only use these functions if there is a good theoretical reason to 9720believe that the assertion cannot fire. For example, if some work is 9721divided into an analysis phase and an implementation phase, the analysis 9722phase might reject inputs that are not 'is_constant', in which case the 9723implementation phase can reasonably use 'to_constant' on the remaining 9724inputs. The assertions should not be used to discover whether a 9725condition ever occurs "in the field"; in other words, they should not be 9726used to restrict code to constants at first, with the intention of only 9727implementing a 'poly_int' version if a user hits the assertion. 9728 9729 If a particular asserting function like 'to_constant' is needed more 9730than once for the same reason, it is probably worth adding a helper 9731function or macro for that situation, so that the justification only 9732needs to be given once. For example: 9733 9734 /* Return the size of an element in a vector of size SIZE, given that 9735 the vector has NELTS elements. The return value is in the same units 9736 as SIZE (either bits or bytes). 9737 9738 to_constant () is safe in this situation because vector elements are 9739 always constant-sized scalars. */ 9740 #define vector_element_size(SIZE, NELTS) \ 9741 (exact_div (SIZE, NELTS).to_constant ()) 9742 9743 Target-specific code in 'config/CPU' only needs to handle non-constant 9744'poly_int's if 'NUM_POLY_INT_COEFFS' is greater than one. For other 9745targets, 'poly_int' degenerates to a compile-time constant and is often 9746interchangable with a normal scalar integer. There are two main 9747exceptions: 9748 9749 * Sometimes an explicit cast to an integer type might be needed, such 9750 as to resolve ambiguities in a '?:' expression, or when passing 9751 values through '...' to things like print functions. 9752 9753 * Target macros are included in target-independent code and so do not 9754 have access to the implicit conversion to a scalar integer. If 9755 this becomes a problem for a particular target macro, the possible 9756 solutions, in order of preference, are: 9757 9758 * Convert the target macro to a target hook (for all targets). 9759 9760 * Put the target's implementation of the target macro in its 9761 'CPU.c' file and call it from the target macro in the 'CPU.h' 9762 file. 9763 9764 * Add 'to_constant ()' calls where necessary. The previous 9765 option is preferable because it will help with any future 9766 conversion of the macro to a hook. 9767 9768 9769File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: poly_int, Up: Top 9770 977111 GENERIC 9772********** 9773 9774The purpose of GENERIC is simply to provide a language-independent way 9775of representing an entire function in trees. To this end, it was 9776necessary to add a few new tree codes to the back end, but almost 9777everything was already there. If you can express it with the codes in 9778'gcc/tree.def', it's GENERIC. 9779 9780 Early on, there was a great deal of debate about how to think about 9781statements in a tree IL. In GENERIC, a statement is defined as any 9782expression whose value, if any, is ignored. A statement will always 9783have 'TREE_SIDE_EFFECTS' set (or it will be discarded), but a 9784non-statement expression may also have side effects. A 'CALL_EXPR', for 9785instance. 9786 9787 It would be possible for some local optimizations to work on the 9788GENERIC form of a function; indeed, the adapted tree inliner works fine 9789on GENERIC, but the current compiler performs inlining after lowering to 9790GIMPLE (a restricted form described in the next section). Indeed, 9791currently the frontends perform this lowering before handing off to 9792'tree_rest_of_compilation', but this seems inelegant. 9793 9794* Menu: 9795 9796* Deficiencies:: Topics net yet covered in this document. 9797* Tree overview:: All about 'tree's. 9798* Types:: Fundamental and aggregate types. 9799* Declarations:: Type declarations and variables. 9800* Attributes:: Declaration and type attributes. 9801* Expressions: Expression trees. Operating on data. 9802* Statements:: Control flow and related trees. 9803* Functions:: Function bodies, linkage, and other aspects. 9804* Language-dependent trees:: Topics and trees specific to language front ends. 9805* C and C++ Trees:: Trees specific to C and C++. 9806 9807 9808File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC 9809 981011.1 Deficiencies 9811================= 9812 9813There are many places in which this document is incomplet and incorrekt. 9814It is, as of yet, only _preliminary_ documentation. 9815 9816 9817File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC 9818 981911.2 Overview 9820============= 9821 9822The central data structure used by the internal representation is the 9823'tree'. These nodes, while all of the C type 'tree', are of many 9824varieties. A 'tree' is a pointer type, but the object to which it 9825points may be of a variety of types. From this point forward, we will 9826refer to trees in ordinary type, rather than in 'this font', except when 9827talking about the actual C type 'tree'. 9828 9829 You can tell what kind of node a particular tree is by using the 9830'TREE_CODE' macro. Many, many macros take trees as input and return 9831trees as output. However, most macros require a certain kind of tree 9832node as input. In other words, there is a type-system for trees, but it 9833is not reflected in the C type-system. 9834 9835 For safety, it is useful to configure GCC with '--enable-checking'. 9836Although this results in a significant performance penalty (since all 9837tree types are checked at run-time), and is therefore inappropriate in a 9838release version, it is extremely helpful during the development process. 9839 9840 Many macros behave as predicates. Many, although not all, of these 9841predicates end in '_P'. Do not rely on the result type of these macros 9842being of any particular type. You may, however, rely on the fact that 9843the type can be compared to '0', so that statements like 9844 if (TEST_P (t) && !TEST_P (y)) 9845 x = 1; 9846and 9847 int i = (TEST_P (t) != 0); 9848are legal. Macros that return 'int' values now may be changed to return 9849'tree' values, or other pointers in the future. Even those that 9850continue to return 'int' may return multiple nonzero codes where 9851previously they returned only zero and one. Therefore, you should not 9852write code like 9853 if (TEST_P (t) == 1) 9854as this code is not guaranteed to work correctly in the future. 9855 9856 You should not take the address of values returned by the macros or 9857functions described here. In particular, no guarantee is given that the 9858values are lvalues. 9859 9860 In general, the names of macros are all in uppercase, while the names 9861of functions are entirely in lowercase. There are rare exceptions to 9862this rule. You should assume that any macro or function whose name is 9863made up entirely of uppercase letters may evaluate its arguments more 9864than once. You may assume that a macro or function whose name is made 9865up entirely of lowercase letters will evaluate its arguments only once. 9866 9867 The 'error_mark_node' is a special tree. Its tree code is 9868'ERROR_MARK', but since there is only ever one node with that code, the 9869usual practice is to compare the tree against 'error_mark_node'. (This 9870test is just a test for pointer equality.) If an error has occurred 9871during front-end processing the flag 'errorcount' will be set. If the 9872front end has encountered code it cannot handle, it will issue a message 9873to the user and set 'sorrycount'. When these flags are set, any macro 9874or function which normally returns a tree of a particular kind may 9875instead return the 'error_mark_node'. Thus, if you intend to do any 9876processing of erroneous code, you must be prepared to deal with the 9877'error_mark_node'. 9878 9879 Occasionally, a particular tree slot (like an operand to an expression, 9880or a particular field in a declaration) will be referred to as "reserved 9881for the back end". These slots are used to store RTL when the tree is 9882converted to RTL for use by the GCC back end. However, if that process 9883is not taking place (e.g., if the front end is being hooked up to an 9884intelligent editor), then those slots may be used by the back end 9885presently in use. 9886 9887 If you encounter situations that do not match this documentation, such 9888as tree nodes of types not mentioned here, or macros documented to 9889return entities of a particular kind that instead return entities of 9890some different kind, you have found a bug, either in the front end or in 9891the documentation. Please report these bugs as you would any other bug. 9892 9893* Menu: 9894 9895* Macros and Functions::Macros and functions that can be used with all trees. 9896* Identifiers:: The names of things. 9897* Containers:: Lists and vectors. 9898 9899 9900File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 9901 990211.2.1 Trees 9903------------ 9904 9905All GENERIC trees have two fields in common. First, 'TREE_CHAIN' is a 9906pointer that can be used as a singly-linked list to other trees. The 9907other is 'TREE_TYPE'. Many trees store the type of an expression or 9908declaration in this field. 9909 9910 These are some other functions for handling trees: 9911 9912'tree_size' 9913 Return the number of bytes a tree takes. 9914 9915'build0' 9916'build1' 9917'build2' 9918'build3' 9919'build4' 9920'build5' 9921'build6' 9922 9923 These functions build a tree and supply values to put in each 9924 parameter. The basic signature is 'code, type, [operands]'. 9925 'code' is the 'TREE_CODE', and 'type' is a tree representing the 9926 'TREE_TYPE'. These are followed by the operands, each of which is 9927 also a tree. 9928 9929 9930File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 9931 993211.2.2 Identifiers 9933------------------ 9934 9935An 'IDENTIFIER_NODE' represents a slightly more general concept than the 9936standard C or C++ concept of identifier. In particular, an 9937'IDENTIFIER_NODE' may contain a '$', or other extraordinary characters. 9938 9939 There are never two distinct 'IDENTIFIER_NODE's representing the same 9940identifier. Therefore, you may use pointer equality to compare 9941'IDENTIFIER_NODE's, rather than using a routine like 'strcmp'. Use 9942'get_identifier' to obtain the unique 'IDENTIFIER_NODE' for a supplied 9943string. 9944 9945 You can use the following macros to access identifiers: 9946'IDENTIFIER_POINTER' 9947 The string represented by the identifier, represented as a 'char*'. 9948 This string is always 'NUL'-terminated, and contains no embedded 9949 'NUL' characters. 9950 9951'IDENTIFIER_LENGTH' 9952 The length of the string returned by 'IDENTIFIER_POINTER', not 9953 including the trailing 'NUL'. This value of 'IDENTIFIER_LENGTH 9954 (x)' is always the same as 'strlen (IDENTIFIER_POINTER (x))'. 9955 9956'IDENTIFIER_OPNAME_P' 9957 This predicate holds if the identifier represents the name of an 9958 overloaded operator. In this case, you should not depend on the 9959 contents of either the 'IDENTIFIER_POINTER' or the 9960 'IDENTIFIER_LENGTH'. 9961 9962'IDENTIFIER_TYPENAME_P' 9963 This predicate holds if the identifier represents the name of a 9964 user-defined conversion operator. In this case, the 'TREE_TYPE' of 9965 the 'IDENTIFIER_NODE' holds the type to which the conversion 9966 operator converts. 9967 9968 9969File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 9970 997111.2.3 Containers 9972----------------- 9973 9974Two common container data structures can be represented directly with 9975tree nodes. A 'TREE_LIST' is a singly linked list containing two trees 9976per node. These are the 'TREE_PURPOSE' and 'TREE_VALUE' of each node. 9977(Often, the 'TREE_PURPOSE' contains some kind of tag, or additional 9978information, while the 'TREE_VALUE' contains the majority of the 9979payload. In other cases, the 'TREE_PURPOSE' is simply 'NULL_TREE', 9980while in still others both the 'TREE_PURPOSE' and 'TREE_VALUE' are of 9981equal stature.) Given one 'TREE_LIST' node, the next node is found by 9982following the 'TREE_CHAIN'. If the 'TREE_CHAIN' is 'NULL_TREE', then 9983you have reached the end of the list. 9984 9985 A 'TREE_VEC' is a simple vector. The 'TREE_VEC_LENGTH' is an integer 9986(not a tree) giving the number of nodes in the vector. The nodes 9987themselves are accessed using the 'TREE_VEC_ELT' macro, which takes two 9988arguments. The first is the 'TREE_VEC' in question; the second is an 9989integer indicating which element in the vector is desired. The elements 9990are indexed from zero. 9991 9992 9993File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC 9994 999511.3 Types 9996========== 9997 9998All types have corresponding tree nodes. However, you should not assume 9999that there is exactly one tree node corresponding to each type. There 10000are often multiple nodes corresponding to the same type. 10001 10002 For the most part, different kinds of types have different tree codes. 10003(For example, pointer types use a 'POINTER_TYPE' code while arrays use 10004an 'ARRAY_TYPE' code.) However, pointers to member functions use the 10005'RECORD_TYPE' code. Therefore, when writing a 'switch' statement that 10006depends on the code associated with a particular type, you should take 10007care to handle pointers to member functions under the 'RECORD_TYPE' case 10008label. 10009 10010 The following functions and macros deal with cv-qualification of types: 10011'TYPE_MAIN_VARIANT' 10012 This macro returns the unqualified version of a type. It may be 10013 applied to an unqualified type, but it is not always the identity 10014 function in that case. 10015 10016 A few other macros and functions are usable with all types: 10017'TYPE_SIZE' 10018 The number of bits required to represent the type, represented as 10019 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 10020 'NULL_TREE'. 10021 10022'TYPE_ALIGN' 10023 The alignment of the type, in bits, represented as an 'int'. 10024 10025'TYPE_NAME' 10026 This macro returns a declaration (in the form of a 'TYPE_DECL') for 10027 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 10028 as you might expect, given its name!) You can look at the 10029 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 10030 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 10031 built-in type, the result of a typedef, or a named class type. 10032 10033'TYPE_CANONICAL' 10034 This macro returns the "canonical" type for the given type node. 10035 Canonical types are used to improve performance in the C++ and 10036 Objective-C++ front ends by allowing efficient comparison between 10037 two type nodes in 'same_type_p': if the 'TYPE_CANONICAL' values of 10038 the types are equal, the types are equivalent; otherwise, the types 10039 are not equivalent. The notion of equivalence for canonical types 10040 is the same as the notion of type equivalence in the language 10041 itself. For instance, 10042 10043 When 'TYPE_CANONICAL' is 'NULL_TREE', there is no canonical type 10044 for the given type node. In this case, comparison between this 10045 type and any other type requires the compiler to perform a deep, 10046 "structural" comparison to see if the two type nodes have the same 10047 form and properties. 10048 10049 The canonical type for a node is always the most fundamental type 10050 in the equivalence class of types. For instance, 'int' is its own 10051 canonical type. A typedef 'I' of 'int' will have 'int' as its 10052 canonical type. Similarly, 'I*' and a typedef 'IP' (defined to 10053 'I*') will has 'int*' as their canonical type. When building a new 10054 type node, be sure to set 'TYPE_CANONICAL' to the appropriate 10055 canonical type. If the new type is a compound type (built from 10056 other types), and any of those other types require structural 10057 equality, use 'SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the new 10058 type also requires structural equality. Finally, if for some 10059 reason you cannot guarantee that 'TYPE_CANONICAL' will point to the 10060 canonical type, use 'SET_TYPE_STRUCTURAL_EQUALITY' to make sure 10061 that the new type-and any type constructed based on it-requires 10062 structural equality. If you suspect that the canonical type system 10063 is miscomparing types, pass '--param verify-canonical-types=1' to 10064 the compiler or configure with '--enable-checking' to force the 10065 compiler to verify its canonical-type comparisons against the 10066 structural comparisons; the compiler will then print any warnings 10067 if the canonical types miscompare. 10068 10069'TYPE_STRUCTURAL_EQUALITY_P' 10070 This predicate holds when the node requires structural equality 10071 checks, e.g., when 'TYPE_CANONICAL' is 'NULL_TREE'. 10072 10073'SET_TYPE_STRUCTURAL_EQUALITY' 10074 This macro states that the type node it is given requires 10075 structural equality checks, e.g., it sets 'TYPE_CANONICAL' to 10076 'NULL_TREE'. 10077 10078'same_type_p' 10079 This predicate takes two types as input, and holds if they are the 10080 same type. For example, if one type is a 'typedef' for the other, 10081 or both are 'typedef's for the same type. This predicate also 10082 holds if the two trees given as input are simply copies of one 10083 another; i.e., there is no difference between them at the source 10084 level, but, for whatever reason, a duplicate has been made in the 10085 representation. You should never use '==' (pointer equality) to 10086 compare types; always use 'same_type_p' instead. 10087 10088 Detailed below are the various kinds of types, and the macros that can 10089be used to access them. Although other kinds of types are used 10090elsewhere in G++, the types described here are the only ones that you 10091will encounter while examining the intermediate representation. 10092 10093'VOID_TYPE' 10094 Used to represent the 'void' type. 10095 10096'INTEGER_TYPE' 10097 Used to represent the various integral types, including 'char', 10098 'short', 'int', 'long', and 'long long'. This code is not used for 10099 enumeration types, nor for the 'bool' type. The 'TYPE_PRECISION' 10100 is the number of bits used in the representation, represented as an 10101 'unsigned int'. (Note that in the general case this is not the 10102 same value as 'TYPE_SIZE'; suppose that there were a 24-bit integer 10103 type, but that alignment requirements for the ABI required 32-bit 10104 alignment. Then, 'TYPE_SIZE' would be an 'INTEGER_CST' for 32, 10105 while 'TYPE_PRECISION' would be 24.) The integer type is unsigned 10106 if 'TYPE_UNSIGNED' holds; otherwise, it is signed. 10107 10108 The 'TYPE_MIN_VALUE' is an 'INTEGER_CST' for the smallest integer 10109 that may be represented by this type. Similarly, the 10110 'TYPE_MAX_VALUE' is an 'INTEGER_CST' for the largest integer that 10111 may be represented by this type. 10112 10113'REAL_TYPE' 10114 Used to represent the 'float', 'double', and 'long double' types. 10115 The number of bits in the floating-point representation is given by 10116 'TYPE_PRECISION', as in the 'INTEGER_TYPE' case. 10117 10118'FIXED_POINT_TYPE' 10119 Used to represent the 'short _Fract', '_Fract', 'long _Fract', 10120 'long long _Fract', 'short _Accum', '_Accum', 'long _Accum', and 10121 'long long _Accum' types. The number of bits in the fixed-point 10122 representation is given by 'TYPE_PRECISION', as in the 10123 'INTEGER_TYPE' case. There may be padding bits, fractional bits 10124 and integral bits. The number of fractional bits is given by 10125 'TYPE_FBIT', and the number of integral bits is given by 10126 'TYPE_IBIT'. The fixed-point type is unsigned if 'TYPE_UNSIGNED' 10127 holds; otherwise, it is signed. The fixed-point type is saturating 10128 if 'TYPE_SATURATING' holds; otherwise, it is not saturating. 10129 10130'COMPLEX_TYPE' 10131 Used to represent GCC built-in '__complex__' data types. The 10132 'TREE_TYPE' is the type of the real and imaginary parts. 10133 10134'ENUMERAL_TYPE' 10135 Used to represent an enumeration type. The 'TYPE_PRECISION' gives 10136 (as an 'int'), the number of bits used to represent the type. If 10137 there are no negative enumeration constants, 'TYPE_UNSIGNED' will 10138 hold. The minimum and maximum enumeration constants may be 10139 obtained with 'TYPE_MIN_VALUE' and 'TYPE_MAX_VALUE', respectively; 10140 each of these macros returns an 'INTEGER_CST'. 10141 10142 The actual enumeration constants themselves may be obtained by 10143 looking at the 'TYPE_VALUES'. This macro will return a 10144 'TREE_LIST', containing the constants. The 'TREE_PURPOSE' of each 10145 node will be an 'IDENTIFIER_NODE' giving the name of the constant; 10146 the 'TREE_VALUE' will be an 'INTEGER_CST' giving the value assigned 10147 to that constant. These constants will appear in the order in 10148 which they were declared. The 'TREE_TYPE' of each of these 10149 constants will be the type of enumeration type itself. 10150 10151'OPAQUE_TYPE' 10152 Used for things that have a 'MODE_OPAQUE' mode class in the 10153 backend. Opaque types have a size and precision, and can be held 10154 in memory or registers. They are used when we do not want the 10155 compiler to make assumptions about the availability of other 10156 operations as would happen with integer types. 10157 10158'BOOLEAN_TYPE' 10159 Used to represent the 'bool' type. 10160 10161'POINTER_TYPE' 10162 Used to represent pointer types, and pointer to data member types. 10163 The 'TREE_TYPE' gives the type to which this type points. 10164 10165'REFERENCE_TYPE' 10166 Used to represent reference types. The 'TREE_TYPE' gives the type 10167 to which this type refers. 10168 10169'FUNCTION_TYPE' 10170 Used to represent the type of non-member functions and of static 10171 member functions. The 'TREE_TYPE' gives the return type of the 10172 function. The 'TYPE_ARG_TYPES' are a 'TREE_LIST' of the argument 10173 types. The 'TREE_VALUE' of each node in this list is the type of 10174 the corresponding argument; the 'TREE_PURPOSE' is an expression for 10175 the default argument value, if any. If the last node in the list 10176 is 'void_list_node' (a 'TREE_LIST' node whose 'TREE_VALUE' is the 10177 'void_type_node'), then functions of this type do not take variable 10178 arguments. Otherwise, they do take a variable number of arguments. 10179 10180 Note that in C (but not in C++) a function declared like 'void f()' 10181 is an unprototyped function taking a variable number of arguments; 10182 the 'TYPE_ARG_TYPES' of such a function will be 'NULL'. 10183 10184'METHOD_TYPE' 10185 Used to represent the type of a non-static member function. Like a 10186 'FUNCTION_TYPE', the return type is given by the 'TREE_TYPE'. The 10187 type of '*this', i.e., the class of which functions of this type 10188 are a member, is given by the 'TYPE_METHOD_BASETYPE'. The 10189 'TYPE_ARG_TYPES' is the parameter list, as for a 'FUNCTION_TYPE', 10190 and includes the 'this' argument. 10191 10192'ARRAY_TYPE' 10193 Used to represent array types. The 'TREE_TYPE' gives the type of 10194 the elements in the array. If the array-bound is present in the 10195 type, the 'TYPE_DOMAIN' is an 'INTEGER_TYPE' whose 'TYPE_MIN_VALUE' 10196 and 'TYPE_MAX_VALUE' will be the lower and upper bounds of the 10197 array, respectively. The 'TYPE_MIN_VALUE' will always be an 10198 'INTEGER_CST' for zero, while the 'TYPE_MAX_VALUE' will be one less 10199 than the number of elements in the array, i.e., the highest value 10200 which may be used to index an element in the array. 10201 10202'RECORD_TYPE' 10203 Used to represent 'struct' and 'class' types, as well as pointers 10204 to member functions and similar constructs in other languages. 10205 'TYPE_FIELDS' contains the items contained in this type, each of 10206 which can be a 'FIELD_DECL', 'VAR_DECL', 'CONST_DECL', or 10207 'TYPE_DECL'. You may not make any assumptions about the ordering 10208 of the fields in the type or whether one or more of them overlap. 10209 10210'UNION_TYPE' 10211 Used to represent 'union' types. Similar to 'RECORD_TYPE' except 10212 that all 'FIELD_DECL' nodes in 'TYPE_FIELD' start at bit position 10213 zero. 10214 10215'QUAL_UNION_TYPE' 10216 Used to represent part of a variant record in Ada. Similar to 10217 'UNION_TYPE' except that each 'FIELD_DECL' has a 'DECL_QUALIFIER' 10218 field, which contains a boolean expression that indicates whether 10219 the field is present in the object. The type will only have one 10220 field, so each field's 'DECL_QUALIFIER' is only evaluated if none 10221 of the expressions in the previous fields in 'TYPE_FIELDS' are 10222 nonzero. Normally these expressions will reference a field in the 10223 outer object using a 'PLACEHOLDER_EXPR'. 10224 10225'LANG_TYPE' 10226 This node is used to represent a language-specific type. The front 10227 end must handle it. 10228 10229'OFFSET_TYPE' 10230 This node is used to represent a pointer-to-data member. For a 10231 data member 'X::m' the 'TYPE_OFFSET_BASETYPE' is 'X' and the 10232 'TREE_TYPE' is the type of 'm'. 10233 10234 There are variables whose values represent some of the basic types. 10235These include: 10236'void_type_node' 10237 A node for 'void'. 10238 10239'integer_type_node' 10240 A node for 'int'. 10241 10242'unsigned_type_node.' 10243 A node for 'unsigned int'. 10244 10245'char_type_node.' 10246 A node for 'char'. 10247It may sometimes be useful to compare one of these variables with a type 10248in hand, using 'same_type_p'. 10249 10250 10251File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC 10252 1025311.4 Declarations 10254================= 10255 10256This section covers the various kinds of declarations that appear in the 10257internal representation, except for declarations of functions 10258(represented by 'FUNCTION_DECL' nodes), which are described in *note 10259Functions::. 10260 10261* Menu: 10262 10263* Working with declarations:: Macros and functions that work on 10264declarations. 10265* Internal structure:: How declaration nodes are represented. 10266 10267 10268File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 10269 1027011.4.1 Working with declarations 10271-------------------------------- 10272 10273Some macros can be used with any kind of declaration. These include: 10274'DECL_NAME' 10275 This macro returns an 'IDENTIFIER_NODE' giving the name of the 10276 entity. 10277 10278'TREE_TYPE' 10279 This macro returns the type of the entity declared. 10280 10281'EXPR_FILENAME' 10282 This macro returns the name of the file in which the entity was 10283 declared, as a 'char*'. For an entity declared implicitly by the 10284 compiler (like '__builtin_memcpy'), this will be the string 10285 '"<internal>"'. 10286 10287'EXPR_LINENO' 10288 This macro returns the line number at which the entity was 10289 declared, as an 'int'. 10290 10291'DECL_ARTIFICIAL' 10292 This predicate holds if the declaration was implicitly generated by 10293 the compiler. For example, this predicate will hold of an 10294 implicitly declared member function, or of the 'TYPE_DECL' 10295 implicitly generated for a class type. Recall that in C++ code 10296 like: 10297 struct S {}; 10298 is roughly equivalent to C code like: 10299 struct S {}; 10300 typedef struct S S; 10301 The implicitly generated 'typedef' declaration is represented by a 10302 'TYPE_DECL' for which 'DECL_ARTIFICIAL' holds. 10303 10304 The various kinds of declarations include: 10305'LABEL_DECL' 10306 These nodes are used to represent labels in function bodies. For 10307 more information, see *note Functions::. These nodes only appear 10308 in block scopes. 10309 10310'CONST_DECL' 10311 These nodes are used to represent enumeration constants. The value 10312 of the constant is given by 'DECL_INITIAL' which will be an 10313 'INTEGER_CST' with the same type as the 'TREE_TYPE' of the 10314 'CONST_DECL', i.e., an 'ENUMERAL_TYPE'. 10315 10316'RESULT_DECL' 10317 These nodes represent the value returned by a function. When a 10318 value is assigned to a 'RESULT_DECL', that indicates that the value 10319 should be returned, via bitwise copy, by the function. You can use 10320 'DECL_SIZE' and 'DECL_ALIGN' on a 'RESULT_DECL', just as with a 10321 'VAR_DECL'. 10322 10323'TYPE_DECL' 10324 These nodes represent 'typedef' declarations. The 'TREE_TYPE' is 10325 the type declared to have the name given by 'DECL_NAME'. In some 10326 cases, there is no associated name. 10327 10328'VAR_DECL' 10329 These nodes represent variables with namespace or block scope, as 10330 well as static data members. The 'DECL_SIZE' and 'DECL_ALIGN' are 10331 analogous to 'TYPE_SIZE' and 'TYPE_ALIGN'. For a declaration, you 10332 should always use the 'DECL_SIZE' and 'DECL_ALIGN' rather than the 10333 'TYPE_SIZE' and 'TYPE_ALIGN' given by the 'TREE_TYPE', since 10334 special attributes may have been applied to the variable to give it 10335 a particular size and alignment. You may use the predicates 10336 'DECL_THIS_STATIC' or 'DECL_THIS_EXTERN' to test whether the 10337 storage class specifiers 'static' or 'extern' were used to declare 10338 a variable. 10339 10340 If this variable is initialized (but does not require a 10341 constructor), the 'DECL_INITIAL' will be an expression for the 10342 initializer. The initializer should be evaluated, and a bitwise 10343 copy into the variable performed. If the 'DECL_INITIAL' is the 10344 'error_mark_node', there is an initializer, but it is given by an 10345 explicit statement later in the code; no bitwise copy is required. 10346 10347 GCC provides an extension that allows either automatic variables, 10348 or global variables, to be placed in particular registers. This 10349 extension is being used for a particular 'VAR_DECL' if 10350 'DECL_REGISTER' holds for the 'VAR_DECL', and if 10351 'DECL_ASSEMBLER_NAME' is not equal to 'DECL_NAME'. In that case, 10352 'DECL_ASSEMBLER_NAME' is the name of the register into which the 10353 variable will be placed. 10354 10355'PARM_DECL' 10356 Used to represent a parameter to a function. Treat these nodes 10357 similarly to 'VAR_DECL' nodes. These nodes only appear in the 10358 'DECL_ARGUMENTS' for a 'FUNCTION_DECL'. 10359 10360 The 'DECL_ARG_TYPE' for a 'PARM_DECL' is the type that will 10361 actually be used when a value is passed to this function. It may 10362 be a wider type than the 'TREE_TYPE' of the parameter; for example, 10363 the ordinary type might be 'short' while the 'DECL_ARG_TYPE' is 10364 'int'. 10365 10366'DEBUG_EXPR_DECL' 10367 Used to represent an anonymous debug-information temporary created 10368 to hold an expression as it is optimized away, so that its value 10369 can be referenced in debug bind statements. 10370 10371'FIELD_DECL' 10372 These nodes represent non-static data members. The 'DECL_SIZE' and 10373 'DECL_ALIGN' behave as for 'VAR_DECL' nodes. The position of the 10374 field within the parent record is specified by a combination of 10375 three attributes. 'DECL_FIELD_OFFSET' is the position, counting in 10376 bytes, of the 'DECL_OFFSET_ALIGN'-bit sized word containing the bit 10377 of the field closest to the beginning of the structure. 10378 'DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 10379 field within this word; this may be nonzero even for fields that 10380 are not bit-fields, since 'DECL_OFFSET_ALIGN' may be greater than 10381 the natural alignment of the field's type. 10382 10383 If 'DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 10384 bit-field, 'DECL_BIT_FIELD_TYPE' also contains the type that was 10385 originally specified for it, while DECL_TYPE may be a modified type 10386 with lesser precision, according to the size of the bit field. 10387 10388'NAMESPACE_DECL' 10389 Namespaces provide a name hierarchy for other declarations. They 10390 appear in the 'DECL_CONTEXT' of other '_DECL' nodes. 10391 10392 10393File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 10394 1039511.4.2 Internal structure 10396------------------------- 10397 10398'DECL' nodes are represented internally as a hierarchy of structures. 10399 10400* Menu: 10401 10402* Current structure hierarchy:: The current DECL node structure 10403hierarchy. 10404* Adding new DECL node types:: How to add a new DECL node to a 10405frontend. 10406 10407 10408File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 10409 1041011.4.2.1 Current structure hierarchy 10411.................................... 10412 10413'struct tree_decl_minimal' 10414 This is the minimal structure to inherit from in order for common 10415 'DECL' macros to work. The fields it contains are a unique ID, 10416 source location, context, and name. 10417 10418'struct tree_decl_common' 10419 This structure inherits from 'struct tree_decl_minimal'. It 10420 contains fields that most 'DECL' nodes need, such as a field to 10421 store alignment, machine mode, size, and attributes. 10422 10423'struct tree_field_decl' 10424 This structure inherits from 'struct tree_decl_common'. It is used 10425 to represent 'FIELD_DECL'. 10426 10427'struct tree_label_decl' 10428 This structure inherits from 'struct tree_decl_common'. It is used 10429 to represent 'LABEL_DECL'. 10430 10431'struct tree_translation_unit_decl' 10432 This structure inherits from 'struct tree_decl_common'. It is used 10433 to represent 'TRANSLATION_UNIT_DECL'. 10434 10435'struct tree_decl_with_rtl' 10436 This structure inherits from 'struct tree_decl_common'. It 10437 contains a field to store the low-level RTL associated with a 10438 'DECL' node. 10439 10440'struct tree_result_decl' 10441 This structure inherits from 'struct tree_decl_with_rtl'. It is 10442 used to represent 'RESULT_DECL'. 10443 10444'struct tree_const_decl' 10445 This structure inherits from 'struct tree_decl_with_rtl'. It is 10446 used to represent 'CONST_DECL'. 10447 10448'struct tree_parm_decl' 10449 This structure inherits from 'struct tree_decl_with_rtl'. It is 10450 used to represent 'PARM_DECL'. 10451 10452'struct tree_decl_with_vis' 10453 This structure inherits from 'struct tree_decl_with_rtl'. It 10454 contains fields necessary to store visibility information, as well 10455 as a section name and assembler name. 10456 10457'struct tree_var_decl' 10458 This structure inherits from 'struct tree_decl_with_vis'. It is 10459 used to represent 'VAR_DECL'. 10460 10461'struct tree_function_decl' 10462 This structure inherits from 'struct tree_decl_with_vis'. It is 10463 used to represent 'FUNCTION_DECL'. 10464 10465 10466File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 10467 1046811.4.2.2 Adding new DECL node types 10469................................... 10470 10471Adding a new 'DECL' tree consists of the following steps 10472 10473Add a new tree code for the 'DECL' node 10474 For language specific 'DECL' nodes, there is a '.def' file in each 10475 frontend directory where the tree code should be added. For 'DECL' 10476 nodes that are part of the middle-end, the code should be added to 10477 'tree.def'. 10478 10479Create a new structure type for the 'DECL' node 10480 These structures should inherit from one of the existing structures 10481 in the language hierarchy by using that structure as the first 10482 member. 10483 10484 struct tree_foo_decl 10485 { 10486 struct tree_decl_with_vis common; 10487 } 10488 10489 Would create a structure name 'tree_foo_decl' that inherits from 10490 'struct tree_decl_with_vis'. 10491 10492 For language specific 'DECL' nodes, this new structure type should 10493 go in the appropriate '.h' file. For 'DECL' nodes that are part of 10494 the middle-end, the structure type should go in 'tree.h'. 10495 10496Add a member to the tree structure enumerator for the node 10497 For garbage collection and dynamic checking purposes, each 'DECL' 10498 node structure type is required to have a unique enumerator value 10499 specified with it. For language specific 'DECL' nodes, this new 10500 enumerator value should go in the appropriate '.def' file. For 10501 'DECL' nodes that are part of the middle-end, the enumerator values 10502 are specified in 'treestruct.def'. 10503 10504Update 'union tree_node' 10505 In order to make your new structure type usable, it must be added 10506 to 'union tree_node'. For language specific 'DECL' nodes, a new 10507 entry should be added to the appropriate '.h' file of the form 10508 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 10509 For 'DECL' nodes that are part of the middle-end, the additional 10510 member goes directly into 'union tree_node' in 'tree.h'. 10511 10512Update dynamic checking info 10513 In order to be able to check whether accessing a named portion of 10514 'union tree_node' is legal, and whether a certain 'DECL' node 10515 contains one of the enumerated 'DECL' node structures in the 10516 hierarchy, a simple lookup table is used. This lookup table needs 10517 to be kept up to date with the tree structure hierarchy, or else 10518 checking and containment macros will fail inappropriately. 10519 10520 For language specific 'DECL' nodes, there is an 'init_ts' function 10521 in an appropriate '.c' file, which initializes the lookup table. 10522 Code setting up the table for new 'DECL' nodes should be added 10523 there. For each 'DECL' tree code and enumerator value representing 10524 a member of the inheritance hierarchy, the table should contain 1 10525 if that tree code inherits (directly or indirectly) from that 10526 member. Thus, a 'FOO_DECL' node derived from 'struct 10527 decl_with_rtl', and enumerator value 'TS_FOO_DECL', would be set up 10528 as follows 10529 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 10530 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 10531 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 10532 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 10533 10534 For 'DECL' nodes that are part of the middle-end, the setup code 10535 goes into 'tree.c'. 10536 10537Add macros to access any new fields and flags 10538 10539 Each added field or flag should have a macro that is used to access 10540 it, that performs appropriate checking to ensure only the right 10541 type of 'DECL' nodes access the field. 10542 10543 These macros generally take the following form 10544 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 10545 However, if the structure is simply a base class for further 10546 structures, something like the following should be used 10547 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 10548 #define BASE_STRUCT_FIELDNAME(NODE) \ 10549 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 10550 10551 Reading them from the generated 'all-tree.def' file (which in turn 10552 includes all the 'tree.def' files), 'gencheck.c' is used during 10553 GCC's build to generate the '*_CHECK' macros for all tree codes. 10554 10555 10556File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC 10557 1055811.5 Attributes in trees 10559======================== 10560 10561Attributes, as specified using the '__attribute__' keyword, are 10562represented internally as a 'TREE_LIST'. The 'TREE_PURPOSE' is the name 10563of the attribute, as an 'IDENTIFIER_NODE'. The 'TREE_VALUE' is a 10564'TREE_LIST' of the arguments of the attribute, if any, or 'NULL_TREE' if 10565there are no arguments; the arguments are stored as the 'TREE_VALUE' of 10566successive entries in the list, and may be identifiers or expressions. 10567The 'TREE_CHAIN' of the attribute is the next attribute in a list of 10568attributes applying to the same declaration or type, or 'NULL_TREE' if 10569there are no further attributes in the list. 10570 10571 Attributes may be attached to declarations and to types; these 10572attributes may be accessed with the following macros. All attributes 10573are stored in this way, and many also cause other changes to the 10574declaration or type or to other internal compiler data structures. 10575 10576 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 10577 This macro returns the attributes on the declaration DECL. 10578 10579 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 10580 This macro returns the attributes on the type TYPE. 10581 10582 10583File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC 10584 1058511.6 Expressions 10586================ 10587 10588The internal representation for expressions is for the most part quite 10589straightforward. However, there are a few facts that one must bear in 10590mind. In particular, the expression "tree" is actually a directed 10591acyclic graph. (For example there may be many references to the integer 10592constant zero throughout the source program; many of these will be 10593represented by the same expression node.) You should not rely on 10594certain kinds of node being shared, nor should you rely on certain kinds 10595of nodes being unshared. 10596 10597 The following macros can be used with all expression nodes: 10598 10599'TREE_TYPE' 10600 Returns the type of the expression. This value may not be 10601 precisely the same type that would be given the expression in the 10602 original program. 10603 10604 In what follows, some nodes that one might expect to always have type 10605'bool' are documented to have either integral or boolean type. At some 10606point in the future, the C front end may also make use of this same 10607intermediate representation, and at this point these nodes will 10608certainly have integral type. The previous sentence is not meant to 10609imply that the C++ front end does not or will not give these nodes 10610integral type. 10611 10612 Below, we list the various kinds of expression nodes. Except where 10613noted otherwise, the operands to an expression are accessed using the 10614'TREE_OPERAND' macro. For example, to access the first operand to a 10615binary plus expression 'expr', use: 10616 10617 TREE_OPERAND (expr, 0) 10618 10619 As this example indicates, the operands are zero-indexed. 10620 10621* Menu: 10622 10623* Constants: Constant expressions. 10624* Storage References:: 10625* Unary and Binary Expressions:: 10626* Vectors:: 10627 10628 10629File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees 10630 1063111.6.1 Constant expressions 10632--------------------------- 10633 10634The table below begins with constants, moves on to unary expressions, 10635then proceeds to binary expressions, and concludes with various other 10636kinds of expressions: 10637 10638'INTEGER_CST' 10639 These nodes represent integer constants. Note that the type of 10640 these constants is obtained with 'TREE_TYPE'; they are not always 10641 of type 'int'. In particular, 'char' constants are represented 10642 with 'INTEGER_CST' nodes. The value of the integer constant 'e' is 10643 represented in an array of HOST_WIDE_INT. There are enough elements 10644 in the array to represent the value without taking extra elements 10645 for redundant 0s or -1. The number of elements used to represent 10646 'e' is available via 'TREE_INT_CST_NUNITS'. Element 'i' can be 10647 extracted by using 'TREE_INT_CST_ELT (e, i)'. 'TREE_INT_CST_LOW' 10648 is a shorthand for 'TREE_INT_CST_ELT (e, 0)'. 10649 10650 The functions 'tree_fits_shwi_p' and 'tree_fits_uhwi_p' can be used 10651 to tell if the value is small enough to fit in a signed 10652 HOST_WIDE_INT or an unsigned HOST_WIDE_INT respectively. The value 10653 can then be extracted using 'tree_to_shwi' and 'tree_to_uhwi'. 10654 10655'REAL_CST' 10656 10657 FIXME: Talk about how to obtain representations of this constant, 10658 do comparisons, and so forth. 10659 10660'FIXED_CST' 10661 10662 These nodes represent fixed-point constants. The type of these 10663 constants is obtained with 'TREE_TYPE'. 'TREE_FIXED_CST_PTR' 10664 points to a 'struct fixed_value'; 'TREE_FIXED_CST' returns the 10665 structure itself. 'struct fixed_value' contains 'data' with the 10666 size of two 'HOST_BITS_PER_WIDE_INT' and 'mode' as the associated 10667 fixed-point machine mode for 'data'. 10668 10669'COMPLEX_CST' 10670 These nodes are used to represent complex number constants, that is 10671 a '__complex__' whose parts are constant nodes. The 10672 'TREE_REALPART' and 'TREE_IMAGPART' return the real and the 10673 imaginary parts respectively. 10674 10675'VECTOR_CST' 10676 These nodes are used to represent vector constants. Each vector 10677 constant V is treated as a specific instance of an arbitrary-length 10678 sequence that itself contains 'VECTOR_CST_NPATTERNS (V)' 10679 interleaved patterns. Each pattern has the form: 10680 10681 { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... } 10682 10683 The first three elements in each pattern are enough to determine 10684 the values of the other elements. However, if all STEPs are zero, 10685 only the first two elements are needed. If in addition each BASE1 10686 is equal to the corresponding BASE0, only the first element in each 10687 pattern is needed. The number of encoded elements per pattern is 10688 given by 'VECTOR_CST_NELTS_PER_PATTERN (V)'. 10689 10690 For example, the constant: 10691 10692 { 0, 1, 2, 6, 3, 8, 4, 10, 5, 12, 6, 14, 7, 16, 8, 18 } 10693 10694 is interpreted as an interleaving of the sequences: 10695 10696 { 0, 2, 3, 4, 5, 6, 7, 8 } 10697 { 1, 6, 8, 10, 12, 14, 16, 18 } 10698 10699 where the sequences are represented by the following patterns: 10700 10701 BASE0 == 0, BASE1 == 2, STEP == 1 10702 BASE0 == 1, BASE1 == 6, STEP == 2 10703 10704 In this case: 10705 10706 VECTOR_CST_NPATTERNS (V) == 2 10707 VECTOR_CST_NELTS_PER_PATTERN (V) == 3 10708 10709 The vector is therefore encoded using the first 6 elements ('{ 0, 10710 1, 2, 6, 3, 8 }'), with the remaining 10 elements being implicit 10711 extensions of them. 10712 10713 Sometimes this scheme can create two possible encodings of the same 10714 vector. For example { 0, 1 } could be seen as two patterns with 10715 one element each or one pattern with two elements (BASE0 and 10716 BASE1). The canonical encoding is always the one with the fewest 10717 patterns or (if both encodings have the same number of petterns) 10718 the one with the fewest encoded elements. 10719 10720 'vector_cst_encoding_nelts (V)' gives the total number of encoded 10721 elements in V, which is 6 in the example above. 10722 'VECTOR_CST_ENCODED_ELTS (V)' gives a pointer to the elements 10723 encoded in V and 'VECTOR_CST_ENCODED_ELT (V, I)' accesses the value 10724 of encoded element I. 10725 10726 'VECTOR_CST_DUPLICATE_P (V)' is true if V simply contains repeated 10727 instances of 'VECTOR_CST_NPATTERNS (V)' values. This is a 10728 shorthand for testing 'VECTOR_CST_NELTS_PER_PATTERN (V) == 1'. 10729 10730 'VECTOR_CST_STEPPED_P (V)' is true if at least one pattern in V has 10731 a nonzero step. This is a shorthand for testing 10732 'VECTOR_CST_NELTS_PER_PATTERN (V) == 3'. 10733 10734 The utility function 'vector_cst_elt' gives the value of an 10735 arbitrary index as a 'tree'. 'vector_cst_int_elt' gives the same 10736 value as a 'wide_int'. 10737 10738'STRING_CST' 10739 These nodes represent string-constants. The 'TREE_STRING_LENGTH' 10740 returns the length of the string, as an 'int'. The 10741 'TREE_STRING_POINTER' is a 'char*' containing the string itself. 10742 The string may not be 'NUL'-terminated, and it may contain embedded 10743 'NUL' characters. Therefore, the 'TREE_STRING_LENGTH' includes the 10744 trailing 'NUL' if it is present. 10745 10746 For wide string constants, the 'TREE_STRING_LENGTH' is the number 10747 of bytes in the string, and the 'TREE_STRING_POINTER' points to an 10748 array of the bytes of the string, as represented on the target 10749 system (that is, as integers in the target endianness). Wide and 10750 non-wide string constants are distinguished only by the 'TREE_TYPE' 10751 of the 'STRING_CST'. 10752 10753 FIXME: The formats of string constants are not well-defined when 10754 the target system bytes are not the same width as host system 10755 bytes. 10756 10757'POLY_INT_CST' 10758 These nodes represent invariants that depend on some 10759 target-specific runtime parameters. They consist of 10760 'NUM_POLY_INT_COEFFS' coefficients, with the first coefficient 10761 being the constant term and the others being multipliers that are 10762 applied to the runtime parameters. 10763 10764 'POLY_INT_CST_ELT (X, I)' references coefficient number I of 10765 'POLY_INT_CST' node X. Each coefficient is an 'INTEGER_CST'. 10766 10767 10768File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees 10769 1077011.6.2 References to storage 10771---------------------------- 10772 10773'ARRAY_REF' 10774 These nodes represent array accesses. The first operand is the 10775 array; the second is the index. To calculate the address of the 10776 memory accessed, you must scale the index by the size of the type 10777 of the array elements. The type of these expressions must be the 10778 type of a component of the array. The third and fourth operands 10779 are used after gimplification to represent the lower bound and 10780 component size but should not be used directly; call 10781 'array_ref_low_bound' and 'array_ref_element_size' instead. 10782 10783'ARRAY_RANGE_REF' 10784 These nodes represent access to a range (or "slice") of an array. 10785 The operands are the same as that for 'ARRAY_REF' and have the same 10786 meanings. The type of these expressions must be an array whose 10787 component type is the same as that of the first operand. The range 10788 of that array type determines the amount of data these expressions 10789 access. 10790 10791'TARGET_MEM_REF' 10792 These nodes represent memory accesses whose address directly map to 10793 an addressing mode of the target architecture. The first argument 10794 is 'TMR_SYMBOL' and must be a 'VAR_DECL' of an object with a fixed 10795 address. The second argument is 'TMR_BASE' and the third one is 10796 'TMR_INDEX'. The fourth argument is 'TMR_STEP' and must be an 10797 'INTEGER_CST'. The fifth argument is 'TMR_OFFSET' and must be an 10798 'INTEGER_CST'. Any of the arguments may be NULL if the appropriate 10799 component does not appear in the address. Address of the 10800 'TARGET_MEM_REF' is determined in the following way. 10801 10802 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 10803 10804 The sixth argument is the reference to the original memory access, 10805 which is preserved for the purposes of the RTL alias analysis. The 10806 seventh argument is a tag representing the results of tree level 10807 alias analysis. 10808 10809'ADDR_EXPR' 10810 These nodes are used to represent the address of an object. (These 10811 expressions will always have pointer or reference type.) The 10812 operand may be another expression, or it may be a declaration. 10813 10814 As an extension, GCC allows users to take the address of a label. 10815 In this case, the operand of the 'ADDR_EXPR' will be a 10816 'LABEL_DECL'. The type of such an expression is 'void*'. 10817 10818 If the object addressed is not an lvalue, a temporary is created, 10819 and the address of the temporary is used. 10820 10821'INDIRECT_REF' 10822 These nodes are used to represent the object pointed to by a 10823 pointer. The operand is the pointer being dereferenced; it will 10824 always have pointer or reference type. 10825 10826'MEM_REF' 10827 These nodes are used to represent the object pointed to by a 10828 pointer offset by a constant. The first operand is the pointer 10829 being dereferenced; it will always have pointer or reference type. 10830 The second operand is a pointer constant. Its type is specifying 10831 the type to be used for type-based alias analysis. 10832 10833'COMPONENT_REF' 10834 These nodes represent non-static data member accesses. The first 10835 operand is the object (rather than a pointer to it); the second 10836 operand is the 'FIELD_DECL' for the data member. The third operand 10837 represents the byte offset of the field, but should not be used 10838 directly; call 'component_ref_field_offset' instead. 10839 10840 10841File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees 10842 1084311.6.3 Unary and Binary Expressions 10844----------------------------------- 10845 10846'NEGATE_EXPR' 10847 These nodes represent unary negation of the single operand, for 10848 both integer and floating-point types. The type of negation can be 10849 determined by looking at the type of the expression. 10850 10851 The behavior of this operation on signed arithmetic overflow is 10852 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10853 10854'ABS_EXPR' 10855 These nodes represent the absolute value of the single operand, for 10856 both integer and floating-point types. This is typically used to 10857 implement the 'abs', 'labs' and 'llabs' builtins for integer types, 10858 and the 'fabs', 'fabsf' and 'fabsl' builtins for floating point 10859 types. The type of abs operation can be determined by looking at 10860 the type of the expression. 10861 10862 This node is not used for complex types. To represent the modulus 10863 or complex abs of a complex value, use the 'BUILT_IN_CABS', 10864 'BUILT_IN_CABSF' or 'BUILT_IN_CABSL' builtins, as used to implement 10865 the C99 'cabs', 'cabsf' and 'cabsl' built-in functions. 10866 10867'ABSU_EXPR' 10868 These nodes represent the absolute value of the single operand in 10869 equivalent unsigned type such that 'ABSU_EXPR' of 'TYPE_MIN' is 10870 well defined. 10871 10872'BIT_NOT_EXPR' 10873 These nodes represent bitwise complement, and will always have 10874 integral type. The only operand is the value to be complemented. 10875 10876'TRUTH_NOT_EXPR' 10877 These nodes represent logical negation, and will always have 10878 integral (or boolean) type. The operand is the value being 10879 negated. The type of the operand and that of the result are always 10880 of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 10881 10882'PREDECREMENT_EXPR' 10883'PREINCREMENT_EXPR' 10884'POSTDECREMENT_EXPR' 10885'POSTINCREMENT_EXPR' 10886 These nodes represent increment and decrement expressions. The 10887 value of the single operand is computed, and the operand 10888 incremented or decremented. In the case of 'PREDECREMENT_EXPR' and 10889 'PREINCREMENT_EXPR', the value of the expression is the value 10890 resulting after the increment or decrement; in the case of 10891 'POSTDECREMENT_EXPR' and 'POSTINCREMENT_EXPR' is the value before 10892 the increment or decrement occurs. The type of the operand, like 10893 that of the result, will be either integral, boolean, or 10894 floating-point. 10895 10896'FIX_TRUNC_EXPR' 10897 These nodes represent conversion of a floating-point value to an 10898 integer. The single operand will have a floating-point type, while 10899 the complete expression will have an integral (or boolean) type. 10900 The operand is rounded towards zero. 10901 10902'FLOAT_EXPR' 10903 These nodes represent conversion of an integral (or boolean) value 10904 to a floating-point value. The single operand will have integral 10905 type, while the complete expression will have a floating-point 10906 type. 10907 10908 FIXME: How is the operand supposed to be rounded? Is this 10909 dependent on '-mieee'? 10910 10911'COMPLEX_EXPR' 10912 These nodes are used to represent complex numbers constructed from 10913 two expressions of the same (integer or real) type. The first 10914 operand is the real part and the second operand is the imaginary 10915 part. 10916 10917'CONJ_EXPR' 10918 These nodes represent the conjugate of their operand. 10919 10920'REALPART_EXPR' 10921'IMAGPART_EXPR' 10922 These nodes represent respectively the real and the imaginary parts 10923 of complex numbers (their sole argument). 10924 10925'NON_LVALUE_EXPR' 10926 These nodes indicate that their one and only operand is not an 10927 lvalue. A back end can treat these identically to the single 10928 operand. 10929 10930'NOP_EXPR' 10931 These nodes are used to represent conversions that do not require 10932 any code-generation. For example, conversion of a 'char*' to an 10933 'int*' does not require any code be generated; such a conversion is 10934 represented by a 'NOP_EXPR'. The single operand is the expression 10935 to be converted. The conversion from a pointer to a reference is 10936 also represented with a 'NOP_EXPR'. 10937 10938'CONVERT_EXPR' 10939 These nodes are similar to 'NOP_EXPR's, but are used in those 10940 situations where code may need to be generated. For example, if an 10941 'int*' is converted to an 'int' code may need to be generated on 10942 some platforms. These nodes are never used for C++-specific 10943 conversions, like conversions between pointers to different classes 10944 in an inheritance hierarchy. Any adjustments that need to be made 10945 in such cases are always indicated explicitly. Similarly, a 10946 user-defined conversion is never represented by a 'CONVERT_EXPR'; 10947 instead, the function calls are made explicit. 10948 10949'FIXED_CONVERT_EXPR' 10950 These nodes are used to represent conversions that involve 10951 fixed-point values. For example, from a fixed-point value to 10952 another fixed-point value, from an integer to a fixed-point value, 10953 from a fixed-point value to an integer, from a floating-point value 10954 to a fixed-point value, or from a fixed-point value to a 10955 floating-point value. 10956 10957'LSHIFT_EXPR' 10958'RSHIFT_EXPR' 10959 These nodes represent left and right shifts, respectively. The 10960 first operand is the value to shift; it will always be of integral 10961 type. The second operand is an expression for the number of bits 10962 by which to shift. Right shift should be treated as arithmetic, 10963 i.e., the high-order bits should be zero-filled when the expression 10964 has unsigned type and filled with the sign bit when the expression 10965 has signed type. Note that the result is undefined if the second 10966 operand is larger than or equal to the first operand's type size. 10967 Unlike most nodes, these can have a vector as first operand and a 10968 scalar as second operand. 10969 10970'BIT_IOR_EXPR' 10971'BIT_XOR_EXPR' 10972'BIT_AND_EXPR' 10973 These nodes represent bitwise inclusive or, bitwise exclusive or, 10974 and bitwise and, respectively. Both operands will always have 10975 integral type. 10976 10977'TRUTH_ANDIF_EXPR' 10978'TRUTH_ORIF_EXPR' 10979 These nodes represent logical "and" and logical "or", respectively. 10980 These operators are not strict; i.e., the second operand is 10981 evaluated only if the value of the expression is not determined by 10982 evaluation of the first operand. The type of the operands and that 10983 of the result are always of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 10984 10985'TRUTH_AND_EXPR' 10986'TRUTH_OR_EXPR' 10987'TRUTH_XOR_EXPR' 10988 These nodes represent logical and, logical or, and logical 10989 exclusive or. They are strict; both arguments are always 10990 evaluated. There are no corresponding operators in C or C++, but 10991 the front end will sometimes generate these expressions anyhow, if 10992 it can tell that strictness does not matter. The type of the 10993 operands and that of the result are always of 'BOOLEAN_TYPE' or 10994 'INTEGER_TYPE'. 10995 10996'POINTER_PLUS_EXPR' 10997 This node represents pointer arithmetic. The first operand is 10998 always a pointer/reference type. The second operand is always an 10999 unsigned integer type compatible with sizetype. This and 11000 POINTER_DIFF_EXPR are the only binary arithmetic operators that can 11001 operate on pointer types. 11002 11003'POINTER_DIFF_EXPR' 11004 This node represents pointer subtraction. The two operands always 11005 have pointer/reference type. It returns a signed integer of the 11006 same precision as the pointers. The behavior is undefined if the 11007 difference of the two pointers, seen as infinite precision 11008 non-negative integers, does not fit in the result type. The result 11009 does not depend on the pointer type, it is not divided by the size 11010 of the pointed-to type. 11011 11012'PLUS_EXPR' 11013'MINUS_EXPR' 11014'MULT_EXPR' 11015 These nodes represent various binary arithmetic operations. 11016 Respectively, these operations are addition, subtraction (of the 11017 second operand from the first) and multiplication. Their operands 11018 may have either integral or floating type, but there will never be 11019 case in which one operand is of floating type and the other is of 11020 integral type. 11021 11022 The behavior of these operations on signed arithmetic overflow is 11023 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 11024 11025'MULT_HIGHPART_EXPR' 11026 This node represents the "high-part" of a widening multiplication. 11027 For an integral type with B bits of precision, the result is the 11028 most significant B bits of the full 2B product. 11029 11030'RDIV_EXPR' 11031 This node represents a floating point division operation. 11032 11033'TRUNC_DIV_EXPR' 11034'FLOOR_DIV_EXPR' 11035'CEIL_DIV_EXPR' 11036'ROUND_DIV_EXPR' 11037 These nodes represent integer division operations that return an 11038 integer result. 'TRUNC_DIV_EXPR' rounds towards zero, 11039 'FLOOR_DIV_EXPR' rounds towards negative infinity, 'CEIL_DIV_EXPR' 11040 rounds towards positive infinity and 'ROUND_DIV_EXPR' rounds to the 11041 closest integer. Integer division in C and C++ is truncating, i.e. 11042 'TRUNC_DIV_EXPR'. 11043 11044 The behavior of these operations on signed arithmetic overflow, 11045 when dividing the minimum signed integer by minus one, is 11046 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 11047 11048'TRUNC_MOD_EXPR' 11049'FLOOR_MOD_EXPR' 11050'CEIL_MOD_EXPR' 11051'ROUND_MOD_EXPR' 11052 These nodes represent the integer remainder or modulus operation. 11053 The integer modulus of two operands 'a' and 'b' is defined as 'a - 11054 (a/b)*b' where the division calculated using the corresponding 11055 division operator. Hence for 'TRUNC_MOD_EXPR' this definition 11056 assumes division using truncation towards zero, i.e. 11057 'TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 11058 division, i.e. 'TRUNC_MOD_EXPR'. 11059 11060'EXACT_DIV_EXPR' 11061 The 'EXACT_DIV_EXPR' code is used to represent integer divisions 11062 where the numerator is known to be an exact multiple of the 11063 denominator. This allows the backend to choose between the faster 11064 of 'TRUNC_DIV_EXPR', 'CEIL_DIV_EXPR' and 'FLOOR_DIV_EXPR' for the 11065 current target. 11066 11067'LT_EXPR' 11068'LE_EXPR' 11069'GT_EXPR' 11070'GE_EXPR' 11071'LTGT_EXPR' 11072'EQ_EXPR' 11073'NE_EXPR' 11074 These nodes represent the less than, less than or equal to, greater 11075 than, greater than or equal to, less or greater than, equal, and 11076 not equal comparison operators. The first and second operands will 11077 either be both of integral type, both of floating type or both of 11078 vector type, except for LTGT_EXPR where they will only be both of 11079 floating type. The result type of these expressions will always be 11080 of integral, boolean or signed integral vector type. These 11081 operations return the result type's zero value for false, the 11082 result type's one value for true, and a vector whose elements are 11083 zero (false) or minus one (true) for vectors. 11084 11085 For floating point comparisons, if we honor IEEE NaNs and either 11086 operand is NaN, then 'NE_EXPR' always returns true and the 11087 remaining operators always return false. On some targets, 11088 comparisons against an IEEE NaN, other than equality and 11089 inequality, may generate a floating-point exception. 11090 11091'ORDERED_EXPR' 11092'UNORDERED_EXPR' 11093 These nodes represent non-trapping ordered and unordered comparison 11094 operators. These operations take two floating point operands and 11095 determine whether they are ordered or unordered relative to each 11096 other. If either operand is an IEEE NaN, their comparison is 11097 defined to be unordered, otherwise the comparison is defined to be 11098 ordered. The result type of these expressions will always be of 11099 integral or boolean type. These operations return the result 11100 type's zero value for false, and the result type's one value for 11101 true. 11102 11103'UNLT_EXPR' 11104'UNLE_EXPR' 11105'UNGT_EXPR' 11106'UNGE_EXPR' 11107'UNEQ_EXPR' 11108 These nodes represent the unordered comparison operators. These 11109 operations take two floating point operands and determine whether 11110 the operands are unordered or are less than, less than or equal to, 11111 greater than, greater than or equal to, or equal respectively. For 11112 example, 'UNLT_EXPR' returns true if either operand is an IEEE NaN 11113 or the first operand is less than the second. All these operations 11114 are guaranteed not to generate a floating point exception. The 11115 result type of these expressions will always be of integral or 11116 boolean type. These operations return the result type's zero value 11117 for false, and the result type's one value for true. 11118 11119'MODIFY_EXPR' 11120 These nodes represent assignment. The left-hand side is the first 11121 operand; the right-hand side is the second operand. The left-hand 11122 side will be a 'VAR_DECL', 'INDIRECT_REF', 'COMPONENT_REF', or 11123 other lvalue. 11124 11125 These nodes are used to represent not only assignment with '=' but 11126 also compound assignments (like '+='), by reduction to '=' 11127 assignment. In other words, the representation for 'i += 3' looks 11128 just like that for 'i = i + 3'. 11129 11130'INIT_EXPR' 11131 These nodes are just like 'MODIFY_EXPR', but are used only when a 11132 variable is initialized, rather than assigned to subsequently. 11133 This means that we can assume that the target of the initialization 11134 is not used in computing its own value; any reference to the lhs in 11135 computing the rhs is undefined. 11136 11137'COMPOUND_EXPR' 11138 These nodes represent comma-expressions. The first operand is an 11139 expression whose value is computed and thrown away prior to the 11140 evaluation of the second operand. The value of the entire 11141 expression is the value of the second operand. 11142 11143'COND_EXPR' 11144 These nodes represent '?:' expressions. The first operand is of 11145 boolean or integral type. If it evaluates to a nonzero value, the 11146 second operand should be evaluated, and returned as the value of 11147 the expression. Otherwise, the third operand is evaluated, and 11148 returned as the value of the expression. 11149 11150 The second operand must have the same type as the entire 11151 expression, unless it unconditionally throws an exception or calls 11152 a noreturn function, in which case it should have void type. The 11153 same constraints apply to the third operand. This allows array 11154 bounds checks to be represented conveniently as '(i >= 0 && i < 10) 11155 ? i : abort()'. 11156 11157 As a GNU extension, the C language front-ends allow the second 11158 operand of the '?:' operator may be omitted in the source. For 11159 example, 'x ? : 3' is equivalent to 'x ? x : 3', assuming that 'x' 11160 is an expression without side effects. In the tree representation, 11161 however, the second operand is always present, possibly protected 11162 by 'SAVE_EXPR' if the first argument does cause side effects. 11163 11164'CALL_EXPR' 11165 These nodes are used to represent calls to functions, including 11166 non-static member functions. 'CALL_EXPR's are implemented as 11167 expression nodes with a variable number of operands. Rather than 11168 using 'TREE_OPERAND' to extract them, it is preferable to use the 11169 specialized accessor macros and functions that operate specifically 11170 on 'CALL_EXPR' nodes. 11171 11172 'CALL_EXPR_FN' returns a pointer to the function to call; it is 11173 always an expression whose type is a 'POINTER_TYPE'. 11174 11175 The number of arguments to the call is returned by 11176 'call_expr_nargs', while the arguments themselves can be accessed 11177 with the 'CALL_EXPR_ARG' macro. The arguments are zero-indexed and 11178 numbered left-to-right. You can iterate over the arguments using 11179 'FOR_EACH_CALL_EXPR_ARG', as in: 11180 11181 tree call, arg; 11182 call_expr_arg_iterator iter; 11183 FOR_EACH_CALL_EXPR_ARG (arg, iter, call) 11184 /* arg is bound to successive arguments of call. */ 11185 ...; 11186 11187 For non-static member functions, there will be an operand 11188 corresponding to the 'this' pointer. There will always be 11189 expressions corresponding to all of the arguments, even if the 11190 function is declared with default arguments and some arguments are 11191 not explicitly provided at the call sites. 11192 11193 'CALL_EXPR's also have a 'CALL_EXPR_STATIC_CHAIN' operand that is 11194 used to implement nested functions. This operand is otherwise 11195 null. 11196 11197'CLEANUP_POINT_EXPR' 11198 These nodes represent full-expressions. The single operand is an 11199 expression to evaluate. Any destructor calls engendered by the 11200 creation of temporaries during the evaluation of that expression 11201 should be performed immediately after the expression is evaluated. 11202 11203'CONSTRUCTOR' 11204 These nodes represent the brace-enclosed initializers for a 11205 structure or an array. They contain a sequence of component values 11206 made out of a vector of constructor_elt, which is a ('INDEX', 11207 'VALUE') pair. 11208 11209 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is a 'RECORD_TYPE', 11210 'UNION_TYPE' or 'QUAL_UNION_TYPE' then the 'INDEX' of each node in 11211 the sequence will be a 'FIELD_DECL' and the 'VALUE' will be the 11212 expression used to initialize that field. 11213 11214 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is an 'ARRAY_TYPE', then 11215 the 'INDEX' of each node in the sequence will be an 'INTEGER_CST' 11216 or a 'RANGE_EXPR' of two 'INTEGER_CST's. A single 'INTEGER_CST' 11217 indicates which element of the array is being assigned to. A 11218 'RANGE_EXPR' indicates an inclusive range of elements to 11219 initialize. In both cases the 'VALUE' is the corresponding 11220 initializer. It is re-evaluated for each element of a 11221 'RANGE_EXPR'. If the 'INDEX' is 'NULL_TREE', then the initializer 11222 is for the next available array element. 11223 11224 In the front end, you should not depend on the fields appearing in 11225 any particular order. However, in the middle end, fields must 11226 appear in declaration order. You should not assume that all fields 11227 will be represented. Unrepresented fields will be cleared 11228 (zeroed), unless the CONSTRUCTOR_NO_CLEARING flag is set, in which 11229 case their value becomes undefined. 11230 11231'COMPOUND_LITERAL_EXPR' 11232 These nodes represent ISO C99 compound literals. The 11233 'COMPOUND_LITERAL_EXPR_DECL_EXPR' is a 'DECL_EXPR' containing an 11234 anonymous 'VAR_DECL' for the unnamed object represented by the 11235 compound literal; the 'DECL_INITIAL' of that 'VAR_DECL' is a 11236 'CONSTRUCTOR' representing the brace-enclosed list of initializers 11237 in the compound literal. That anonymous 'VAR_DECL' can also be 11238 accessed directly by the 'COMPOUND_LITERAL_EXPR_DECL' macro. 11239 11240'SAVE_EXPR' 11241 11242 A 'SAVE_EXPR' represents an expression (possibly involving side 11243 effects) that is used more than once. The side effects should 11244 occur only the first time the expression is evaluated. Subsequent 11245 uses should just reuse the computed value. The first operand to 11246 the 'SAVE_EXPR' is the expression to evaluate. The side effects 11247 should be executed where the 'SAVE_EXPR' is first encountered in a 11248 depth-first preorder traversal of the expression tree. 11249 11250'TARGET_EXPR' 11251 A 'TARGET_EXPR' represents a temporary object. The first operand 11252 is a 'VAR_DECL' for the temporary variable. The second operand is 11253 the initializer for the temporary. The initializer is evaluated 11254 and, if non-void, copied (bitwise) into the temporary. If the 11255 initializer is void, that means that it will perform the 11256 initialization itself. 11257 11258 Often, a 'TARGET_EXPR' occurs on the right-hand side of an 11259 assignment, or as the second operand to a comma-expression which is 11260 itself the right-hand side of an assignment, etc. In this case, we 11261 say that the 'TARGET_EXPR' is "normal"; otherwise, we say it is 11262 "orphaned". For a normal 'TARGET_EXPR' the temporary variable 11263 should be treated as an alias for the left-hand side of the 11264 assignment, rather than as a new temporary variable. 11265 11266 The third operand to the 'TARGET_EXPR', if present, is a 11267 cleanup-expression (i.e., destructor call) for the temporary. If 11268 this expression is orphaned, then this expression must be executed 11269 when the statement containing this expression is complete. These 11270 cleanups must always be executed in the order opposite to that in 11271 which they were encountered. Note that if a temporary is created 11272 on one branch of a conditional operator (i.e., in the second or 11273 third operand to a 'COND_EXPR'), the cleanup must be run only if 11274 that branch is actually executed. 11275 11276'VA_ARG_EXPR' 11277 This node is used to implement support for the C/C++ variable 11278 argument-list mechanism. It represents expressions like 'va_arg 11279 (ap, type)'. Its 'TREE_TYPE' yields the tree representation for 11280 'type' and its sole argument yields the representation for 'ap'. 11281 11282'ANNOTATE_EXPR' 11283 This node is used to attach markers to an expression. The first 11284 operand is the annotated expression, the second is an 'INTEGER_CST' 11285 with a value from 'enum annot_expr_kind', the third is an 11286 'INTEGER_CST'. 11287 11288 11289File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees 11290 1129111.6.4 Vectors 11292-------------- 11293 11294'VEC_DUPLICATE_EXPR' 11295 This node has a single operand and represents a vector in which 11296 every element is equal to that operand. 11297 11298'VEC_SERIES_EXPR' 11299 This node represents a vector formed from a scalar base and step, 11300 given as the first and second operands respectively. Element I of 11301 the result is equal to 'BASE + I*STEP'. 11302 11303 This node is restricted to integral types, in order to avoid 11304 specifying the rounding behavior for floating-point types. 11305 11306'VEC_LSHIFT_EXPR' 11307'VEC_RSHIFT_EXPR' 11308 These nodes represent whole vector left and right shifts, 11309 respectively. The first operand is the vector to shift; it will 11310 always be of vector type. The second operand is an expression for 11311 the number of bits by which to shift. Note that the result is 11312 undefined if the second operand is larger than or equal to the 11313 first operand's type size. 11314 11315'VEC_WIDEN_MULT_HI_EXPR' 11316'VEC_WIDEN_MULT_LO_EXPR' 11317 These nodes represent widening vector multiplication of the high 11318 and low parts of the two input vectors, respectively. Their 11319 operands are vectors that contain the same number of elements ('N') 11320 of the same integral type. The result is a vector that contains 11321 half as many elements, of an integral type whose size is twice as 11322 wide. In the case of 'VEC_WIDEN_MULT_HI_EXPR' the high 'N/2' 11323 elements of the two vector are multiplied to produce the vector of 11324 'N/2' products. In the case of 'VEC_WIDEN_MULT_LO_EXPR' the low 11325 'N/2' elements of the two vector are multiplied to produce the 11326 vector of 'N/2' products. 11327 11328'VEC_WIDEN_PLUS_HI_EXPR' 11329'VEC_WIDEN_PLUS_LO_EXPR' 11330 These nodes represent widening vector addition of the high and low 11331 parts of the two input vectors, respectively. Their operands are 11332 vectors that contain the same number of elements ('N') of the same 11333 integral type. The result is a vector that contains half as many 11334 elements, of an integral type whose size is twice as wide. In the 11335 case of 'VEC_WIDEN_PLUS_HI_EXPR' the high 'N/2' elements of the two 11336 vectors are added to produce the vector of 'N/2' products. In the 11337 case of 'VEC_WIDEN_PLUS_LO_EXPR' the low 'N/2' elements of the two 11338 vectors are added to produce the vector of 'N/2' products. 11339 11340'VEC_WIDEN_MINUS_HI_EXPR' 11341'VEC_WIDEN_MINUS_LO_EXPR' 11342 These nodes represent widening vector subtraction of the high and 11343 low parts of the two input vectors, respectively. Their operands 11344 are vectors that contain the same number of elements ('N') of the 11345 same integral type. The high/low elements of the second vector are 11346 subtracted from the high/low elements of the first. The result is 11347 a vector that contains half as many elements, of an integral type 11348 whose size is twice as wide. In the case of 11349 'VEC_WIDEN_MINUS_HI_EXPR' the high 'N/2' elements of the second 11350 vector are subtracted from the high 'N/2' of the first to produce 11351 the vector of 'N/2' products. In the case of 11352 'VEC_WIDEN_MINUS_LO_EXPR' the low 'N/2' elements of the second 11353 vector are subtracted from the low 'N/2' of the first to produce 11354 the vector of 'N/2' products. 11355 11356'VEC_UNPACK_HI_EXPR' 11357'VEC_UNPACK_LO_EXPR' 11358 These nodes represent unpacking of the high and low parts of the 11359 input vector, respectively. The single operand is a vector that 11360 contains 'N' elements of the same integral or floating point type. 11361 The result is a vector that contains half as many elements, of an 11362 integral or floating point type whose size is twice as wide. In 11363 the case of 'VEC_UNPACK_HI_EXPR' the high 'N/2' elements of the 11364 vector are extracted and widened (promoted). In the case of 11365 'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the vector are 11366 extracted and widened (promoted). 11367 11368'VEC_UNPACK_FLOAT_HI_EXPR' 11369'VEC_UNPACK_FLOAT_LO_EXPR' 11370 These nodes represent unpacking of the high and low parts of the 11371 input vector, where the values are converted from fixed point to 11372 floating point. The single operand is a vector that contains 'N' 11373 elements of the same integral type. The result is a vector that 11374 contains half as many elements of a floating point type whose size 11375 is twice as wide. In the case of 'VEC_UNPACK_FLOAT_HI_EXPR' the 11376 high 'N/2' elements of the vector are extracted, converted and 11377 widened. In the case of 'VEC_UNPACK_FLOAT_LO_EXPR' the low 'N/2' 11378 elements of the vector are extracted, converted and widened. 11379 11380'VEC_UNPACK_FIX_TRUNC_HI_EXPR' 11381'VEC_UNPACK_FIX_TRUNC_LO_EXPR' 11382 These nodes represent unpacking of the high and low parts of the 11383 input vector, where the values are truncated from floating point to 11384 fixed point. The single operand is a vector that contains 'N' 11385 elements of the same floating point type. The result is a vector 11386 that contains half as many elements of an integral type whose size 11387 is twice as wide. In the case of 'VEC_UNPACK_FIX_TRUNC_HI_EXPR' 11388 the high 'N/2' elements of the vector are extracted and converted 11389 with truncation. In the case of 'VEC_UNPACK_FIX_TRUNC_LO_EXPR' the 11390 low 'N/2' elements of the vector are extracted and converted with 11391 truncation. 11392 11393'VEC_PACK_TRUNC_EXPR' 11394 This node represents packing of truncated elements of the two input 11395 vectors into the output vector. Input operands are vectors that 11396 contain the same number of elements of the same integral or 11397 floating point type. The result is a vector that contains twice as 11398 many elements of an integral or floating point type whose size is 11399 half as wide. The elements of the two vectors are demoted and 11400 merged (concatenated) to form the output vector. 11401 11402'VEC_PACK_SAT_EXPR' 11403 This node represents packing of elements of the two input vectors 11404 into the output vector using saturation. Input operands are 11405 vectors that contain the same number of elements of the same 11406 integral type. The result is a vector that contains twice as many 11407 elements of an integral type whose size is half as wide. The 11408 elements of the two vectors are demoted and merged (concatenated) 11409 to form the output vector. 11410 11411'VEC_PACK_FIX_TRUNC_EXPR' 11412 This node represents packing of elements of the two input vectors 11413 into the output vector, where the values are converted from 11414 floating point to fixed point. Input operands are vectors that 11415 contain the same number of elements of a floating point type. The 11416 result is a vector that contains twice as many elements of an 11417 integral type whose size is half as wide. The elements of the two 11418 vectors are merged (concatenated) to form the output vector. 11419 11420'VEC_PACK_FLOAT_EXPR' 11421 This node represents packing of elements of the two input vectors 11422 into the output vector, where the values are converted from fixed 11423 point to floating point. Input operands are vectors that contain 11424 the same number of elements of an integral type. The result is a 11425 vector that contains twice as many elements of floating point type 11426 whose size is half as wide. The elements of the two vectors are 11427 merged (concatenated) to form the output vector. 11428 11429'VEC_COND_EXPR' 11430 These nodes represent '?:' expressions. The three operands must be 11431 vectors of the same size and number of elements. The second and 11432 third operands must have the same type as the entire expression. 11433 The first operand is of signed integral vector type. If an element 11434 of the first operand evaluates to a zero value, the corresponding 11435 element of the result is taken from the third operand. If it 11436 evaluates to a minus one value, it is taken from the second 11437 operand. It should never evaluate to any other value currently, 11438 but optimizations should not rely on that property. In contrast 11439 with a 'COND_EXPR', all operands are always evaluated. 11440 11441'SAD_EXPR' 11442 This node represents the Sum of Absolute Differences operation. 11443 The three operands must be vectors of integral types. The first 11444 and second operand must have the same type. The size of the vector 11445 element of the third operand must be at lease twice of the size of 11446 the vector element of the first and second one. The SAD is 11447 calculated between the first and second operands, added to the 11448 third operand, and returned. 11449 11450 11451File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC 11452 1145311.7 Statements 11454=============== 11455 11456Most statements in GIMPLE are assignment statements, represented by 11457'GIMPLE_ASSIGN'. No other C expressions can appear at statement level; 11458a reference to a volatile object is converted into a 'GIMPLE_ASSIGN'. 11459 11460 There are also several varieties of complex statements. 11461 11462* Menu: 11463 11464* Basic Statements:: 11465* Blocks:: 11466* Statement Sequences:: 11467* Empty Statements:: 11468* Jumps:: 11469* Cleanups:: 11470* OpenMP:: 11471* OpenACC:: 11472 11473 11474File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements 11475 1147611.7.1 Basic Statements 11477----------------------- 11478 11479'ASM_EXPR' 11480 11481 Used to represent an inline assembly statement. For an inline 11482 assembly statement like: 11483 asm ("mov x, y"); 11484 The 'ASM_STRING' macro will return a 'STRING_CST' node for '"mov x, 11485 y"'. If the original statement made use of the extended-assembly 11486 syntax, then 'ASM_OUTPUTS', 'ASM_INPUTS', and 'ASM_CLOBBERS' will 11487 be the outputs, inputs, and clobbers for the statement, represented 11488 as 'STRING_CST' nodes. The extended-assembly syntax looks like: 11489 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 11490 The first string is the 'ASM_STRING', containing the instruction 11491 template. The next two strings are the output and inputs, 11492 respectively; this statement has no clobbers. As this example 11493 indicates, "plain" assembly statements are merely a special case of 11494 extended assembly statements; they have no cv-qualifiers, outputs, 11495 inputs, or clobbers. All of the strings will be 'NUL'-terminated, 11496 and will contain no embedded 'NUL'-characters. 11497 11498 If the assembly statement is declared 'volatile', or if the 11499 statement was not an extended assembly statement, and is therefore 11500 implicitly volatile, then the predicate 'ASM_VOLATILE_P' will hold 11501 of the 'ASM_EXPR'. 11502 11503'DECL_EXPR' 11504 11505 Used to represent a local declaration. The 'DECL_EXPR_DECL' macro 11506 can be used to obtain the entity declared. This declaration may be 11507 a 'LABEL_DECL', indicating that the label declared is a local 11508 label. (As an extension, GCC allows the declaration of labels with 11509 scope.) In C, this declaration may be a 'FUNCTION_DECL', 11510 indicating the use of the GCC nested function extension. For more 11511 information, *note Functions::. 11512 11513'LABEL_EXPR' 11514 11515 Used to represent a label. The 'LABEL_DECL' declared by this 11516 statement can be obtained with the 'LABEL_EXPR_LABEL' macro. The 11517 'IDENTIFIER_NODE' giving the name of the label can be obtained from 11518 the 'LABEL_DECL' with 'DECL_NAME'. 11519 11520'GOTO_EXPR' 11521 11522 Used to represent a 'goto' statement. The 'GOTO_DESTINATION' will 11523 usually be a 'LABEL_DECL'. However, if the "computed goto" 11524 extension has been used, the 'GOTO_DESTINATION' will be an 11525 arbitrary expression indicating the destination. This expression 11526 will always have pointer type. 11527 11528'RETURN_EXPR' 11529 11530 Used to represent a 'return' statement. Operand 0 represents the 11531 value to return. It should either be the 'RESULT_DECL' for the 11532 containing function, or a 'MODIFY_EXPR' or 'INIT_EXPR' setting the 11533 function's 'RESULT_DECL'. It will be 'NULL_TREE' if the statement 11534 was just 11535 return; 11536 11537'LOOP_EXPR' 11538 These nodes represent "infinite" loops. The 'LOOP_EXPR_BODY' 11539 represents the body of the loop. It should be executed forever, 11540 unless an 'EXIT_EXPR' is encountered. 11541 11542'EXIT_EXPR' 11543 These nodes represent conditional exits from the nearest enclosing 11544 'LOOP_EXPR'. The single operand is the condition; if it is 11545 nonzero, then the loop should be exited. An 'EXIT_EXPR' will only 11546 appear within a 'LOOP_EXPR'. 11547 11548'SWITCH_EXPR' 11549 11550 Used to represent a 'switch' statement. The 'SWITCH_COND' is the 11551 expression on which the switch is occurring. The 'SWITCH_BODY' is 11552 the body of the switch statement. 'SWITCH_ALL_CASES_P' is true if 11553 the switch includes a default label or the case label ranges cover 11554 all possible values of the condition expression. 11555 11556 Note that 'TREE_TYPE' for a 'SWITCH_EXPR' represents the original 11557 type of switch expression as given in the source, before any 11558 compiler conversions, instead of the type of the switch expression 11559 itself (which is not meaningful). 11560 11561'CASE_LABEL_EXPR' 11562 11563 Use to represent a 'case' label, range of 'case' labels, or a 11564 'default' label. If 'CASE_LOW' is 'NULL_TREE', then this is a 11565 'default' label. Otherwise, if 'CASE_HIGH' is 'NULL_TREE', then 11566 this is an ordinary 'case' label. In this case, 'CASE_LOW' is an 11567 expression giving the value of the label. Both 'CASE_LOW' and 11568 'CASE_HIGH' are 'INTEGER_CST' nodes. These values will have the 11569 same type as the condition expression in the switch statement. 11570 11571 Otherwise, if both 'CASE_LOW' and 'CASE_HIGH' are defined, the 11572 statement is a range of case labels. Such statements originate 11573 with the extension that allows users to write things of the form: 11574 case 2 ... 5: 11575 The first value will be 'CASE_LOW', while the second will be 11576 'CASE_HIGH'. 11577 11578'DEBUG_BEGIN_STMT' 11579 11580 Marks the beginning of a source statement, for purposes of debug 11581 information generation. 11582 11583 11584File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements 11585 1158611.7.2 Blocks 11587------------- 11588 11589Block scopes and the variables they declare in GENERIC are expressed 11590using the 'BIND_EXPR' code, which in previous versions of GCC was 11591primarily used for the C statement-expression extension. 11592 11593 Variables in a block are collected into 'BIND_EXPR_VARS' in declaration 11594order through their 'TREE_CHAIN' field. Any runtime initialization is 11595moved out of 'DECL_INITIAL' and into a statement in the controlled 11596block. When gimplifying from C or C++, this initialization replaces the 11597'DECL_STMT'. These variables will never require cleanups. The scope of 11598these variables is just the body 11599 11600 Variable-length arrays (VLAs) complicate this process, as their size 11601often refers to variables initialized earlier in the block and their 11602initialization involves an explicit stack allocation. To handle this, 11603we add an indirection and replace them with a pointer to stack space 11604allocated by means of 'alloca'. In most cases, we also arrange for this 11605space to be reclaimed when the enclosing 'BIND_EXPR' is exited, the 11606exception to this being when there is an explicit call to 'alloca' in 11607the source code, in which case the stack is left depressed on exit of 11608the 'BIND_EXPR'. 11609 11610 A C++ program will usually contain more 'BIND_EXPR's than there are 11611syntactic blocks in the source code, since several C++ constructs have 11612implicit scopes associated with them. On the other hand, although the 11613C++ front end uses pseudo-scopes to handle cleanups for objects with 11614destructors, these don't translate into the GIMPLE form; multiple 11615declarations at the same level use the same 'BIND_EXPR'. 11616 11617 11618File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 11619 1162011.7.3 Statement Sequences 11621-------------------------- 11622 11623Multiple statements at the same nesting level are collected into a 11624'STATEMENT_LIST'. Statement lists are modified and traversed using the 11625interface in 'tree-iterator.h'. 11626 11627 11628File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements 11629 1163011.7.4 Empty Statements 11631----------------------- 11632 11633Whenever possible, statements with no effect are discarded. But if they 11634are nested within another construct which cannot be discarded for some 11635reason, they are instead replaced with an empty statement, generated by 11636'build_empty_stmt'. Initially, all empty statements were shared, after 11637the pattern of the Java front end, but this caused a lot of trouble in 11638practice. 11639 11640 An empty statement is represented as '(void)0'. 11641 11642 11643File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements 11644 1164511.7.5 Jumps 11646------------ 11647 11648Other jumps are expressed by either 'GOTO_EXPR' or 'RETURN_EXPR'. 11649 11650 The operand of a 'GOTO_EXPR' must be either a label or a variable 11651containing the address to jump to. 11652 11653 The operand of a 'RETURN_EXPR' is either 'NULL_TREE', 'RESULT_DECL', or 11654a 'MODIFY_EXPR' which sets the return value. It would be nice to move 11655the 'MODIFY_EXPR' into a separate statement, but the special return 11656semantics in 'expand_return' make that difficult. It may still happen 11657in the future, perhaps by moving most of that logic into 11658'expand_assignment'. 11659 11660 11661File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements 11662 1166311.7.6 Cleanups 11664--------------- 11665 11666Destructors for local C++ objects and similar dynamic cleanups are 11667represented in GIMPLE by a 'TRY_FINALLY_EXPR'. 'TRY_FINALLY_EXPR' has 11668two operands, both of which are a sequence of statements to execute. 11669The first sequence is executed. When it completes the second sequence 11670is executed. 11671 11672 The first sequence may complete in the following ways: 11673 11674 1. Execute the last statement in the sequence and fall off the end. 11675 11676 2. Execute a goto statement ('GOTO_EXPR') to an ordinary label outside 11677 the sequence. 11678 11679 3. Execute a return statement ('RETURN_EXPR'). 11680 11681 4. Throw an exception. This is currently not explicitly represented 11682 in GIMPLE. 11683 11684 The second sequence is not executed if the first sequence completes by 11685calling 'setjmp' or 'exit' or any other function that does not return. 11686The second sequence is also not executed if the first sequence completes 11687via a non-local goto or a computed goto (in general the compiler does 11688not know whether such a goto statement exits the first sequence or not, 11689so we assume that it doesn't). 11690 11691 After the second sequence is executed, if it completes normally by 11692falling off the end, execution continues wherever the first sequence 11693would have continued, by falling off the end, or doing a goto, etc. 11694 11695 If the second sequence is an 'EH_ELSE_EXPR' selector, then the sequence 11696in its first operand is used when the first sequence completes normally, 11697and that in its second operand is used for exceptional cleanups, i.e., 11698when an exception propagates out of the first sequence. 11699 11700 'TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 11701to appear on every edge out of the controlled block; this reduces the 11702freedom to move code across these edges. Therefore, the EH lowering 11703pass which runs before most of the optimization passes eliminates these 11704expressions by explicitly adding the cleanup to each edge. Rethrowing 11705the exception is represented using 'RESX_EXPR'. 11706 11707 11708File: gccint.info, Node: OpenMP, Next: OpenACC, Prev: Cleanups, Up: Statements 11709 1171011.7.7 OpenMP 11711------------- 11712 11713All the statements starting with 'OMP_' represent directives and clauses 11714used by the OpenMP API <https://www.openmp.org>. 11715 11716'OMP_PARALLEL' 11717 11718 Represents '#pragma omp parallel [clause1 ... clauseN]'. It has 11719 four operands: 11720 11721 Operand 'OMP_PARALLEL_BODY' is valid while in GENERIC and High 11722 GIMPLE forms. It contains the body of code to be executed by all 11723 the threads. During GIMPLE lowering, this operand becomes 'NULL' 11724 and the body is emitted linearly after 'OMP_PARALLEL'. 11725 11726 Operand 'OMP_PARALLEL_CLAUSES' is the list of clauses associated 11727 with the directive. 11728 11729 Operand 'OMP_PARALLEL_FN' is created by 'pass_lower_omp', it 11730 contains the 'FUNCTION_DECL' for the function that will contain the 11731 body of the parallel region. 11732 11733 Operand 'OMP_PARALLEL_DATA_ARG' is also created by 11734 'pass_lower_omp'. If there are shared variables to be communicated 11735 to the children threads, this operand will contain the 'VAR_DECL' 11736 that contains all the shared values and variables. 11737 11738'OMP_FOR' 11739 11740 Represents '#pragma omp for [clause1 ... clauseN]'. It has six 11741 operands: 11742 11743 Operand 'OMP_FOR_BODY' contains the loop body. 11744 11745 Operand 'OMP_FOR_CLAUSES' is the list of clauses associated with 11746 the directive. 11747 11748 Operand 'OMP_FOR_INIT' is the loop initialization code of the form 11749 'VAR = N1'. 11750 11751 Operand 'OMP_FOR_COND' is the loop conditional expression of the 11752 form 'VAR {<,>,<=,>=} N2'. 11753 11754 Operand 'OMP_FOR_INCR' is the loop index increment of the form 'VAR 11755 {+=,-=} INCR'. 11756 11757 Operand 'OMP_FOR_PRE_BODY' contains side effect code from operands 11758 'OMP_FOR_INIT', 'OMP_FOR_COND' and 'OMP_FOR_INC'. These side 11759 effects are part of the 'OMP_FOR' block but must be evaluated 11760 before the start of loop body. 11761 11762 The loop index variable 'VAR' must be a signed integer variable, 11763 which is implicitly private to each thread. Bounds 'N1' and 'N2' 11764 and the increment expression 'INCR' are required to be loop 11765 invariant integer expressions that are evaluated without any 11766 synchronization. The evaluation order, frequency of evaluation and 11767 side effects are unspecified by the standard. 11768 11769'OMP_SECTIONS' 11770 11771 Represents '#pragma omp sections [clause1 ... clauseN]'. 11772 11773 Operand 'OMP_SECTIONS_BODY' contains the sections body, which in 11774 turn contains a set of 'OMP_SECTION' nodes for each of the 11775 concurrent sections delimited by '#pragma omp section'. 11776 11777 Operand 'OMP_SECTIONS_CLAUSES' is the list of clauses associated 11778 with the directive. 11779 11780'OMP_SECTION' 11781 11782 Section delimiter for 'OMP_SECTIONS'. 11783 11784'OMP_SINGLE' 11785 11786 Represents '#pragma omp single'. 11787 11788 Operand 'OMP_SINGLE_BODY' contains the body of code to be executed 11789 by a single thread. 11790 11791 Operand 'OMP_SINGLE_CLAUSES' is the list of clauses associated with 11792 the directive. 11793 11794'OMP_MASTER' 11795 11796 Represents '#pragma omp master'. 11797 11798 Operand 'OMP_MASTER_BODY' contains the body of code to be executed 11799 by the master thread. 11800 11801'OMP_ORDERED' 11802 11803 Represents '#pragma omp ordered'. 11804 11805 Operand 'OMP_ORDERED_BODY' contains the body of code to be executed 11806 in the sequential order dictated by the loop index variable. 11807 11808'OMP_CRITICAL' 11809 11810 Represents '#pragma omp critical [name]'. 11811 11812 Operand 'OMP_CRITICAL_BODY' is the critical section. 11813 11814 Operand 'OMP_CRITICAL_NAME' is an optional identifier to label the 11815 critical section. 11816 11817'OMP_RETURN' 11818 11819 This does not represent any OpenMP directive, it is an artificial 11820 marker to indicate the end of the body of an OpenMP. It is used by 11821 the flow graph ('tree-cfg.c') and OpenMP region building code 11822 ('omp-low.c'). 11823 11824'OMP_CONTINUE' 11825 11826 Similarly, this instruction does not represent an OpenMP directive, 11827 it is used by 'OMP_FOR' (and similar codes) as well as 11828 'OMP_SECTIONS' to mark the place where the code needs to loop to 11829 the next iteration, or the next section, respectively. 11830 11831 In some cases, 'OMP_CONTINUE' is placed right before 'OMP_RETURN'. 11832 But if there are cleanups that need to occur right after the 11833 looping body, it will be emitted between 'OMP_CONTINUE' and 11834 'OMP_RETURN'. 11835 11836'OMP_ATOMIC' 11837 11838 Represents '#pragma omp atomic'. 11839 11840 Operand 0 is the address at which the atomic operation is to be 11841 performed. 11842 11843 Operand 1 is the expression to evaluate. The gimplifier tries 11844 three alternative code generation strategies. Whenever possible, 11845 an atomic update built-in is used. If that fails, a 11846 compare-and-swap loop is attempted. If that also fails, a regular 11847 critical section around the expression is used. 11848 11849'OMP_CLAUSE' 11850 11851 Represents clauses associated with one of the 'OMP_' directives. 11852 Clauses are represented by separate subcodes defined in 'tree.h'. 11853 Clauses codes can be one of: 'OMP_CLAUSE_PRIVATE', 11854 'OMP_CLAUSE_SHARED', 'OMP_CLAUSE_FIRSTPRIVATE', 11855 'OMP_CLAUSE_LASTPRIVATE', 'OMP_CLAUSE_COPYIN', 11856 'OMP_CLAUSE_COPYPRIVATE', 'OMP_CLAUSE_IF', 11857 'OMP_CLAUSE_NUM_THREADS', 'OMP_CLAUSE_SCHEDULE', 11858 'OMP_CLAUSE_NOWAIT', 'OMP_CLAUSE_ORDERED', 'OMP_CLAUSE_DEFAULT', 11859 'OMP_CLAUSE_REDUCTION', 'OMP_CLAUSE_COLLAPSE', 'OMP_CLAUSE_UNTIED', 11860 'OMP_CLAUSE_FINAL', and 'OMP_CLAUSE_MERGEABLE'. Each code 11861 represents the corresponding OpenMP clause. 11862 11863 Clauses associated with the same directive are chained together via 11864 'OMP_CLAUSE_CHAIN'. Those clauses that accept a list of variables 11865 are restricted to exactly one, accessed with 'OMP_CLAUSE_VAR'. 11866 Therefore, multiple variables under the same clause 'C' need to be 11867 represented as multiple 'C' clauses chained together. This 11868 facilitates adding new clauses during compilation. 11869 11870 11871File: gccint.info, Node: OpenACC, Prev: OpenMP, Up: Statements 11872 1187311.7.8 OpenACC 11874-------------- 11875 11876All the statements starting with 'OACC_' represent directives and 11877clauses used by the OpenACC API <https://www.openacc.org>. 11878 11879'OACC_CACHE' 11880 11881 Represents '#pragma acc cache (var ...)'. 11882 11883'OACC_DATA' 11884 11885 Represents '#pragma acc data [clause1 ... clauseN]'. 11886 11887'OACC_DECLARE' 11888 11889 Represents '#pragma acc declare [clause1 ... clauseN]'. 11890 11891'OACC_ENTER_DATA' 11892 11893 Represents '#pragma acc enter data [clause1 ... clauseN]'. 11894 11895'OACC_EXIT_DATA' 11896 11897 Represents '#pragma acc exit data [clause1 ... clauseN]'. 11898 11899'OACC_HOST_DATA' 11900 11901 Represents '#pragma acc host_data [clause1 ... clauseN]'. 11902 11903'OACC_KERNELS' 11904 11905 Represents '#pragma acc kernels [clause1 ... clauseN]'. 11906 11907'OACC_LOOP' 11908 11909 Represents '#pragma acc loop [clause1 ... clauseN]'. 11910 11911 See the description of the 'OMP_FOR' code. 11912 11913'OACC_PARALLEL' 11914 11915 Represents '#pragma acc parallel [clause1 ... clauseN]'. 11916 11917'OACC_SERIAL' 11918 11919 Represents '#pragma acc serial [clause1 ... clauseN]'. 11920 11921'OACC_UPDATE' 11922 11923 Represents '#pragma acc update [clause1 ... clauseN]'. 11924 11925 11926File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC 11927 1192811.8 Functions 11929============== 11930 11931A function is represented by a 'FUNCTION_DECL' node. It stores the 11932basic pieces of the function such as body, parameters, and return type 11933as well as information on the surrounding context, visibility, and 11934linkage. 11935 11936* Menu: 11937 11938* Function Basics:: Function names, body, and parameters. 11939* Function Properties:: Context, linkage, etc. 11940 11941 11942File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions 11943 1194411.8.1 Function Basics 11945---------------------- 11946 11947A function has four core parts: the name, the parameters, the result, 11948and the body. The following macros and functions access these parts of 11949a 'FUNCTION_DECL' as well as other basic features: 11950'DECL_NAME' 11951 This macro returns the unqualified name of the function, as an 11952 'IDENTIFIER_NODE'. For an instantiation of a function template, 11953 the 'DECL_NAME' is the unqualified name of the template, not 11954 something like 'f<int>'. The value of 'DECL_NAME' is undefined 11955 when used on a constructor, destructor, overloaded operator, or 11956 type-conversion operator, or any function that is implicitly 11957 generated by the compiler. See below for macros that can be used 11958 to distinguish these cases. 11959 11960'DECL_ASSEMBLER_NAME' 11961 This macro returns the mangled name of the function, also an 11962 'IDENTIFIER_NODE'. This name does not contain leading underscores 11963 on systems that prefix all identifiers with underscores. The 11964 mangled name is computed in the same way on all platforms; if 11965 special processing is required to deal with the object file format 11966 used on a particular platform, it is the responsibility of the back 11967 end to perform those modifications. (Of course, the back end 11968 should not modify 'DECL_ASSEMBLER_NAME' itself.) 11969 11970 Using 'DECL_ASSEMBLER_NAME' will cause additional memory to be 11971 allocated (for the mangled name of the entity) so it should be used 11972 only when emitting assembly code. It should not be used within the 11973 optimizers to determine whether or not two declarations are the 11974 same, even though some of the existing optimizers do use it in that 11975 way. These uses will be removed over time. 11976 11977'DECL_ARGUMENTS' 11978 This macro returns the 'PARM_DECL' for the first argument to the 11979 function. Subsequent 'PARM_DECL' nodes can be obtained by 11980 following the 'TREE_CHAIN' links. 11981 11982'DECL_RESULT' 11983 This macro returns the 'RESULT_DECL' for the function. 11984 11985'DECL_SAVED_TREE' 11986 This macro returns the complete body of the function. 11987 11988'TREE_TYPE' 11989 This macro returns the 'FUNCTION_TYPE' or 'METHOD_TYPE' for the 11990 function. 11991 11992'DECL_INITIAL' 11993 A function that has a definition in the current translation unit 11994 will have a non-'NULL' 'DECL_INITIAL'. However, back ends should 11995 not make use of the particular value given by 'DECL_INITIAL'. 11996 11997 It should contain a tree of 'BLOCK' nodes that mirrors the scopes 11998 that variables are bound in the function. Each block contains a 11999 list of decls declared in a basic block, a pointer to a chain of 12000 blocks at the next lower scope level, then a pointer to the next 12001 block at the same level and a backpointer to the parent 'BLOCK' or 12002 'FUNCTION_DECL'. So given a function as follows: 12003 12004 void foo() 12005 { 12006 int a; 12007 { 12008 int b; 12009 } 12010 int c; 12011 } 12012 12013 you would get the following: 12014 12015 tree foo = FUNCTION_DECL; 12016 tree decl_a = VAR_DECL; 12017 tree decl_b = VAR_DECL; 12018 tree decl_c = VAR_DECL; 12019 tree block_a = BLOCK; 12020 tree block_b = BLOCK; 12021 tree block_c = BLOCK; 12022 BLOCK_VARS(block_a) = decl_a; 12023 BLOCK_SUBBLOCKS(block_a) = block_b; 12024 BLOCK_CHAIN(block_a) = block_c; 12025 BLOCK_SUPERCONTEXT(block_a) = foo; 12026 BLOCK_VARS(block_b) = decl_b; 12027 BLOCK_SUPERCONTEXT(block_b) = block_a; 12028 BLOCK_VARS(block_c) = decl_c; 12029 BLOCK_SUPERCONTEXT(block_c) = foo; 12030 DECL_INITIAL(foo) = block_a; 12031 12032 12033File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions 12034 1203511.8.2 Function Properties 12036-------------------------- 12037 12038To determine the scope of a function, you can use the 'DECL_CONTEXT' 12039macro. This macro will return the class (either a 'RECORD_TYPE' or a 12040'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 12041a member. For a virtual function, this macro returns the class in which 12042the function was actually defined, not the base class in which the 12043virtual declaration occurred. 12044 12045 In C, the 'DECL_CONTEXT' for a function maybe another function. This 12046representation indicates that the GNU nested function extension is in 12047use. For details on the semantics of nested functions, see the GCC 12048Manual. The nested function can refer to local variables in its 12049containing function. Such references are not explicitly marked in the 12050tree structure; back ends must look at the 'DECL_CONTEXT' for the 12051referenced 'VAR_DECL'. If the 'DECL_CONTEXT' for the referenced 12052'VAR_DECL' is not the same as the function currently being processed, 12053and neither 'DECL_EXTERNAL' nor 'TREE_STATIC' hold, then the reference 12054is to a local variable in a containing function, and the back end must 12055take appropriate action. 12056 12057'DECL_EXTERNAL' 12058 This predicate holds if the function is undefined. 12059 12060'TREE_PUBLIC' 12061 This predicate holds if the function has external linkage. 12062 12063'TREE_STATIC' 12064 This predicate holds if the function has been defined. 12065 12066'TREE_THIS_VOLATILE' 12067 This predicate holds if the function does not return normally. 12068 12069'TREE_READONLY' 12070 This predicate holds if the function can only read its arguments. 12071 12072'DECL_PURE_P' 12073 This predicate holds if the function can only read its arguments, 12074 but may also read global memory. 12075 12076'DECL_VIRTUAL_P' 12077 This predicate holds if the function is virtual. 12078 12079'DECL_ARTIFICIAL' 12080 This macro holds if the function was implicitly generated by the 12081 compiler, rather than explicitly declared. In addition to 12082 implicitly generated class member functions, this macro holds for 12083 the special functions created to implement static initialization 12084 and destruction, to compute run-time type information, and so 12085 forth. 12086 12087'DECL_FUNCTION_SPECIFIC_TARGET' 12088 This macro returns a tree node that holds the target options that 12089 are to be used to compile this particular function or 'NULL_TREE' 12090 if the function is to be compiled with the target options specified 12091 on the command line. 12092 12093'DECL_FUNCTION_SPECIFIC_OPTIMIZATION' 12094 This macro returns a tree node that holds the optimization options 12095 that are to be used to compile this particular function or 12096 'NULL_TREE' if the function is to be compiled with the optimization 12097 options specified on the command line. 12098 12099 12100File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC 12101 1210211.9 Language-dependent trees 12103============================= 12104 12105Front ends may wish to keep some state associated with various GENERIC 12106trees while parsing. To support this, trees provide a set of flags that 12107may be used by the front end. They are accessed using 12108'TREE_LANG_FLAG_n' where 'n' is currently 0 through 6. 12109 12110 If necessary, a front end can use some language-dependent tree codes in 12111its GENERIC representation, so long as it provides a hook for converting 12112them to GIMPLE and doesn't expect them to work with any (hypothetical) 12113optimizers that run before the conversion to GIMPLE. The intermediate 12114representation used while parsing C and C++ looks very little like 12115GENERIC, but the C and C++ gimplifier hooks are perfectly happy to take 12116it as input and spit out GIMPLE. 12117 12118 12119File: gccint.info, Node: C and C++ Trees, Prev: Language-dependent trees, Up: GENERIC 12120 1212111.10 C and C++ Trees 12122===================== 12123 12124This section documents the internal representation used by GCC to 12125represent C and C++ source programs. When presented with a C or C++ 12126source program, GCC parses the program, performs semantic analysis 12127(including the generation of error messages), and then produces the 12128internal representation described here. This representation contains a 12129complete representation for the entire translation unit provided as 12130input to the front end. This representation is then typically processed 12131by a code-generator in order to produce machine code, but could also be 12132used in the creation of source browsers, intelligent editors, automatic 12133documentation generators, interpreters, and any other programs needing 12134the ability to process C or C++ code. 12135 12136 This section explains the internal representation. In particular, it 12137documents the internal representation for C and C++ source constructs, 12138and the macros, functions, and variables that can be used to access 12139these constructs. The C++ representation is largely a superset of the 12140representation used in the C front end. There is only one construct 12141used in C that does not appear in the C++ front end and that is the GNU 12142"nested function" extension. Many of the macros documented here do not 12143apply in C because the corresponding language constructs do not appear 12144in C. 12145 12146 The C and C++ front ends generate a mix of GENERIC trees and ones 12147specific to C and C++. These language-specific trees are higher-level 12148constructs than the ones in GENERIC to make the parser's job easier. 12149This section describes those trees that aren't part of GENERIC as well 12150as aspects of GENERIC trees that are treated in a language-specific 12151manner. 12152 12153 If you are developing a "back end", be it is a code-generator or some 12154other tool, that uses this representation, you may occasionally find 12155that you need to ask questions not easily answered by the functions and 12156macros available here. If that situation occurs, it is quite likely 12157that GCC already supports the functionality you desire, but that the 12158interface is simply not documented here. In that case, you should ask 12159the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting 12160the functionality you require. Similarly, if you find yourself writing 12161functions that do not deal directly with your back end, but instead 12162might be useful to other people using the GCC front end, you should 12163submit your patches for inclusion in GCC. 12164 12165* Menu: 12166 12167* Types for C++:: Fundamental and aggregate types. 12168* Namespaces:: Namespaces. 12169* Classes:: Classes. 12170* Functions for C++:: Overloading and accessors for C++. 12171* Statements for C and C++:: Statements specific to C and C++. 12172* C++ Expressions:: From 'typeid' to 'throw'. 12173 12174 12175File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees 12176 1217711.10.1 Types for C++ 12178--------------------- 12179 12180In C++, an array type is not qualified; rather the type of the array 12181elements is qualified. This situation is reflected in the intermediate 12182representation. The macros described here will always examine the 12183qualification of the underlying element type when applied to an array 12184type. (If the element type is itself an array, then the recursion 12185continues until a non-array type is found, and the qualification of this 12186type is examined.) So, for example, 'CP_TYPE_CONST_P' will hold of the 12187type 'const int ()[7]', denoting an array of seven 'int's. 12188 12189 The following functions and macros deal with cv-qualification of types: 12190'cp_type_quals' 12191 This function returns the set of type qualifiers applied to this 12192 type. This value is 'TYPE_UNQUALIFIED' if no qualifiers have been 12193 applied. The 'TYPE_QUAL_CONST' bit is set if the type is 12194 'const'-qualified. The 'TYPE_QUAL_VOLATILE' bit is set if the type 12195 is 'volatile'-qualified. The 'TYPE_QUAL_RESTRICT' bit is set if 12196 the type is 'restrict'-qualified. 12197 12198'CP_TYPE_CONST_P' 12199 This macro holds if the type is 'const'-qualified. 12200 12201'CP_TYPE_VOLATILE_P' 12202 This macro holds if the type is 'volatile'-qualified. 12203 12204'CP_TYPE_RESTRICT_P' 12205 This macro holds if the type is 'restrict'-qualified. 12206 12207'CP_TYPE_CONST_NON_VOLATILE_P' 12208 This predicate holds for a type that is 'const'-qualified, but 12209 _not_ 'volatile'-qualified; other cv-qualifiers are ignored as 12210 well: only the 'const'-ness is tested. 12211 12212 A few other macros and functions are usable with all types: 12213'TYPE_SIZE' 12214 The number of bits required to represent the type, represented as 12215 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 12216 'NULL_TREE'. 12217 12218'TYPE_ALIGN' 12219 The alignment of the type, in bits, represented as an 'int'. 12220 12221'TYPE_NAME' 12222 This macro returns a declaration (in the form of a 'TYPE_DECL') for 12223 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 12224 as you might expect, given its name!) You can look at the 12225 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 12226 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 12227 built-in type, the result of a typedef, or a named class type. 12228 12229'CP_INTEGRAL_TYPE' 12230 This predicate holds if the type is an integral type. Notice that 12231 in C++, enumerations are _not_ integral types. 12232 12233'ARITHMETIC_TYPE_P' 12234 This predicate holds if the type is an integral type (in the C++ 12235 sense) or a floating point type. 12236 12237'CLASS_TYPE_P' 12238 This predicate holds for a class-type. 12239 12240'TYPE_BUILT_IN' 12241 This predicate holds for a built-in type. 12242 12243'TYPE_PTRDATAMEM_P' 12244 This predicate holds if the type is a pointer to data member. 12245 12246'TYPE_PTR_P' 12247 This predicate holds if the type is a pointer type, and the pointee 12248 is not a data member. 12249 12250'TYPE_PTRFN_P' 12251 This predicate holds for a pointer to function type. 12252 12253'TYPE_PTROB_P' 12254 This predicate holds for a pointer to object type. Note however 12255 that it does not hold for the generic pointer to object type 'void 12256 *'. You may use 'TYPE_PTROBV_P' to test for a pointer to object 12257 type as well as 'void *'. 12258 12259 The table below describes types specific to C and C++ as well as 12260language-dependent info about GENERIC types. 12261 12262'POINTER_TYPE' 12263 Used to represent pointer types, and pointer to data member types. 12264 If 'TREE_TYPE' is a pointer to data member type, then 12265 'TYPE_PTRDATAMEM_P' will hold. For a pointer to data member type 12266 of the form 'T X::*', 'TYPE_PTRMEM_CLASS_TYPE' will be the type 12267 'X', while 'TYPE_PTRMEM_POINTED_TO_TYPE' will be the type 'T'. 12268 12269'RECORD_TYPE' 12270 Used to represent 'struct' and 'class' types in C and C++. If 12271 'TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 12272 type. In that case, the 'TYPE_PTRMEMFUNC_FN_TYPE' is a 12273 'POINTER_TYPE' pointing to a 'METHOD_TYPE'. The 'METHOD_TYPE' is 12274 the type of a function pointed to by the pointer-to-member 12275 function. If 'TYPE_PTRMEMFUNC_P' does not hold, this type is a 12276 class type. For more information, *note Classes::. 12277 12278'UNKNOWN_TYPE' 12279 This node is used to represent a type the knowledge of which is 12280 insufficient for a sound processing. 12281 12282'TYPENAME_TYPE' 12283 Used to represent a construct of the form 'typename T::A'. The 12284 'TYPE_CONTEXT' is 'T'; the 'TYPE_NAME' is an 'IDENTIFIER_NODE' for 12285 'A'. If the type is specified via a template-id, then 12286 'TYPENAME_TYPE_FULLNAME' yields a 'TEMPLATE_ID_EXPR'. The 12287 'TREE_TYPE' is non-'NULL' if the node is implicitly generated in 12288 support for the implicit typename extension; in which case the 12289 'TREE_TYPE' is a type node for the base-class. 12290 12291'TYPEOF_TYPE' 12292 Used to represent the '__typeof__' extension. The 'TYPE_FIELDS' is 12293 the expression the type of which is being represented. 12294 12295 12296File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees 12297 1229811.10.2 Namespaces 12299------------------ 12300 12301The root of the entire intermediate representation is the variable 12302'global_namespace'. This is the namespace specified with '::' in C++ 12303source code. All other namespaces, types, variables, functions, and so 12304forth can be found starting with this namespace. 12305 12306 However, except for the fact that it is distinguished as the root of 12307the representation, the global namespace is no different from any other 12308namespace. Thus, in what follows, we describe namespaces generally, 12309rather than the global namespace in particular. 12310 12311 A namespace is represented by a 'NAMESPACE_DECL' node. 12312 12313 The following macros and functions can be used on a 'NAMESPACE_DECL': 12314 12315'DECL_NAME' 12316 This macro is used to obtain the 'IDENTIFIER_NODE' corresponding to 12317 the unqualified name of the name of the namespace (*note 12318 Identifiers::). The name of the global namespace is '::', even 12319 though in C++ the global namespace is unnamed. However, you should 12320 use comparison with 'global_namespace', rather than 'DECL_NAME' to 12321 determine whether or not a namespace is the global one. An unnamed 12322 namespace will have a 'DECL_NAME' equal to 12323 'anonymous_namespace_name'. Within a single translation unit, all 12324 unnamed namespaces will have the same name. 12325 12326'DECL_CONTEXT' 12327 This macro returns the enclosing namespace. The 'DECL_CONTEXT' for 12328 the 'global_namespace' is 'NULL_TREE'. 12329 12330'DECL_NAMESPACE_ALIAS' 12331 If this declaration is for a namespace alias, then 12332 'DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 12333 alias. 12334 12335 Do not attempt to use 'cp_namespace_decls' for a namespace which is 12336 an alias. Instead, follow 'DECL_NAMESPACE_ALIAS' links until you 12337 reach an ordinary, non-alias, namespace, and call 12338 'cp_namespace_decls' there. 12339 12340'DECL_NAMESPACE_STD_P' 12341 This predicate holds if the namespace is the special '::std' 12342 namespace. 12343 12344'cp_namespace_decls' 12345 This function will return the declarations contained in the 12346 namespace, including types, overloaded functions, other namespaces, 12347 and so forth. If there are no declarations, this function will 12348 return 'NULL_TREE'. The declarations are connected through their 12349 'TREE_CHAIN' fields. 12350 12351 Although most entries on this list will be declarations, 12352 'TREE_LIST' nodes may also appear. In this case, the 'TREE_VALUE' 12353 will be an 'OVERLOAD'. The value of the 'TREE_PURPOSE' is 12354 unspecified; back ends should ignore this value. As with the other 12355 kinds of declarations returned by 'cp_namespace_decls', the 12356 'TREE_CHAIN' will point to the next declaration in this list. 12357 12358 For more information on the kinds of declarations that can occur on 12359 this list, *Note Declarations::. Some declarations will not appear 12360 on this list. In particular, no 'FIELD_DECL', 'LABEL_DECL', or 12361 'PARM_DECL' nodes will appear here. 12362 12363 This function cannot be used with namespaces that have 12364 'DECL_NAMESPACE_ALIAS' set. 12365 12366 12367File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees 12368 1236911.10.3 Classes 12370--------------- 12371 12372Besides namespaces, the other high-level scoping construct in C++ is the 12373class. (Throughout this manual the term "class" is used to mean the 12374types referred to in the ANSI/ISO C++ Standard as classes; these include 12375types defined with the 'class', 'struct', and 'union' keywords.) 12376 12377 A class type is represented by either a 'RECORD_TYPE' or a 12378'UNION_TYPE'. A class declared with the 'union' tag is represented by a 12379'UNION_TYPE', while classes declared with either the 'struct' or the 12380'class' tag are represented by 'RECORD_TYPE's. You can use the 12381'CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 12382type is a 'class' as opposed to a 'struct'. This macro will be true 12383only for classes declared with the 'class' tag. 12384 12385 Almost all members are available on the 'TYPE_FIELDS' list. Given one 12386member, the next can be found by following the 'TREE_CHAIN'. You should 12387not depend in any way on the order in which fields appear on this list. 12388All nodes on this list will be 'DECL' nodes. A 'FIELD_DECL' is used to 12389represent a non-static data member, a 'VAR_DECL' is used to represent a 12390static data member, and a 'TYPE_DECL' is used to represent a type. Note 12391that the 'CONST_DECL' for an enumeration constant will appear on this 12392list, if the enumeration type was declared in the class. (Of course, 12393the 'TYPE_DECL' for the enumeration type will appear here as well.) 12394There are no entries for base classes on this list. In particular, 12395there is no 'FIELD_DECL' for the "base-class portion" of an object. If 12396a function member is overloaded, each of the overloaded functions 12397appears; no 'OVERLOAD' nodes appear on the 'TYPE_FIELDS' list. 12398Implicitly declared functions (including default constructors, copy 12399constructors, assignment operators, and destructors) will appear on this 12400list as well. 12401 12402 The 'TYPE_VFIELD' is a compiler-generated field used to point to 12403virtual function tables. It may or may not appear on the 'TYPE_FIELDS' 12404list. However, back ends should handle the 'TYPE_VFIELD' just like all 12405the entries on the 'TYPE_FIELDS' list. 12406 12407 Every class has an associated "binfo", which can be obtained with 12408'TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 12409given by 'TYPE_BINFO' is the degenerate case, whereby every class is 12410considered to be its own base-class. The base binfos for a particular 12411binfo are held in a vector, whose length is obtained with 12412'BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 12413'BINFO_BASE_BINFO' and 'BINFO_BASE_ITERATE'. To add a new binfo, use 12414'BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 12415'BINFO_BASE_BINFOS', but normally you do not need to use that. The 12416class type associated with a binfo is given by 'BINFO_TYPE'. It is not 12417always the case that 'BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 12418and qualified types. Neither is it the case that 'TYPE_BINFO 12419(BINFO_TYPE (y))' is the same binfo as 'y'. The reason is that if 'y' 12420is a binfo representing a base-class 'B' of a derived class 'D', then 12421'BINFO_TYPE (y)' will be 'B', and 'TYPE_BINFO (BINFO_TYPE (y))' will be 12422'B' as its own base-class, rather than as a base-class of 'D'. 12423 12424 The access to a base type can be found with 'BINFO_BASE_ACCESS'. This 12425will produce 'access_public_node', 'access_private_node' or 12426'access_protected_node'. If bases are always public, 12427'BINFO_BASE_ACCESSES' may be 'NULL'. 12428 12429 'BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 12430virtually or not. The other flags, 'BINFO_FLAG_0' to 'BINFO_FLAG_6', 12431can be used for language specific use. 12432 12433 The following macros can be used on a tree node representing a 12434class-type. 12435 12436'LOCAL_CLASS_P' 12437 This predicate holds if the class is local class _i.e._ declared 12438 inside a function body. 12439 12440'TYPE_POLYMORPHIC_P' 12441 This predicate holds if the class has at least one virtual function 12442 (declared or inherited). 12443 12444'TYPE_HAS_DEFAULT_CONSTRUCTOR' 12445 This predicate holds whenever its argument represents a class-type 12446 with default constructor. 12447 12448'CLASSTYPE_HAS_MUTABLE' 12449'TYPE_HAS_MUTABLE_P' 12450 These predicates hold for a class-type having a mutable data 12451 member. 12452 12453'CLASSTYPE_NON_POD_P' 12454 This predicate holds only for class-types that are not PODs. 12455 12456'TYPE_HAS_NEW_OPERATOR' 12457 This predicate holds for a class-type that defines 'operator new'. 12458 12459'TYPE_HAS_ARRAY_NEW_OPERATOR' 12460 This predicate holds for a class-type for which 'operator new[]' is 12461 defined. 12462 12463'TYPE_OVERLOADS_CALL_EXPR' 12464 This predicate holds for class-type for which the function call 12465 'operator()' is overloaded. 12466 12467'TYPE_OVERLOADS_ARRAY_REF' 12468 This predicate holds for a class-type that overloads 'operator[]' 12469 12470'TYPE_OVERLOADS_ARROW' 12471 This predicate holds for a class-type for which 'operator->' is 12472 overloaded. 12473 12474 12475File: gccint.info, Node: Functions for C++, Next: Statements for C and C++, Prev: Classes, Up: C and C++ Trees 12476 1247711.10.4 Functions for C++ 12478------------------------- 12479 12480A function is represented by a 'FUNCTION_DECL' node. A set of 12481overloaded functions is sometimes represented by an 'OVERLOAD' node. 12482 12483 An 'OVERLOAD' node is not a declaration, so none of the 'DECL_' macros 12484should be used on an 'OVERLOAD'. An 'OVERLOAD' node is similar to a 12485'TREE_LIST'. Use 'OVL_CURRENT' to get the function associated with an 12486'OVERLOAD' node; use 'OVL_NEXT' to get the next 'OVERLOAD' node in the 12487list of overloaded functions. The macros 'OVL_CURRENT' and 'OVL_NEXT' 12488are actually polymorphic; you can use them to work with 'FUNCTION_DECL' 12489nodes as well as with overloads. In the case of a 'FUNCTION_DECL', 12490'OVL_CURRENT' will always return the function itself, and 'OVL_NEXT' 12491will always be 'NULL_TREE'. 12492 12493 To determine the scope of a function, you can use the 'DECL_CONTEXT' 12494macro. This macro will return the class (either a 'RECORD_TYPE' or a 12495'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 12496a member. For a virtual function, this macro returns the class in which 12497the function was actually defined, not the base class in which the 12498virtual declaration occurred. 12499 12500 If a friend function is defined in a class scope, the 12501'DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 12502it was defined. For example, in 12503 class C { friend void f() {} }; 12504the 'DECL_CONTEXT' for 'f' will be the 'global_namespace', but the 12505'DECL_FRIEND_CONTEXT' will be the 'RECORD_TYPE' for 'C'. 12506 12507 The following macros and functions can be used on a 'FUNCTION_DECL': 12508'DECL_MAIN_P' 12509 This predicate holds for a function that is the program entry point 12510 '::code'. 12511 12512'DECL_LOCAL_FUNCTION_P' 12513 This predicate holds if the function was declared at block scope, 12514 even though it has a global scope. 12515 12516'DECL_ANTICIPATED' 12517 This predicate holds if the function is a built-in function but its 12518 prototype is not yet explicitly declared. 12519 12520'DECL_EXTERN_C_FUNCTION_P' 12521 This predicate holds if the function is declared as an ''extern 12522 "C"'' function. 12523 12524'DECL_LINKONCE_P' 12525 This macro holds if multiple copies of this function may be emitted 12526 in various translation units. It is the responsibility of the 12527 linker to merge the various copies. Template instantiations are 12528 the most common example of functions for which 'DECL_LINKONCE_P' 12529 holds; G++ instantiates needed templates in all translation units 12530 which require them, and then relies on the linker to remove 12531 duplicate instantiations. 12532 12533 FIXME: This macro is not yet implemented. 12534 12535'DECL_FUNCTION_MEMBER_P' 12536 This macro holds if the function is a member of a class, rather 12537 than a member of a namespace. 12538 12539'DECL_STATIC_FUNCTION_P' 12540 This predicate holds if the function a static member function. 12541 12542'DECL_NONSTATIC_MEMBER_FUNCTION_P' 12543 This macro holds for a non-static member function. 12544 12545'DECL_CONST_MEMFUNC_P' 12546 This predicate holds for a 'const'-member function. 12547 12548'DECL_VOLATILE_MEMFUNC_P' 12549 This predicate holds for a 'volatile'-member function. 12550 12551'DECL_CONSTRUCTOR_P' 12552 This macro holds if the function is a constructor. 12553 12554'DECL_NONCONVERTING_P' 12555 This predicate holds if the constructor is a non-converting 12556 constructor. 12557 12558'DECL_COMPLETE_CONSTRUCTOR_P' 12559 This predicate holds for a function which is a constructor for an 12560 object of a complete type. 12561 12562'DECL_BASE_CONSTRUCTOR_P' 12563 This predicate holds for a function which is a constructor for a 12564 base class sub-object. 12565 12566'DECL_COPY_CONSTRUCTOR_P' 12567 This predicate holds for a function which is a copy-constructor. 12568 12569'DECL_DESTRUCTOR_P' 12570 This macro holds if the function is a destructor. 12571 12572'DECL_COMPLETE_DESTRUCTOR_P' 12573 This predicate holds if the function is the destructor for an 12574 object a complete type. 12575 12576'DECL_OVERLOADED_OPERATOR_P' 12577 This macro holds if the function is an overloaded operator. 12578 12579'DECL_CONV_FN_P' 12580 This macro holds if the function is a type-conversion operator. 12581 12582'DECL_GLOBAL_CTOR_P' 12583 This predicate holds if the function is a file-scope initialization 12584 function. 12585 12586'DECL_GLOBAL_DTOR_P' 12587 This predicate holds if the function is a file-scope finalization 12588 function. 12589 12590'DECL_THUNK_P' 12591 This predicate holds if the function is a thunk. 12592 12593 These functions represent stub code that adjusts the 'this' pointer 12594 and then jumps to another function. When the jumped-to function 12595 returns, control is transferred directly to the caller, without 12596 returning to the thunk. The first parameter to the thunk is always 12597 the 'this' pointer; the thunk should add 'THUNK_DELTA' to this 12598 value. (The 'THUNK_DELTA' is an 'int', not an 'INTEGER_CST'.) 12599 12600 Then, if 'THUNK_VCALL_OFFSET' (an 'INTEGER_CST') is nonzero the 12601 adjusted 'this' pointer must be adjusted again. The complete 12602 calculation is given by the following pseudo-code: 12603 12604 this += THUNK_DELTA 12605 if (THUNK_VCALL_OFFSET) 12606 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 12607 12608 Finally, the thunk should jump to the location given by 12609 'DECL_INITIAL'; this will always be an expression for the address 12610 of a function. 12611 12612'DECL_NON_THUNK_FUNCTION_P' 12613 This predicate holds if the function is _not_ a thunk function. 12614 12615'GLOBAL_INIT_PRIORITY' 12616 If either 'DECL_GLOBAL_CTOR_P' or 'DECL_GLOBAL_DTOR_P' holds, then 12617 this gives the initialization priority for the function. The 12618 linker will arrange that all functions for which 12619 'DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 12620 before 'main' is called. When the program exits, all functions for 12621 which 'DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 12622 12623'TYPE_RAISES_EXCEPTIONS' 12624 This macro returns the list of exceptions that a (member-)function 12625 can raise. The returned list, if non 'NULL', is comprised of nodes 12626 whose 'TREE_VALUE' represents a type. 12627 12628'TYPE_NOTHROW_P' 12629 This predicate holds when the exception-specification of its 12630 arguments is of the form ''()''. 12631 12632'DECL_ARRAY_DELETE_OPERATOR_P' 12633 This predicate holds if the function an overloaded 'operator 12634 delete[]'. 12635 12636 12637File: gccint.info, Node: Statements for C and C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees 12638 1263911.10.5 Statements for C and C++ 12640-------------------------------- 12641 12642A function that has a definition in the current translation unit has a 12643non-'NULL' 'DECL_INITIAL'. However, back ends should not make use of 12644the particular value given by 'DECL_INITIAL'. 12645 12646 The 'DECL_SAVED_TREE' gives the complete body of the function. 12647 12648 There are tree nodes corresponding to all of the source-level statement 12649constructs, used within the C and C++ frontends. These are enumerated 12650here, together with a list of the various macros that can be used to 12651obtain information about them. There are a few macros that can be used 12652with all statements: 12653 12654'STMT_IS_FULL_EXPR_P' 12655 In C++, statements normally constitute "full expressions"; 12656 temporaries created during a statement are destroyed when the 12657 statement is complete. However, G++ sometimes represents 12658 expressions by statements; these statements will not have 12659 'STMT_IS_FULL_EXPR_P' set. Temporaries created during such 12660 statements should be destroyed when the innermost enclosing 12661 statement with 'STMT_IS_FULL_EXPR_P' set is exited. 12662 12663 Here is the list of the various statement nodes, and the macros used to 12664access them. This documentation describes the use of these nodes in 12665non-template functions (including instantiations of template functions). 12666In template functions, the same nodes are used, but sometimes in 12667slightly different ways. 12668 12669 Many of the statements have substatements. For example, a 'while' loop 12670has a body, which is itself a statement. If the substatement is 12671'NULL_TREE', it is considered equivalent to a statement consisting of a 12672single ';', i.e., an expression statement in which the expression has 12673been omitted. A substatement may in fact be a list of statements, 12674connected via their 'TREE_CHAIN's. So, you should always process the 12675statement tree by looping over substatements, like this: 12676 void process_stmt (stmt) 12677 tree stmt; 12678 { 12679 while (stmt) 12680 { 12681 switch (TREE_CODE (stmt)) 12682 { 12683 case IF_STMT: 12684 process_stmt (THEN_CLAUSE (stmt)); 12685 /* More processing here. */ 12686 break; 12687 12688 ... 12689 } 12690 12691 stmt = TREE_CHAIN (stmt); 12692 } 12693 } 12694 In other words, while the 'then' clause of an 'if' statement in C++ can 12695be only one statement (although that one statement may be a compound 12696statement), the intermediate representation sometimes uses several 12697statements chained together. 12698 12699'BREAK_STMT' 12700 12701 Used to represent a 'break' statement. There are no additional 12702 fields. 12703 12704'CLEANUP_STMT' 12705 12706 Used to represent an action that should take place upon exit from 12707 the enclosing scope. Typically, these actions are calls to 12708 destructors for local objects, but back ends cannot rely on this 12709 fact. If these nodes are in fact representing such destructors, 12710 'CLEANUP_DECL' will be the 'VAR_DECL' destroyed. Otherwise, 12711 'CLEANUP_DECL' will be 'NULL_TREE'. In any case, the 12712 'CLEANUP_EXPR' is the expression to execute. The cleanups executed 12713 on exit from a scope should be run in the reverse order of the 12714 order in which the associated 'CLEANUP_STMT's were encountered. 12715 12716'CONTINUE_STMT' 12717 12718 Used to represent a 'continue' statement. There are no additional 12719 fields. 12720 12721'CTOR_STMT' 12722 12723 Used to mark the beginning (if 'CTOR_BEGIN_P' holds) or end (if 12724 'CTOR_END_P' holds of the main body of a constructor. See also 12725 'SUBOBJECT' for more information on how to use these nodes. 12726 12727'DO_STMT' 12728 12729 Used to represent a 'do' loop. The body of the loop is given by 12730 'DO_BODY' while the termination condition for the loop is given by 12731 'DO_COND'. The condition for a 'do'-statement is always an 12732 expression. 12733 12734'EMPTY_CLASS_EXPR' 12735 12736 Used to represent a temporary object of a class with no data whose 12737 address is never taken. (All such objects are interchangeable.) 12738 The 'TREE_TYPE' represents the type of the object. 12739 12740'EXPR_STMT' 12741 12742 Used to represent an expression statement. Use 'EXPR_STMT_EXPR' to 12743 obtain the expression. 12744 12745'FOR_STMT' 12746 12747 Used to represent a 'for' statement. The 'FOR_INIT_STMT' is the 12748 initialization statement for the loop. The 'FOR_COND' is the 12749 termination condition. The 'FOR_EXPR' is the expression executed 12750 right before the 'FOR_COND' on each loop iteration; often, this 12751 expression increments a counter. The body of the loop is given by 12752 'FOR_BODY'. 'FOR_SCOPE' holds the scope of the 'for' statement 12753 (used in the C++ front end only). Note that 'FOR_INIT_STMT' and 12754 'FOR_BODY' return statements, while 'FOR_COND' and 'FOR_EXPR' 12755 return expressions. 12756 12757'HANDLER' 12758 12759 Used to represent a C++ 'catch' block. The 'HANDLER_TYPE' is the 12760 type of exception that will be caught by this handler; it is equal 12761 (by pointer equality) to 'NULL' if this handler is for all types. 12762 'HANDLER_PARMS' is the 'DECL_STMT' for the catch parameter, and 12763 'HANDLER_BODY' is the code for the block itself. 12764 12765'IF_STMT' 12766 12767 Used to represent an 'if' statement. The 'IF_COND' is the 12768 expression. 12769 12770 If the condition is a 'TREE_LIST', then the 'TREE_PURPOSE' is a 12771 statement (usually a 'DECL_STMT'). Each time the condition is 12772 evaluated, the statement should be executed. Then, the 12773 'TREE_VALUE' should be used as the conditional expression itself. 12774 This representation is used to handle C++ code like this: 12775 12776 if (int i = 7) ... 12777 12778 where there is a new local variable (or variables) declared within 12779 the condition. 12780 12781 The 'THEN_CLAUSE' represents the statement given by the 'then' 12782 condition, while the 'ELSE_CLAUSE' represents the statement given 12783 by the 'else' condition. 12784 12785 C++ distinguishes between this and 'COND_EXPR' for handling 12786 templates. 12787 12788'SUBOBJECT' 12789 12790 In a constructor, these nodes are used to mark the point at which a 12791 subobject of 'this' is fully constructed. If, after this point, an 12792 exception is thrown before a 'CTOR_STMT' with 'CTOR_END_P' set is 12793 encountered, the 'SUBOBJECT_CLEANUP' must be executed. The 12794 cleanups must be executed in the reverse order in which they 12795 appear. 12796 12797'SWITCH_STMT' 12798 12799 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 12800 the expression on which the switch is occurring. See the 12801 documentation for an 'IF_STMT' for more information on the 12802 representation used for the condition. The 'SWITCH_STMT_BODY' is 12803 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 12804 original type of switch expression as given in the source, before 12805 any compiler conversions. The 'SWITCH_STMT_SCOPE' is the statement 12806 scope (used in the C++ front end only). 12807 12808 There are also two boolean flags used with 'SWITCH_STMT'. 12809 'SWITCH_STMT_ALL_CASES_P' is true if the switch includes a default 12810 label or the case label ranges cover all possible values of the 12811 condition expression. 'SWITCH_STMT_NO_BREAK_P' is true if there 12812 are no 'break' statements in the switch. 12813 12814'TRY_BLOCK' 12815 Used to represent a 'try' block. The body of the try block is 12816 given by 'TRY_STMTS'. Each of the catch blocks is a 'HANDLER' 12817 node. The first handler is given by 'TRY_HANDLERS'. Subsequent 12818 handlers are obtained by following the 'TREE_CHAIN' link from one 12819 handler to the next. The body of the handler is given by 12820 'HANDLER_BODY'. 12821 12822 If 'CLEANUP_P' holds of the 'TRY_BLOCK', then the 'TRY_HANDLERS' 12823 will not be a 'HANDLER' node. Instead, it will be an expression 12824 that should be executed if an exception is thrown in the try block. 12825 It must rethrow the exception after executing that code. And, if 12826 an exception is thrown while the expression is executing, 12827 'terminate' must be called. 12828 12829'USING_STMT' 12830 Used to represent a 'using' directive. The namespace is given by 12831 'USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 12832 is needed inside template functions, to implement using directives 12833 during instantiation. 12834 12835'WHILE_STMT' 12836 12837 Used to represent a 'while' loop. The 'WHILE_COND' is the 12838 termination condition for the loop. See the documentation for an 12839 'IF_STMT' for more information on the representation used for the 12840 condition. 12841 12842 The 'WHILE_BODY' is the body of the loop. 12843 12844 12845File: gccint.info, Node: C++ Expressions, Prev: Statements for C and C++, Up: C and C++ Trees 12846 1284711.10.6 C++ Expressions 12848----------------------- 12849 12850This section describes expressions specific to the C and C++ front ends. 12851 12852'TYPEID_EXPR' 12853 12854 Used to represent a 'typeid' expression. 12855 12856'NEW_EXPR' 12857'VEC_NEW_EXPR' 12858 12859 Used to represent a call to 'new' and 'new[]' respectively. 12860 12861'DELETE_EXPR' 12862'VEC_DELETE_EXPR' 12863 12864 Used to represent a call to 'delete' and 'delete[]' respectively. 12865 12866'MEMBER_REF' 12867 12868 Represents a reference to a member of a class. 12869 12870'THROW_EXPR' 12871 12872 Represents an instance of 'throw' in the program. Operand 0, which 12873 is the expression to throw, may be 'NULL_TREE'. 12874 12875'AGGR_INIT_EXPR' 12876 An 'AGGR_INIT_EXPR' represents the initialization as the return 12877 value of a function call, or as the result of a constructor. An 12878 'AGGR_INIT_EXPR' will only appear as a full-expression, or as the 12879 second operand of a 'TARGET_EXPR'. 'AGGR_INIT_EXPR's have a 12880 representation similar to that of 'CALL_EXPR's. You can use the 12881 'AGGR_INIT_EXPR_FN' and 'AGGR_INIT_EXPR_ARG' macros to access the 12882 function to call and the arguments to pass. 12883 12884 If 'AGGR_INIT_VIA_CTOR_P' holds of the 'AGGR_INIT_EXPR', then the 12885 initialization is via a constructor call. The address of the 12886 'AGGR_INIT_EXPR_SLOT' operand, which is always a 'VAR_DECL', is 12887 taken, and this value replaces the first argument in the argument 12888 list. 12889 12890 In either case, the expression is void. 12891 12892 12893File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top 12894 1289512 GIMPLE 12896********* 12897 12898GIMPLE is a three-address representation derived from GENERIC by 12899breaking down GENERIC expressions into tuples of no more than 3 operands 12900(with some exceptions like function calls). GIMPLE was heavily 12901influenced by the SIMPLE IL used by the McCAT compiler project at McGill 12902University, though we have made some different choices. For one thing, 12903SIMPLE doesn't support 'goto'. 12904 12905 Temporaries are introduced to hold intermediate values needed to 12906compute complex expressions. Additionally, all the control structures 12907used in GENERIC are lowered into conditional jumps, lexical scopes are 12908removed and exception regions are converted into an on the side 12909exception region tree. 12910 12911 The compiler pass which converts GENERIC into GIMPLE is referred to as 12912the 'gimplifier'. The gimplifier works recursively, generating GIMPLE 12913tuples out of the original GENERIC expressions. 12914 12915 One of the early implementation strategies used for the GIMPLE 12916representation was to use the same internal data structures used by 12917front ends to represent parse trees. This simplified implementation 12918because we could leverage existing functionality and interfaces. 12919However, GIMPLE is a much more restrictive representation than abstract 12920syntax trees (AST), therefore it does not require the full structural 12921complexity provided by the main tree data structure. 12922 12923 The GENERIC representation of a function is stored in the 12924'DECL_SAVED_TREE' field of the associated 'FUNCTION_DECL' tree node. It 12925is converted to GIMPLE by a call to 'gimplify_function_tree'. 12926 12927 If a front end wants to include language-specific tree codes in the 12928tree representation which it provides to the back end, it must provide a 12929definition of 'LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 12930front end trees to GIMPLE. Usually such a hook will involve much of the 12931same code for expanding front end trees to RTL. This function can 12932return fully lowered GIMPLE, or it can return GENERIC trees and let the 12933main gimplifier lower them the rest of the way; this is often simpler. 12934GIMPLE that is not fully lowered is known as "High GIMPLE" and consists 12935of the IL before the pass 'pass_lower_cf'. High GIMPLE contains some 12936container statements like lexical scopes (represented by 'GIMPLE_BIND') 12937and nested expressions (e.g., 'GIMPLE_TRY'), while "Low GIMPLE" exposes 12938all of the implicit jumps for control and exception expressions directly 12939in the IL and EH region trees. 12940 12941 The C and C++ front ends currently convert directly from front end 12942trees to GIMPLE, and hand that off to the back end rather than first 12943converting to GENERIC. Their gimplifier hooks know about all the 12944'_STMT' nodes and how to convert them to GENERIC forms. There was some 12945work done on a genericization pass which would run first, but the 12946existence of 'STMT_EXPR' meant that in order to convert all of the C 12947statements into GENERIC equivalents would involve walking the entire 12948tree anyway, so it was simpler to lower all the way. This might change 12949in the future if someone writes an optimization pass which would work 12950better with higher-level trees, but currently the optimizers all expect 12951GIMPLE. 12952 12953 You can request to dump a C-like representation of the GIMPLE form with 12954the flag '-fdump-tree-gimple'. 12955 12956* Menu: 12957 12958* Tuple representation:: 12959* Class hierarchy of GIMPLE statements:: 12960* GIMPLE instruction set:: 12961* GIMPLE Exception Handling:: 12962* Temporaries:: 12963* Operands:: 12964* Manipulating GIMPLE statements:: 12965* Tuple specific accessors:: 12966* GIMPLE sequences:: 12967* Sequence iterators:: 12968* Adding a new GIMPLE statement code:: 12969* Statement and operand traversals:: 12970 12971 12972File: gccint.info, Node: Tuple representation, Next: Class hierarchy of GIMPLE statements, Up: GIMPLE 12973 1297412.1 Tuple representation 12975========================= 12976 12977GIMPLE instructions are tuples of variable size divided in two groups: a 12978header describing the instruction and its locations, and a variable 12979length body with all the operands. Tuples are organized into a 12980hierarchy with 3 main classes of tuples. 12981 1298212.1.1 'gimple' (gsbase) 12983------------------------ 12984 12985This is the root of the hierarchy, it holds basic information needed by 12986most GIMPLE statements. There are some fields that may not be relevant 12987to every GIMPLE statement, but those were moved into the base structure 12988to take advantage of holes left by other fields (thus making the 12989structure more compact). The structure takes 4 words (32 bytes) on 64 12990bit hosts: 12991 12992Field Size (bits) 12993'code' 8 12994'subcode' 16 12995'no_warning' 1 12996'visited' 1 12997'nontemporal_move' 1 12998'plf' 2 12999'modified' 1 13000'has_volatile_ops' 1 13001'references_memory_p' 1 13002'uid' 32 13003'location' 32 13004'num_ops' 32 13005'bb' 64 13006'block' 63 13007Total size 32 bytes 13008 13009 * 'code' Main identifier for a GIMPLE instruction. 13010 13011 * 'subcode' Used to distinguish different variants of the same basic 13012 instruction or provide flags applicable to a given code. The 13013 'subcode' flags field has different uses depending on the code of 13014 the instruction, but mostly it distinguishes instructions of the 13015 same family. The most prominent use of this field is in 13016 assignments, where subcode indicates the operation done on the RHS 13017 of the assignment. For example, a = b + c is encoded as 13018 'GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'. 13019 13020 * 'no_warning' Bitflag to indicate whether a warning has already been 13021 issued on this statement. 13022 13023 * 'visited' General purpose "visited" marker. Set and cleared by 13024 each pass when needed. 13025 13026 * 'nontemporal_move' Bitflag used in assignments that represent 13027 non-temporal moves. Although this bitflag is only used in 13028 assignments, it was moved into the base to take advantage of the 13029 bit holes left by the previous fields. 13030 13031 * 'plf' Pass Local Flags. This 2-bit mask can be used as general 13032 purpose markers by any pass. Passes are responsible for clearing 13033 and setting these two flags accordingly. 13034 13035 * 'modified' Bitflag to indicate whether the statement has been 13036 modified. Used mainly by the operand scanner to determine when to 13037 re-scan a statement for operands. 13038 13039 * 'has_volatile_ops' Bitflag to indicate whether this statement 13040 contains operands that have been marked volatile. 13041 13042 * 'references_memory_p' Bitflag to indicate whether this statement 13043 contains memory references (i.e., its operands are either global 13044 variables, or pointer dereferences or anything that must reside in 13045 memory). 13046 13047 * 'uid' This is an unsigned integer used by passes that want to 13048 assign IDs to every statement. These IDs must be assigned and used 13049 by each pass. 13050 13051 * 'location' This is a 'location_t' identifier to specify source code 13052 location for this statement. It is inherited from the front end. 13053 13054 * 'num_ops' Number of operands that this statement has. This 13055 specifies the size of the operand vector embedded in the tuple. 13056 Only used in some tuples, but it is declared in the base tuple to 13057 take advantage of the 32-bit hole left by the previous fields. 13058 13059 * 'bb' Basic block holding the instruction. 13060 13061 * 'block' Lexical block holding this statement. Also used for debug 13062 information generation. 13063 1306412.1.2 'gimple_statement_with_ops' 13065---------------------------------- 13066 13067This tuple is actually split in two: 'gimple_statement_with_ops_base' 13068and 'gimple_statement_with_ops'. This is needed to accommodate the way 13069the operand vector is allocated. The operand vector is defined to be an 13070array of 1 element. So, to allocate a dynamic number of operands, the 13071memory allocator ('gimple_alloc') simply allocates enough memory to hold 13072the structure itself plus 'N - 1' operands which run "off the end" of 13073the structure. For example, to allocate space for a tuple with 3 13074operands, 'gimple_alloc' reserves 'sizeof (struct 13075gimple_statement_with_ops) + 2 * sizeof (tree)' bytes. 13076 13077 On the other hand, several fields in this tuple need to be shared with 13078the 'gimple_statement_with_memory_ops' tuple. So, these common fields 13079are placed in 'gimple_statement_with_ops_base' which is then inherited 13080from the other two tuples. 13081 13082'gsbase' 256 13083'def_ops' 64 13084'use_ops' 64 13085'op' 'num_ops' * 64 13086Total 48 + 8 * 'num_ops' bytes 13087size 13088 13089 * 'gsbase' Inherited from 'struct gimple'. 13090 13091 * 'def_ops' Array of pointers into the operand array indicating all 13092 the slots that contain a variable written-to by the statement. 13093 This array is also used for immediate use chaining. Note that it 13094 would be possible to not rely on this array, but the changes 13095 required to implement this are pretty invasive. 13096 13097 * 'use_ops' Similar to 'def_ops' but for variables read by the 13098 statement. 13099 13100 * 'op' Array of trees with 'num_ops' slots. 13101 1310212.1.3 'gimple_statement_with_memory_ops' 13103----------------------------------------- 13104 13105This tuple is essentially identical to 'gimple_statement_with_ops', 13106except that it contains 4 additional fields to hold vectors related 13107memory stores and loads. Similar to the previous case, the structure is 13108split in two to accommodate for the operand vector 13109('gimple_statement_with_memory_ops_base' and 13110'gimple_statement_with_memory_ops'). 13111 13112Field Size (bits) 13113'gsbase' 256 13114'def_ops' 64 13115'use_ops' 64 13116'vdef_ops' 64 13117'vuse_ops' 64 13118'stores' 64 13119'loads' 64 13120'op' 'num_ops' * 64 13121Total size 80 + 8 * 'num_ops' bytes 13122 13123 * 'vdef_ops' Similar to 'def_ops' but for 'VDEF' operators. There is 13124 one entry per memory symbol written by this statement. This is 13125 used to maintain the memory SSA use-def and def-def chains. 13126 13127 * 'vuse_ops' Similar to 'use_ops' but for 'VUSE' operators. There is 13128 one entry per memory symbol loaded by this statement. This is used 13129 to maintain the memory SSA use-def chains. 13130 13131 * 'stores' Bitset with all the UIDs for the symbols written-to by the 13132 statement. This is different than 'vdef_ops' in that all the 13133 affected symbols are mentioned in this set. If memory partitioning 13134 is enabled, the 'vdef_ops' vector will refer to memory partitions. 13135 Furthermore, no SSA information is stored in this set. 13136 13137 * 'loads' Similar to 'stores', but for memory loads. (Note that 13138 there is some amount of redundancy here, it should be possible to 13139 reduce memory utilization further by removing these sets). 13140 13141 All the other tuples are defined in terms of these three basic ones. 13142Each tuple will add some fields. 13143 13144 13145File: gccint.info, Node: Class hierarchy of GIMPLE statements, Next: GIMPLE instruction set, Prev: Tuple representation, Up: GIMPLE 13146 1314712.2 Class hierarchy of GIMPLE statements 13148========================================= 13149 13150The following diagram shows the C++ inheritance hierarchy of statement 13151kinds, along with their relationships to 'GSS_' values (layouts) and 13152'GIMPLE_' values (codes): 13153 13154 gimple 13155 | layout: GSS_BASE 13156 | used for 4 codes: GIMPLE_ERROR_MARK 13157 | GIMPLE_NOP 13158 | GIMPLE_OMP_SECTIONS_SWITCH 13159 | GIMPLE_PREDICT 13160 | 13161 + gimple_statement_with_ops_base 13162 | | (no GSS layout) 13163 | | 13164 | + gimple_statement_with_ops 13165 | | | layout: GSS_WITH_OPS 13166 | | | 13167 | | + gcond 13168 | | | code: GIMPLE_COND 13169 | | | 13170 | | + gdebug 13171 | | | code: GIMPLE_DEBUG 13172 | | | 13173 | | + ggoto 13174 | | | code: GIMPLE_GOTO 13175 | | | 13176 | | + glabel 13177 | | | code: GIMPLE_LABEL 13178 | | | 13179 | | + gswitch 13180 | | code: GIMPLE_SWITCH 13181 | | 13182 | + gimple_statement_with_memory_ops_base 13183 | | layout: GSS_WITH_MEM_OPS_BASE 13184 | | 13185 | + gimple_statement_with_memory_ops 13186 | | | layout: GSS_WITH_MEM_OPS 13187 | | | 13188 | | + gassign 13189 | | | code GIMPLE_ASSIGN 13190 | | | 13191 | | + greturn 13192 | | code GIMPLE_RETURN 13193 | | 13194 | + gcall 13195 | | layout: GSS_CALL, code: GIMPLE_CALL 13196 | | 13197 | + gasm 13198 | | layout: GSS_ASM, code: GIMPLE_ASM 13199 | | 13200 | + gtransaction 13201 | layout: GSS_TRANSACTION, code: GIMPLE_TRANSACTION 13202 | 13203 + gimple_statement_omp 13204 | | layout: GSS_OMP. Used for code GIMPLE_OMP_SECTION 13205 | | 13206 | + gomp_critical 13207 | | layout: GSS_OMP_CRITICAL, code: GIMPLE_OMP_CRITICAL 13208 | | 13209 | + gomp_for 13210 | | layout: GSS_OMP_FOR, code: GIMPLE_OMP_FOR 13211 | | 13212 | + gomp_parallel_layout 13213 | | | layout: GSS_OMP_PARALLEL_LAYOUT 13214 | | | 13215 | | + gimple_statement_omp_taskreg 13216 | | | | 13217 | | | + gomp_parallel 13218 | | | | code: GIMPLE_OMP_PARALLEL 13219 | | | | 13220 | | | + gomp_task 13221 | | | code: GIMPLE_OMP_TASK 13222 | | | 13223 | | + gimple_statement_omp_target 13224 | | code: GIMPLE_OMP_TARGET 13225 | | 13226 | + gomp_sections 13227 | | layout: GSS_OMP_SECTIONS, code: GIMPLE_OMP_SECTIONS 13228 | | 13229 | + gimple_statement_omp_single_layout 13230 | | layout: GSS_OMP_SINGLE_LAYOUT 13231 | | 13232 | + gomp_single 13233 | | code: GIMPLE_OMP_SINGLE 13234 | | 13235 | + gomp_teams 13236 | code: GIMPLE_OMP_TEAMS 13237 | 13238 + gbind 13239 | layout: GSS_BIND, code: GIMPLE_BIND 13240 | 13241 + gcatch 13242 | layout: GSS_CATCH, code: GIMPLE_CATCH 13243 | 13244 + geh_filter 13245 | layout: GSS_EH_FILTER, code: GIMPLE_EH_FILTER 13246 | 13247 + geh_else 13248 | layout: GSS_EH_ELSE, code: GIMPLE_EH_ELSE 13249 | 13250 + geh_mnt 13251 | layout: GSS_EH_MNT, code: GIMPLE_EH_MUST_NOT_THROW 13252 | 13253 + gphi 13254 | layout: GSS_PHI, code: GIMPLE_PHI 13255 | 13256 + gimple_statement_eh_ctrl 13257 | | layout: GSS_EH_CTRL 13258 | | 13259 | + gresx 13260 | | code: GIMPLE_RESX 13261 | | 13262 | + geh_dispatch 13263 | code: GIMPLE_EH_DISPATCH 13264 | 13265 + gtry 13266 | layout: GSS_TRY, code: GIMPLE_TRY 13267 | 13268 + gimple_statement_wce 13269 | layout: GSS_WCE, code: GIMPLE_WITH_CLEANUP_EXPR 13270 | 13271 + gomp_continue 13272 | layout: GSS_OMP_CONTINUE, code: GIMPLE_OMP_CONTINUE 13273 | 13274 + gomp_atomic_load 13275 | layout: GSS_OMP_ATOMIC_LOAD, code: GIMPLE_OMP_ATOMIC_LOAD 13276 | 13277 + gimple_statement_omp_atomic_store_layout 13278 | layout: GSS_OMP_ATOMIC_STORE_LAYOUT, 13279 | code: GIMPLE_OMP_ATOMIC_STORE 13280 | 13281 + gomp_atomic_store 13282 | code: GIMPLE_OMP_ATOMIC_STORE 13283 | 13284 + gomp_return 13285 code: GIMPLE_OMP_RETURN 13286 13287 13288File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Class hierarchy of GIMPLE statements, Up: GIMPLE 13289 1329012.3 GIMPLE instruction set 13291=========================== 13292 13293The following table briefly describes the GIMPLE instruction set. 13294 13295Instruction High GIMPLE Low GIMPLE 13296'GIMPLE_ASM' x x 13297'GIMPLE_ASSIGN' x x 13298'GIMPLE_BIND' x 13299'GIMPLE_CALL' x x 13300'GIMPLE_CATCH' x 13301'GIMPLE_COND' x x 13302'GIMPLE_DEBUG' x x 13303'GIMPLE_EH_FILTER' x 13304'GIMPLE_GOTO' x x 13305'GIMPLE_LABEL' x x 13306'GIMPLE_NOP' x x 13307'GIMPLE_OMP_ATOMIC_LOAD' x x 13308'GIMPLE_OMP_ATOMIC_STORE' x x 13309'GIMPLE_OMP_CONTINUE' x x 13310'GIMPLE_OMP_CRITICAL' x x 13311'GIMPLE_OMP_FOR' x x 13312'GIMPLE_OMP_MASTER' x x 13313'GIMPLE_OMP_ORDERED' x x 13314'GIMPLE_OMP_PARALLEL' x x 13315'GIMPLE_OMP_RETURN' x x 13316'GIMPLE_OMP_SECTION' x x 13317'GIMPLE_OMP_SECTIONS' x x 13318'GIMPLE_OMP_SECTIONS_SWITCH' x x 13319'GIMPLE_OMP_SINGLE' x x 13320'GIMPLE_PHI' x 13321'GIMPLE_RESX' x 13322'GIMPLE_RETURN' x x 13323'GIMPLE_SWITCH' x x 13324'GIMPLE_TRY' x 13325 13326 13327File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE 13328 1332912.4 Exception Handling 13330======================= 13331 13332Other exception handling constructs are represented using 13333'GIMPLE_TRY_CATCH'. 'GIMPLE_TRY_CATCH' has two operands. The first 13334operand is a sequence of statements to execute. If executing these 13335statements does not throw an exception, then the second operand is 13336ignored. Otherwise, if an exception is thrown, then the second operand 13337of the 'GIMPLE_TRY_CATCH' is checked. The second operand may have the 13338following forms: 13339 13340 1. A sequence of statements to execute. When an exception occurs, 13341 these statements are executed, and then the exception is rethrown. 13342 13343 2. A sequence of 'GIMPLE_CATCH' statements. Each 'GIMPLE_CATCH' has a 13344 list of applicable exception types and handler code. If the thrown 13345 exception matches one of the caught types, the associated handler 13346 code is executed. If the handler code falls off the bottom, 13347 execution continues after the original 'GIMPLE_TRY_CATCH'. 13348 13349 3. A 'GIMPLE_EH_FILTER' statement. This has a list of permitted 13350 exception types, and code to handle a match failure. If the thrown 13351 exception does not match one of the allowed types, the associated 13352 match failure code is executed. If the thrown exception does 13353 match, it continues unwinding the stack looking for the next 13354 handler. 13355 13356 Currently throwing an exception is not directly represented in GIMPLE, 13357since it is implemented by calling a function. At some point in the 13358future we will want to add some way to express that the call will throw 13359an exception of a known type. 13360 13361 Just before running the optimizers, the compiler lowers the high-level 13362EH constructs above into a set of 'goto's, magic labels, and EH regions. 13363Continuing to unwind at the end of a cleanup is represented with a 13364'GIMPLE_RESX'. 13365 13366 13367File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE 13368 1336912.5 Temporaries 13370================ 13371 13372When gimplification encounters a subexpression that is too complex, it 13373creates a new temporary variable to hold the value of the subexpression, 13374and adds a new statement to initialize it before the current statement. 13375These special temporaries are known as 'expression temporaries', and are 13376allocated using 'get_formal_tmp_var'. The compiler tries to always 13377evaluate identical expressions into the same temporary, to simplify 13378elimination of redundant calculations. 13379 13380 We can only use expression temporaries when we know that it will not be 13381reevaluated before its value is used, and that it will not be otherwise 13382modified(1). Other temporaries can be allocated using 13383'get_initialized_tmp_var' or 'create_tmp_var'. 13384 13385 Currently, an expression like 'a = b + 5' is not reduced any further. 13386We tried converting it to something like 13387 T1 = b + 5; 13388 a = T1; 13389 but this bloated the representation for minimal benefit. However, a 13390variable which must live in memory cannot appear in an expression; its 13391value is explicitly loaded into a temporary first. Similarly, storing 13392the value of an expression to a memory variable goes through a 13393temporary. 13394 13395 ---------- Footnotes ---------- 13396 13397 (1) These restrictions are derived from those in Morgan 4.8. 13398 13399 13400File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE 13401 1340212.6 Operands 13403============= 13404 13405In general, expressions in GIMPLE consist of an operation and the 13406appropriate number of simple operands; these operands must either be a 13407GIMPLE rvalue ('is_gimple_val'), i.e. a constant or a register variable. 13408More complex operands are factored out into temporaries, so that 13409 a = b + c + d 13410 becomes 13411 T1 = b + c; 13412 a = T1 + d; 13413 13414 The same rule holds for arguments to a 'GIMPLE_CALL'. 13415 13416 The target of an assignment is usually a variable, but can also be a 13417'MEM_REF' or a compound lvalue as described below. 13418 13419* Menu: 13420 13421* Compound Expressions:: 13422* Compound Lvalues:: 13423* Conditional Expressions:: 13424* Logical Operators:: 13425 13426 13427File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands 13428 1342912.6.1 Compound Expressions 13430--------------------------- 13431 13432The left-hand side of a C comma expression is simply moved into a 13433separate statement. 13434 13435 13436File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands 13437 1343812.6.2 Compound Lvalues 13439----------------------- 13440 13441Currently compound lvalues involving array and structure field 13442references are not broken down; an expression like 'a.b[2] = 42' is not 13443reduced any further (though complex array subscripts are). This 13444restriction is a workaround for limitations in later optimizers; if we 13445were to convert this to 13446 13447 T1 = &a.b; 13448 T1[2] = 42; 13449 13450 alias analysis would not remember that the reference to 'T1[2]' came by 13451way of 'a.b', so it would think that the assignment could alias another 13452member of 'a'; this broke 'struct-alias-1.c'. Future optimizer 13453improvements may make this limitation unnecessary. 13454 13455 13456File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands 13457 1345812.6.3 Conditional Expressions 13459------------------------------ 13460 13461A C '?:' expression is converted into an 'if' statement with each branch 13462assigning to the same temporary. So, 13463 13464 a = b ? c : d; 13465 becomes 13466 if (b == 1) 13467 T1 = c; 13468 else 13469 T1 = d; 13470 a = T1; 13471 13472 The GIMPLE level if-conversion pass re-introduces '?:' expression, if 13473appropriate. It is used to vectorize loops with conditions using vector 13474conditional operations. 13475 13476 Note that in GIMPLE, 'if' statements are represented using 13477'GIMPLE_COND', as described below. 13478 13479 13480File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands 13481 1348212.6.4 Logical Operators 13483------------------------ 13484 13485Except when they appear in the condition operand of a 'GIMPLE_COND', 13486logical 'and' and 'or' operators are simplified as follows: 'a = b && c' 13487becomes 13488 13489 T1 = (bool)b; 13490 if (T1 == true) 13491 T1 = (bool)c; 13492 a = T1; 13493 13494 Note that 'T1' in this example cannot be an expression temporary, 13495because it has two different assignments. 13496 1349712.6.5 Manipulating operands 13498---------------------------- 13499 13500All gimple operands are of type 'tree'. But only certain types of trees 13501are allowed to be used as operand tuples. Basic validation is 13502controlled by the function 'get_gimple_rhs_class', which given a tree 13503code, returns an 'enum' with the following values of type 'enum 13504gimple_rhs_class' 13505 13506 * 'GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand. 13507 13508 * 'GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation. 13509 13510 * 'GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation. 13511 13512 * 'GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation. 13513 13514 * 'GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be 13515 split into simpler operands (for instance, 'SSA_NAME', 'VAR_DECL', 13516 'COMPONENT_REF', etc). 13517 13518 This operand class also acts as an escape hatch for tree nodes that 13519 may be flattened out into the operand vector, but would need more 13520 than two slots on the RHS. For instance, a 'COND_EXPR' expression 13521 of the form '(a op b) ? x : y' could be flattened out on the 13522 operand vector using 4 slots, but it would also require additional 13523 processing to distinguish 'c = a op b' from 'c = a op b ? x : y'. 13524 Something similar occurs with 'ASSERT_EXPR'. In time, these 13525 special case tree expressions should be flattened into the operand 13526 vector. 13527 13528 For tree nodes in the categories 'GIMPLE_TERNARY_RHS', 13529'GIMPLE_BINARY_RHS' and 'GIMPLE_UNARY_RHS', they cannot be stored inside 13530tuples directly. They first need to be flattened and separated into 13531individual components. For instance, given the GENERIC expression 13532 13533 a = b + c 13534 13535 its tree representation is: 13536 13537 MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> 13538 13539 In this case, the GIMPLE form for this statement is logically identical 13540to its GENERIC form but in GIMPLE, the 'PLUS_EXPR' on the RHS of the 13541assignment is not represented as a tree, instead the two operands are 13542taken out of the 'PLUS_EXPR' sub-tree and flattened into the GIMPLE 13543tuple as follows: 13544 13545 GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> 13546 1354712.6.6 Operand vector allocation 13548-------------------------------- 13549 13550The operand vector is stored at the bottom of the three tuple structures 13551that accept operands. This means, that depending on the code of a given 13552statement, its operand vector will be at different offsets from the base 13553of the structure. To access tuple operands use the following accessors 13554 13555 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 13556 Returns the number of operands in statement G. 13557 13558 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 13559 Returns operand 'I' from statement 'G'. 13560 13561 -- GIMPLE function: tree * gimple_ops (gimple g) 13562 Returns a pointer into the operand vector for statement 'G'. This 13563 is computed using an internal table called 'gimple_ops_offset_'[]. 13564 This table is indexed by the gimple code of 'G'. 13565 13566 When the compiler is built, this table is filled-in using the sizes 13567 of the structures used by each statement code defined in 13568 gimple.def. Since the operand vector is at the bottom of the 13569 structure, for a gimple code 'C' the offset is computed as sizeof 13570 (struct-of 'C') - sizeof (tree). 13571 13572 This mechanism adds one memory indirection to every access when 13573 using 'gimple_op'(), if this becomes a bottleneck, a pass can 13574 choose to memoize the result from 'gimple_ops'() and use that to 13575 access the operands. 13576 1357712.6.7 Operand validation 13578------------------------- 13579 13580When adding a new operand to a gimple statement, the operand will be 13581validated according to what each tuple accepts in its operand vector. 13582These predicates are called by the 'gimple_NAME_set_...()'. Each tuple 13583will use one of the following predicates (Note, this list is not 13584exhaustive): 13585 13586 -- GIMPLE function: bool is_gimple_val (tree t) 13587 Returns true if t is a "GIMPLE value", which are all the 13588 non-addressable stack variables (variables for which 13589 'is_gimple_reg' returns true) and constants (expressions for which 13590 'is_gimple_min_invariant' returns true). 13591 13592 -- GIMPLE function: bool is_gimple_addressable (tree t) 13593 Returns true if t is a symbol or memory reference whose address can 13594 be taken. 13595 13596 -- GIMPLE function: bool is_gimple_asm_val (tree t) 13597 Similar to 'is_gimple_val' but it also accepts hard registers. 13598 13599 -- GIMPLE function: bool is_gimple_call_addr (tree t) 13600 Return true if t is a valid expression to use as the function 13601 called by a 'GIMPLE_CALL'. 13602 13603 -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t) 13604 Return true if t is a valid expression to use as first operand of a 13605 'MEM_REF' expression. 13606 13607 -- GIMPLE function: bool is_gimple_constant (tree t) 13608 Return true if t is a valid gimple constant. 13609 13610 -- GIMPLE function: bool is_gimple_min_invariant (tree t) 13611 Return true if t is a valid minimal invariant. This is different 13612 from constants, in that the specific value of t may not be known at 13613 compile time, but it is known that it doesn't change (e.g., the 13614 address of a function local variable). 13615 13616 -- GIMPLE function: bool is_gimple_ip_invariant (tree t) 13617 Return true if t is an interprocedural invariant. This means that 13618 t is a valid invariant in all functions (e.g. it can be an address 13619 of a global variable but not of a local one). 13620 13621 -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t) 13622 Return true if t is an 'ADDR_EXPR' that does not change once the 13623 program is running (and which is valid in all functions). 13624 1362512.6.8 Statement validation 13626--------------------------- 13627 13628 -- GIMPLE function: bool is_gimple_assign (gimple g) 13629 Return true if the code of g is 'GIMPLE_ASSIGN'. 13630 13631 -- GIMPLE function: bool is_gimple_call (gimple g) 13632 Return true if the code of g is 'GIMPLE_CALL'. 13633 13634 -- GIMPLE function: bool is_gimple_debug (gimple g) 13635 Return true if the code of g is 'GIMPLE_DEBUG'. 13636 13637 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple g) 13638 Return true if g is a 'GIMPLE_ASSIGN' that performs a type cast 13639 operation. 13640 13641 -- GIMPLE function: bool gimple_debug_bind_p (gimple g) 13642 Return true if g is a 'GIMPLE_DEBUG' that binds the value of an 13643 expression to a variable. 13644 13645 -- GIMPLE function: bool is_gimple_omp (gimple g) 13646 Return true if g is any of the OpenMP codes. 13647 13648 -- GIMPLE function: bool gimple_debug_begin_stmt_p (gimple g) 13649 Return true if g is a 'GIMPLE_DEBUG' that marks the beginning of a 13650 source statement. 13651 13652 -- GIMPLE function: bool gimple_debug_inline_entry_p (gimple g) 13653 Return true if g is a 'GIMPLE_DEBUG' that marks the entry point of 13654 an inlined function. 13655 13656 -- GIMPLE function: bool gimple_debug_nonbind_marker_p (gimple g) 13657 Return true if g is a 'GIMPLE_DEBUG' that marks a program location, 13658 without any variable binding. 13659 13660 13661File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE 13662 1366312.7 Manipulating GIMPLE statements 13664=================================== 13665 13666This section documents all the functions available to handle each of the 13667GIMPLE instructions. 13668 1366912.7.1 Common accessors 13670----------------------- 13671 13672The following are common accessors for gimple statements. 13673 13674 -- GIMPLE function: enum gimple_code gimple_code (gimple g) 13675 Return the code for statement 'G'. 13676 13677 -- GIMPLE function: basic_block gimple_bb (gimple g) 13678 Return the basic block to which statement 'G' belongs to. 13679 13680 -- GIMPLE function: tree gimple_block (gimple g) 13681 Return the lexical scope block holding statement 'G'. 13682 13683 -- GIMPLE function: tree gimple_expr_type (gimple stmt) 13684 Return the type of the main expression computed by 'STMT'. Return 13685 'void_type_node' if 'STMT' computes nothing. This will only return 13686 something meaningful for 'GIMPLE_ASSIGN', 'GIMPLE_COND' and 13687 'GIMPLE_CALL'. For all other tuple codes, it will return 13688 'void_type_node'. 13689 13690 -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt) 13691 Return the tree code for the expression computed by 'STMT'. This 13692 is only meaningful for 'GIMPLE_CALL', 'GIMPLE_ASSIGN' and 13693 'GIMPLE_COND'. If 'STMT' is 'GIMPLE_CALL', it will return 13694 'CALL_EXPR'. For 'GIMPLE_COND', it returns the code of the 13695 comparison predicate. For 'GIMPLE_ASSIGN' it returns the code of 13696 the operation performed by the 'RHS' of the assignment. 13697 13698 -- GIMPLE function: void gimple_set_block (gimple g, tree block) 13699 Set the lexical scope block of 'G' to 'BLOCK'. 13700 13701 -- GIMPLE function: location_t gimple_locus (gimple g) 13702 Return locus information for statement 'G'. 13703 13704 -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus) 13705 Set locus information for statement 'G'. 13706 13707 -- GIMPLE function: bool gimple_locus_empty_p (gimple g) 13708 Return true if 'G' does not have locus information. 13709 13710 -- GIMPLE function: bool gimple_no_warning_p (gimple stmt) 13711 Return true if no warnings should be emitted for statement 'STMT'. 13712 13713 -- GIMPLE function: void gimple_set_visited (gimple stmt, bool 13714 visited_p) 13715 Set the visited status on statement 'STMT' to 'VISITED_P'. 13716 13717 -- GIMPLE function: bool gimple_visited_p (gimple stmt) 13718 Return the visited status on statement 'STMT'. 13719 13720 -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask 13721 plf, bool val_p) 13722 Set pass local flag 'PLF' on statement 'STMT' to 'VAL_P'. 13723 13724 -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum plf_mask 13725 plf) 13726 Return the value of pass local flag 'PLF' on statement 'STMT'. 13727 13728 -- GIMPLE function: bool gimple_has_ops (gimple g) 13729 Return true if statement 'G' has register or memory operands. 13730 13731 -- GIMPLE function: bool gimple_has_mem_ops (gimple g) 13732 Return true if statement 'G' has memory operands. 13733 13734 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 13735 Return the number of operands for statement 'G'. 13736 13737 -- GIMPLE function: tree * gimple_ops (gimple g) 13738 Return the array of operands for statement 'G'. 13739 13740 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 13741 Return operand 'I' for statement 'G'. 13742 13743 -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i) 13744 Return a pointer to operand 'I' for statement 'G'. 13745 13746 -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op) 13747 Set operand 'I' of statement 'G' to 'OP'. 13748 13749 -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt) 13750 Return the set of symbols that have had their address taken by 13751 'STMT'. 13752 13753 -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g) 13754 Return the set of 'DEF' operands for statement 'G'. 13755 13756 -- GIMPLE function: void gimple_set_def_ops (gimple g, struct 13757 def_optype_d *def) 13758 Set 'DEF' to be the set of 'DEF' operands for statement 'G'. 13759 13760 -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g) 13761 Return the set of 'USE' operands for statement 'G'. 13762 13763 -- GIMPLE function: void gimple_set_use_ops (gimple g, struct 13764 use_optype_d *use) 13765 Set 'USE' to be the set of 'USE' operands for statement 'G'. 13766 13767 -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g) 13768 Return the set of 'VUSE' operands for statement 'G'. 13769 13770 -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct 13771 voptype_d *ops) 13772 Set 'OPS' to be the set of 'VUSE' operands for statement 'G'. 13773 13774 -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g) 13775 Return the set of 'VDEF' operands for statement 'G'. 13776 13777 -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct 13778 voptype_d *ops) 13779 Set 'OPS' to be the set of 'VDEF' operands for statement 'G'. 13780 13781 -- GIMPLE function: bitmap gimple_loaded_syms (gimple g) 13782 Return the set of symbols loaded by statement 'G'. Each element of 13783 the set is the 'DECL_UID' of the corresponding symbol. 13784 13785 -- GIMPLE function: bitmap gimple_stored_syms (gimple g) 13786 Return the set of symbols stored by statement 'G'. Each element of 13787 the set is the 'DECL_UID' of the corresponding symbol. 13788 13789 -- GIMPLE function: bool gimple_modified_p (gimple g) 13790 Return true if statement 'G' has operands and the modified field 13791 has been set. 13792 13793 -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt) 13794 Return true if statement 'STMT' contains volatile operands. 13795 13796 -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, bool 13797 volatilep) 13798 Return true if statement 'STMT' contains volatile operands. 13799 13800 -- GIMPLE function: void update_stmt (gimple s) 13801 Mark statement 'S' as modified, and update it. 13802 13803 -- GIMPLE function: void update_stmt_if_modified (gimple s) 13804 Update statement 'S' if it has been marked modified. 13805 13806 -- GIMPLE function: gimple gimple_copy (gimple stmt) 13807 Return a deep copy of statement 'STMT'. 13808 13809 13810File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE 13811 1381212.8 Tuple specific accessors 13813============================= 13814 13815* Menu: 13816 13817* GIMPLE_ASM:: 13818* GIMPLE_ASSIGN:: 13819* GIMPLE_BIND:: 13820* GIMPLE_CALL:: 13821* GIMPLE_CATCH:: 13822* GIMPLE_COND:: 13823* GIMPLE_DEBUG:: 13824* GIMPLE_EH_FILTER:: 13825* GIMPLE_LABEL:: 13826* GIMPLE_GOTO:: 13827* GIMPLE_NOP:: 13828* GIMPLE_OMP_ATOMIC_LOAD:: 13829* GIMPLE_OMP_ATOMIC_STORE:: 13830* GIMPLE_OMP_CONTINUE:: 13831* GIMPLE_OMP_CRITICAL:: 13832* GIMPLE_OMP_FOR:: 13833* GIMPLE_OMP_MASTER:: 13834* GIMPLE_OMP_ORDERED:: 13835* GIMPLE_OMP_PARALLEL:: 13836* GIMPLE_OMP_RETURN:: 13837* GIMPLE_OMP_SECTION:: 13838* GIMPLE_OMP_SECTIONS:: 13839* GIMPLE_OMP_SINGLE:: 13840* GIMPLE_PHI:: 13841* GIMPLE_RESX:: 13842* GIMPLE_RETURN:: 13843* GIMPLE_SWITCH:: 13844* GIMPLE_TRY:: 13845* GIMPLE_WITH_CLEANUP_EXPR:: 13846 13847 13848File: gccint.info, Node: GIMPLE_ASM, Next: GIMPLE_ASSIGN, Up: Tuple specific accessors 13849 1385012.8.1 'GIMPLE_ASM' 13851------------------- 13852 13853 -- GIMPLE function: gasm *gimple_build_asm_vec ( const char *string, 13854 vec<tree, va_gc> *inputs, vec<tree, va_gc> *outputs, vec<tree, 13855 va_gc> *clobbers, vec<tree, va_gc> *labels) 13856 Build a 'GIMPLE_ASM' statement. This statement is used for 13857 building in-line assembly constructs. 'STRING' is the assembly 13858 code. 'INPUTS', 'OUTPUTS', 'CLOBBERS' and 'LABELS' are the inputs, 13859 outputs, clobbered registers and labels. 13860 13861 -- GIMPLE function: unsigned gimple_asm_ninputs (const gasm *g) 13862 Return the number of input operands for 'GIMPLE_ASM' 'G'. 13863 13864 -- GIMPLE function: unsigned gimple_asm_noutputs (const gasm *g) 13865 Return the number of output operands for 'GIMPLE_ASM' 'G'. 13866 13867 -- GIMPLE function: unsigned gimple_asm_nclobbers (const gasm *g) 13868 Return the number of clobber operands for 'GIMPLE_ASM' 'G'. 13869 13870 -- GIMPLE function: tree gimple_asm_input_op (const gasm *g, unsigned 13871 index) 13872 Return input operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13873 13874 -- GIMPLE function: void gimple_asm_set_input_op (gasm *g, unsigned 13875 index, tree in_op) 13876 Set 'IN_OP' to be input operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13877 13878 -- GIMPLE function: tree gimple_asm_output_op (const gasm *g, unsigned 13879 index) 13880 Return output operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13881 13882 -- GIMPLE function: void gimple_asm_set_output_op (gasm *g, unsigned 13883 index, tree out_op) 13884 Set 'OUT_OP' to be output operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13885 13886 -- GIMPLE function: tree gimple_asm_clobber_op (const gasm *g, unsigned 13887 index) 13888 Return clobber operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13889 13890 -- GIMPLE function: void gimple_asm_set_clobber_op (gasm *g, unsigned 13891 index, tree clobber_op) 13892 Set 'CLOBBER_OP' to be clobber operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13893 13894 -- GIMPLE function: const char * gimple_asm_string (const gasm *g) 13895 Return the string representing the assembly instruction in 13896 'GIMPLE_ASM' 'G'. 13897 13898 -- GIMPLE function: bool gimple_asm_volatile_p (const gasm *g) 13899 Return true if 'G' is an asm statement marked volatile. 13900 13901 -- GIMPLE function: void gimple_asm_set_volatile (gasm *g, bool 13902 volatile_p) 13903 Mark asm statement 'G' as volatile or non-volatile based on 13904 'VOLATILE_P'. 13905 13906 13907File: gccint.info, Node: GIMPLE_ASSIGN, Next: GIMPLE_BIND, Prev: GIMPLE_ASM, Up: Tuple specific accessors 13908 1390912.8.2 'GIMPLE_ASSIGN' 13910---------------------- 13911 13912 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, tree rhs) 13913 Build a 'GIMPLE_ASSIGN' statement. The left-hand side is an lvalue 13914 passed in lhs. The right-hand side can be either a unary or binary 13915 tree expression. The expression tree rhs will be flattened and its 13916 operands assigned to the corresponding operand slots in the new 13917 statement. This function is useful when you already have a tree 13918 expression that you want to convert into a tuple. However, try to 13919 avoid building expression trees for the sole purpose of calling 13920 this function. If you already have the operands in separate trees, 13921 it is better to use 'gimple_build_assign' with 'enum tree_code' 13922 argument and separate arguments for each operand. 13923 13924 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13925 tree_code subcode, tree op1, tree op2, tree op3) 13926 This function is similar to two operand 'gimple_build_assign', but 13927 is used to build a 'GIMPLE_ASSIGN' statement when the operands of 13928 the right-hand side of the assignment are already split into 13929 different operands. 13930 13931 The left-hand side is an lvalue passed in lhs. Subcode is the 13932 'tree_code' for the right-hand side of the assignment. Op1, op2 13933 and op3 are the operands. 13934 13935 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13936 tree_code subcode, tree op1, tree op2) 13937 Like the above 5 operand 'gimple_build_assign', but with the last 13938 argument 'NULL' - this overload should not be used for 13939 'GIMPLE_TERNARY_RHS' assignments. 13940 13941 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13942 tree_code subcode, tree op1) 13943 Like the above 4 operand 'gimple_build_assign', but with the last 13944 argument 'NULL' - this overload should be used only for 13945 'GIMPLE_UNARY_RHS' and 'GIMPLE_SINGLE_RHS' assignments. 13946 13947 -- GIMPLE function: gimple gimplify_assign (tree dst, tree src, 13948 gimple_seq *seq_p) 13949 Build a new 'GIMPLE_ASSIGN' tuple and append it to the end of 13950 '*SEQ_P'. 13951 13952 'DST'/'SRC' are the destination and source respectively. You can pass 13953ungimplified trees in 'DST' or 'SRC', in which case they will be 13954converted to a gimple operand if necessary. 13955 13956 This function returns the newly created 'GIMPLE_ASSIGN' tuple. 13957 13958 -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g) 13959 Return the code of the expression computed on the 'RHS' of 13960 assignment statement 'G'. 13961 13962 -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class 13963 (gimple g) 13964 Return the gimple rhs class of the code for the expression computed 13965 on the rhs of assignment statement 'G'. This will never return 13966 'GIMPLE_INVALID_RHS'. 13967 13968 -- GIMPLE function: tree gimple_assign_lhs (gimple g) 13969 Return the 'LHS' of assignment statement 'G'. 13970 13971 -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g) 13972 Return a pointer to the 'LHS' of assignment statement 'G'. 13973 13974 -- GIMPLE function: tree gimple_assign_rhs1 (gimple g) 13975 Return the first operand on the 'RHS' of assignment statement 'G'. 13976 13977 -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g) 13978 Return the address of the first operand on the 'RHS' of assignment 13979 statement 'G'. 13980 13981 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 13982 Return the second operand on the 'RHS' of assignment statement 'G'. 13983 13984 -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g) 13985 Return the address of the second operand on the 'RHS' of assignment 13986 statement 'G'. 13987 13988 -- GIMPLE function: tree gimple_assign_rhs3 (gimple g) 13989 Return the third operand on the 'RHS' of assignment statement 'G'. 13990 13991 -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g) 13992 Return the address of the third operand on the 'RHS' of assignment 13993 statement 'G'. 13994 13995 -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs) 13996 Set 'LHS' to be the 'LHS' operand of assignment statement 'G'. 13997 13998 -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs) 13999 Set 'RHS' to be the first operand on the 'RHS' of assignment 14000 statement 'G'. 14001 14002 -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs) 14003 Set 'RHS' to be the second operand on the 'RHS' of assignment 14004 statement 'G'. 14005 14006 -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs) 14007 Set 'RHS' to be the third operand on the 'RHS' of assignment 14008 statement 'G'. 14009 14010 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple s) 14011 Return true if 'S' is a type-cast assignment. 14012 14013 14014File: gccint.info, Node: GIMPLE_BIND, Next: GIMPLE_CALL, Prev: GIMPLE_ASSIGN, Up: Tuple specific accessors 14015 1401612.8.3 'GIMPLE_BIND' 14017-------------------- 14018 14019 -- GIMPLE function: gbind *gimple_build_bind (tree vars, gimple_seq 14020 body) 14021 Build a 'GIMPLE_BIND' statement with a list of variables in 'VARS' 14022 and a body of statements in sequence 'BODY'. 14023 14024 -- GIMPLE function: tree gimple_bind_vars (const gbind *g) 14025 Return the variables declared in the 'GIMPLE_BIND' statement 'G'. 14026 14027 -- GIMPLE function: void gimple_bind_set_vars (gbind *g, tree vars) 14028 Set 'VARS' to be the set of variables declared in the 'GIMPLE_BIND' 14029 statement 'G'. 14030 14031 -- GIMPLE function: void gimple_bind_append_vars (gbind *g, tree vars) 14032 Append 'VARS' to the set of variables declared in the 'GIMPLE_BIND' 14033 statement 'G'. 14034 14035 -- GIMPLE function: gimple_seq gimple_bind_body (gbind *g) 14036 Return the GIMPLE sequence contained in the 'GIMPLE_BIND' statement 14037 'G'. 14038 14039 -- GIMPLE function: void gimple_bind_set_body (gbind *g, gimple_seq 14040 seq) 14041 Set 'SEQ' to be sequence contained in the 'GIMPLE_BIND' statement 14042 'G'. 14043 14044 -- GIMPLE function: void gimple_bind_add_stmt (gbind *gs, gimple stmt) 14045 Append a statement to the end of a 'GIMPLE_BIND''s body. 14046 14047 -- GIMPLE function: void gimple_bind_add_seq (gbind *gs, gimple_seq 14048 seq) 14049 Append a sequence of statements to the end of a 'GIMPLE_BIND''s 14050 body. 14051 14052 -- GIMPLE function: tree gimple_bind_block (const gbind *g) 14053 Return the 'TREE_BLOCK' node associated with 'GIMPLE_BIND' 14054 statement 'G'. This is analogous to the 'BIND_EXPR_BLOCK' field in 14055 trees. 14056 14057 -- GIMPLE function: void gimple_bind_set_block (gbind *g, tree block) 14058 Set 'BLOCK' to be the 'TREE_BLOCK' node associated with 14059 'GIMPLE_BIND' statement 'G'. 14060 14061 14062File: gccint.info, Node: GIMPLE_CALL, Next: GIMPLE_CATCH, Prev: GIMPLE_BIND, Up: Tuple specific accessors 14063 1406412.8.4 'GIMPLE_CALL' 14065-------------------- 14066 14067 -- GIMPLE function: gcall *gimple_build_call (tree fn, unsigned nargs, 14068 ...) 14069 Build a 'GIMPLE_CALL' statement to function 'FN'. The argument 14070 'FN' must be either a 'FUNCTION_DECL' or a gimple call address as 14071 determined by 'is_gimple_call_addr'. 'NARGS' are the number of 14072 arguments. The rest of the arguments follow the argument 'NARGS', 14073 and must be trees that are valid as rvalues in gimple (i.e., each 14074 operand is validated with 'is_gimple_operand'). 14075 14076 -- GIMPLE function: gcall *gimple_build_call_from_tree (tree call_expr, 14077 tree fnptrtype) 14078 Build a 'GIMPLE_CALL' from a 'CALL_EXPR' node. The arguments and 14079 the function are taken from the expression directly. The type of 14080 the 'GIMPLE_CALL' is set from the second parameter passed by a 14081 caller. This routine assumes that 'call_expr' is already in GIMPLE 14082 form. That is, its operands are GIMPLE values and the function 14083 call needs no further simplification. All the call flags in 14084 'call_expr' are copied over to the new 'GIMPLE_CALL'. 14085 14086 -- GIMPLE function: gcall *gimple_build_call_vec (tree fn, 'vec<tree>' 14087 args) 14088 Identical to 'gimple_build_call' but the arguments are stored in a 14089 'vec<tree>'. 14090 14091 -- GIMPLE function: tree gimple_call_lhs (gimple g) 14092 Return the 'LHS' of call statement 'G'. 14093 14094 -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g) 14095 Return a pointer to the 'LHS' of call statement 'G'. 14096 14097 -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs) 14098 Set 'LHS' to be the 'LHS' operand of call statement 'G'. 14099 14100 -- GIMPLE function: tree gimple_call_fn (gimple g) 14101 Return the tree node representing the function called by call 14102 statement 'G'. 14103 14104 -- GIMPLE function: void gimple_call_set_fn (gcall *g, tree fn) 14105 Set 'FN' to be the function called by call statement 'G'. This has 14106 to be a gimple value specifying the address of the called function. 14107 14108 -- GIMPLE function: tree gimple_call_fndecl (gimple g) 14109 If a given 'GIMPLE_CALL''s callee is a 'FUNCTION_DECL', return it. 14110 Otherwise return 'NULL'. This function is analogous to 14111 'get_callee_fndecl' in 'GENERIC'. 14112 14113 -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl) 14114 Set the called function to 'FNDECL'. 14115 14116 -- GIMPLE function: tree gimple_call_return_type (const gcall *g) 14117 Return the type returned by call statement 'G'. 14118 14119 -- GIMPLE function: tree gimple_call_chain (gimple g) 14120 Return the static chain for call statement 'G'. 14121 14122 -- GIMPLE function: void gimple_call_set_chain (gcall *g, tree chain) 14123 Set 'CHAIN' to be the static chain for call statement 'G'. 14124 14125 -- GIMPLE function: unsigned gimple_call_num_args (gimple g) 14126 Return the number of arguments used by call statement 'G'. 14127 14128 -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index) 14129 Return the argument at position 'INDEX' for call statement 'G'. 14130 The first argument is 0. 14131 14132 -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned 14133 index) 14134 Return a pointer to the argument at position 'INDEX' for call 14135 statement 'G'. 14136 14137 -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned index, 14138 tree arg) 14139 Set 'ARG' to be the argument at position 'INDEX' for call statement 14140 'G'. 14141 14142 -- GIMPLE function: void gimple_call_set_tail (gcall *s) 14143 Mark call statement 'S' as being a tail call (i.e., a call just 14144 before the exit of a function). These calls are candidate for tail 14145 call optimization. 14146 14147 -- GIMPLE function: bool gimple_call_tail_p (gcall *s) 14148 Return true if 'GIMPLE_CALL' 'S' is marked as a tail call. 14149 14150 -- GIMPLE function: bool gimple_call_noreturn_p (gimple s) 14151 Return true if 'S' is a noreturn call. 14152 14153 -- GIMPLE function: gimple gimple_call_copy_skip_args (gcall *stmt, 14154 bitmap args_to_skip) 14155 Build a 'GIMPLE_CALL' identical to 'STMT' but skipping the 14156 arguments in the positions marked by the set 'ARGS_TO_SKIP'. 14157 14158 14159File: gccint.info, Node: GIMPLE_CATCH, Next: GIMPLE_COND, Prev: GIMPLE_CALL, Up: Tuple specific accessors 14160 1416112.8.5 'GIMPLE_CATCH' 14162--------------------- 14163 14164 -- GIMPLE function: gcatch *gimple_build_catch (tree types, gimple_seq 14165 handler) 14166 Build a 'GIMPLE_CATCH' statement. 'TYPES' are the tree types this 14167 catch handles. 'HANDLER' is a sequence of statements with the code 14168 for the handler. 14169 14170 -- GIMPLE function: tree gimple_catch_types (const gcatch *g) 14171 Return the types handled by 'GIMPLE_CATCH' statement 'G'. 14172 14173 -- GIMPLE function: tree * gimple_catch_types_ptr (gcatch *g) 14174 Return a pointer to the types handled by 'GIMPLE_CATCH' statement 14175 'G'. 14176 14177 -- GIMPLE function: gimple_seq gimple_catch_handler (gcatch *g) 14178 Return the GIMPLE sequence representing the body of the handler of 14179 'GIMPLE_CATCH' statement 'G'. 14180 14181 -- GIMPLE function: void gimple_catch_set_types (gcatch *g, tree t) 14182 Set 'T' to be the set of types handled by 'GIMPLE_CATCH' 'G'. 14183 14184 -- GIMPLE function: void gimple_catch_set_handler (gcatch *g, 14185 gimple_seq handler) 14186 Set 'HANDLER' to be the body of 'GIMPLE_CATCH' 'G'. 14187 14188 14189File: gccint.info, Node: GIMPLE_COND, Next: GIMPLE_DEBUG, Prev: GIMPLE_CATCH, Up: Tuple specific accessors 14190 1419112.8.6 'GIMPLE_COND' 14192-------------------- 14193 14194 -- GIMPLE function: gcond *gimple_build_cond ( enum tree_code 14195 pred_code, tree lhs, tree rhs, tree t_label, tree f_label) 14196 Build a 'GIMPLE_COND' statement. 'A' 'GIMPLE_COND' statement 14197 compares 'LHS' and 'RHS' and if the condition in 'PRED_CODE' is 14198 true, jump to the label in 't_label', otherwise jump to the label 14199 in 'f_label'. 'PRED_CODE' are relational operator tree codes like 14200 'EQ_EXPR', 'LT_EXPR', 'LE_EXPR', 'NE_EXPR', etc. 14201 14202 -- GIMPLE function: gcond *gimple_build_cond_from_tree (tree cond, tree 14203 t_label, tree f_label) 14204 Build a 'GIMPLE_COND' statement from the conditional expression 14205 tree 'COND'. 'T_LABEL' and 'F_LABEL' are as in 14206 'gimple_build_cond'. 14207 14208 -- GIMPLE function: enum tree_code gimple_cond_code (gimple g) 14209 Return the code of the predicate computed by conditional statement 14210 'G'. 14211 14212 -- GIMPLE function: void gimple_cond_set_code (gcond *g, enum tree_code 14213 code) 14214 Set 'CODE' to be the predicate code for the conditional statement 14215 'G'. 14216 14217 -- GIMPLE function: tree gimple_cond_lhs (gimple g) 14218 Return the 'LHS' of the predicate computed by conditional statement 14219 'G'. 14220 14221 -- GIMPLE function: void gimple_cond_set_lhs (gcond *g, tree lhs) 14222 Set 'LHS' to be the 'LHS' operand of the predicate computed by 14223 conditional statement 'G'. 14224 14225 -- GIMPLE function: tree gimple_cond_rhs (gimple g) 14226 Return the 'RHS' operand of the predicate computed by conditional 14227 'G'. 14228 14229 -- GIMPLE function: void gimple_cond_set_rhs (gcond *g, tree rhs) 14230 Set 'RHS' to be the 'RHS' operand of the predicate computed by 14231 conditional statement 'G'. 14232 14233 -- GIMPLE function: tree gimple_cond_true_label (const gcond *g) 14234 Return the label used by conditional statement 'G' when its 14235 predicate evaluates to true. 14236 14237 -- GIMPLE function: void gimple_cond_set_true_label (gcond *g, tree 14238 label) 14239 Set 'LABEL' to be the label used by conditional statement 'G' when 14240 its predicate evaluates to true. 14241 14242 -- GIMPLE function: void gimple_cond_set_false_label (gcond *g, tree 14243 label) 14244 Set 'LABEL' to be the label used by conditional statement 'G' when 14245 its predicate evaluates to false. 14246 14247 -- GIMPLE function: tree gimple_cond_false_label (const gcond *g) 14248 Return the label used by conditional statement 'G' when its 14249 predicate evaluates to false. 14250 14251 -- GIMPLE function: void gimple_cond_make_false (gcond *g) 14252 Set the conditional 'COND_STMT' to be of the form 'if (1 == 0)'. 14253 14254 -- GIMPLE function: void gimple_cond_make_true (gcond *g) 14255 Set the conditional 'COND_STMT' to be of the form 'if (1 == 1)'. 14256 14257 14258File: gccint.info, Node: GIMPLE_DEBUG, Next: GIMPLE_EH_FILTER, Prev: GIMPLE_COND, Up: Tuple specific accessors 14259 1426012.8.7 'GIMPLE_DEBUG' 14261--------------------- 14262 14263 -- GIMPLE function: gdebug *gimple_build_debug_bind (tree var, tree 14264 value, gimple stmt) 14265 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BIND' 14266 'subcode'. The effect of this statement is to tell debug 14267 information generation machinery that the value of user variable 14268 'var' is given by 'value' at that point, and to remain with that 14269 value until 'var' runs out of scope, a dynamically-subsequent debug 14270 bind statement overrides the binding, or conflicting values reach a 14271 control flow merge point. Even if components of the 'value' 14272 expression change afterwards, the variable is supposed to retain 14273 the same value, though not necessarily the same location. 14274 14275 It is expected that 'var' be most often a tree for automatic user 14276 variables ('VAR_DECL' or 'PARM_DECL') that satisfy the requirements 14277 for gimple registers, but it may also be a tree for a scalarized 14278 component of a user variable ('ARRAY_REF', 'COMPONENT_REF'), or a 14279 debug temporary ('DEBUG_EXPR_DECL'). 14280 14281 As for 'value', it can be an arbitrary tree expression, but it is 14282 recommended that it be in a suitable form for a gimple assignment 14283 'RHS'. It is not expected that user variables that could appear as 14284 'var' ever appear in 'value', because in the latter we'd have their 14285 'SSA_NAME's instead, but even if they were not in SSA form, user 14286 variables appearing in 'value' are to be regarded as part of the 14287 executable code space, whereas those in 'var' are to be regarded as 14288 part of the source code space. There is no way to refer to the 14289 value bound to a user variable within a 'value' expression. 14290 14291 If 'value' is 'GIMPLE_DEBUG_BIND_NOVALUE', debug information 14292 generation machinery is informed that the variable 'var' is 14293 unbound, i.e., that its value is indeterminate, which sometimes 14294 means it is really unavailable, and other times that the compiler 14295 could not keep track of it. 14296 14297 Block and location information for the newly-created stmt are taken 14298 from 'stmt', if given. 14299 14300 -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt) 14301 Return the user variable VAR that is bound at 'stmt'. 14302 14303 -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt) 14304 Return the value expression that is bound to a user variable at 14305 'stmt'. 14306 14307 -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple 14308 stmt) 14309 Return a pointer to the value expression that is bound to a user 14310 variable at 'stmt'. 14311 14312 -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree 14313 var) 14314 Modify the user variable bound at 'stmt' to VAR. 14315 14316 -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, tree 14317 var) 14318 Modify the value bound to the user variable bound at 'stmt' to 14319 VALUE. 14320 14321 -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt) 14322 Modify the value bound to the user variable bound at 'stmt' so that 14323 the variable becomes unbound. 14324 14325 -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt) 14326 Return 'TRUE' if 'stmt' binds a user variable to a value, and 14327 'FALSE' if it unbinds the variable. 14328 14329 -- GIMPLE function: gimple gimple_build_debug_begin_stmt (tree block, 14330 location_t location) 14331 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BEGIN_STMT' 14332 'subcode'. The effect of this statement is to tell debug 14333 information generation machinery that the user statement at the 14334 given 'location' and 'block' starts at the point at which the 14335 statement is inserted. The intent is that side effects (e.g. 14336 variable bindings) of all prior user statements are observable, and 14337 that none of the side effects of subsequent user statements are. 14338 14339 -- GIMPLE function: gimple gimple_build_debug_inline_entry (tree block, 14340 location_t location) 14341 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_INLINE_ENTRY' 14342 'subcode'. The effect of this statement is to tell debug 14343 information generation machinery that a function call at 'location' 14344 underwent inline substitution, that 'block' is the enclosing 14345 lexical block created for the substitution, and that at the point 14346 of the program in which the stmt is inserted, all parameters for 14347 the inlined function are bound to the respective arguments, and 14348 none of the side effects of its stmts are observable. 14349 14350 14351File: gccint.info, Node: GIMPLE_EH_FILTER, Next: GIMPLE_LABEL, Prev: GIMPLE_DEBUG, Up: Tuple specific accessors 14352 1435312.8.8 'GIMPLE_EH_FILTER' 14354------------------------- 14355 14356 -- GIMPLE function: geh_filter *gimple_build_eh_filter (tree types, 14357 gimple_seq failure) 14358 Build a 'GIMPLE_EH_FILTER' statement. 'TYPES' are the filter's 14359 types. 'FAILURE' is a sequence with the filter's failure action. 14360 14361 -- GIMPLE function: tree gimple_eh_filter_types (gimple g) 14362 Return the types handled by 'GIMPLE_EH_FILTER' statement 'G'. 14363 14364 -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g) 14365 Return a pointer to the types handled by 'GIMPLE_EH_FILTER' 14366 statement 'G'. 14367 14368 -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g) 14369 Return the sequence of statement to execute when 'GIMPLE_EH_FILTER' 14370 statement fails. 14371 14372 -- GIMPLE function: void gimple_eh_filter_set_types (geh_filter *g, 14373 tree types) 14374 Set 'TYPES' to be the set of types handled by 'GIMPLE_EH_FILTER' 14375 'G'. 14376 14377 -- GIMPLE function: void gimple_eh_filter_set_failure (geh_filter *g, 14378 gimple_seq failure) 14379 Set 'FAILURE' to be the sequence of statements to execute on 14380 failure for 'GIMPLE_EH_FILTER' 'G'. 14381 14382 -- GIMPLE function: tree gimple_eh_must_not_throw_fndecl ( geh_mnt 14383 *eh_mnt_stmt) 14384 Get the function decl to be called by the MUST_NOT_THROW region. 14385 14386 -- GIMPLE function: void gimple_eh_must_not_throw_set_fndecl ( geh_mnt 14387 *eh_mnt_stmt, tree decl) 14388 Set the function decl to be called by GS to DECL. 14389 14390 14391File: gccint.info, Node: GIMPLE_LABEL, Next: GIMPLE_GOTO, Prev: GIMPLE_EH_FILTER, Up: Tuple specific accessors 14392 1439312.8.9 'GIMPLE_LABEL' 14394--------------------- 14395 14396 -- GIMPLE function: glabel *gimple_build_label (tree label) 14397 Build a 'GIMPLE_LABEL' statement with corresponding to the tree 14398 label, 'LABEL'. 14399 14400 -- GIMPLE function: tree gimple_label_label (const glabel *g) 14401 Return the 'LABEL_DECL' node used by 'GIMPLE_LABEL' statement 'G'. 14402 14403 -- GIMPLE function: void gimple_label_set_label (glabel *g, tree label) 14404 Set 'LABEL' to be the 'LABEL_DECL' node used by 'GIMPLE_LABEL' 14405 statement 'G'. 14406 14407 14408File: gccint.info, Node: GIMPLE_GOTO, Next: GIMPLE_NOP, Prev: GIMPLE_LABEL, Up: Tuple specific accessors 14409 1441012.8.10 'GIMPLE_GOTO' 14411--------------------- 14412 14413 -- GIMPLE function: ggoto *gimple_build_goto (tree dest) 14414 Build a 'GIMPLE_GOTO' statement to label 'DEST'. 14415 14416 -- GIMPLE function: tree gimple_goto_dest (gimple g) 14417 Return the destination of the unconditional jump 'G'. 14418 14419 -- GIMPLE function: void gimple_goto_set_dest (ggoto *g, tree dest) 14420 Set 'DEST' to be the destination of the unconditional jump 'G'. 14421 14422 14423File: gccint.info, Node: GIMPLE_NOP, Next: GIMPLE_OMP_ATOMIC_LOAD, Prev: GIMPLE_GOTO, Up: Tuple specific accessors 14424 1442512.8.11 'GIMPLE_NOP' 14426-------------------- 14427 14428 -- GIMPLE function: gimple gimple_build_nop (void) 14429 Build a 'GIMPLE_NOP' statement. 14430 14431 -- GIMPLE function: bool gimple_nop_p (gimple g) 14432 Returns 'TRUE' if statement 'G' is a 'GIMPLE_NOP'. 14433 14434 14435File: gccint.info, Node: GIMPLE_OMP_ATOMIC_LOAD, Next: GIMPLE_OMP_ATOMIC_STORE, Prev: GIMPLE_NOP, Up: Tuple specific accessors 14436 1443712.8.12 'GIMPLE_OMP_ATOMIC_LOAD' 14438-------------------------------- 14439 14440 -- GIMPLE function: gomp_atomic_load *gimple_build_omp_atomic_load ( 14441 tree lhs, tree rhs) 14442 Build a 'GIMPLE_OMP_ATOMIC_LOAD' statement. 'LHS' is the left-hand 14443 side of the assignment. 'RHS' is the right-hand side of the 14444 assignment. 14445 14446 -- GIMPLE function: void gimple_omp_atomic_load_set_lhs ( 14447 gomp_atomic_load *g, tree lhs) 14448 Set the 'LHS' of an atomic load. 14449 14450 -- GIMPLE function: tree gimple_omp_atomic_load_lhs ( const 14451 gomp_atomic_load *g) 14452 Get the 'LHS' of an atomic load. 14453 14454 -- GIMPLE function: void gimple_omp_atomic_load_set_rhs ( 14455 gomp_atomic_load *g, tree rhs) 14456 Set the 'RHS' of an atomic set. 14457 14458 -- GIMPLE function: tree gimple_omp_atomic_load_rhs ( const 14459 gomp_atomic_load *g) 14460 Get the 'RHS' of an atomic set. 14461 14462 14463File: gccint.info, Node: GIMPLE_OMP_ATOMIC_STORE, Next: GIMPLE_OMP_CONTINUE, Prev: GIMPLE_OMP_ATOMIC_LOAD, Up: Tuple specific accessors 14464 1446512.8.13 'GIMPLE_OMP_ATOMIC_STORE' 14466--------------------------------- 14467 14468 -- GIMPLE function: gomp_atomic_store *gimple_build_omp_atomic_store ( 14469 tree val) 14470 Build a 'GIMPLE_OMP_ATOMIC_STORE' statement. 'VAL' is the value to 14471 be stored. 14472 14473 -- GIMPLE function: void gimple_omp_atomic_store_set_val ( 14474 gomp_atomic_store *g, tree val) 14475 Set the value being stored in an atomic store. 14476 14477 -- GIMPLE function: tree gimple_omp_atomic_store_val ( const 14478 gomp_atomic_store *g) 14479 Return the value being stored in an atomic store. 14480 14481 14482File: gccint.info, Node: GIMPLE_OMP_CONTINUE, Next: GIMPLE_OMP_CRITICAL, Prev: GIMPLE_OMP_ATOMIC_STORE, Up: Tuple specific accessors 14483 1448412.8.14 'GIMPLE_OMP_CONTINUE' 14485----------------------------- 14486 14487 -- GIMPLE function: gomp_continue *gimple_build_omp_continue ( tree 14488 control_def, tree control_use) 14489 Build a 'GIMPLE_OMP_CONTINUE' statement. 'CONTROL_DEF' is the 14490 definition of the control variable. 'CONTROL_USE' is the use of 14491 the control variable. 14492 14493 -- GIMPLE function: tree gimple_omp_continue_control_def ( const 14494 gomp_continue *s) 14495 Return the definition of the control variable on a 14496 'GIMPLE_OMP_CONTINUE' in 'S'. 14497 14498 -- GIMPLE function: tree gimple_omp_continue_control_def_ptr ( 14499 gomp_continue *s) 14500 Same as above, but return the pointer. 14501 14502 -- GIMPLE function: tree gimple_omp_continue_set_control_def ( 14503 gomp_continue *s) 14504 Set the control variable definition for a 'GIMPLE_OMP_CONTINUE' 14505 statement in 'S'. 14506 14507 -- GIMPLE function: tree gimple_omp_continue_control_use ( const 14508 gomp_continue *s) 14509 Return the use of the control variable on a 'GIMPLE_OMP_CONTINUE' 14510 in 'S'. 14511 14512 -- GIMPLE function: tree gimple_omp_continue_control_use_ptr ( 14513 gomp_continue *s) 14514 Same as above, but return the pointer. 14515 14516 -- GIMPLE function: tree gimple_omp_continue_set_control_use ( 14517 gomp_continue *s) 14518 Set the control variable use for a 'GIMPLE_OMP_CONTINUE' statement 14519 in 'S'. 14520 14521 14522File: gccint.info, Node: GIMPLE_OMP_CRITICAL, Next: GIMPLE_OMP_FOR, Prev: GIMPLE_OMP_CONTINUE, Up: Tuple specific accessors 14523 1452412.8.15 'GIMPLE_OMP_CRITICAL' 14525----------------------------- 14526 14527 -- GIMPLE function: gomp_critical *gimple_build_omp_critical ( 14528 gimple_seq body, tree name) 14529 Build a 'GIMPLE_OMP_CRITICAL' statement. 'BODY' is the sequence of 14530 statements for which only one thread can execute. 'NAME' is an 14531 optional identifier for this critical block. 14532 14533 -- GIMPLE function: tree gimple_omp_critical_name ( const gomp_critical 14534 *g) 14535 Return the name associated with 'OMP_CRITICAL' statement 'G'. 14536 14537 -- GIMPLE function: tree * gimple_omp_critical_name_ptr ( gomp_critical 14538 *g) 14539 Return a pointer to the name associated with 'OMP' critical 14540 statement 'G'. 14541 14542 -- GIMPLE function: void gimple_omp_critical_set_name ( gomp_critical 14543 *g, tree name) 14544 Set 'NAME' to be the name associated with 'OMP' critical statement 14545 'G'. 14546 14547 14548File: gccint.info, Node: GIMPLE_OMP_FOR, Next: GIMPLE_OMP_MASTER, Prev: GIMPLE_OMP_CRITICAL, Up: Tuple specific accessors 14549 1455012.8.16 'GIMPLE_OMP_FOR' 14551------------------------ 14552 14553 -- GIMPLE function: gomp_for *gimple_build_omp_for (gimple_seq body, 14554 tree clauses, tree index, tree initial, tree final, tree incr, 14555 gimple_seq pre_body, enum tree_code omp_for_cond) 14556 Build a 'GIMPLE_OMP_FOR' statement. 'BODY' is sequence of 14557 statements inside the for loop. 'CLAUSES', are any of the loop 14558 construct's clauses. 'PRE_BODY' is the sequence of statements that 14559 are loop invariant. 'INDEX' is the index variable. 'INITIAL' is 14560 the initial value of 'INDEX'. 'FINAL' is final value of 'INDEX'. 14561 OMP_FOR_COND is the predicate used to compare 'INDEX' and 'FINAL'. 14562 'INCR' is the increment expression. 14563 14564 -- GIMPLE function: tree gimple_omp_for_clauses (gimple g) 14565 Return the clauses associated with 'OMP_FOR' 'G'. 14566 14567 -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g) 14568 Return a pointer to the 'OMP_FOR' 'G'. 14569 14570 -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree 14571 clauses) 14572 Set 'CLAUSES' to be the list of clauses associated with 'OMP_FOR' 14573 'G'. 14574 14575 -- GIMPLE function: tree gimple_omp_for_index (gimple g) 14576 Return the index variable for 'OMP_FOR' 'G'. 14577 14578 -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g) 14579 Return a pointer to the index variable for 'OMP_FOR' 'G'. 14580 14581 -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree 14582 index) 14583 Set 'INDEX' to be the index variable for 'OMP_FOR' 'G'. 14584 14585 -- GIMPLE function: tree gimple_omp_for_initial (gimple g) 14586 Return the initial value for 'OMP_FOR' 'G'. 14587 14588 -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g) 14589 Return a pointer to the initial value for 'OMP_FOR' 'G'. 14590 14591 -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree 14592 initial) 14593 Set 'INITIAL' to be the initial value for 'OMP_FOR' 'G'. 14594 14595 -- GIMPLE function: tree gimple_omp_for_final (gimple g) 14596 Return the final value for 'OMP_FOR' 'G'. 14597 14598 -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g) 14599 turn a pointer to the final value for 'OMP_FOR' 'G'. 14600 14601 -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree 14602 final) 14603 Set 'FINAL' to be the final value for 'OMP_FOR' 'G'. 14604 14605 -- GIMPLE function: tree gimple_omp_for_incr (gimple g) 14606 Return the increment value for 'OMP_FOR' 'G'. 14607 14608 -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g) 14609 Return a pointer to the increment value for 'OMP_FOR' 'G'. 14610 14611 -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr) 14612 Set 'INCR' to be the increment value for 'OMP_FOR' 'G'. 14613 14614 -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g) 14615 Return the sequence of statements to execute before the 'OMP_FOR' 14616 statement 'G' starts. 14617 14618 -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g, 14619 gimple_seq pre_body) 14620 Set 'PRE_BODY' to be the sequence of statements to execute before 14621 the 'OMP_FOR' statement 'G' starts. 14622 14623 -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum 14624 tree_code cond) 14625 Set 'COND' to be the condition code for 'OMP_FOR' 'G'. 14626 14627 -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g) 14628 Return the condition code associated with 'OMP_FOR' 'G'. 14629 14630 14631File: gccint.info, Node: GIMPLE_OMP_MASTER, Next: GIMPLE_OMP_ORDERED, Prev: GIMPLE_OMP_FOR, Up: Tuple specific accessors 14632 1463312.8.17 'GIMPLE_OMP_MASTER' 14634--------------------------- 14635 14636 -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body) 14637 Build a 'GIMPLE_OMP_MASTER' statement. 'BODY' is the sequence of 14638 statements to be executed by just the master. 14639 14640 14641File: gccint.info, Node: GIMPLE_OMP_ORDERED, Next: GIMPLE_OMP_PARALLEL, Prev: GIMPLE_OMP_MASTER, Up: Tuple specific accessors 14642 1464312.8.18 'GIMPLE_OMP_ORDERED' 14644---------------------------- 14645 14646 -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body) 14647 Build a 'GIMPLE_OMP_ORDERED' statement. 14648 14649 'BODY' is the sequence of statements inside a loop that will executed 14650in sequence. 14651 14652 14653File: gccint.info, Node: GIMPLE_OMP_PARALLEL, Next: GIMPLE_OMP_RETURN, Prev: GIMPLE_OMP_ORDERED, Up: Tuple specific accessors 14654 1465512.8.19 'GIMPLE_OMP_PARALLEL' 14656----------------------------- 14657 14658 -- GIMPLE function: gomp_parallel *gimple_build_omp_parallel 14659 (gimple_seq body, tree clauses, tree child_fn, tree data_arg) 14660 Build a 'GIMPLE_OMP_PARALLEL' statement. 14661 14662 'BODY' is sequence of statements which are executed in parallel. 14663'CLAUSES', are the 'OMP' parallel construct's clauses. 'CHILD_FN' is 14664the function created for the parallel threads to execute. 'DATA_ARG' 14665are the shared data argument(s). 14666 14667 -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g) 14668 Return true if 'OMP' parallel statement 'G' has the 14669 'GF_OMP_PARALLEL_COMBINED' flag set. 14670 14671 -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g) 14672 Set the 'GF_OMP_PARALLEL_COMBINED' field in 'OMP' parallel 14673 statement 'G'. 14674 14675 -- GIMPLE function: gimple_seq gimple_omp_body (gimple g) 14676 Return the body for the 'OMP' statement 'G'. 14677 14678 -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq 14679 body) 14680 Set 'BODY' to be the body for the 'OMP' statement 'G'. 14681 14682 -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g) 14683 Return the clauses associated with 'OMP_PARALLEL' 'G'. 14684 14685 -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr ( 14686 gomp_parallel *g) 14687 Return a pointer to the clauses associated with 'OMP_PARALLEL' 'G'. 14688 14689 -- GIMPLE function: void gimple_omp_parallel_set_clauses ( 14690 gomp_parallel *g, tree clauses) 14691 Set 'CLAUSES' to be the list of clauses associated with 14692 'OMP_PARALLEL' 'G'. 14693 14694 -- GIMPLE function: tree gimple_omp_parallel_child_fn ( const 14695 gomp_parallel *g) 14696 Return the child function used to hold the body of 'OMP_PARALLEL' 14697 'G'. 14698 14699 -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr ( 14700 gomp_parallel *g) 14701 Return a pointer to the child function used to hold the body of 14702 'OMP_PARALLEL' 'G'. 14703 14704 -- GIMPLE function: void gimple_omp_parallel_set_child_fn ( 14705 gomp_parallel *g, tree child_fn) 14706 Set 'CHILD_FN' to be the child function for 'OMP_PARALLEL' 'G'. 14707 14708 -- GIMPLE function: tree gimple_omp_parallel_data_arg ( const 14709 gomp_parallel *g) 14710 Return the artificial argument used to send variables and values 14711 from the parent to the children threads in 'OMP_PARALLEL' 'G'. 14712 14713 -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr ( 14714 gomp_parallel *g) 14715 Return a pointer to the data argument for 'OMP_PARALLEL' 'G'. 14716 14717 -- GIMPLE function: void gimple_omp_parallel_set_data_arg ( 14718 gomp_parallel *g, tree data_arg) 14719 Set 'DATA_ARG' to be the data argument for 'OMP_PARALLEL' 'G'. 14720 14721 14722File: gccint.info, Node: GIMPLE_OMP_RETURN, Next: GIMPLE_OMP_SECTION, Prev: GIMPLE_OMP_PARALLEL, Up: Tuple specific accessors 14723 1472412.8.20 'GIMPLE_OMP_RETURN' 14725--------------------------- 14726 14727 -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p) 14728 Build a 'GIMPLE_OMP_RETURN' statement. 'WAIT_P' is true if this is 14729 a non-waiting return. 14730 14731 -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s) 14732 Set the nowait flag on 'GIMPLE_OMP_RETURN' statement 'S'. 14733 14734 -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g) 14735 Return true if 'OMP' return statement 'G' has the 14736 'GF_OMP_RETURN_NOWAIT' flag set. 14737 14738 14739File: gccint.info, Node: GIMPLE_OMP_SECTION, Next: GIMPLE_OMP_SECTIONS, Prev: GIMPLE_OMP_RETURN, Up: Tuple specific accessors 14740 1474112.8.21 'GIMPLE_OMP_SECTION' 14742---------------------------- 14743 14744 -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body) 14745 Build a 'GIMPLE_OMP_SECTION' statement for a sections statement. 14746 14747 'BODY' is the sequence of statements in the section. 14748 14749 -- GIMPLE function: bool gimple_omp_section_last_p (gimple g) 14750 Return true if 'OMP' section statement 'G' has the 14751 'GF_OMP_SECTION_LAST' flag set. 14752 14753 -- GIMPLE function: void gimple_omp_section_set_last (gimple g) 14754 Set the 'GF_OMP_SECTION_LAST' flag on 'G'. 14755 14756 14757File: gccint.info, Node: GIMPLE_OMP_SECTIONS, Next: GIMPLE_OMP_SINGLE, Prev: GIMPLE_OMP_SECTION, Up: Tuple specific accessors 14758 1475912.8.22 'GIMPLE_OMP_SECTIONS' 14760----------------------------- 14761 14762 -- GIMPLE function: gomp_sections *gimple_build_omp_sections ( 14763 gimple_seq body, tree clauses) 14764 Build a 'GIMPLE_OMP_SECTIONS' statement. 'BODY' is a sequence of 14765 section statements. 'CLAUSES' are any of the 'OMP' sections 14766 construct's clauses: private, firstprivate, lastprivate, reduction, 14767 and nowait. 14768 14769 -- GIMPLE function: gimple gimple_build_omp_sections_switch (void) 14770 Build a 'GIMPLE_OMP_SECTIONS_SWITCH' statement. 14771 14772 -- GIMPLE function: tree gimple_omp_sections_control (gimple g) 14773 Return the control variable associated with the 14774 'GIMPLE_OMP_SECTIONS' in 'G'. 14775 14776 -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g) 14777 Return a pointer to the clauses associated with the 14778 'GIMPLE_OMP_SECTIONS' in 'G'. 14779 14780 -- GIMPLE function: void gimple_omp_sections_set_control (gimple g, 14781 tree control) 14782 Set 'CONTROL' to be the set of clauses associated with the 14783 'GIMPLE_OMP_SECTIONS' in 'G'. 14784 14785 -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g) 14786 Return the clauses associated with 'OMP_SECTIONS' 'G'. 14787 14788 -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g) 14789 Return a pointer to the clauses associated with 'OMP_SECTIONS' 'G'. 14790 14791 -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g, 14792 tree clauses) 14793 Set 'CLAUSES' to be the set of clauses associated with 14794 'OMP_SECTIONS' 'G'. 14795 14796 14797File: gccint.info, Node: GIMPLE_OMP_SINGLE, Next: GIMPLE_PHI, Prev: GIMPLE_OMP_SECTIONS, Up: Tuple specific accessors 14798 1479912.8.23 'GIMPLE_OMP_SINGLE' 14800--------------------------- 14801 14802 -- GIMPLE function: gomp_single *gimple_build_omp_single ( gimple_seq 14803 body, tree clauses) 14804 Build a 'GIMPLE_OMP_SINGLE' statement. 'BODY' is the sequence of 14805 statements that will be executed once. 'CLAUSES' are any of the 14806 'OMP' single construct's clauses: private, firstprivate, 14807 copyprivate, nowait. 14808 14809 -- GIMPLE function: tree gimple_omp_single_clauses (gimple g) 14810 Return the clauses associated with 'OMP_SINGLE' 'G'. 14811 14812 -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g) 14813 Return a pointer to the clauses associated with 'OMP_SINGLE' 'G'. 14814 14815 -- GIMPLE function: void gimple_omp_single_set_clauses ( gomp_single 14816 *g, tree clauses) 14817 Set 'CLAUSES' to be the clauses associated with 'OMP_SINGLE' 'G'. 14818 14819 14820File: gccint.info, Node: GIMPLE_PHI, Next: GIMPLE_RESX, Prev: GIMPLE_OMP_SINGLE, Up: Tuple specific accessors 14821 1482212.8.24 'GIMPLE_PHI' 14823-------------------- 14824 14825 -- GIMPLE function: unsigned gimple_phi_capacity (gimple g) 14826 Return the maximum number of arguments supported by 'GIMPLE_PHI' 14827 'G'. 14828 14829 -- GIMPLE function: unsigned gimple_phi_num_args (gimple g) 14830 Return the number of arguments in 'GIMPLE_PHI' 'G'. This must 14831 always be exactly the number of incoming edges for the basic block 14832 holding 'G'. 14833 14834 -- GIMPLE function: tree gimple_phi_result (gimple g) 14835 Return the 'SSA' name created by 'GIMPLE_PHI' 'G'. 14836 14837 -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g) 14838 Return a pointer to the 'SSA' name created by 'GIMPLE_PHI' 'G'. 14839 14840 -- GIMPLE function: void gimple_phi_set_result (gphi *g, tree result) 14841 Set 'RESULT' to be the 'SSA' name created by 'GIMPLE_PHI' 'G'. 14842 14843 -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index) 14844 Return the 'PHI' argument corresponding to incoming edge 'INDEX' 14845 for 'GIMPLE_PHI' 'G'. 14846 14847 -- GIMPLE function: void gimple_phi_set_arg (gphi *g, index, struct 14848 phi_arg_d * phiarg) 14849 Set 'PHIARG' to be the argument corresponding to incoming edge 14850 'INDEX' for 'GIMPLE_PHI' 'G'. 14851 14852 14853File: gccint.info, Node: GIMPLE_RESX, Next: GIMPLE_RETURN, Prev: GIMPLE_PHI, Up: Tuple specific accessors 14854 1485512.8.25 'GIMPLE_RESX' 14856--------------------- 14857 14858 -- GIMPLE function: gresx *gimple_build_resx (int region) 14859 Build a 'GIMPLE_RESX' statement which is a statement. This 14860 statement is a placeholder for _Unwind_Resume before we know if a 14861 function call or a branch is needed. 'REGION' is the exception 14862 region from which control is flowing. 14863 14864 -- GIMPLE function: int gimple_resx_region (const gresx *g) 14865 Return the region number for 'GIMPLE_RESX' 'G'. 14866 14867 -- GIMPLE function: void gimple_resx_set_region (gresx *g, int region) 14868 Set 'REGION' to be the region number for 'GIMPLE_RESX' 'G'. 14869 14870 14871File: gccint.info, Node: GIMPLE_RETURN, Next: GIMPLE_SWITCH, Prev: GIMPLE_RESX, Up: Tuple specific accessors 14872 1487312.8.26 'GIMPLE_RETURN' 14874----------------------- 14875 14876 -- GIMPLE function: greturn *gimple_build_return (tree retval) 14877 Build a 'GIMPLE_RETURN' statement whose return value is retval. 14878 14879 -- GIMPLE function: tree gimple_return_retval (const greturn *g) 14880 Return the return value for 'GIMPLE_RETURN' 'G'. 14881 14882 -- GIMPLE function: void gimple_return_set_retval (greturn *g, tree 14883 retval) 14884 Set 'RETVAL' to be the return value for 'GIMPLE_RETURN' 'G'. 14885 14886 14887File: gccint.info, Node: GIMPLE_SWITCH, Next: GIMPLE_TRY, Prev: GIMPLE_RETURN, Up: Tuple specific accessors 14888 1488912.8.27 'GIMPLE_SWITCH' 14890----------------------- 14891 14892 -- GIMPLE function: gswitch *gimple_build_switch (tree index, tree 14893 default_label, 'vec'<tree> *args) 14894 Build a 'GIMPLE_SWITCH' statement. 'INDEX' is the index variable 14895 to switch on, and 'DEFAULT_LABEL' represents the default label. 14896 'ARGS' is a vector of 'CASE_LABEL_EXPR' trees that contain the 14897 non-default case labels. Each label is a tree of code 14898 'CASE_LABEL_EXPR'. 14899 14900 -- GIMPLE function: unsigned gimple_switch_num_labels ( const gswitch 14901 *g) 14902 Return the number of labels associated with the switch statement 14903 'G'. 14904 14905 -- GIMPLE function: void gimple_switch_set_num_labels (gswitch *g, 14906 unsigned nlabels) 14907 Set 'NLABELS' to be the number of labels for the switch statement 14908 'G'. 14909 14910 -- GIMPLE function: tree gimple_switch_index (const gswitch *g) 14911 Return the index variable used by the switch statement 'G'. 14912 14913 -- GIMPLE function: void gimple_switch_set_index (gswitch *g, tree 14914 index) 14915 Set 'INDEX' to be the index variable for switch statement 'G'. 14916 14917 -- GIMPLE function: tree gimple_switch_label (const gswitch *g, 14918 unsigned index) 14919 Return the label numbered 'INDEX'. The default label is 0, 14920 followed by any labels in a switch statement. 14921 14922 -- GIMPLE function: void gimple_switch_set_label (gswitch *g, unsigned 14923 index, tree label) 14924 Set the label number 'INDEX' to 'LABEL'. 0 is always the default 14925 label. 14926 14927 -- GIMPLE function: tree gimple_switch_default_label ( const gswitch 14928 *g) 14929 Return the default label for a switch statement. 14930 14931 -- GIMPLE function: void gimple_switch_set_default_label (gswitch *g, 14932 tree label) 14933 Set the default label for a switch statement. 14934 14935 14936File: gccint.info, Node: GIMPLE_TRY, Next: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_SWITCH, Up: Tuple specific accessors 14937 1493812.8.28 'GIMPLE_TRY' 14939-------------------- 14940 14941 -- GIMPLE function: gtry *gimple_build_try (gimple_seq eval, gimple_seq 14942 cleanup, unsigned int kind) 14943 Build a 'GIMPLE_TRY' statement. 'EVAL' is a sequence with the 14944 expression to evaluate. 'CLEANUP' is a sequence of statements to 14945 run at clean-up time. 'KIND' is the enumeration value 14946 'GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct 14947 or 'GIMPLE_TRY_FINALLY' if this statement denotes a try/finally 14948 construct. 14949 14950 -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g) 14951 Return the kind of try block represented by 'GIMPLE_TRY' 'G'. This 14952 is either 'GIMPLE_TRY_CATCH' or 'GIMPLE_TRY_FINALLY'. 14953 14954 -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g) 14955 Return the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 14956 14957 -- GIMPLE function: gimple_seq gimple_try_eval (gimple g) 14958 Return the sequence of statements used as the body for 'GIMPLE_TRY' 14959 'G'. 14960 14961 -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g) 14962 Return the sequence of statements used as the cleanup body for 14963 'GIMPLE_TRY' 'G'. 14964 14965 -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g, 14966 bool catch_is_cleanup) 14967 Set the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 14968 14969 -- GIMPLE function: void gimple_try_set_eval (gtry *g, gimple_seq eval) 14970 Set 'EVAL' to be the sequence of statements to use as the body for 14971 'GIMPLE_TRY' 'G'. 14972 14973 -- GIMPLE function: void gimple_try_set_cleanup (gtry *g, gimple_seq 14974 cleanup) 14975 Set 'CLEANUP' to be the sequence of statements to use as the 14976 cleanup body for 'GIMPLE_TRY' 'G'. 14977 14978 14979File: gccint.info, Node: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_TRY, Up: Tuple specific accessors 14980 1498112.8.29 'GIMPLE_WITH_CLEANUP_EXPR' 14982---------------------------------- 14983 14984 -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup) 14985 Build a 'GIMPLE_WITH_CLEANUP_EXPR' statement. 'CLEANUP' is the 14986 clean-up expression. 14987 14988 -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g) 14989 Return the cleanup sequence for cleanup statement 'G'. 14990 14991 -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq 14992 cleanup) 14993 Set 'CLEANUP' to be the cleanup sequence for 'G'. 14994 14995 -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g) 14996 Return the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 14997 14998 -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, bool 14999 eh_only_p) 15000 Set the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 15001 15002 15003File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE 15004 1500512.9 GIMPLE sequences 15006===================== 15007 15008GIMPLE sequences are the tuple equivalent of 'STATEMENT_LIST''s used in 15009'GENERIC'. They are used to chain statements together, and when used in 15010conjunction with sequence iterators, provide a framework for iterating 15011through statements. 15012 15013 GIMPLE sequences are of type struct 'gimple_sequence', but are more 15014commonly passed by reference to functions dealing with sequences. The 15015type for a sequence pointer is 'gimple_seq' which is the same as struct 15016'gimple_sequence' *. When declaring a local sequence, you can define a 15017local variable of type struct 'gimple_sequence'. When declaring a 15018sequence allocated on the garbage collected heap, use the function 15019'gimple_seq_alloc' documented below. 15020 15021 There are convenience functions for iterating through sequences in the 15022section entitled Sequence Iterators. 15023 15024 Below is a list of functions to manipulate and query sequences. 15025 15026 -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple 15027 g) 15028 Link a gimple statement to the end of the sequence *'SEQ' if 'G' is 15029 not 'NULL'. If *'SEQ' is 'NULL', allocate a sequence before 15030 linking. 15031 15032 -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest, 15033 gimple_seq src) 15034 Append sequence 'SRC' to the end of sequence *'DEST' if 'SRC' is 15035 not 'NULL'. If *'DEST' is 'NULL', allocate a new sequence before 15036 appending. 15037 15038 -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src) 15039 Perform a deep copy of sequence 'SRC' and return the result. 15040 15041 -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq) 15042 Reverse the order of the statements in the sequence 'SEQ'. Return 15043 'SEQ'. 15044 15045 -- GIMPLE function: gimple gimple_seq_first (gimple_seq s) 15046 Return the first statement in sequence 'S'. 15047 15048 -- GIMPLE function: gimple gimple_seq_last (gimple_seq s) 15049 Return the last statement in sequence 'S'. 15050 15051 -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple 15052 last) 15053 Set the last statement in sequence 'S' to the statement in 'LAST'. 15054 15055 -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple 15056 first) 15057 Set the first statement in sequence 'S' to the statement in 15058 'FIRST'. 15059 15060 -- GIMPLE function: void gimple_seq_init (gimple_seq s) 15061 Initialize sequence 'S' to an empty sequence. 15062 15063 -- GIMPLE function: gimple_seq gimple_seq_alloc (void) 15064 Allocate a new sequence in the garbage collected store and return 15065 it. 15066 15067 -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq 15068 src) 15069 Copy the sequence 'SRC' into the sequence 'DEST'. 15070 15071 -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s) 15072 Return true if the sequence 'S' is empty. 15073 15074 -- GIMPLE function: gimple_seq bb_seq (basic_block bb) 15075 Returns the sequence of statements in 'BB'. 15076 15077 -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq) 15078 Sets the sequence of statements in 'BB' to 'SEQ'. 15079 15080 -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq) 15081 Determine whether 'SEQ' contains exactly one statement. 15082 15083 15084File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE 15085 1508612.10 Sequence iterators 15087======================== 15088 15089Sequence iterators are convenience constructs for iterating through 15090statements in a sequence. Given a sequence 'SEQ', here is a typical use 15091of gimple sequence iterators: 15092 15093 gimple_stmt_iterator gsi; 15094 15095 for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi)) 15096 { 15097 gimple g = gsi_stmt (gsi); 15098 /* Do something with gimple statement G. */ 15099 } 15100 15101 Backward iterations are possible: 15102 15103 for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi)) 15104 15105 Forward and backward iterations on basic blocks are possible with 15106'gsi_start_bb' and 'gsi_last_bb'. 15107 15108 In the documentation below we sometimes refer to enum 15109'gsi_iterator_update'. The valid options for this enumeration are: 15110 15111 * 'GSI_NEW_STMT' Only valid when a single statement is added. Move 15112 the iterator to it. 15113 15114 * 'GSI_SAME_STMT' Leave the iterator at the same statement. 15115 15116 * 'GSI_CONTINUE_LINKING' Move iterator to whatever position is 15117 suitable for linking other statements in the same direction. 15118 15119 Below is a list of the functions used to manipulate and use statement 15120iterators. 15121 15122 -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq) 15123 Return a new iterator pointing to the sequence 'SEQ''s first 15124 statement. If 'SEQ' is empty, the iterator's basic block is 15125 'NULL'. Use 'gsi_start_bb' instead when the iterator needs to 15126 always have the correct basic block set. 15127 15128 -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb) 15129 Return a new iterator pointing to the first statement in basic 15130 block 'BB'. 15131 15132 -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq) 15133 Return a new iterator initially pointing to the last statement of 15134 sequence 'SEQ'. If 'SEQ' is empty, the iterator's basic block is 15135 'NULL'. Use 'gsi_last_bb' instead when the iterator needs to 15136 always have the correct basic block set. 15137 15138 -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb) 15139 Return a new iterator pointing to the last statement in basic block 15140 'BB'. 15141 15142 -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i) 15143 Return 'TRUE' if at the end of 'I'. 15144 15145 -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i) 15146 Return 'TRUE' if we're one statement before the end of 'I'. 15147 15148 -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i) 15149 Advance the iterator to the next gimple statement. 15150 15151 -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i) 15152 Advance the iterator to the previous gimple statement. 15153 15154 -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i) 15155 Return the current stmt. 15156 15157 -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block 15158 bb) 15159 Return a block statement iterator that points to the first 15160 non-label statement in block 'BB'. 15161 15162 -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i) 15163 Return a pointer to the current stmt. 15164 15165 -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i) 15166 Return the basic block associated with this iterator. 15167 15168 -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i) 15169 Return the sequence associated with this iterator. 15170 15171 -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool 15172 remove_eh_info) 15173 Remove the current stmt from the sequence. The iterator is updated 15174 to point to the next statement. When 'REMOVE_EH_INFO' is true we 15175 remove the statement pointed to by iterator 'I' from the 'EH' 15176 tables. Otherwise we do not modify the 'EH' tables. Generally, 15177 'REMOVE_EH_INFO' should be true when the statement is going to be 15178 removed from the 'IL' and not reinserted elsewhere. 15179 15180 -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i, 15181 gimple_seq seq, enum gsi_iterator_update mode) 15182 Links the sequence of statements 'SEQ' before the statement pointed 15183 by iterator 'I'. 'MODE' indicates what to do with the iterator 15184 after insertion (see 'enum gsi_iterator_update' above). 15185 15186 -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i, 15187 gimple g, enum gsi_iterator_update mode) 15188 Links statement 'G' before the statement pointed-to by iterator 15189 'I'. Updates iterator 'I' according to 'MODE'. 15190 15191 -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i, 15192 gimple_seq seq, enum gsi_iterator_update mode) 15193 Links sequence 'SEQ' after the statement pointed-to by iterator 15194 'I'. 'MODE' is as in 'gsi_insert_after'. 15195 15196 -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i, 15197 gimple g, enum gsi_iterator_update mode) 15198 Links statement 'G' after the statement pointed-to by iterator 'I'. 15199 'MODE' is as in 'gsi_insert_after'. 15200 15201 -- GIMPLE function: gimple_seq gsi_split_seq_after 15202 (gimple_stmt_iterator i) 15203 Move all statements in the sequence after 'I' to a new sequence. 15204 Return this new sequence. 15205 15206 -- GIMPLE function: gimple_seq gsi_split_seq_before 15207 (gimple_stmt_iterator *i) 15208 Move all statements in the sequence before 'I' to a new sequence. 15209 Return this new sequence. 15210 15211 -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple 15212 stmt, bool update_eh_info) 15213 Replace the statement pointed-to by 'I' to 'STMT'. If 15214 'UPDATE_EH_INFO' is true, the exception handling information of the 15215 original statement is moved to the new statement. 15216 15217 -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i, 15218 gimple stmt, enum gsi_iterator_update mode) 15219 Insert statement 'STMT' before the statement pointed-to by iterator 15220 'I', update 'STMT''s basic block and scan it for new operands. 15221 'MODE' specifies how to update iterator 'I' after insertion (see 15222 enum 'gsi_iterator_update'). 15223 15224 -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator 15225 *i, gimple_seq seq, enum gsi_iterator_update mode) 15226 Like 'gsi_insert_before', but for all the statements in 'SEQ'. 15227 15228 -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i, 15229 gimple stmt, enum gsi_iterator_update mode) 15230 Insert statement 'STMT' after the statement pointed-to by iterator 15231 'I', update 'STMT''s basic block and scan it for new operands. 15232 'MODE' specifies how to update iterator 'I' after insertion (see 15233 enum 'gsi_iterator_update'). 15234 15235 -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator *i, 15236 gimple_seq seq, enum gsi_iterator_update mode) 15237 Like 'gsi_insert_after', but for all the statements in 'SEQ'. 15238 15239 -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt) 15240 Finds iterator for 'STMT'. 15241 15242 -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from, 15243 gimple_stmt_iterator *to) 15244 Move the statement at 'FROM' so it comes right after the statement 15245 at 'TO'. 15246 15247 -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from, 15248 gimple_stmt_iterator *to) 15249 Move the statement at 'FROM' so it comes right before the statement 15250 at 'TO'. 15251 15252 -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator 15253 *from, basic_block bb) 15254 Move the statement at 'FROM' to the end of basic block 'BB'. 15255 15256 -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt) 15257 Add 'STMT' to the pending list of edge 'E'. No actual insertion is 15258 made until a call to 'gsi_commit_edge_inserts'() is made. 15259 15260 -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq 15261 seq) 15262 Add the sequence of statements in 'SEQ' to the pending list of edge 15263 'E'. No actual insertion is made until a call to 15264 'gsi_commit_edge_inserts'() is made. 15265 15266 -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e, 15267 gimple stmt) 15268 Similar to 'gsi_insert_on_edge'+'gsi_commit_edge_inserts'. If a 15269 new block has to be created, it is returned. 15270 15271 -- GIMPLE function: void gsi_commit_one_edge_insert (edge e, 15272 basic_block *new_bb) 15273 Commit insertions pending at edge 'E'. If a new block is created, 15274 set 'NEW_BB' to this block, otherwise set it to 'NULL'. 15275 15276 -- GIMPLE function: void gsi_commit_edge_inserts (void) 15277 This routine will commit all pending edge insertions, creating any 15278 new basic blocks which are necessary. 15279 15280 15281File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE 15282 1528312.11 Adding a new GIMPLE statement code 15284======================================== 15285 15286The first step in adding a new GIMPLE statement code, is modifying the 15287file 'gimple.def', which contains all the GIMPLE codes. Then you must 15288add a corresponding gimple subclass located in 'gimple.h'. This in 15289turn, will require you to add a corresponding 'GTY' tag in 15290'gsstruct.def', and code to handle this tag in 'gss_for_code' which is 15291located in 'gimple.c'. 15292 15293 In order for the garbage collector to know the size of the structure 15294you created in 'gimple.h', you need to add a case to handle your new 15295GIMPLE statement in 'gimple_size' which is located in 'gimple.c'. 15296 15297 You will probably want to create a function to build the new gimple 15298statement in 'gimple.c'. The function should be called 15299'gimple_build_NEW-TUPLE-NAME', and should return the new tuple as a 15300pointer to the appropriate gimple subclass. 15301 15302 If your new statement requires accessors for any members or operands it 15303may have, put simple inline accessors in 'gimple.h' and any non-trivial 15304accessors in 'gimple.c' with a corresponding prototype in 'gimple.h'. 15305 15306 You should add the new statement subclass to the class hierarchy 15307diagram in 'gimple.texi'. 15308 15309 15310File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE 15311 1531212.12 Statement and operand traversals 15313====================================== 15314 15315There are two functions available for walking statements and sequences: 15316'walk_gimple_stmt' and 'walk_gimple_seq', accordingly, and a third 15317function for walking the operands in a statement: 'walk_gimple_op'. 15318 15319 -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi, 15320 walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct 15321 walk_stmt_info *wi) 15322 This function is used to walk the current statement in 'GSI', 15323 optionally using traversal state stored in 'WI'. If 'WI' is 15324 'NULL', no state is kept during the traversal. 15325 15326 The callback 'CALLBACK_STMT' is called. If 'CALLBACK_STMT' returns 15327 true, it means that the callback function has handled all the 15328 operands of the statement and it is not necessary to walk its 15329 operands. 15330 15331 If 'CALLBACK_STMT' is 'NULL' or it returns false, 'CALLBACK_OP' is 15332 called on each operand of the statement via 'walk_gimple_op'. If 15333 'walk_gimple_op' returns non-'NULL' for any operand, the remaining 15334 operands are not scanned. 15335 15336 The return value is that returned by the last call to 15337 'walk_gimple_op', or 'NULL_TREE' if no 'CALLBACK_OP' is specified. 15338 15339 -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn 15340 callback_op, struct walk_stmt_info *wi) 15341 Use this function to walk the operands of statement 'STMT'. Every 15342 operand is walked via 'walk_tree' with optional state information 15343 in 'WI'. 15344 15345 'CALLBACK_OP' is called on each operand of 'STMT' via 'walk_tree'. 15346 Additional parameters to 'walk_tree' must be stored in 'WI'. For 15347 each operand 'OP', 'walk_tree' is called as: 15348 15349 walk_tree (&OP, CALLBACK_OP, WI, PSET) 15350 15351 If 'CALLBACK_OP' returns non-'NULL' for an operand, the remaining 15352 operands are not scanned. The return value is that returned by the 15353 last call to 'walk_tree', or 'NULL_TREE' if no 'CALLBACK_OP' is 15354 specified. 15355 15356 -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn 15357 callback_stmt, walk_tree_fn callback_op, struct walk_stmt_info 15358 *wi) 15359 This function walks all the statements in the sequence 'SEQ' 15360 calling 'walk_gimple_stmt' on each one. 'WI' is as in 15361 'walk_gimple_stmt'. If 'walk_gimple_stmt' returns non-'NULL', the 15362 walk is stopped and the value returned. Otherwise, all the 15363 statements are walked and 'NULL_TREE' returned. 15364 15365 15366File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top 15367 1536813 Analysis and Optimization of GIMPLE tuples 15369********************************************* 15370 15371GCC uses three main intermediate languages to represent the program 15372during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 15373language-independent representation generated by each front end. It is 15374used to serve as an interface between the parser and optimizer. GENERIC 15375is a common representation that is able to represent programs written in 15376all the languages supported by GCC. 15377 15378 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 15379target and language independent optimizations (e.g., inlining, constant 15380propagation, tail call elimination, redundancy elimination, etc). Much 15381like GENERIC, GIMPLE is a language independent, tree based 15382representation. However, it differs from GENERIC in that the GIMPLE 15383grammar is more restrictive: expressions contain no more than 3 operands 15384(except function calls), it has no control flow structures and 15385expressions with side effects are only allowed on the right hand side of 15386assignments. See the chapter describing GENERIC and GIMPLE for more 15387details. 15388 15389 This chapter describes the data structures and functions used in the 15390GIMPLE optimizers (also known as "tree optimizers" or "middle end"). In 15391particular, it focuses on all the macros, data structures, functions and 15392programming constructs needed to implement optimization passes for 15393GIMPLE. 15394 15395* Menu: 15396 15397* Annotations:: Attributes for variables. 15398* SSA Operands:: SSA names referenced by GIMPLE statements. 15399* SSA:: Static Single Assignment representation. 15400* Alias analysis:: Representing aliased loads and stores. 15401* Memory model:: Memory model used by the middle-end. 15402 15403 15404File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA 15405 1540613.1 Annotations 15407================ 15408 15409The optimizers need to associate attributes with variables during the 15410optimization process. For instance, we need to know whether a variable 15411has aliases. All these attributes are stored in data structures called 15412annotations which are then linked to the field 'ann' in 'struct 15413tree_common'. 15414 15415 15416File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 15417 1541813.2 SSA Operands 15419================= 15420 15421Almost every GIMPLE statement will contain a reference to a variable or 15422memory location. Since statements come in different shapes and sizes, 15423their operands are going to be located at various spots inside the 15424statement's tree. To facilitate access to the statement's operands, 15425they are organized into lists associated inside each statement's 15426annotation. Each element in an operand list is a pointer to a 15427'VAR_DECL', 'PARM_DECL' or 'SSA_NAME' tree node. This provides a very 15428convenient way of examining and replacing operands. 15429 15430 Data flow analysis and optimization is done on all tree nodes 15431representing variables. Any node for which 'SSA_VAR_P' returns nonzero 15432is considered when scanning statement operands. However, not all 15433'SSA_VAR_P' variables are processed in the same way. For the purposes 15434of optimization, we need to distinguish between references to local 15435scalar variables and references to globals, statics, structures, arrays, 15436aliased variables, etc. The reason is simple, the compiler can gather 15437complete data flow information for a local scalar. On the other hand, a 15438global variable may be modified by a function call, it may not be 15439possible to keep track of all the elements of an array or the fields of 15440a structure, etc. 15441 15442 The operand scanner gathers two kinds of operands: "real" and 15443"virtual". An operand for which 'is_gimple_reg' returns true is 15444considered real, otherwise it is a virtual operand. We also distinguish 15445between uses and definitions. An operand is used if its value is loaded 15446by the statement (e.g., the operand at the RHS of an assignment). If 15447the statement assigns a new value to the operand, the operand is 15448considered a definition (e.g., the operand at the LHS of an assignment). 15449 15450 Virtual and real operands also have very different data flow 15451properties. Real operands are unambiguous references to the full object 15452that they represent. For instance, given 15453 15454 { 15455 int a, b; 15456 a = b 15457 } 15458 15459 Since 'a' and 'b' are non-aliased locals, the statement 'a = b' will 15460have one real definition and one real use because variable 'a' is 15461completely modified with the contents of variable 'b'. Real definition 15462are also known as "killing definitions". Similarly, the use of 'b' 15463reads all its bits. 15464 15465 In contrast, virtual operands are used with variables that can have a 15466partial or ambiguous reference. This includes structures, arrays, 15467globals, and aliased variables. In these cases, we have two types of 15468definitions. For globals, structures, and arrays, we can determine from 15469a statement whether a variable of these types has a killing definition. 15470If the variable does, then the statement is marked as having a "must 15471definition" of that variable. However, if a statement is only defining 15472a part of the variable (i.e. a field in a structure), or if we know that 15473a statement might define the variable but we cannot say for sure, then 15474we mark that statement as having a "may definition". For instance, 15475given 15476 15477 { 15478 int a, b, *p; 15479 15480 if (...) 15481 p = &a; 15482 else 15483 p = &b; 15484 *p = 5; 15485 return *p; 15486 } 15487 15488 The assignment '*p = 5' may be a definition of 'a' or 'b'. If we 15489cannot determine statically where 'p' is pointing to at the time of the 15490store operation, we create virtual definitions to mark that statement as 15491a potential definition site for 'a' and 'b'. Memory loads are similarly 15492marked with virtual use operands. Virtual operands are shown in tree 15493dumps right before the statement that contains them. To request a tree 15494dump with virtual operands, use the '-vops' option to '-fdump-tree': 15495 15496 { 15497 int a, b, *p; 15498 15499 if (...) 15500 p = &a; 15501 else 15502 p = &b; 15503 # a = VDEF <a> 15504 # b = VDEF <b> 15505 *p = 5; 15506 15507 # VUSE <a> 15508 # VUSE <b> 15509 return *p; 15510 } 15511 15512 Notice that 'VDEF' operands have two copies of the referenced variable. 15513This indicates that this is not a killing definition of that variable. 15514In this case we refer to it as a "may definition" or "aliased store". 15515The presence of the second copy of the variable in the 'VDEF' operand 15516will become important when the function is converted into SSA form. 15517This will be used to link all the non-killing definitions to prevent 15518optimizations from making incorrect assumptions about them. 15519 15520 Operands are updated as soon as the statement is finished via a call to 15521'update_stmt'. If statement elements are changed via 'SET_USE' or 15522'SET_DEF', then no further action is required (i.e., those macros take 15523care of updating the statement). If changes are made by manipulating 15524the statement's tree directly, then a call must be made to 'update_stmt' 15525when complete. Calling one of the 'bsi_insert' routines or 15526'bsi_replace' performs an implicit call to 'update_stmt'. 15527 1552813.2.1 Operand Iterators And Access Routines 15529-------------------------------------------- 15530 15531Operands are collected by 'tree-ssa-operands.c'. They are stored inside 15532each statement's annotation and can be accessed through either the 15533operand iterators or an access routine. 15534 15535 The following access routines are available for examining operands: 15536 15537 1. 'SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 15538 NULL unless there is exactly one operand matching the specified 15539 flags. If there is exactly one operand, the operand is returned as 15540 either a 'tree', 'def_operand_p', or 'use_operand_p'. 15541 15542 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 15543 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 15544 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 15545 15546 2. 'ZERO_SSA_OPERANDS': This macro returns true if there are no 15547 operands matching the specified flags. 15548 15549 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 15550 return; 15551 15552 3. 'NUM_SSA_OPERANDS': This macro Returns the number of operands 15553 matching 'flags'. This actually executes a loop to perform the 15554 count, so only use this if it is really needed. 15555 15556 int count = NUM_SSA_OPERANDS (stmt, flags) 15557 15558 If you wish to iterate over some or all operands, use the 15559'FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 15560all the operands for a statement: 15561 15562 void 15563 print_ops (tree stmt) 15564 { 15565 ssa_op_iter; 15566 tree var; 15567 15568 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 15569 print_generic_expr (stderr, var, TDF_SLIM); 15570 } 15571 15572 How to choose the appropriate iterator: 15573 15574 1. Determine whether you are need to see the operand pointers, or just 15575 the trees, and choose the appropriate macro: 15576 15577 Need Macro: 15578 ---- ------- 15579 use_operand_p FOR_EACH_SSA_USE_OPERAND 15580 def_operand_p FOR_EACH_SSA_DEF_OPERAND 15581 tree FOR_EACH_SSA_TREE_OPERAND 15582 15583 2. You need to declare a variable of the type you are interested in, 15584 and an ssa_op_iter structure which serves as the loop controlling 15585 variable. 15586 15587 3. Determine which operands you wish to use, and specify the flags of 15588 those you are interested in. They are documented in 15589 'tree-ssa-operands.h': 15590 15591 #define SSA_OP_USE 0x01 /* Real USE operands. */ 15592 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 15593 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 15594 #define SSA_OP_VDEF 0x08 /* VDEF operands. */ 15595 15596 /* These are commonly grouped operand flags. */ 15597 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE) 15598 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF) 15599 #define SSA_OP_ALL_VIRTUALS (SSA_OP_VIRTUAL_USES | SSA_OP_VIRTUAL_DEFS) 15600 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 15601 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 15602 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 15603 15604 So if you want to look at the use pointers for all the 'USE' and 'VUSE' 15605operands, you would do something like: 15606 15607 use_operand_p use_p; 15608 ssa_op_iter iter; 15609 15610 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 15611 { 15612 process_use_ptr (use_p); 15613 } 15614 15615 The 'TREE' macro is basically the same as the 'USE' and 'DEF' macros, 15616only with the use or def dereferenced via 'USE_FROM_PTR (use_p)' and 15617'DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use and 15618defs flags can be mixed. 15619 15620 tree var; 15621 ssa_op_iter iter; 15622 15623 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE) 15624 { 15625 print_generic_expr (stderr, var, TDF_SLIM); 15626 } 15627 15628 'VDEF's are broken into two flags, one for the 'DEF' portion 15629('SSA_OP_VDEF') and one for the USE portion ('SSA_OP_VUSE'). 15630 15631 There are many examples in the code, in addition to the documentation 15632in 'tree-ssa-operands.h' and 'ssa-iterators.h'. 15633 15634 There are also a couple of variants on the stmt iterators regarding PHI 15635nodes. 15636 15637 'FOR_EACH_PHI_ARG' Works exactly like 'FOR_EACH_SSA_USE_OPERAND', 15638except it works over 'PHI' arguments instead of statement operands. 15639 15640 /* Look at every virtual PHI use. */ 15641 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 15642 { 15643 my_code; 15644 } 15645 15646 /* Look at every real PHI use. */ 15647 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 15648 my_code; 15649 15650 /* Look at every PHI use. */ 15651 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 15652 my_code; 15653 15654 'FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 15655'FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 15656statement or a 'PHI' node. These should be used when it is appropriate 15657but they are not quite as efficient as the individual 'FOR_EACH_PHI' and 15658'FOR_EACH_SSA' routines. 15659 15660 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 15661 { 15662 my_code; 15663 } 15664 15665 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 15666 { 15667 my_code; 15668 } 15669 1567013.2.2 Immediate Uses 15671--------------------- 15672 15673Immediate use information is now always available. Using the immediate 15674use iterators, you may examine every use of any 'SSA_NAME'. For 15675instance, to change each use of 'ssa_var' to 'ssa_var2' and call 15676fold_stmt on each stmt after that is done: 15677 15678 use_operand_p imm_use_p; 15679 imm_use_iterator iterator; 15680 tree ssa_var, stmt; 15681 15682 15683 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 15684 { 15685 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 15686 SET_USE (imm_use_p, ssa_var_2); 15687 fold_stmt (stmt); 15688 } 15689 15690 There are 2 iterators which can be used. 'FOR_EACH_IMM_USE_FAST' is 15691used when the immediate uses are not changed, i.e., you are looking at 15692the uses, but not setting them. 15693 15694 If they do get changed, then care must be taken that things are not 15695changed under the iterators, so use the 'FOR_EACH_IMM_USE_STMT' and 15696'FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 15697sanity of the use list by moving all the uses for a statement into a 15698controlled position, and then iterating over those uses. Then the 15699optimization can manipulate the stmt when all the uses have been 15700processed. This is a little slower than the FAST version since it adds 15701a placeholder element and must sort through the list a bit for each 15702statement. This placeholder element must be also be removed if the loop 15703is terminated early; a destructor takes care of that when leaving the 15704'FOR_EACH_IMM_USE_STMT' scope. 15705 15706 There are checks in 'verify_ssa' which verify that the immediate use 15707list is up to date, as well as checking that an optimization didn't 15708break from the loop without using this macro. It is safe to simply 15709'break'; from a 'FOR_EACH_IMM_USE_FAST' traverse. 15710 15711 Some useful functions and macros: 15712 1. 'has_zero_uses (ssa_var)' : Returns true if there are no uses of 15713 'ssa_var'. 15714 2. 'has_single_use (ssa_var)' : Returns true if there is only a single 15715 use of 'ssa_var'. 15716 3. 'single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 15717 Returns true if there is only a single use of 'ssa_var', and also 15718 returns the use pointer and statement it occurs in, in the second 15719 and third parameters. 15720 4. 'num_imm_uses (ssa_var)' : Returns the number of immediate uses of 15721 'ssa_var'. It is better not to use this if possible since it 15722 simply utilizes a loop to count the uses. 15723 5. 'PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a 'PHI' node, 15724 return the index number for the use. An assert is triggered if the 15725 use isn't located in a 'PHI' node. 15726 6. 'USE_STMT (use_p)' : Return the statement a use occurs in. 15727 15728 Note that uses are not put into an immediate use list until their 15729statement is actually inserted into the instruction stream via a 'bsi_*' 15730routine. 15731 15732 It is also still possible to utilize lazy updating of statements, but 15733this should be used only when absolutely required. Both alias analysis 15734and the dominator optimizations currently do this. 15735 15736 When lazy updating is being used, the immediate use information is out 15737of date and cannot be used reliably. Lazy updating is achieved by 15738simply marking statements modified via calls to 'gimple_set_modified' 15739instead of 'update_stmt'. When lazy updating is no longer required, all 15740the modified statements must have 'update_stmt' called in order to bring 15741them up to date. This must be done before the optimization is finished, 15742or 'verify_ssa' will trigger an abort. 15743 15744 This is done with a simple loop over the instruction stream: 15745 block_stmt_iterator bsi; 15746 basic_block bb; 15747 FOR_EACH_BB (bb) 15748 { 15749 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 15750 update_stmt_if_modified (bsi_stmt (bsi)); 15751 } 15752 15753 15754File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA 15755 1575613.3 Static Single Assignment 15757============================= 15758 15759Most of the tree optimizers rely on the data flow information provided 15760by the Static Single Assignment (SSA) form. We implement the SSA form 15761as described in 'R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 15762Zadeck. Efficiently Computing Static Single Assignment Form and the 15763Control Dependence Graph. ACM Transactions on Programming Languages and 15764Systems, 13(4):451-490, October 1991'. 15765 15766 The SSA form is based on the premise that program variables are 15767assigned in exactly one location in the program. Multiple assignments 15768to the same variable create new versions of that variable. Naturally, 15769actual programs are seldom in SSA form initially because variables tend 15770to be assigned multiple times. The compiler modifies the program 15771representation so that every time a variable is assigned in the code, a 15772new version of the variable is created. Different versions of the same 15773variable are distinguished by subscripting the variable name with its 15774version number. Variables used in the right-hand side of expressions 15775are renamed so that their version number matches that of the most recent 15776assignment. 15777 15778 We represent variable versions using 'SSA_NAME' nodes. The renaming 15779process in 'tree-ssa.c' wraps every real and virtual operand with an 15780'SSA_NAME' node which contains the version number and the statement that 15781created the 'SSA_NAME'. Only definitions and virtual definitions may 15782create new 'SSA_NAME' nodes. 15783 15784 Sometimes, flow of control makes it impossible to determine the most 15785recent version of a variable. In these cases, the compiler inserts an 15786artificial definition for that variable called "PHI function" or "PHI 15787node". This new definition merges all the incoming versions of the 15788variable to create a new name for it. For instance, 15789 15790 if (...) 15791 a_1 = 5; 15792 else if (...) 15793 a_2 = 2; 15794 else 15795 a_3 = 13; 15796 15797 # a_4 = PHI <a_1, a_2, a_3> 15798 return a_4; 15799 15800 Since it is not possible to determine which of the three branches will 15801be taken at runtime, we don't know which of 'a_1', 'a_2' or 'a_3' to use 15802at the return statement. So, the SSA renamer creates a new version 15803'a_4' which is assigned the result of "merging" 'a_1', 'a_2' and 'a_3'. 15804Hence, PHI nodes mean "one of these operands. I don't know which". 15805 15806 The following functions can be used to examine PHI nodes 15807 15808 -- Function: gimple_phi_result (PHI) 15809 Returns the 'SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 15810 15811 -- Function: gimple_phi_num_args (PHI) 15812 Returns the number of arguments in PHI. This number is exactly the 15813 number of incoming edges to the basic block holding PHI. 15814 15815 -- Function: gimple_phi_arg (PHI, I) 15816 Returns Ith argument of PHI. 15817 15818 -- Function: gimple_phi_arg_edge (PHI, I) 15819 Returns the incoming edge for the Ith argument of PHI. 15820 15821 -- Function: gimple_phi_arg_def (PHI, I) 15822 Returns the 'SSA_NAME' for the Ith argument of PHI. 15823 1582413.3.1 Preserving the SSA form 15825------------------------------ 15826 15827Some optimization passes make changes to the function that invalidate 15828the SSA property. This can happen when a pass has added new symbols or 15829changed the program so that variables that were previously aliased 15830aren't anymore. Whenever something like this happens, the affected 15831symbols must be renamed into SSA form again. Transformations that emit 15832new code or replicate existing statements will also need to update the 15833SSA form. 15834 15835 Since GCC implements two different SSA forms for register and virtual 15836variables, keeping the SSA form up to date depends on whether you are 15837updating register or virtual names. In both cases, the general idea 15838behind incremental SSA updates is similar: when new SSA names are 15839created, they typically are meant to replace other existing names in the 15840program. 15841 15842 For instance, given the following code: 15843 15844 1 L0: 15845 2 x_1 = PHI (0, x_5) 15846 3 if (x_1 < 10) 15847 4 if (x_1 > 7) 15848 5 y_2 = 0 15849 6 else 15850 7 y_3 = x_1 + x_7 15851 8 endif 15852 9 x_5 = x_1 + 1 15853 10 goto L0; 15854 11 endif 15855 15856 Suppose that we insert new names 'x_10' and 'x_11' (lines '4' and '8'). 15857 15858 1 L0: 15859 2 x_1 = PHI (0, x_5) 15860 3 if (x_1 < 10) 15861 4 x_10 = ... 15862 5 if (x_1 > 7) 15863 6 y_2 = 0 15864 7 else 15865 8 x_11 = ... 15866 9 y_3 = x_1 + x_7 15867 10 endif 15868 11 x_5 = x_1 + 1 15869 12 goto L0; 15870 13 endif 15871 15872 We want to replace all the uses of 'x_1' with the new definitions of 15873'x_10' and 'x_11'. Note that the only uses that should be replaced are 15874those at lines '5', '9' and '11'. Also, the use of 'x_7' at line '9' 15875should _not_ be replaced (this is why we cannot just mark symbol 'x' for 15876renaming). 15877 15878 Additionally, we may need to insert a PHI node at line '11' because 15879that is a merge point for 'x_10' and 'x_11'. So the use of 'x_1' at 15880line '11' will be replaced with the new PHI node. The insertion of PHI 15881nodes is optional. They are not strictly necessary to preserve the SSA 15882form, and depending on what the caller inserted, they may not even be 15883useful for the optimizers. 15884 15885 Updating the SSA form is a two step process. First, the pass has to 15886identify which names need to be updated and/or which symbols need to be 15887renamed into SSA form for the first time. When new names are introduced 15888to replace existing names in the program, the mapping between the old 15889and the new names are registered by calling 'register_new_name_mapping' 15890(note that if your pass creates new code by duplicating basic blocks, 15891the call to 'tree_duplicate_bb' will set up the necessary mappings 15892automatically). 15893 15894 After the replacement mappings have been registered and new symbols 15895marked for renaming, a call to 'update_ssa' makes the registered 15896changes. This can be done with an explicit call or by creating 'TODO' 15897flags in the 'tree_opt_pass' structure for your pass. There are several 15898'TODO' flags that control the behavior of 'update_ssa': 15899 15900 * 'TODO_update_ssa'. Update the SSA form inserting PHI nodes for 15901 newly exposed symbols and virtual names marked for updating. When 15902 updating real names, only insert PHI nodes for a real name 'O_j' in 15903 blocks reached by all the new and old definitions for 'O_j'. If 15904 the iterated dominance frontier for 'O_j' is not pruned, we may end 15905 up inserting PHI nodes in blocks that have one or more edges with 15906 no incoming definition for 'O_j'. This would lead to uninitialized 15907 warnings for 'O_j''s symbol. 15908 15909 * 'TODO_update_ssa_no_phi'. Update the SSA form without inserting 15910 any new PHI nodes at all. This is used by passes that have either 15911 inserted all the PHI nodes themselves or passes that need only to 15912 patch use-def and def-def chains for virtuals (e.g., DCE). 15913 15914 * 'TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are 15915 needed. No pruning of the IDF is done. This is used by passes 15916 that need the PHI nodes for 'O_j' even if it means that some 15917 arguments will come from the default definition of 'O_j''s symbol 15918 (e.g., 'pass_linear_transform'). 15919 15920 WARNING: If you need to use this flag, chances are that your pass 15921 may be doing something wrong. Inserting PHI nodes for an old name 15922 where not all edges carry a new replacement may lead to silent 15923 codegen errors or spurious uninitialized warnings. 15924 15925 * 'TODO_update_ssa_only_virtuals'. Passes that update the SSA form 15926 on their own may want to delegate the updating of virtual names to 15927 the generic updater. Since FUD chains are easier to maintain, this 15928 simplifies the work they need to do. NOTE: If this flag is used, 15929 any OLD->NEW mappings for real names are explicitly destroyed and 15930 only the symbols marked for renaming are processed. 15931 1593213.3.2 Examining 'SSA_NAME' nodes 15933--------------------------------- 15934 15935The following macros can be used to examine 'SSA_NAME' nodes 15936 15937 -- Macro: SSA_NAME_DEF_STMT (VAR) 15938 Returns the statement S that creates the 'SSA_NAME' VAR. If S is 15939 an empty statement (i.e., 'IS_EMPTY_STMT (S)' returns 'true'), it 15940 means that the first reference to this variable is a USE or a VUSE. 15941 15942 -- Macro: SSA_NAME_VERSION (VAR) 15943 Returns the version number of the 'SSA_NAME' object VAR. 15944 1594513.3.3 Walking the dominator tree 15946--------------------------------- 15947 15948 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 15949 15950 This function walks the dominator tree for the current CFG calling 15951 a set of callback functions defined in STRUCT DOM_WALK_DATA in 15952 'domwalk.h'. The call back functions you need to define give you 15953 hooks to execute custom code at various points during traversal: 15954 15955 1. Once to initialize any local data needed while processing BB 15956 and its children. This local data is pushed into an internal 15957 stack which is automatically pushed and popped as the walker 15958 traverses the dominator tree. 15959 15960 2. Once before traversing all the statements in the BB. 15961 15962 3. Once for every statement inside BB. 15963 15964 4. Once after traversing all the statements and before recursing 15965 into BB's dominator children. 15966 15967 5. It then recurses into all the dominator children of BB. 15968 15969 6. After recursing into all the dominator children of BB it can, 15970 optionally, traverse every statement in BB again (i.e., 15971 repeating steps 2 and 3). 15972 15973 7. Once after walking the statements in BB and BB's dominator 15974 children. At this stage, the block local data stack is 15975 popped. 15976 15977 15978File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA 15979 1598013.4 Alias analysis 15981=================== 15982 15983Alias analysis in GIMPLE SSA form consists of two pieces. First the 15984virtual SSA web ties conflicting memory accesses and provides a SSA 15985use-def chain and SSA immediate-use chains for walking possibly 15986dependent memory accesses. Second an alias-oracle can be queried to 15987disambiguate explicit and implicit memory references. 15988 15989 1. Memory SSA form. 15990 15991 All statements that may use memory have exactly one accompanied use 15992 of a virtual SSA name that represents the state of memory at the 15993 given point in the IL. 15994 15995 All statements that may define memory have exactly one accompanied 15996 definition of a virtual SSA name using the previous state of memory 15997 and defining the new state of memory after the given point in the 15998 IL. 15999 16000 int i; 16001 int foo (void) 16002 { 16003 # .MEM_3 = VDEF <.MEM_2(D)> 16004 i = 1; 16005 # VUSE <.MEM_3> 16006 return i; 16007 } 16008 16009 The virtual SSA names in this case are '.MEM_2(D)' and '.MEM_3'. 16010 The store to the global variable 'i' defines '.MEM_3' invalidating 16011 '.MEM_2(D)'. The load from 'i' uses that new state '.MEM_3'. 16012 16013 The virtual SSA web serves as constraints to SSA optimizers 16014 preventing illegitimate code-motion and optimization. It also 16015 provides a way to walk related memory statements. 16016 16017 2. Points-to and escape analysis. 16018 16019 Points-to analysis builds a set of constraints from the GIMPLE SSA 16020 IL representing all pointer operations and facts we do or do not 16021 know about pointers. Solving this set of constraints yields a 16022 conservatively correct solution for each pointer variable in the 16023 program (though we are only interested in SSA name pointers) as to 16024 what it may possibly point to. 16025 16026 This points-to solution for a given SSA name pointer is stored in 16027 the 'pt_solution' sub-structure of the 'SSA_NAME_PTR_INFO' record. 16028 The following accessor functions are available: 16029 16030 * 'pt_solution_includes' 16031 * 'pt_solutions_intersect' 16032 16033 Points-to analysis also computes the solution for two special set 16034 of pointers, 'ESCAPED' and 'CALLUSED'. Those represent all memory 16035 that has escaped the scope of analysis or that is used by pure or 16036 nested const calls. 16037 16038 3. Type-based alias analysis 16039 16040 Type-based alias analysis is frontend dependent though generic 16041 support is provided by the middle-end in 'alias.c'. TBAA code is 16042 used by both tree optimizers and RTL optimizers. 16043 16044 Every language that wishes to perform language-specific alias 16045 analysis should define a function that computes, given a 'tree' 16046 node, an alias set for the node. Nodes in different alias sets are 16047 not allowed to alias. For an example, see the C front-end function 16048 'c_get_alias_set'. 16049 16050 4. Tree alias-oracle 16051 16052 The tree alias-oracle provides means to disambiguate two memory 16053 references and memory references against statements. The following 16054 queries are available: 16055 16056 * 'refs_may_alias_p' 16057 * 'ref_maybe_used_by_stmt_p' 16058 * 'stmt_may_clobber_ref_p' 16059 16060 In addition to those two kind of statement walkers are available 16061 walking statements related to a reference ref. 16062 'walk_non_aliased_vuses' walks over dominating memory defining 16063 statements and calls back if the statement does not clobber ref 16064 providing the non-aliased VUSE. The walk stops at the first 16065 clobbering statement or if asked to. 'walk_aliased_vdefs' walks 16066 over dominating memory defining statements and calls back on each 16067 statement clobbering ref providing its aliasing VDEF. The walk 16068 stops if asked to. 16069 16070 16071File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA 16072 1607313.5 Memory model 16074================= 16075 16076The memory model used by the middle-end models that of the C/C++ 16077languages. The middle-end has the notion of an effective type of a 16078memory region which is used for type-based alias analysis. 16079 16080 The following is a refinement of ISO C99 6.5/6, clarifying the block 16081copy case to follow common sense and extending the concept of a dynamic 16082effective type to objects with a declared type as required for C++. 16083 16084 The effective type of an object for an access to its stored value is 16085 the declared type of the object or the effective type determined by 16086 a previous store to it. If a value is stored into an object through 16087 an lvalue having a type that is not a character type, then the 16088 type of the lvalue becomes the effective type of the object for that 16089 access and for subsequent accesses that do not modify the stored value. 16090 If a value is copied into an object using memcpy or memmove, 16091 or is copied as an array of character type, then the effective type 16092 of the modified object for that access and for subsequent accesses that 16093 do not modify the value is undetermined. For all other accesses to an 16094 object, the effective type of the object is simply the type of the 16095 lvalue used for the access. 16096 16097 16098File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top 16099 1610014 RTL Representation 16101********************* 16102 16103The last part of the compiler work is done on a low-level intermediate 16104representation called Register Transfer Language. In this language, the 16105instructions to be output are described, pretty much one by one, in an 16106algebraic form that describes what the instruction does. 16107 16108 RTL is inspired by Lisp lists. It has both an internal form, made up 16109of structures that point at other structures, and a textual form that is 16110used in the machine description and in printed debugging dumps. The 16111textual form uses nested parentheses to indicate the pointers in the 16112internal form. 16113 16114* Menu: 16115 16116* RTL Objects:: Expressions vs vectors vs strings vs integers. 16117* RTL Classes:: Categories of RTL expression objects, and their structure. 16118* Accessors:: Macros to access expression operands or vector elts. 16119* Special Accessors:: Macros to access specific annotations on RTL. 16120* Flags:: Other flags in an RTL expression. 16121* Machine Modes:: Describing the size and format of a datum. 16122* Constants:: Expressions with constant values. 16123* Regs and Memory:: Expressions representing register contents or memory. 16124* Arithmetic:: Expressions representing arithmetic on other expressions. 16125* Comparisons:: Expressions representing comparison of expressions. 16126* Bit-Fields:: Expressions representing bit-fields in memory or reg. 16127* Vector Operations:: Expressions involving vector datatypes. 16128* Conversions:: Extending, truncating, floating or fixing. 16129* RTL Declarations:: Declaring volatility, constancy, etc. 16130* Side Effects:: Expressions for storing in registers, etc. 16131* Incdec:: Embedded side-effects for autoincrement addressing. 16132* Assembler:: Representing 'asm' with operands. 16133* Debug Information:: Expressions representing debugging information. 16134* Insns:: Expression types for entire insns. 16135* Calls:: RTL representation of function call insns. 16136* RTL SSA:: An on-the-side SSA form for RTL 16137* Sharing:: Some expressions are unique; others *must* be copied. 16138* Reading RTL:: Reading textual RTL from a file. 16139 16140 16141File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 16142 1614314.1 RTL Object Types 16144===================== 16145 16146RTL uses five kinds of objects: expressions, integers, wide integers, 16147strings and vectors. Expressions are the most important ones. An RTL 16148expression ("RTX", for short) is a C structure, but it is usually 16149referred to with a pointer; a type that is given the typedef name 'rtx'. 16150 16151 An integer is simply an 'int'; their written form uses decimal digits. 16152A wide integer is an integral object whose type is 'HOST_WIDE_INT'; 16153their written form uses decimal digits. 16154 16155 A string is a sequence of characters. In core it is represented as a 16156'char *' in usual C fashion, and it is written in C syntax as well. 16157However, strings in RTL may never be null. If you write an empty string 16158in a machine description, it is represented in core as a null pointer 16159rather than as a pointer to a null character. In certain contexts, 16160these null pointers instead of strings are valid. Within RTL code, 16161strings are most commonly found inside 'symbol_ref' expressions, but 16162they appear in other contexts in the RTL expressions that make up 16163machine descriptions. 16164 16165 In a machine description, strings are normally written with double 16166quotes, as you would in C. However, strings in machine descriptions may 16167extend over many lines, which is invalid C, and adjacent string 16168constants are not concatenated as they are in C. Any string constant 16169may be surrounded with a single set of parentheses. Sometimes this 16170makes the machine description easier to read. 16171 16172 There is also a special syntax for strings, which can be useful when C 16173code is embedded in a machine description. Wherever a string can 16174appear, it is also valid to write a C-style brace block. The entire 16175brace block, including the outermost pair of braces, is considered to be 16176the string constant. Double quote characters inside the braces are not 16177special. Therefore, if you write string constants in the C code, you 16178need not escape each quote character with a backslash. 16179 16180 A vector contains an arbitrary number of pointers to expressions. The 16181number of elements in the vector is explicitly present in the vector. 16182The written form of a vector consists of square brackets ('[...]') 16183surrounding the elements, in sequence and with whitespace separating 16184them. Vectors of length zero are not created; null pointers are used 16185instead. 16186 16187 Expressions are classified by "expression codes" (also called RTX 16188codes). The expression code is a name defined in 'rtl.def', which is 16189also (in uppercase) a C enumeration constant. The possible expression 16190codes and their meanings are machine-independent. The code of an RTX 16191can be extracted with the macro 'GET_CODE (X)' and altered with 16192'PUT_CODE (X, NEWCODE)'. 16193 16194 The expression code determines how many operands the expression 16195contains, and what kinds of objects they are. In RTL, unlike Lisp, you 16196cannot tell by looking at an operand what kind of object it is. 16197Instead, you must know from its context--from the expression code of the 16198containing expression. For example, in an expression of code 'subreg', 16199the first operand is to be regarded as an expression and the second 16200operand as a polynomial integer. In an expression of code 'plus', there 16201are two operands, both of which are to be regarded as expressions. In a 16202'symbol_ref' expression, there is one operand, which is to be regarded 16203as a string. 16204 16205 Expressions are written as parentheses containing the name of the 16206expression type, its flags and machine mode if any, and then the 16207operands of the expression (separated by spaces). 16208 16209 Expression code names in the 'md' file are written in lowercase, but 16210when they appear in C code they are written in uppercase. In this 16211manual, they are shown as follows: 'const_int'. 16212 16213 In a few contexts a null pointer is valid where an expression is 16214normally wanted. The written form of this is '(nil)'. 16215 16216 16217File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 16218 1621914.2 RTL Classes and Formats 16220============================ 16221 16222The various expression codes are divided into several "classes", which 16223are represented by single characters. You can determine the class of an 16224RTX code with the macro 'GET_RTX_CLASS (CODE)'. Currently, 'rtl.def' 16225defines these classes: 16226 16227'RTX_OBJ' 16228 An RTX code that represents an actual object, such as a register 16229 ('REG') or a memory location ('MEM', 'SYMBOL_REF'). 'LO_SUM') is 16230 also included; instead, 'SUBREG' and 'STRICT_LOW_PART' are not in 16231 this class, but in class 'RTX_EXTRA'. 16232 16233'RTX_CONST_OBJ' 16234 An RTX code that represents a constant object. 'HIGH' is also 16235 included in this class. 16236 16237'RTX_COMPARE' 16238 An RTX code for a non-symmetric comparison, such as 'GEU' or 'LT'. 16239 16240'RTX_COMM_COMPARE' 16241 An RTX code for a symmetric (commutative) comparison, such as 'EQ' 16242 or 'ORDERED'. 16243 16244'RTX_UNARY' 16245 An RTX code for a unary arithmetic operation, such as 'NEG', 'NOT', 16246 or 'ABS'. This category also includes value extension (sign or 16247 zero) and conversions between integer and floating point. 16248 16249'RTX_COMM_ARITH' 16250 An RTX code for a commutative binary operation, such as 'PLUS' or 16251 'AND'. 'NE' and 'EQ' are comparisons, so they have class 16252 'RTX_COMM_COMPARE'. 16253 16254'RTX_BIN_ARITH' 16255 An RTX code for a non-commutative binary operation, such as 16256 'MINUS', 'DIV', or 'ASHIFTRT'. 16257 16258'RTX_BITFIELD_OPS' 16259 An RTX code for a bit-field operation. Currently only 16260 'ZERO_EXTRACT' and 'SIGN_EXTRACT'. These have three inputs and are 16261 lvalues (so they can be used for insertion as well). *Note 16262 Bit-Fields::. 16263 16264'RTX_TERNARY' 16265 An RTX code for other three input operations. Currently only 16266 'IF_THEN_ELSE', 'VEC_MERGE', 'SIGN_EXTRACT', 'ZERO_EXTRACT', and 16267 'FMA'. 16268 16269'RTX_INSN' 16270 An RTX code for an entire instruction: 'INSN', 'JUMP_INSN', and 16271 'CALL_INSN'. *Note Insns::. 16272 16273'RTX_MATCH' 16274 An RTX code for something that matches in insns, such as 16275 'MATCH_DUP'. These only occur in machine descriptions. 16276 16277'RTX_AUTOINC' 16278 An RTX code for an auto-increment addressing mode, such as 16279 'POST_INC'. 'XEXP (X, 0)' gives the auto-modified register. 16280 16281'RTX_EXTRA' 16282 All other RTX codes. This category includes the remaining codes 16283 used only in machine descriptions ('DEFINE_*', etc.). It also 16284 includes all the codes describing side effects ('SET', 'USE', 16285 'CLOBBER', etc.) and the non-insns that may appear on an insn 16286 chain, such as 'NOTE', 'BARRIER', and 'CODE_LABEL'. 'SUBREG' is 16287 also part of this class. 16288 16289 For each expression code, 'rtl.def' specifies the number of contained 16290objects and their kinds using a sequence of characters called the 16291"format" of the expression code. For example, the format of 'subreg' is 16292'ep'. 16293 16294 These are the most commonly used format characters: 16295 16296'e' 16297 An expression (actually a pointer to an expression). 16298 16299'i' 16300 An integer. 16301 16302'w' 16303 A wide integer. 16304 16305's' 16306 A string. 16307 16308'E' 16309 A vector of expressions. 16310 16311 A few other format characters are used occasionally: 16312 16313'u' 16314 'u' is equivalent to 'e' except that it is printed differently in 16315 debugging dumps. It is used for pointers to insns. 16316 16317'n' 16318 'n' is equivalent to 'i' except that it is printed differently in 16319 debugging dumps. It is used for the line number or code number of 16320 a 'note' insn. 16321 16322'S' 16323 'S' indicates a string which is optional. In the RTL objects in 16324 core, 'S' is equivalent to 's', but when the object is read, from 16325 an 'md' file, the string value of this operand may be omitted. An 16326 omitted string is taken to be the null string. 16327 16328'V' 16329 'V' indicates a vector which is optional. In the RTL objects in 16330 core, 'V' is equivalent to 'E', but when the object is read from an 16331 'md' file, the vector value of this operand may be omitted. An 16332 omitted vector is effectively the same as a vector of no elements. 16333 16334'B' 16335 'B' indicates a pointer to basic block structure. 16336 16337'p' 16338 A polynomial integer. At present this is used only for 16339 'SUBREG_BYTE'. 16340 16341'0' 16342 '0' means a slot whose contents do not fit any normal category. 16343 '0' slots are not printed at all in dumps, and are often used in 16344 special ways by small parts of the compiler. 16345 16346 There are macros to get the number of operands and the format of an 16347expression code: 16348 16349'GET_RTX_LENGTH (CODE)' 16350 Number of operands of an RTX of code CODE. 16351 16352'GET_RTX_FORMAT (CODE)' 16353 The format of an RTX of code CODE, as a C string. 16354 16355 Some classes of RTX codes always have the same format. For example, it 16356is safe to assume that all comparison operations have format 'ee'. 16357 16358'RTX_UNARY' 16359 All codes of this class have format 'e'. 16360 16361'RTX_BIN_ARITH' 16362'RTX_COMM_ARITH' 16363'RTX_COMM_COMPARE' 16364'RTX_COMPARE' 16365 All codes of these classes have format 'ee'. 16366 16367'RTX_BITFIELD_OPS' 16368'RTX_TERNARY' 16369 All codes of these classes have format 'eee'. 16370 16371'RTX_INSN' 16372 All codes of this class have formats that begin with 'iuueiee'. 16373 *Note Insns::. Note that not all RTL objects linked onto an insn 16374 chain are of class 'RTX_INSN'. 16375 16376'RTX_CONST_OBJ' 16377'RTX_OBJ' 16378'RTX_MATCH' 16379'RTX_EXTRA' 16380 You can make no assumptions about the format of these codes. 16381 16382 16383File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 16384 1638514.3 Access to Operands 16386======================= 16387 16388Operands of expressions are accessed using the macros 'XEXP', 'XINT', 16389'XWINT' and 'XSTR'. Each of these macros takes two arguments: an 16390expression-pointer (RTX) and an operand number (counting from zero). 16391Thus, 16392 16393 XEXP (X, 2) 16394 16395accesses operand 2 of expression X, as an expression. 16396 16397 XINT (X, 2) 16398 16399accesses the same operand as an integer. 'XSTR', used in the same 16400fashion, would access it as a string. 16401 16402 Any operand can be accessed as an integer, as an expression or as a 16403string. You must choose the correct method of access for the kind of 16404value actually stored in the operand. You would do this based on the 16405expression code of the containing expression. That is also how you 16406would know how many operands there are. 16407 16408 For example, if X is an 'int_list' expression, you know that it has two 16409operands which can be correctly accessed as 'XINT (X, 0)' and 'XEXP (X, 164101)'. Incorrect accesses like 'XEXP (X, 0)' and 'XINT (X, 1)' would 16411compile, but would trigger an internal compiler error when rtl checking 16412is enabled. Nothing stops you from writing 'XEXP (X, 28)' either, but 16413this will access memory past the end of the expression with 16414unpredictable results. 16415 16416 Access to operands which are vectors is more complicated. You can use 16417the macro 'XVEC' to get the vector-pointer itself, or the macros 16418'XVECEXP' and 'XVECLEN' to access the elements and length of a vector. 16419 16420'XVEC (EXP, IDX)' 16421 Access the vector-pointer which is operand number IDX in EXP. 16422 16423'XVECLEN (EXP, IDX)' 16424 Access the length (number of elements) in the vector which is in 16425 operand number IDX in EXP. This value is an 'int'. 16426 16427'XVECEXP (EXP, IDX, ELTNUM)' 16428 Access element number ELTNUM in the vector which is in operand 16429 number IDX in EXP. This value is an RTX. 16430 16431 It is up to you to make sure that ELTNUM is not negative and is 16432 less than 'XVECLEN (EXP, IDX)'. 16433 16434 All the macros defined in this section expand into lvalues and 16435therefore can be used to assign the operands, lengths and vector 16436elements as well as to access them. 16437 16438 16439File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 16440 1644114.4 Access to Special Operands 16442=============================== 16443 16444Some RTL nodes have special annotations associated with them. 16445 16446'MEM' 16447 'MEM_ALIAS_SET (X)' 16448 If 0, X is not in any alias set, and may alias anything. 16449 Otherwise, X can only alias 'MEM's in a conflicting alias set. 16450 This value is set in a language-dependent manner in the 16451 front-end, and should not be altered in the back-end. In some 16452 front-ends, these numbers may correspond in some way to types, 16453 or other language-level entities, but they need not, and the 16454 back-end makes no such assumptions. These set numbers are 16455 tested with 'alias_sets_conflict_p'. 16456 16457 'MEM_EXPR (X)' 16458 If this register is known to hold the value of some user-level 16459 declaration, this is that tree node. It may also be a 16460 'COMPONENT_REF', in which case this is some field reference, 16461 and 'TREE_OPERAND (X, 0)' contains the declaration, or another 16462 'COMPONENT_REF', or null if there is no compile-time object 16463 associated with the reference. 16464 16465 'MEM_OFFSET_KNOWN_P (X)' 16466 True if the offset of the memory reference from 'MEM_EXPR' is 16467 known. 'MEM_OFFSET (X)' provides the offset if so. 16468 16469 'MEM_OFFSET (X)' 16470 The offset from the start of 'MEM_EXPR'. The value is only 16471 valid if 'MEM_OFFSET_KNOWN_P (X)' is true. 16472 16473 'MEM_SIZE_KNOWN_P (X)' 16474 True if the size of the memory reference is known. 'MEM_SIZE 16475 (X)' provides its size if so. 16476 16477 'MEM_SIZE (X)' 16478 The size in bytes of the memory reference. This is mostly 16479 relevant for 'BLKmode' references as otherwise the size is 16480 implied by the mode. The value is only valid if 16481 'MEM_SIZE_KNOWN_P (X)' is true. 16482 16483 'MEM_ALIGN (X)' 16484 The known alignment in bits of the memory reference. 16485 16486 'MEM_ADDR_SPACE (X)' 16487 The address space of the memory reference. This will commonly 16488 be zero for the generic address space. 16489 16490'REG' 16491 'ORIGINAL_REGNO (X)' 16492 This field holds the number the register "originally" had; for 16493 a pseudo register turned into a hard reg this will hold the 16494 old pseudo register number. 16495 16496 'REG_EXPR (X)' 16497 If this register is known to hold the value of some user-level 16498 declaration, this is that tree node. 16499 16500 'REG_OFFSET (X)' 16501 If this register is known to hold the value of some user-level 16502 declaration, this is the offset into that logical storage. 16503 16504'SYMBOL_REF' 16505 'SYMBOL_REF_DECL (X)' 16506 If the 'symbol_ref' X was created for a 'VAR_DECL' or a 16507 'FUNCTION_DECL', that tree is recorded here. If this value is 16508 null, then X was created by back end code generation routines, 16509 and there is no associated front end symbol table entry. 16510 16511 'SYMBOL_REF_DECL' may also point to a tree of class ''c'', 16512 that is, some sort of constant. In this case, the 16513 'symbol_ref' is an entry in the per-file constant pool; again, 16514 there is no associated front end symbol table entry. 16515 16516 'SYMBOL_REF_CONSTANT (X)' 16517 If 'CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 16518 pool entry for X. It is null otherwise. 16519 16520 'SYMBOL_REF_DATA (X)' 16521 A field of opaque type used to store 'SYMBOL_REF_DECL' or 16522 'SYMBOL_REF_CONSTANT'. 16523 16524 'SYMBOL_REF_FLAGS (X)' 16525 In a 'symbol_ref', this is used to communicate various 16526 predicates about the symbol. Some of these are common enough 16527 to be computed by common code, some are specific to the 16528 target. The common bits are: 16529 16530 'SYMBOL_FLAG_FUNCTION' 16531 Set if the symbol refers to a function. 16532 16533 'SYMBOL_FLAG_LOCAL' 16534 Set if the symbol is local to this "module". See 16535 'TARGET_BINDS_LOCAL_P'. 16536 16537 'SYMBOL_FLAG_EXTERNAL' 16538 Set if this symbol is not defined in this translation 16539 unit. Note that this is not the inverse of 16540 'SYMBOL_FLAG_LOCAL'. 16541 16542 'SYMBOL_FLAG_SMALL' 16543 Set if the symbol is located in the small data section. 16544 See 'TARGET_IN_SMALL_DATA_P'. 16545 16546 'SYMBOL_REF_TLS_MODEL (X)' 16547 This is a multi-bit field accessor that returns the 16548 'tls_model' to be used for a thread-local storage symbol. 16549 It returns zero for non-thread-local symbols. 16550 16551 'SYMBOL_FLAG_HAS_BLOCK_INFO' 16552 Set if the symbol has 'SYMBOL_REF_BLOCK' and 16553 'SYMBOL_REF_BLOCK_OFFSET' fields. 16554 16555 'SYMBOL_FLAG_ANCHOR' 16556 Set if the symbol is used as a section anchor. "Section 16557 anchors" are symbols that have a known position within an 16558 'object_block' and that can be used to access nearby 16559 members of that block. They are used to implement 16560 '-fsection-anchors'. 16561 16562 If this flag is set, then 'SYMBOL_FLAG_HAS_BLOCK_INFO' 16563 will be too. 16564 16565 Bits beginning with 'SYMBOL_FLAG_MACH_DEP' are available for 16566 the target's use. 16567 16568'SYMBOL_REF_BLOCK (X)' 16569 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the 'object_block' 16570 structure to which the symbol belongs, or 'NULL' if it has not been 16571 assigned a block. 16572 16573'SYMBOL_REF_BLOCK_OFFSET (X)' 16574 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 16575 the first object in 'SYMBOL_REF_BLOCK (X)'. The value is negative 16576 if X has not yet been assigned to a block, or it has not been given 16577 an offset within that block. 16578 16579 16580File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 16581 1658214.5 Flags in an RTL Expression 16583=============================== 16584 16585RTL expressions contain several flags (one-bit bit-fields) that are used 16586in certain types of expression. Most often they are accessed with the 16587following macros, which expand into lvalues. 16588 16589'CROSSING_JUMP_P (X)' 16590 Nonzero in a 'jump_insn' if it crosses between hot and cold 16591 sections, which could potentially be very far apart in the 16592 executable. The presence of this flag indicates to other 16593 optimizations that this branching instruction should not be 16594 "collapsed" into a simpler branching construct. It is used when 16595 the optimization to partition basic blocks into hot and cold 16596 sections is turned on. 16597 16598'CONSTANT_POOL_ADDRESS_P (X)' 16599 Nonzero in a 'symbol_ref' if it refers to part of the current 16600 function's constant pool. For most targets these addresses are in 16601 a '.rodata' section entirely separate from the function, but for 16602 some targets the addresses are close to the beginning of the 16603 function. In either case GCC assumes these addresses can be 16604 addressed directly, perhaps with the help of base registers. 16605 Stored in the 'unchanging' field and printed as '/u'. 16606 16607'INSN_ANNULLED_BRANCH_P (X)' 16608 In a 'jump_insn', 'call_insn', or 'insn' indicates that the branch 16609 is an annulling one. See the discussion under 'sequence' below. 16610 Stored in the 'unchanging' field and printed as '/u'. 16611 16612'INSN_DELETED_P (X)' 16613 In an 'insn', 'call_insn', 'jump_insn', 'code_label', 16614 'jump_table_data', 'barrier', or 'note', nonzero if the insn has 16615 been deleted. Stored in the 'volatil' field and printed as '/v'. 16616 16617'INSN_FROM_TARGET_P (X)' 16618 In an 'insn' or 'jump_insn' or 'call_insn' in a delay slot of a 16619 branch, indicates that the insn is from the target of the branch. 16620 If the branch insn has 'INSN_ANNULLED_BRANCH_P' set, this insn will 16621 only be executed if the branch is taken. For annulled branches 16622 with 'INSN_FROM_TARGET_P' clear, the insn will be executed only if 16623 the branch is not taken. When 'INSN_ANNULLED_BRANCH_P' is not set, 16624 this insn will always be executed. Stored in the 'in_struct' field 16625 and printed as '/s'. 16626 16627'LABEL_PRESERVE_P (X)' 16628 In a 'code_label' or 'note', indicates that the label is referenced 16629 by code or data not visible to the RTL of a given function. Labels 16630 referenced by a non-local goto will have this bit set. Stored in 16631 the 'in_struct' field and printed as '/s'. 16632 16633'LABEL_REF_NONLOCAL_P (X)' 16634 In 'label_ref' and 'reg_label' expressions, nonzero if this is a 16635 reference to a non-local label. Stored in the 'volatil' field and 16636 printed as '/v'. 16637 16638'MEM_KEEP_ALIAS_SET_P (X)' 16639 In 'mem' expressions, 1 if we should keep the alias set for this 16640 mem unchanged when we access a component. Set to 1, for example, 16641 when we are already in a non-addressable component of an aggregate. 16642 Stored in the 'jump' field and printed as '/j'. 16643 16644'MEM_VOLATILE_P (X)' 16645 In 'mem', 'asm_operands', and 'asm_input' expressions, nonzero for 16646 volatile memory references. Stored in the 'volatil' field and 16647 printed as '/v'. 16648 16649'MEM_NOTRAP_P (X)' 16650 In 'mem', nonzero for memory references that will not trap. Stored 16651 in the 'call' field and printed as '/c'. 16652 16653'MEM_POINTER (X)' 16654 Nonzero in a 'mem' if the memory reference holds a pointer. Stored 16655 in the 'frame_related' field and printed as '/f'. 16656 16657'MEM_READONLY_P (X)' 16658 Nonzero in a 'mem', if the memory is statically allocated and 16659 read-only. 16660 16661 Read-only in this context means never modified during the lifetime 16662 of the program, not necessarily in ROM or in write-disabled pages. 16663 A common example of the later is a shared library's global offset 16664 table. This table is initialized by the runtime loader, so the 16665 memory is technically writable, but after control is transferred 16666 from the runtime loader to the application, this memory will never 16667 be subsequently modified. 16668 16669 Stored in the 'unchanging' field and printed as '/u'. 16670 16671'PREFETCH_SCHEDULE_BARRIER_P (X)' 16672 In a 'prefetch', indicates that the prefetch is a scheduling 16673 barrier. No other INSNs will be moved over it. Stored in the 16674 'volatil' field and printed as '/v'. 16675 16676'REG_FUNCTION_VALUE_P (X)' 16677 Nonzero in a 'reg' if it is the place in which this function's 16678 value is going to be returned. (This happens only in a hard 16679 register.) Stored in the 'return_val' field and printed as '/i'. 16680 16681'REG_POINTER (X)' 16682 Nonzero in a 'reg' if the register holds a pointer. Stored in the 16683 'frame_related' field and printed as '/f'. 16684 16685'REG_USERVAR_P (X)' 16686 In a 'reg', nonzero if it corresponds to a variable present in the 16687 user's source code. Zero for temporaries generated internally by 16688 the compiler. Stored in the 'volatil' field and printed as '/v'. 16689 16690 The same hard register may be used also for collecting the values 16691 of functions called by this one, but 'REG_FUNCTION_VALUE_P' is zero 16692 in this kind of use. 16693 16694'RTL_CONST_CALL_P (X)' 16695 In a 'call_insn' indicates that the insn represents a call to a 16696 const function. Stored in the 'unchanging' field and printed as 16697 '/u'. 16698 16699'RTL_PURE_CALL_P (X)' 16700 In a 'call_insn' indicates that the insn represents a call to a 16701 pure function. Stored in the 'return_val' field and printed as 16702 '/i'. 16703 16704'RTL_CONST_OR_PURE_CALL_P (X)' 16705 In a 'call_insn', true if 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' 16706 is true. 16707 16708'RTL_LOOPING_CONST_OR_PURE_CALL_P (X)' 16709 In a 'call_insn' indicates that the insn represents a possibly 16710 infinite looping call to a const or pure function. Stored in the 16711 'call' field and printed as '/c'. Only true if one of 16712 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' is true. 16713 16714'RTX_FRAME_RELATED_P (X)' 16715 Nonzero in an 'insn', 'call_insn', 'jump_insn', 'barrier', or 'set' 16716 which is part of a function prologue and sets the stack pointer, 16717 sets the frame pointer, or saves a register. This flag should also 16718 be set on an instruction that sets up a temporary register to use 16719 in place of the frame pointer. Stored in the 'frame_related' field 16720 and printed as '/f'. 16721 16722 In particular, on RISC targets where there are limits on the sizes 16723 of immediate constants, it is sometimes impossible to reach the 16724 register save area directly from the stack pointer. In that case, 16725 a temporary register is used that is near enough to the register 16726 save area, and the Canonical Frame Address, i.e., DWARF2's logical 16727 frame pointer, register must (temporarily) be changed to be this 16728 temporary register. So, the instruction that sets this temporary 16729 register must be marked as 'RTX_FRAME_RELATED_P'. 16730 16731 If the marked instruction is overly complex (defined in terms of 16732 what 'dwarf2out_frame_debug_expr' can handle), you will also have 16733 to create a 'REG_FRAME_RELATED_EXPR' note and attach it to the 16734 instruction. This note should contain a simple expression of the 16735 computation performed by this instruction, i.e., one that 16736 'dwarf2out_frame_debug_expr' can handle. 16737 16738 This flag is required for exception handling support on targets 16739 with RTL prologues. 16740 16741'SCHED_GROUP_P (X)' 16742 During instruction scheduling, in an 'insn', 'call_insn', 16743 'jump_insn' or 'jump_table_data', indicates that the previous insn 16744 must be scheduled together with this insn. This is used to ensure 16745 that certain groups of instructions will not be split up by the 16746 instruction scheduling pass, for example, 'use' insns before a 16747 'call_insn' may not be separated from the 'call_insn'. Stored in 16748 the 'in_struct' field and printed as '/s'. 16749 16750'SET_IS_RETURN_P (X)' 16751 For a 'set', nonzero if it is for a return. Stored in the 'jump' 16752 field and printed as '/j'. 16753 16754'SIBLING_CALL_P (X)' 16755 For a 'call_insn', nonzero if the insn is a sibling call. Stored 16756 in the 'jump' field and printed as '/j'. 16757 16758'STRING_POOL_ADDRESS_P (X)' 16759 For a 'symbol_ref' expression, nonzero if it addresses this 16760 function's string constant pool. Stored in the 'frame_related' 16761 field and printed as '/f'. 16762 16763'SUBREG_PROMOTED_UNSIGNED_P (X)' 16764 Returns a value greater then zero for a 'subreg' that has 16765 'SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 16766 kept zero-extended, zero if it is kept sign-extended, and less then 16767 zero if it is extended some other way via the 'ptr_extend' 16768 instruction. Stored in the 'unchanging' field and 'volatil' field, 16769 printed as '/u' and '/v'. This macro may only be used to get the 16770 value it may not be used to change the value. Use 16771 'SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 16772 16773'SUBREG_PROMOTED_UNSIGNED_SET (X)' 16774 Set the 'unchanging' and 'volatil' fields in a 'subreg' to reflect 16775 zero, sign, or other extension. If 'volatil' is zero, then 16776 'unchanging' as nonzero means zero extension and as zero means sign 16777 extension. If 'volatil' is nonzero then some other type of 16778 extension was done via the 'ptr_extend' instruction. 16779 16780'SUBREG_PROMOTED_VAR_P (X)' 16781 Nonzero in a 'subreg' if it was made when accessing an object that 16782 was promoted to a wider mode in accord with the 'PROMOTED_MODE' 16783 machine description macro (*note Storage Layout::). In this case, 16784 the mode of the 'subreg' is the declared mode of the object and the 16785 mode of 'SUBREG_REG' is the mode of the register that holds the 16786 object. Promoted variables are always either sign- or 16787 zero-extended to the wider mode on every assignment. Stored in the 16788 'in_struct' field and printed as '/s'. 16789 16790'SYMBOL_REF_USED (X)' 16791 In a 'symbol_ref', indicates that X has been used. This is 16792 normally only used to ensure that X is only declared external once. 16793 Stored in the 'used' field. 16794 16795'SYMBOL_REF_WEAK (X)' 16796 In a 'symbol_ref', indicates that X has been declared weak. Stored 16797 in the 'return_val' field and printed as '/i'. 16798 16799'SYMBOL_REF_FLAG (X)' 16800 In a 'symbol_ref', this is used as a flag for machine-specific 16801 purposes. Stored in the 'volatil' field and printed as '/v'. 16802 16803 Most uses of 'SYMBOL_REF_FLAG' are historic and may be subsumed by 16804 'SYMBOL_REF_FLAGS'. Certainly use of 'SYMBOL_REF_FLAGS' is 16805 mandatory if the target requires more than one bit of storage. 16806 16807 These are the fields to which the above macros refer: 16808 16809'call' 16810 In a 'mem', 1 means that the memory reference will not trap. 16811 16812 In a 'call', 1 means that this pure or const call may possibly 16813 infinite loop. 16814 16815 In an RTL dump, this flag is represented as '/c'. 16816 16817'frame_related' 16818 In an 'insn' or 'set' expression, 1 means that it is part of a 16819 function prologue and sets the stack pointer, sets the frame 16820 pointer, saves a register, or sets up a temporary register to use 16821 in place of the frame pointer. 16822 16823 In 'reg' expressions, 1 means that the register holds a pointer. 16824 16825 In 'mem' expressions, 1 means that the memory reference holds a 16826 pointer. 16827 16828 In 'symbol_ref' expressions, 1 means that the reference addresses 16829 this function's string constant pool. 16830 16831 In an RTL dump, this flag is represented as '/f'. 16832 16833'in_struct' 16834 In 'reg' expressions, it is 1 if the register has its entire life 16835 contained within the test expression of some loop. 16836 16837 In 'subreg' expressions, 1 means that the 'subreg' is accessing an 16838 object that has had its mode promoted from a wider mode. 16839 16840 In 'label_ref' expressions, 1 means that the referenced label is 16841 outside the innermost loop containing the insn in which the 16842 'label_ref' was found. 16843 16844 In 'code_label' expressions, it is 1 if the label may never be 16845 deleted. This is used for labels which are the target of non-local 16846 gotos. Such a label that would have been deleted is replaced with 16847 a 'note' of type 'NOTE_INSN_DELETED_LABEL'. 16848 16849 In an 'insn' during dead-code elimination, 1 means that the insn is 16850 dead code. 16851 16852 In an 'insn' or 'jump_insn' during reorg for an insn in the delay 16853 slot of a branch, 1 means that this insn is from the target of the 16854 branch. 16855 16856 In an 'insn' during instruction scheduling, 1 means that this insn 16857 must be scheduled as part of a group together with the previous 16858 insn. 16859 16860 In an RTL dump, this flag is represented as '/s'. 16861 16862'return_val' 16863 In 'reg' expressions, 1 means the register contains the value to be 16864 returned by the current function. On machines that pass parameters 16865 in registers, the same register number may be used for parameters 16866 as well, but this flag is not set on such uses. 16867 16868 In 'symbol_ref' expressions, 1 means the referenced symbol is weak. 16869 16870 In 'call' expressions, 1 means the call is pure. 16871 16872 In an RTL dump, this flag is represented as '/i'. 16873 16874'jump' 16875 In a 'mem' expression, 1 means we should keep the alias set for 16876 this mem unchanged when we access a component. 16877 16878 In a 'set', 1 means it is for a return. 16879 16880 In a 'call_insn', 1 means it is a sibling call. 16881 16882 In a 'jump_insn', 1 means it is a crossing jump. 16883 16884 In an RTL dump, this flag is represented as '/j'. 16885 16886'unchanging' 16887 In 'reg' and 'mem' expressions, 1 means that the value of the 16888 expression never changes. 16889 16890 In 'subreg' expressions, it is 1 if the 'subreg' references an 16891 unsigned object whose mode has been promoted to a wider mode. 16892 16893 In an 'insn' or 'jump_insn' in the delay slot of a branch 16894 instruction, 1 means an annulling branch should be used. 16895 16896 In a 'symbol_ref' expression, 1 means that this symbol addresses 16897 something in the per-function constant pool. 16898 16899 In a 'call_insn' 1 means that this instruction is a call to a const 16900 function. 16901 16902 In an RTL dump, this flag is represented as '/u'. 16903 16904'used' 16905 This flag is used directly (without an access macro) at the end of 16906 RTL generation for a function, to count the number of times an 16907 expression appears in insns. Expressions that appear more than 16908 once are copied, according to the rules for shared structure (*note 16909 Sharing::). 16910 16911 For a 'reg', it is used directly (without an access macro) by the 16912 leaf register renumbering code to ensure that each register is only 16913 renumbered once. 16914 16915 In a 'symbol_ref', it indicates that an external declaration for 16916 the symbol has already been written. 16917 16918'volatil' 16919 In a 'mem', 'asm_operands', or 'asm_input' expression, it is 1 if 16920 the memory reference is volatile. Volatile memory references may 16921 not be deleted, reordered or combined. 16922 16923 In a 'symbol_ref' expression, it is used for machine-specific 16924 purposes. 16925 16926 In a 'reg' expression, it is 1 if the value is a user-level 16927 variable. 0 indicates an internal compiler temporary. 16928 16929 In an 'insn', 1 means the insn has been deleted. 16930 16931 In 'label_ref' and 'reg_label' expressions, 1 means a reference to 16932 a non-local label. 16933 16934 In 'prefetch' expressions, 1 means that the containing insn is a 16935 scheduling barrier. 16936 16937 In an RTL dump, this flag is represented as '/v'. 16938 16939 16940File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 16941 1694214.6 Machine Modes 16943================== 16944 16945A machine mode describes a size of data object and the representation 16946used for it. In the C code, machine modes are represented by an 16947enumeration type, 'machine_mode', defined in 'machmode.def'. Each RTL 16948expression has room for a machine mode and so do certain kinds of tree 16949expressions (declarations and types, to be precise). 16950 16951 In debugging dumps and machine descriptions, the machine mode of an RTL 16952expression is written after the expression code with a colon to separate 16953them. The letters 'mode' which appear at the end of each machine mode 16954name are omitted. For example, '(reg:SI 38)' is a 'reg' expression with 16955machine mode 'SImode'. If the mode is 'VOIDmode', it is not written at 16956all. 16957 16958 Here is a table of machine modes. The term "byte" below refers to an 16959object of 'BITS_PER_UNIT' bits (*note Storage Layout::). 16960 16961'BImode' 16962 "Bit" mode represents a single bit, for predicate registers. 16963 16964'QImode' 16965 "Quarter-Integer" mode represents a single byte treated as an 16966 integer. 16967 16968'HImode' 16969 "Half-Integer" mode represents a two-byte integer. 16970 16971'PSImode' 16972 "Partial Single Integer" mode represents an integer which occupies 16973 four bytes but which doesn't really use all four. On some 16974 machines, this is the right mode to use for pointers. 16975 16976'SImode' 16977 "Single Integer" mode represents a four-byte integer. 16978 16979'PDImode' 16980 "Partial Double Integer" mode represents an integer which occupies 16981 eight bytes but which doesn't really use all eight. On some 16982 machines, this is the right mode to use for certain pointers. 16983 16984'DImode' 16985 "Double Integer" mode represents an eight-byte integer. 16986 16987'TImode' 16988 "Tetra Integer" (?) mode represents a sixteen-byte integer. 16989 16990'OImode' 16991 "Octa Integer" (?) mode represents a thirty-two-byte integer. 16992 16993'XImode' 16994 "Hexadeca Integer" (?) mode represents a sixty-four-byte integer. 16995 16996'QFmode' 16997 "Quarter-Floating" mode represents a quarter-precision (single 16998 byte) floating point number. 16999 17000'HFmode' 17001 "Half-Floating" mode represents a half-precision (two byte) 17002 floating point number. 17003 17004'TQFmode' 17005 "Three-Quarter-Floating" (?) mode represents a 17006 three-quarter-precision (three byte) floating point number. 17007 17008'SFmode' 17009 "Single Floating" mode represents a four byte floating point 17010 number. In the common case, of a processor with IEEE arithmetic 17011 and 8-bit bytes, this is a single-precision IEEE floating point 17012 number; it can also be used for double-precision (on processors 17013 with 16-bit bytes) and single-precision VAX and IBM types. 17014 17015'DFmode' 17016 "Double Floating" mode represents an eight byte floating point 17017 number. In the common case, of a processor with IEEE arithmetic 17018 and 8-bit bytes, this is a double-precision IEEE floating point 17019 number. 17020 17021'XFmode' 17022 "Extended Floating" mode represents an IEEE extended floating point 17023 number. This mode only has 80 meaningful bits (ten bytes). Some 17024 processors require such numbers to be padded to twelve bytes, 17025 others to sixteen; this mode is used for either. 17026 17027'SDmode' 17028 "Single Decimal Floating" mode represents a four byte decimal 17029 floating point number (as distinct from conventional binary 17030 floating point). 17031 17032'DDmode' 17033 "Double Decimal Floating" mode represents an eight byte decimal 17034 floating point number. 17035 17036'TDmode' 17037 "Tetra Decimal Floating" mode represents a sixteen byte decimal 17038 floating point number all 128 of whose bits are meaningful. 17039 17040'TFmode' 17041 "Tetra Floating" mode represents a sixteen byte floating point 17042 number all 128 of whose bits are meaningful. One common use is the 17043 IEEE quad-precision format. 17044 17045'QQmode' 17046 "Quarter-Fractional" mode represents a single byte treated as a 17047 signed fractional number. The default format is "s.7". 17048 17049'HQmode' 17050 "Half-Fractional" mode represents a two-byte signed fractional 17051 number. The default format is "s.15". 17052 17053'SQmode' 17054 "Single Fractional" mode represents a four-byte signed fractional 17055 number. The default format is "s.31". 17056 17057'DQmode' 17058 "Double Fractional" mode represents an eight-byte signed fractional 17059 number. The default format is "s.63". 17060 17061'TQmode' 17062 "Tetra Fractional" mode represents a sixteen-byte signed fractional 17063 number. The default format is "s.127". 17064 17065'UQQmode' 17066 "Unsigned Quarter-Fractional" mode represents a single byte treated 17067 as an unsigned fractional number. The default format is ".8". 17068 17069'UHQmode' 17070 "Unsigned Half-Fractional" mode represents a two-byte unsigned 17071 fractional number. The default format is ".16". 17072 17073'USQmode' 17074 "Unsigned Single Fractional" mode represents a four-byte unsigned 17075 fractional number. The default format is ".32". 17076 17077'UDQmode' 17078 "Unsigned Double Fractional" mode represents an eight-byte unsigned 17079 fractional number. The default format is ".64". 17080 17081'UTQmode' 17082 "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned 17083 fractional number. The default format is ".128". 17084 17085'HAmode' 17086 "Half-Accumulator" mode represents a two-byte signed accumulator. 17087 The default format is "s8.7". 17088 17089'SAmode' 17090 "Single Accumulator" mode represents a four-byte signed 17091 accumulator. The default format is "s16.15". 17092 17093'DAmode' 17094 "Double Accumulator" mode represents an eight-byte signed 17095 accumulator. The default format is "s32.31". 17096 17097'TAmode' 17098 "Tetra Accumulator" mode represents a sixteen-byte signed 17099 accumulator. The default format is "s64.63". 17100 17101'UHAmode' 17102 "Unsigned Half-Accumulator" mode represents a two-byte unsigned 17103 accumulator. The default format is "8.8". 17104 17105'USAmode' 17106 "Unsigned Single Accumulator" mode represents a four-byte unsigned 17107 accumulator. The default format is "16.16". 17108 17109'UDAmode' 17110 "Unsigned Double Accumulator" mode represents an eight-byte 17111 unsigned accumulator. The default format is "32.32". 17112 17113'UTAmode' 17114 "Unsigned Tetra Accumulator" mode represents a sixteen-byte 17115 unsigned accumulator. The default format is "64.64". 17116 17117'CCmode' 17118 "Condition Code" mode represents the value of a condition code, 17119 which is a machine-specific set of bits used to represent the 17120 result of a comparison operation. Other machine-specific modes may 17121 also be used for the condition code. These modes are not used on 17122 machines that use 'cc0' (*note Condition Code::). 17123 17124'BLKmode' 17125 "Block" mode represents values that are aggregates to which none of 17126 the other modes apply. In RTL, only memory references can have 17127 this mode, and only if they appear in string-move or vector 17128 instructions. On machines which have no such instructions, 17129 'BLKmode' will not appear in RTL. 17130 17131'VOIDmode' 17132 Void mode means the absence of a mode or an unspecified mode. For 17133 example, RTL expressions of code 'const_int' have mode 'VOIDmode' 17134 because they can be taken to have whatever mode the context 17135 requires. In debugging dumps of RTL, 'VOIDmode' is expressed by 17136 the absence of any mode. 17137 17138'QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 17139 These modes stand for a complex number represented as a pair of 17140 floating point values. The floating point values are in 'QFmode', 17141 'HFmode', 'SFmode', 'DFmode', 'XFmode', and 'TFmode', respectively. 17142 17143'CQImode, CHImode, CSImode, CDImode, CTImode, COImode, CPSImode' 17144 These modes stand for a complex number represented as a pair of 17145 integer values. The integer values are in 'QImode', 'HImode', 17146 'SImode', 'DImode', 'TImode', 'OImode', and 'PSImode', 17147 respectively. 17148 17149'BND32mode BND64mode' 17150 These modes stand for bounds for pointer of 32 and 64 bit size 17151 respectively. Mode size is double pointer mode size. 17152 17153 The machine description defines 'Pmode' as a C macro which expands into 17154the machine mode used for addresses. Normally this is the mode whose 17155size is 'BITS_PER_WORD', 'SImode' on 32-bit machines. 17156 17157 The only modes which a machine description must support are 'QImode', 17158and the modes corresponding to 'BITS_PER_WORD', 'FLOAT_TYPE_SIZE' and 17159'DOUBLE_TYPE_SIZE'. The compiler will attempt to use 'DImode' for 171608-byte structures and unions, but this can be prevented by overriding 17161the definition of 'MAX_FIXED_MODE_SIZE'. Alternatively, you can have 17162the compiler use 'TImode' for 16-byte structures and unions. Likewise, 17163you can arrange for the C type 'short int' to avoid using 'HImode'. 17164 17165 Very few explicit references to machine modes remain in the compiler 17166and these few references will soon be removed. Instead, the machine 17167modes are divided into mode classes. These are represented by the 17168enumeration type 'enum mode_class' defined in 'machmode.h'. The 17169possible mode classes are: 17170 17171'MODE_INT' 17172 Integer modes. By default these are 'BImode', 'QImode', 'HImode', 17173 'SImode', 'DImode', 'TImode', and 'OImode'. 17174 17175'MODE_PARTIAL_INT' 17176 The "partial integer" modes, 'PQImode', 'PHImode', 'PSImode' and 17177 'PDImode'. 17178 17179'MODE_FLOAT' 17180 Floating point modes. By default these are 'QFmode', 'HFmode', 17181 'TQFmode', 'SFmode', 'DFmode', 'XFmode' and 'TFmode'. 17182 17183'MODE_DECIMAL_FLOAT' 17184 Decimal floating point modes. By default these are 'SDmode', 17185 'DDmode' and 'TDmode'. 17186 17187'MODE_FRACT' 17188 Signed fractional modes. By default these are 'QQmode', 'HQmode', 17189 'SQmode', 'DQmode' and 'TQmode'. 17190 17191'MODE_UFRACT' 17192 Unsigned fractional modes. By default these are 'UQQmode', 17193 'UHQmode', 'USQmode', 'UDQmode' and 'UTQmode'. 17194 17195'MODE_ACCUM' 17196 Signed accumulator modes. By default these are 'HAmode', 'SAmode', 17197 'DAmode' and 'TAmode'. 17198 17199'MODE_UACCUM' 17200 Unsigned accumulator modes. By default these are 'UHAmode', 17201 'USAmode', 'UDAmode' and 'UTAmode'. 17202 17203'MODE_COMPLEX_INT' 17204 Complex integer modes. (These are not currently implemented). 17205 17206'MODE_COMPLEX_FLOAT' 17207 Complex floating point modes. By default these are 'QCmode', 17208 'HCmode', 'SCmode', 'DCmode', 'XCmode', and 'TCmode'. 17209 17210'MODE_CC' 17211 Modes representing condition code values. These are 'CCmode' plus 17212 any 'CC_MODE' modes listed in the 'MACHINE-modes.def'. *Note Jump 17213 Patterns::, also see *note Condition Code::. 17214 17215'MODE_POINTER_BOUNDS' 17216 Pointer bounds modes. Used to represent values of pointer bounds 17217 type. Operations in these modes may be executed as NOPs depending 17218 on hardware features and environment setup. 17219 17220'MODE_OPAQUE' 17221 This is a mode class for modes that don't want to provide 17222 operations other than register moves, memory moves, loads, stores, 17223 and 'unspec's. They have a size and precision and that's all. 17224 17225'MODE_RANDOM' 17226 This is a catchall mode class for modes which don't fit into the 17227 above classes. Currently 'VOIDmode' and 'BLKmode' are in 17228 'MODE_RANDOM'. 17229 17230 'machmode.h' also defines various wrapper classes that combine a 17231'machine_mode' with a static assertion that a particular condition 17232holds. The classes are: 17233 17234'scalar_int_mode' 17235 A mode that has class 'MODE_INT' or 'MODE_PARTIAL_INT'. 17236 17237'scalar_float_mode' 17238 A mode that has class 'MODE_FLOAT' or 'MODE_DECIMAL_FLOAT'. 17239 17240'scalar_mode' 17241 A mode that holds a single numerical value. In practice this means 17242 that the mode is a 'scalar_int_mode', is a 'scalar_float_mode', or 17243 has class 'MODE_FRACT', 'MODE_UFRACT', 'MODE_ACCUM', 'MODE_UACCUM' 17244 or 'MODE_POINTER_BOUNDS'. 17245 17246'complex_mode' 17247 A mode that has class 'MODE_COMPLEX_INT' or 'MODE_COMPLEX_FLOAT'. 17248 17249'fixed_size_mode' 17250 A mode whose size is known at compile time. 17251 17252 Named modes use the most constrained of the available wrapper classes, 17253if one exists, otherwise they use 'machine_mode'. For example, 'QImode' 17254is a 'scalar_int_mode', 'SFmode' is a 'scalar_float_mode' and 'BLKmode' 17255is a plain 'machine_mode'. It is possible to refer to any mode as a raw 17256'machine_mode' by adding the 'E_' prefix, where 'E' stands for 17257"enumeration". For example, the raw 'machine_mode' names of the modes 17258just mentioned are 'E_QImode', 'E_SFmode' and 'E_BLKmode' respectively. 17259 17260 The wrapper classes implicitly convert to 'machine_mode' and to any 17261wrapper class that represents a more general condition; for example 17262'scalar_int_mode' and 'scalar_float_mode' both convert to 'scalar_mode' 17263and all three convert to 'fixed_size_mode'. The classes act like 17264'machine_mode's that accept only certain named modes. 17265 17266 'machmode.h' also defines a template class 'opt_mode<T>' that holds a 17267'T' or nothing, where 'T' can be either 'machine_mode' or one of the 17268wrapper classes above. The main operations on an 'opt_mode<T>' X are as 17269follows: 17270 17271'X.exists ()' 17272 Return true if X holds a mode rather than nothing. 17273 17274'X.exists (&Y)' 17275 Return true if X holds a mode rather than nothing, storing the mode 17276 in Y if so. Y must be assignment-compatible with T. 17277 17278'X.require ()' 17279 Assert that X holds a mode rather than nothing and return that 17280 mode. 17281 17282'X = Y' 17283 Set X to Y, where Y is a T or implicitly converts to a T. 17284 17285 The default constructor sets an 'opt_mode<T>' to nothing. There is 17286also a constructor that takes an initial value of type T. 17287 17288 It is possible to use the 'is-a.h' accessors on a 'machine_mode' or 17289machine mode wrapper X: 17290 17291'is_a <T> (X)' 17292 Return true if X meets the conditions for wrapper class T. 17293 17294'is_a <T> (X, &Y)' 17295 Return true if X meets the conditions for wrapper class T, storing 17296 it in Y if so. Y must be assignment-compatible with T. 17297 17298'as_a <T> (X)' 17299 Assert that X meets the conditions for wrapper class T and return 17300 it as a T. 17301 17302'dyn_cast <T> (X)' 17303 Return an 'opt_mode<T>' that holds X if X meets the conditions for 17304 wrapper class T and that holds nothing otherwise. 17305 17306 The purpose of these wrapper classes is to give stronger static type 17307checking. For example, if a function takes a 'scalar_int_mode', a 17308caller that has a general 'machine_mode' must either check or assert 17309that the code is indeed a scalar integer first, using one of the 17310functions above. 17311 17312 The wrapper classes are normal C++ classes, with user-defined 17313constructors. Sometimes it is useful to have a POD version of the same 17314type, particularly if the type appears in a 'union'. The template class 17315'pod_mode<T>' provides a POD version of wrapper class T. It is 17316assignment-compatible with T and implicitly converts to both 17317'machine_mode' and T. 17318 17319 Here are some C macros that relate to machine modes: 17320 17321'GET_MODE (X)' 17322 Returns the machine mode of the RTX X. 17323 17324'PUT_MODE (X, NEWMODE)' 17325 Alters the machine mode of the RTX X to be NEWMODE. 17326 17327'NUM_MACHINE_MODES' 17328 Stands for the number of machine modes available on the target 17329 machine. This is one greater than the largest numeric value of any 17330 machine mode. 17331 17332'GET_MODE_NAME (M)' 17333 Returns the name of mode M as a string. 17334 17335'GET_MODE_CLASS (M)' 17336 Returns the mode class of mode M. 17337 17338'GET_MODE_WIDER_MODE (M)' 17339 Returns the next wider natural mode. For example, the expression 17340 'GET_MODE_WIDER_MODE (QImode)' returns 'HImode'. 17341 17342'GET_MODE_SIZE (M)' 17343 Returns the size in bytes of a datum of mode M. 17344 17345'GET_MODE_BITSIZE (M)' 17346 Returns the size in bits of a datum of mode M. 17347 17348'GET_MODE_IBIT (M)' 17349 Returns the number of integral bits of a datum of fixed-point mode 17350 M. 17351 17352'GET_MODE_FBIT (M)' 17353 Returns the number of fractional bits of a datum of fixed-point 17354 mode M. 17355 17356'GET_MODE_MASK (M)' 17357 Returns a bitmask containing 1 for all bits in a word that fit 17358 within mode M. This macro can only be used for modes whose bitsize 17359 is less than or equal to 'HOST_BITS_PER_INT'. 17360 17361'GET_MODE_ALIGNMENT (M)' 17362 Return the required alignment, in bits, for an object of mode M. 17363 17364'GET_MODE_UNIT_SIZE (M)' 17365 Returns the size in bytes of the subunits of a datum of mode M. 17366 This is the same as 'GET_MODE_SIZE' except in the case of complex 17367 modes. For them, the unit size is the size of the real or 17368 imaginary part. 17369 17370'GET_MODE_NUNITS (M)' 17371 Returns the number of units contained in a mode, i.e., 17372 'GET_MODE_SIZE' divided by 'GET_MODE_UNIT_SIZE'. 17373 17374'GET_CLASS_NARROWEST_MODE (C)' 17375 Returns the narrowest mode in mode class C. 17376 17377 The following 3 variables are defined on every target. They can be 17378used to allocate buffers that are guaranteed to be large enough to hold 17379any value that can be represented on the target. The first two can be 17380overridden by defining them in the target's mode.def file, however, the 17381value must be a constant that can determined very early in the 17382compilation process. The third symbol cannot be overridden. 17383 17384'BITS_PER_UNIT' 17385 The number of bits in an addressable storage unit (byte). If you 17386 do not define this, the default is 8. 17387 17388'MAX_BITSIZE_MODE_ANY_INT' 17389 The maximum bitsize of any mode that is used in integer math. This 17390 should be overridden by the target if it uses large integers as 17391 containers for larger vectors but otherwise never uses the contents 17392 to compute integer values. 17393 17394'MAX_BITSIZE_MODE_ANY_MODE' 17395 The bitsize of the largest mode on the target. The default value 17396 is the largest mode size given in the mode definition file, which 17397 is always correct for targets whose modes have a fixed size. 17398 Targets that might increase the size of a mode beyond this default 17399 should define 'MAX_BITSIZE_MODE_ANY_MODE' to the actual upper limit 17400 in 'MACHINE-modes.def'. 17401 17402 The global variables 'byte_mode' and 'word_mode' contain modes whose 17403classes are 'MODE_INT' and whose bitsizes are either 'BITS_PER_UNIT' or 17404'BITS_PER_WORD', respectively. On 32-bit machines, these are 'QImode' 17405and 'SImode', respectively. 17406 17407 17408File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 17409 1741014.7 Constant Expression Types 17411============================== 17412 17413The simplest RTL expressions are those that represent constant values. 17414 17415'(const_int I)' 17416 This type of expression represents the integer value I. I is 17417 customarily accessed with the macro 'INTVAL' as in 'INTVAL (EXP)', 17418 which is equivalent to 'XWINT (EXP, 0)'. 17419 17420 Constants generated for modes with fewer bits than in 17421 'HOST_WIDE_INT' must be sign extended to full width (e.g., with 17422 'gen_int_mode'). For constants for modes with more bits than in 17423 'HOST_WIDE_INT' the implied high order bits of that constant are 17424 copies of the top bit. Note however that values are neither 17425 inherently signed nor inherently unsigned; where necessary, 17426 signedness is determined by the rtl operation instead. 17427 17428 There is only one expression object for the integer value zero; it 17429 is the value of the variable 'const0_rtx'. Likewise, the only 17430 expression for integer value one is found in 'const1_rtx', the only 17431 expression for integer value two is found in 'const2_rtx', and the 17432 only expression for integer value negative one is found in 17433 'constm1_rtx'. Any attempt to create an expression of code 17434 'const_int' and value zero, one, two or negative one will return 17435 'const0_rtx', 'const1_rtx', 'const2_rtx' or 'constm1_rtx' as 17436 appropriate. 17437 17438 Similarly, there is only one object for the integer whose value is 17439 'STORE_FLAG_VALUE'. It is found in 'const_true_rtx'. If 17440 'STORE_FLAG_VALUE' is one, 'const_true_rtx' and 'const1_rtx' will 17441 point to the same object. If 'STORE_FLAG_VALUE' is -1, 17442 'const_true_rtx' and 'constm1_rtx' will point to the same object. 17443 17444'(const_double:M I0 I1 ...)' 17445 This represents either a floating-point constant of mode M or (on 17446 older ports that do not define 'TARGET_SUPPORTS_WIDE_INT') an 17447 integer constant too large to fit into 'HOST_BITS_PER_WIDE_INT' 17448 bits but small enough to fit within twice that number of bits. In 17449 the latter case, M will be 'VOIDmode'. For integral values 17450 constants for modes with more bits than twice the number in 17451 'HOST_WIDE_INT' the implied high order bits of that constant are 17452 copies of the top bit of 'CONST_DOUBLE_HIGH'. Note however that 17453 integral values are neither inherently signed nor inherently 17454 unsigned; where necessary, signedness is determined by the rtl 17455 operation instead. 17456 17457 On more modern ports, 'CONST_DOUBLE' only represents floating point 17458 values. New ports define 'TARGET_SUPPORTS_WIDE_INT' to make this 17459 designation. 17460 17461 If M is 'VOIDmode', the bits of the value are stored in I0 and I1. 17462 I0 is customarily accessed with the macro 'CONST_DOUBLE_LOW' and I1 17463 with 'CONST_DOUBLE_HIGH'. 17464 17465 If the constant is floating point (regardless of its precision), 17466 then the number of integers used to store the value depends on the 17467 size of 'REAL_VALUE_TYPE' (*note Floating Point::). The integers 17468 represent a floating point number, but not precisely in the target 17469 machine's or host machine's floating point format. To convert them 17470 to the precise bit pattern used by the target machine, use the 17471 macro 'REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 17472 Output::). 17473 17474 The host dependency for the number of integers used to store a 17475 double value makes it problematic for machine descriptions to use 17476 expressions of code 'const_double' and therefore a syntactic alias 17477 has been provided: 17478 17479 (const_double_zero:M) 17480 17481 standing for: 17482 17483 (const_double:M 0 0 ...) 17484 17485 for matching the floating-point value zero, possibly the only 17486 useful one. 17487 17488'(const_wide_int:M NUNITS ELT0 ...)' 17489 This contains an array of 'HOST_WIDE_INT's that is large enough to 17490 hold any constant that can be represented on the target. This form 17491 of rtl is only used on targets that define 17492 'TARGET_SUPPORTS_WIDE_INT' to be nonzero and then 'CONST_DOUBLE's 17493 are only used to hold floating-point values. If the target leaves 17494 'TARGET_SUPPORTS_WIDE_INT' defined as 0, 'CONST_WIDE_INT's are not 17495 used and 'CONST_DOUBLE's are as they were before. 17496 17497 The values are stored in a compressed format. The higher-order 0s 17498 or -1s are not represented if they are just the logical sign 17499 extension of the number that is represented. 17500 17501'CONST_WIDE_INT_VEC (CODE)' 17502 Returns the entire array of 'HOST_WIDE_INT's that are used to store 17503 the value. This macro should be rarely used. 17504 17505'CONST_WIDE_INT_NUNITS (CODE)' 17506 The number of 'HOST_WIDE_INT's used to represent the number. Note 17507 that this generally is smaller than the number of 'HOST_WIDE_INT's 17508 implied by the mode size. 17509 17510'CONST_WIDE_INT_ELT (CODE,I)' 17511 Returns the 'i'th element of the array. Element 0 is contains the 17512 low order bits of the constant. 17513 17514'(const_fixed:M ...)' 17515 Represents a fixed-point constant of mode M. The operand is a data 17516 structure of type 'struct fixed_value' and is accessed with the 17517 macro 'CONST_FIXED_VALUE'. The high part of data is accessed with 17518 'CONST_FIXED_VALUE_HIGH'; the low part is accessed with 17519 'CONST_FIXED_VALUE_LOW'. 17520 17521'(const_poly_int:M [C0 C1 ...])' 17522 Represents a 'poly_int'-style polynomial integer with coefficients 17523 C0, C1, .... The coefficients are 'wide_int'-based integers rather 17524 than rtxes. 'CONST_POLY_INT_COEFFS' gives the values of individual 17525 coefficients (which is mostly only useful in low-level routines) 17526 and 'const_poly_int_value' gives the full 'poly_int' value. 17527 17528'(const_vector:M [X0 X1 ...])' 17529 Represents a vector constant. The values in square brackets are 17530 elements of the vector, which are always 'const_int', 17531 'const_wide_int', 'const_double' or 'const_fixed' expressions. 17532 17533 Each vector constant V is treated as a specific instance of an 17534 arbitrary-length sequence that itself contains 17535 'CONST_VECTOR_NPATTERNS (V)' interleaved patterns. Each pattern 17536 has the form: 17537 17538 { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... } 17539 17540 The first three elements in each pattern are enough to determine 17541 the values of the other elements. However, if all STEPs are zero, 17542 only the first two elements are needed. If in addition each BASE1 17543 is equal to the corresponding BASE0, only the first element in each 17544 pattern is needed. The number of determining elements per pattern 17545 is given by 'CONST_VECTOR_NELTS_PER_PATTERN (V)'. 17546 17547 For example, the constant: 17548 17549 { 0, 1, 2, 6, 3, 8, 4, 10, 5, 12, 6, 14, 7, 16, 8, 18 } 17550 17551 is interpreted as an interleaving of the sequences: 17552 17553 { 0, 2, 3, 4, 5, 6, 7, 8 } 17554 { 1, 6, 8, 10, 12, 14, 16, 18 } 17555 17556 where the sequences are represented by the following patterns: 17557 17558 BASE0 == 0, BASE1 == 2, STEP == 1 17559 BASE0 == 1, BASE1 == 6, STEP == 2 17560 17561 In this case: 17562 17563 CONST_VECTOR_NPATTERNS (V) == 2 17564 CONST_VECTOR_NELTS_PER_PATTERN (V) == 3 17565 17566 Thus the first 6 elements ('{ 0, 1, 2, 6, 3, 8 }') are enough to 17567 determine the whole sequence; we refer to them as the "encoded" 17568 elements. They are the only elements present in the square 17569 brackets for variable-length 'const_vector's (i.e. for 17570 'const_vector's whose mode M has a variable number of elements). 17571 However, as a convenience to code that needs to handle both 17572 'const_vector's and 'parallel's, all elements are present in the 17573 square brackets for fixed-length 'const_vector's; the encoding 17574 scheme simply reduces the amount of work involved in processing 17575 constants that follow a regular pattern. 17576 17577 Sometimes this scheme can create two possible encodings of the same 17578 vector. For example { 0, 1 } could be seen as two patterns with 17579 one element each or one pattern with two elements (BASE0 and 17580 BASE1). The canonical encoding is always the one with the fewest 17581 patterns or (if both encodings have the same number of petterns) 17582 the one with the fewest encoded elements. 17583 17584 'const_vector_encoding_nelts (V)' gives the total number of encoded 17585 elements in V, which is 6 in the example above. 17586 'CONST_VECTOR_ENCODED_ELT (V, I)' accesses the value of encoded 17587 element I. 17588 17589 'CONST_VECTOR_DUPLICATE_P (V)' is true if V simply contains 17590 repeated instances of 'CONST_VECTOR_NPATTERNS (V)' values. This is 17591 a shorthand for testing 'CONST_VECTOR_NELTS_PER_PATTERN (V) == 1'. 17592 17593 'CONST_VECTOR_STEPPED_P (V)' is true if at least one pattern in V 17594 has a nonzero step. This is a shorthand for testing 17595 'CONST_VECTOR_NELTS_PER_PATTERN (V) == 3'. 17596 17597 'CONST_VECTOR_NUNITS (V)' gives the total number of elements in V; 17598 it is a shorthand for getting the number of units in 'GET_MODE 17599 (V)'. 17600 17601 The utility function 'const_vector_elt' gives the value of an 17602 arbitrary element as an 'rtx'. 'const_vector_int_elt' gives the 17603 same value as a 'wide_int'. 17604 17605'(const_string STR)' 17606 Represents a constant string with value STR. Currently this is 17607 used only for insn attributes (*note Insn Attributes::) since 17608 constant strings in C are placed in memory. 17609 17610'(symbol_ref:MODE SYMBOL)' 17611 Represents the value of an assembler label for data. SYMBOL is a 17612 string that describes the name of the assembler label. If it 17613 starts with a '*', the label is the rest of SYMBOL not including 17614 the '*'. Otherwise, the label is SYMBOL, usually prefixed with 17615 '_'. 17616 17617 The 'symbol_ref' contains a mode, which is usually 'Pmode'. 17618 Usually that is the only mode for which a symbol is directly valid. 17619 17620'(label_ref:MODE LABEL)' 17621 Represents the value of an assembler label for code. It contains 17622 one operand, an expression, which must be a 'code_label' or a 17623 'note' of type 'NOTE_INSN_DELETED_LABEL' that appears in the 17624 instruction sequence to identify the place where the label should 17625 go. 17626 17627 The reason for using a distinct expression type for code label 17628 references is so that jump optimization can distinguish them. 17629 17630 The 'label_ref' contains a mode, which is usually 'Pmode'. Usually 17631 that is the only mode for which a label is directly valid. 17632 17633'(const:M EXP)' 17634 Represents a constant that is the result of an assembly-time 17635 arithmetic computation. The operand, EXP, contains only 17636 'const_int', 'symbol_ref', 'label_ref' or 'unspec' expressions, 17637 combined with 'plus' and 'minus'. Any such 'unspec's are 17638 target-specific and typically represent some form of relocation 17639 operator. M should be a valid address mode. 17640 17641'(high:M EXP)' 17642 Represents the high-order bits of EXP. The number of bits is 17643 machine-dependent and is normally the number of bits specified in 17644 an instruction that initializes the high order bits of a register. 17645 It is used with 'lo_sum' to represent the typical two-instruction 17646 sequence used in RISC machines to reference large immediate values 17647 and/or link-time constants such as global memory addresses. In the 17648 latter case, M is 'Pmode' and EXP is usually a constant expression 17649 involving 'symbol_ref'. 17650 17651 The macro 'CONST0_RTX (MODE)' refers to an expression with value 0 in 17652mode MODE. If mode MODE is of mode class 'MODE_INT', it returns 17653'const0_rtx'. If mode MODE is of mode class 'MODE_FLOAT', it returns a 17654'CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a 17655'CONST_VECTOR' expression in mode MODE. Similarly, the macro 17656'CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE 17657and similarly for 'CONST2_RTX'. The 'CONST1_RTX' and 'CONST2_RTX' 17658macros are undefined for vector modes. 17659 17660 17661File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 17662 1766314.8 Registers and Memory 17664========================= 17665 17666Here are the RTL expression types for describing access to machine 17667registers and to main memory. 17668 17669'(reg:M N)' 17670 For small values of the integer N (those that are less than 17671 'FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 17672 register number N: a "hard register". For larger values of N, it 17673 stands for a temporary value or "pseudo register". The compiler's 17674 strategy is to generate code assuming an unlimited number of such 17675 pseudo registers, and later convert them into hard registers or 17676 into memory references. 17677 17678 M is the machine mode of the reference. It is necessary because 17679 machines can generally refer to each register in more than one 17680 mode. For example, a register may contain a full word but there 17681 may be instructions to refer to it as a half word or as a single 17682 byte, as well as instructions to refer to it as a floating point 17683 number of various precisions. 17684 17685 Even for a register that the machine can access in only one mode, 17686 the mode must always be specified. 17687 17688 The symbol 'FIRST_PSEUDO_REGISTER' is defined by the machine 17689 description, since the number of hard registers on the machine is 17690 an invariant characteristic of the machine. Note, however, that 17691 not all of the machine registers must be general registers. All 17692 the machine registers that can be used for storage of data are 17693 given hard register numbers, even those that can be used only in 17694 certain instructions or can hold only certain types of data. 17695 17696 A hard register may be accessed in various modes throughout one 17697 function, but each pseudo register is given a natural mode and is 17698 accessed only in that mode. When it is necessary to describe an 17699 access to a pseudo register using a nonnatural mode, a 'subreg' 17700 expression is used. 17701 17702 A 'reg' expression with a machine mode that specifies more than one 17703 word of data may actually stand for several consecutive registers. 17704 If in addition the register number specifies a hardware register, 17705 then it actually represents several consecutive hardware registers 17706 starting with the specified one. 17707 17708 Each pseudo register number used in a function's RTL code is 17709 represented by a unique 'reg' expression. 17710 17711 Some pseudo register numbers, those within the range of 17712 'FIRST_VIRTUAL_REGISTER' to 'LAST_VIRTUAL_REGISTER' only appear 17713 during the RTL generation phase and are eliminated before the 17714 optimization phases. These represent locations in the stack frame 17715 that cannot be determined until RTL generation for the function has 17716 been completed. The following virtual register numbers are 17717 defined: 17718 17719 'VIRTUAL_INCOMING_ARGS_REGNUM' 17720 This points to the first word of the incoming arguments passed 17721 on the stack. Normally these arguments are placed there by 17722 the caller, but the callee may have pushed some arguments that 17723 were previously passed in registers. 17724 17725 When RTL generation is complete, this virtual register is 17726 replaced by the sum of the register given by 17727 'ARG_POINTER_REGNUM' and the value of 'FIRST_PARM_OFFSET'. 17728 17729 'VIRTUAL_STACK_VARS_REGNUM' 17730 If 'FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 17731 points to immediately above the first variable on the stack. 17732 Otherwise, it points to the first variable on the stack. 17733 17734 'VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 17735 register given by 'FRAME_POINTER_REGNUM' and the value 17736 'TARGET_STARTING_FRAME_OFFSET'. 17737 17738 'VIRTUAL_STACK_DYNAMIC_REGNUM' 17739 This points to the location of dynamically allocated memory on 17740 the stack immediately after the stack pointer has been 17741 adjusted by the amount of memory desired. 17742 17743 This virtual register is replaced by the sum of the register 17744 given by 'STACK_POINTER_REGNUM' and the value 17745 'STACK_DYNAMIC_OFFSET'. 17746 17747 'VIRTUAL_OUTGOING_ARGS_REGNUM' 17748 This points to the location in the stack at which outgoing 17749 arguments should be written when the stack is pre-pushed 17750 (arguments pushed using push insns should always use 17751 'STACK_POINTER_REGNUM'). 17752 17753 This virtual register is replaced by the sum of the register 17754 given by 'STACK_POINTER_REGNUM' and the value 17755 'STACK_POINTER_OFFSET'. 17756 17757'(subreg:M1 REG:M2 BYTENUM)' 17758 17759 'subreg' expressions are used to refer to a register in a machine 17760 mode other than its natural one, or to refer to one register of a 17761 multi-part 'reg' that actually refers to several registers. 17762 17763 Each pseudo register has a natural mode. If it is necessary to 17764 operate on it in a different mode, the register must be enclosed in 17765 a 'subreg'. 17766 17767 There are currently three supported types for the first operand of 17768 a 'subreg': 17769 * pseudo registers This is the most common case. Most 'subreg's 17770 have pseudo 'reg's as their first operand. 17771 17772 * mem 'subreg's of 'mem' were common in earlier versions of GCC 17773 and are still supported. During the reload pass these are 17774 replaced by plain 'mem's. On machines that do not do 17775 instruction scheduling, use of 'subreg's of 'mem' are still 17776 used, but this is no longer recommended. Such 'subreg's are 17777 considered to be 'register_operand's rather than 17778 'memory_operand's before and during reload. Because of this, 17779 the scheduling passes cannot properly schedule instructions 17780 with 'subreg's of 'mem', so for machines that do scheduling, 17781 'subreg's of 'mem' should never be used. To support this, the 17782 combine and recog passes have explicit code to inhibit the 17783 creation of 'subreg's of 'mem' when 'INSN_SCHEDULING' is 17784 defined. 17785 17786 The use of 'subreg's of 'mem' after the reload pass is an area 17787 that is not well understood and should be avoided. There is 17788 still some code in the compiler to support this, but this code 17789 has possibly rotted. This use of 'subreg's is discouraged and 17790 will most likely not be supported in the future. 17791 17792 * hard registers It is seldom necessary to wrap hard registers 17793 in 'subreg's; such registers would normally reduce to a single 17794 'reg' rtx. This use of 'subreg's is discouraged and may not 17795 be supported in the future. 17796 17797 'subreg's of 'subreg's are not supported. Using 17798 'simplify_gen_subreg' is the recommended way to avoid this problem. 17799 17800 'subreg's come in two distinct flavors, each having its own usage 17801 and rules: 17802 17803 Paradoxical subregs 17804 When M1 is strictly wider than M2, the 'subreg' expression is 17805 called "paradoxical". The canonical test for this class of 17806 'subreg' is: 17807 17808 paradoxical_subreg_p (M1, M2) 17809 17810 Paradoxical 'subreg's can be used as both lvalues and rvalues. 17811 When used as an lvalue, the low-order bits of the source value 17812 are stored in REG and the high-order bits are discarded. When 17813 used as an rvalue, the low-order bits of the 'subreg' are 17814 taken from REG while the high-order bits may or may not be 17815 defined. 17816 17817 The high-order bits of rvalues are defined in the following 17818 circumstances: 17819 17820 * 'subreg's of 'mem' When M2 is smaller than a word, the 17821 macro 'LOAD_EXTEND_OP', can control how the high-order 17822 bits are defined. 17823 17824 * 'subreg' of 'reg's The upper bits are defined when 17825 'SUBREG_PROMOTED_VAR_P' is true. 17826 'SUBREG_PROMOTED_UNSIGNED_P' describes what the upper 17827 bits hold. Such subregs usually represent local 17828 variables, register variables and parameter pseudo 17829 variables that have been promoted to a wider mode. 17830 17831 BYTENUM is always zero for a paradoxical 'subreg', even on 17832 big-endian targets. 17833 17834 For example, the paradoxical 'subreg': 17835 17836 (set (subreg:SI (reg:HI X) 0) Y) 17837 17838 stores the lower 2 bytes of Y in X and discards the upper 2 17839 bytes. A subsequent: 17840 17841 (set Z (subreg:SI (reg:HI X) 0)) 17842 17843 would set the lower two bytes of Z to Y and set the upper two 17844 bytes to an unknown value assuming 'SUBREG_PROMOTED_VAR_P' is 17845 false. 17846 17847 Normal subregs 17848 When M1 is at least as narrow as M2 the 'subreg' expression is 17849 called "normal". 17850 17851 Normal 'subreg's restrict consideration to certain bits of 17852 REG. For this purpose, REG is divided into 17853 individually-addressable blocks in which each block has: 17854 17855 REGMODE_NATURAL_SIZE (M2) 17856 17857 bytes. Usually the value is 'UNITS_PER_WORD'; that is, most 17858 targets usually treat each word of a register as being 17859 independently addressable. 17860 17861 There are two types of normal 'subreg'. If M1 is known to be 17862 no bigger than a block, the 'subreg' refers to the 17863 least-significant part (or "lowpart") of one block of REG. If 17864 M1 is known to be larger than a block, the 'subreg' refers to 17865 two or more complete blocks. 17866 17867 When used as an lvalue, 'subreg' is a block-based accessor. 17868 Storing to a 'subreg' modifies all the blocks of REG that 17869 overlap the 'subreg', but it leaves the other blocks of REG 17870 alone. 17871 17872 When storing to a normal 'subreg' that is smaller than a 17873 block, the other bits of the referenced block are usually left 17874 in an undefined state. This laxity makes it easier to 17875 generate efficient code for such instructions. To represent 17876 an instruction that preserves all the bits outside of those in 17877 the 'subreg', use 'strict_low_part' or 'zero_extract' around 17878 the 'subreg'. 17879 17880 BYTENUM must identify the offset of the first byte of the 17881 'subreg' from the start of REG, assuming that REG is laid out 17882 in memory order. The memory order of bytes is defined by two 17883 target macros, 'WORDS_BIG_ENDIAN' and 'BYTES_BIG_ENDIAN': 17884 17885 * 'WORDS_BIG_ENDIAN', if set to 1, says that byte number 17886 zero is part of the most significant word; otherwise, it 17887 is part of the least significant word. 17888 17889 * 'BYTES_BIG_ENDIAN', if set to 1, says that byte number 17890 zero is the most significant byte within a word; 17891 otherwise, it is the least significant byte within a 17892 word. 17893 17894 On a few targets, 'FLOAT_WORDS_BIG_ENDIAN' disagrees with 17895 'WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 17896 floating point values as if they had the same endianness as 17897 integer values. This works because they handle them solely as 17898 a collection of integer values, with no particular numerical 17899 value. Only real.c and the runtime libraries care about 17900 'FLOAT_WORDS_BIG_ENDIAN'. 17901 17902 Thus, 17903 17904 (subreg:HI (reg:SI X) 2) 17905 17906 on a 'BYTES_BIG_ENDIAN', 'UNITS_PER_WORD == 4' target is the 17907 same as 17908 17909 (subreg:HI (reg:SI X) 0) 17910 17911 on a little-endian, 'UNITS_PER_WORD == 4' target. Both 17912 'subreg's access the lower two bytes of register X. 17913 17914 Note that the byte offset is a polynomial integer; it may not 17915 be a compile-time constant on targets with variable-sized 17916 modes. However, the restrictions above mean that there are 17917 only a certain set of acceptable offsets for a given 17918 combination of M1 and M2. The compiler can always tell which 17919 blocks a valid subreg occupies, and whether the subreg is a 17920 lowpart of a block. 17921 17922 A 'MODE_PARTIAL_INT' mode behaves as if it were as wide as the 17923 corresponding 'MODE_INT' mode, except that it has a number of 17924 undefined bits, which are determined by the precision of the mode. 17925 17926 For example, on a little-endian target which defines 'PSImode' to 17927 have a precision of 20 bits: 17928 17929 (subreg:PSI (reg:SI 0) 0) 17930 17931 accesses the low 20 bits of '(reg:SI 0)'. 17932 17933 Continuing with a 'PSImode' precision of 20 bits, if we assume 17934 'REGMODE_NATURAL_SIZE (DImode) <= 4', then the following two 17935 'subreg's: 17936 17937 (subreg:PSI (reg:DI 0) 0) 17938 (subreg:PSI (reg:DI 0) 4) 17939 17940 represent accesses to the low 20 bits of the two halves of '(reg:DI 17941 0)'. 17942 17943 If 'REGMODE_NATURAL_SIZE (PSImode) <= 2' then these two 'subreg's: 17944 17945 (subreg:HI (reg:PSI 0) 0) 17946 (subreg:HI (reg:PSI 0) 2) 17947 17948 represent independent 2-byte accesses that together span the whole 17949 of '(reg:PSI 0)'. Storing to the first 'subreg' does not affect 17950 the value of the second, and vice versa, so the assignment: 17951 17952 (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4)) 17953 17954 sets the low 16 bits of '(reg:PSI 0)' to '(reg:HI 4)', and the high 17955 4 defined bits of '(reg:PSI 0)' retain their original value. The 17956 behavior here is the same as for normal 'subreg's, when there are 17957 no 'MODE_PARTIAL_INT' modes involved. 17958 17959 The rules above apply to both pseudo REGs and hard REGs. If the 17960 semantics are not correct for particular combinations of M1, M2 and 17961 hard REG, the target-specific code must ensure that those 17962 combinations are never used. For example: 17963 17964 TARGET_CAN_CHANGE_MODE_CLASS (M2, M1, CLASS) 17965 17966 must be false for every class CLASS that includes REG. 17967 17968 GCC must be able to determine at compile time whether a subreg is 17969 paradoxical, whether it occupies a whole number of blocks, or 17970 whether it is a lowpart of a block. This means that certain 17971 combinations of variable-sized mode are not permitted. For 17972 example, if M2 holds N 'SI' values, where N is greater than zero, 17973 it is not possible to form a 'DI' 'subreg' of it; such a 'subreg' 17974 would be paradoxical when N is 1 but not when N is greater than 1. 17975 17976 The first operand of a 'subreg' expression is customarily accessed 17977 with the 'SUBREG_REG' macro and the second operand is customarily 17978 accessed with the 'SUBREG_BYTE' macro. 17979 17980 It has been several years since a platform in which 17981 'BYTES_BIG_ENDIAN' not equal to 'WORDS_BIG_ENDIAN' has been tested. 17982 Anyone wishing to support such a platform in the future may be 17983 confronted with code rot. 17984 17985'(scratch:M)' 17986 This represents a scratch register that will be required for the 17987 execution of a single instruction and not used subsequently. It is 17988 converted into a 'reg' by either the local register allocator or 17989 the reload pass. 17990 17991 'scratch' is usually present inside a 'clobber' operation (*note 17992 Side Effects::). 17993 17994'(cc0)' 17995 This refers to the machine's condition code register. It has no 17996 operands and may not have a machine mode. There are two ways to 17997 use it: 17998 17999 * To stand for a complete set of condition code flags. This is 18000 best on most machines, where each comparison sets the entire 18001 series of flags. 18002 18003 With this technique, '(cc0)' may be validly used in only two 18004 contexts: as the destination of an assignment (in test and 18005 compare instructions) and in comparison operators comparing 18006 against zero ('const_int' with value zero; that is to say, 18007 'const0_rtx'). 18008 18009 * To stand for a single flag that is the result of a single 18010 condition. This is useful on machines that have only a single 18011 flag bit, and in which comparison instructions must specify 18012 the condition to test. 18013 18014 With this technique, '(cc0)' may be validly used in only two 18015 contexts: as the destination of an assignment (in test and 18016 compare instructions) where the source is a comparison 18017 operator, and as the first operand of 'if_then_else' (in a 18018 conditional branch). 18019 18020 There is only one expression object of code 'cc0'; it is the value 18021 of the variable 'cc0_rtx'. Any attempt to create an expression of 18022 code 'cc0' will return 'cc0_rtx'. 18023 18024 Instructions can set the condition code implicitly. On many 18025 machines, nearly all instructions set the condition code based on 18026 the value that they compute or store. It is not necessary to 18027 record these actions explicitly in the RTL because the machine 18028 description includes a prescription for recognizing the 18029 instructions that do so (by means of the macro 'NOTICE_UPDATE_CC'). 18030 *Note Condition Code::. Only instructions whose sole purpose is to 18031 set the condition code, and instructions that use the condition 18032 code, need mention '(cc0)'. 18033 18034 On some machines, the condition code register is given a register 18035 number and a 'reg' is used instead of '(cc0)'. This is usually the 18036 preferable approach if only a small subset of instructions modify 18037 the condition code. Other machines store condition codes in 18038 general registers; in such cases a pseudo register should be used. 18039 18040 Some machines, such as the SPARC and RS/6000, have two sets of 18041 arithmetic instructions, one that sets and one that does not set 18042 the condition code. This is best handled by normally generating 18043 the instruction that does not set the condition code, and making a 18044 pattern that both performs the arithmetic and sets the condition 18045 code register (which would not be '(cc0)' in this case). For 18046 examples, search for 'addcc' and 'andcc' in 'sparc.md'. 18047 18048'(pc)' 18049 This represents the machine's program counter. It has no operands 18050 and may not have a machine mode. '(pc)' may be validly used only 18051 in certain specific contexts in jump instructions. 18052 18053 There is only one expression object of code 'pc'; it is the value 18054 of the variable 'pc_rtx'. Any attempt to create an expression of 18055 code 'pc' will return 'pc_rtx'. 18056 18057 All instructions that do not jump alter the program counter 18058 implicitly by incrementing it, but there is no need to mention this 18059 in the RTL. 18060 18061'(mem:M ADDR ALIAS)' 18062 This RTX represents a reference to main memory at an address 18063 represented by the expression ADDR. M specifies how large a unit 18064 of memory is accessed. ALIAS specifies an alias set for the 18065 reference. In general two items are in different alias sets if 18066 they cannot reference the same memory address. 18067 18068 The construct '(mem:BLK (scratch))' is considered to alias all 18069 other memories. Thus it may be used as a memory barrier in 18070 epilogue stack deallocation patterns. 18071 18072'(concatM RTX RTX)' 18073 This RTX represents the concatenation of two other RTXs. This is 18074 used for complex values. It should only appear in the RTL attached 18075 to declarations and during RTL generation. It should not appear in 18076 the ordinary insn chain. 18077 18078'(concatnM [RTX ...])' 18079 This RTX represents the concatenation of all the RTX to make a 18080 single value. Like 'concat', this should only appear in 18081 declarations, and not in the insn chain. 18082 18083 18084File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 18085 1808614.9 RTL Expressions for Arithmetic 18087=================================== 18088 18089Unless otherwise specified, all the operands of arithmetic expressions 18090must be valid for mode M. An operand is valid for mode M if it has mode 18091M, or if it is a 'const_int' or 'const_double' and M is a mode of class 18092'MODE_INT'. 18093 18094 For commutative binary operations, constants should be placed in the 18095second operand. 18096 18097'(plus:M X Y)' 18098'(ss_plus:M X Y)' 18099'(us_plus:M X Y)' 18100 18101 These three expressions all represent the sum of the values 18102 represented by X and Y carried out in machine mode M. They differ 18103 in their behavior on overflow of integer modes. 'plus' wraps round 18104 modulo the width of M; 'ss_plus' saturates at the maximum signed 18105 value representable in M; 'us_plus' saturates at the maximum 18106 unsigned value. 18107 18108'(lo_sum:M X Y)' 18109 18110 This expression represents the sum of X and the low-order bits of 18111 Y. It is used with 'high' (*note Constants::) to represent the 18112 typical two-instruction sequence used in RISC machines to reference 18113 large immediate values and/or link-time constants such as global 18114 memory addresses. In the latter case, M is 'Pmode' and Y is 18115 usually a constant expression involving 'symbol_ref'. 18116 18117 The number of low order bits is machine-dependent but is normally 18118 the number of bits in mode M minus the number of bits set by 18119 'high'. 18120 18121'(minus:M X Y)' 18122'(ss_minus:M X Y)' 18123'(us_minus:M X Y)' 18124 18125 These three expressions represent the result of subtracting Y from 18126 X, carried out in mode M. Behavior on overflow is the same as for 18127 the three variants of 'plus' (see above). 18128 18129'(compare:M X Y)' 18130 Represents the result of subtracting Y from X for purposes of 18131 comparison. The result is computed without overflow, as if with 18132 infinite precision. 18133 18134 Of course, machines cannot really subtract with infinite precision. 18135 However, they can pretend to do so when only the sign of the result 18136 will be used, which is the case when the result is stored in the 18137 condition code. And that is the _only_ way this kind of expression 18138 may validly be used: as a value to be stored in the condition 18139 codes, either '(cc0)' or a register. *Note Comparisons::. 18140 18141 The mode M is not related to the modes of X and Y, but instead is 18142 the mode of the condition code value. If '(cc0)' is used, it is 18143 'VOIDmode'. Otherwise it is some mode in class 'MODE_CC', often 18144 'CCmode'. *Note Condition Code::. If M is 'VOIDmode' or 'CCmode', 18145 the operation returns sufficient information (in an unspecified 18146 format) so that any comparison operator can be applied to the 18147 result of the 'COMPARE' operation. For other modes in class 18148 'MODE_CC', the operation only returns a subset of this information. 18149 18150 Normally, X and Y must have the same mode. Otherwise, 'compare' is 18151 valid only if the mode of X is in class 'MODE_INT' and Y is a 18152 'const_int' or 'const_double' with mode 'VOIDmode'. The mode of X 18153 determines what mode the comparison is to be done in; thus it must 18154 not be 'VOIDmode'. 18155 18156 If one of the operands is a constant, it should be placed in the 18157 second operand and the comparison code adjusted as appropriate. 18158 18159 A 'compare' specifying two 'VOIDmode' constants is not valid since 18160 there is no way to know in what mode the comparison is to be 18161 performed; the comparison must either be folded during the 18162 compilation or the first operand must be loaded into a register 18163 while its mode is still known. 18164 18165'(neg:M X)' 18166'(ss_neg:M X)' 18167'(us_neg:M X)' 18168 These two expressions represent the negation (subtraction from 18169 zero) of the value represented by X, carried out in mode M. They 18170 differ in the behavior on overflow of integer modes. In the case 18171 of 'neg', the negation of the operand may be a number not 18172 representable in mode M, in which case it is truncated to M. 18173 'ss_neg' and 'us_neg' ensure that an out-of-bounds result saturates 18174 to the maximum or minimum signed or unsigned value. 18175 18176'(mult:M X Y)' 18177'(ss_mult:M X Y)' 18178'(us_mult:M X Y)' 18179 Represents the signed product of the values represented by X and Y 18180 carried out in machine mode M. 'ss_mult' and 'us_mult' ensure that 18181 an out-of-bounds result saturates to the maximum or minimum signed 18182 or unsigned value. 18183 18184 Some machines support a multiplication that generates a product 18185 wider than the operands. Write the pattern for this as 18186 18187 (mult:M (sign_extend:M X) (sign_extend:M Y)) 18188 18189 where M is wider than the modes of X and Y, which need not be the 18190 same. 18191 18192 For unsigned widening multiplication, use the same idiom, but with 18193 'zero_extend' instead of 'sign_extend'. 18194 18195'(fma:M X Y Z)' 18196 Represents the 'fma', 'fmaf', and 'fmal' builtin functions, which 18197 compute 'X * Y + Z' without doing an intermediate rounding step. 18198 18199'(div:M X Y)' 18200'(ss_div:M X Y)' 18201 Represents the quotient in signed division of X by Y, carried out 18202 in machine mode M. If M is a floating point mode, it represents 18203 the exact quotient; otherwise, the integerized quotient. 'ss_div' 18204 ensures that an out-of-bounds result saturates to the maximum or 18205 minimum signed value. 18206 18207 Some machines have division instructions in which the operands and 18208 quotient widths are not all the same; you should represent such 18209 instructions using 'truncate' and 'sign_extend' as in, 18210 18211 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 18212 18213'(udiv:M X Y)' 18214'(us_div:M X Y)' 18215 Like 'div' but represents unsigned division. 'us_div' ensures that 18216 an out-of-bounds result saturates to the maximum or minimum 18217 unsigned value. 18218 18219'(mod:M X Y)' 18220'(umod:M X Y)' 18221 Like 'div' and 'udiv' but represent the remainder instead of the 18222 quotient. 18223 18224'(smin:M X Y)' 18225'(smax:M X Y)' 18226 Represents the smaller (for 'smin') or larger (for 'smax') of X and 18227 Y, interpreted as signed values in mode M. When used with floating 18228 point, if both operands are zeros, or if either operand is 'NaN', 18229 then it is unspecified which of the two operands is returned as the 18230 result. 18231 18232'(umin:M X Y)' 18233'(umax:M X Y)' 18234 Like 'smin' and 'smax', but the values are interpreted as unsigned 18235 integers. 18236 18237'(not:M X)' 18238 Represents the bitwise complement of the value represented by X, 18239 carried out in mode M, which must be a fixed-point machine mode. 18240 18241'(and:M X Y)' 18242 Represents the bitwise logical-and of the values represented by X 18243 and Y, carried out in machine mode M, which must be a fixed-point 18244 machine mode. 18245 18246'(ior:M X Y)' 18247 Represents the bitwise inclusive-or of the values represented by X 18248 and Y, carried out in machine mode M, which must be a fixed-point 18249 mode. 18250 18251'(xor:M X Y)' 18252 Represents the bitwise exclusive-or of the values represented by X 18253 and Y, carried out in machine mode M, which must be a fixed-point 18254 mode. 18255 18256'(ashift:M X C)' 18257'(ss_ashift:M X C)' 18258'(us_ashift:M X C)' 18259 These three expressions represent the result of arithmetically 18260 shifting X left by C places. They differ in their behavior on 18261 overflow of integer modes. An 'ashift' operation is a plain shift 18262 with no special behavior in case of a change in the sign bit; 18263 'ss_ashift' and 'us_ashift' saturates to the minimum or maximum 18264 representable value if any of the bits shifted out differs from the 18265 final sign bit. 18266 18267 X have mode M, a fixed-point machine mode. C be a fixed-point mode 18268 or be a constant with mode 'VOIDmode'; which mode is determined by 18269 the mode called for in the machine description entry for the 18270 left-shift instruction. For example, on the VAX, the mode of C is 18271 'QImode' regardless of M. 18272 18273'(lshiftrt:M X C)' 18274'(ashiftrt:M X C)' 18275 Like 'ashift' but for right shift. Unlike the case for left shift, 18276 these two operations are distinct. 18277 18278'(rotate:M X C)' 18279'(rotatert:M X C)' 18280 Similar but represent left and right rotate. If C is a constant, 18281 use 'rotate'. 18282 18283'(abs:M X)' 18284'(ss_abs:M X)' 18285 Represents the absolute value of X, computed in mode M. 'ss_abs' 18286 ensures that an out-of-bounds result saturates to the maximum 18287 signed value. 18288 18289'(sqrt:M X)' 18290 Represents the square root of X, computed in mode M. Most often M 18291 will be a floating point mode. 18292 18293'(ffs:M X)' 18294 Represents one plus the index of the least significant 1-bit in X, 18295 represented as an integer of mode M. (The value is zero if X is 18296 zero.) The mode of X must be M or 'VOIDmode'. 18297 18298'(clrsb:M X)' 18299 Represents the number of redundant leading sign bits in X, 18300 represented as an integer of mode M, starting at the most 18301 significant bit position. This is one less than the number of 18302 leading sign bits (either 0 or 1), with no special cases. The mode 18303 of X must be M or 'VOIDmode'. 18304 18305'(clz:M X)' 18306 Represents the number of leading 0-bits in X, represented as an 18307 integer of mode M, starting at the most significant bit position. 18308 If X is zero, the value is determined by 18309 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one 18310 of the few expressions that is not invariant under widening. The 18311 mode of X must be M or 'VOIDmode'. 18312 18313'(ctz:M X)' 18314 Represents the number of trailing 0-bits in X, represented as an 18315 integer of mode M, starting at the least significant bit position. 18316 If X is zero, the value is determined by 18317 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case, 18318 'ctz(x)' is equivalent to 'ffs(X) - 1'. The mode of X must be M or 18319 'VOIDmode'. 18320 18321'(popcount:M X)' 18322 Represents the number of 1-bits in X, represented as an integer of 18323 mode M. The mode of X must be M or 'VOIDmode'. 18324 18325'(parity:M X)' 18326 Represents the number of 1-bits modulo 2 in X, represented as an 18327 integer of mode M. The mode of X must be M or 'VOIDmode'. 18328 18329'(bswap:M X)' 18330 Represents the value X with the order of bytes reversed, carried 18331 out in mode M, which must be a fixed-point machine mode. The mode 18332 of X must be M or 'VOIDmode'. 18333 18334 18335File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 18336 1833714.10 Comparison Operations 18338=========================== 18339 18340Comparison operators test a relation on two operands and are considered 18341to represent a machine-dependent nonzero value described by, but not 18342necessarily equal to, 'STORE_FLAG_VALUE' (*note Misc::) if the relation 18343holds, or zero if it does not, for comparison operators whose results 18344have a 'MODE_INT' mode, 'FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 18345relation holds, or zero if it does not, for comparison operators that 18346return floating-point values, and a vector of either 18347'VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 18348zeros if it does not, for comparison operators that return vector 18349results. The mode of the comparison operation is independent of the 18350mode of the data being compared. If the comparison operation is being 18351tested (e.g., the first operand of an 'if_then_else'), the mode must be 18352'VOIDmode'. 18353 18354 There are two ways that comparison operations may be used. The 18355comparison operators may be used to compare the condition codes '(cc0)' 18356against zero, as in '(eq (cc0) (const_int 0))'. Such a construct 18357actually refers to the result of the preceding instruction in which the 18358condition codes were set. The instruction setting the condition code 18359must be adjacent to the instruction using the condition code; only 18360'note' insns may separate them. 18361 18362 Alternatively, a comparison operation may directly compare two data 18363objects. The mode of the comparison is determined by the operands; they 18364must both be valid for a common machine mode. A comparison with both 18365operands constant would be invalid as the machine mode could not be 18366deduced from it, but such a comparison should never exist in RTL due to 18367constant folding. 18368 18369 In the example above, if '(cc0)' were last set to '(compare X Y)', the 18370comparison operation is identical to '(eq X Y)'. Usually only one style 18371of comparisons is supported on a particular machine, but the combine 18372pass will try to merge the operations to produce the 'eq' shown in case 18373it exists in the context of the particular insn involved. 18374 18375 Inequality comparisons come in two flavors, signed and unsigned. Thus, 18376there are distinct expression codes 'gt' and 'gtu' for signed and 18377unsigned greater-than. These can produce different results for the same 18378pair of integer values: for example, 1 is signed greater-than -1 but not 18379unsigned greater-than, because -1 when regarded as unsigned is actually 18380'0xffffffff' which is greater than 1. 18381 18382 The signed comparisons are also used for floating point values. 18383Floating point comparisons are distinguished by the machine modes of the 18384operands. 18385 18386'(eq:M X Y)' 18387 'STORE_FLAG_VALUE' if the values represented by X and Y are equal, 18388 otherwise 0. 18389 18390'(ne:M X Y)' 18391 'STORE_FLAG_VALUE' if the values represented by X and Y are not 18392 equal, otherwise 0. 18393 18394'(gt:M X Y)' 18395 'STORE_FLAG_VALUE' if the X is greater than Y. If they are 18396 fixed-point, the comparison is done in a signed sense. 18397 18398'(gtu:M X Y)' 18399 Like 'gt' but does unsigned comparison, on fixed-point numbers 18400 only. 18401 18402'(lt:M X Y)' 18403'(ltu:M X Y)' 18404 Like 'gt' and 'gtu' but test for "less than". 18405 18406'(ge:M X Y)' 18407'(geu:M X Y)' 18408 Like 'gt' and 'gtu' but test for "greater than or equal". 18409 18410'(le:M X Y)' 18411'(leu:M X Y)' 18412 Like 'gt' and 'gtu' but test for "less than or equal". 18413 18414'(if_then_else COND THEN ELSE)' 18415 This is not a comparison operation but is listed here because it is 18416 always used in conjunction with a comparison operation. To be 18417 precise, COND is a comparison expression. This expression 18418 represents a choice, according to COND, between the value 18419 represented by THEN and the one represented by ELSE. 18420 18421 On most machines, 'if_then_else' expressions are valid only to 18422 express conditional jumps. 18423 18424'(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 18425 Similar to 'if_then_else', but more general. Each of TEST1, TEST2, 18426 ... is performed in turn. The result of this expression is the 18427 VALUE corresponding to the first nonzero test, or DEFAULT if none 18428 of the tests are nonzero expressions. 18429 18430 This is currently not valid for instruction patterns and is 18431 supported only for insn attributes. *Note Insn Attributes::. 18432 18433 18434File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 18435 1843614.11 Bit-Fields 18437================ 18438 18439Special expression codes exist to represent bit-field instructions. 18440 18441'(sign_extract:M LOC SIZE POS)' 18442 This represents a reference to a sign-extended bit-field contained 18443 or starting in LOC (a memory or register reference). The bit-field 18444 is SIZE bits wide and starts at bit POS. The compilation option 18445 'BITS_BIG_ENDIAN' says which end of the memory unit POS counts 18446 from. 18447 18448 If LOC is in memory, its mode must be a single-byte integer mode. 18449 If LOC is in a register, the mode to use is specified by the 18450 operand of the 'insv' or 'extv' pattern (*note Standard Names::) 18451 and is usually a full-word integer mode, which is the default if 18452 none is specified. 18453 18454 The mode of POS is machine-specific and is also specified in the 18455 'insv' or 'extv' pattern. 18456 18457 The mode M is the same as the mode that would be used for LOC if it 18458 were a register. 18459 18460 A 'sign_extract' cannot appear as an lvalue, or part thereof, in 18461 RTL. 18462 18463'(zero_extract:M LOC SIZE POS)' 18464 Like 'sign_extract' but refers to an unsigned or zero-extended 18465 bit-field. The same sequence of bits are extracted, but they are 18466 filled to an entire word with zeros instead of by sign-extension. 18467 18468 Unlike 'sign_extract', this type of expressions can be lvalues in 18469 RTL; they may appear on the left side of an assignment, indicating 18470 insertion of a value into the specified bit-field. 18471 18472 18473File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 18474 1847514.12 Vector Operations 18476======================= 18477 18478All normal RTL expressions can be used with vector modes; they are 18479interpreted as operating on each part of the vector independently. 18480Additionally, there are a few new expressions to describe specific 18481vector operations. 18482 18483'(vec_merge:M VEC1 VEC2 ITEMS)' 18484 This describes a merge operation between two vectors. The result 18485 is a vector of mode M; its elements are selected from either VEC1 18486 or VEC2. Which elements are selected is described by ITEMS, which 18487 is a bit mask represented by a 'const_int'; a zero bit indicates 18488 the corresponding element in the result vector is taken from VEC2 18489 while a set bit indicates it is taken from VEC1. 18490 18491'(vec_select:M VEC1 SELECTION)' 18492 This describes an operation that selects parts of a vector. VEC1 18493 is the source vector, and SELECTION is a 'parallel' that contains a 18494 'const_int' (or another expression, if the selection can be made at 18495 runtime) for each of the subparts of the result vector, giving the 18496 number of the source subpart that should be stored into it. The 18497 result mode M is either the submode for a single element of VEC1 18498 (if only one subpart is selected), or another vector mode with that 18499 element submode (if multiple subparts are selected). 18500 18501'(vec_concat:M X1 X2)' 18502 Describes a vector concat operation. The result is a concatenation 18503 of the vectors or scalars X1 and X2; its length is the sum of the 18504 lengths of the two inputs. 18505 18506'(vec_duplicate:M X)' 18507 This operation converts a scalar into a vector or a small vector 18508 into a larger one by duplicating the input values. The output 18509 vector mode must have the same submodes as the input vector mode or 18510 the scalar modes, and the number of output parts must be an integer 18511 multiple of the number of input parts. 18512 18513'(vec_series:M BASE STEP)' 18514 This operation creates a vector in which element I is equal to 18515 'BASE + I*STEP'. M must be a vector integer mode. 18516 18517 18518File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 18519 1852014.13 Conversions 18521================= 18522 18523All conversions between machine modes must be represented by explicit 18524conversion operations. For example, an expression which is the sum of a 18525byte and a full word cannot be written as '(plus:SI (reg:QI 34) (reg:SI 1852680))' because the 'plus' operation requires two operands of the same 18527machine mode. Therefore, the byte-sized operand is enclosed in a 18528conversion operation, as in 18529 18530 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 18531 18532 The conversion operation is not a mere placeholder, because there may 18533be more than one way of converting from a given starting mode to the 18534desired final mode. The conversion operation code says how to do it. 18535 18536 For all conversion operations, X must not be 'VOIDmode' because the 18537mode in which to do the conversion would not be known. The conversion 18538must either be done at compile-time or X must be placed into a register. 18539 18540'(sign_extend:M X)' 18541 Represents the result of sign-extending the value X to machine mode 18542 M. M must be a fixed-point mode and X a fixed-point value of a 18543 mode narrower than M. 18544 18545'(zero_extend:M X)' 18546 Represents the result of zero-extending the value X to machine mode 18547 M. M must be a fixed-point mode and X a fixed-point value of a 18548 mode narrower than M. 18549 18550'(float_extend:M X)' 18551 Represents the result of extending the value X to machine mode M. 18552 M must be a floating point mode and X a floating point value of a 18553 mode narrower than M. 18554 18555'(truncate:M X)' 18556 Represents the result of truncating the value X to machine mode M. 18557 M must be a fixed-point mode and X a fixed-point value of a mode 18558 wider than M. 18559 18560'(ss_truncate:M X)' 18561 Represents the result of truncating the value X to machine mode M, 18562 using signed saturation in the case of overflow. Both M and the 18563 mode of X must be fixed-point modes. 18564 18565'(us_truncate:M X)' 18566 Represents the result of truncating the value X to machine mode M, 18567 using unsigned saturation in the case of overflow. Both M and the 18568 mode of X must be fixed-point modes. 18569 18570'(float_truncate:M X)' 18571 Represents the result of truncating the value X to machine mode M. 18572 M must be a floating point mode and X a floating point value of a 18573 mode wider than M. 18574 18575'(float:M X)' 18576 Represents the result of converting fixed point value X, regarded 18577 as signed, to floating point mode M. 18578 18579'(unsigned_float:M X)' 18580 Represents the result of converting fixed point value X, regarded 18581 as unsigned, to floating point mode M. 18582 18583'(fix:M X)' 18584 When M is a floating-point mode, represents the result of 18585 converting floating point value X (valid for mode M) to an integer, 18586 still represented in floating point mode M, by rounding towards 18587 zero. 18588 18589 When M is a fixed-point mode, represents the result of converting 18590 floating point value X to mode M, regarded as signed. How rounding 18591 is done is not specified, so this operation may be used validly in 18592 compiling C code only for integer-valued operands. 18593 18594'(unsigned_fix:M X)' 18595 Represents the result of converting floating point value X to fixed 18596 point mode M, regarded as unsigned. How rounding is done is not 18597 specified. 18598 18599'(fract_convert:M X)' 18600 Represents the result of converting fixed-point value X to 18601 fixed-point mode M, signed integer value X to fixed-point mode M, 18602 floating-point value X to fixed-point mode M, fixed-point value X 18603 to integer mode M regarded as signed, or fixed-point value X to 18604 floating-point mode M. When overflows or underflows happen, the 18605 results are undefined. 18606 18607'(sat_fract:M X)' 18608 Represents the result of converting fixed-point value X to 18609 fixed-point mode M, signed integer value X to fixed-point mode M, 18610 or floating-point value X to fixed-point mode M. When overflows or 18611 underflows happen, the results are saturated to the maximum or the 18612 minimum. 18613 18614'(unsigned_fract_convert:M X)' 18615 Represents the result of converting fixed-point value X to integer 18616 mode M regarded as unsigned, or unsigned integer value X to 18617 fixed-point mode M. When overflows or underflows happen, the 18618 results are undefined. 18619 18620'(unsigned_sat_fract:M X)' 18621 Represents the result of converting unsigned integer value X to 18622 fixed-point mode M. When overflows or underflows happen, the 18623 results are saturated to the maximum or the minimum. 18624 18625 18626File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 18627 1862814.14 Declarations 18629================== 18630 18631Declaration expression codes do not represent arithmetic operations but 18632rather state assertions about their operands. 18633 18634'(strict_low_part (subreg:M (reg:N R) 0))' 18635 This expression code is used in only one context: as the 18636 destination operand of a 'set' expression. In addition, the 18637 operand of this expression must be a non-paradoxical 'subreg' 18638 expression. 18639 18640 The presence of 'strict_low_part' says that the part of the 18641 register which is meaningful in mode N, but is not part of mode M, 18642 is not to be altered. Normally, an assignment to such a subreg is 18643 allowed to have undefined effects on the rest of the register when 18644 M is smaller than 'REGMODE_NATURAL_SIZE (N)'. 18645 18646 18647File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 18648 1864914.15 Side Effect Expressions 18650============================= 18651 18652The expression codes described so far represent values, not actions. 18653But machine instructions never produce values; they are meaningful only 18654for their side effects on the state of the machine. Special expression 18655codes are used to represent side effects. 18656 18657 The body of an instruction is always one of these side effect codes; 18658the codes described above, which represent values, appear only as the 18659operands of these. 18660 18661'(set LVAL X)' 18662 Represents the action of storing the value of X into the place 18663 represented by LVAL. LVAL must be an expression representing a 18664 place that can be stored in: 'reg' (or 'subreg', 'strict_low_part' 18665 or 'zero_extract'), 'mem', 'pc', 'parallel', or 'cc0'. 18666 18667 If LVAL is a 'reg', 'subreg' or 'mem', it has a machine mode; then 18668 X must be valid for that mode. 18669 18670 If LVAL is a 'reg' whose machine mode is less than the full width 18671 of the register, then it means that the part of the register 18672 specified by the machine mode is given the specified value and the 18673 rest of the register receives an undefined value. Likewise, if 18674 LVAL is a 'subreg' whose machine mode is narrower than the mode of 18675 the register, the rest of the register can be changed in an 18676 undefined way. 18677 18678 If LVAL is a 'strict_low_part' of a subreg, then the part of the 18679 register specified by the machine mode of the 'subreg' is given the 18680 value X and the rest of the register is not changed. 18681 18682 If LVAL is a 'zero_extract', then the referenced part of the 18683 bit-field (a memory or register reference) specified by the 18684 'zero_extract' is given the value X and the rest of the bit-field 18685 is not changed. Note that 'sign_extract' cannot appear in LVAL. 18686 18687 If LVAL is '(cc0)', it has no machine mode, and X may be either a 18688 'compare' expression or a value that may have any mode. The latter 18689 case represents a "test" instruction. The expression '(set (cc0) 18690 (reg:M N))' is equivalent to '(set (cc0) (compare (reg:M N) 18691 (const_int 0)))'. Use the former expression to save space during 18692 the compilation. 18693 18694 If LVAL is a 'parallel', it is used to represent the case of a 18695 function returning a structure in multiple registers. Each element 18696 of the 'parallel' is an 'expr_list' whose first operand is a 'reg' 18697 and whose second operand is a 'const_int' representing the offset 18698 (in bytes) into the structure at which the data in that register 18699 corresponds. The first element may be null to indicate that the 18700 structure is also passed partly in memory. 18701 18702 If LVAL is '(pc)', we have a jump instruction, and the 18703 possibilities for X are very limited. It may be a 'label_ref' 18704 expression (unconditional jump). It may be an 'if_then_else' 18705 (conditional jump), in which case either the second or the third 18706 operand must be '(pc)' (for the case which does not jump) and the 18707 other of the two must be a 'label_ref' (for the case which does 18708 jump). X may also be a 'mem' or '(plus:SI (pc) Y)', where Y may be 18709 a 'reg' or a 'mem'; these unusual patterns are used to represent 18710 jumps through branch tables. 18711 18712 If LVAL is neither '(cc0)' nor '(pc)', the mode of LVAL must not be 18713 'VOIDmode' and the mode of X must be valid for the mode of LVAL. 18714 18715 LVAL is customarily accessed with the 'SET_DEST' macro and X with 18716 the 'SET_SRC' macro. 18717 18718'(return)' 18719 As the sole expression in a pattern, represents a return from the 18720 current function, on machines where this can be done with one 18721 instruction, such as VAXen. On machines where a multi-instruction 18722 "epilogue" must be executed in order to return from the function, 18723 returning is done by jumping to a label which precedes the 18724 epilogue, and the 'return' expression code is never used. 18725 18726 Inside an 'if_then_else' expression, represents the value to be 18727 placed in 'pc' to return to the caller. 18728 18729 Note that an insn pattern of '(return)' is logically equivalent to 18730 '(set (pc) (return))', but the latter form is never used. 18731 18732'(simple_return)' 18733 Like '(return)', but truly represents only a function return, while 18734 '(return)' may represent an insn that also performs other functions 18735 of the function epilogue. Like '(return)', this may also occur in 18736 conditional jumps. 18737 18738'(call FUNCTION NARGS)' 18739 Represents a function call. FUNCTION is a 'mem' expression whose 18740 address is the address of the function to be called. NARGS is an 18741 expression which can be used for two purposes: on some machines it 18742 represents the number of bytes of stack argument; on others, it 18743 represents the number of argument registers. 18744 18745 Each machine has a standard machine mode which FUNCTION must have. 18746 The machine description defines macro 'FUNCTION_MODE' to expand 18747 into the requisite mode name. The purpose of this mode is to 18748 specify what kind of addressing is allowed, on machines where the 18749 allowed kinds of addressing depend on the machine mode being 18750 addressed. 18751 18752'(clobber X)' 18753 Represents the storing or possible storing of an unpredictable, 18754 undescribed value into X, which must be a 'reg', 'scratch', 18755 'parallel' or 'mem' expression. 18756 18757 One place this is used is in string instructions that store 18758 standard values into particular hard registers. It may not be 18759 worth the trouble to describe the values that are stored, but it is 18760 essential to inform the compiler that the registers will be 18761 altered, lest it attempt to keep data in them across the string 18762 instruction. 18763 18764 If X is '(mem:BLK (const_int 0))' or '(mem:BLK (scratch))', it 18765 means that all memory locations must be presumed clobbered. If X 18766 is a 'parallel', it has the same meaning as a 'parallel' in a 'set' 18767 expression. 18768 18769 Note that the machine description classifies certain hard registers 18770 as "call-clobbered". All function call instructions are assumed by 18771 default to clobber these registers, so there is no need to use 18772 'clobber' expressions to indicate this fact. Also, each function 18773 call is assumed to have the potential to alter any memory location, 18774 unless the function is declared 'const'. 18775 18776 If the last group of expressions in a 'parallel' are each a 18777 'clobber' expression whose arguments are 'reg' or 'match_scratch' 18778 (*note RTL Template::) expressions, the combiner phase can add the 18779 appropriate 'clobber' expressions to an insn it has constructed 18780 when doing so will cause a pattern to be matched. 18781 18782 This feature can be used, for example, on a machine that whose 18783 multiply and add instructions don't use an MQ register but which 18784 has an add-accumulate instruction that does clobber the MQ 18785 register. Similarly, a combined instruction might require a 18786 temporary register while the constituent instructions might not. 18787 18788 When a 'clobber' expression for a register appears inside a 18789 'parallel' with other side effects, the register allocator 18790 guarantees that the register is unoccupied both before and after 18791 that insn if it is a hard register clobber. For pseudo-register 18792 clobber, the register allocator and the reload pass do not assign 18793 the same hard register to the clobber and the input operands if 18794 there is an insn alternative containing the '&' constraint (*note 18795 Modifiers::) for the clobber and the hard register is in register 18796 classes of the clobber in the alternative. You can clobber either 18797 a specific hard register, a pseudo register, or a 'scratch' 18798 expression; in the latter two cases, GCC will allocate a hard 18799 register that is available there for use as a temporary. 18800 18801 For instructions that require a temporary register, you should use 18802 'scratch' instead of a pseudo-register because this will allow the 18803 combiner phase to add the 'clobber' when required. You do this by 18804 coding ('clobber' ('match_scratch' ...)). If you do clobber a 18805 pseudo register, use one which appears nowhere else--generate a new 18806 one each time. Otherwise, you may confuse CSE. 18807 18808 There is one other known use for clobbering a pseudo register in a 18809 'parallel': when one of the input operands of the insn is also 18810 clobbered by the insn. In this case, using the same pseudo 18811 register in the clobber and elsewhere in the insn produces the 18812 expected results. 18813 18814'(use X)' 18815 Represents the use of the value of X. It indicates that the value 18816 in X at this point in the program is needed, even though it may not 18817 be apparent why this is so. Therefore, the compiler will not 18818 attempt to delete previous instructions whose only effect is to 18819 store a value in X. X must be a 'reg' expression. 18820 18821 In some situations, it may be tempting to add a 'use' of a register 18822 in a 'parallel' to describe a situation where the value of a 18823 special register will modify the behavior of the instruction. A 18824 hypothetical example might be a pattern for an addition that can 18825 either wrap around or use saturating addition depending on the 18826 value of a special control register: 18827 18828 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 18829 (reg:SI 4)] 0)) 18830 (use (reg:SI 1))]) 18831 18832 18833 This will not work, several of the optimizers only look at 18834 expressions locally; it is very likely that if you have multiple 18835 insns with identical inputs to the 'unspec', they will be optimized 18836 away even if register 1 changes in between. 18837 18838 This means that 'use' can _only_ be used to describe that the 18839 register is live. You should think twice before adding 'use' 18840 statements, more often you will want to use 'unspec' instead. The 18841 'use' RTX is most commonly useful to describe that a fixed register 18842 is implicitly used in an insn. It is also safe to use in patterns 18843 where the compiler knows for other reasons that the result of the 18844 whole pattern is variable, such as 'cpymemM' or 'call' patterns. 18845 18846 During the reload phase, an insn that has a 'use' as pattern can 18847 carry a reg_equal note. These 'use' insns will be deleted before 18848 the reload phase exits. 18849 18850 During the delayed branch scheduling phase, X may be an insn. This 18851 indicates that X previously was located at this place in the code 18852 and its data dependencies need to be taken into account. These 18853 'use' insns will be deleted before the delayed branch scheduling 18854 phase exits. 18855 18856'(parallel [X0 X1 ...])' 18857 Represents several side effects performed in parallel. The square 18858 brackets stand for a vector; the operand of 'parallel' is a vector 18859 of expressions. X0, X1 and so on are individual side effect 18860 expressions--expressions of code 'set', 'call', 'return', 18861 'simple_return', 'clobber' or 'use'. 18862 18863 "In parallel" means that first all the values used in the 18864 individual side-effects are computed, and second all the actual 18865 side-effects are performed. For example, 18866 18867 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 18868 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 18869 18870 says unambiguously that the values of hard register 1 and the 18871 memory location addressed by it are interchanged. In both places 18872 where '(reg:SI 1)' appears as a memory address it refers to the 18873 value in register 1 _before_ the execution of the insn. 18874 18875 It follows that it is _incorrect_ to use 'parallel' and expect the 18876 result of one 'set' to be available for the next one. For example, 18877 people sometimes attempt to represent a jump-if-zero instruction 18878 this way: 18879 18880 (parallel [(set (cc0) (reg:SI 34)) 18881 (set (pc) (if_then_else 18882 (eq (cc0) (const_int 0)) 18883 (label_ref ...) 18884 (pc)))]) 18885 18886 But this is incorrect, because it says that the jump condition 18887 depends on the condition code value _before_ this instruction, not 18888 on the new value that is set by this instruction. 18889 18890 Peephole optimization, which takes place together with final 18891 assembly code output, can produce insns whose patterns consist of a 18892 'parallel' whose elements are the operands needed to output the 18893 resulting assembler code--often 'reg', 'mem' or constant 18894 expressions. This would not be well-formed RTL at any other stage 18895 in compilation, but it is OK then because no further optimization 18896 remains to be done. However, the definition of the macro 18897 'NOTICE_UPDATE_CC', if any, must deal with such insns if you define 18898 any peephole optimizations. 18899 18900'(cond_exec [COND EXPR])' 18901 Represents a conditionally executed expression. The EXPR is 18902 executed only if the COND is nonzero. The COND expression must not 18903 have side-effects, but the EXPR may very well have side-effects. 18904 18905'(sequence [INSNS ...])' 18906 Represents a sequence of insns. If a 'sequence' appears in the 18907 chain of insns, then each of the INSNS that appears in the sequence 18908 must be suitable for appearing in the chain of insns, i.e. must 18909 satisfy the 'INSN_P' predicate. 18910 18911 After delay-slot scheduling is completed, an insn and all the insns 18912 that reside in its delay slots are grouped together into a 18913 'sequence'. The insn requiring the delay slot is the first insn in 18914 the vector; subsequent insns are to be placed in the delay slot. 18915 18916 'INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 18917 indicate that a branch insn should be used that will conditionally 18918 annul the effect of the insns in the delay slots. In such a case, 18919 'INSN_FROM_TARGET_P' indicates that the insn is from the target of 18920 the branch and should be executed only if the branch is taken; 18921 otherwise the insn should be executed only if the branch is not 18922 taken. *Note Delay Slots::. 18923 18924 Some back ends also use 'sequence' objects for purposes other than 18925 delay-slot groups. This is not supported in the common parts of 18926 the compiler, which treat such sequences as delay-slot groups. 18927 18928 DWARF2 Call Frame Address (CFA) adjustments are sometimes also 18929 expressed using 'sequence' objects as the value of a 18930 'RTX_FRAME_RELATED_P' note. This only happens if the CFA 18931 adjustments cannot be easily derived from the pattern of the 18932 instruction to which the note is attached. In such cases, the 18933 value of the note is used instead of best-guesing the semantics of 18934 the instruction. The back end can attach notes containing a 18935 'sequence' of 'set' patterns that express the effect of the parent 18936 instruction. 18937 18938 These expression codes appear in place of a side effect, as the body of 18939an insn, though strictly speaking they do not always describe side 18940effects as such: 18941 18942'(asm_input S)' 18943 Represents literal assembler code as described by the string S. 18944 18945'(unspec [OPERANDS ...] INDEX)' 18946'(unspec_volatile [OPERANDS ...] INDEX)' 18947 Represents a machine-specific operation on OPERANDS. INDEX selects 18948 between multiple machine-specific operations. 'unspec_volatile' is 18949 used for volatile operations and operations that may trap; 'unspec' 18950 is used for other operations. 18951 18952 These codes may appear inside a 'pattern' of an insn, inside a 18953 'parallel', or inside an expression. 18954 18955'(addr_vec:M [LR0 LR1 ...])' 18956 Represents a table of jump addresses. The vector elements LR0, 18957 etc., are 'label_ref' expressions. The mode M specifies how much 18958 space is given to each address; normally M would be 'Pmode'. 18959 18960'(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 18961 Represents a table of jump addresses expressed as offsets from 18962 BASE. The vector elements LR0, etc., are 'label_ref' expressions 18963 and so is BASE. The mode M specifies how much space is given to 18964 each address-difference. MIN and MAX are set up by branch 18965 shortening and hold a label with a minimum and a maximum address, 18966 respectively. FLAGS indicates the relative position of BASE, MIN 18967 and MAX to the containing insn and of MIN and MAX to BASE. See 18968 rtl.def for details. 18969 18970'(prefetch:M ADDR RW LOCALITY)' 18971 Represents prefetch of memory at address ADDR. Operand RW is 1 if 18972 the prefetch is for data to be written, 0 otherwise; targets that 18973 do not support write prefetches should treat this as a normal 18974 prefetch. Operand LOCALITY specifies the amount of temporal 18975 locality; 0 if there is none or 1, 2, or 3 for increasing levels of 18976 temporal locality; targets that do not support locality hints 18977 should ignore this. 18978 18979 This insn is used to minimize cache-miss latency by moving data 18980 into a cache before it is accessed. It should use only 18981 non-faulting data prefetch instructions. 18982 18983 18984File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 18985 1898614.16 Embedded Side-Effects on Addresses 18987======================================== 18988 18989Six special side-effect expression codes appear as memory addresses. 18990 18991'(pre_dec:M X)' 18992 Represents the side effect of decrementing X by a standard amount 18993 and represents also the value that X has after being decremented. 18994 X must be a 'reg' or 'mem', but most machines allow only a 'reg'. 18995 M must be the machine mode for pointers on the machine in use. The 18996 amount X is decremented by is the length in bytes of the machine 18997 mode of the containing memory reference of which this expression 18998 serves as the address. Here is an example of its use: 18999 19000 (mem:DF (pre_dec:SI (reg:SI 39))) 19001 19002 This says to decrement pseudo register 39 by the length of a 19003 'DFmode' value and use the result to address a 'DFmode' value. 19004 19005'(pre_inc:M X)' 19006 Similar, but specifies incrementing X instead of decrementing it. 19007 19008'(post_dec:M X)' 19009 Represents the same side effect as 'pre_dec' but a different value. 19010 The value represented here is the value X has before being 19011 decremented. 19012 19013'(post_inc:M X)' 19014 Similar, but specifies incrementing X instead of decrementing it. 19015 19016'(post_modify:M X Y)' 19017 19018 Represents the side effect of setting X to Y and represents X 19019 before X is modified. X must be a 'reg' or 'mem', but most 19020 machines allow only a 'reg'. M must be the machine mode for 19021 pointers on the machine in use. 19022 19023 The expression Y must be one of three forms: '(plus:M X Z)', 19024 '(minus:M X Z)', or '(plus:M X I)', where Z is an index register 19025 and I is a constant. 19026 19027 Here is an example of its use: 19028 19029 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 19030 (reg:SI 48)))) 19031 19032 This says to modify pseudo register 42 by adding the contents of 19033 pseudo register 48 to it, after the use of what ever 42 points to. 19034 19035'(pre_modify:M X EXPR)' 19036 Similar except side effects happen before the use. 19037 19038 These embedded side effect expressions must be used with care. 19039Instruction patterns may not use them. Until the 'flow' pass of the 19040compiler, they may occur only to represent pushes onto the stack. The 19041'flow' pass finds cases where registers are incremented or decremented 19042in one instruction and used as an address shortly before or after; these 19043cases are then transformed to use pre- or post-increment or -decrement. 19044 19045 If a register used as the operand of these expressions is used in 19046another address in an insn, the original value of the register is used. 19047Uses of the register outside of an address are not permitted within the 19048same insn as a use in an embedded side effect expression because such 19049insns behave differently on different machines and hence must be treated 19050as ambiguous and disallowed. 19051 19052 An instruction that can be represented with an embedded side effect 19053could also be represented using 'parallel' containing an additional 19054'set' to describe how the address register is altered. This is not done 19055because machines that allow these operations at all typically allow them 19056wherever a memory address is called for. Describing them as additional 19057parallel stores would require doubling the number of entries in the 19058machine description. 19059 19060 19061File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL 19062 1906314.17 Assembler Instructions as Expressions 19064=========================================== 19065 19066The RTX code 'asm_operands' represents a value produced by a 19067user-specified assembler instruction. It is used to represent an 'asm' 19068statement with arguments. An 'asm' statement with a single output 19069operand, like this: 19070 19071 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 19072 19073is represented using a single 'asm_operands' RTX which represents the 19074value that is stored in 'outputvar': 19075 19076 (set RTX-FOR-OUTPUTVAR 19077 (asm_operands "foo %1,%2,%0" "a" 0 19078 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 19079 [(asm_input:M1 "g") 19080 (asm_input:M2 "di")])) 19081 19082Here the operands of the 'asm_operands' RTX are the assembler template 19083string, the output-operand's constraint, the index-number of the output 19084operand among the output operands specified, a vector of input operand 19085RTX's, and a vector of input-operand modes and constraints. The mode M1 19086is the mode of the sum 'x+y'; M2 is that of '*z'. 19087 19088 When an 'asm' statement has multiple output values, its insn has 19089several such 'set' RTX's inside of a 'parallel'. Each 'set' contains an 19090'asm_operands'; all of these share the same assembler template and 19091vectors, but each contains the constraint for the respective output 19092operand. They are also distinguished by the output-operand index 19093number, which is 0, 1, ... for successive output operands. 19094 19095 19096File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL 19097 1909814.18 Variable Location Debug Information in RTL 19099================================================ 19100 19101Variable tracking relies on 'MEM_EXPR' and 'REG_EXPR' annotations to 19102determine what user variables memory and register references refer to. 19103 19104 Variable tracking at assignments uses these notes only when they refer 19105to variables that live at fixed locations (e.g., addressable variables, 19106global non-automatic variables). For variables whose location may vary, 19107it relies on the following types of notes. 19108 19109'(var_location:MODE VAR EXP STAT)' 19110 Binds variable 'var', a tree, to value EXP, an RTL expression. It 19111 appears only in 'NOTE_INSN_VAR_LOCATION' and 'DEBUG_INSN's, with 19112 slightly different meanings. MODE, if present, represents the mode 19113 of EXP, which is useful if it is a modeless expression. STAT is 19114 only meaningful in notes, indicating whether the variable is known 19115 to be initialized or uninitialized. 19116 19117'(debug_expr:MODE DECL)' 19118 Stands for the value bound to the 'DEBUG_EXPR_DECL' DECL, that 19119 points back to it, within value expressions in 'VAR_LOCATION' 19120 nodes. 19121 19122'(debug_implicit_ptr:MODE DECL)' 19123 Stands for the location of a DECL that is no longer addressable. 19124 19125'(entry_value:MODE DECL)' 19126 Stands for the value a DECL had at the entry point of the 19127 containing function. 19128 19129'(debug_parameter_ref:MODE DECL)' 19130 Refers to a parameter that was completely optimized out. 19131 19132'(debug_marker:MODE)' 19133 Marks a program location. With 'VOIDmode', it stands for the 19134 beginning of a statement, a recommended inspection point logically 19135 after all prior side effects, and before any subsequent side 19136 effects. With 'BLKmode', it indicates an inline entry point: the 19137 lexical block encoded in the 'INSN_LOCATION' is the enclosing block 19138 that encloses the inlined function. 19139 19140 19141File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL 19142 1914314.19 Insns 19144=========== 19145 19146The RTL representation of the code for a function is a doubly-linked 19147chain of objects called "insns". Insns are expressions with special 19148codes that are used for no other purpose. Some insns are actual 19149instructions; others represent dispatch tables for 'switch' statements; 19150others represent labels to jump to or various sorts of declarative 19151information. 19152 19153 In addition to its own specific data, each insn must have a unique 19154id-number that distinguishes it from all other insns in the current 19155function (after delayed branch scheduling, copies of an insn with the 19156same id-number may be present in multiple places in a function, but 19157these copies will always be identical and will only appear inside a 19158'sequence'), and chain pointers to the preceding and following insns. 19159These three fields occupy the same position in every insn, independent 19160of the expression code of the insn. They could be accessed with 'XEXP' 19161and 'XINT', but instead three special macros are always used: 19162 19163'INSN_UID (I)' 19164 Accesses the unique id of insn I. 19165 19166'PREV_INSN (I)' 19167 Accesses the chain pointer to the insn preceding I. If I is the 19168 first insn, this is a null pointer. 19169 19170'NEXT_INSN (I)' 19171 Accesses the chain pointer to the insn following I. If I is the 19172 last insn, this is a null pointer. 19173 19174 The first insn in the chain is obtained by calling 'get_insns'; the 19175last insn is the result of calling 'get_last_insn'. Within the chain 19176delimited by these insns, the 'NEXT_INSN' and 'PREV_INSN' pointers must 19177always correspond: if INSN is not the first insn, 19178 19179 NEXT_INSN (PREV_INSN (INSN)) == INSN 19180 19181is always true and if INSN is not the last insn, 19182 19183 PREV_INSN (NEXT_INSN (INSN)) == INSN 19184 19185is always true. 19186 19187 After delay slot scheduling, some of the insns in the chain might be 19188'sequence' expressions, which contain a vector of insns. The value of 19189'NEXT_INSN' in all but the last of these insns is the next insn in the 19190vector; the value of 'NEXT_INSN' of the last insn in the vector is the 19191same as the value of 'NEXT_INSN' for the 'sequence' in which it is 19192contained. Similar rules apply for 'PREV_INSN'. 19193 19194 This means that the above invariants are not necessarily true for insns 19195inside 'sequence' expressions. Specifically, if INSN is the first insn 19196in a 'sequence', 'NEXT_INSN (PREV_INSN (INSN))' is the insn containing 19197the 'sequence' expression, as is the value of 'PREV_INSN (NEXT_INSN 19198(INSN))' if INSN is the last insn in the 'sequence' expression. You can 19199use these expressions to find the containing 'sequence' expression. 19200 19201 Every insn has one of the following expression codes: 19202 19203'insn' 19204 The expression code 'insn' is used for instructions that do not 19205 jump and do not do function calls. 'sequence' expressions are 19206 always contained in insns with code 'insn' even if one of those 19207 insns should jump or do function calls. 19208 19209 Insns with code 'insn' have four additional fields beyond the three 19210 mandatory ones listed above. These four are described in a table 19211 below. 19212 19213'jump_insn' 19214 The expression code 'jump_insn' is used for instructions that may 19215 jump (or, more generally, may contain 'label_ref' expressions to 19216 which 'pc' can be set in that instruction). If there is an 19217 instruction to return from the current function, it is recorded as 19218 a 'jump_insn'. 19219 19220 'jump_insn' insns have the same extra fields as 'insn' insns, 19221 accessed in the same way and in addition contain a field 19222 'JUMP_LABEL' which is defined once jump optimization has completed. 19223 19224 For simple conditional and unconditional jumps, this field contains 19225 the 'code_label' to which this insn will (possibly conditionally) 19226 branch. In a more complex jump, 'JUMP_LABEL' records one of the 19227 labels that the insn refers to; other jump target labels are 19228 recorded as 'REG_LABEL_TARGET' notes. The exception is 'addr_vec' 19229 and 'addr_diff_vec', where 'JUMP_LABEL' is 'NULL_RTX' and the only 19230 way to find the labels is to scan the entire body of the insn. 19231 19232 Return insns count as jumps, but their 'JUMP_LABEL' is 'RETURN' or 19233 'SIMPLE_RETURN'. 19234 19235'call_insn' 19236 The expression code 'call_insn' is used for instructions that may 19237 do function calls. It is important to distinguish these 19238 instructions because they imply that certain registers and memory 19239 locations may be altered unpredictably. 19240 19241 'call_insn' insns have the same extra fields as 'insn' insns, 19242 accessed in the same way and in addition contain a field 19243 'CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 19244 'expr_list' expressions) containing 'use', 'clobber' and sometimes 19245 'set' expressions that denote hard registers and 'mem's used or 19246 clobbered by the called function. 19247 19248 A 'mem' generally points to a stack slot in which arguments passed 19249 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 19250 Register Arguments.) are stored. If the argument is caller-copied 19251 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 19252 will be mentioned in 'clobber' and 'use' entries; if it's 19253 callee-copied, only a 'use' will appear, and the 'mem' may point to 19254 addresses that are not stack slots. 19255 19256 Registers occurring inside a 'clobber' in this list augment 19257 registers specified in 'CALL_USED_REGISTERS' (*note Register 19258 Basics::). 19259 19260 If the list contains a 'set' involving two registers, it indicates 19261 that the function returns one of its arguments. Such a 'set' may 19262 look like a no-op if the same register holds the argument and the 19263 return value. 19264 19265'code_label' 19266 A 'code_label' insn represents a label that a jump insn can jump 19267 to. It contains two special fields of data in addition to the 19268 three standard ones. 'CODE_LABEL_NUMBER' is used to hold the 19269 "label number", a number that identifies this label uniquely among 19270 all the labels in the compilation (not just in the current 19271 function). Ultimately, the label is represented in the assembler 19272 output as an assembler label, usually of the form 'LN' where N is 19273 the label number. 19274 19275 When a 'code_label' appears in an RTL expression, it normally 19276 appears within a 'label_ref' which represents the address of the 19277 label, as a number. 19278 19279 Besides as a 'code_label', a label can also be represented as a 19280 'note' of type 'NOTE_INSN_DELETED_LABEL'. 19281 19282 The field 'LABEL_NUSES' is only defined once the jump optimization 19283 phase is completed. It contains the number of times this label is 19284 referenced in the current function. 19285 19286 The field 'LABEL_KIND' differentiates four different types of 19287 labels: 'LABEL_NORMAL', 'LABEL_STATIC_ENTRY', 'LABEL_GLOBAL_ENTRY', 19288 and 'LABEL_WEAK_ENTRY'. The only labels that do not have type 19289 'LABEL_NORMAL' are "alternate entry points" to the current 19290 function. These may be static (visible only in the containing 19291 translation unit), global (exposed to all translation units), or 19292 weak (global, but can be overridden by another symbol with the same 19293 name). 19294 19295 Much of the compiler treats all four kinds of label identically. 19296 Some of it needs to know whether or not a label is an alternate 19297 entry point; for this purpose, the macro 'LABEL_ALT_ENTRY_P' is 19298 provided. It is equivalent to testing whether 'LABEL_KIND (label) 19299 == LABEL_NORMAL'. The only place that cares about the distinction 19300 between static, global, and weak alternate entry points, besides 19301 the front-end code that creates them, is the function 19302 'output_alternate_entry_point', in 'final.c'. 19303 19304 To set the kind of a label, use the 'SET_LABEL_KIND' macro. 19305 19306'jump_table_data' 19307 A 'jump_table_data' insn is a placeholder for the jump-table data 19308 of a 'casesi' or 'tablejump' insn. They are placed after a 19309 'tablejump_p' insn. A 'jump_table_data' insn is not part o a basic 19310 blockm but it is associated with the basic block that ends with the 19311 'tablejump_p' insn. The 'PATTERN' of a 'jump_table_data' is always 19312 either an 'addr_vec' or an 'addr_diff_vec', and a 'jump_table_data' 19313 insn is always preceded by a 'code_label'. The 'tablejump_p' insn 19314 refers to that 'code_label' via its 'JUMP_LABEL'. 19315 19316'barrier' 19317 Barriers are placed in the instruction stream when control cannot 19318 flow past them. They are placed after unconditional jump 19319 instructions to indicate that the jumps are unconditional and after 19320 calls to 'volatile' functions, which do not return (e.g., 'exit'). 19321 They contain no information beyond the three standard fields. 19322 19323'note' 19324 'note' insns are used to represent additional debugging and 19325 declarative information. They contain two nonstandard fields, an 19326 integer which is accessed with the macro 'NOTE_LINE_NUMBER' and a 19327 string accessed with 'NOTE_SOURCE_FILE'. 19328 19329 If 'NOTE_LINE_NUMBER' is positive, the note represents the position 19330 of a source line and 'NOTE_SOURCE_FILE' is the source file name 19331 that the line came from. These notes control generation of line 19332 number data in the assembler output. 19333 19334 Otherwise, 'NOTE_LINE_NUMBER' is not really a line number but a 19335 code with one of the following values (and 'NOTE_SOURCE_FILE' must 19336 contain a null pointer): 19337 19338 'NOTE_INSN_DELETED' 19339 Such a note is completely ignorable. Some passes of the 19340 compiler delete insns by altering them into notes of this 19341 kind. 19342 19343 'NOTE_INSN_DELETED_LABEL' 19344 This marks what used to be a 'code_label', but was not used 19345 for other purposes than taking its address and was transformed 19346 to mark that no code jumps to it. 19347 19348 'NOTE_INSN_BLOCK_BEG' 19349 'NOTE_INSN_BLOCK_END' 19350 These types of notes indicate the position of the beginning 19351 and end of a level of scoping of variable names. They control 19352 the output of debugging information. 19353 19354 'NOTE_INSN_EH_REGION_BEG' 19355 'NOTE_INSN_EH_REGION_END' 19356 These types of notes indicate the position of the beginning 19357 and end of a level of scoping for exception handling. 19358 'NOTE_EH_HANDLER' identifies which region is associated with 19359 these notes. 19360 19361 'NOTE_INSN_FUNCTION_BEG' 19362 Appears at the start of the function body, after the function 19363 prologue. 19364 19365 'NOTE_INSN_VAR_LOCATION' 19366 This note is used to generate variable location debugging 19367 information. It indicates that the user variable in its 19368 'VAR_LOCATION' operand is at the location given in the RTL 19369 expression, or holds a value that can be computed by 19370 evaluating the RTL expression from that static point in the 19371 program up to the next such note for the same user variable. 19372 19373 'NOTE_INSN_BEGIN_STMT' 19374 This note is used to generate 'is_stmt' markers in line number 19375 debugging information. It indicates the beginning of a user 19376 statement. 19377 19378 'NOTE_INSN_INLINE_ENTRY' 19379 This note is used to generate 'entry_pc' for inlined 19380 subroutines in debugging information. It indicates an 19381 inspection point at which all arguments for the inlined 19382 function have been bound, and before its first statement. 19383 19384 These codes are printed symbolically when they appear in debugging 19385 dumps. 19386 19387'debug_insn' 19388 The expression code 'debug_insn' is used for pseudo-instructions 19389 that hold debugging information for variable tracking at 19390 assignments (see '-fvar-tracking-assignments' option). They are 19391 the RTL representation of 'GIMPLE_DEBUG' statements (*note 19392 GIMPLE_DEBUG::), with a 'VAR_LOCATION' operand that binds a user 19393 variable tree to an RTL representation of the 'value' in the 19394 corresponding statement. A 'DEBUG_EXPR' in it stands for the value 19395 bound to the corresponding 'DEBUG_EXPR_DECL'. 19396 19397 'GIMPLE_DEBUG_BEGIN_STMT' and 'GIMPLE_DEBUG_INLINE_ENTRY' are 19398 expanded to RTL as a 'DEBUG_INSN' with a 'DEBUG_MARKER' 'PATTERN'; 19399 the difference is the RTL mode: the former's 'DEBUG_MARKER' is 19400 'VOIDmode', whereas the latter is 'BLKmode'; information about the 19401 inlined function can be taken from the lexical block encoded in the 19402 'INSN_LOCATION'. These 'DEBUG_INSN's, that do not carry 19403 'VAR_LOCATION' information, just 'DEBUG_MARKER's, can be detected 19404 by testing 'DEBUG_MARKER_INSN_P', whereas those that do can be 19405 recognized as 'DEBUG_BIND_INSN_P'. 19406 19407 Throughout optimization passes, 'DEBUG_INSN's are not reordered 19408 with respect to each other, particularly during scheduling. 19409 Binding information is kept in pseudo-instruction form, so that, 19410 unlike notes, it gets the same treatment and adjustments that 19411 regular instructions would. It is the variable tracking pass that 19412 turns these pseudo-instructions into 'NOTE_INSN_VAR_LOCATION', 19413 'NOTE_INSN_BEGIN_STMT' and 'NOTE_INSN_INLINE_ENTRY' notes, 19414 analyzing control flow, value equivalences and changes to registers 19415 and memory referenced in value expressions, propagating the values 19416 of debug temporaries and determining expressions that can be used 19417 to compute the value of each user variable at as many points 19418 (ranges, actually) in the program as possible. 19419 19420 Unlike 'NOTE_INSN_VAR_LOCATION', the value expression in an 19421 'INSN_VAR_LOCATION' denotes a value at that specific point in the 19422 program, rather than an expression that can be evaluated at any 19423 later point before an overriding 'VAR_LOCATION' is encountered. 19424 E.g., if a user variable is bound to a 'REG' and then a subsequent 19425 insn modifies the 'REG', the note location would keep mapping the 19426 user variable to the register across the insn, whereas the insn 19427 location would keep the variable bound to the value, so that the 19428 variable tracking pass would emit another location note for the 19429 variable at the point in which the register is modified. 19430 19431 The machine mode of an insn is normally 'VOIDmode', but some phases use 19432the mode for various purposes. 19433 19434 The common subexpression elimination pass sets the mode of an insn to 19435'QImode' when it is the first insn in a block that has already been 19436processed. 19437 19438 The second Haifa scheduling pass, for targets that can multiple issue, 19439sets the mode of an insn to 'TImode' when it is believed that the 19440instruction begins an issue group. That is, when the instruction cannot 19441issue simultaneously with the previous. This may be relied on by later 19442passes, in particular machine-dependent reorg. 19443 19444 Here is a table of the extra fields of 'insn', 'jump_insn' and 19445'call_insn' insns: 19446 19447'PATTERN (I)' 19448 An expression for the side effect performed by this insn. This 19449 must be one of the following codes: 'set', 'call', 'use', 19450 'clobber', 'return', 'simple_return', 'asm_input', 'asm_output', 19451 'addr_vec', 'addr_diff_vec', 'trap_if', 'unspec', 19452 'unspec_volatile', 'parallel', 'cond_exec', or 'sequence'. If it 19453 is a 'parallel', each element of the 'parallel' must be one these 19454 codes, except that 'parallel' expressions cannot be nested and 19455 'addr_vec' and 'addr_diff_vec' are not permitted inside a 19456 'parallel' expression. 19457 19458'INSN_CODE (I)' 19459 An integer that says which pattern in the machine description 19460 matches this insn, or -1 if the matching has not yet been 19461 attempted. 19462 19463 Such matching is never attempted and this field remains -1 on an 19464 insn whose pattern consists of a single 'use', 'clobber', 19465 'asm_input', 'addr_vec' or 'addr_diff_vec' expression. 19466 19467 Matching is also never attempted on insns that result from an 'asm' 19468 statement. These contain at least one 'asm_operands' expression. 19469 The function 'asm_noperands' returns a non-negative value for such 19470 insns. 19471 19472 In the debugging output, this field is printed as a number followed 19473 by a symbolic representation that locates the pattern in the 'md' 19474 file as some small positive or negative offset from a named 19475 pattern. 19476 19477'LOG_LINKS (I)' 19478 A list (chain of 'insn_list' expressions) giving information about 19479 dependencies between instructions within a basic block. Neither a 19480 jump nor a label may come between the related insns. These are 19481 only used by the schedulers and by combine. This is a deprecated 19482 data structure. Def-use and use-def chains are now preferred. 19483 19484'REG_NOTES (I)' 19485 A list (chain of 'expr_list', 'insn_list' and 'int_list' 19486 expressions) giving miscellaneous information about the insn. It 19487 is often information pertaining to the registers used in this insn. 19488 19489 The 'LOG_LINKS' field of an insn is a chain of 'insn_list' expressions. 19490Each of these has two operands: the first is an insn, and the second is 19491another 'insn_list' expression (the next one in the chain). The last 19492'insn_list' in the chain has a null pointer as second operand. The 19493significant thing about the chain is which insns appear in it (as first 19494operands of 'insn_list' expressions). Their order is not significant. 19495 19496 This list is originally set up by the flow analysis pass; it is a null 19497pointer until then. Flow only adds links for those data dependencies 19498which can be used for instruction combination. For each insn, the flow 19499analysis pass adds a link to insns which store into registers values 19500that are used for the first time in this insn. 19501 19502 The 'REG_NOTES' field of an insn is a chain similar to the 'LOG_LINKS' 19503field but it includes 'expr_list' and 'int_list' expressions in addition 19504to 'insn_list' expressions. There are several kinds of register notes, 19505which are distinguished by the machine mode, which in a register note is 19506really understood as being an 'enum reg_note'. The first operand OP of 19507the note is data whose meaning depends on the kind of note. 19508 19509 The macro 'REG_NOTE_KIND (X)' returns the kind of register note. Its 19510counterpart, the macro 'PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 19511register note type of X to be NEWKIND. 19512 19513 Register notes are of three classes: They may say something about an 19514input to an insn, they may say something about an output of an insn, or 19515they may create a linkage between two insns. There are also a set of 19516values that are only used in 'LOG_LINKS'. 19517 19518 These register notes annotate inputs to an insn: 19519 19520'REG_DEAD' 19521 The value in OP dies in this insn; that is to say, altering the 19522 value immediately after this insn would not affect the future 19523 behavior of the program. 19524 19525 It does not follow that the register OP has no useful value after 19526 this insn since OP is not necessarily modified by this insn. 19527 Rather, no subsequent instruction uses the contents of OP. 19528 19529'REG_UNUSED' 19530 The register OP being set by this insn will not be used in a 19531 subsequent insn. This differs from a 'REG_DEAD' note, which 19532 indicates that the value in an input will not be used subsequently. 19533 These two notes are independent; both may be present for the same 19534 register. 19535 19536'REG_INC' 19537 The register OP is incremented (or decremented; at this level there 19538 is no distinction) by an embedded side effect inside this insn. 19539 This means it appears in a 'post_inc', 'pre_inc', 'post_dec' or 19540 'pre_dec' expression. 19541 19542'REG_NONNEG' 19543 The register OP is known to have a nonnegative value when this insn 19544 is reached. This is used by special looping instructions that 19545 terminate when the register goes negative. 19546 19547 The 'REG_NONNEG' note is added only to 'doloop_end' insns, if its 19548 pattern uses a 'ge' condition. 19549 19550'REG_LABEL_OPERAND' 19551 This insn uses OP, a 'code_label' or a 'note' of type 19552 'NOTE_INSN_DELETED_LABEL', but is not a 'jump_insn', or it is a 19553 'jump_insn' that refers to the operand as an ordinary operand. The 19554 label may still eventually be a jump target, but if so in an 19555 indirect jump in a subsequent insn. The presence of this note 19556 allows jump optimization to be aware that OP is, in fact, being 19557 used, and flow optimization to build an accurate flow graph. 19558 19559'REG_LABEL_TARGET' 19560 This insn is a 'jump_insn' but not an 'addr_vec' or 19561 'addr_diff_vec'. It uses OP, a 'code_label' as a direct or 19562 indirect jump target. Its purpose is similar to that of 19563 'REG_LABEL_OPERAND'. This note is only present if the insn has 19564 multiple targets; the last label in the insn (in the highest 19565 numbered insn-field) goes into the 'JUMP_LABEL' field and does not 19566 have a 'REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns. 19567 19568'REG_SETJMP' 19569 Appears attached to each 'CALL_INSN' to 'setjmp' or a related 19570 function. 19571 19572 The following notes describe attributes of outputs of an insn: 19573 19574'REG_EQUIV' 19575'REG_EQUAL' 19576 This note is only valid on an insn that sets only one register and 19577 indicates that that register will be equal to OP at run time; the 19578 scope of this equivalence differs between the two types of notes. 19579 The value which the insn explicitly copies into the register may 19580 look different from OP, but they will be equal at run time. If the 19581 output of the single 'set' is a 'strict_low_part' or 'zero_extract' 19582 expression, the note refers to the register that is contained in 19583 its first operand. 19584 19585 For 'REG_EQUIV', the register is equivalent to OP throughout the 19586 entire function, and could validly be replaced in all its 19587 occurrences by OP. ("Validly" here refers to the data flow of the 19588 program; simple replacement may make some insns invalid.) For 19589 example, when a constant is loaded into a register that is never 19590 assigned any other value, this kind of note is used. 19591 19592 When a parameter is copied into a pseudo-register at entry to a 19593 function, a note of this kind records that the register is 19594 equivalent to the stack slot where the parameter was passed. 19595 Although in this case the register may be set by other insns, it is 19596 still valid to replace the register by the stack slot throughout 19597 the function. 19598 19599 A 'REG_EQUIV' note is also used on an instruction which copies a 19600 register parameter into a pseudo-register at entry to a function, 19601 if there is a stack slot where that parameter could be stored. 19602 Although other insns may set the pseudo-register, it is valid for 19603 the compiler to replace the pseudo-register by stack slot 19604 throughout the function, provided the compiler ensures that the 19605 stack slot is properly initialized by making the replacement in the 19606 initial copy instruction as well. This is used on machines for 19607 which the calling convention allocates stack space for register 19608 parameters. See 'REG_PARM_STACK_SPACE' in *note Stack Arguments::. 19609 19610 In the case of 'REG_EQUAL', the register that is set by this insn 19611 will be equal to OP at run time at the end of this insn but not 19612 necessarily elsewhere in the function. In this case, OP is 19613 typically an arithmetic expression. For example, when a sequence 19614 of insns such as a library call is used to perform an arithmetic 19615 operation, this kind of note is attached to the insn that produces 19616 or copies the final value. 19617 19618 These two notes are used in different ways by the compiler passes. 19619 'REG_EQUAL' is used by passes prior to register allocation (such as 19620 common subexpression elimination and loop optimization) to tell 19621 them how to think of that value. 'REG_EQUIV' notes are used by 19622 register allocation to indicate that there is an available 19623 substitute expression (either a constant or a 'mem' expression for 19624 the location of a parameter on the stack) that may be used in place 19625 of a register if insufficient registers are available. 19626 19627 Except for stack homes for parameters, which are indicated by a 19628 'REG_EQUIV' note and are not useful to the early optimization 19629 passes and pseudo registers that are equivalent to a memory 19630 location throughout their entire life, which is not detected until 19631 later in the compilation, all equivalences are initially indicated 19632 by an attached 'REG_EQUAL' note. In the early stages of register 19633 allocation, a 'REG_EQUAL' note is changed into a 'REG_EQUIV' note 19634 if OP is a constant and the insn represents the only set of its 19635 destination register. 19636 19637 Thus, compiler passes prior to register allocation need only check 19638 for 'REG_EQUAL' notes and passes subsequent to register allocation 19639 need only check for 'REG_EQUIV' notes. 19640 19641 These notes describe linkages between insns. They occur in pairs: one 19642insn has one of a pair of notes that points to a second insn, which has 19643the inverse note pointing back to the first insn. 19644 19645'REG_CC_SETTER' 19646'REG_CC_USER' 19647 On machines that use 'cc0', the insns which set and use 'cc0' set 19648 and use 'cc0' are adjacent. However, when branch delay slot 19649 filling is done, this may no longer be true. In this case a 19650 'REG_CC_USER' note will be placed on the insn setting 'cc0' to 19651 point to the insn using 'cc0' and a 'REG_CC_SETTER' note will be 19652 placed on the insn using 'cc0' to point to the insn setting 'cc0'. 19653 19654 These values are only used in the 'LOG_LINKS' field, and indicate the 19655type of dependency that each link represents. Links which indicate a 19656data dependence (a read after write dependence) do not use any code, 19657they simply have mode 'VOIDmode', and are printed without any 19658descriptive text. 19659 19660'REG_DEP_TRUE' 19661 This indicates a true dependence (a read after write dependence). 19662 19663'REG_DEP_OUTPUT' 19664 This indicates an output dependence (a write after write 19665 dependence). 19666 19667'REG_DEP_ANTI' 19668 This indicates an anti dependence (a write after read dependence). 19669 19670 These notes describe information gathered from gcov profile data. They 19671are stored in the 'REG_NOTES' field of an insn. 19672 19673'REG_BR_PROB' 19674 This is used to specify the ratio of branches to non-branches of a 19675 branch insn according to the profile data. The note is represented 19676 as an 'int_list' expression whose integer value is an encoding of 19677 'profile_probability' type. 'profile_probability' provide member 19678 function 'from_reg_br_prob_note' and 'to_reg_br_prob_note' to 19679 extract and store the probability into the RTL encoding. 19680 19681'REG_BR_PRED' 19682 These notes are found in JUMP insns after delayed branch scheduling 19683 has taken place. They indicate both the direction and the 19684 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 19685 values. 19686 19687'REG_FRAME_RELATED_EXPR' 19688 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 19689 expression is used in place of the actual insn pattern. This is 19690 done in cases where the pattern is either complex or misleading. 19691 19692 The note 'REG_CALL_NOCF_CHECK' is used in conjunction with the 19693'-fcf-protection=branch' option. The note is set if a 'nocf_check' 19694attribute is specified for a function type or a pointer to function 19695type. The note is stored in the 'REG_NOTES' field of an insn. 19696 19697'REG_CALL_NOCF_CHECK' 19698 Users have control through the 'nocf_check' attribute to identify 19699 which calls to a function should be skipped from control-flow 19700 instrumentation when the option '-fcf-protection=branch' is 19701 specified. The compiler puts a 'REG_CALL_NOCF_CHECK' note on each 19702 'CALL_INSN' instruction that has a function type marked with a 19703 'nocf_check' attribute. 19704 19705 For convenience, the machine mode in an 'insn_list' or 'expr_list' is 19706printed using these symbolic codes in debugging dumps. 19707 19708 The only difference between the expression codes 'insn_list' and 19709'expr_list' is that the first operand of an 'insn_list' is assumed to be 19710an insn and is printed in debugging dumps as the insn's unique id; the 19711first operand of an 'expr_list' is printed in the ordinary way as an 19712expression. 19713 19714 19715File: gccint.info, Node: Calls, Next: RTL SSA, Prev: Insns, Up: RTL 19716 1971714.20 RTL Representation of Function-Call Insns 19718=============================================== 19719 19720Insns that call subroutines have the RTL expression code 'call_insn'. 19721These insns must satisfy special rules, and their bodies must use a 19722special RTL expression code, 'call'. 19723 19724 A 'call' expression has two operands, as follows: 19725 19726 (call (mem:FM ADDR) NBYTES) 19727 19728Here NBYTES is an operand that represents the number of bytes of 19729argument data being passed to the subroutine, FM is a machine mode 19730(which must equal as the definition of the 'FUNCTION_MODE' macro in the 19731machine description) and ADDR represents the address of the subroutine. 19732 19733 For a subroutine that returns no value, the 'call' expression as shown 19734above is the entire body of the insn, except that the insn might also 19735contain 'use' or 'clobber' expressions. 19736 19737 For a subroutine that returns a value whose mode is not 'BLKmode', the 19738value is returned in a hard register. If this register's number is R, 19739then the body of the call insn looks like this: 19740 19741 (set (reg:M R) 19742 (call (mem:FM ADDR) NBYTES)) 19743 19744This RTL expression makes it clear (to the optimizer passes) that the 19745appropriate register receives a useful value in this insn. 19746 19747 When a subroutine returns a 'BLKmode' value, it is handled by passing 19748to the subroutine the address of a place to store the value. So the 19749call insn itself does not "return" any value, and it has the same RTL 19750form as a call that returns nothing. 19751 19752 On some machines, the call instruction itself clobbers some register, 19753for example to contain the return address. 'call_insn' insns on these 19754machines should have a body which is a 'parallel' that contains both the 19755'call' expression and 'clobber' expressions that indicate which 19756registers are destroyed. Similarly, if the call instruction requires 19757some register other than the stack pointer that is not explicitly 19758mentioned in its RTL, a 'use' subexpression should mention that 19759register. 19760 19761 Functions that are called are assumed to modify all registers listed in 19762the configuration macro 'CALL_USED_REGISTERS' (*note Register Basics::) 19763and, with the exception of 'const' functions and library calls, to 19764modify all of memory. 19765 19766 Insns containing just 'use' expressions directly precede the 19767'call_insn' insn to indicate which registers contain inputs to the 19768function. Similarly, if registers other than those in 19769'CALL_USED_REGISTERS' are clobbered by the called function, insns 19770containing a single 'clobber' follow immediately after the call to 19771indicate which registers. 19772 19773 19774File: gccint.info, Node: RTL SSA, Next: Sharing, Prev: Calls, Up: RTL 19775 1977614.21 On-the-Side SSA Form for RTL 19777================================== 19778 19779The patterns of an individual RTL instruction describe which registers 19780are inputs to that instruction and which registers are outputs from that 19781instruction. However, it is often useful to know where the definition 19782of a register input comes from and where the result of a register output 19783is used. One way of obtaining this information is to use the RTL SSA 19784form, which provides a Static Single Assignment representation of the 19785RTL instructions. 19786 19787 The RTL SSA code is located in the 'rtl-ssa' subdirectory of the GCC 19788source tree. This section only gives a brief overview of it; please see 19789the comments in the source code for more details. 19790 19791* Menu: 19792 19793* Using RTL SSA:: What a pass needs to do to use the RTL SSA form 19794* RTL SSA Instructions:: How instructions are represented and organized 19795* RTL SSA Basic Blocks:: How instructions are grouped into blocks 19796* RTL SSA Resources:: How registers and memory are represented 19797* RTL SSA Accesses:: How register and memory accesses are represented 19798* RTL SSA Phi Nodes:: How multiple sources are combined into one 19799* RTL SSA Access Lists:: How accesses are chained together 19800* Changing RTL Instructions:: How to use the RTL SSA framework to change insns 19801 19802 19803File: gccint.info, Node: Using RTL SSA, Next: RTL SSA Instructions, Up: RTL SSA 19804 1980514.21.1 Using RTL SSA in a pass 19806------------------------------- 19807 19808A pass that wants to use the RTL SSA form should start with the 19809following: 19810 19811 #define INCLUDE_ALGORITHM 19812 #define INCLUDE_FUNCTIONAL 19813 #include "config.h" 19814 #include "system.h" 19815 #include "coretypes.h" 19816 #include "backend.h" 19817 #include "rtl.h" 19818 #include "df.h" 19819 #include "rtl-ssa.h" 19820 19821 All the RTL SSA code is contained in the 'rtl_ssa' namespace, so most 19822passes will then want to do: 19823 19824 using namespace rtl_ssa; 19825 19826 However, this is purely a matter of taste, and the examples in the rest 19827of this section do not require it. 19828 19829 The RTL SSA represention is an optional on-the-side feature that 19830applies on top of the normal RTL instructions. It is currently local to 19831individual RTL passes and is not maintained across passes. 19832 19833 However, in order to allow the RTL SSA information to be preserved 19834across passes in future, 'crtl->ssa' points to the current function's 19835SSA form (if any). Passes that want to use the RTL SSA form should 19836first do: 19837 19838 crtl->ssa = new rtl_ssa::function_info (FN); 19839 19840 where FN is the function that the pass is processing. (Passes that are 19841'using namespace rtl_ssa' do not need the 'rtl_ssa::'.) 19842 19843 Once the pass has finished with the SSA form, it should do the 19844following: 19845 19846 free_dominance_info (CDI_DOMINATORS); 19847 if (crtl->ssa->perform_pending_updates ()) 19848 cleanup_cfg (0); 19849 19850 delete crtl->ssa; 19851 crtl->ssa = nullptr; 19852 19853 The 'free_dominance_info' call is necessary because dominance 19854information is not currently maintained between RTL passes. The next 19855two lines commit any changes to the RTL instructions that were queued 19856for later; see the comment above the declaration of 19857'perform_pending_updates' for details. The final two lines discard the 19858RTL SSA form and free the associated memory. 19859 19860 19861File: gccint.info, Node: RTL SSA Instructions, Next: RTL SSA Basic Blocks, Prev: Using RTL SSA, Up: RTL SSA 19862 1986314.21.2 RTL SSA Instructions 19864---------------------------- 19865 19866RTL SSA instructions are represented by an 'rtl_ssa::insn_info'. These 19867instructions are chained together in a single list that follows a 19868reverse postorder (RPO) traversal of the function. This means that if 19869any path through the function can execute an instruction I1 and then 19870later execute an instruction I2 for the first time, I1 appears before I2 19871in the list(1). 19872 19873 Two RTL SSA instructions can be compared to find which instruction 19874occurs earlier than the other in the RPO. One way to do this is to use 19875the C++ comparison operators, such as: 19876 19877 *INSN1 < *INSN2 19878 19879 Another way is to use the 'compare_with' function: 19880 19881 INSN1->compare_with (INSN2) 19882 19883 This expression is greater than zero if INSN1 comes after INSN2 in the 19884RPO, less than zero if INSN1 comes before INSN2 in the RPO, or zero if 19885INSN1 and INSN2 are the same. This order is maintained even if 19886instructions are added to the function or moved around. 19887 19888 The main purpose of 'rtl_ssa::insn_info' is to hold SSA information 19889about an instruction. However, it also caches certain properties of the 19890instruction, such as whether it is an inline assembly instruction, 19891whether it has volatile accesses, and so on. 19892 19893 ---------- Footnotes ---------- 19894 19895 (1) Note that this order is different from the order of the 19896underlying RTL instructions, which follow machine code order instead. 19897 19898 19899File: gccint.info, Node: RTL SSA Basic Blocks, Next: RTL SSA Resources, Prev: RTL SSA Instructions, Up: RTL SSA 19900 1990114.21.3 RTL SSA Basic Blocks 19902---------------------------- 19903 19904RTL SSA instructions (*note RTL SSA Instructions::) are organized into 19905basic blocks, with each block being represented by an 'rtl_ssa:bb_info'. 19906There is a one-to-one mapping between these 'rtl_ssa:bb_info' structures 19907and the underlying CFG 'basic_block' structures (*note Basic Blocks::). 19908 19909 If a CFG basic block BB contains an RTL instruction INSN, the RTL SSA 19910represenation of BB also contains an RTL SSA representation of INSN(1). 19911Within RTL SSA, these instructions are referred to as "real" 19912instructions. These real instructions fall into two groups: debug 19913instructions and nondebug instructions. Only nondebug instructions 19914should affect code generation decisions. 19915 19916 In addition, each RTL SSA basic block has two "artificial" 19917instructions: a "head" instruction that comes before all the real 19918instructions and an "end" instruction that comes after all real 19919instructions. These instructions exist to represent things that are 19920conceptually defined or used at the start and end of a basic block. The 19921instructions always exist, even if they do not currently do anything. 19922 19923 Like instructions, these blocks are chained together in a reverse 19924postorder. This list includes the entry block (which always comes 19925first) and the exit block (which always comes last). 19926 19927 RTL SSA basic blocks are chained together into "extended basic blocks" 19928(EBBs), represented by an 'rtl_ssa::ebb_info'. Extended basic blocks 19929contain one or more basic blocks. They have the property that if a 19930block BBY comes immediately after a block BBX in an EBB, then BBY can 19931only be reached by BBX; in other words, BBX is the sole predecessor of 19932BBY. 19933 19934 Each extended basic block starts with an artificial "phi node" 19935instruction. This instruction defines all phi nodes for the EBB (*note 19936RTL SSA Phi Nodes::). (Individual blocks in an EBB do not need phi 19937nodes because their live values can only come from one source.) 19938 19939 The contents of a function are therefore represented using a four-level 19940hierarchy: 19941 19942 * functions ('rtl_ssa::function_info'), which contain ... 19943 19944 * extended basic blocks ('rtl_ssa::ebb_info'), which contain ... 19945 19946 * basic blocks ('rtl_ssa::bb_info'), which contain ... 19947 19948 * instructions ('rtl_ssa::insn_info') 19949 19950 In dumps, a basic block is identified as 'bbN', where N is the index of 19951the associated CFG 'basic_block' structure. An EBB is in turn 19952identified by the index of its first block. For example, an EBB that 19953contains 'bb10', 'bb5', 'bb6' and 'bb9' is identified as EBB10. 19954 19955 ---------- Footnotes ---------- 19956 19957 (1) Note that this excludes non-instruction things like 'note's and 19958'barrier's that also appear in the chain of RTL instructions. 19959 19960 19961File: gccint.info, Node: RTL SSA Resources, Next: RTL SSA Accesses, Prev: RTL SSA Basic Blocks, Up: RTL SSA 19962 1996314.21.4 RTL SSA Resources 19964------------------------- 19965 19966The RTL SSA form tracks two types of "resource": registers and memory. 19967Each hard and pseudo register is a separate resource. Memory is a 19968single unified resource, like it is in GIMPLE (*note GIMPLE::). 19969 19970 Each resource has a unique identifier. The unique identifier for a 19971register is simply its register number. The unique identifier for 19972memory is a special register number called 'MEM_REGNO'. 19973 19974 Since resource numbers so closely match register numbers, it is 19975sometimes convenient to refer to them simply as register numbers, or 19976"regnos" for short. However, the RTL SSA form also provides an 19977abstraction of resources in the form of 'rtl_ssa::resource_info'. This 19978is a lightweight class that records both the regno of a resource and the 19979'machine_mode' that the resource has (*note Machine Modes::). It has 19980functions for testing whether a resource is a register or memory. In 19981principle it could be extended to other kinds of resource in future. 19982 19983 19984File: gccint.info, Node: RTL SSA Accesses, Next: RTL SSA Phi Nodes, Prev: RTL SSA Resources, Up: RTL SSA 19985 1998614.21.5 RTL SSA Register and Memory Accesses 19987-------------------------------------------- 19988 19989In the RTL SSA form, most reads or writes of a resource are represented 19990as a 'rtl_ssa::access_info'(1). These 'rtl_ssa::access_info's are 19991organized into the following class hierarchy: 19992 19993 rtl_ssa::access_info 19994 | 19995 +-- rtl_ssa::use_info 19996 | 19997 +-- rtl_ssa::def_info 19998 | 19999 +-- rtl_ssa::clobber_info 20000 | 20001 +-- rtl_ssa::set_info 20002 | 20003 +-- rtl_ssa::phi_info 20004 20005 A 'rtl_ssa::use_info' represents a read or use of a resource and a 20006'rtl_ssa::def_info' represents a write or definition of a resource. As 20007in the main RTL representation, there are two basic types of definition: 20008clobbers and sets. The difference is that a clobber leaves the register 20009with an unspecified value that cannot be used or relied on by later 20010instructions, while a set leaves the register with a known value that 20011later instructions could use if they wanted to. A 20012'rtl_ssa::clobber_info' represents a clobber and a 'rtl_ssa::set_info' 20013represent a set. 20014 20015 Each 'rtl_ssa::use_info' records which single 'rtl_ssa::set_info' 20016provides the value of the resource; this is null if the resource is 20017completely undefined at the point of use. Each 'rtl_ssa::set_info' in 20018turn records all the 'rtl_ssa::use_info's that use its value. 20019 20020 If a value of a resource can come from multiple sources, a 20021'rtl_ssa::phi_info' brings those multiple sources together into a single 20022definition (*note RTL SSA Phi Nodes::). 20023 20024 ---------- Footnotes ---------- 20025 20026 (1) The exceptions are call clobbers, which are generally represented 20027separately. See the comment above 'rtl_ssa::insn_info' for details. 20028 20029 20030File: gccint.info, Node: RTL SSA Phi Nodes, Next: RTL SSA Access Lists, Prev: RTL SSA Accesses, Up: RTL SSA 20031 2003214.21.6 RTL SSA Phi Nodes 20033------------------------- 20034 20035If a resource is live on entry to an extended basic block and if the 20036resource's value can come from multiple sources, the extended basic 20037block has a "phi node" that collects together these multiple sources. 20038The phi node conceptually has one input for each incoming edge of the 20039extended basic block, with the input specifying the value of the 20040resource on that edge. For example, suppose a function contains the 20041following RTL: 20042 20043 ;; Basic block bb3 20044 ... 20045 (set (reg:SI R1) (const_int 0)) ;; A 20046 (set (pc) (label_ref bb5)) 20047 20048 ;; Basic block bb4 20049 ... 20050 (set (reg:SI R1) (const_int 1)) ;; B 20051 ;; Fall through 20052 20053 ;; Basic block bb5 20054 ;; preds: bb3, bb4 20055 ;; live in: R1 ... 20056 (code_label bb5) 20057 ... 20058 (set (reg:SI R2) 20059 (plus:SI (reg:SI R1) ...)) ;; C 20060 20061 The value of R1 on entry to block 5 can come from either A or B. The 20062extended basic block that contains block 5 would therefore have a phi 20063node with two inputs: the first input would have the value of R1 defined 20064by A and the second input would have the value of R1 defined by B. This 20065phi node would then provide the value of R1 for C (assuming that R1 does 20066not change again between the start of block 5 and C). 20067 20068 Since RTL is not a "native" SSA representation, these phi nodes simply 20069collect together definitions that already exist. Each input to a phi 20070node for a resource R is itself a definition of resource R (or is null 20071if the resource is completely undefined for a particular incoming edge). 20072This is in contrast to a native SSA representation like GIMPLE, where 20073the phi inputs can be arbitrary expressions. As a result, RTL SSA phi 20074nodes never involve "hidden" moves: all moves are instead explicit. 20075 20076 Phi nodes are represented as a 'rtl_ssa::phi_node'. Each input to a 20077phi node is represented as an 'rtl_ssa::use_info'. 20078 20079 20080File: gccint.info, Node: RTL SSA Access Lists, Next: Changing RTL Instructions, Prev: RTL SSA Phi Nodes, Up: RTL SSA 20081 2008214.21.7 RTL SSA Access Lists 20083---------------------------- 20084 20085All the definitions of a resource are chained together in reverse 20086postorder. In general, this list can contain an arbitrary mix of both 20087sets ('rtl_ssa::set_info') and clobbers ('rtl_ssa::clobber_info'). 20088However, it is often useful to skip over all intervening clobbers of a 20089resource in order to find the next set. The list is constructed in such 20090a way that this can be done in amortized constant time. 20091 20092 All uses ('rtl_ssa::use_info') of a given set are also chained together 20093into a list. This list of uses is divided into three parts: 20094 20095 1. uses by "real" nondebug instructions (*note real RTL SSA insns::) 20096 20097 2. uses by real debug instructions 20098 20099 3. uses by phi nodes (*note RTL SSA Phi Nodes::) 20100 20101 The first and second parts individually follow reverse postorder. The 20102third part has no particular order. 20103 20104 The last use by a real nondebug instruction always comes earlier in the 20105reverse postorder than the next definition of the resource (if any). 20106This means that the accesses follow a linear sequence of the form: 20107 20108 * first definition of resource R 20109 20110 * first use by a real nondebug instruction of the first 20111 definition of resource R 20112 20113 * ... 20114 20115 * last use by a real nondebug instruction of the first 20116 definition of resource R 20117 20118 * second definition of resource R 20119 20120 * first use by a real nondebug instruction of the second 20121 definition of resource R 20122 20123 * ... 20124 20125 * last use by a real nondebug instruction of the second 20126 definition of resource R 20127 20128 * ... 20129 20130 * last definition of resource R 20131 20132 * first use by a real nondebug instruction of the last 20133 definition of resource R 20134 20135 * ... 20136 20137 * last use by a real nondebug instruction of the last definition 20138 of resource R 20139 20140 (Note that clobbers never have uses; only sets do.) 20141 20142 This linear view is easy to achieve when there is only a single 20143definition of a resource, which is commonly true for pseudo registers. 20144However, things are more complex if code has a structure like the 20145following: 20146 20147 // ebb2, bb2 20148 R = VA; // A 20149 if (...) 20150 { 20151 // ebb2, bb3 20152 use1 (R); // B 20153 ... 20154 R = VC; // C 20155 } 20156 else 20157 { 20158 // ebb4, bb4 20159 use2 (R); // D 20160 } 20161 20162 The list of accesses would begin as follows: 20163 20164 * definition of R by A 20165 20166 * use of A's definition of R by B 20167 20168 * definition of R by C 20169 20170 The next access to R is in D, but the value of R that D uses comes from 20171A rather than C. 20172 20173 This is resolved by adding a phi node for 'ebb4'. All inputs to this 20174phi node have the same value, which in the example above is A's 20175definition of R. In other circumstances, it would not be necessary to 20176create a phi node when all inputs are equal, so these phi nodes are 20177referred to as "degenerate" phi nodes. 20178 20179 The full list of accesses to R is therefore: 20180 20181 * definition of R by A 20182 20183 * use of A's definition of R by B 20184 20185 * definition of R by C 20186 20187 * definition of R by ebb4's phi instruction, with the input coming 20188 from A 20189 20190 * use of the ebb4's R phi definition of R by B 20191 20192 Note that A's definition is also used by ebb4's phi node, but this use 20193belongs to the third part of the use list described above and so does 20194not form part of the linear sequence. 20195 20196 It is possible to "look through" any degenerate phi to the ultimate 20197definition using the function 'look_through_degenerate_phi'. Note that 20198the input to a degenerate phi is never itself provided by a degenerate 20199phi. 20200 20201 At present, the SSA form takes this principle one step further and 20202guarantees that, for any given resource RES, one of the following is 20203true: 20204 20205 * The resource has a single definition DEF, which is not a phi node. 20206 Excluding uses of undefined registers, all uses of RES by real 20207 nondebug instructions use the value provided by DEF. 20208 20209 * Excluding uses of undefined registers, all uses of RES use values 20210 provided by definitions that occur earlier in the same extended 20211 basic block. These definitions might come from phi nodes or from 20212 real instructions. 20213 20214 20215File: gccint.info, Node: Changing RTL Instructions, Prev: RTL SSA Access Lists, Up: RTL SSA 20216 2021714.21.8 Using the RTL SSA framework to change instructions 20218---------------------------------------------------------- 20219 20220There are various routines that help to change a single RTL instruction 20221or a group of RTL instructions while keeping the RTL SSA form 20222up-to-date. This section first describes the process for changing a 20223single instruction, then goes on to describe the differences when 20224changing multiple instructions. 20225 20226* Menu: 20227 20228* Changing One RTL SSA Instruction:: 20229* Changing Multiple RTL SSA Instructions:: 20230 20231 20232File: gccint.info, Node: Changing One RTL SSA Instruction, Next: Changing Multiple RTL SSA Instructions, Up: Changing RTL Instructions 20233 2023414.21.8.1 Changing One RTL SSA Instruction 20235.......................................... 20236 20237Before making a change, passes should first use a statement like the 20238following: 20239 20240 auto attempt = crtl->ssa->new_change_attempt (); 20241 20242 Here, 'attempt' is an RAII object that should remain in scope for the 20243entire change attempt. It automatically frees temporary memory related 20244to the changes when it goes out of scope. 20245 20246 Next, the pass should create an 'rtl_ssa::insn_change' object for the 20247instruction that it wants to change. This object specifies several 20248things: 20249 20250 * what the instruction's new list of uses should be ('new_uses'). By 20251 default this is the same as the instruction's current list of uses. 20252 20253 * what the instruction's new list of definitions should be 20254 ('new_defs'). By default this is the same as the instruction's 20255 current list of definitions. 20256 20257 * where the instruction should be located ('move_range'). This is a 20258 range of instructions after which the instruction could be placed, 20259 represented as an 'rtl_ssa::insn_range'. By default the 20260 instruction must remain at its current position. 20261 20262 If a pass was attempting to change all these properties of an 20263instruction 'insn', it might do something like this: 20264 20265 rtl_ssa::insn_change change (insn); 20266 change.new_defs = ...; 20267 change.new_uses = ...; 20268 change.move_range = ...; 20269 20270 This 'rtl_ssa::insn_change' only describes something that the pass 20271_might_ do; at this stage, nothing has actually changed. 20272 20273 As noted above, the default 'move_range' requires the instruction to 20274remain where it is. At the other extreme, it is possible to allow the 20275instruction to move anywhere within its extended basic block, provided 20276that all the new uses and definitions can be performed at the new 20277location. The way to do this is: 20278 20279 change.move_range = insn->ebb ()->insn_range (); 20280 20281 In either case, the next step is to make sure that move range is 20282consistent with the new uses and definitions. The way to do this is: 20283 20284 if (!rtl_ssa::restrict_movement (change)) 20285 return false; 20286 20287 This function tries to limit 'move_range' to a range of instructions at 20288which 'new_uses' and 'new_defs' can be correctly performed. It returns 20289true on success or false if no suitable location exists. 20290 20291 The pass should also tentatively change the pattern of the instruction 20292to whatever form the pass wants the instruction to have. This should 20293use the facilities provided by 'recog.c'. For example: 20294 20295 rtl_insn *rtl = insn->rtl (); 20296 insn_change_watermark watermark; 20297 validate_change (rtl, &PATTERN (rtl), new_pat, 1); 20298 20299 will tentatively replace 'insn''s pattern with 'new_pat'. 20300 20301 These changes and the construction of the 'rtl_ssa::insn_change' can 20302happen in either order or be interleaved. 20303 20304 After the tentative changes to the instruction are complete, the pass 20305should check whether the new pattern matches a target instruction or 20306satisfies the requirements of an inline asm: 20307 20308 if (!rtl_ssa::recog (change)) 20309 return false; 20310 20311 This step might change the instruction pattern further in order to make 20312it match. It might also add new definitions or restrict the range of 20313the move. For example, if the new pattern did not match in its original 20314form, but could be made to match by adding a clobber of the flags 20315register, 'rtl_ssa::recog' will check whether the flags register is free 20316at an appropriate point. If so, it will add a clobber of the flags 20317register to 'new_defs' and restrict 'move_range' to the locations at 20318which the flags register can be safely clobbered. 20319 20320 Even if the proposed new instruction is valid according to 20321'rtl_ssa::recog', the change might not be worthwhile. For example, when 20322optimizing for speed, the new instruction might turn out to be slower 20323than the original one. When optimizing for size, the new instruction 20324might turn out to be bigger than the original one. 20325 20326 Passes should check for this case using 'change_is_worthwhile'. For 20327example: 20328 20329 if (!rtl_ssa::change_is_worthwhile (change)) 20330 return false; 20331 20332 If the change passes this test too then the pass can perform the change 20333using: 20334 20335 confirm_change_group (); 20336 crtl->ssa->change_insn (change); 20337 20338 Putting all this together, the change has the following form: 20339 20340 auto attempt = crtl->ssa->new_change_attempt (); 20341 20342 rtl_ssa::insn_change change (insn); 20343 change.new_defs = ...; 20344 change.new_uses = ...; 20345 change.move_range = ...; 20346 20347 if (!rtl_ssa::restrict_movement (change)) 20348 return false; 20349 20350 insn_change_watermark watermark; 20351 // Use validate_change etc. to change INSN's pattern. 20352 ... 20353 if (!rtl_ssa::recog (change) 20354 || !rtl_ssa::change_is_worthwhile (change)) 20355 return false; 20356 20357 confirm_change_group (); 20358 crtl->ssa->change_insn (change); 20359 20360 20361File: gccint.info, Node: Changing Multiple RTL SSA Instructions, Prev: Changing One RTL SSA Instruction, Up: Changing RTL Instructions 20362 2036314.21.8.2 Changing Multiple RTL SSA Instructions 20364................................................ 20365 20366The process for changing multiple instructions is similar to the process 20367for changing single instructions (*note Changing One RTL SSA 20368Instruction::). The pass should again start the change attempt with: 20369 20370 auto attempt = crtl->ssa->new_change_attempt (); 20371 20372 and keep 'attempt' in scope for the duration of the change attempt. It 20373should then construct an 'rtl_ssa::insn_change' for each change that it 20374wants to make. 20375 20376 After this, it should combine the changes into a sequence of 20377'rtl_ssa::insn_change' pointers. This sequence must be in reverse 20378postorder; the instructions will remain strictly in the order that the 20379sequence specifies. 20380 20381 For example, if a pass is changing exactly two instructions, it might 20382do: 20383 20384 rtl_ssa::insn_change *changes[] = { &change1, change2 }; 20385 20386 where 'change1''s instruction must come before 'change2''s. 20387Alternatively, if the pass is changing a variable number of 20388instructions, it might build up the sequence in a 20389'vec<rtl_ssa::insn_change *>'. 20390 20391 By default, 'rtl_ssa::restrict_movement' assumes that all instructions 20392other than the one passed to it will remain in their current positions 20393and will retain their current uses and definitions. When changing 20394multiple instructions, it is usually more effective to ignore the other 20395instructions that are changing. The sequencing described above ensures 20396that the changing instructions remain in the correct order with respect 20397to each other. The way to do this is: 20398 20399 if (!rtl_ssa::restrict_movement (change, insn_is_changing (changes))) 20400 return false; 20401 20402 Similarly, when 'rtl_ssa::restrict_movement' is detecting whether a 20403register can be clobbered, it by default assumes that all other 20404instructions will remain in their current positions and retain their 20405current form. It is again more effective to ignore changing 20406instructions (which might, for example, no longer need to clobber the 20407flags register). The way to do this is: 20408 20409 if (!rtl_ssa::recog (change, insn_is_changing (changes))) 20410 return false; 20411 20412 When changing multiple instructions, the important question is usually 20413not whether each individual change is worthwhile, but whether the 20414changes as a whole are worthwhile. The way to test this is: 20415 20416 if (!rtl_ssa::changes_are_worthwhile (changes)) 20417 return false; 20418 20419 The process for changing single instructions makes sure that one 20420'rtl_ssa::insn_change' in isolation is valid. But when changing 20421multiple instructions, it is also necessary to test whether the sequence 20422as a whole is valid. For example, it might be impossible to satisfy all 20423of the 'move_range's at once. 20424 20425 Therefore, once the pass has a sequence of changes that are 20426individually correct, it should use: 20427 20428 if (!crtl->ssa->verify_insn_changes (changes)) 20429 return false; 20430 20431 to check whether the sequence as a whole is valid. If all checks pass, 20432the final step is: 20433 20434 confirm_change_group (); 20435 crtl->ssa->change_insns (changes); 20436 20437 Putting all this together, the process for a two-instruction change is: 20438 20439 auto attempt = crtl->ssa->new_change_attempt (); 20440 20441 rtl_ssa::insn_change change (insn1); 20442 change1.new_defs = ...; 20443 change1.new_uses = ...; 20444 change1.move_range = ...; 20445 20446 rtl_ssa::insn_change change (insn2); 20447 change2.new_defs = ...; 20448 change2.new_uses = ...; 20449 change2.move_range = ...; 20450 20451 rtl_ssa::insn_change *changes[] = { &change1, change2 }; 20452 20453 auto is_changing = insn_is_changing (changes); 20454 if (!rtl_ssa::restrict_movement (change1, is_changing) 20455 || !rtl_ssa::restrict_movement (change2, is_changing)) 20456 return false; 20457 20458 insn_change_watermark watermark; 20459 // Use validate_change etc. to change INSN1's and INSN2's patterns. 20460 ... 20461 if (!rtl_ssa::recog (change1, is_changing) 20462 || !rtl_ssa::recog (change2, is_changing) 20463 || !rtl_ssa::changes_are_worthwhile (changes) 20464 || !crtl->ssa->verify_insn_changes (changes)) 20465 return false; 20466 20467 confirm_change_group (); 20468 crtl->ssa->change_insns (changes); 20469 20470 20471File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: RTL SSA, Up: RTL 20472 2047314.22 Structure Sharing Assumptions 20474=================================== 20475 20476The compiler assumes that certain kinds of RTL expressions are unique; 20477there do not exist two distinct objects representing the same value. In 20478other cases, it makes an opposite assumption: that no RTL expression 20479object of a certain kind appears in more than one place in the 20480containing structure. 20481 20482 These assumptions refer to a single function; except for the RTL 20483objects that describe global variables and external functions, and a few 20484standard objects such as small integer constants, no RTL objects are 20485common to two functions. 20486 20487 * Each pseudo-register has only a single 'reg' object to represent 20488 it, and therefore only a single machine mode. 20489 20490 * For any symbolic label, there is only one 'symbol_ref' object 20491 referring to it. 20492 20493 * All 'const_int' expressions with equal values are shared. 20494 20495 * All 'const_poly_int' expressions with equal modes and values are 20496 shared. 20497 20498 * There is only one 'pc' expression. 20499 20500 * There is only one 'cc0' expression. 20501 20502 * There is only one 'const_double' expression with value 0 for each 20503 floating point mode. Likewise for values 1 and 2. 20504 20505 * There is only one 'const_vector' expression with value 0 for each 20506 vector mode, be it an integer or a double constant vector. 20507 20508 * No 'label_ref' or 'scratch' appears in more than one place in the 20509 RTL structure; in other words, it is safe to do a tree-walk of all 20510 the insns in the function and assume that each time a 'label_ref' 20511 or 'scratch' is seen it is distinct from all others that are seen. 20512 20513 * Only one 'mem' object is normally created for each static variable 20514 or stack slot, so these objects are frequently shared in all the 20515 places they appear. However, separate but equal objects for these 20516 variables are occasionally made. 20517 20518 * When a single 'asm' statement has multiple output operands, a 20519 distinct 'asm_operands' expression is made for each output operand. 20520 However, these all share the vector which contains the sequence of 20521 input operands. This sharing is used later on to test whether two 20522 'asm_operands' expressions come from the same statement, so all 20523 optimizations must carefully preserve the sharing if they copy the 20524 vector at all. 20525 20526 * No RTL object appears in more than one place in the RTL structure 20527 except as described above. Many passes of the compiler rely on 20528 this by assuming that they can modify RTL objects in place without 20529 unwanted side-effects on other insns. 20530 20531 * During initial RTL generation, shared structure is freely 20532 introduced. After all the RTL for a function has been generated, 20533 all shared structure is copied by 'unshare_all_rtl' in 20534 'emit-rtl.c', after which the above rules are guaranteed to be 20535 followed. 20536 20537 * During the combiner pass, shared structure within an insn can exist 20538 temporarily. However, the shared structure is copied before the 20539 combiner is finished with the insn. This is done by calling 20540 'copy_rtx_if_shared', which is a subroutine of 'unshare_all_rtl'. 20541 20542 20543File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 20544 2054514.23 Reading RTL 20546================= 20547 20548To read an RTL object from a file, call 'read_rtx'. It takes one 20549argument, a stdio stream, and returns a single RTL object. This routine 20550is defined in 'read-rtl.c'. It is not available in the compiler itself, 20551only the various programs that generate the compiler back end from the 20552machine description. 20553 20554 People frequently have the idea of using RTL stored as text in a file 20555as an interface between a language front end and the bulk of GCC. This 20556idea is not feasible. 20557 20558 GCC was designed to use RTL internally only. Correct RTL for a given 20559program is very dependent on the particular target machine. And the RTL 20560does not contain all the information about the program. 20561 20562 The proper way to interface GCC to a new language front end is with the 20563"tree" data structure, described in the files 'tree.h' and 'tree.def'. 20564The documentation for this structure (*note GENERIC::) is incomplete. 20565 20566 20567File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top 20568 2056915 Control Flow Graph 20570********************* 20571 20572A control flow graph (CFG) is a data structure built on top of the 20573intermediate code representation (the RTL or 'GIMPLE' instruction 20574stream) abstracting the control flow behavior of a function that is 20575being compiled. The CFG is a directed graph where the vertices 20576represent basic blocks and edges represent possible transfer of control 20577flow from one basic block to another. The data structures used to 20578represent the control flow graph are defined in 'basic-block.h'. 20579 20580 In GCC, the representation of control flow is maintained throughout the 20581compilation process, from constructing the CFG early in 'pass_build_cfg' 20582to 'pass_free_cfg' (see 'passes.def'). The CFG takes various different 20583modes and may undergo extensive manipulations, but the graph is always 20584valid between its construction and its release. This way, transfer of 20585information such as data flow, a measured profile, or the loop tree, can 20586be propagated through the passes pipeline, and even from 'GIMPLE' to 20587'RTL'. 20588 20589 Often the CFG may be better viewed as integral part of instruction 20590chain, than structure built on the top of it. Updating the compiler's 20591intermediate representation for instructions cannot be easily done 20592without proper maintenance of the CFG simultaneously. 20593 20594* Menu: 20595 20596* Basic Blocks:: The definition and representation of basic blocks. 20597* Edges:: Types of edges and their representation. 20598* Profile information:: Representation of frequencies and probabilities. 20599* Maintaining the CFG:: Keeping the control flow graph and up to date. 20600* Liveness information:: Using and maintaining liveness information. 20601 20602 20603File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 20604 2060515.1 Basic Blocks 20606================= 20607 20608A basic block is a straight-line sequence of code with only one entry 20609point and only one exit. In GCC, basic blocks are represented using the 20610'basic_block' data type. 20611 20612 Special basic blocks represent possible entry and exit points of a 20613function. These blocks are called 'ENTRY_BLOCK_PTR' and 20614'EXIT_BLOCK_PTR'. These blocks do not contain any code. 20615 20616 The 'BASIC_BLOCK' array contains all basic blocks in an unspecified 20617order. Each 'basic_block' structure has a field that holds a unique 20618integer identifier 'index' that is the index of the block in the 20619'BASIC_BLOCK' array. The total number of basic blocks in the function 20620is 'n_basic_blocks'. Both the basic block indices and the total number 20621of basic blocks may vary during the compilation process, as passes 20622reorder, create, duplicate, and destroy basic blocks. The index for any 20623block should never be greater than 'last_basic_block'. The indices 0 20624and 1 are special codes reserved for 'ENTRY_BLOCK' and 'EXIT_BLOCK', the 20625indices of 'ENTRY_BLOCK_PTR' and 'EXIT_BLOCK_PTR'. 20626 20627 Two pointer members of the 'basic_block' structure are the pointers 20628'next_bb' and 'prev_bb'. These are used to keep doubly linked chain of 20629basic blocks in the same order as the underlying instruction stream. 20630The chain of basic blocks is updated transparently by the provided API 20631for manipulating the CFG. The macro 'FOR_EACH_BB' can be used to visit 20632all the basic blocks in lexicographical order, except 'ENTRY_BLOCK' and 20633'EXIT_BLOCK'. The macro 'FOR_ALL_BB' also visits all basic blocks in 20634lexicographical order, including 'ENTRY_BLOCK' and 'EXIT_BLOCK'. 20635 20636 The functions 'post_order_compute' and 'inverted_post_order_compute' 20637can be used to compute topological orders of the CFG. The orders are 20638stored as vectors of basic block indices. The 'BASIC_BLOCK' array can 20639be used to iterate each basic block by index. Dominator traversals are 20640also possible using 'walk_dominator_tree'. Given two basic blocks A and 20641B, block A dominates block B if A is _always_ executed before B. 20642 20643 Each 'basic_block' also contains pointers to the first instruction (the 20644"head") and the last instruction (the "tail") or "end" of the 20645instruction stream contained in a basic block. In fact, since the 20646'basic_block' data type is used to represent blocks in both major 20647intermediate representations of GCC ('GIMPLE' and RTL), there are 20648pointers to the head and end of a basic block for both representations, 20649stored in intermediate representation specific data in the 'il' field of 20650'struct basic_block_def'. 20651 20652 For RTL, these pointers are 'BB_HEAD' and 'BB_END'. 20653 20654 In the RTL representation of a function, the instruction stream 20655contains not only the "real" instructions, but also "notes" or "insn 20656notes" (to distinguish them from "reg notes"). Any function that moves 20657or duplicates the basic blocks needs to take care of updating of these 20658notes. Many of these notes expect that the instruction stream consists 20659of linear regions, so updating can sometimes be tedious. All types of 20660insn notes are defined in 'insn-notes.def'. 20661 20662 In the RTL function representation, the instructions contained in a 20663basic block always follow a 'NOTE_INSN_BASIC_BLOCK', but zero or more 20664'CODE_LABEL' nodes can precede the block note. A basic block ends with 20665a control flow instruction or with the last instruction before the next 20666'CODE_LABEL' or 'NOTE_INSN_BASIC_BLOCK'. By definition, a 'CODE_LABEL' 20667cannot appear in the middle of the instruction stream of a basic block. 20668 20669 In addition to notes, the jump table vectors are also represented as 20670"pseudo-instructions" inside the insn stream. These vectors never 20671appear in the basic block and should always be placed just after the 20672table jump instructions referencing them. After removing the table-jump 20673it is often difficult to eliminate the code computing the address and 20674referencing the vector, so cleaning up these vectors is postponed until 20675after liveness analysis. Thus the jump table vectors may appear in the 20676insn stream unreferenced and without any purpose. Before any edge is 20677made "fall-thru", the existence of such construct in the way needs to be 20678checked by calling 'can_fallthru' function. 20679 20680 For the 'GIMPLE' representation, the PHI nodes and statements contained 20681in a basic block are in a 'gimple_seq' pointed to by the basic block 20682intermediate language specific pointers. Abstract containers and 20683iterators are used to access the PHI nodes and statements in a basic 20684blocks. These iterators are called "GIMPLE statement iterators" (GSIs). 20685Grep for '^gsi' in the various 'gimple-*' and 'tree-*' files. There is 20686a 'gimple_stmt_iterator' type for iterating over all kinds of statement, 20687and a 'gphi_iterator' subclass for iterating over PHI nodes. The 20688following snippet will pretty-print all PHI nodes the statements of the 20689current function in the GIMPLE representation. 20690 20691 basic_block bb; 20692 20693 FOR_EACH_BB (bb) 20694 { 20695 gphi_iterator pi; 20696 gimple_stmt_iterator si; 20697 20698 for (pi = gsi_start_phis (bb); !gsi_end_p (pi); gsi_next (&pi)) 20699 { 20700 gphi *phi = pi.phi (); 20701 print_gimple_stmt (dump_file, phi, 0, TDF_SLIM); 20702 } 20703 for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si)) 20704 { 20705 gimple stmt = gsi_stmt (si); 20706 print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM); 20707 } 20708 } 20709 20710 20711File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 20712 2071315.2 Edges 20714========== 20715 20716Edges represent possible control flow transfers from the end of some 20717basic block A to the head of another basic block B. We say that A is a 20718predecessor of B, and B is a successor of A. Edges are represented in 20719GCC with the 'edge' data type. Each 'edge' acts as a link between two 20720basic blocks: The 'src' member of an edge points to the predecessor 20721basic block of the 'dest' basic block. The members 'preds' and 'succs' 20722of the 'basic_block' data type point to type-safe vectors of edges to 20723the predecessors and successors of the block. 20724 20725 When walking the edges in an edge vector, "edge iterators" should be 20726used. Edge iterators are constructed using the 'edge_iterator' data 20727structure and several methods are available to operate on them: 20728 20729'ei_start' 20730 This function initializes an 'edge_iterator' that points to the 20731 first edge in a vector of edges. 20732 20733'ei_last' 20734 This function initializes an 'edge_iterator' that points to the 20735 last edge in a vector of edges. 20736 20737'ei_end_p' 20738 This predicate is 'true' if an 'edge_iterator' represents the last 20739 edge in an edge vector. 20740 20741'ei_one_before_end_p' 20742 This predicate is 'true' if an 'edge_iterator' represents the 20743 second last edge in an edge vector. 20744 20745'ei_next' 20746 This function takes a pointer to an 'edge_iterator' and makes it 20747 point to the next edge in the sequence. 20748 20749'ei_prev' 20750 This function takes a pointer to an 'edge_iterator' and makes it 20751 point to the previous edge in the sequence. 20752 20753'ei_edge' 20754 This function returns the 'edge' currently pointed to by an 20755 'edge_iterator'. 20756 20757'ei_safe_safe' 20758 This function returns the 'edge' currently pointed to by an 20759 'edge_iterator', but returns 'NULL' if the iterator is pointing at 20760 the end of the sequence. This function has been provided for 20761 existing code makes the assumption that a 'NULL' edge indicates the 20762 end of the sequence. 20763 20764 The convenience macro 'FOR_EACH_EDGE' can be used to visit all of the 20765edges in a sequence of predecessor or successor edges. It must not be 20766used when an element might be removed during the traversal, otherwise 20767elements will be missed. Here is an example of how to use the macro: 20768 20769 edge e; 20770 edge_iterator ei; 20771 20772 FOR_EACH_EDGE (e, ei, bb->succs) 20773 { 20774 if (e->flags & EDGE_FALLTHRU) 20775 break; 20776 } 20777 20778 There are various reasons why control flow may transfer from one block 20779to another. One possibility is that some instruction, for example a 20780'CODE_LABEL', in a linearized instruction stream just always starts a 20781new basic block. In this case a "fall-thru" edge links the basic block 20782to the first following basic block. But there are several other reasons 20783why edges may be created. The 'flags' field of the 'edge' data type is 20784used to store information about the type of edge we are dealing with. 20785Each edge is of one of the following types: 20786 20787_jump_ 20788 No type flags are set for edges corresponding to jump instructions. 20789 These edges are used for unconditional or conditional jumps and in 20790 RTL also for table jumps. They are the easiest to manipulate as 20791 they may be freely redirected when the flow graph is not in SSA 20792 form. 20793 20794_fall-thru_ 20795 Fall-thru edges are present in case where the basic block may 20796 continue execution to the following one without branching. These 20797 edges have the 'EDGE_FALLTHRU' flag set. Unlike other types of 20798 edges, these edges must come into the basic block immediately 20799 following in the instruction stream. The function 20800 'force_nonfallthru' is available to insert an unconditional jump in 20801 the case that redirection is needed. Note that this may require 20802 creation of a new basic block. 20803 20804_exception handling_ 20805 Exception handling edges represent possible control transfers from 20806 a trapping instruction to an exception handler. The definition of 20807 "trapping" varies. In C++, only function calls can throw, but for 20808 Ada exceptions like division by zero or segmentation fault are 20809 defined and thus each instruction possibly throwing this kind of 20810 exception needs to be handled as control flow instruction. 20811 Exception edges have the 'EDGE_ABNORMAL' and 'EDGE_EH' flags set. 20812 20813 When updating the instruction stream it is easy to change possibly 20814 trapping instruction to non-trapping, by simply removing the 20815 exception edge. The opposite conversion is difficult, but should 20816 not happen anyway. The edges can be eliminated via 20817 'purge_dead_edges' call. 20818 20819 In the RTL representation, the destination of an exception edge is 20820 specified by 'REG_EH_REGION' note attached to the insn. In case of 20821 a trapping call the 'EDGE_ABNORMAL_CALL' flag is set too. In the 20822 'GIMPLE' representation, this extra flag is not set. 20823 20824 In the RTL representation, the predicate 'may_trap_p' may be used 20825 to check whether instruction still may trap or not. For the tree 20826 representation, the 'tree_could_trap_p' predicate is available, but 20827 this predicate only checks for possible memory traps, as in 20828 dereferencing an invalid pointer location. 20829 20830_sibling calls_ 20831 Sibling calls or tail calls terminate the function in a 20832 non-standard way and thus an edge to the exit must be present. 20833 'EDGE_SIBCALL' and 'EDGE_ABNORMAL' are set in such case. These 20834 edges only exist in the RTL representation. 20835 20836_computed jumps_ 20837 Computed jumps contain edges to all labels in the function 20838 referenced from the code. All those edges have 'EDGE_ABNORMAL' 20839 flag set. The edges used to represent computed jumps often cause 20840 compile time performance problems, since functions consisting of 20841 many taken labels and many computed jumps may have _very_ dense 20842 flow graphs, so these edges need to be handled with special care. 20843 During the earlier stages of the compilation process, GCC tries to 20844 avoid such dense flow graphs by factoring computed jumps. For 20845 example, given the following series of jumps, 20846 20847 goto *x; 20848 [ ... ] 20849 20850 goto *x; 20851 [ ... ] 20852 20853 goto *x; 20854 [ ... ] 20855 20856 factoring the computed jumps results in the following code sequence 20857 which has a much simpler flow graph: 20858 20859 goto y; 20860 [ ... ] 20861 20862 goto y; 20863 [ ... ] 20864 20865 goto y; 20866 [ ... ] 20867 20868 y: 20869 goto *x; 20870 20871 However, the classic problem with this transformation is that it 20872 has a runtime cost in there resulting code: An extra jump. 20873 Therefore, the computed jumps are un-factored in the later passes 20874 of the compiler (in the pass called 20875 'pass_duplicate_computed_gotos'). Be aware of that when you work 20876 on passes in that area. There have been numerous examples already 20877 where the compile time for code with unfactored computed jumps 20878 caused some serious headaches. 20879 20880_nonlocal goto handlers_ 20881 GCC allows nested functions to return into caller using a 'goto' to 20882 a label passed to as an argument to the callee. The labels passed 20883 to nested functions contain special code to cleanup after function 20884 call. Such sections of code are referred to as "nonlocal goto 20885 receivers". If a function contains such nonlocal goto receivers, 20886 an edge from the call to the label is created with the 20887 'EDGE_ABNORMAL' and 'EDGE_ABNORMAL_CALL' flags set. 20888 20889_function entry points_ 20890 By definition, execution of function starts at basic block 0, so 20891 there is always an edge from the 'ENTRY_BLOCK_PTR' to basic block 20892 0. There is no 'GIMPLE' representation for alternate entry points 20893 at this moment. In RTL, alternate entry points are specified by 20894 'CODE_LABEL' with 'LABEL_ALTERNATE_NAME' defined. This feature is 20895 currently used for multiple entry point prologues and is limited to 20896 post-reload passes only. This can be used by back-ends to emit 20897 alternate prologues for functions called from different contexts. 20898 In future full support for multiple entry functions defined by 20899 Fortran 90 needs to be implemented. 20900 20901_function exits_ 20902 In the pre-reload representation a function terminates after the 20903 last instruction in the insn chain and no explicit return 20904 instructions are used. This corresponds to the fall-thru edge into 20905 exit block. After reload, optimal RTL epilogues are used that use 20906 explicit (conditional) return instructions that are represented by 20907 edges with no flags set. 20908 20909 20910File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 20911 2091215.3 Profile information 20913======================== 20914 20915In many cases a compiler must make a choice whether to trade speed in 20916one part of code for speed in another, or to trade code size for code 20917speed. In such cases it is useful to know information about how often 20918some given block will be executed. That is the purpose for maintaining 20919profile within the flow graph. GCC can handle profile information 20920obtained through "profile feedback", but it can also estimate branch 20921probabilities based on statics and heuristics. 20922 20923 The feedback based profile is produced by compiling the program with 20924instrumentation, executing it on a train run and reading the numbers of 20925executions of basic blocks and edges back to the compiler while 20926re-compiling the program to produce the final executable. This method 20927provides very accurate information about where a program spends most of 20928its time on the train run. Whether it matches the average run of course 20929depends on the choice of train data set, but several studies have shown 20930that the behavior of a program usually changes just marginally over 20931different data sets. 20932 20933 When profile feedback is not available, the compiler may be asked to 20934attempt to predict the behavior of each branch in the program using a 20935set of heuristics (see 'predict.def' for details) and compute estimated 20936frequencies of each basic block by propagating the probabilities over 20937the graph. 20938 20939 Each 'basic_block' contains two integer fields to represent profile 20940information: 'frequency' and 'count'. The 'frequency' is an estimation 20941how often is basic block executed within a function. It is represented 20942as an integer scaled in the range from 0 to 'BB_FREQ_BASE'. The most 20943frequently executed basic block in function is initially set to 20944'BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 20945During optimization, the frequency of the most frequent basic block can 20946both decrease (for instance by loop unrolling) or grow (for instance by 20947cross-jumping optimization), so scaling sometimes has to be performed 20948multiple times. 20949 20950 The 'count' contains hard-counted numbers of execution measured during 20951training runs and is nonzero only when profile feedback is available. 20952This value is represented as the host's widest integer (typically a 64 20953bit integer) of the special type 'gcov_type'. 20954 20955 Most optimization passes can use only the frequency information of a 20956basic block, but a few passes may want to know hard execution counts. 20957The frequencies should always match the counts after scaling, however 20958during updating of the profile information numerical error may 20959accumulate into quite large errors. 20960 20961 Each edge also contains a branch probability field: an integer in the 20962range from 0 to 'REG_BR_PROB_BASE'. It represents probability of 20963passing control from the end of the 'src' basic block to the 'dest' 20964basic block, i.e. the probability that control will flow along this 20965edge. The 'EDGE_FREQUENCY' macro is available to compute how frequently 20966a given edge is taken. There is a 'count' field for each edge as well, 20967representing same information as for a basic block. 20968 20969 The basic block frequencies are not represented in the instruction 20970stream, but in the RTL representation the edge frequencies are 20971represented for conditional jumps (via the 'REG_BR_PROB' macro) since 20972they are used when instructions are output to the assembly file and the 20973flow graph is no longer maintained. 20974 20975 The probability that control flow arrives via a given edge to its 20976destination basic block is called "reverse probability" and is not 20977directly represented, but it may be easily computed from frequencies of 20978basic blocks. 20979 20980 Updating profile information is a delicate task that can unfortunately 20981not be easily integrated with the CFG manipulation API. Many of the 20982functions and hooks to modify the CFG, such as 20983'redirect_edge_and_branch', do not have enough information to easily 20984update the profile, so updating it is in the majority of cases left up 20985to the caller. It is difficult to uncover bugs in the profile updating 20986code, because they manifest themselves only by producing worse code, and 20987checking profile consistency is not possible because of numeric error 20988accumulation. Hence special attention needs to be given to this issue 20989in each pass that modifies the CFG. 20990 20991 It is important to point out that 'REG_BR_PROB_BASE' and 'BB_FREQ_BASE' 20992are both set low enough to be possible to compute second power of any 20993frequency or probability in the flow graph, it is not possible to even 20994square the 'count' field, as modern CPUs are fast enough to execute 20995$2^32$ operations quickly. 20996 20997 20998File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 20999 2100015.4 Maintaining the CFG 21001======================== 21002 21003An important task of each compiler pass is to keep both the control flow 21004graph and all profile information up-to-date. Reconstruction of the 21005control flow graph after each pass is not an option, since it may be 21006very expensive and lost profile information cannot be reconstructed at 21007all. 21008 21009 GCC has two major intermediate representations, and both use the 21010'basic_block' and 'edge' data types to represent control flow. Both 21011representations share as much of the CFG maintenance code as possible. 21012For each representation, a set of "hooks" is defined so that each 21013representation can provide its own implementation of CFG manipulation 21014routines when necessary. These hooks are defined in 'cfghooks.h'. 21015There are hooks for almost all common CFG manipulations, including block 21016splitting and merging, edge redirection and creating and deleting basic 21017blocks. These hooks should provide everything you need to maintain and 21018manipulate the CFG in both the RTL and 'GIMPLE' representation. 21019 21020 At the moment, the basic block boundaries are maintained transparently 21021when modifying instructions, so there rarely is a need to move them 21022manually (such as in case someone wants to output instruction outside 21023basic block explicitly). 21024 21025 In the RTL representation, each instruction has a 'BLOCK_FOR_INSN' 21026value that represents pointer to the basic block that contains the 21027instruction. In the 'GIMPLE' representation, the function 'gimple_bb' 21028returns a pointer to the basic block containing the queried statement. 21029 21030 When changes need to be applied to a function in its 'GIMPLE' 21031representation, "GIMPLE statement iterators" should be used. These 21032iterators provide an integrated abstraction of the flow graph and the 21033instruction stream. Block statement iterators are constructed using the 21034'gimple_stmt_iterator' data structure and several modifiers are 21035available, including the following: 21036 21037'gsi_start' 21038 This function initializes a 'gimple_stmt_iterator' that points to 21039 the first non-empty statement in a basic block. 21040 21041'gsi_last' 21042 This function initializes a 'gimple_stmt_iterator' that points to 21043 the last statement in a basic block. 21044 21045'gsi_end_p' 21046 This predicate is 'true' if a 'gimple_stmt_iterator' represents the 21047 end of a basic block. 21048 21049'gsi_next' 21050 This function takes a 'gimple_stmt_iterator' and makes it point to 21051 its successor. 21052 21053'gsi_prev' 21054 This function takes a 'gimple_stmt_iterator' and makes it point to 21055 its predecessor. 21056 21057'gsi_insert_after' 21058 This function inserts a statement after the 'gimple_stmt_iterator' 21059 passed in. The final parameter determines whether the statement 21060 iterator is updated to point to the newly inserted statement, or 21061 left pointing to the original statement. 21062 21063'gsi_insert_before' 21064 This function inserts a statement before the 'gimple_stmt_iterator' 21065 passed in. The final parameter determines whether the statement 21066 iterator is updated to point to the newly inserted statement, or 21067 left pointing to the original statement. 21068 21069'gsi_remove' 21070 This function removes the 'gimple_stmt_iterator' passed in and 21071 rechains the remaining statements in a basic block, if any. 21072 21073 In the RTL representation, the macros 'BB_HEAD' and 'BB_END' may be 21074used to get the head and end 'rtx' of a basic block. No abstract 21075iterators are defined for traversing the insn chain, but you can just 21076use 'NEXT_INSN' and 'PREV_INSN' instead. *Note Insns::. 21077 21078 Usually a code manipulating pass simplifies the instruction stream and 21079the flow of control, possibly eliminating some edges. This may for 21080example happen when a conditional jump is replaced with an unconditional 21081jump. Updating of edges is not transparent and each optimization pass 21082is required to do so manually. However only few cases occur in 21083practice. The pass may call 'purge_dead_edges' on a given basic block 21084to remove superfluous edges, if any. 21085 21086 Another common scenario is redirection of branch instructions, but this 21087is best modeled as redirection of edges in the control flow graph and 21088thus use of 'redirect_edge_and_branch' is preferred over more low level 21089functions, such as 'redirect_jump' that operate on RTL chain only. The 21090CFG hooks defined in 'cfghooks.h' should provide the complete API 21091required for manipulating and maintaining the CFG. 21092 21093 It is also possible that a pass has to insert control flow instruction 21094into the middle of a basic block, thus creating an entry point in the 21095middle of the basic block, which is impossible by definition: The block 21096must be split to make sure it only has one entry point, i.e. the head of 21097the basic block. The CFG hook 'split_block' may be used when an 21098instruction in the middle of a basic block has to become the target of a 21099jump or branch instruction. 21100 21101 For a global optimizer, a common operation is to split edges in the 21102flow graph and insert instructions on them. In the RTL representation, 21103this can be easily done using the 'insert_insn_on_edge' function that 21104emits an instruction "on the edge", caching it for a later 21105'commit_edge_insertions' call that will take care of moving the inserted 21106instructions off the edge into the instruction stream contained in a 21107basic block. This includes the creation of new basic blocks where 21108needed. In the 'GIMPLE' representation, the equivalent functions are 21109'gsi_insert_on_edge' which inserts a block statement iterator on an 21110edge, and 'gsi_commit_edge_inserts' which flushes the instruction to 21111actual instruction stream. 21112 21113 While debugging the optimization pass, the 'verify_flow_info' function 21114may be useful to find bugs in the control flow graph updating code. 21115 21116 21117File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 21118 2111915.5 Liveness information 21120========================= 21121 21122Liveness information is useful to determine whether some register is 21123"live" at given point of program, i.e. that it contains a value that may 21124be used at a later point in the program. This information is used, for 21125instance, during register allocation, as the pseudo registers only need 21126to be assigned to a unique hard register or to a stack slot if they are 21127live. The hard registers and stack slots may be freely reused for other 21128values when a register is dead. 21129 21130 Liveness information is available in the back end starting with 21131'pass_df_initialize' and ending with 'pass_df_finish'. Three flavors of 21132live analysis are available: With 'LR', it is possible to determine at 21133any point 'P' in the function if the register may be used on some path 21134from 'P' to the end of the function. With 'UR', it is possible to 21135determine if there is a path from the beginning of the function to 'P' 21136that defines the variable. 'LIVE' is the intersection of the 'LR' and 21137'UR' and a variable is live at 'P' if there is both an assignment that 21138reaches it from the beginning of the function and a use that can be 21139reached on some path from 'P' to the end of the function. 21140 21141 In general 'LIVE' is the most useful of the three. The macros 21142'DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The 21143macros take a basic block number and return a bitmap that is indexed by 21144the register number. This information is only guaranteed to be up to 21145date after calls are made to 'df_analyze'. See the file 'df-core.c' for 21146details on using the dataflow. 21147 21148 The liveness information is stored partly in the RTL instruction stream 21149and partly in the flow graph. Local information is stored in the 21150instruction stream: Each instruction may contain 'REG_DEAD' notes 21151representing that the value of a given register is no longer needed, or 21152'REG_UNUSED' notes representing that the value computed by the 21153instruction is never used. The second is useful for instructions 21154computing multiple values at once. 21155 21156 21157File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top 21158 2115916 Analysis and Representation of Loops 21160*************************************** 21161 21162GCC provides extensive infrastructure for work with natural loops, i.e., 21163strongly connected components of CFG with only one entry block. This 21164chapter describes representation of loops in GCC, both on GIMPLE and in 21165RTL, as well as the interfaces to loop-related analyses (induction 21166variable analysis and number of iterations analysis). 21167 21168* Menu: 21169 21170* Loop representation:: Representation and analysis of loops. 21171* Loop querying:: Getting information about loops. 21172* Loop manipulation:: Loop manipulation functions. 21173* LCSSA:: Loop-closed SSA form. 21174* Scalar evolutions:: Induction variables on GIMPLE. 21175* loop-iv:: Induction variables on RTL. 21176* Number of iterations:: Number of iterations analysis. 21177* Dependency analysis:: Data dependency analysis. 21178 21179 21180File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 21181 2118216.1 Loop representation 21183======================== 21184 21185This chapter describes the representation of loops in GCC, and functions 21186that can be used to build, modify and analyze this representation. Most 21187of the interfaces and data structures are declared in 'cfgloop.h'. Loop 21188structures are analyzed and this information disposed or updated at the 21189discretion of individual passes. Still most of the generic CFG 21190manipulation routines are aware of loop structures and try to keep them 21191up-to-date. By this means an increasing part of the compilation 21192pipeline is setup to maintain loop structure across passes to allow 21193attaching meta information to individual loops for consumption by later 21194passes. 21195 21196 In general, a natural loop has one entry block (header) and possibly 21197several back edges (latches) leading to the header from the inside of 21198the loop. Loops with several latches may appear if several loops share 21199a single header, or if there is a branching in the middle of the loop. 21200The representation of loops in GCC however allows only loops with a 21201single latch. During loop analysis, headers of such loops are split and 21202forwarder blocks are created in order to disambiguate their structures. 21203Heuristic based on profile information and structure of the induction 21204variables in the loops is used to determine whether the latches 21205correspond to sub-loops or to control flow in a single loop. This means 21206that the analysis sometimes changes the CFG, and if you run it in the 21207middle of an optimization pass, you must be able to deal with the new 21208blocks. You may avoid CFG changes by passing 21209'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note 21210however that most other loop manipulation functions will not work 21211correctly for loops with multiple latch edges (the functions that only 21212query membership of blocks to loops and subloop relationships, or 21213enumerate and test loop exits, can be expected to work). 21214 21215 Body of the loop is the set of blocks that are dominated by its header, 21216and reachable from its latch against the direction of edges in CFG. The 21217loops are organized in a containment hierarchy (tree) such that all the 21218loops immediately contained inside loop L are the children of L in the 21219tree. This tree is represented by the 'struct loops' structure. The 21220root of this tree is a fake loop that contains all blocks in the 21221function. Each of the loops is represented in a 'struct loop' 21222structure. Each loop is assigned an index ('num' field of the 'struct 21223loop' structure), and the pointer to the loop is stored in the 21224corresponding field of the 'larray' vector in the loops structure. The 21225indices do not have to be continuous, there may be empty ('NULL') 21226entries in the 'larray' created by deleting loops. Also, there is no 21227guarantee on the relative order of a loop and its subloops in the 21228numbering. The index of a loop never changes. 21229 21230 The entries of the 'larray' field should not be accessed directly. The 21231function 'get_loop' returns the loop description for a loop with the 21232given index. 'number_of_loops' function returns number of loops in the 21233function. To traverse all loops, use 'FOR_EACH_LOOP' macro. The 21234'flags' argument of the macro is used to determine the direction of 21235traversal and the set of loops visited. Each loop is guaranteed to be 21236visited exactly once, regardless of the changes to the loop tree, and 21237the loops may be removed during the traversal. The newly created loops 21238are never traversed, if they need to be visited, this must be done 21239separately after their creation. 21240 21241 Each basic block contains the reference to the innermost loop it 21242belongs to ('loop_father'). For this reason, it is only possible to 21243have one 'struct loops' structure initialized at the same time for each 21244CFG. The global variable 'current_loops' contains the 'struct loops' 21245structure. Many of the loop manipulation functions assume that 21246dominance information is up-to-date. 21247 21248 The loops are analyzed through 'loop_optimizer_init' function. The 21249argument of this function is a set of flags represented in an integer 21250bitmask. These flags specify what other properties of the loop 21251structures should be calculated/enforced and preserved later: 21252 21253 * 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes 21254 to CFG will be performed in the loop analysis, in particular, loops 21255 with multiple latch edges will not be disambiguated. If a loop has 21256 multiple latches, its latch block is set to NULL. Most of the loop 21257 manipulation functions will not work for loops in this shape. No 21258 other flags that require CFG changes can be passed to 21259 loop_optimizer_init. 21260 * 'LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a way 21261 that each loop has only one entry edge, and additionally, the 21262 source block of this entry edge has only one successor. This 21263 creates a natural place where the code can be moved out of the 21264 loop, and ensures that the entry edge of the loop leads from its 21265 immediate super-loop. 21266 * 'LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 21267 the latch block of each loop to have only one successor. This 21268 ensures that the latch of the loop does not belong to any of its 21269 sub-loops, and makes manipulation with the loops significantly 21270 easier. Most of the loop manipulation functions assume that the 21271 loops are in this shape. Note that with this flag, the "normal" 21272 loop without any control flow inside and with one exit consists of 21273 two basic blocks. 21274 * 'LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 21275 the strongly connected components that are not natural loops (have 21276 more than one entry block) are marked with 'BB_IRREDUCIBLE_LOOP' 21277 and 'EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 21278 and edges that belong to natural loops that are in such an 21279 irreducible region (but it is set for the entry and exit edges of 21280 such a loop, if they lead to/from this region). 21281 * 'LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and 21282 updated for each loop. This makes some functions (e.g., 21283 'get_loop_exit_edges') more efficient. Some functions (e.g., 21284 'single_exit') can be used only if the lists of exits are recorded. 21285 21286 These properties may also be computed/enforced later, using functions 21287'create_preheaders', 'force_single_succ_latches', 21288'mark_irreducible_loops' and 'record_loop_exits'. The properties can be 21289queried using 'loops_state_satisfies_p'. 21290 21291 The memory occupied by the loops structures should be freed with 21292'loop_optimizer_finalize' function. When loop structures are setup to 21293be preserved across passes this function reduces the information to be 21294kept up-to-date to a minimum (only 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' 21295set). 21296 21297 The CFG manipulation functions in general do not update loop 21298structures. Specialized versions that additionally do so are provided 21299for the most common tasks. On GIMPLE, 'cleanup_tree_cfg_loop' function 21300can be used to cleanup CFG while updating the loops structures if 21301'current_loops' is set. 21302 21303 At the moment loop structure is preserved from the start of GIMPLE loop 21304optimizations until the end of RTL loop optimizations. During this time 21305a loop can be tracked by its 'struct loop' and number. 21306 21307 21308File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 21309 2131016.2 Loop querying 21311================== 21312 21313The functions to query the information about loops are declared in 21314'cfgloop.h'. Some of the information can be taken directly from the 21315structures. 'loop_father' field of each basic block contains the 21316innermost loop to that the block belongs. The most useful fields of 21317loop structure (that are kept up-to-date at all times) are: 21318 21319 * 'header', 'latch': Header and latch basic blocks of the loop. 21320 * 'num_nodes': Number of basic blocks in the loop (including the 21321 basic blocks of the sub-loops). 21322 * 'outer', 'inner', 'next': The super-loop, the first sub-loop, and 21323 the sibling of the loop in the loops tree. 21324 21325 There are other fields in the loop structures, many of them used only 21326by some of the passes, or not updated during CFG changes; in general, 21327they should not be accessed directly. 21328 21329 The most important functions to query loop structures are: 21330 21331 * 'loop_depth': The depth of the loop in the loops tree, i.e., the 21332 number of super-loops of the loop. 21333 * 'flow_loops_dump': Dumps the information about loops to a file. 21334 * 'verify_loop_structure': Checks consistency of the loop structures. 21335 * 'loop_latch_edge': Returns the latch edge of a loop. 21336 * 'loop_preheader_edge': If loops have preheaders, returns the 21337 preheader edge of a loop. 21338 * 'flow_loop_nested_p': Tests whether loop is a sub-loop of another 21339 loop. 21340 * 'flow_bb_inside_loop_p': Tests whether a basic block belongs to a 21341 loop (including its sub-loops). 21342 * 'find_common_loop': Finds the common super-loop of two loops. 21343 * 'superloop_at_depth': Returns the super-loop of a loop with the 21344 given depth. 21345 * 'tree_num_loop_insns', 'num_loop_insns': Estimates the number of 21346 insns in the loop, on GIMPLE and on RTL. 21347 * 'loop_exit_edge_p': Tests whether edge is an exit from a loop. 21348 * 'mark_loop_exit_edges': Marks all exit edges of all loops with 21349 'EDGE_LOOP_EXIT' flag. 21350 * 'get_loop_body', 'get_loop_body_in_dom_order', 21351 'get_loop_body_in_bfs_order': Enumerates the basic blocks in the 21352 loop in depth-first search order in reversed CFG, ordered by 21353 dominance relation, and breath-first search order, respectively. 21354 * 'single_exit': Returns the single exit edge of the loop, or 'NULL' 21355 if the loop has more than one exit. You can only use this function 21356 if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used. 21357 * 'get_loop_exit_edges': Enumerates the exit edges of a loop. 21358 * 'just_once_each_iteration_p': Returns true if the basic block is 21359 executed exactly once during each iteration of a loop (that is, it 21360 does not belong to a sub-loop, and it dominates the latch of the 21361 loop). 21362 21363 21364File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 21365 2136616.3 Loop manipulation 21367====================== 21368 21369The loops tree can be manipulated using the following functions: 21370 21371 * 'flow_loop_tree_node_add': Adds a node to the tree. 21372 * 'flow_loop_tree_node_remove': Removes a node from the tree. 21373 * 'add_bb_to_loop': Adds a basic block to a loop. 21374 * 'remove_bb_from_loops': Removes a basic block from loops. 21375 21376 Most low-level CFG functions update loops automatically. The following 21377functions handle some more complicated cases of CFG manipulations: 21378 21379 * 'remove_path': Removes an edge and all blocks it dominates. 21380 * 'split_loop_exit_edge': Splits exit edge of the loop, ensuring that 21381 PHI node arguments remain in the loop (this ensures that 21382 loop-closed SSA form is preserved). Only useful on GIMPLE. 21383 21384 Finally, there are some higher-level loop transformations implemented. 21385While some of them are written so that they should work on non-innermost 21386loops, they are mostly untested in that case, and at the moment, they 21387are only reliable for the innermost loops: 21388 21389 * 'create_iv': Creates a new induction variable. Only works on 21390 GIMPLE. 'standard_iv_increment_position' can be used to find a 21391 suitable place for the iv increment. 21392 * 'duplicate_loop_to_header_edge', 21393 'tree_duplicate_loop_to_header_edge': These functions (on RTL and 21394 on GIMPLE) duplicate the body of the loop prescribed number of 21395 times on one of the edges entering loop header, thus performing 21396 either loop unrolling or loop peeling. 'can_duplicate_loop_p' 21397 ('can_unroll_loop_p' on GIMPLE) must be true for the duplicated 21398 loop. 21399 * 'loop_version': This function creates a copy of a loop, and a 21400 branch before them that selects one of them depending on the 21401 prescribed condition. This is useful for optimizations that need 21402 to verify some assumptions in runtime (one of the copies of the 21403 loop is usually left unchanged, while the other one is transformed 21404 in some way). 21405 * 'tree_unroll_loop': Unrolls the loop, including peeling the extra 21406 iterations to make the number of iterations divisible by unroll 21407 factor, updating the exit condition, and removing the exits that 21408 now cannot be taken. Works only on GIMPLE. 21409 21410 21411File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 21412 2141316.4 Loop-closed SSA form 21414========================= 21415 21416Throughout the loop optimizations on tree level, one extra condition is 21417enforced on the SSA form: No SSA name is used outside of the loop in 21418that it is defined. The SSA form satisfying this condition is called 21419"loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 21420created at the exits of the loops for the SSA names that are used 21421outside of them. Only the real operands (not virtual SSA names) are 21422held in LCSSA, in order to save memory. 21423 21424 There are various benefits of LCSSA: 21425 21426 * Many optimizations (value range analysis, final value replacement) 21427 are interested in the values that are defined in the loop and used 21428 outside of it, i.e., exactly those for that we create new PHI 21429 nodes. 21430 * In induction variable analysis, it is not necessary to specify the 21431 loop in that the analysis should be performed - the scalar 21432 evolution analysis always returns the results with respect to the 21433 loop in that the SSA name is defined. 21434 * It makes updating of SSA form during loop transformations simpler. 21435 Without LCSSA, operations like loop unrolling may force creation of 21436 PHI nodes arbitrarily far from the loop, while in LCSSA, the SSA 21437 form can be updated locally. However, since we only keep real 21438 operands in LCSSA, we cannot use this advantage (we could have 21439 local updating of real operands, but it is not much more efficient 21440 than to use generic SSA form updating for it as well; the amount of 21441 changes to SSA is the same). 21442 21443 However, it also means LCSSA must be updated. This is usually 21444straightforward, unless you create a new value in loop and use it 21445outside, or unless you manipulate loop exit edges (functions are 21446provided to make these manipulations simple). 21447'rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, and 21448'verify_loop_closed_ssa' to check that the invariant of LCSSA is 21449preserved. 21450 21451 21452File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 21453 2145416.5 Scalar evolutions 21455====================== 21456 21457Scalar evolutions (SCEV) are used to represent results of induction 21458variable analysis on GIMPLE. They enable us to represent variables with 21459complicated behavior in a simple and consistent way (we only use it to 21460express values of polynomial induction variables, but it is possible to 21461extend it). The interfaces to SCEV analysis are declared in 21462'tree-scalar-evolution.h'. To use scalar evolutions analysis, 21463'scev_initialize' must be used. To stop using SCEV, 'scev_finalize' 21464should be used. SCEV analysis caches results in order to save time and 21465memory. This cache however is made invalid by most of the loop 21466transformations, including removal of code. If such a transformation is 21467performed, 'scev_reset' must be called to clean the caches. 21468 21469 Given an SSA name, its behavior in loops can be analyzed using the 21470'analyze_scalar_evolution' function. The returned SCEV however does not 21471have to be fully analyzed and it may contain references to other SSA 21472names defined in the loop. To resolve these (potentially recursive) 21473references, 'instantiate_parameters' or 'resolve_mixers' functions must 21474be used. 'instantiate_parameters' is useful when you use the results of 21475SCEV only for some analysis, and when you work with whole nest of loops 21476at once. It will try replacing all SSA names by their SCEV in all 21477loops, including the super-loops of the current loop, thus providing a 21478complete information about the behavior of the variable in the loop 21479nest. 'resolve_mixers' is useful if you work with only one loop at a 21480time, and if you possibly need to create code based on the value of the 21481induction variable. It will only resolve the SSA names defined in the 21482current loop, leaving the SSA names defined outside unchanged, even if 21483their evolution in the outer loops is known. 21484 21485 The SCEV is a normal tree expression, except for the fact that it may 21486contain several special tree nodes. One of them is 'SCEV_NOT_KNOWN', 21487used for SSA names whose value cannot be expressed. The other one is 21488'POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 21489and loop (both base and step may contain further polynomial chrecs). 21490Type of the expression and of base and step must be the same. A 21491variable has evolution 'POLYNOMIAL_CHREC(base, step, loop)' if it is (in 21492the specified loop) equivalent to 'x_1' in the following example 21493 21494 while (...) 21495 { 21496 x_1 = phi (base, x_2); 21497 x_2 = x_1 + step; 21498 } 21499 21500 Note that this includes the language restrictions on the operations. 21501For example, if we compile C code and 'x' has signed type, then the 21502overflow in addition would cause undefined behavior, and we may assume 21503that this does not happen. Hence, the value with this SCEV cannot 21504overflow (which restricts the number of iterations of such a loop). 21505 21506 In many cases, one wants to restrict the attention just to affine 21507induction variables. In this case, the extra expressive power of SCEV 21508is not useful, and may complicate the optimizations. In this case, 21509'simple_iv' function may be used to analyze a value - the result is a 21510loop-invariant base and step. 21511 21512 21513File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 21514 2151516.6 IV analysis on RTL 21516======================= 21517 21518The induction variable on RTL is simple and only allows analysis of 21519affine induction variables, and only in one loop at once. The interface 21520is declared in 'cfgloop.h'. Before analyzing induction variables in a 21521loop L, 'iv_analysis_loop_init' function must be called on L. After the 21522analysis (possibly calling 'iv_analysis_loop_init' for several loops) is 21523finished, 'iv_analysis_done' should be called. The following functions 21524can be used to access the results of the analysis: 21525 21526 * 'iv_analyze': Analyzes a single register used in the given insn. 21527 If no use of the register in this insn is found, the following 21528 insns are scanned, so that this function can be called on the insn 21529 returned by get_condition. 21530 * 'iv_analyze_result': Analyzes result of the assignment in the given 21531 insn. 21532 * 'iv_analyze_expr': Analyzes a more complicated expression. All its 21533 operands are analyzed by 'iv_analyze', and hence they must be used 21534 in the specified insn or one of the following insns. 21535 21536 The description of the induction variable is provided in 'struct 21537rtx_iv'. In order to handle subregs, the representation is a bit 21538complicated; if the value of the 'extend' field is not 'UNKNOWN', the 21539value of the induction variable in the i-th iteration is 21540 21541 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 21542 21543 with the following exception: if 'first_special' is true, then the 21544value in the first iteration (when 'i' is zero) is 'delta + mult * 21545base'. However, if 'extend' is equal to 'UNKNOWN', then 'first_special' 21546must be false, 'delta' 0, 'mult' 1 and the value in the i-th iteration 21547is 21548 21549 subreg_{mode} (base + i * step) 21550 21551 The function 'get_iv_value' can be used to perform these calculations. 21552 21553 21554File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 21555 2155616.7 Number of iterations analysis 21557================================== 21558 21559Both on GIMPLE and on RTL, there are functions available to determine 21560the number of iterations of a loop, with a similar interface. The 21561number of iterations of a loop in GCC is defined as the number of 21562executions of the loop latch. In many cases, it is not possible to 21563determine the number of iterations unconditionally - the determined 21564number is correct only if some assumptions are satisfied. The analysis 21565tries to verify these conditions using the information contained in the 21566program; if it fails, the conditions are returned together with the 21567result. The following information and conditions are provided by the 21568analysis: 21569 21570 * 'assumptions': If this condition is false, the rest of the 21571 information is invalid. 21572 * 'noloop_assumptions' on RTL, 'may_be_zero' on GIMPLE: If this 21573 condition is true, the loop exits in the first iteration. 21574 * 'infinite': If this condition is true, the loop is infinite. This 21575 condition is only available on RTL. On GIMPLE, conditions for 21576 finiteness of the loop are included in 'assumptions'. 21577 * 'niter_expr' on RTL, 'niter' on GIMPLE: The expression that gives 21578 number of iterations. The number of iterations is defined as the 21579 number of executions of the loop latch. 21580 21581 Both on GIMPLE and on RTL, it necessary for the induction variable 21582analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 21583On GIMPLE, the results are stored to 'struct tree_niter_desc' structure. 21584Number of iterations before the loop is exited through a given exit can 21585be determined using 'number_of_iterations_exit' function. On RTL, the 21586results are returned in 'struct niter_desc' structure. The 21587corresponding function is named 'check_simple_exit'. There are also 21588functions that pass through all the exits of a loop and try to find one 21589with easy to determine number of iterations - 'find_loop_niter' on 21590GIMPLE and 'find_simple_exit' on RTL. Finally, there are functions that 21591provide the same information, but additionally cache it, so that 21592repeated calls to number of iterations are not so costly - 21593'number_of_latch_executions' on GIMPLE and 'get_simple_loop_desc' on 21594RTL. 21595 21596 Note that some of these functions may behave slightly differently than 21597others - some of them return only the expression for the number of 21598iterations, and fail if there are some assumptions. The function 21599'number_of_latch_executions' works only for single-exit loops. The 21600function 'number_of_cond_exit_executions' can be used to determine 21601number of executions of the exit condition of a single-exit loop (i.e., 21602the 'number_of_latch_executions' increased by one). 21603 21604 On GIMPLE, below constraint flags affect semantics of some APIs of 21605number of iterations analyzer: 21606 21607 * 'LOOP_C_INFINITE': If this constraint flag is set, the loop is 21608 known to be infinite. APIs like 'number_of_iterations_exit' can 21609 return false directly without doing any analysis. 21610 * 'LOOP_C_FINITE': If this constraint flag is set, the loop is known 21611 to be finite, in other words, loop's number of iterations can be 21612 computed with 'assumptions' be true. 21613 21614 Generally, the constraint flags are set/cleared by consumers which are 21615loop optimizers. It's also the consumers' responsibility to set/clear 21616constraints correctly. Failing to do that might result in hard to track 21617down bugs in scev/niter consumers. One typical use case is vectorizer: 21618it drives number of iterations analyzer by setting 'LOOP_C_FINITE' and 21619vectorizes possibly infinite loop by versioning loop with analysis 21620result. In return, constraints set by consumers can also help number of 21621iterations analyzer in following optimizers. For example, 'niter' of a 21622loop versioned under 'assumptions' is valid unconditionally. 21623 21624 Other constraints may be added in the future, for example, a constraint 21625indicating that loops' latch must roll thus 'may_be_zero' would be false 21626unconditionally. 21627 21628 21629File: gccint.info, Node: Dependency analysis, Prev: Number of iterations, Up: Loop Analysis and Representation 21630 2163116.8 Data Dependency Analysis 21632============================= 21633 21634The code for the data dependence analysis can be found in 21635'tree-data-ref.c' and its interface and data structures are described in 21636'tree-data-ref.h'. The function that computes the data dependences for 21637all the array and pointer references for a given loop is 21638'compute_data_dependences_for_loop'. This function is currently used by 21639the linear loop transform and the vectorization passes. Before calling 21640this function, one has to allocate two vectors: a first vector will 21641contain the set of data references that are contained in the analyzed 21642loop body, and the second vector will contain the dependence relations 21643between the data references. Thus if the vector of data references is 21644of size 'n', the vector containing the dependence relations will contain 21645'n*n' elements. However if the analyzed loop contains side effects, 21646such as calls that potentially can interfere with the data references in 21647the current analyzed loop, the analysis stops while scanning the loop 21648body for data references, and inserts a single 'chrec_dont_know' in the 21649dependence relation array. 21650 21651 The data references are discovered in a particular order during the 21652scanning of the loop body: the loop body is analyzed in execution order, 21653and the data references of each statement are pushed at the end of the 21654data reference array. Two data references syntactically occur in the 21655program in the same order as in the array of data references. This 21656syntactic order is important in some classical data dependence tests, 21657and mapping this order to the elements of this array avoids costly 21658queries to the loop body representation. 21659 21660 Three types of data references are currently handled: ARRAY_REF, 21661INDIRECT_REF and COMPONENT_REF. The data structure for the data 21662reference is 'data_reference', where 'data_reference_p' is a name of a 21663pointer to the data reference structure. The structure contains the 21664following elements: 21665 21666 * 'base_object_info': Provides information about the base object of 21667 the data reference and its access functions. These access 21668 functions represent the evolution of the data reference in the loop 21669 relative to its base, in keeping with the classical meaning of the 21670 data reference access function for the support of arrays. For 21671 example, for a reference 'a.b[i][j]', the base object is 'a.b' and 21672 the access functions, one for each array subscript, are: '{i_init, 21673 + i_step}_1, {j_init, +, j_step}_2'. 21674 21675 * 'first_location_in_loop': Provides information about the first 21676 location accessed by the data reference in the loop and about the 21677 access function used to represent evolution relative to this 21678 location. This data is used to support pointers, and is not used 21679 for arrays (for which we have base objects). Pointer accesses are 21680 represented as a one-dimensional access that starts from the first 21681 location accessed in the loop. For example: 21682 21683 for1 i 21684 for2 j 21685 *((int *)p + i + j) = a[i][j]; 21686 21687 The access function of the pointer access is '{0, + 4B}_for2' 21688 relative to 'p + i'. The access functions of the array are 21689 '{i_init, + i_step}_for1' and '{j_init, +, j_step}_for2' relative 21690 to 'a'. 21691 21692 Usually, the object the pointer refers to is either unknown, or we 21693 cannot prove that the access is confined to the boundaries of a 21694 certain object. 21695 21696 Two data references can be compared only if at least one of these 21697 two representations has all its fields filled for both data 21698 references. 21699 21700 The current strategy for data dependence tests is as follows: If 21701 both 'a' and 'b' are represented as arrays, compare 'a.base_object' 21702 and 'b.base_object'; if they are equal, apply dependence tests (use 21703 access functions based on base_objects). Else if both 'a' and 'b' 21704 are represented as pointers, compare 'a.first_location' and 21705 'b.first_location'; if they are equal, apply dependence tests (use 21706 access functions based on first location). However, if 'a' and 'b' 21707 are represented differently, only try to prove that the bases are 21708 definitely different. 21709 21710 * Aliasing information. 21711 * Alignment information. 21712 21713 The structure describing the relation between two data references is 21714'data_dependence_relation' and the shorter name for a pointer to such a 21715structure is 'ddr_p'. This structure contains: 21716 21717 * a pointer to each data reference, 21718 * a tree node 'are_dependent' that is set to 'chrec_known' if the 21719 analysis has proved that there is no dependence between these two 21720 data references, 'chrec_dont_know' if the analysis was not able to 21721 determine any useful result and potentially there could exist a 21722 dependence between these data references, and 'are_dependent' is 21723 set to 'NULL_TREE' if there exist a dependence relation between the 21724 data references, and the description of this dependence relation is 21725 given in the 'subscripts', 'dir_vects', and 'dist_vects' arrays, 21726 * a boolean that determines whether the dependence relation can be 21727 represented by a classical distance vector, 21728 * an array 'subscripts' that contains a description of each subscript 21729 of the data references. Given two array accesses a subscript is 21730 the tuple composed of the access functions for a given dimension. 21731 For example, given 'A[f1][f2][f3]' and 'B[g1][g2][g3]', there are 21732 three subscripts: '(f1, g1), (f2, g2), (f3, g3)'. 21733 * two arrays 'dir_vects' and 'dist_vects' that contain classical 21734 representations of the data dependences under the form of direction 21735 and distance dependence vectors, 21736 * an array of loops 'loop_nest' that contains the loops to which the 21737 distance and direction vectors refer to. 21738 21739 Several functions for pretty printing the information extracted by the 21740data dependence analysis are available: 'dump_ddrs' prints with a 21741maximum verbosity the details of a data dependence relations array, 21742'dump_dist_dir_vectors' prints only the classical distance and direction 21743vectors for a data dependence relations array, and 21744'dump_data_references' prints the details of the data references 21745contained in a data reference array. 21746 21747 21748File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 21749 2175017 Machine Descriptions 21751*********************** 21752 21753A machine description has two parts: a file of instruction patterns 21754('.md' file) and a C header file of macro definitions. 21755 21756 The '.md' file for a target machine contains a pattern for each 21757instruction that the target machine supports (or at least each 21758instruction that is worth telling the compiler about). It may also 21759contain comments. A semicolon causes the rest of the line to be a 21760comment, unless the semicolon is inside a quoted string. 21761 21762 See the next chapter for information on the C header file. 21763 21764* Menu: 21765 21766* Overview:: How the machine description is used. 21767* Patterns:: How to write instruction patterns. 21768* Example:: An explained example of a 'define_insn' pattern. 21769* RTL Template:: The RTL template defines what insns match a pattern. 21770* Output Template:: The output template says how to make assembler code 21771 from such an insn. 21772* Output Statement:: For more generality, write C code to output 21773 the assembler code. 21774* Predicates:: Controlling what kinds of operands can be used 21775 for an insn. 21776* Constraints:: Fine-tuning operand selection. 21777* Standard Names:: Names mark patterns to use for code generation. 21778* Pattern Ordering:: When the order of patterns makes a difference. 21779* Dependent Patterns:: Having one pattern may make you need another. 21780* Jump Patterns:: Special considerations for patterns for jump insns. 21781* Looping Patterns:: How to define patterns for special looping insns. 21782* Insn Canonicalizations::Canonicalization of Instructions 21783* Expander Definitions::Generating a sequence of several RTL insns 21784 for a standard operation. 21785* Insn Splitting:: Splitting Instructions into Multiple Instructions. 21786* Including Patterns:: Including Patterns in Machine Descriptions. 21787* Peephole Definitions::Defining machine-specific peephole optimizations. 21788* Insn Attributes:: Specifying the value of attributes for generated insns. 21789* Conditional Execution::Generating 'define_insn' patterns for 21790 predication. 21791* Define Subst:: Generating 'define_insn' and 'define_expand' 21792 patterns from other patterns. 21793* Constant Definitions::Defining symbolic constants that can be used in the 21794 md file. 21795* Iterators:: Using iterators to generate patterns from a template. 21796 21797 21798File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 21799 2180017.1 Overview of How the Machine Description is Used 21801==================================================== 21802 21803There are three main conversions that happen in the compiler: 21804 21805 1. The front end reads the source code and builds a parse tree. 21806 21807 2. The parse tree is used to generate an RTL insn list based on named 21808 instruction patterns. 21809 21810 3. The insn list is matched against the RTL templates to produce 21811 assembler code. 21812 21813 For the generate pass, only the names of the insns matter, from either 21814a named 'define_insn' or a 'define_expand'. The compiler will choose 21815the pattern with the right name and apply the operands according to the 21816documentation later in this chapter, without regard for the RTL template 21817or operand constraints. Note that the names the compiler looks for are 21818hard-coded in the compiler--it will ignore unnamed patterns and patterns 21819with names it doesn't know about, but if you don't provide a named 21820pattern it needs, it will abort. 21821 21822 If a 'define_insn' is used, the template given is inserted into the 21823insn list. If a 'define_expand' is used, one of three things happens, 21824based on the condition logic. The condition logic may manually create 21825new insns for the insn list, say via 'emit_insn()', and invoke 'DONE'. 21826For certain named patterns, it may invoke 'FAIL' to tell the compiler to 21827use an alternate way of performing that task. If it invokes neither 21828'DONE' nor 'FAIL', the template given in the pattern is inserted, as if 21829the 'define_expand' were a 'define_insn'. 21830 21831 Once the insn list is generated, various optimization passes convert, 21832replace, and rearrange the insns in the insn list. This is where the 21833'define_split' and 'define_peephole' patterns get used, for example. 21834 21835 Finally, the insn list's RTL is matched up with the RTL templates in 21836the 'define_insn' patterns, and those patterns are used to emit the 21837final assembly code. For this purpose, each named 'define_insn' acts 21838like it's unnamed, since the names are ignored. 21839 21840 21841File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 21842 2184317.2 Everything about Instruction Patterns 21844========================================== 21845 21846A 'define_insn' expression is used to define instruction patterns to 21847which insns may be matched. A 'define_insn' expression contains an 21848incomplete RTL expression, with pieces to be filled in later, operand 21849constraints that restrict how the pieces can be filled in, and an output 21850template or C code to generate the assembler output. 21851 21852 A 'define_insn' is an RTL expression containing four or five operands: 21853 21854 1. An optional name N. When a name is present, the compiler 21855 automically generates a C++ function 'gen_N' that takes the 21856 operands of the instruction as arguments and returns the 21857 instruction's rtx pattern. The compiler also assigns the 21858 instruction a unique code 'CODE_FOR_N', with all such codes 21859 belonging to an enum called 'insn_code'. 21860 21861 These names serve one of two purposes. The first is to indicate 21862 that the instruction performs a certain standard job for the 21863 RTL-generation pass of the compiler, such as a move, an addition, 21864 or a conditional jump. The second is to help the target generate 21865 certain target-specific operations, such as when implementing 21866 target-specific intrinsic functions. 21867 21868 It is better to prefix target-specific names with the name of the 21869 target, to avoid any clash with current or future standard names. 21870 21871 The absence of a name is indicated by writing an empty string where 21872 the name should go. Nameless instruction patterns are never used 21873 for generating RTL code, but they may permit several simpler insns 21874 to be combined later on. 21875 21876 For the purpose of debugging the compiler, you may also specify a 21877 name beginning with the '*' character. Such a name is used only 21878 for identifying the instruction in RTL dumps; it is equivalent to 21879 having a nameless pattern for all other purposes. Names beginning 21880 with the '*' character are not required to be unique. 21881 21882 The name may also have the form '@N'. This has the same effect as 21883 a name 'N', but in addition tells the compiler to generate further 21884 helper functions; see *note Parameterized Names:: for details. 21885 21886 2. The "RTL template": This is a vector of incomplete RTL expressions 21887 which describe the semantics of the instruction (*note RTL 21888 Template::). It is incomplete because it may contain 21889 'match_operand', 'match_operator', and 'match_dup' expressions that 21890 stand for operands of the instruction. 21891 21892 If the vector has multiple elements, the RTL template is treated as 21893 a 'parallel' expression. 21894 21895 3. The condition: This is a string which contains a C expression. 21896 When the compiler attempts to match RTL against a pattern, the 21897 condition is evaluated. If the condition evaluates to 'true', the 21898 match is permitted. The condition may be an empty string, which is 21899 treated as always 'true'. 21900 21901 For a named pattern, the condition may not depend on the data in 21902 the insn being matched, but only the target-machine-type flags. 21903 The compiler needs to test these conditions during initialization 21904 in order to learn exactly which named instructions are available in 21905 a particular run. 21906 21907 For nameless patterns, the condition is applied only when matching 21908 an individual insn, and only after the insn has matched the 21909 pattern's recognition template. The insn's operands may be found 21910 in the vector 'operands'. 21911 21912 An instruction condition cannot become more restrictive as 21913 compilation progresses. If the condition accepts a particular RTL 21914 instruction at one stage of compilation, it must continue to accept 21915 that instruction until the final pass. For example, 21916 '!reload_completed' and 'can_create_pseudo_p ()' are both invalid 21917 instruction conditions, because they are true during the earlier 21918 RTL passes and false during the later ones. For the same reason, 21919 if a condition accepts an instruction before register allocation, 21920 it cannot later try to control register allocation by excluding 21921 certain register or value combinations. 21922 21923 Although a condition cannot become more restrictive as compilation 21924 progresses, the condition for a nameless pattern _can_ become more 21925 permissive. For example, a nameless instruction can require 21926 'reload_completed' to be true, in which case it only matches after 21927 register allocation. 21928 21929 4. The "output template" or "output statement": This is either a 21930 string, or a fragment of C code which returns a string. 21931 21932 When simple substitution isn't general enough, you can specify a 21933 piece of C code to compute the output. *Note Output Statement::. 21934 21935 5. The "insn attributes": This is an optional vector containing the 21936 values of attributes for insns matching this pattern (*note Insn 21937 Attributes::). 21938 21939 21940File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 21941 2194217.3 Example of 'define_insn' 21943============================= 21944 21945Here is an example of an instruction pattern, taken from the machine 21946description for the 68000/68020. 21947 21948 (define_insn "tstsi" 21949 [(set (cc0) 21950 (match_operand:SI 0 "general_operand" "rm"))] 21951 "" 21952 "* 21953 { 21954 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 21955 return \"tstl %0\"; 21956 return \"cmpl #0,%0\"; 21957 }") 21958 21959This can also be written using braced strings: 21960 21961 (define_insn "tstsi" 21962 [(set (cc0) 21963 (match_operand:SI 0 "general_operand" "rm"))] 21964 "" 21965 { 21966 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 21967 return "tstl %0"; 21968 return "cmpl #0,%0"; 21969 }) 21970 21971 This describes an instruction which sets the condition codes based on 21972the value of a general operand. It has no condition, so any insn with 21973an RTL description of the form shown may be matched to this pattern. 21974The name 'tstsi' means "test a 'SImode' value" and tells the RTL 21975generation pass that, when it is necessary to test such a value, an insn 21976to do so can be constructed using this pattern. 21977 21978 The output control string is a piece of C code which chooses which 21979output template to return based on the kind of operand and the specific 21980type of CPU for which code is being generated. 21981 21982 '"rm"' is an operand constraint. Its meaning is explained below. 21983 21984 21985File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 21986 2198717.4 RTL Template 21988================= 21989 21990The RTL template is used to define which insns match the particular 21991pattern and how to find their operands. For named patterns, the RTL 21992template also says how to construct an insn from specified operands. 21993 21994 Construction involves substituting specified operands into a copy of 21995the template. Matching involves determining the values that serve as 21996the operands in the insn being matched. Both of these activities are 21997controlled by special expression types that direct matching and 21998substitution of the operands. 21999 22000'(match_operand:M N PREDICATE CONSTRAINT)' 22001 This expression is a placeholder for operand number N of the insn. 22002 When constructing an insn, operand number N will be substituted at 22003 this point. When matching an insn, whatever appears at this 22004 position in the insn will be taken as operand number N; but it must 22005 satisfy PREDICATE or this instruction pattern will not match at 22006 all. 22007 22008 Operand numbers must be chosen consecutively counting from zero in 22009 each instruction pattern. There may be only one 'match_operand' 22010 expression in the pattern for each operand number. Usually 22011 operands are numbered in the order of appearance in 'match_operand' 22012 expressions. In the case of a 'define_expand', any operand numbers 22013 used only in 'match_dup' expressions have higher values than all 22014 other operand numbers. 22015 22016 PREDICATE is a string that is the name of a function that accepts 22017 two arguments, an expression and a machine mode. *Note 22018 Predicates::. During matching, the function will be called with 22019 the putative operand as the expression and M as the mode argument 22020 (if M is not specified, 'VOIDmode' will be used, which normally 22021 causes PREDICATE to accept any mode). If it returns zero, this 22022 instruction pattern fails to match. PREDICATE may be an empty 22023 string; then it means no test is to be done on the operand, so 22024 anything which occurs in this position is valid. 22025 22026 Most of the time, PREDICATE will reject modes other than M--but not 22027 always. For example, the predicate 'address_operand' uses M as the 22028 mode of memory ref that the address should be valid for. Many 22029 predicates accept 'const_int' nodes even though their mode is 22030 'VOIDmode'. 22031 22032 CONSTRAINT controls reloading and the choice of the best register 22033 class to use for a value, as explained later (*note Constraints::). 22034 If the constraint would be an empty string, it can be omitted. 22035 22036 People are often unclear on the difference between the constraint 22037 and the predicate. The predicate helps decide whether a given insn 22038 matches the pattern. The constraint plays no role in this 22039 decision; instead, it controls various decisions in the case of an 22040 insn which does match. 22041 22042'(match_scratch:M N CONSTRAINT)' 22043 This expression is also a placeholder for operand number N and 22044 indicates that operand must be a 'scratch' or 'reg' expression. 22045 22046 When matching patterns, this is equivalent to 22047 22048 (match_operand:M N "scratch_operand" CONSTRAINT) 22049 22050 but, when generating RTL, it produces a ('scratch':M) expression. 22051 22052 If the last few expressions in a 'parallel' are 'clobber' 22053 expressions whose operands are either a hard register or 22054 'match_scratch', the combiner can add or delete them when 22055 necessary. *Note Side Effects::. 22056 22057'(match_dup N)' 22058 This expression is also a placeholder for operand number N. It is 22059 used when the operand needs to appear more than once in the insn. 22060 22061 In construction, 'match_dup' acts just like 'match_operand': the 22062 operand is substituted into the insn being constructed. But in 22063 matching, 'match_dup' behaves differently. It assumes that operand 22064 number N has already been determined by a 'match_operand' appearing 22065 earlier in the recognition template, and it matches only an 22066 identical-looking expression. 22067 22068 Note that 'match_dup' should not be used to tell the compiler that 22069 a particular register is being used for two operands (example: 22070 'add' that adds one register to another; the second register is 22071 both an input operand and the output operand). Use a matching 22072 constraint (*note Simple Constraints::) for those. 'match_dup' is 22073 for the cases where one operand is used in two places in the 22074 template, such as an instruction that computes both a quotient and 22075 a remainder, where the opcode takes two input operands but the RTL 22076 template has to refer to each of those twice; once for the quotient 22077 pattern and once for the remainder pattern. 22078 22079'(match_operator:M N PREDICATE [OPERANDS...])' 22080 This pattern is a kind of placeholder for a variable RTL expression 22081 code. 22082 22083 When constructing an insn, it stands for an RTL expression whose 22084 expression code is taken from that of operand N, and whose operands 22085 are constructed from the patterns OPERANDS. 22086 22087 When matching an expression, it matches an expression if the 22088 function PREDICATE returns nonzero on that expression _and_ the 22089 patterns OPERANDS match the operands of the expression. 22090 22091 Suppose that the function 'commutative_operator' is defined as 22092 follows, to match any expression whose operator is one of the 22093 commutative arithmetic operators of RTL and whose mode is MODE: 22094 22095 int 22096 commutative_integer_operator (x, mode) 22097 rtx x; 22098 machine_mode mode; 22099 { 22100 enum rtx_code code = GET_CODE (x); 22101 if (GET_MODE (x) != mode) 22102 return 0; 22103 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 22104 || code == EQ || code == NE); 22105 } 22106 22107 Then the following pattern will match any RTL expression consisting 22108 of a commutative operator applied to two general operands: 22109 22110 (match_operator:SI 3 "commutative_operator" 22111 [(match_operand:SI 1 "general_operand" "g") 22112 (match_operand:SI 2 "general_operand" "g")]) 22113 22114 Here the vector '[OPERANDS...]' contains two patterns because the 22115 expressions to be matched all contain two operands. 22116 22117 When this pattern does match, the two operands of the commutative 22118 operator are recorded as operands 1 and 2 of the insn. (This is 22119 done by the two instances of 'match_operand'.) Operand 3 of the 22120 insn will be the entire commutative expression: use 'GET_CODE 22121 (operands[3])' to see which commutative operator was used. 22122 22123 The machine mode M of 'match_operator' works like that of 22124 'match_operand': it is passed as the second argument to the 22125 predicate function, and that function is solely responsible for 22126 deciding whether the expression to be matched "has" that mode. 22127 22128 When constructing an insn, argument 3 of the gen-function will 22129 specify the operation (i.e. the expression code) for the expression 22130 to be made. It should be an RTL expression, whose expression code 22131 is copied into a new expression whose operands are arguments 1 and 22132 2 of the gen-function. The subexpressions of argument 3 are not 22133 used; only its expression code matters. 22134 22135 When 'match_operator' is used in a pattern for matching an insn, it 22136 usually best if the operand number of the 'match_operator' is 22137 higher than that of the actual operands of the insn. This improves 22138 register allocation because the register allocator often looks at 22139 operands 1 and 2 of insns to see if it can do register tying. 22140 22141 There is no way to specify constraints in 'match_operator'. The 22142 operand of the insn which corresponds to the 'match_operator' never 22143 has any constraints because it is never reloaded as a whole. 22144 However, if parts of its OPERANDS are matched by 'match_operand' 22145 patterns, those parts may have constraints of their own. 22146 22147'(match_op_dup:M N[OPERANDS...])' 22148 Like 'match_dup', except that it applies to operators instead of 22149 operands. When constructing an insn, operand number N will be 22150 substituted at this point. But in matching, 'match_op_dup' behaves 22151 differently. It assumes that operand number N has already been 22152 determined by a 'match_operator' appearing earlier in the 22153 recognition template, and it matches only an identical-looking 22154 expression. 22155 22156'(match_parallel N PREDICATE [SUBPAT...])' 22157 This pattern is a placeholder for an insn that consists of a 22158 'parallel' expression with a variable number of elements. This 22159 expression should only appear at the top level of an insn pattern. 22160 22161 When constructing an insn, operand number N will be substituted at 22162 this point. When matching an insn, it matches if the body of the 22163 insn is a 'parallel' expression with at least as many elements as 22164 the vector of SUBPAT expressions in the 'match_parallel', if each 22165 SUBPAT matches the corresponding element of the 'parallel', _and_ 22166 the function PREDICATE returns nonzero on the 'parallel' that is 22167 the body of the insn. It is the responsibility of the predicate to 22168 validate elements of the 'parallel' beyond those listed in the 22169 'match_parallel'. 22170 22171 A typical use of 'match_parallel' is to match load and store 22172 multiple expressions, which can contain a variable number of 22173 elements in a 'parallel'. For example, 22174 22175 (define_insn "" 22176 [(match_parallel 0 "load_multiple_operation" 22177 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 22178 (match_operand:SI 2 "memory_operand" "m")) 22179 (use (reg:SI 179)) 22180 (clobber (reg:SI 179))])] 22181 "" 22182 "loadm 0,0,%1,%2") 22183 22184 This example comes from 'a29k.md'. The function 22185 'load_multiple_operation' is defined in 'a29k.c' and checks that 22186 subsequent elements in the 'parallel' are the same as the 'set' in 22187 the pattern, except that they are referencing subsequent registers 22188 and memory locations. 22189 22190 An insn that matches this pattern might look like: 22191 22192 (parallel 22193 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 22194 (use (reg:SI 179)) 22195 (clobber (reg:SI 179)) 22196 (set (reg:SI 21) 22197 (mem:SI (plus:SI (reg:SI 100) 22198 (const_int 4)))) 22199 (set (reg:SI 22) 22200 (mem:SI (plus:SI (reg:SI 100) 22201 (const_int 8))))]) 22202 22203'(match_par_dup N [SUBPAT...])' 22204 Like 'match_op_dup', but for 'match_parallel' instead of 22205 'match_operator'. 22206 22207 22208File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 22209 2221017.5 Output Templates and Operand Substitution 22211============================================== 22212 22213The "output template" is a string which specifies how to output the 22214assembler code for an instruction pattern. Most of the template is a 22215fixed string which is output literally. The character '%' is used to 22216specify where to substitute an operand; it can also be used to identify 22217places where different variants of the assembler require different 22218syntax. 22219 22220 In the simplest case, a '%' followed by a digit N says to output 22221operand N at that point in the string. 22222 22223 '%' followed by a letter and a digit says to output an operand in an 22224alternate fashion. Four letters have standard, built-in meanings 22225described below. The machine description macro 'PRINT_OPERAND' can 22226define additional letters with nonstandard meanings. 22227 22228 '%cDIGIT' can be used to substitute an operand that is a constant value 22229without the syntax that normally indicates an immediate operand. 22230 22231 '%nDIGIT' is like '%cDIGIT' except that the value of the constant is 22232negated before printing. 22233 22234 '%aDIGIT' can be used to substitute an operand as if it were a memory 22235reference, with the actual operand treated as the address. This may be 22236useful when outputting a "load address" instruction, because often the 22237assembler syntax for such an instruction requires you to write the 22238operand as if it were a memory reference. 22239 22240 '%lDIGIT' is used to substitute a 'label_ref' into a jump instruction. 22241 22242 '%=' outputs a number which is unique to each instruction in the entire 22243compilation. This is useful for making local labels to be referred to 22244more than once in a single template that generates multiple assembler 22245instructions. 22246 22247 '%' followed by a punctuation character specifies a substitution that 22248does not use an operand. Only one case is standard: '%%' outputs a '%' 22249into the assembler code. Other nonstandard cases can be defined in the 22250'PRINT_OPERAND' macro. You must also define which punctuation 22251characters are valid with the 'PRINT_OPERAND_PUNCT_VALID_P' macro. 22252 22253 The template may generate multiple assembler instructions. Write the 22254text for the instructions, with '\;' between them. 22255 22256 When the RTL contains two operands which are required by constraint to 22257match each other, the output template must refer only to the 22258lower-numbered operand. Matching operands are not always identical, and 22259the rest of the compiler arranges to put the proper RTL expression for 22260printing into the lower-numbered operand. 22261 22262 One use of nonstandard letters or punctuation following '%' is to 22263distinguish between different assembler languages for the same machine; 22264for example, Motorola syntax versus MIT syntax for the 68000. Motorola 22265syntax requires periods in most opcode names, while MIT syntax does not. 22266For example, the opcode 'movel' in MIT syntax is 'move.l' in Motorola 22267syntax. The same file of patterns is used for both kinds of output 22268syntax, but the character sequence '%.' is used in each place where 22269Motorola syntax wants a period. The 'PRINT_OPERAND' macro for Motorola 22270syntax defines the sequence to output a period; the macro for MIT syntax 22271defines it to do nothing. 22272 22273 As a special case, a template consisting of the single character '#' 22274instructs the compiler to first split the insn, and then output the 22275resulting instructions separately. This helps eliminate redundancy in 22276the output templates. If you have a 'define_insn' that needs to emit 22277multiple assembler instructions, and there is a matching 'define_split' 22278already defined, then you can simply use '#' as the output template 22279instead of writing an output template that emits the multiple assembler 22280instructions. 22281 22282 Note that '#' only has an effect while generating assembly code; it 22283does not affect whether a split occurs earlier. An associated 22284'define_split' must exist and it must be suitable for use after register 22285allocation. 22286 22287 If the macro 'ASSEMBLER_DIALECT' is defined, you can use construct of 22288the form '{option0|option1|option2}' in the templates. These describe 22289multiple variants of assembler language syntax. *Note Instruction 22290Output::. 22291 22292 22293File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 22294 2229517.6 C Statements for Assembler Output 22296====================================== 22297 22298Often a single fixed template string cannot produce correct and 22299efficient assembler code for all the cases that are recognized by a 22300single instruction pattern. For example, the opcodes may depend on the 22301kinds of operands; or some unfortunate combinations of operands may 22302require extra machine instructions. 22303 22304 If the output control string starts with a '@', then it is actually a 22305series of templates, each on a separate line. (Blank lines and leading 22306spaces and tabs are ignored.) The templates correspond to the pattern's 22307constraint alternatives (*note Multi-Alternative::). For example, if a 22308target machine has a two-address add instruction 'addr' to add into a 22309register and another 'addm' to add a register to memory, you might write 22310this pattern: 22311 22312 (define_insn "addsi3" 22313 [(set (match_operand:SI 0 "general_operand" "=r,m") 22314 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 22315 (match_operand:SI 2 "general_operand" "g,r")))] 22316 "" 22317 "@ 22318 addr %2,%0 22319 addm %2,%0") 22320 22321 If the output control string starts with a '*', then it is not an 22322output template but rather a piece of C program that should compute a 22323template. It should execute a 'return' statement to return the 22324template-string you want. Most such templates use C string literals, 22325which require doublequote characters to delimit them. To include these 22326doublequote characters in the string, prefix each one with '\'. 22327 22328 If the output control string is written as a brace block instead of a 22329double-quoted string, it is automatically assumed to be C code. In that 22330case, it is not necessary to put in a leading asterisk, or to escape the 22331doublequotes surrounding C string literals. 22332 22333 The operands may be found in the array 'operands', whose C data type is 22334'rtx []'. 22335 22336 It is very common to select different ways of generating assembler code 22337based on whether an immediate operand is within a certain range. Be 22338careful when doing this, because the result of 'INTVAL' is an integer on 22339the host machine. If the host machine has more bits in an 'int' than 22340the target machine has in the mode in which the constant will be used, 22341then some of the bits you get from 'INTVAL' will be superfluous. For 22342proper results, you must carefully disregard the values of those bits. 22343 22344 It is possible to output an assembler instruction and then go on to 22345output or compute more of them, using the subroutine 'output_asm_insn'. 22346This receives two arguments: a template-string and a vector of operands. 22347The vector may be 'operands', or it may be another array of 'rtx' that 22348you declare locally and initialize yourself. 22349 22350 When an insn pattern has multiple alternatives in its constraints, 22351often the appearance of the assembler code is determined mostly by which 22352alternative was matched. When this is so, the C code can test the 22353variable 'which_alternative', which is the ordinal number of the 22354alternative that was actually satisfied (0 for the first, 1 for the 22355second alternative, etc.). 22356 22357 For example, suppose there are two opcodes for storing zero, 'clrreg' 22358for registers and 'clrmem' for memory locations. Here is how a pattern 22359could use 'which_alternative' to choose between them: 22360 22361 (define_insn "" 22362 [(set (match_operand:SI 0 "general_operand" "=r,m") 22363 (const_int 0))] 22364 "" 22365 { 22366 return (which_alternative == 0 22367 ? "clrreg %0" : "clrmem %0"); 22368 }) 22369 22370 The example above, where the assembler code to generate was _solely_ 22371determined by the alternative, could also have been specified as 22372follows, having the output control string start with a '@': 22373 22374 (define_insn "" 22375 [(set (match_operand:SI 0 "general_operand" "=r,m") 22376 (const_int 0))] 22377 "" 22378 "@ 22379 clrreg %0 22380 clrmem %0") 22381 22382 If you just need a little bit of C code in one (or a few) alternatives, 22383you can use '*' inside of a '@' multi-alternative template: 22384 22385 (define_insn "" 22386 [(set (match_operand:SI 0 "general_operand" "=r,<,m") 22387 (const_int 0))] 22388 "" 22389 "@ 22390 clrreg %0 22391 * return stack_mem_p (operands[0]) ? \"push 0\" : \"clrmem %0\"; 22392 clrmem %0") 22393 22394 22395File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 22396 2239717.7 Predicates 22398=============== 22399 22400A predicate determines whether a 'match_operand' or 'match_operator' 22401expression matches, and therefore whether the surrounding instruction 22402pattern will be used for that combination of operands. GCC has a number 22403of machine-independent predicates, and you can define machine-specific 22404predicates as needed. By convention, predicates used with 22405'match_operand' have names that end in '_operand', and those used with 22406'match_operator' have names that end in '_operator'. 22407 22408 All predicates are boolean functions (in the mathematical sense) of two 22409arguments: the RTL expression that is being considered at that position 22410in the instruction pattern, and the machine mode that the 22411'match_operand' or 'match_operator' specifies. In this section, the 22412first argument is called OP and the second argument MODE. Predicates 22413can be called from C as ordinary two-argument functions; this can be 22414useful in output templates or other machine-specific code. 22415 22416 Operand predicates can allow operands that are not actually acceptable 22417to the hardware, as long as the constraints give reload the ability to 22418fix them up (*note Constraints::). However, GCC will usually generate 22419better code if the predicates specify the requirements of the machine 22420instructions as closely as possible. Reload cannot fix up operands that 22421must be constants ("immediate operands"); you must use a predicate that 22422allows only constants, or else enforce the requirement in the extra 22423condition. 22424 22425 Most predicates handle their MODE argument in a uniform manner. If 22426MODE is 'VOIDmode' (unspecified), then OP can have any mode. If MODE is 22427anything else, then OP must have the same mode, unless OP is a 22428'CONST_INT' or integer 'CONST_DOUBLE'. These RTL expressions always 22429have 'VOIDmode', so it would be counterproductive to check that their 22430mode matches. Instead, predicates that accept 'CONST_INT' and/or 22431integer 'CONST_DOUBLE' check that the value stored in the constant will 22432fit in the requested mode. 22433 22434 Predicates with this behavior are called "normal". 'genrecog' can 22435optimize the instruction recognizer based on knowledge of how normal 22436predicates treat modes. It can also diagnose certain kinds of common 22437errors in the use of normal predicates; for instance, it is almost 22438always an error to use a normal predicate without specifying a mode. 22439 22440 Predicates that do something different with their MODE argument are 22441called "special". The generic predicates 'address_operand' and 22442'pmode_register_operand' are special predicates. 'genrecog' does not do 22443any optimizations or diagnosis when special predicates are used. 22444 22445* Menu: 22446 22447* Machine-Independent Predicates:: Predicates available to all back ends. 22448* Defining Predicates:: How to write machine-specific predicate 22449 functions. 22450 22451 22452File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 22453 2245417.7.1 Machine-Independent Predicates 22455------------------------------------- 22456 22457These are the generic predicates available to all back ends. They are 22458defined in 'recog.c'. The first category of predicates allow only 22459constant, or "immediate", operands. 22460 22461 -- Function: immediate_operand 22462 This predicate allows any sort of constant that fits in MODE. It 22463 is an appropriate choice for instructions that take operands that 22464 must be constant. 22465 22466 -- Function: const_int_operand 22467 This predicate allows any 'CONST_INT' expression that fits in MODE. 22468 It is an appropriate choice for an immediate operand that does not 22469 allow a symbol or label. 22470 22471 -- Function: const_double_operand 22472 This predicate accepts any 'CONST_DOUBLE' expression that has 22473 exactly MODE. If MODE is 'VOIDmode', it will also accept 22474 'CONST_INT'. It is intended for immediate floating point 22475 constants. 22476 22477The second category of predicates allow only some kind of machine 22478register. 22479 22480 -- Function: register_operand 22481 This predicate allows any 'REG' or 'SUBREG' expression that is 22482 valid for MODE. It is often suitable for arithmetic instruction 22483 operands on a RISC machine. 22484 22485 -- Function: pmode_register_operand 22486 This is a slight variant on 'register_operand' which works around a 22487 limitation in the machine-description reader. 22488 22489 (match_operand N "pmode_register_operand" CONSTRAINT) 22490 22491 means exactly what 22492 22493 (match_operand:P N "register_operand" CONSTRAINT) 22494 22495 would mean, if the machine-description reader accepted ':P' mode 22496 suffixes. Unfortunately, it cannot, because 'Pmode' is an alias 22497 for some other mode, and might vary with machine-specific options. 22498 *Note Misc::. 22499 22500 -- Function: scratch_operand 22501 This predicate allows hard registers and 'SCRATCH' expressions, but 22502 not pseudo-registers. It is used internally by 'match_scratch'; it 22503 should not be used directly. 22504 22505The third category of predicates allow only some kind of memory 22506reference. 22507 22508 -- Function: memory_operand 22509 This predicate allows any valid reference to a quantity of mode 22510 MODE in memory, as determined by the weak form of 22511 'GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 22512 22513 -- Function: address_operand 22514 This predicate is a little unusual; it allows any operand that is a 22515 valid expression for the _address_ of a quantity of mode MODE, 22516 again determined by the weak form of 'GO_IF_LEGITIMATE_ADDRESS'. 22517 To first order, if '(mem:MODE (EXP))' is acceptable to 22518 'memory_operand', then EXP is acceptable to 'address_operand'. 22519 Note that EXP does not necessarily have the mode MODE. 22520 22521 -- Function: indirect_operand 22522 This is a stricter form of 'memory_operand' which allows only 22523 memory references with a 'general_operand' as the address 22524 expression. New uses of this predicate are discouraged, because 22525 'general_operand' is very permissive, so it's hard to tell what an 22526 'indirect_operand' does or does not allow. If a target has 22527 different requirements for memory operands for different 22528 instructions, it is better to define target-specific predicates 22529 which enforce the hardware's requirements explicitly. 22530 22531 -- Function: push_operand 22532 This predicate allows a memory reference suitable for pushing a 22533 value onto the stack. This will be a 'MEM' which refers to 22534 'stack_pointer_rtx', with a side effect in its address expression 22535 (*note Incdec::); which one is determined by the 'STACK_PUSH_CODE' 22536 macro (*note Frame Layout::). 22537 22538 -- Function: pop_operand 22539 This predicate allows a memory reference suitable for popping a 22540 value off the stack. Again, this will be a 'MEM' referring to 22541 'stack_pointer_rtx', with a side effect in its address expression. 22542 However, this time 'STACK_POP_CODE' is expected. 22543 22544The fourth category of predicates allow some combination of the above 22545operands. 22546 22547 -- Function: nonmemory_operand 22548 This predicate allows any immediate or register operand valid for 22549 MODE. 22550 22551 -- Function: nonimmediate_operand 22552 This predicate allows any register or memory operand valid for 22553 MODE. 22554 22555 -- Function: general_operand 22556 This predicate allows any immediate, register, or memory operand 22557 valid for MODE. 22558 22559Finally, there are two generic operator predicates. 22560 22561 -- Function: comparison_operator 22562 This predicate matches any expression which performs an arithmetic 22563 comparison in MODE; that is, 'COMPARISON_P' is true for the 22564 expression code. 22565 22566 -- Function: ordered_comparison_operator 22567 This predicate matches any expression which performs an arithmetic 22568 comparison in MODE and whose expression code is valid for integer 22569 modes; that is, the expression code will be one of 'eq', 'ne', 22570 'lt', 'ltu', 'le', 'leu', 'gt', 'gtu', 'ge', 'geu'. 22571 22572 22573File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 22574 2257517.7.2 Defining Machine-Specific Predicates 22576------------------------------------------- 22577 22578Many machines have requirements for their operands that cannot be 22579expressed precisely using the generic predicates. You can define 22580additional predicates using 'define_predicate' and 22581'define_special_predicate' expressions. These expressions have three 22582operands: 22583 22584 * The name of the predicate, as it will be referred to in 22585 'match_operand' or 'match_operator' expressions. 22586 22587 * An RTL expression which evaluates to true if the predicate allows 22588 the operand OP, false if it does not. This expression can only use 22589 the following RTL codes: 22590 22591 'MATCH_OPERAND' 22592 When written inside a predicate expression, a 'MATCH_OPERAND' 22593 expression evaluates to true if the predicate it names would 22594 allow OP. The operand number and constraint are ignored. Due 22595 to limitations in 'genrecog', you can only refer to generic 22596 predicates and predicates that have already been defined. 22597 22598 'MATCH_CODE' 22599 This expression evaluates to true if OP or a specified 22600 subexpression of OP has one of a given list of RTX codes. 22601 22602 The first operand of this expression is a string constant 22603 containing a comma-separated list of RTX code names (in lower 22604 case). These are the codes for which the 'MATCH_CODE' will be 22605 true. 22606 22607 The second operand is a string constant which indicates what 22608 subexpression of OP to examine. If it is absent or the empty 22609 string, OP itself is examined. Otherwise, the string constant 22610 must be a sequence of digits and/or lowercase letters. Each 22611 character indicates a subexpression to extract from the 22612 current expression; for the first character this is OP, for 22613 the second and subsequent characters it is the result of the 22614 previous character. A digit N extracts 'XEXP (E, N)'; a 22615 letter L extracts 'XVECEXP (E, 0, N)' where N is the 22616 alphabetic ordinal of L (0 for 'a', 1 for 'b', and so on). 22617 The 'MATCH_CODE' then examines the RTX code of the 22618 subexpression extracted by the complete string. It is not 22619 possible to extract components of an 'rtvec' that is not at 22620 position 0 within its RTX object. 22621 22622 'MATCH_TEST' 22623 This expression has one operand, a string constant containing 22624 a C expression. The predicate's arguments, OP and MODE, are 22625 available with those names in the C expression. The 22626 'MATCH_TEST' evaluates to true if the C expression evaluates 22627 to a nonzero value. 'MATCH_TEST' expressions must not have 22628 side effects. 22629 22630 'AND' 22631 'IOR' 22632 'NOT' 22633 'IF_THEN_ELSE' 22634 The basic 'MATCH_' expressions can be combined using these 22635 logical operators, which have the semantics of the C operators 22636 '&&', '||', '!', and '? :' respectively. As in Common Lisp, 22637 you may give an 'AND' or 'IOR' expression an arbitrary number 22638 of arguments; this has exactly the same effect as writing a 22639 chain of two-argument 'AND' or 'IOR' expressions. 22640 22641 * An optional block of C code, which should execute 'return true' if 22642 the predicate is found to match and 'return false' if it does not. 22643 It must not have any side effects. The predicate arguments, OP and 22644 MODE, are available with those names. 22645 22646 If a code block is present in a predicate definition, then the RTL 22647 expression must evaluate to true _and_ the code block must execute 22648 'return true' for the predicate to allow the operand. The RTL 22649 expression is evaluated first; do not re-check anything in the code 22650 block that was checked in the RTL expression. 22651 22652 The program 'genrecog' scans 'define_predicate' and 22653'define_special_predicate' expressions to determine which RTX codes are 22654possibly allowed. You should always make this explicit in the RTL 22655predicate expression, using 'MATCH_OPERAND' and 'MATCH_CODE'. 22656 22657 Here is an example of a simple predicate definition, from the IA64 22658machine description: 22659 22660 ;; True if OP is a 'SYMBOL_REF' which refers to the sdata section. 22661 (define_predicate "small_addr_symbolic_operand" 22662 (and (match_code "symbol_ref") 22663 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 22664 22665And here is another, showing the use of the C block. 22666 22667 ;; True if OP is a register operand that is (or could be) a GR reg. 22668 (define_predicate "gr_register_operand" 22669 (match_operand 0 "register_operand") 22670 { 22671 unsigned int regno; 22672 if (GET_CODE (op) == SUBREG) 22673 op = SUBREG_REG (op); 22674 22675 regno = REGNO (op); 22676 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 22677 }) 22678 22679 Predicates written with 'define_predicate' automatically include a test 22680that MODE is 'VOIDmode', or OP has the same mode as MODE, or OP is a 22681'CONST_INT' or 'CONST_DOUBLE'. They do _not_ check specifically for 22682integer 'CONST_DOUBLE', nor do they test that the value of either kind 22683of constant fits in the requested mode. This is because target-specific 22684predicates that take constants usually have to do more stringent value 22685checks anyway. If you need the exact same treatment of 'CONST_INT' or 22686'CONST_DOUBLE' that the generic predicates provide, use a 22687'MATCH_OPERAND' subexpression to call 'const_int_operand', 22688'const_double_operand', or 'immediate_operand'. 22689 22690 Predicates written with 'define_special_predicate' do not get any 22691automatic mode checks, and are treated as having special mode handling 22692by 'genrecog'. 22693 22694 The program 'genpreds' is responsible for generating code to test 22695predicates. It also writes a header file containing function 22696declarations for all machine-specific predicates. It is not necessary 22697to declare these predicates in 'CPU-protos.h'. 22698 22699 22700File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 22701 2270217.8 Operand Constraints 22703======================== 22704 22705Each 'match_operand' in an instruction pattern can specify constraints 22706for the operands allowed. The constraints allow you to fine-tune 22707matching within the set of operands allowed by the predicate. 22708 22709 Constraints can say whether an operand may be in a register, and which 22710kinds of register; whether the operand can be a memory reference, and 22711which kinds of address; whether the operand may be an immediate 22712constant, and which possible values it may have. Constraints can also 22713require two operands to match. Side-effects aren't allowed in operands 22714of inline 'asm', unless '<' or '>' constraints are used, because there 22715is no guarantee that the side effects will happen exactly once in an 22716instruction that can update the addressing register. 22717 22718* Menu: 22719 22720* Simple Constraints:: Basic use of constraints. 22721* Multi-Alternative:: When an insn has two alternative constraint-patterns. 22722* Class Preferences:: Constraints guide which hard register to put things in. 22723* Modifiers:: More precise control over effects of constraints. 22724* Machine Constraints:: Existing constraints for some particular machines. 22725* Disable Insn Alternatives:: Disable insn alternatives using attributes. 22726* Define Constraints:: How to define machine-specific constraints. 22727* C Constraint Interface:: How to test constraints from C code. 22728 22729 22730File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 22731 2273217.8.1 Simple Constraints 22733------------------------- 22734 22735The simplest kind of constraint is a string full of letters, each of 22736which describes one kind of operand that is permitted. Here are the 22737letters that are allowed: 22738 22739whitespace 22740 Whitespace characters are ignored and can be inserted at any 22741 position except the first. This enables each alternative for 22742 different operands to be visually aligned in the machine 22743 description even if they have different number of constraints and 22744 modifiers. 22745 22746'm' 22747 A memory operand is allowed, with any kind of address that the 22748 machine supports in general. Note that the letter used for the 22749 general memory constraint can be re-defined by a back end using the 22750 'TARGET_MEM_CONSTRAINT' macro. 22751 22752'o' 22753 A memory operand is allowed, but only if the address is 22754 "offsettable". This means that adding a small integer (actually, 22755 the width in bytes of the operand, as determined by its machine 22756 mode) may be added to the address and the result is also a valid 22757 memory address. 22758 22759 For example, an address which is constant is offsettable; so is an 22760 address that is the sum of a register and a constant (as long as a 22761 slightly larger constant is also within the range of 22762 address-offsets supported by the machine); but an autoincrement or 22763 autodecrement address is not offsettable. More complicated 22764 indirect/indexed addresses may or may not be offsettable depending 22765 on the other addressing modes that the machine supports. 22766 22767 Note that in an output operand which can be matched by another 22768 operand, the constraint letter 'o' is valid only when accompanied 22769 by both '<' (if the target machine has predecrement addressing) and 22770 '>' (if the target machine has preincrement addressing). 22771 22772'V' 22773 A memory operand that is not offsettable. In other words, anything 22774 that would fit the 'm' constraint but not the 'o' constraint. 22775 22776'<' 22777 A memory operand with autodecrement addressing (either predecrement 22778 or postdecrement) is allowed. In inline 'asm' this constraint is 22779 only allowed if the operand is used exactly once in an instruction 22780 that can handle the side effects. Not using an operand with '<' in 22781 constraint string in the inline 'asm' pattern at all or using it in 22782 multiple instructions isn't valid, because the side effects 22783 wouldn't be performed or would be performed more than once. 22784 Furthermore, on some targets the operand with '<' in constraint 22785 string must be accompanied by special instruction suffixes like 22786 '%U0' instruction suffix on PowerPC or '%P0' on IA-64. 22787 22788'>' 22789 A memory operand with autoincrement addressing (either preincrement 22790 or postincrement) is allowed. In inline 'asm' the same 22791 restrictions as for '<' apply. 22792 22793'r' 22794 A register operand is allowed provided that it is in a general 22795 register. 22796 22797'i' 22798 An immediate integer operand (one with constant value) is allowed. 22799 This includes symbolic constants whose values will be known only at 22800 assembly time or later. 22801 22802'n' 22803 An immediate integer operand with a known numeric value is allowed. 22804 Many systems cannot support assembly-time constants for operands 22805 less than a word wide. Constraints for these operands should use 22806 'n' rather than 'i'. 22807 22808'I', 'J', 'K', ... 'P' 22809 Other letters in the range 'I' through 'P' may be defined in a 22810 machine-dependent fashion to permit immediate integer operands with 22811 explicit integer values in specified ranges. For example, on the 22812 68000, 'I' is defined to stand for the range of values 1 to 8. 22813 This is the range permitted as a shift count in the shift 22814 instructions. 22815 22816'E' 22817 An immediate floating operand (expression code 'const_double') is 22818 allowed, but only if the target floating point format is the same 22819 as that of the host machine (on which the compiler is running). 22820 22821'F' 22822 An immediate floating operand (expression code 'const_double' or 22823 'const_vector') is allowed. 22824 22825'G', 'H' 22826 'G' and 'H' may be defined in a machine-dependent fashion to permit 22827 immediate floating operands in particular ranges of values. 22828 22829's' 22830 An immediate integer operand whose value is not an explicit integer 22831 is allowed. 22832 22833 This might appear strange; if an insn allows a constant operand 22834 with a value not known at compile time, it certainly must allow any 22835 known value. So why use 's' instead of 'i'? Sometimes it allows 22836 better code to be generated. 22837 22838 For example, on the 68000 in a fullword instruction it is possible 22839 to use an immediate operand; but if the immediate value is between 22840 -128 and 127, better code results from loading the value into a 22841 register and using the register. This is because the load into the 22842 register can be done with a 'moveq' instruction. We arrange for 22843 this to happen by defining the letter 'K' to mean "any integer 22844 outside the range -128 to 127", and then specifying 'Ks' in the 22845 operand constraints. 22846 22847'g' 22848 Any register, memory or immediate integer operand is allowed, 22849 except for registers that are not general registers. 22850 22851'X' 22852 Any operand whatsoever is allowed, even if it does not satisfy 22853 'general_operand'. This is normally used in the constraint of a 22854 'match_scratch' when certain alternatives will not actually require 22855 a scratch register. 22856 22857'0', '1', '2', ... '9' 22858 An operand that matches the specified operand number is allowed. 22859 If a digit is used together with letters within the same 22860 alternative, the digit should come last. 22861 22862 This number is allowed to be more than a single digit. If multiple 22863 digits are encountered consecutively, they are interpreted as a 22864 single decimal integer. There is scant chance for ambiguity, since 22865 to-date it has never been desirable that '10' be interpreted as 22866 matching either operand 1 _or_ operand 0. Should this be desired, 22867 one can use multiple alternatives instead. 22868 22869 This is called a "matching constraint" and what it really means is 22870 that the assembler has only a single operand that fills two roles 22871 considered separate in the RTL insn. For example, an add insn has 22872 two input operands and one output operand in the RTL, but on most 22873 CISC machines an add instruction really has only two operands, one 22874 of them an input-output operand: 22875 22876 addl #35,r12 22877 22878 Matching constraints are used in these circumstances. More 22879 precisely, the two operands that match must include one input-only 22880 operand and one output-only operand. Moreover, the digit must be a 22881 smaller number than the number of the operand that uses it in the 22882 constraint. 22883 22884 For operands to match in a particular case usually means that they 22885 are identical-looking RTL expressions. But in a few special cases 22886 specific kinds of dissimilarity are allowed. For example, '*x' as 22887 an input operand will match '*x++' as an output operand. For 22888 proper results in such cases, the output template should always use 22889 the output-operand's number when printing the operand. 22890 22891'p' 22892 An operand that is a valid memory address is allowed. This is for 22893 "load address" and "push address" instructions. 22894 22895 'p' in the constraint must be accompanied by 'address_operand' as 22896 the predicate in the 'match_operand'. This predicate interprets 22897 the mode specified in the 'match_operand' as the mode of the memory 22898 reference for which the address would be valid. 22899 22900OTHER-LETTERS 22901 Other letters can be defined in machine-dependent fashion to stand 22902 for particular classes of registers or other arbitrary operand 22903 types. 'd', 'a' and 'f' are defined on the 68000/68020 to stand 22904 for data, address and floating point registers. 22905 22906 In order to have valid assembler code, each operand must satisfy its 22907constraint. But a failure to do so does not prevent the pattern from 22908applying to an insn. Instead, it directs the compiler to modify the 22909code so that the constraint will be satisfied. Usually this is done by 22910copying an operand into a register. 22911 22912 Contrast, therefore, the two instruction patterns that follow: 22913 22914 (define_insn "" 22915 [(set (match_operand:SI 0 "general_operand" "=r") 22916 (plus:SI (match_dup 0) 22917 (match_operand:SI 1 "general_operand" "r")))] 22918 "" 22919 "...") 22920 22921which has two operands, one of which must appear in two places, and 22922 22923 (define_insn "" 22924 [(set (match_operand:SI 0 "general_operand" "=r") 22925 (plus:SI (match_operand:SI 1 "general_operand" "0") 22926 (match_operand:SI 2 "general_operand" "r")))] 22927 "" 22928 "...") 22929 22930which has three operands, two of which are required by a constraint to 22931be identical. If we are considering an insn of the form 22932 22933 (insn N PREV NEXT 22934 (set (reg:SI 3) 22935 (plus:SI (reg:SI 6) (reg:SI 109))) 22936 ...) 22937 22938the first pattern would not apply at all, because this insn does not 22939contain two identical subexpressions in the right place. The pattern 22940would say, "That does not look like an add instruction; try other 22941patterns". The second pattern would say, "Yes, that's an add 22942instruction, but there is something wrong with it". It would direct the 22943reload pass of the compiler to generate additional insns to make the 22944constraint true. The results might look like this: 22945 22946 (insn N2 PREV N 22947 (set (reg:SI 3) (reg:SI 6)) 22948 ...) 22949 22950 (insn N N2 NEXT 22951 (set (reg:SI 3) 22952 (plus:SI (reg:SI 3) (reg:SI 109))) 22953 ...) 22954 22955 It is up to you to make sure that each operand, in each pattern, has 22956constraints that can handle any RTL expression that could be present for 22957that operand. (When multiple alternatives are in use, each pattern 22958must, for each possible combination of operand expressions, have at 22959least one alternative which can handle that combination of operands.) 22960The constraints don't need to _allow_ any possible operand--when this is 22961the case, they do not constrain--but they must at least point the way to 22962reloading any possible operand so that it will fit. 22963 22964 * If the constraint accepts whatever operands the predicate permits, 22965 there is no problem: reloading is never necessary for this operand. 22966 22967 For example, an operand whose constraints permit everything except 22968 registers is safe provided its predicate rejects registers. 22969 22970 An operand whose predicate accepts only constant values is safe 22971 provided its constraints include the letter 'i'. If any possible 22972 constant value is accepted, then nothing less than 'i' will do; if 22973 the predicate is more selective, then the constraints may also be 22974 more selective. 22975 22976 * Any operand expression can be reloaded by copying it into a 22977 register. So if an operand's constraints allow some kind of 22978 register, it is certain to be safe. It need not permit all classes 22979 of registers; the compiler knows how to copy a register into 22980 another register of the proper class in order to make an 22981 instruction valid. 22982 22983 * A nonoffsettable memory reference can be reloaded by copying the 22984 address into a register. So if the constraint uses the letter 'o', 22985 all memory references are taken care of. 22986 22987 * A constant operand can be reloaded by allocating space in memory to 22988 hold it as preinitialized data. Then the memory reference can be 22989 used in place of the constant. So if the constraint uses the 22990 letters 'o' or 'm', constant operands are not a problem. 22991 22992 * If the constraint permits a constant and a pseudo register used in 22993 an insn was not allocated to a hard register and is equivalent to a 22994 constant, the register will be replaced with the constant. If the 22995 predicate does not permit a constant and the insn is re-recognized 22996 for some reason, the compiler will crash. Thus the predicate must 22997 always recognize any objects allowed by the constraint. 22998 22999 If the operand's predicate can recognize registers, but the constraint 23000does not permit them, it can make the compiler crash. When this operand 23001happens to be a register, the reload pass will be stymied, because it 23002does not know how to copy a register temporarily into memory. 23003 23004 If the predicate accepts a unary operator, the constraint applies to 23005the operand. For example, the MIPS processor at ISA level 3 supports an 23006instruction which adds two registers in 'SImode' to produce a 'DImode' 23007result, but only if the registers are correctly sign extended. This 23008predicate for the input operands accepts a 'sign_extend' of an 'SImode' 23009register. Write the constraint to indicate the type of register that is 23010required for the operand of the 'sign_extend'. 23011 23012 23013File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 23014 2301517.8.2 Multiple Alternative Constraints 23016--------------------------------------- 23017 23018Sometimes a single instruction has multiple alternative sets of possible 23019operands. For example, on the 68000, a logical-or instruction can 23020combine register or an immediate value into memory, or it can combine 23021any kind of operand into a register; but it cannot combine one memory 23022location into another. 23023 23024 These constraints are represented as multiple alternatives. An 23025alternative can be described by a series of letters for each operand. 23026The overall constraint for an operand is made from the letters for this 23027operand from the first alternative, a comma, the letters for this 23028operand from the second alternative, a comma, and so on until the last 23029alternative. All operands for a single instruction must have the same 23030number of alternatives. Here is how it is done for fullword logical-or 23031on the 68000: 23032 23033 (define_insn "iorsi3" 23034 [(set (match_operand:SI 0 "general_operand" "=m,d") 23035 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 23036 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 23037 ...) 23038 23039 The first alternative has 'm' (memory) for operand 0, '0' for operand 1 23040(meaning it must match operand 0), and 'dKs' for operand 2. The second 23041alternative has 'd' (data register) for operand 0, '0' for operand 1, 23042and 'dmKs' for operand 2. The '=' and '%' in the constraints apply to 23043all the alternatives; their meaning is explained in the next section 23044(*note Class Preferences::). 23045 23046 If all the operands fit any one alternative, the instruction is valid. 23047Otherwise, for each alternative, the compiler counts how many 23048instructions must be added to copy the operands so that that alternative 23049applies. The alternative requiring the least copying is chosen. If two 23050alternatives need the same amount of copying, the one that comes first 23051is chosen. These choices can be altered with the '?' and '!' 23052characters: 23053 23054'?' 23055 Disparage slightly the alternative that the '?' appears in, as a 23056 choice when no alternative applies exactly. The compiler regards 23057 this alternative as one unit more costly for each '?' that appears 23058 in it. 23059 23060'!' 23061 Disparage severely the alternative that the '!' appears in. This 23062 alternative can still be used if it fits without reloading, but if 23063 reloading is needed, some other alternative will be used. 23064 23065'^' 23066 This constraint is analogous to '?' but it disparages slightly the 23067 alternative only if the operand with the '^' needs a reload. 23068 23069'$' 23070 This constraint is analogous to '!' but it disparages severely the 23071 alternative only if the operand with the '$' needs a reload. 23072 23073 When an insn pattern has multiple alternatives in its constraints, 23074often the appearance of the assembler code is determined mostly by which 23075alternative was matched. When this is so, the C code for writing the 23076assembler code can use the variable 'which_alternative', which is the 23077ordinal number of the alternative that was actually satisfied (0 for the 23078first, 1 for the second alternative, etc.). *Note Output Statement::. 23079 23080 23081File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 23082 2308317.8.3 Register Class Preferences 23084--------------------------------- 23085 23086The operand constraints have another function: they enable the compiler 23087to decide which kind of hardware register a pseudo register is best 23088allocated to. The compiler examines the constraints that apply to the 23089insns that use the pseudo register, looking for the machine-dependent 23090letters such as 'd' and 'a' that specify classes of registers. The 23091pseudo register is put in whichever class gets the most "votes". The 23092constraint letters 'g' and 'r' also vote: they vote in favor of a 23093general register. The machine description says which registers are 23094considered general. 23095 23096 Of course, on some machines all registers are equivalent, and no 23097register classes are defined. Then none of this complexity is relevant. 23098 23099 23100File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 23101 2310217.8.4 Constraint Modifier Characters 23103------------------------------------- 23104 23105Here are constraint modifier characters. 23106 23107'=' 23108 Means that this operand is written to by this instruction: the 23109 previous value is discarded and replaced by new data. 23110 23111'+' 23112 Means that this operand is both read and written by the 23113 instruction. 23114 23115 When the compiler fixes up the operands to satisfy the constraints, 23116 it needs to know which operands are read by the instruction and 23117 which are written by it. '=' identifies an operand which is only 23118 written; '+' identifies an operand that is both read and written; 23119 all other operands are assumed to only be read. 23120 23121 If you specify '=' or '+' in a constraint, you put it in the first 23122 character of the constraint string. 23123 23124'&' 23125 Means (in a particular alternative) that this operand is an 23126 "earlyclobber" operand, which is written before the instruction is 23127 finished using the input operands. Therefore, this operand may not 23128 lie in a register that is read by the instruction or as part of any 23129 memory address. 23130 23131 '&' applies only to the alternative in which it is written. In 23132 constraints with multiple alternatives, sometimes one alternative 23133 requires '&' while others do not. See, for example, the 'movdf' 23134 insn of the 68000. 23135 23136 An operand which is read by the instruction can be tied to an 23137 earlyclobber operand if its only use as an input occurs before the 23138 early result is written. Adding alternatives of this form often 23139 allows GCC to produce better code when only some of the read 23140 operands can be affected by the earlyclobber. See, for example, 23141 the 'mulsi3' insn of the ARM. 23142 23143 Furthermore, if the "earlyclobber" operand is also a read/write 23144 operand, then that operand is written only after it's used. 23145 23146 '&' does not obviate the need to write '=' or '+'. As 23147 "earlyclobber" operands are always written, a read-only 23148 "earlyclobber" operand is ill-formed and will be rejected by the 23149 compiler. 23150 23151'%' 23152 Declares the instruction to be commutative for this operand and the 23153 following operand. This means that the compiler may interchange 23154 the two operands if that is the cheapest way to make all operands 23155 fit the constraints. '%' applies to all alternatives and must 23156 appear as the first character in the constraint. Only read-only 23157 operands can use '%'. 23158 23159 This is often used in patterns for addition instructions that 23160 really have only two operands: the result must go in one of the 23161 arguments. Here for example, is how the 68000 halfword-add 23162 instruction is defined: 23163 23164 (define_insn "addhi3" 23165 [(set (match_operand:HI 0 "general_operand" "=m,r") 23166 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 23167 (match_operand:HI 2 "general_operand" "di,g")))] 23168 ...) 23169 GCC can only handle one commutative pair in an asm; if you use 23170 more, the compiler may fail. Note that you need not use the 23171 modifier if the two alternatives are strictly identical; this would 23172 only waste time in the reload pass. The modifier is not 23173 operational after register allocation, so the result of 23174 'define_peephole2' and 'define_split's performed after reload 23175 cannot rely on '%' to make the intended insn match. 23176 23177'#' 23178 Says that all following characters, up to the next comma, are to be 23179 ignored as a constraint. They are significant only for choosing 23180 register preferences. 23181 23182'*' 23183 Says that the following character should be ignored when choosing 23184 register preferences. '*' has no effect on the meaning of the 23185 constraint as a constraint, and no effect on reloading. For LRA 23186 '*' additionally disparages slightly the alternative if the 23187 following character matches the operand. 23188 23189 Here is an example: the 68000 has an instruction to sign-extend a 23190 halfword in a data register, and can also sign-extend a value by 23191 copying it into an address register. While either kind of register 23192 is acceptable, the constraints on an address-register destination 23193 are less strict, so it is best if register allocation makes an 23194 address register its goal. Therefore, '*' is used so that the 'd' 23195 constraint letter (for data register) is ignored when computing 23196 register preferences. 23197 23198 (define_insn "extendhisi2" 23199 [(set (match_operand:SI 0 "general_operand" "=*d,a") 23200 (sign_extend:SI 23201 (match_operand:HI 1 "general_operand" "0,g")))] 23202 ...) 23203 23204 23205File: gccint.info, Node: Machine Constraints, Next: Disable Insn Alternatives, Prev: Modifiers, Up: Constraints 23206 2320717.8.5 Constraints for Particular Machines 23208------------------------------------------ 23209 23210Whenever possible, you should use the general-purpose constraint letters 23211in 'asm' arguments, since they will convey meaning more readily to 23212people reading your code. Failing that, use the constraint letters that 23213usually have very similar meanings across architectures. The most 23214commonly used constraints are 'm' and 'r' (for memory and 23215general-purpose registers respectively; *note Simple Constraints::), and 23216'I', usually the letter indicating the most common immediate-constant 23217format. 23218 23219 Each architecture defines additional constraints. These constraints 23220are used by the compiler itself for instruction generation, as well as 23221for 'asm' statements; therefore, some of the constraints are not 23222particularly useful for 'asm'. Here is a summary of some of the 23223machine-dependent constraints available on some particular machines; it 23224includes both constraints that are useful for 'asm' and constraints that 23225aren't. The compiler source file mentioned in the table heading for 23226each architecture is the definitive reference for the meanings of that 23227architecture's constraints. 23228 23229_AArch64 family--'config/aarch64/constraints.md'_ 23230 'k' 23231 The stack pointer register ('SP') 23232 23233 'w' 23234 Floating point register, Advanced SIMD vector register or SVE 23235 vector register 23236 23237 'x' 23238 Like 'w', but restricted to registers 0 to 15 inclusive. 23239 23240 'y' 23241 Like 'w', but restricted to registers 0 to 7 inclusive. 23242 23243 'Upl' 23244 One of the low eight SVE predicate registers ('P0' to 'P7') 23245 23246 'Upa' 23247 Any of the SVE predicate registers ('P0' to 'P15') 23248 23249 'I' 23250 Integer constant that is valid as an immediate operand in an 23251 'ADD' instruction 23252 23253 'J' 23254 Integer constant that is valid as an immediate operand in a 23255 'SUB' instruction (once negated) 23256 23257 'K' 23258 Integer constant that can be used with a 32-bit logical 23259 instruction 23260 23261 'L' 23262 Integer constant that can be used with a 64-bit logical 23263 instruction 23264 23265 'M' 23266 Integer constant that is valid as an immediate operand in a 23267 32-bit 'MOV' pseudo instruction. The 'MOV' may be assembled 23268 to one of several different machine instructions depending on 23269 the value 23270 23271 'N' 23272 Integer constant that is valid as an immediate operand in a 23273 64-bit 'MOV' pseudo instruction 23274 23275 'S' 23276 An absolute symbolic address or a label reference 23277 23278 'Y' 23279 Floating point constant zero 23280 23281 'Z' 23282 Integer constant zero 23283 23284 'Ush' 23285 The high part (bits 12 and upwards) of the pc-relative address 23286 of a symbol within 4GB of the instruction 23287 23288 'Q' 23289 A memory address which uses a single base register with no 23290 offset 23291 23292 'Ump' 23293 A memory address suitable for a load/store pair instruction in 23294 SI, DI, SF and DF modes 23295 23296_AMD GCN --'config/gcn/constraints.md'_ 23297 'I' 23298 Immediate integer in the range -16 to 64 23299 23300 'J' 23301 Immediate 16-bit signed integer 23302 23303 'Kf' 23304 Immediate constant -1 23305 23306 'L' 23307 Immediate 15-bit unsigned integer 23308 23309 'A' 23310 Immediate constant that can be inlined in an instruction 23311 encoding: integer -16..64, or float 0.0, +/-0.5, +/-1.0, 23312 +/-2.0, +/-4.0, 1.0/(2.0*PI) 23313 23314 'B' 23315 Immediate 32-bit signed integer that can be attached to an 23316 instruction encoding 23317 23318 'C' 23319 Immediate 32-bit integer in range -16..4294967295 (i.e. 23320 32-bit unsigned integer or 'A' constraint) 23321 23322 'DA' 23323 Immediate 64-bit constant that can be split into two 'A' 23324 constants 23325 23326 'DB' 23327 Immediate 64-bit constant that can be split into two 'B' 23328 constants 23329 23330 'U' 23331 Any 'unspec' 23332 23333 'Y' 23334 Any 'symbol_ref' or 'label_ref' 23335 23336 'v' 23337 VGPR register 23338 23339 'Sg' 23340 SGPR register 23341 23342 'SD' 23343 SGPR registers valid for instruction destinations, including 23344 VCC, M0 and EXEC 23345 23346 'SS' 23347 SGPR registers valid for instruction sources, including VCC, 23348 M0, EXEC and SCC 23349 23350 'Sm' 23351 SGPR registers valid as a source for scalar memory 23352 instructions (excludes M0 and EXEC) 23353 23354 'Sv' 23355 SGPR registers valid as a source or destination for vector 23356 instructions (excludes EXEC) 23357 23358 'ca' 23359 All condition registers: SCC, VCCZ, EXECZ 23360 23361 'cs' 23362 Scalar condition register: SCC 23363 23364 'cV' 23365 Vector condition register: VCC, VCC_LO, VCC_HI 23366 23367 'e' 23368 EXEC register (EXEC_LO and EXEC_HI) 23369 23370 'RB' 23371 Memory operand with address space suitable for 'buffer_*' 23372 instructions 23373 23374 'RF' 23375 Memory operand with address space suitable for 'flat_*' 23376 instructions 23377 23378 'RS' 23379 Memory operand with address space suitable for 's_*' 23380 instructions 23381 23382 'RL' 23383 Memory operand with address space suitable for 'ds_*' LDS 23384 instructions 23385 23386 'RG' 23387 Memory operand with address space suitable for 'ds_*' GDS 23388 instructions 23389 23390 'RD' 23391 Memory operand with address space suitable for any 'ds_*' 23392 instructions 23393 23394 'RM' 23395 Memory operand with address space suitable for 'global_*' 23396 instructions 23397 23398_ARC --'config/arc/constraints.md'_ 23399 'q' 23400 Registers usable in ARCompact 16-bit instructions: 'r0'-'r3', 23401 'r12'-'r15'. This constraint can only match when the '-mq' 23402 option is in effect. 23403 23404 'e' 23405 Registers usable as base-regs of memory addresses in ARCompact 23406 16-bit memory instructions: 'r0'-'r3', 'r12'-'r15', 'sp'. 23407 This constraint can only match when the '-mq' option is in 23408 effect. 23409 'D' 23410 ARC FPX (dpfp) 64-bit registers. 'D0', 'D1'. 23411 23412 'I' 23413 A signed 12-bit integer constant. 23414 23415 'Cal' 23416 constant for arithmetic/logical operations. This might be any 23417 constant that can be put into a long immediate by the assmbler 23418 or linker without involving a PIC relocation. 23419 23420 'K' 23421 A 3-bit unsigned integer constant. 23422 23423 'L' 23424 A 6-bit unsigned integer constant. 23425 23426 'CnL' 23427 One's complement of a 6-bit unsigned integer constant. 23428 23429 'CmL' 23430 Two's complement of a 6-bit unsigned integer constant. 23431 23432 'M' 23433 A 5-bit unsigned integer constant. 23434 23435 'O' 23436 A 7-bit unsigned integer constant. 23437 23438 'P' 23439 A 8-bit unsigned integer constant. 23440 23441 'H' 23442 Any const_double value. 23443 23444_ARM family--'config/arm/constraints.md'_ 23445 23446 'h' 23447 In Thumb state, the core registers 'r8'-'r15'. 23448 23449 'k' 23450 The stack pointer register. 23451 23452 'l' 23453 In Thumb State the core registers 'r0'-'r7'. In ARM state 23454 this is an alias for the 'r' constraint. 23455 23456 't' 23457 VFP floating-point registers 's0'-'s31'. Used for 32 bit 23458 values. 23459 23460 'w' 23461 VFP floating-point registers 'd0'-'d31' and the appropriate 23462 subset 'd0'-'d15' based on command line options. Used for 64 23463 bit values only. Not valid for Thumb1. 23464 23465 'y' 23466 The iWMMX co-processor registers. 23467 23468 'z' 23469 The iWMMX GR registers. 23470 23471 'G' 23472 The floating-point constant 0.0 23473 23474 'I' 23475 Integer that is valid as an immediate operand in a data 23476 processing instruction. That is, an integer in the range 0 to 23477 255 rotated by a multiple of 2 23478 23479 'J' 23480 Integer in the range -4095 to 4095 23481 23482 'K' 23483 Integer that satisfies constraint 'I' when inverted (ones 23484 complement) 23485 23486 'L' 23487 Integer that satisfies constraint 'I' when negated (twos 23488 complement) 23489 23490 'M' 23491 Integer in the range 0 to 32 23492 23493 'Q' 23494 A memory reference where the exact address is in a single 23495 register (''m'' is preferable for 'asm' statements) 23496 23497 'R' 23498 An item in the constant pool 23499 23500 'S' 23501 A symbol in the text segment of the current file 23502 23503 'Uv' 23504 A memory reference suitable for VFP load/store insns 23505 (reg+constant offset) 23506 23507 'Uy' 23508 A memory reference suitable for iWMMXt load/store 23509 instructions. 23510 23511 'Uq' 23512 A memory reference suitable for the ARMv4 ldrsb instruction. 23513 23514_AVR family--'config/avr/constraints.md'_ 23515 'l' 23516 Registers from r0 to r15 23517 23518 'a' 23519 Registers from r16 to r23 23520 23521 'd' 23522 Registers from r16 to r31 23523 23524 'w' 23525 Registers from r24 to r31. These registers can be used in 23526 'adiw' command 23527 23528 'e' 23529 Pointer register (r26-r31) 23530 23531 'b' 23532 Base pointer register (r28-r31) 23533 23534 'q' 23535 Stack pointer register (SPH:SPL) 23536 23537 't' 23538 Temporary register r0 23539 23540 'x' 23541 Register pair X (r27:r26) 23542 23543 'y' 23544 Register pair Y (r29:r28) 23545 23546 'z' 23547 Register pair Z (r31:r30) 23548 23549 'I' 23550 Constant greater than -1, less than 64 23551 23552 'J' 23553 Constant greater than -64, less than 1 23554 23555 'K' 23556 Constant integer 2 23557 23558 'L' 23559 Constant integer 0 23560 23561 'M' 23562 Constant that fits in 8 bits 23563 23564 'N' 23565 Constant integer -1 23566 23567 'O' 23568 Constant integer 8, 16, or 24 23569 23570 'P' 23571 Constant integer 1 23572 23573 'G' 23574 A floating point constant 0.0 23575 23576 'Q' 23577 A memory address based on Y or Z pointer with displacement. 23578 23579_Blackfin family--'config/bfin/constraints.md'_ 23580 'a' 23581 P register 23582 23583 'd' 23584 D register 23585 23586 'z' 23587 A call clobbered P register. 23588 23589 'qN' 23590 A single register. If N is in the range 0 to 7, the 23591 corresponding D register. If it is 'A', then the register P0. 23592 23593 'D' 23594 Even-numbered D register 23595 23596 'W' 23597 Odd-numbered D register 23598 23599 'e' 23600 Accumulator register. 23601 23602 'A' 23603 Even-numbered accumulator register. 23604 23605 'B' 23606 Odd-numbered accumulator register. 23607 23608 'b' 23609 I register 23610 23611 'v' 23612 B register 23613 23614 'f' 23615 M register 23616 23617 'c' 23618 Registers used for circular buffering, i.e. I, B, or L 23619 registers. 23620 23621 'C' 23622 The CC register. 23623 23624 't' 23625 LT0 or LT1. 23626 23627 'k' 23628 LC0 or LC1. 23629 23630 'u' 23631 LB0 or LB1. 23632 23633 'x' 23634 Any D, P, B, M, I or L register. 23635 23636 'y' 23637 Additional registers typically used only in prologues and 23638 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 23639 USP. 23640 23641 'w' 23642 Any register except accumulators or CC. 23643 23644 'Ksh' 23645 Signed 16 bit integer (in the range -32768 to 32767) 23646 23647 'Kuh' 23648 Unsigned 16 bit integer (in the range 0 to 65535) 23649 23650 'Ks7' 23651 Signed 7 bit integer (in the range -64 to 63) 23652 23653 'Ku7' 23654 Unsigned 7 bit integer (in the range 0 to 127) 23655 23656 'Ku5' 23657 Unsigned 5 bit integer (in the range 0 to 31) 23658 23659 'Ks4' 23660 Signed 4 bit integer (in the range -8 to 7) 23661 23662 'Ks3' 23663 Signed 3 bit integer (in the range -3 to 4) 23664 23665 'Ku3' 23666 Unsigned 3 bit integer (in the range 0 to 7) 23667 23668 'PN' 23669 Constant N, where N is a single-digit constant in the range 0 23670 to 4. 23671 23672 'PA' 23673 An integer equal to one of the MACFLAG_XXX constants that is 23674 suitable for use with either accumulator. 23675 23676 'PB' 23677 An integer equal to one of the MACFLAG_XXX constants that is 23678 suitable for use only with accumulator A1. 23679 23680 'M1' 23681 Constant 255. 23682 23683 'M2' 23684 Constant 65535. 23685 23686 'J' 23687 An integer constant with exactly a single bit set. 23688 23689 'L' 23690 An integer constant with all bits set except exactly one. 23691 23692 'H' 23693 23694 'Q' 23695 Any SYMBOL_REF. 23696 23697_CR16 Architecture--'config/cr16/cr16.h'_ 23698 23699 'b' 23700 Registers from r0 to r14 (registers without stack pointer) 23701 23702 't' 23703 Register from r0 to r11 (all 16-bit registers) 23704 23705 'p' 23706 Register from r12 to r15 (all 32-bit registers) 23707 23708 'I' 23709 Signed constant that fits in 4 bits 23710 23711 'J' 23712 Signed constant that fits in 5 bits 23713 23714 'K' 23715 Signed constant that fits in 6 bits 23716 23717 'L' 23718 Unsigned constant that fits in 4 bits 23719 23720 'M' 23721 Signed constant that fits in 32 bits 23722 23723 'N' 23724 Check for 64 bits wide constants for add/sub instructions 23725 23726 'G' 23727 Floating point constant that is legal for store immediate 23728 23729_C-SKY--'config/csky/constraints.md'_ 23730 23731 'a' 23732 The mini registers r0 - r7. 23733 23734 'b' 23735 The low registers r0 - r15. 23736 23737 'c' 23738 C register. 23739 23740 'y' 23741 HI and LO registers. 23742 23743 'l' 23744 LO register. 23745 23746 'h' 23747 HI register. 23748 23749 'v' 23750 Vector registers. 23751 23752 'z' 23753 Stack pointer register (SP). 23754 23755 The C-SKY back end supports a large set of additional constraints 23756 that are only useful for instruction selection or splitting rather 23757 than inline asm, such as constraints representing constant integer 23758 ranges accepted by particular instruction encodings. Refer to the 23759 source code for details. 23760 23761_Epiphany--'config/epiphany/constraints.md'_ 23762 'U16' 23763 An unsigned 16-bit constant. 23764 23765 'K' 23766 An unsigned 5-bit constant. 23767 23768 'L' 23769 A signed 11-bit constant. 23770 23771 'Cm1' 23772 A signed 11-bit constant added to -1. Can only match when the 23773 '-m1reg-REG' option is active. 23774 23775 'Cl1' 23776 Left-shift of -1, i.e., a bit mask with a block of leading 23777 ones, the rest being a block of trailing zeroes. Can only 23778 match when the '-m1reg-REG' option is active. 23779 23780 'Cr1' 23781 Right-shift of -1, i.e., a bit mask with a trailing block of 23782 ones, the rest being zeroes. Or to put it another way, one 23783 less than a power of two. Can only match when the 23784 '-m1reg-REG' option is active. 23785 23786 'Cal' 23787 Constant for arithmetic/logical operations. This is like 'i', 23788 except that for position independent code, no symbols / 23789 expressions needing relocations are allowed. 23790 23791 'Csy' 23792 Symbolic constant for call/jump instruction. 23793 23794 'Rcs' 23795 The register class usable in short insns. This is a register 23796 class constraint, and can thus drive register allocation. 23797 This constraint won't match unless '-mprefer-short-insn-regs' 23798 is in effect. 23799 23800 'Rsc' 23801 The the register class of registers that can be used to hold a 23802 sibcall call address. I.e., a caller-saved register. 23803 23804 'Rct' 23805 Core control register class. 23806 23807 'Rgs' 23808 The register group usable in short insns. This constraint 23809 does not use a register class, so that it only passively 23810 matches suitable registers, and doesn't drive register 23811 allocation. 23812 23813 'Car' 23814 Constant suitable for the addsi3_r pattern. This is a valid 23815 offset For byte, halfword, or word addressing. 23816 23817 'Rra' 23818 Matches the return address if it can be replaced with the link 23819 register. 23820 23821 'Rcc' 23822 Matches the integer condition code register. 23823 23824 'Sra' 23825 Matches the return address if it is in a stack slot. 23826 23827 'Cfm' 23828 Matches control register values to switch fp mode, which are 23829 encapsulated in 'UNSPEC_FP_MODE'. 23830 23831_FRV--'config/frv/frv.h'_ 23832 'a' 23833 Register in the class 'ACC_REGS' ('acc0' to 'acc7'). 23834 23835 'b' 23836 Register in the class 'EVEN_ACC_REGS' ('acc0' to 'acc7'). 23837 23838 'c' 23839 Register in the class 'CC_REGS' ('fcc0' to 'fcc3' and 'icc0' 23840 to 'icc3'). 23841 23842 'd' 23843 Register in the class 'GPR_REGS' ('gr0' to 'gr63'). 23844 23845 'e' 23846 Register in the class 'EVEN_REGS' ('gr0' to 'gr63'). Odd 23847 registers are excluded not in the class but through the use of 23848 a machine mode larger than 4 bytes. 23849 23850 'f' 23851 Register in the class 'FPR_REGS' ('fr0' to 'fr63'). 23852 23853 'h' 23854 Register in the class 'FEVEN_REGS' ('fr0' to 'fr63'). Odd 23855 registers are excluded not in the class but through the use of 23856 a machine mode larger than 4 bytes. 23857 23858 'l' 23859 Register in the class 'LR_REG' (the 'lr' register). 23860 23861 'q' 23862 Register in the class 'QUAD_REGS' ('gr2' to 'gr63'). Register 23863 numbers not divisible by 4 are excluded not in the class but 23864 through the use of a machine mode larger than 8 bytes. 23865 23866 't' 23867 Register in the class 'ICC_REGS' ('icc0' to 'icc3'). 23868 23869 'u' 23870 Register in the class 'FCC_REGS' ('fcc0' to 'fcc3'). 23871 23872 'v' 23873 Register in the class 'ICR_REGS' ('cc4' to 'cc7'). 23874 23875 'w' 23876 Register in the class 'FCR_REGS' ('cc0' to 'cc3'). 23877 23878 'x' 23879 Register in the class 'QUAD_FPR_REGS' ('fr0' to 'fr63'). 23880 Register numbers not divisible by 4 are excluded not in the 23881 class but through the use of a machine mode larger than 8 23882 bytes. 23883 23884 'z' 23885 Register in the class 'SPR_REGS' ('lcr' and 'lr'). 23886 23887 'A' 23888 Register in the class 'QUAD_ACC_REGS' ('acc0' to 'acc7'). 23889 23890 'B' 23891 Register in the class 'ACCG_REGS' ('accg0' to 'accg7'). 23892 23893 'C' 23894 Register in the class 'CR_REGS' ('cc0' to 'cc7'). 23895 23896 'G' 23897 Floating point constant zero 23898 23899 'I' 23900 6-bit signed integer constant 23901 23902 'J' 23903 10-bit signed integer constant 23904 23905 'L' 23906 16-bit signed integer constant 23907 23908 'M' 23909 16-bit unsigned integer constant 23910 23911 'N' 23912 12-bit signed integer constant that is negative--i.e. in the 23913 range of -2048 to -1 23914 23915 'O' 23916 Constant zero 23917 23918 'P' 23919 12-bit signed integer constant that is greater than zero--i.e. 23920 in the range of 1 to 2047. 23921 23922_FT32--'config/ft32/constraints.md'_ 23923 'A' 23924 An absolute address 23925 23926 'B' 23927 An offset address 23928 23929 'W' 23930 A register indirect memory operand 23931 23932 'e' 23933 An offset address. 23934 23935 'f' 23936 An offset address. 23937 23938 'O' 23939 The constant zero or one 23940 23941 'I' 23942 A 16-bit signed constant (-32768 ... 32767) 23943 23944 'w' 23945 A bitfield mask suitable for bext or bins 23946 23947 'x' 23948 An inverted bitfield mask suitable for bext or bins 23949 23950 'L' 23951 A 16-bit unsigned constant, multiple of 4 (0 ... 65532) 23952 23953 'S' 23954 A 20-bit signed constant (-524288 ... 524287) 23955 23956 'b' 23957 A constant for a bitfield width (1 ... 16) 23958 23959 'KA' 23960 A 10-bit signed constant (-512 ... 511) 23961 23962_Hewlett-Packard PA-RISC--'config/pa/pa.h'_ 23963 'a' 23964 General register 1 23965 23966 'f' 23967 Floating point register 23968 23969 'q' 23970 Shift amount register 23971 23972 'x' 23973 Floating point register (deprecated) 23974 23975 'y' 23976 Upper floating point register (32-bit), floating point 23977 register (64-bit) 23978 23979 'Z' 23980 Any register 23981 23982 'I' 23983 Signed 11-bit integer constant 23984 23985 'J' 23986 Signed 14-bit integer constant 23987 23988 'K' 23989 Integer constant that can be deposited with a 'zdepi' 23990 instruction 23991 23992 'L' 23993 Signed 5-bit integer constant 23994 23995 'M' 23996 Integer constant 0 23997 23998 'N' 23999 Integer constant that can be loaded with a 'ldil' instruction 24000 24001 'O' 24002 Integer constant whose value plus one is a power of 2 24003 24004 'P' 24005 Integer constant that can be used for 'and' operations in 24006 'depi' and 'extru' instructions 24007 24008 'S' 24009 Integer constant 31 24010 24011 'U' 24012 Integer constant 63 24013 24014 'G' 24015 Floating-point constant 0.0 24016 24017 'A' 24018 A 'lo_sum' data-linkage-table memory operand 24019 24020 'Q' 24021 A memory operand that can be used as the destination operand 24022 of an integer store instruction 24023 24024 'R' 24025 A scaled or unscaled indexed memory operand 24026 24027 'T' 24028 A memory operand for floating-point loads and stores 24029 24030 'W' 24031 A register indirect memory operand 24032 24033_Intel IA-64--'config/ia64/ia64.h'_ 24034 'a' 24035 General register 'r0' to 'r3' for 'addl' instruction 24036 24037 'b' 24038 Branch register 24039 24040 'c' 24041 Predicate register ('c' as in "conditional") 24042 24043 'd' 24044 Application register residing in M-unit 24045 24046 'e' 24047 Application register residing in I-unit 24048 24049 'f' 24050 Floating-point register 24051 24052 'm' 24053 Memory operand. If used together with '<' or '>', the operand 24054 can have postincrement and postdecrement which require 24055 printing with '%Pn' on IA-64. 24056 24057 'G' 24058 Floating-point constant 0.0 or 1.0 24059 24060 'I' 24061 14-bit signed integer constant 24062 24063 'J' 24064 22-bit signed integer constant 24065 24066 'K' 24067 8-bit signed integer constant for logical instructions 24068 24069 'L' 24070 8-bit adjusted signed integer constant for compare pseudo-ops 24071 24072 'M' 24073 6-bit unsigned integer constant for shift counts 24074 24075 'N' 24076 9-bit signed integer constant for load and store 24077 postincrements 24078 24079 'O' 24080 The constant zero 24081 24082 'P' 24083 0 or -1 for 'dep' instruction 24084 24085 'Q' 24086 Non-volatile memory for floating-point loads and stores 24087 24088 'R' 24089 Integer constant in the range 1 to 4 for 'shladd' instruction 24090 24091 'S' 24092 Memory operand except postincrement and postdecrement. This 24093 is now roughly the same as 'm' when not used together with '<' 24094 or '>'. 24095 24096_M32C--'config/m32c/m32c.c'_ 24097 'Rsp' 24098 'Rfb' 24099 'Rsb' 24100 '$sp', '$fb', '$sb'. 24101 24102 'Rcr' 24103 Any control register, when they're 16 bits wide (nothing if 24104 control registers are 24 bits wide) 24105 24106 'Rcl' 24107 Any control register, when they're 24 bits wide. 24108 24109 'R0w' 24110 'R1w' 24111 'R2w' 24112 'R3w' 24113 $r0, $r1, $r2, $r3. 24114 24115 'R02' 24116 $r0 or $r2, or $r2r0 for 32 bit values. 24117 24118 'R13' 24119 $r1 or $r3, or $r3r1 for 32 bit values. 24120 24121 'Rdi' 24122 A register that can hold a 64 bit value. 24123 24124 'Rhl' 24125 $r0 or $r1 (registers with addressable high/low bytes) 24126 24127 'R23' 24128 $r2 or $r3 24129 24130 'Raa' 24131 Address registers 24132 24133 'Raw' 24134 Address registers when they're 16 bits wide. 24135 24136 'Ral' 24137 Address registers when they're 24 bits wide. 24138 24139 'Rqi' 24140 Registers that can hold QI values. 24141 24142 'Rad' 24143 Registers that can be used with displacements ($a0, $a1, $sb). 24144 24145 'Rsi' 24146 Registers that can hold 32 bit values. 24147 24148 'Rhi' 24149 Registers that can hold 16 bit values. 24150 24151 'Rhc' 24152 Registers chat can hold 16 bit values, including all control 24153 registers. 24154 24155 'Rra' 24156 $r0 through R1, plus $a0 and $a1. 24157 24158 'Rfl' 24159 The flags register. 24160 24161 'Rmm' 24162 The memory-based pseudo-registers $mem0 through $mem15. 24163 24164 'Rpi' 24165 Registers that can hold pointers (16 bit registers for r8c, 24166 m16c; 24 bit registers for m32cm, m32c). 24167 24168 'Rpa' 24169 Matches multiple registers in a PARALLEL to form a larger 24170 register. Used to match function return values. 24171 24172 'Is3' 24173 -8 ... 7 24174 24175 'IS1' 24176 -128 ... 127 24177 24178 'IS2' 24179 -32768 ... 32767 24180 24181 'IU2' 24182 0 ... 65535 24183 24184 'In4' 24185 -8 ... -1 or 1 ... 8 24186 24187 'In5' 24188 -16 ... -1 or 1 ... 16 24189 24190 'In6' 24191 -32 ... -1 or 1 ... 32 24192 24193 'IM2' 24194 -65536 ... -1 24195 24196 'Ilb' 24197 An 8 bit value with exactly one bit set. 24198 24199 'Ilw' 24200 A 16 bit value with exactly one bit set. 24201 24202 'Sd' 24203 The common src/dest memory addressing modes. 24204 24205 'Sa' 24206 Memory addressed using $a0 or $a1. 24207 24208 'Si' 24209 Memory addressed with immediate addresses. 24210 24211 'Ss' 24212 Memory addressed using the stack pointer ($sp). 24213 24214 'Sf' 24215 Memory addressed using the frame base register ($fb). 24216 24217 'Ss' 24218 Memory addressed using the small base register ($sb). 24219 24220 'S1' 24221 $r1h 24222 24223_MicroBlaze--'config/microblaze/constraints.md'_ 24224 'd' 24225 A general register ('r0' to 'r31'). 24226 24227 'z' 24228 A status register ('rmsr', '$fcc1' to '$fcc7'). 24229 24230_MIPS--'config/mips/constraints.md'_ 24231 'd' 24232 A general-purpose register. This is equivalent to 'r' unless 24233 generating MIPS16 code, in which case the MIPS16 register set 24234 is used. 24235 24236 'f' 24237 A floating-point register (if available). 24238 24239 'h' 24240 Formerly the 'hi' register. This constraint is no longer 24241 supported. 24242 24243 'l' 24244 The 'lo' register. Use this register to store values that are 24245 no bigger than a word. 24246 24247 'x' 24248 The concatenated 'hi' and 'lo' registers. Use this register 24249 to store doubleword values. 24250 24251 'c' 24252 A register suitable for use in an indirect jump. This will 24253 always be '$25' for '-mabicalls'. 24254 24255 'v' 24256 Register '$3'. Do not use this constraint in new code; it is 24257 retained only for compatibility with glibc. 24258 24259 'y' 24260 Equivalent to 'r'; retained for backwards compatibility. 24261 24262 'z' 24263 A floating-point condition code register. 24264 24265 'I' 24266 A signed 16-bit constant (for arithmetic instructions). 24267 24268 'J' 24269 Integer zero. 24270 24271 'K' 24272 An unsigned 16-bit constant (for logic instructions). 24273 24274 'L' 24275 A signed 32-bit constant in which the lower 16 bits are zero. 24276 Such constants can be loaded using 'lui'. 24277 24278 'M' 24279 A constant that cannot be loaded using 'lui', 'addiu' or 24280 'ori'. 24281 24282 'N' 24283 A constant in the range -65535 to -1 (inclusive). 24284 24285 'O' 24286 A signed 15-bit constant. 24287 24288 'P' 24289 A constant in the range 1 to 65535 (inclusive). 24290 24291 'G' 24292 Floating-point zero. 24293 24294 'R' 24295 An address that can be used in a non-macro load or store. 24296 24297 'ZC' 24298 A memory operand whose address is formed by a base register 24299 and offset that is suitable for use in instructions with the 24300 same addressing mode as 'll' and 'sc'. 24301 24302 'ZD' 24303 An address suitable for a 'prefetch' instruction, or for any 24304 other instruction with the same addressing mode as 'prefetch'. 24305 24306_Motorola 680x0--'config/m68k/constraints.md'_ 24307 'a' 24308 Address register 24309 24310 'd' 24311 Data register 24312 24313 'f' 24314 68881 floating-point register, if available 24315 24316 'I' 24317 Integer in the range 1 to 8 24318 24319 'J' 24320 16-bit signed number 24321 24322 'K' 24323 Signed number whose magnitude is greater than 0x80 24324 24325 'L' 24326 Integer in the range -8 to -1 24327 24328 'M' 24329 Signed number whose magnitude is greater than 0x100 24330 24331 'N' 24332 Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate 24333 24334 'O' 24335 16 (for rotate using swap) 24336 24337 'P' 24338 Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate 24339 24340 'R' 24341 Numbers that mov3q can handle 24342 24343 'G' 24344 Floating point constant that is not a 68881 constant 24345 24346 'S' 24347 Operands that satisfy 'm' when -mpcrel is in effect 24348 24349 'T' 24350 Operands that satisfy 's' when -mpcrel is not in effect 24351 24352 'Q' 24353 Address register indirect addressing mode 24354 24355 'U' 24356 Register offset addressing 24357 24358 'W' 24359 const_call_operand 24360 24361 'Cs' 24362 symbol_ref or const 24363 24364 'Ci' 24365 const_int 24366 24367 'C0' 24368 const_int 0 24369 24370 'Cj' 24371 Range of signed numbers that don't fit in 16 bits 24372 24373 'Cmvq' 24374 Integers valid for mvq 24375 24376 'Capsw' 24377 Integers valid for a moveq followed by a swap 24378 24379 'Cmvz' 24380 Integers valid for mvz 24381 24382 'Cmvs' 24383 Integers valid for mvs 24384 24385 'Ap' 24386 push_operand 24387 24388 'Ac' 24389 Non-register operands allowed in clr 24390 24391_Moxie--'config/moxie/constraints.md'_ 24392 'A' 24393 An absolute address 24394 24395 'B' 24396 An offset address 24397 24398 'W' 24399 A register indirect memory operand 24400 24401 'I' 24402 A constant in the range of 0 to 255. 24403 24404 'N' 24405 A constant in the range of 0 to -255. 24406 24407_MSP430-'config/msp430/constraints.md'_ 24408 24409 'R12' 24410 Register R12. 24411 24412 'R13' 24413 Register R13. 24414 24415 'K' 24416 Integer constant 1. 24417 24418 'L' 24419 Integer constant -1^20..1^19. 24420 24421 'M' 24422 Integer constant 1-4. 24423 24424 'Ya' 24425 Memory references which do not require an extended MOVX 24426 instruction. 24427 24428 'Yl' 24429 Memory reference, labels only. 24430 24431 'Ys' 24432 Memory reference, stack only. 24433 24434_NDS32--'config/nds32/constraints.md'_ 24435 'w' 24436 LOW register class $r0 to $r7 constraint for V3/V3M ISA. 24437 'l' 24438 LOW register class $r0 to $r7. 24439 'd' 24440 MIDDLE register class $r0 to $r11, $r16 to $r19. 24441 'h' 24442 HIGH register class $r12 to $r14, $r20 to $r31. 24443 't' 24444 Temporary assist register $ta (i.e. $r15). 24445 'k' 24446 Stack register $sp. 24447 'Iu03' 24448 Unsigned immediate 3-bit value. 24449 'In03' 24450 Negative immediate 3-bit value in the range of -7-0. 24451 'Iu04' 24452 Unsigned immediate 4-bit value. 24453 'Is05' 24454 Signed immediate 5-bit value. 24455 'Iu05' 24456 Unsigned immediate 5-bit value. 24457 'In05' 24458 Negative immediate 5-bit value in the range of -31-0. 24459 'Ip05' 24460 Unsigned immediate 5-bit value for movpi45 instruction with 24461 range 16-47. 24462 'Iu06' 24463 Unsigned immediate 6-bit value constraint for addri36.sp 24464 instruction. 24465 'Iu08' 24466 Unsigned immediate 8-bit value. 24467 'Iu09' 24468 Unsigned immediate 9-bit value. 24469 'Is10' 24470 Signed immediate 10-bit value. 24471 'Is11' 24472 Signed immediate 11-bit value. 24473 'Is15' 24474 Signed immediate 15-bit value. 24475 'Iu15' 24476 Unsigned immediate 15-bit value. 24477 'Ic15' 24478 A constant which is not in the range of imm15u but ok for bclr 24479 instruction. 24480 'Ie15' 24481 A constant which is not in the range of imm15u but ok for bset 24482 instruction. 24483 'It15' 24484 A constant which is not in the range of imm15u but ok for btgl 24485 instruction. 24486 'Ii15' 24487 A constant whose compliment value is in the range of imm15u 24488 and ok for bitci instruction. 24489 'Is16' 24490 Signed immediate 16-bit value. 24491 'Is17' 24492 Signed immediate 17-bit value. 24493 'Is19' 24494 Signed immediate 19-bit value. 24495 'Is20' 24496 Signed immediate 20-bit value. 24497 'Ihig' 24498 The immediate value that can be simply set high 20-bit. 24499 'Izeb' 24500 The immediate value 0xff. 24501 'Izeh' 24502 The immediate value 0xffff. 24503 'Ixls' 24504 The immediate value 0x01. 24505 'Ix11' 24506 The immediate value 0x7ff. 24507 'Ibms' 24508 The immediate value with power of 2. 24509 'Ifex' 24510 The immediate value with power of 2 minus 1. 24511 'U33' 24512 Memory constraint for 333 format. 24513 'U45' 24514 Memory constraint for 45 format. 24515 'U37' 24516 Memory constraint for 37 format. 24517 24518_Nios II family--'config/nios2/constraints.md'_ 24519 24520 'I' 24521 Integer that is valid as an immediate operand in an 24522 instruction taking a signed 16-bit number. Range -32768 to 24523 32767. 24524 24525 'J' 24526 Integer that is valid as an immediate operand in an 24527 instruction taking an unsigned 16-bit number. Range 0 to 24528 65535. 24529 24530 'K' 24531 Integer that is valid as an immediate operand in an 24532 instruction taking only the upper 16-bits of a 32-bit number. 24533 Range 32-bit numbers with the lower 16-bits being 0. 24534 24535 'L' 24536 Integer that is valid as an immediate operand for a shift 24537 instruction. Range 0 to 31. 24538 24539 'M' 24540 Integer that is valid as an immediate operand for only the 24541 value 0. Can be used in conjunction with the format modifier 24542 'z' to use 'r0' instead of '0' in the assembly output. 24543 24544 'N' 24545 Integer that is valid as an immediate operand for a custom 24546 instruction opcode. Range 0 to 255. 24547 24548 'P' 24549 An immediate operand for R2 andchi/andci instructions. 24550 24551 'S' 24552 Matches immediates which are addresses in the small data 24553 section and therefore can be added to 'gp' as a 16-bit 24554 immediate to re-create their 32-bit value. 24555 24556 'U' 24557 Matches constants suitable as an operand for the rdprs and 24558 cache instructions. 24559 24560 'v' 24561 A memory operand suitable for Nios II R2 load/store exclusive 24562 instructions. 24563 24564 'w' 24565 A memory operand suitable for load/store IO and cache 24566 instructions. 24567 24568 'T' 24569 A 'const' wrapped 'UNSPEC' expression, representing a 24570 supported PIC or TLS relocation. 24571 24572_OpenRISC--'config/or1k/constraints.md'_ 24573 'I' 24574 Integer that is valid as an immediate operand in an 24575 instruction taking a signed 16-bit number. Range -32768 to 24576 32767. 24577 24578 'K' 24579 Integer that is valid as an immediate operand in an 24580 instruction taking an unsigned 16-bit number. Range 0 to 24581 65535. 24582 24583 'M' 24584 Signed 16-bit constant shifted left 16 bits. (Used with 24585 'l.movhi') 24586 24587 'O' 24588 Zero 24589 24590 'c' 24591 Register usable for sibcalls. 24592 24593_PDP-11--'config/pdp11/constraints.md'_ 24594 'a' 24595 Floating point registers AC0 through AC3. These can be loaded 24596 from/to memory with a single instruction. 24597 24598 'd' 24599 Odd numbered general registers (R1, R3, R5). These are used 24600 for 16-bit multiply operations. 24601 24602 'D' 24603 A memory reference that is encoded within the opcode, but not 24604 auto-increment or auto-decrement. 24605 24606 'f' 24607 Any of the floating point registers (AC0 through AC5). 24608 24609 'G' 24610 Floating point constant 0. 24611 24612 'h' 24613 Floating point registers AC4 and AC5. These cannot be loaded 24614 from/to memory with a single instruction. 24615 24616 'I' 24617 An integer constant that fits in 16 bits. 24618 24619 'J' 24620 An integer constant whose low order 16 bits are zero. 24621 24622 'K' 24623 An integer constant that does not meet the constraints for 24624 codes 'I' or 'J'. 24625 24626 'L' 24627 The integer constant 1. 24628 24629 'M' 24630 The integer constant -1. 24631 24632 'N' 24633 The integer constant 0. 24634 24635 'O' 24636 Integer constants 0 through 3; shifts by these amounts are 24637 handled as multiple single-bit shifts rather than a single 24638 variable-length shift. 24639 24640 'Q' 24641 A memory reference which requires an additional word (address 24642 or offset) after the opcode. 24643 24644 'R' 24645 A memory reference that is encoded within the opcode. 24646 24647_PowerPC and IBM RS6000--'config/rs6000/constraints.md'_ 24648 'r' 24649 A general purpose register (GPR), 'r0'...'r31'. 24650 24651 'b' 24652 A base register. Like 'r', but 'r0' is not allowed, so 24653 'r1'...'r31'. 24654 24655 'f' 24656 A floating point register (FPR), 'f0'...'f31'. 24657 24658 'd' 24659 A floating point register. This is the same as 'f' nowadays; 24660 historically 'f' was for single-precision and 'd' was for 24661 double-precision floating point. 24662 24663 'v' 24664 An Altivec vector register (VR), 'v0'...'v31'. 24665 24666 'wa' 24667 A VSX register (VSR), 'vs0'...'vs63'. This is either an FPR 24668 ('vs0'...'vs31' are 'f0'...'f31') or a VR ('vs32'...'vs63' are 24669 'v0'...'v31'). 24670 24671 When using 'wa', you should use the '%x' output modifier, so 24672 that the correct register number is printed. For example: 24673 24674 asm ("xvadddp %x0,%x1,%x2" 24675 : "=wa" (v1) 24676 : "wa" (v2), "wa" (v3)); 24677 24678 You should not use '%x' for 'v' operands: 24679 24680 asm ("xsaddqp %0,%1,%2" 24681 : "=v" (v1) 24682 : "v" (v2), "v" (v3)); 24683 24684 'h' 24685 A special register ('vrsave', 'ctr', or 'lr'). 24686 24687 'c' 24688 The count register, 'ctr'. 24689 24690 'l' 24691 The link register, 'lr'. 24692 24693 'x' 24694 Condition register field 0, 'cr0'. 24695 24696 'y' 24697 Any condition register field, 'cr0'...'cr7'. 24698 24699 'z' 24700 The carry bit, 'XER[CA]'. 24701 24702 'we' 24703 Like 'wa', if '-mpower9-vector' and '-m64' are used; 24704 otherwise, 'NO_REGS'. 24705 24706 'wn' 24707 No register ('NO_REGS'). 24708 24709 'wr' 24710 Like 'r', if '-mpowerpc64' is used; otherwise, 'NO_REGS'. 24711 24712 'wx' 24713 Like 'd', if '-mpowerpc-gfxopt' is used; otherwise, 'NO_REGS'. 24714 24715 'wA' 24716 Like 'b', if '-mpowerpc64' is used; otherwise, 'NO_REGS'. 24717 24718 'wB' 24719 Signed 5-bit constant integer that can be loaded into an 24720 Altivec register. 24721 24722 'wD' 24723 Int constant that is the element number of the 64-bit scalar 24724 in a vector. 24725 24726 'wE' 24727 Vector constant that can be loaded with the XXSPLTIB 24728 instruction. 24729 24730 'wF' 24731 Memory operand suitable for power8 GPR load fusion. 24732 24733 'wL' 24734 Int constant that is the element number mfvsrld accesses in a 24735 vector. 24736 24737 'wM' 24738 Match vector constant with all 1's if the XXLORC instruction 24739 is available. 24740 24741 'wO' 24742 Memory operand suitable for the ISA 3.0 vector d-form 24743 instructions. 24744 24745 'wQ' 24746 Memory operand suitable for the load/store quad instructions. 24747 24748 'wS' 24749 Vector constant that can be loaded with XXSPLTIB & sign 24750 extension. 24751 24752 'wY' 24753 A memory operand for a DS-form instruction. 24754 24755 'wZ' 24756 An indexed or indirect memory operand, ignoring the bottom 4 24757 bits. 24758 24759 'I' 24760 A signed 16-bit constant. 24761 24762 'J' 24763 An unsigned 16-bit constant shifted left 16 bits (use 'L' 24764 instead for 'SImode' constants). 24765 24766 'K' 24767 An unsigned 16-bit constant. 24768 24769 'L' 24770 A signed 16-bit constant shifted left 16 bits. 24771 24772 'M' 24773 An integer constant greater than 31. 24774 24775 'N' 24776 An exact power of 2. 24777 24778 'O' 24779 The integer constant zero. 24780 24781 'P' 24782 A constant whose negation is a signed 16-bit constant. 24783 24784 'eI' 24785 A signed 34-bit integer constant if prefixed instructions are 24786 supported. 24787 24788 'G' 24789 A floating point constant that can be loaded into a register 24790 with one instruction per word. 24791 24792 'H' 24793 A floating point constant that can be loaded into a register 24794 using three instructions. 24795 24796 'm' 24797 A memory operand. Normally, 'm' does not allow addresses that 24798 update the base register. If the '<' or '>' constraint is 24799 also used, they are allowed and therefore on PowerPC targets 24800 in that case it is only safe to use 'm<>' in an 'asm' 24801 statement if that 'asm' statement accesses the operand exactly 24802 once. The 'asm' statement must also use '%U<OPNO>' as a 24803 placeholder for the "update" flag in the corresponding load or 24804 store instruction. For example: 24805 24806 asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); 24807 24808 is correct but: 24809 24810 asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); 24811 24812 is not. 24813 24814 'es' 24815 A "stable" memory operand; that is, one which does not include 24816 any automodification of the base register. This used to be 24817 useful when 'm' allowed automodification of the base register, 24818 but as those are now only allowed when '<' or '>' is used, 24819 'es' is basically the same as 'm' without '<' and '>'. 24820 24821 'Q' 24822 A memory operand addressed by just a base register. 24823 24824 'Y' 24825 A memory operand for a DQ-form instruction. 24826 24827 'Z' 24828 A memory operand accessed with indexed or indirect addressing. 24829 24830 'R' 24831 An AIX TOC entry. 24832 24833 'a' 24834 An indexed or indirect address. 24835 24836 'U' 24837 A V.4 small data reference. 24838 24839 'W' 24840 A vector constant that does not require memory. 24841 24842 'j' 24843 The zero vector constant. 24844 24845_PRU--'config/pru/constraints.md'_ 24846 'I' 24847 An unsigned 8-bit integer constant. 24848 24849 'J' 24850 An unsigned 16-bit integer constant. 24851 24852 'L' 24853 An unsigned 5-bit integer constant (for shift counts). 24854 24855 'T' 24856 A text segment (program memory) constant label. 24857 24858 'Z' 24859 Integer constant zero. 24860 24861_RL78--'config/rl78/constraints.md'_ 24862 24863 'Int3' 24864 An integer constant in the range 1 ... 7. 24865 'Int8' 24866 An integer constant in the range 0 ... 255. 24867 'J' 24868 An integer constant in the range -255 ... 0 24869 'K' 24870 The integer constant 1. 24871 'L' 24872 The integer constant -1. 24873 'M' 24874 The integer constant 0. 24875 'N' 24876 The integer constant 2. 24877 'O' 24878 The integer constant -2. 24879 'P' 24880 An integer constant in the range 1 ... 15. 24881 'Qbi' 24882 The built-in compare types-eq, ne, gtu, ltu, geu, and leu. 24883 'Qsc' 24884 The synthetic compare types-gt, lt, ge, and le. 24885 'Wab' 24886 A memory reference with an absolute address. 24887 'Wbc' 24888 A memory reference using 'BC' as a base register, with an 24889 optional offset. 24890 'Wca' 24891 A memory reference using 'AX', 'BC', 'DE', or 'HL' for the 24892 address, for calls. 24893 'Wcv' 24894 A memory reference using any 16-bit register pair for the 24895 address, for calls. 24896 'Wd2' 24897 A memory reference using 'DE' as a base register, with an 24898 optional offset. 24899 'Wde' 24900 A memory reference using 'DE' as a base register, without any 24901 offset. 24902 'Wfr' 24903 Any memory reference to an address in the far address space. 24904 'Wh1' 24905 A memory reference using 'HL' as a base register, with an 24906 optional one-byte offset. 24907 'Whb' 24908 A memory reference using 'HL' as a base register, with 'B' or 24909 'C' as the index register. 24910 'Whl' 24911 A memory reference using 'HL' as a base register, without any 24912 offset. 24913 'Ws1' 24914 A memory reference using 'SP' as a base register, with an 24915 optional one-byte offset. 24916 'Y' 24917 Any memory reference to an address in the near address space. 24918 'A' 24919 The 'AX' register. 24920 'B' 24921 The 'BC' register. 24922 'D' 24923 The 'DE' register. 24924 'R' 24925 'A' through 'L' registers. 24926 'S' 24927 The 'SP' register. 24928 'T' 24929 The 'HL' register. 24930 'Z08W' 24931 The 16-bit 'R8' register. 24932 'Z10W' 24933 The 16-bit 'R10' register. 24934 'Zint' 24935 The registers reserved for interrupts ('R24' to 'R31'). 24936 'a' 24937 The 'A' register. 24938 'b' 24939 The 'B' register. 24940 'c' 24941 The 'C' register. 24942 'd' 24943 The 'D' register. 24944 'e' 24945 The 'E' register. 24946 'h' 24947 The 'H' register. 24948 'l' 24949 The 'L' register. 24950 'v' 24951 The virtual registers. 24952 'w' 24953 The 'PSW' register. 24954 'x' 24955 The 'X' register. 24956 24957_RISC-V--'config/riscv/constraints.md'_ 24958 24959 'f' 24960 A floating-point register (if available). 24961 24962 'I' 24963 An I-type 12-bit signed immediate. 24964 24965 'J' 24966 Integer zero. 24967 24968 'K' 24969 A 5-bit unsigned immediate for CSR access instructions. 24970 24971 'A' 24972 An address that is held in a general-purpose register. 24973 24974_RX--'config/rx/constraints.md'_ 24975 'Q' 24976 An address which does not involve register indirect addressing 24977 or pre/post increment/decrement addressing. 24978 24979 'Symbol' 24980 A symbol reference. 24981 24982 'Int08' 24983 A constant in the range -256 to 255, inclusive. 24984 24985 'Sint08' 24986 A constant in the range -128 to 127, inclusive. 24987 24988 'Sint16' 24989 A constant in the range -32768 to 32767, inclusive. 24990 24991 'Sint24' 24992 A constant in the range -8388608 to 8388607, inclusive. 24993 24994 'Uint04' 24995 A constant in the range 0 to 15, inclusive. 24996 24997_S/390 and zSeries--'config/s390/s390.h'_ 24998 'a' 24999 Address register (general purpose register except r0) 25000 25001 'c' 25002 Condition code register 25003 25004 'd' 25005 Data register (arbitrary general purpose register) 25006 25007 'f' 25008 Floating-point register 25009 25010 'I' 25011 Unsigned 8-bit constant (0-255) 25012 25013 'J' 25014 Unsigned 12-bit constant (0-4095) 25015 25016 'K' 25017 Signed 16-bit constant (-32768-32767) 25018 25019 'L' 25020 Value appropriate as displacement. 25021 '(0..4095)' 25022 for short displacement 25023 '(-524288..524287)' 25024 for long displacement 25025 25026 'M' 25027 Constant integer with a value of 0x7fffffff. 25028 25029 'N' 25030 Multiple letter constraint followed by 4 parameter letters. 25031 '0..9:' 25032 number of the part counting from most to least 25033 significant 25034 'H,Q:' 25035 mode of the part 25036 'D,S,H:' 25037 mode of the containing operand 25038 '0,F:' 25039 value of the other parts (F--all bits set) 25040 The constraint matches if the specified part of a constant has 25041 a value different from its other parts. 25042 25043 'Q' 25044 Memory reference without index register and with short 25045 displacement. 25046 25047 'R' 25048 Memory reference with index register and short displacement. 25049 25050 'S' 25051 Memory reference without index register but with long 25052 displacement. 25053 25054 'T' 25055 Memory reference with index register and long displacement. 25056 25057 'U' 25058 Pointer with short displacement. 25059 25060 'W' 25061 Pointer with long displacement. 25062 25063 'Y' 25064 Shift count operand. 25065 25066_SPARC--'config/sparc/sparc.h'_ 25067 'f' 25068 Floating-point register on the SPARC-V8 architecture and lower 25069 floating-point register on the SPARC-V9 architecture. 25070 25071 'e' 25072 Floating-point register. It is equivalent to 'f' on the 25073 SPARC-V8 architecture and contains both lower and upper 25074 floating-point registers on the SPARC-V9 architecture. 25075 25076 'c' 25077 Floating-point condition code register. 25078 25079 'd' 25080 Lower floating-point register. It is only valid on the 25081 SPARC-V9 architecture when the Visual Instruction Set is 25082 available. 25083 25084 'b' 25085 Floating-point register. It is only valid on the SPARC-V9 25086 architecture when the Visual Instruction Set is available. 25087 25088 'h' 25089 64-bit global or out register for the SPARC-V8+ architecture. 25090 25091 'C' 25092 The constant all-ones, for floating-point. 25093 25094 'A' 25095 Signed 5-bit constant 25096 25097 'D' 25098 A vector constant 25099 25100 'I' 25101 Signed 13-bit constant 25102 25103 'J' 25104 Zero 25105 25106 'K' 25107 32-bit constant with the low 12 bits clear (a constant that 25108 can be loaded with the 'sethi' instruction) 25109 25110 'L' 25111 A constant in the range supported by 'movcc' instructions 25112 (11-bit signed immediate) 25113 25114 'M' 25115 A constant in the range supported by 'movrcc' instructions 25116 (10-bit signed immediate) 25117 25118 'N' 25119 Same as 'K', except that it verifies that bits that are not in 25120 the lower 32-bit range are all zero. Must be used instead of 25121 'K' for modes wider than 'SImode' 25122 25123 'O' 25124 The constant 4096 25125 25126 'G' 25127 Floating-point zero 25128 25129 'H' 25130 Signed 13-bit constant, sign-extended to 32 or 64 bits 25131 25132 'P' 25133 The constant -1 25134 25135 'Q' 25136 Floating-point constant whose integral representation can be 25137 moved into an integer register using a single sethi 25138 instruction 25139 25140 'R' 25141 Floating-point constant whose integral representation can be 25142 moved into an integer register using a single mov instruction 25143 25144 'S' 25145 Floating-point constant whose integral representation can be 25146 moved into an integer register using a high/lo_sum instruction 25147 sequence 25148 25149 'T' 25150 Memory address aligned to an 8-byte boundary 25151 25152 'U' 25153 Even register 25154 25155 'W' 25156 Memory address for 'e' constraint registers 25157 25158 'w' 25159 Memory address with only a base register 25160 25161 'Y' 25162 Vector zero 25163 25164_TI C6X family--'config/c6x/constraints.md'_ 25165 'a' 25166 Register file A (A0-A31). 25167 25168 'b' 25169 Register file B (B0-B31). 25170 25171 'A' 25172 Predicate registers in register file A (A0-A2 on C64X and 25173 higher, A1 and A2 otherwise). 25174 25175 'B' 25176 Predicate registers in register file B (B0-B2). 25177 25178 'C' 25179 A call-used register in register file B (B0-B9, B16-B31). 25180 25181 'Da' 25182 Register file A, excluding predicate registers (A3-A31, plus 25183 A0 if not C64X or higher). 25184 25185 'Db' 25186 Register file B, excluding predicate registers (B3-B31). 25187 25188 'Iu4' 25189 Integer constant in the range 0 ... 15. 25190 25191 'Iu5' 25192 Integer constant in the range 0 ... 31. 25193 25194 'In5' 25195 Integer constant in the range -31 ... 0. 25196 25197 'Is5' 25198 Integer constant in the range -16 ... 15. 25199 25200 'I5x' 25201 Integer constant that can be the operand of an ADDA or a SUBA 25202 insn. 25203 25204 'IuB' 25205 Integer constant in the range 0 ... 65535. 25206 25207 'IsB' 25208 Integer constant in the range -32768 ... 32767. 25209 25210 'IsC' 25211 Integer constant in the range -2^{20} ... 2^{20} - 1. 25212 25213 'Jc' 25214 Integer constant that is a valid mask for the clr instruction. 25215 25216 'Js' 25217 Integer constant that is a valid mask for the set instruction. 25218 25219 'Q' 25220 Memory location with A base register. 25221 25222 'R' 25223 Memory location with B base register. 25224 25225 'S0' 25226 On C64x+ targets, a GP-relative small data reference. 25227 25228 'S1' 25229 Any kind of 'SYMBOL_REF', for use in a call address. 25230 25231 'Si' 25232 Any kind of immediate operand, unless it matches the S0 25233 constraint. 25234 25235 'T' 25236 Memory location with B base register, but not using a long 25237 offset. 25238 25239 'W' 25240 A memory operand with an address that cannot be used in an 25241 unaligned access. 25242 25243 'Z' 25244 Register B14 (aka DP). 25245 25246_TILE-Gx--'config/tilegx/constraints.md'_ 25247 'R00' 25248 'R01' 25249 'R02' 25250 'R03' 25251 'R04' 25252 'R05' 25253 'R06' 25254 'R07' 25255 'R08' 25256 'R09' 25257 'R10' 25258 Each of these represents a register constraint for an 25259 individual register, from r0 to r10. 25260 25261 'I' 25262 Signed 8-bit integer constant. 25263 25264 'J' 25265 Signed 16-bit integer constant. 25266 25267 'K' 25268 Unsigned 16-bit integer constant. 25269 25270 'L' 25271 Integer constant that fits in one signed byte when incremented 25272 by one (-129 ... 126). 25273 25274 'm' 25275 Memory operand. If used together with '<' or '>', the operand 25276 can have postincrement which requires printing with '%In' and 25277 '%in' on TILE-Gx. For example: 25278 25279 asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val)); 25280 25281 'M' 25282 A bit mask suitable for the BFINS instruction. 25283 25284 'N' 25285 Integer constant that is a byte tiled out eight times. 25286 25287 'O' 25288 The integer zero constant. 25289 25290 'P' 25291 Integer constant that is a sign-extended byte tiled out as 25292 four shorts. 25293 25294 'Q' 25295 Integer constant that fits in one signed byte when incremented 25296 (-129 ... 126), but excluding -1. 25297 25298 'S' 25299 Integer constant that has all 1 bits consecutive and starting 25300 at bit 0. 25301 25302 'T' 25303 A 16-bit fragment of a got, tls, or pc-relative reference. 25304 25305 'U' 25306 Memory operand except postincrement. This is roughly the same 25307 as 'm' when not used together with '<' or '>'. 25308 25309 'W' 25310 An 8-element vector constant with identical elements. 25311 25312 'Y' 25313 A 4-element vector constant with identical elements. 25314 25315 'Z0' 25316 The integer constant 0xffffffff. 25317 25318 'Z1' 25319 The integer constant 0xffffffff00000000. 25320 25321_TILEPro--'config/tilepro/constraints.md'_ 25322 'R00' 25323 'R01' 25324 'R02' 25325 'R03' 25326 'R04' 25327 'R05' 25328 'R06' 25329 'R07' 25330 'R08' 25331 'R09' 25332 'R10' 25333 Each of these represents a register constraint for an 25334 individual register, from r0 to r10. 25335 25336 'I' 25337 Signed 8-bit integer constant. 25338 25339 'J' 25340 Signed 16-bit integer constant. 25341 25342 'K' 25343 Nonzero integer constant with low 16 bits zero. 25344 25345 'L' 25346 Integer constant that fits in one signed byte when incremented 25347 by one (-129 ... 126). 25348 25349 'm' 25350 Memory operand. If used together with '<' or '>', the operand 25351 can have postincrement which requires printing with '%In' and 25352 '%in' on TILEPro. For example: 25353 25354 asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val)); 25355 25356 'M' 25357 A bit mask suitable for the MM instruction. 25358 25359 'N' 25360 Integer constant that is a byte tiled out four times. 25361 25362 'O' 25363 The integer zero constant. 25364 25365 'P' 25366 Integer constant that is a sign-extended byte tiled out as two 25367 shorts. 25368 25369 'Q' 25370 Integer constant that fits in one signed byte when incremented 25371 (-129 ... 126), but excluding -1. 25372 25373 'T' 25374 A symbolic operand, or a 16-bit fragment of a got, tls, or 25375 pc-relative reference. 25376 25377 'U' 25378 Memory operand except postincrement. This is roughly the same 25379 as 'm' when not used together with '<' or '>'. 25380 25381 'W' 25382 A 4-element vector constant with identical elements. 25383 25384 'Y' 25385 A 2-element vector constant with identical elements. 25386 25387_Visium--'config/visium/constraints.md'_ 25388 'b' 25389 EAM register 'mdb' 25390 25391 'c' 25392 EAM register 'mdc' 25393 25394 'f' 25395 Floating point register 25396 25397 'k' 25398 Register for sibcall optimization 25399 25400 'l' 25401 General register, but not 'r29', 'r30' and 'r31' 25402 25403 't' 25404 Register 'r1' 25405 25406 'u' 25407 Register 'r2' 25408 25409 'v' 25410 Register 'r3' 25411 25412 'G' 25413 Floating-point constant 0.0 25414 25415 'J' 25416 Integer constant in the range 0 .. 65535 (16-bit immediate) 25417 25418 'K' 25419 Integer constant in the range 1 .. 31 (5-bit immediate) 25420 25421 'L' 25422 Integer constant in the range -65535 .. -1 (16-bit negative 25423 immediate) 25424 25425 'M' 25426 Integer constant -1 25427 25428 'O' 25429 Integer constant 0 25430 25431 'P' 25432 Integer constant 32 25433 25434_x86 family--'config/i386/constraints.md'_ 25435 'R' 25436 Legacy register--the eight integer registers available on all 25437 i386 processors ('a', 'b', 'c', 'd', 'si', 'di', 'bp', 'sp'). 25438 25439 'q' 25440 Any register accessible as 'Rl'. In 32-bit mode, 'a', 'b', 25441 'c', and 'd'; in 64-bit mode, any integer register. 25442 25443 'Q' 25444 Any register accessible as 'Rh': 'a', 'b', 'c', and 'd'. 25445 25446 'l' 25447 Any register that can be used as the index in a base+index 25448 memory access: that is, any general register except the stack 25449 pointer. 25450 25451 'a' 25452 The 'a' register. 25453 25454 'b' 25455 The 'b' register. 25456 25457 'c' 25458 The 'c' register. 25459 25460 'd' 25461 The 'd' register. 25462 25463 'S' 25464 The 'si' register. 25465 25466 'D' 25467 The 'di' register. 25468 25469 'A' 25470 The 'a' and 'd' registers. This class is used for 25471 instructions that return double word results in the 'ax:dx' 25472 register pair. Single word values will be allocated either in 25473 'ax' or 'dx'. For example on i386 the following implements 25474 'rdtsc': 25475 25476 unsigned long long rdtsc (void) 25477 { 25478 unsigned long long tick; 25479 __asm__ __volatile__("rdtsc":"=A"(tick)); 25480 return tick; 25481 } 25482 25483 This is not correct on x86-64 as it would allocate tick in 25484 either 'ax' or 'dx'. You have to use the following variant 25485 instead: 25486 25487 unsigned long long rdtsc (void) 25488 { 25489 unsigned int tickl, tickh; 25490 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); 25491 return ((unsigned long long)tickh << 32)|tickl; 25492 } 25493 25494 'U' 25495 The call-clobbered integer registers. 25496 25497 'f' 25498 Any 80387 floating-point (stack) register. 25499 25500 't' 25501 Top of 80387 floating-point stack ('%st(0)'). 25502 25503 'u' 25504 Second from top of 80387 floating-point stack ('%st(1)'). 25505 25506 'Yk' 25507 Any mask register that can be used as a predicate, i.e. 25508 'k1-k7'. 25509 25510 'k' 25511 Any mask register. 25512 25513 'y' 25514 Any MMX register. 25515 25516 'x' 25517 Any SSE register. 25518 25519 'v' 25520 Any EVEX encodable SSE register ('%xmm0-%xmm31'). 25521 25522 'w' 25523 Any bound register. 25524 25525 'Yz' 25526 First SSE register ('%xmm0'). 25527 25528 'Yi' 25529 Any SSE register, when SSE2 and inter-unit moves are enabled. 25530 25531 'Yj' 25532 Any SSE register, when SSE2 and inter-unit moves from vector 25533 registers are enabled. 25534 25535 'Ym' 25536 Any MMX register, when inter-unit moves are enabled. 25537 25538 'Yn' 25539 Any MMX register, when inter-unit moves from vector registers 25540 are enabled. 25541 25542 'Yp' 25543 Any integer register when 'TARGET_PARTIAL_REG_STALL' is 25544 disabled. 25545 25546 'Ya' 25547 Any integer register when zero extensions with 'AND' are 25548 disabled. 25549 25550 'Yb' 25551 Any register that can be used as the GOT base when calling 25552 '___tls_get_addr': that is, any general register except 'a' 25553 and 'sp' registers, for '-fno-plt' if linker supports it. 25554 Otherwise, 'b' register. 25555 25556 'Yf' 25557 Any x87 register when 80387 floating-point arithmetic is 25558 enabled. 25559 25560 'Yr' 25561 Lower SSE register when avoiding REX prefix and all SSE 25562 registers otherwise. 25563 25564 'Yv' 25565 For AVX512VL, any EVEX-encodable SSE register 25566 ('%xmm0-%xmm31'), otherwise any SSE register. 25567 25568 'Yh' 25569 Any EVEX-encodable SSE register, that has number factor of 25570 four. 25571 25572 'Bf' 25573 Flags register operand. 25574 25575 'Bg' 25576 GOT memory operand. 25577 25578 'Bm' 25579 Vector memory operand. 25580 25581 'Bc' 25582 Constant memory operand. 25583 25584 'Bn' 25585 Memory operand without REX prefix. 25586 25587 'Bs' 25588 Sibcall memory operand. 25589 25590 'Bw' 25591 Call memory operand. 25592 25593 'Bz' 25594 Constant call address operand. 25595 25596 'BC' 25597 SSE constant -1 operand. 25598 25599 'I' 25600 Integer constant in the range 0 ... 31, for 32-bit shifts. 25601 25602 'J' 25603 Integer constant in the range 0 ... 63, for 64-bit shifts. 25604 25605 'K' 25606 Signed 8-bit integer constant. 25607 25608 'L' 25609 '0xFF' or '0xFFFF', for andsi as a zero-extending move. 25610 25611 'M' 25612 0, 1, 2, or 3 (shifts for the 'lea' instruction). 25613 25614 'N' 25615 Unsigned 8-bit integer constant (for 'in' and 'out' 25616 instructions). 25617 25618 'O' 25619 Integer constant in the range 0 ... 127, for 128-bit shifts. 25620 25621 'G' 25622 Standard 80387 floating point constant. 25623 25624 'C' 25625 SSE constant zero operand. 25626 25627 'e' 25628 32-bit signed integer constant, or a symbolic reference known 25629 to fit that range (for immediate operands in sign-extending 25630 x86-64 instructions). 25631 25632 'We' 25633 32-bit signed integer constant, or a symbolic reference known 25634 to fit that range (for sign-extending conversion operations 25635 that require non-'VOIDmode' immediate operands). 25636 25637 'Wz' 25638 32-bit unsigned integer constant, or a symbolic reference 25639 known to fit that range (for zero-extending conversion 25640 operations that require non-'VOIDmode' immediate operands). 25641 25642 'Wd' 25643 128-bit integer constant where both the high and low 64-bit 25644 word satisfy the 'e' constraint. 25645 25646 'Z' 25647 32-bit unsigned integer constant, or a symbolic reference 25648 known to fit that range (for immediate operands in 25649 zero-extending x86-64 instructions). 25650 25651 'Tv' 25652 VSIB address operand. 25653 25654 'Ts' 25655 Address operand without segment register. 25656 25657_Xstormy16--'config/stormy16/stormy16.h'_ 25658 'a' 25659 Register r0. 25660 25661 'b' 25662 Register r1. 25663 25664 'c' 25665 Register r2. 25666 25667 'd' 25668 Register r8. 25669 25670 'e' 25671 Registers r0 through r7. 25672 25673 't' 25674 Registers r0 and r1. 25675 25676 'y' 25677 The carry register. 25678 25679 'z' 25680 Registers r8 and r9. 25681 25682 'I' 25683 A constant between 0 and 3 inclusive. 25684 25685 'J' 25686 A constant that has exactly one bit set. 25687 25688 'K' 25689 A constant that has exactly one bit clear. 25690 25691 'L' 25692 A constant between 0 and 255 inclusive. 25693 25694 'M' 25695 A constant between -255 and 0 inclusive. 25696 25697 'N' 25698 A constant between -3 and 0 inclusive. 25699 25700 'O' 25701 A constant between 1 and 4 inclusive. 25702 25703 'P' 25704 A constant between -4 and -1 inclusive. 25705 25706 'Q' 25707 A memory reference that is a stack push. 25708 25709 'R' 25710 A memory reference that is a stack pop. 25711 25712 'S' 25713 A memory reference that refers to a constant address of known 25714 value. 25715 25716 'T' 25717 The register indicated by Rx (not implemented yet). 25718 25719 'U' 25720 A constant that is not between 2 and 15 inclusive. 25721 25722 'Z' 25723 The constant 0. 25724 25725_Xtensa--'config/xtensa/constraints.md'_ 25726 'a' 25727 General-purpose 32-bit register 25728 25729 'b' 25730 One-bit boolean register 25731 25732 'A' 25733 MAC16 40-bit accumulator register 25734 25735 'I' 25736 Signed 12-bit integer constant, for use in MOVI instructions 25737 25738 'J' 25739 Signed 8-bit integer constant, for use in ADDI instructions 25740 25741 'K' 25742 Integer constant valid for BccI instructions 25743 25744 'L' 25745 Unsigned constant valid for BccUI instructions 25746 25747 25748File: gccint.info, Node: Disable Insn Alternatives, Next: Define Constraints, Prev: Machine Constraints, Up: Constraints 25749 2575017.8.6 Disable insn alternatives using the 'enabled' attribute 25751-------------------------------------------------------------- 25752 25753There are three insn attributes that may be used to selectively disable 25754instruction alternatives: 25755 25756'enabled' 25757 Says whether an alternative is available on the current subtarget. 25758 25759'preferred_for_size' 25760 Says whether an enabled alternative should be used in code that is 25761 optimized for size. 25762 25763'preferred_for_speed' 25764 Says whether an enabled alternative should be used in code that is 25765 optimized for speed. 25766 25767 All these attributes should use '(const_int 1)' to allow an alternative 25768or '(const_int 0)' to disallow it. The attributes must be a static 25769property of the subtarget; they cannot for example depend on the current 25770operands, on the current optimization level, on the location of the insn 25771within the body of a loop, on whether register allocation has finished, 25772or on the current compiler pass. 25773 25774 The 'enabled' attribute is a correctness property. It tells GCC to act 25775as though the disabled alternatives were never defined in the first 25776place. This is useful when adding new instructions to an existing 25777pattern in cases where the new instructions are only available for 25778certain cpu architecture levels (typically mapped to the '-march=' 25779command-line option). 25780 25781 In contrast, the 'preferred_for_size' and 'preferred_for_speed' 25782attributes are strong optimization hints rather than correctness 25783properties. 'preferred_for_size' tells GCC which alternatives to 25784consider when adding or modifying an instruction that GCC wants to 25785optimize for size. 'preferred_for_speed' does the same thing for speed. 25786Note that things like code motion can lead to cases where code optimized 25787for size uses alternatives that are not preferred for size, and 25788similarly for speed. 25789 25790 Although 'define_insn's can in principle specify the 'enabled' 25791attribute directly, it is often clearer to have subsiduary attributes 25792for each architectural feature of interest. The 'define_insn's can then 25793use these subsiduary attributes to say which alternatives require which 25794features. The example below does this for 'cpu_facility'. 25795 25796 E.g. the following two patterns could easily be merged using the 25797'enabled' attribute: 25798 25799 25800 (define_insn "*movdi_old" 25801 [(set (match_operand:DI 0 "register_operand" "=d") 25802 (match_operand:DI 1 "register_operand" " d"))] 25803 "!TARGET_NEW" 25804 "lgr %0,%1") 25805 25806 (define_insn "*movdi_new" 25807 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 25808 (match_operand:DI 1 "register_operand" " d,d,f"))] 25809 "TARGET_NEW" 25810 "@ 25811 lgr %0,%1 25812 ldgr %0,%1 25813 lgdr %0,%1") 25814 25815 25816 to: 25817 25818 25819 (define_insn "*movdi_combined" 25820 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 25821 (match_operand:DI 1 "register_operand" " d,d,f"))] 25822 "" 25823 "@ 25824 lgr %0,%1 25825 ldgr %0,%1 25826 lgdr %0,%1" 25827 [(set_attr "cpu_facility" "*,new,new")]) 25828 25829 25830 with the 'enabled' attribute defined like this: 25831 25832 25833 (define_attr "cpu_facility" "standard,new" (const_string "standard")) 25834 25835 (define_attr "enabled" "" 25836 (cond [(eq_attr "cpu_facility" "standard") (const_int 1) 25837 (and (eq_attr "cpu_facility" "new") 25838 (ne (symbol_ref "TARGET_NEW") (const_int 0))) 25839 (const_int 1)] 25840 (const_int 0))) 25841 25842 25843 25844File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Disable Insn Alternatives, Up: Constraints 25845 2584617.8.7 Defining Machine-Specific Constraints 25847-------------------------------------------- 25848 25849Machine-specific constraints fall into two categories: register and 25850non-register constraints. Within the latter category, constraints which 25851allow subsets of all possible memory or address operands should be 25852specially marked, to give 'reload' more information. 25853 25854 Machine-specific constraints can be given names of arbitrary length, 25855but they must be entirely composed of letters, digits, underscores 25856('_'), and angle brackets ('< >'). Like C identifiers, they must begin 25857with a letter or underscore. 25858 25859 In order to avoid ambiguity in operand constraint strings, no 25860constraint can have a name that begins with any other constraint's name. 25861For example, if 'x' is defined as a constraint name, 'xy' may not be, 25862and vice versa. As a consequence of this rule, no constraint may begin 25863with one of the generic constraint letters: 'E F V X g i m n o p r s'. 25864 25865 Register constraints correspond directly to register classes. *Note 25866Register Classes::. There is thus not much flexibility in their 25867definitions. 25868 25869 -- MD Expression: define_register_constraint name regclass docstring 25870 All three arguments are string constants. NAME is the name of the 25871 constraint, as it will appear in 'match_operand' expressions. If 25872 NAME is a multi-letter constraint its length shall be the same for 25873 all constraints starting with the same letter. REGCLASS can be 25874 either the name of the corresponding register class (*note Register 25875 Classes::), or a C expression which evaluates to the appropriate 25876 register class. If it is an expression, it must have no side 25877 effects, and it cannot look at the operand. The usual use of 25878 expressions is to map some register constraints to 'NO_REGS' when 25879 the register class is not available on a given subarchitecture. 25880 25881 DOCSTRING is a sentence documenting the meaning of the constraint. 25882 Docstrings are explained further below. 25883 25884 Non-register constraints are more like predicates: the constraint 25885definition gives a boolean expression which indicates whether the 25886constraint matches. 25887 25888 -- MD Expression: define_constraint name docstring exp 25889 The NAME and DOCSTRING arguments are the same as for 25890 'define_register_constraint', but note that the docstring comes 25891 immediately after the name for these expressions. EXP is an RTL 25892 expression, obeying the same rules as the RTL expressions in 25893 predicate definitions. *Note Defining Predicates::, for details. 25894 If it evaluates true, the constraint matches; if it evaluates 25895 false, it doesn't. Constraint expressions should indicate which 25896 RTL codes they might match, just like predicate expressions. 25897 25898 'match_test' C expressions have access to the following variables: 25899 25900 OP 25901 The RTL object defining the operand. 25902 MODE 25903 The machine mode of OP. 25904 IVAL 25905 'INTVAL (OP)', if OP is a 'const_int'. 25906 HVAL 25907 'CONST_DOUBLE_HIGH (OP)', if OP is an integer 'const_double'. 25908 LVAL 25909 'CONST_DOUBLE_LOW (OP)', if OP is an integer 'const_double'. 25910 RVAL 25911 'CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 25912 'const_double'. 25913 25914 The *VAL variables should only be used once another piece of the 25915 expression has verified that OP is the appropriate kind of RTL 25916 object. 25917 25918 Most non-register constraints should be defined with 25919'define_constraint'. The remaining two definition expressions are only 25920appropriate for constraints that should be handled specially by 'reload' 25921if they fail to match. 25922 25923 -- MD Expression: define_memory_constraint name docstring exp 25924 Use this expression for constraints that match a subset of all 25925 memory operands: that is, 'reload' can make them match by 25926 converting the operand to the form '(mem (reg X))', where X is a 25927 base register (from the register class specified by 25928 'BASE_REG_CLASS', *note Register Classes::). 25929 25930 For example, on the S/390, some instructions do not accept 25931 arbitrary memory references, but only those that do not make use of 25932 an index register. The constraint letter 'Q' is defined to 25933 represent a memory address of this type. If 'Q' is defined with 25934 'define_memory_constraint', a 'Q' constraint can handle any memory 25935 operand, because 'reload' knows it can simply copy the memory 25936 address into a base register if required. This is analogous to the 25937 way an 'o' constraint can handle any memory operand. 25938 25939 The syntax and semantics are otherwise identical to 25940 'define_constraint'. 25941 25942 -- MD Expression: define_special_memory_constraint name docstring exp 25943 Use this expression for constraints that match a subset of all 25944 memory operands: that is, 'reload' cannot make them match by 25945 reloading the address as it is described for 25946 'define_memory_constraint' or such address reload is undesirable 25947 with the performance point of view. 25948 25949 For example, 'define_special_memory_constraint' can be useful if 25950 specifically aligned memory is necessary or desirable for some insn 25951 operand. 25952 25953 The syntax and semantics are otherwise identical to 25954 'define_memory_constraint'. 25955 25956 -- MD Expression: define_relaxed_memory_constraint name docstring exp 25957 The test expression in a 'define_memory_constraint' can assume that 25958 'TARGET_LEGITIMATE_ADDRESS_P' holds for the address inside a 'mem' 25959 rtx and so it does not need to test this condition itself. In 25960 other words, a 'define_memory_constraint' test of the form: 25961 25962 (match_test "mem") 25963 25964 is enough to test whether an rtx is a 'mem' _and_ whether its 25965 address satisfies 'TARGET_MEM_CONSTRAINT' (which is usually ''m''). 25966 Thus the conditions imposed by a 'define_memory_constraint' always 25967 apply on top of the conditions imposed by 'TARGET_MEM_CONSTRAINT'. 25968 25969 However, it is sometimes useful to define memory constraints that 25970 allow addresses beyond those accepted by 25971 'TARGET_LEGITIMATE_ADDRESS_P'. 'define_relaxed_memory_constraint' 25972 exists for this case. The test expression in a 25973 'define_relaxed_memory_constraint' is applied with no 25974 preconditions, so that the expression can determine "from scratch" 25975 exactly which addresses are valid and which are not. 25976 25977 The syntax and semantics are otherwise identical to 25978 'define_memory_constraint'. 25979 25980 -- MD Expression: define_address_constraint name docstring exp 25981 Use this expression for constraints that match a subset of all 25982 address operands: that is, 'reload' can make the constraint match 25983 by converting the operand to the form '(reg X)', again with X a 25984 base register. 25985 25986 Constraints defined with 'define_address_constraint' can only be 25987 used with the 'address_operand' predicate, or machine-specific 25988 predicates that work the same way. They are treated analogously to 25989 the generic 'p' constraint. 25990 25991 The syntax and semantics are otherwise identical to 25992 'define_constraint'. 25993 25994 For historical reasons, names beginning with the letters 'G H' are 25995reserved for constraints that match only 'const_double's, and names 25996beginning with the letters 'I J K L M N O P' are reserved for 25997constraints that match only 'const_int's. This may change in the 25998future. For the time being, constraints with these names must be 25999written in a stylized form, so that 'genpreds' can tell you did it 26000correctly: 26001 26002 (define_constraint "[GHIJKLMNOP]..." 26003 "DOC..." 26004 (and (match_code "const_int") ; 'const_double' for G/H 26005 CONDITION...)) ; usually a 'match_test' 26006 26007 It is fine to use names beginning with other letters for constraints 26008that match 'const_double's or 'const_int's. 26009 26010 Each docstring in a constraint definition should be one or more 26011complete sentences, marked up in Texinfo format. _They are currently 26012unused._ In the future they will be copied into the GCC manual, in 26013*note Machine Constraints::, replacing the hand-maintained tables 26014currently found in that section. Also, in the future the compiler may 26015use this to give more helpful diagnostics when poor choice of 'asm' 26016constraints causes a reload failure. 26017 26018 If you put the pseudo-Texinfo directive '@internal' at the beginning of 26019a docstring, then (in the future) it will appear only in the internals 26020manual's version of the machine-specific constraint tables. Use this 26021for constraints that should not appear in 'asm' statements. 26022 26023 26024File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 26025 2602617.8.8 Testing constraints from C 26027--------------------------------- 26028 26029It is occasionally useful to test a constraint from C code rather than 26030implicitly via the constraint string in a 'match_operand'. The 26031generated file 'tm_p.h' declares a few interfaces for working with 26032constraints. At present these are defined for all constraints except 26033'g' (which is equivalent to 'general_operand'). 26034 26035 Some valid constraint names are not valid C identifiers, so there is a 26036mangling scheme for referring to them from C. Constraint names that do 26037not contain angle brackets or underscores are left unchanged. 26038Underscores are doubled, each '<' is replaced with '_l', and each '>' 26039with '_g'. Here are some examples: 26040 26041 *Original* *Mangled* 26042 x x 26043 P42x P42x 26044 P4_x P4__x 26045 P4>x P4_gx 26046 P4>> P4_g_g 26047 P4_g> P4__g_g 26048 26049 Throughout this section, the variable C is either a constraint in the 26050abstract sense, or a constant from 'enum constraint_num'; the variable M 26051is a mangled constraint name (usually as part of a larger identifier). 26052 26053 -- Enum: constraint_num 26054 For each constraint except 'g', there is a corresponding 26055 enumeration constant: 'CONSTRAINT_' plus the mangled name of the 26056 constraint. Functions that take an 'enum constraint_num' as an 26057 argument expect one of these constants. 26058 26059 -- Function: inline bool satisfies_constraint_M (rtx EXP) 26060 For each non-register constraint M except 'g', there is one of 26061 these functions; it returns 'true' if EXP satisfies the constraint. 26062 These functions are only visible if 'rtl.h' was included before 26063 'tm_p.h'. 26064 26065 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 26066 C) 26067 Like the 'satisfies_constraint_M' functions, but the constraint to 26068 test is given as an argument, C. If C specifies a register 26069 constraint, this function will always return 'false'. 26070 26071 -- Function: enum reg_class reg_class_for_constraint (enum 26072 constraint_num C) 26073 Returns the register class associated with C. If C is not a 26074 register constraint, or those registers are not available for the 26075 currently selected subtarget, returns 'NO_REGS'. 26076 26077 Here is an example use of 'satisfies_constraint_M'. In peephole 26078optimizations (*note Peephole Definitions::), operand constraint strings 26079are ignored, so if there are relevant constraints, they must be tested 26080in the C condition. In the example, the optimization is applied if 26081operand 2 does _not_ satisfy the 'K' constraint. (This is a simplified 26082version of a peephole definition from the i386 machine description.) 26083 26084 (define_peephole2 26085 [(match_scratch:SI 3 "r") 26086 (set (match_operand:SI 0 "register_operand" "") 26087 (mult:SI (match_operand:SI 1 "memory_operand" "") 26088 (match_operand:SI 2 "immediate_operand" "")))] 26089 26090 "!satisfies_constraint_K (operands[2])" 26091 26092 [(set (match_dup 3) (match_dup 1)) 26093 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 26094 26095 "") 26096 26097 26098File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 26099 2610017.9 Standard Pattern Names For Generation 26101========================================== 26102 26103Here is a table of the instruction names that are meaningful in the RTL 26104generation pass of the compiler. Giving one of these names to an 26105instruction pattern tells the RTL generation pass that it can use the 26106pattern to accomplish a certain task. 26107 26108'movM' 26109 Here M stands for a two-letter machine mode name, in lowercase. 26110 This instruction pattern moves data with that machine mode from 26111 operand 1 to operand 0. For example, 'movsi' moves full-word data. 26112 26113 If operand 0 is a 'subreg' with mode M of a register whose own mode 26114 is wider than M, the effect of this instruction is to store the 26115 specified value in the part of the register that corresponds to 26116 mode M. Bits outside of M, but which are within the same target 26117 word as the 'subreg' are undefined. Bits which are outside the 26118 target word are left unchanged. 26119 26120 This class of patterns is special in several ways. First of all, 26121 each of these names up to and including full word size _must_ be 26122 defined, because there is no other way to copy a datum from one 26123 place to another. If there are patterns accepting operands in 26124 larger modes, 'movM' must be defined for integer modes of those 26125 sizes. 26126 26127 Second, these patterns are not used solely in the RTL generation 26128 pass. Even the reload pass can generate move insns to copy values 26129 from stack slots into temporary registers. When it does so, one of 26130 the operands is a hard register and the other is an operand that 26131 can need to be reloaded into a register. 26132 26133 Therefore, when given such a pair of operands, the pattern must 26134 generate RTL which needs no reloading and needs no temporary 26135 registers--no registers other than the operands. For example, if 26136 you support the pattern with a 'define_expand', then in such a case 26137 the 'define_expand' mustn't call 'force_reg' or any other such 26138 function which might generate new pseudo registers. 26139 26140 This requirement exists even for subword modes on a RISC machine 26141 where fetching those modes from memory normally requires several 26142 insns and some temporary registers. 26143 26144 During reload a memory reference with an invalid address may be 26145 passed as an operand. Such an address will be replaced with a 26146 valid address later in the reload pass. In this case, nothing may 26147 be done with the address except to use it as it stands. If it is 26148 copied, it will not be replaced with a valid address. No attempt 26149 should be made to make such an address into a valid address and no 26150 routine (such as 'change_address') that will do so may be called. 26151 Note that 'general_operand' will fail when applied to such an 26152 address. 26153 26154 The global variable 'reload_in_progress' (which must be explicitly 26155 declared if required) can be used to determine whether such special 26156 handling is required. 26157 26158 The variety of operands that have reloads depends on the rest of 26159 the machine description, but typically on a RISC machine these can 26160 only be pseudo registers that did not get hard registers, while on 26161 other machines explicit memory references will get optional 26162 reloads. 26163 26164 If a scratch register is required to move an object to or from 26165 memory, it can be allocated using 'gen_reg_rtx' prior to life 26166 analysis. 26167 26168 If there are cases which need scratch registers during or after 26169 reload, you must provide an appropriate secondary_reload target 26170 hook. 26171 26172 The macro 'can_create_pseudo_p' can be used to determine if it is 26173 unsafe to create new pseudo registers. If this variable is 26174 nonzero, then it is unsafe to call 'gen_reg_rtx' to allocate a new 26175 pseudo. 26176 26177 The constraints on a 'movM' must permit moving any hard register to 26178 any other hard register provided that 'TARGET_HARD_REGNO_MODE_OK' 26179 permits mode M in both registers and 'TARGET_REGISTER_MOVE_COST' 26180 applied to their classes returns a value of 2. 26181 26182 It is obligatory to support floating point 'movM' instructions into 26183 and out of any registers that can hold fixed point values, because 26184 unions and structures (which have modes 'SImode' or 'DImode') can 26185 be in those registers and they may have floating point members. 26186 26187 There may also be a need to support fixed point 'movM' instructions 26188 in and out of floating point registers. Unfortunately, I have 26189 forgotten why this was so, and I don't know whether it is still 26190 true. If 'TARGET_HARD_REGNO_MODE_OK' rejects fixed point values in 26191 floating point registers, then the constraints of the fixed point 26192 'movM' instructions must be designed to avoid ever trying to reload 26193 into a floating point register. 26194 26195'reload_inM' 26196'reload_outM' 26197 These named patterns have been obsoleted by the target hook 26198 'secondary_reload'. 26199 26200 Like 'movM', but used when a scratch register is required to move 26201 between operand 0 and operand 1. Operand 2 describes the scratch 26202 register. See the discussion of the 'SECONDARY_RELOAD_CLASS' macro 26203 in *note Register Classes::. 26204 26205 There are special restrictions on the form of the 'match_operand's 26206 used in these patterns. First, only the predicate for the reload 26207 operand is examined, i.e., 'reload_in' examines operand 1, but not 26208 the predicates for operand 0 or 2. Second, there may be only one 26209 alternative in the constraints. Third, only a single register 26210 class letter may be used for the constraint; subsequent constraint 26211 letters are ignored. As a special exception, an empty constraint 26212 string matches the 'ALL_REGS' register class. This may relieve 26213 ports of the burden of defining an 'ALL_REGS' constraint letter 26214 just for these patterns. 26215 26216'movstrictM' 26217 Like 'movM' except that if operand 0 is a 'subreg' with mode M of a 26218 register whose natural mode is wider, the 'movstrictM' instruction 26219 is guaranteed not to alter any of the register except the part 26220 which belongs to mode M. 26221 26222'movmisalignM' 26223 This variant of a move pattern is designed to load or store a value 26224 from a memory address that is not naturally aligned for its mode. 26225 For a store, the memory will be in operand 0; for a load, the 26226 memory will be in operand 1. The other operand is guaranteed not 26227 to be a memory, so that it's easy to tell whether this is a load or 26228 store. 26229 26230 This pattern is used by the autovectorizer, and when expanding a 26231 'MISALIGNED_INDIRECT_REF' expression. 26232 26233'load_multiple' 26234 Load several consecutive memory locations into consecutive 26235 registers. Operand 0 is the first of the consecutive registers, 26236 operand 1 is the first memory location, and operand 2 is a 26237 constant: the number of consecutive registers. 26238 26239 Define this only if the target machine really has such an 26240 instruction; do not define this if the most efficient way of 26241 loading consecutive registers from memory is to do them one at a 26242 time. 26243 26244 On some machines, there are restrictions as to which consecutive 26245 registers can be stored into memory, such as particular starting or 26246 ending register numbers or only a range of valid counts. For those 26247 machines, use a 'define_expand' (*note Expander Definitions::) and 26248 make the pattern fail if the restrictions are not met. 26249 26250 Write the generated insn as a 'parallel' with elements being a 26251 'set' of one register from the appropriate memory location (you may 26252 also need 'use' or 'clobber' elements). Use a 'match_parallel' 26253 (*note RTL Template::) to recognize the insn. See 'rs6000.md' for 26254 examples of the use of this insn pattern. 26255 26256'store_multiple' 26257 Similar to 'load_multiple', but store several consecutive registers 26258 into consecutive memory locations. Operand 0 is the first of the 26259 consecutive memory locations, operand 1 is the first register, and 26260 operand 2 is a constant: the number of consecutive registers. 26261 26262'vec_load_lanesMN' 26263 Perform an interleaved load of several vectors from memory operand 26264 1 into register operand 0. Both operands have mode M. The 26265 register operand is viewed as holding consecutive vectors of mode 26266 N, while the memory operand is a flat array that contains the same 26267 number of elements. The operation is equivalent to: 26268 26269 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 26270 for (j = 0; j < GET_MODE_NUNITS (N); j++) 26271 for (i = 0; i < c; i++) 26272 operand0[i][j] = operand1[j * c + i]; 26273 26274 For example, 'vec_load_lanestiv4hi' loads 8 16-bit values from 26275 memory into a register of mode 'TI'. The register contains two 26276 consecutive vectors of mode 'V4HI'. 26277 26278 This pattern can only be used if: 26279 TARGET_ARRAY_MODE_SUPPORTED_P (N, C) 26280 is true. GCC assumes that, if a target supports this kind of 26281 instruction for some mode N, it also supports unaligned loads for 26282 vectors of mode N. 26283 26284 This pattern is not allowed to 'FAIL'. 26285 26286'vec_mask_load_lanesMN' 26287 Like 'vec_load_lanesMN', but takes an additional mask operand 26288 (operand 2) that specifies which elements of the destination 26289 vectors should be loaded. Other elements of the destination 26290 vectors are set to zero. The operation is equivalent to: 26291 26292 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 26293 for (j = 0; j < GET_MODE_NUNITS (N); j++) 26294 if (operand2[j]) 26295 for (i = 0; i < c; i++) 26296 operand0[i][j] = operand1[j * c + i]; 26297 else 26298 for (i = 0; i < c; i++) 26299 operand0[i][j] = 0; 26300 26301 This pattern is not allowed to 'FAIL'. 26302 26303'vec_store_lanesMN' 26304 Equivalent to 'vec_load_lanesMN', with the memory and register 26305 operands reversed. That is, the instruction is equivalent to: 26306 26307 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 26308 for (j = 0; j < GET_MODE_NUNITS (N); j++) 26309 for (i = 0; i < c; i++) 26310 operand0[j * c + i] = operand1[i][j]; 26311 26312 for a memory operand 0 and register operand 1. 26313 26314 This pattern is not allowed to 'FAIL'. 26315 26316'vec_mask_store_lanesMN' 26317 Like 'vec_store_lanesMN', but takes an additional mask operand 26318 (operand 2) that specifies which elements of the source vectors 26319 should be stored. The operation is equivalent to: 26320 26321 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 26322 for (j = 0; j < GET_MODE_NUNITS (N); j++) 26323 if (operand2[j]) 26324 for (i = 0; i < c; i++) 26325 operand0[j * c + i] = operand1[i][j]; 26326 26327 This pattern is not allowed to 'FAIL'. 26328 26329'gather_loadMN' 26330 Load several separate memory locations into a vector of mode M. 26331 Operand 1 is a scalar base address and operand 2 is a vector of 26332 mode N containing offsets from that base. Operand 0 is a 26333 destination vector with the same number of elements as N. For each 26334 element index I: 26335 26336 * extend the offset element I to address width, using zero 26337 extension if operand 3 is 1 and sign extension if operand 3 is 26338 zero; 26339 * multiply the extended offset by operand 4; 26340 * add the result to the base; and 26341 * load the value at that address into element I of operand 0. 26342 26343 The value of operand 3 does not matter if the offsets are already 26344 address width. 26345 26346'mask_gather_loadMN' 26347 Like 'gather_loadMN', but takes an extra mask operand as operand 5. 26348 Bit I of the mask is set if element I of the result should be 26349 loaded from memory and clear if element I of the result should be 26350 set to zero. 26351 26352'scatter_storeMN' 26353 Store a vector of mode M into several distinct memory locations. 26354 Operand 0 is a scalar base address and operand 1 is a vector of 26355 mode N containing offsets from that base. Operand 4 is the vector 26356 of values that should be stored, which has the same number of 26357 elements as N. For each element index I: 26358 26359 * extend the offset element I to address width, using zero 26360 extension if operand 2 is 1 and sign extension if operand 2 is 26361 zero; 26362 * multiply the extended offset by operand 3; 26363 * add the result to the base; and 26364 * store element I of operand 4 to that address. 26365 26366 The value of operand 2 does not matter if the offsets are already 26367 address width. 26368 26369'mask_scatter_storeMN' 26370 Like 'scatter_storeMN', but takes an extra mask operand as operand 26371 5. Bit I of the mask is set if element I of the result should be 26372 stored to memory. 26373 26374'vec_setM' 26375 Set given field in the vector value. Operand 0 is the vector to 26376 modify, operand 1 is new value of field and operand 2 specify the 26377 field index. 26378 26379'vec_extractMN' 26380 Extract given field from the vector value. Operand 1 is the 26381 vector, operand 2 specify field index and operand 0 place to store 26382 value into. The N mode is the mode of the field or vector of 26383 fields that should be extracted, should be either element mode of 26384 the vector mode M, or a vector mode with the same element mode and 26385 smaller number of elements. If N is a vector mode, the index is 26386 counted in units of that mode. 26387 26388'vec_initMN' 26389 Initialize the vector to given values. Operand 0 is the vector to 26390 initialize and operand 1 is parallel containing values for 26391 individual fields. The N mode is the mode of the elements, should 26392 be either element mode of the vector mode M, or a vector mode with 26393 the same element mode and smaller number of elements. 26394 26395'vec_duplicateM' 26396 Initialize vector output operand 0 so that each element has the 26397 value given by scalar input operand 1. The vector has mode M and 26398 the scalar has the mode appropriate for one element of M. 26399 26400 This pattern only handles duplicates of non-constant inputs. 26401 Constant vectors go through the 'movM' pattern instead. 26402 26403 This pattern is not allowed to 'FAIL'. 26404 26405'vec_seriesM' 26406 Initialize vector output operand 0 so that element I is equal to 26407 operand 1 plus I times operand 2. In other words, create a linear 26408 series whose base value is operand 1 and whose step is operand 2. 26409 26410 The vector output has mode M and the scalar inputs have the mode 26411 appropriate for one element of M. This pattern is not used for 26412 floating-point vectors, in order to avoid having to specify the 26413 rounding behavior for I > 1. 26414 26415 This pattern is not allowed to 'FAIL'. 26416 26417'while_ultMN' 26418 Set operand 0 to a mask that is true while incrementing operand 1 26419 gives a value that is less than operand 2. Operand 0 has mode N 26420 and operands 1 and 2 are scalar integers of mode M. The operation 26421 is equivalent to: 26422 26423 operand0[0] = operand1 < operand2; 26424 for (i = 1; i < GET_MODE_NUNITS (N); i++) 26425 operand0[i] = operand0[i - 1] && (operand1 + i < operand2); 26426 26427'check_raw_ptrsM' 26428 Check whether, given two pointers A and B and a length LEN, a write 26429 of LEN bytes at A followed by a read of LEN bytes at B can be split 26430 into interleaved byte accesses 'A[0], B[0], A[1], B[1], ...' 26431 without affecting the dependencies between the bytes. Set operand 26432 0 to true if the split is possible and false otherwise. 26433 26434 Operands 1, 2 and 3 provide the values of A, B and LEN 26435 respectively. Operand 4 is a constant integer that provides the 26436 known common alignment of A and B. All inputs have mode M. 26437 26438 This split is possible if: 26439 26440 A == B || A + LEN <= B || B + LEN <= A 26441 26442 You should only define this pattern if the target has a way of 26443 accelerating the test without having to do the individual 26444 comparisons. 26445 26446'check_war_ptrsM' 26447 Like 'check_raw_ptrsM', but with the read and write swapped round. 26448 The split is possible in this case if: 26449 26450 B <= A || A + LEN <= B 26451 26452'vec_cmpMN' 26453 Output a vector comparison. Operand 0 of mode N is the destination 26454 for predicate in operand 1 which is a signed vector comparison with 26455 operands of mode M in operands 2 and 3. Predicate is computed by 26456 element-wise evaluation of the vector comparison with a truth value 26457 of all-ones and a false value of all-zeros. 26458 26459'vec_cmpuMN' 26460 Similar to 'vec_cmpMN' but perform unsigned vector comparison. 26461 26462'vec_cmpeqMN' 26463 Similar to 'vec_cmpMN' but perform equality or non-equality vector 26464 comparison only. If 'vec_cmpMN' or 'vec_cmpuMN' instruction 26465 pattern is supported, it will be preferred over 'vec_cmpeqMN', so 26466 there is no need to define this instruction pattern if the others 26467 are supported. 26468 26469'vcondMN' 26470 Output a conditional vector move. Operand 0 is the destination to 26471 receive a combination of operand 1 and operand 2, which are of mode 26472 M, dependent on the outcome of the predicate in operand 3 which is 26473 a signed vector comparison with operands of mode N in operands 4 26474 and 5. The modes M and N should have the same size. Operand 0 26475 will be set to the value OP1 & MSK | OP2 & ~MSK where MSK is 26476 computed by element-wise evaluation of the vector comparison with a 26477 truth value of all-ones and a false value of all-zeros. 26478 26479'vconduMN' 26480 Similar to 'vcondMN' but performs unsigned vector comparison. 26481 26482'vcondeqMN' 26483 Similar to 'vcondMN' but performs equality or non-equality vector 26484 comparison only. If 'vcondMN' or 'vconduMN' instruction pattern is 26485 supported, it will be preferred over 'vcondeqMN', so there is no 26486 need to define this instruction pattern if the others are 26487 supported. 26488 26489'vcond_mask_MN' 26490 Similar to 'vcondMN' but operand 3 holds a pre-computed result of 26491 vector comparison. 26492 26493'maskloadMN' 26494 Perform a masked load of vector from memory operand 1 of mode M 26495 into register operand 0. Mask is provided in register operand 2 of 26496 mode N. 26497 26498 This pattern is not allowed to 'FAIL'. 26499 26500'maskstoreMN' 26501 Perform a masked store of vector from register operand 1 of mode M 26502 into memory operand 0. Mask is provided in register operand 2 of 26503 mode N. 26504 26505 This pattern is not allowed to 'FAIL'. 26506 26507'len_load_M' 26508 Load the number of vector elements specified by operand 2 from 26509 memory operand 1 into vector register operand 0, setting the other 26510 elements of operand 0 to undefined values. Operands 0 and 1 have 26511 mode M, which must be a vector mode. Operand 2 has whichever 26512 integer mode the target prefers. If operand 2 exceeds the number 26513 of elements in mode M, the behavior is undefined. If the target 26514 prefers the length to be measured in bytes rather than elements, it 26515 should only implement this pattern for vectors of 'QI' elements. 26516 26517 This pattern is not allowed to 'FAIL'. 26518 26519'len_store_M' 26520 Store the number of vector elements specified by operand 2 from 26521 vector register operand 1 into memory operand 0, leaving the other 26522 elements of operand 0 unchanged. Operands 0 and 1 have mode M, 26523 which must be a vector mode. Operand 2 has whichever integer mode 26524 the target prefers. If operand 2 exceeds the number of elements in 26525 mode M, the behavior is undefined. If the target prefers the 26526 length to be measured in bytes rather than elements, it should only 26527 implement this pattern for vectors of 'QI' elements. 26528 26529 This pattern is not allowed to 'FAIL'. 26530 26531'vec_permM' 26532 Output a (variable) vector permutation. Operand 0 is the 26533 destination to receive elements from operand 1 and operand 2, which 26534 are of mode M. Operand 3 is the "selector". It is an integral 26535 mode vector of the same width and number of elements as mode M. 26536 26537 The input elements are numbered from 0 in operand 1 through 2*N-1 26538 in operand 2. The elements of the selector must be computed modulo 26539 2*N. Note that if 'rtx_equal_p(operand1, operand2)', this can be 26540 implemented with just operand 1 and selector elements modulo N. 26541 26542 In order to make things easy for a number of targets, if there is 26543 no 'vec_perm' pattern for mode M, but there is for mode Q where Q 26544 is a vector of 'QImode' of the same width as M, the middle-end will 26545 lower the mode M 'VEC_PERM_EXPR' to mode Q. 26546 26547 See also 'TARGET_VECTORIZER_VEC_PERM_CONST', which performs the 26548 analogous operation for constant selectors. 26549 26550'pushM1' 26551 Output a push instruction. Operand 0 is value to push. Used only 26552 when 'PUSH_ROUNDING' is defined. For historical reason, this 26553 pattern may be missing and in such case an 'mov' expander is used 26554 instead, with a 'MEM' expression forming the push operation. The 26555 'mov' expander method is deprecated. 26556 26557'addM3' 26558 Add operand 2 and operand 1, storing the result in operand 0. All 26559 operands must have mode M. This can be used even on two-address 26560 machines, by means of constraints requiring operands 1 and 0 to be 26561 the same location. 26562 26563'ssaddM3', 'usaddM3' 26564'subM3', 'sssubM3', 'ussubM3' 26565'mulM3', 'ssmulM3', 'usmulM3' 26566'divM3', 'ssdivM3' 26567'udivM3', 'usdivM3' 26568'modM3', 'umodM3' 26569'uminM3', 'umaxM3' 26570'andM3', 'iorM3', 'xorM3' 26571 Similar, for other arithmetic operations. 26572 26573'addvM4' 26574 Like 'addM3' but takes a 'code_label' as operand 3 and emits code 26575 to jump to it if signed overflow occurs during the addition. This 26576 pattern is used to implement the built-in functions performing 26577 signed integer addition with overflow checking. 26578 26579'subvM4', 'mulvM4' 26580 Similar, for other signed arithmetic operations. 26581 26582'uaddvM4' 26583 Like 'addvM4' but for unsigned addition. That is to say, the 26584 operation is the same as signed addition but the jump is taken only 26585 on unsigned overflow. 26586 26587'usubvM4', 'umulvM4' 26588 Similar, for other unsigned arithmetic operations. 26589 26590'addptrM3' 26591 Like 'addM3' but is guaranteed to only be used for address 26592 calculations. The expanded code is not allowed to clobber the 26593 condition code. It only needs to be defined if 'addM3' sets the 26594 condition code. If adds used for address calculations and normal 26595 adds are not compatible it is required to expand a distinct pattern 26596 (e.g. using an unspec). The pattern is used by LRA to emit address 26597 calculations. 'addM3' is used if 'addptrM3' is not defined. 26598 26599'fmaM4' 26600 Multiply operand 2 and operand 1, then add operand 3, storing the 26601 result in operand 0 without doing an intermediate rounding step. 26602 All operands must have mode M. This pattern is used to implement 26603 the 'fma', 'fmaf', and 'fmal' builtin functions from the ISO C99 26604 standard. 26605 26606'fmsM4' 26607 Like 'fmaM4', except operand 3 subtracted from the product instead 26608 of added to the product. This is represented in the rtl as 26609 26610 (fma:M OP1 OP2 (neg:M OP3)) 26611 26612'fnmaM4' 26613 Like 'fmaM4' except that the intermediate product is negated before 26614 being added to operand 3. This is represented in the rtl as 26615 26616 (fma:M (neg:M OP1) OP2 OP3) 26617 26618'fnmsM4' 26619 Like 'fmsM4' except that the intermediate product is negated before 26620 subtracting operand 3. This is represented in the rtl as 26621 26622 (fma:M (neg:M OP1) OP2 (neg:M OP3)) 26623 26624'sminM3', 'smaxM3' 26625 Signed minimum and maximum operations. When used with floating 26626 point, if both operands are zeros, or if either operand is 'NaN', 26627 then it is unspecified which of the two operands is returned as the 26628 result. 26629 26630'fminM3', 'fmaxM3' 26631 IEEE-conformant minimum and maximum operations. If one operand is 26632 a quiet 'NaN', then the other operand is returned. If both 26633 operands are quiet 'NaN', then a quiet 'NaN' is returned. In the 26634 case when gcc supports signaling 'NaN' (-fsignaling-nans) an 26635 invalid floating point exception is raised and a quiet 'NaN' is 26636 returned. 26637 26638 All operands have mode M, which is a scalar or vector 26639 floating-point mode. These patterns are not allowed to 'FAIL'. 26640 26641'reduc_smin_scal_M', 'reduc_smax_scal_M' 26642 Find the signed minimum/maximum of the elements of a vector. The 26643 vector is operand 1, and operand 0 is the scalar result, with mode 26644 equal to the mode of the elements of the input vector. 26645 26646'reduc_umin_scal_M', 'reduc_umax_scal_M' 26647 Find the unsigned minimum/maximum of the elements of a vector. The 26648 vector is operand 1, and operand 0 is the scalar result, with mode 26649 equal to the mode of the elements of the input vector. 26650 26651'reduc_plus_scal_M' 26652 Compute the sum of the elements of a vector. The vector is operand 26653 1, and operand 0 is the scalar result, with mode equal to the mode 26654 of the elements of the input vector. 26655 26656'reduc_and_scal_M' 26657'reduc_ior_scal_M' 26658'reduc_xor_scal_M' 26659 Compute the bitwise 'AND'/'IOR'/'XOR' reduction of the elements of 26660 a vector of mode M. Operand 1 is the vector input and operand 0 is 26661 the scalar result. The mode of the scalar result is the same as 26662 one element of M. 26663 26664'extract_last_M' 26665 Find the last set bit in mask operand 1 and extract the associated 26666 element of vector operand 2. Store the result in scalar operand 0. 26667 Operand 2 has vector mode M while operand 0 has the mode 26668 appropriate for one element of M. Operand 1 has the usual mask 26669 mode for vectors of mode M; see 'TARGET_VECTORIZE_GET_MASK_MODE'. 26670 26671'fold_extract_last_M' 26672 If any bits of mask operand 2 are set, find the last set bit, 26673 extract the associated element from vector operand 3, and store the 26674 result in operand 0. Store operand 1 in operand 0 otherwise. 26675 Operand 3 has mode M and operands 0 and 1 have the mode appropriate 26676 for one element of M. Operand 2 has the usual mask mode for 26677 vectors of mode M; see 'TARGET_VECTORIZE_GET_MASK_MODE'. 26678 26679'fold_left_plus_M' 26680 Take scalar operand 1 and successively add each element from vector 26681 operand 2. Store the result in scalar operand 0. The vector has 26682 mode M and the scalars have the mode appropriate for one element of 26683 M. The operation is strictly in-order: there is no reassociation. 26684 26685'mask_fold_left_plus_M' 26686 Like 'fold_left_plus_M', but takes an additional mask operand 26687 (operand 3) that specifies which elements of the source vector 26688 should be added. 26689 26690'sdot_prodM' 26691'udot_prodM' 26692 Compute the sum of the products of two signed/unsigned elements. 26693 Operand 1 and operand 2 are of the same mode. Their product, which 26694 is of a wider mode, is computed and added to operand 3. Operand 3 26695 is of a mode equal or wider than the mode of the product. The 26696 result is placed in operand 0, which is of the same mode as operand 26697 3. 26698 26699'ssadM' 26700'usadM' 26701 Compute the sum of absolute differences of two signed/unsigned 26702 elements. Operand 1 and operand 2 are of the same mode. Their 26703 absolute difference, which is of a wider mode, is computed and 26704 added to operand 3. Operand 3 is of a mode equal or wider than the 26705 mode of the absolute difference. The result is placed in operand 26706 0, which is of the same mode as operand 3. 26707 26708'widen_ssumM3' 26709'widen_usumM3' 26710 Operands 0 and 2 are of the same mode, which is wider than the mode 26711 of operand 1. Add operand 1 to operand 2 and place the widened 26712 result in operand 0. (This is used express accumulation of 26713 elements into an accumulator of a wider mode.) 26714 26715'smulhsM3' 26716'umulhsM3' 26717 Signed/unsigned multiply high with scale. This is equivalent to 26718 the C code: 26719 narrow op0, op1, op2; 26720 ... 26721 op0 = (narrow) (((wide) op1 * (wide) op2) >> (N / 2 - 1)); 26722 where the sign of 'narrow' determines whether this is a signed or 26723 unsigned operation, and N is the size of 'wide' in bits. 26724 26725'smulhrsM3' 26726'umulhrsM3' 26727 Signed/unsigned multiply high with round and scale. This is 26728 equivalent to the C code: 26729 narrow op0, op1, op2; 26730 ... 26731 op0 = (narrow) (((((wide) op1 * (wide) op2) >> (N / 2 - 2)) + 1) >> 1); 26732 where the sign of 'narrow' determines whether this is a signed or 26733 unsigned operation, and N is the size of 'wide' in bits. 26734 26735'sdiv_pow2M3' 26736'sdiv_pow2M3' 26737 Signed division by power-of-2 immediate. Equivalent to: 26738 signed op0, op1; 26739 ... 26740 op0 = op1 / (1 << imm); 26741 26742'vec_shl_insert_M' 26743 Shift the elements in vector input operand 1 left one element (i.e. 26744 away from element 0) and fill the vacated element 0 with the scalar 26745 in operand 2. Store the result in vector output operand 0. 26746 Operands 0 and 1 have mode M and operand 2 has the mode appropriate 26747 for one element of M. 26748 26749'vec_shl_M' 26750 Whole vector left shift in bits, i.e. away from element 0. Operand 26751 1 is a vector to be shifted. Operand 2 is an integer shift amount 26752 in bits. Operand 0 is where the resulting shifted vector is 26753 stored. The output and input vectors should have the same modes. 26754 26755'vec_shr_M' 26756 Whole vector right shift in bits, i.e. towards element 0. Operand 26757 1 is a vector to be shifted. Operand 2 is an integer shift amount 26758 in bits. Operand 0 is where the resulting shifted vector is 26759 stored. The output and input vectors should have the same modes. 26760 26761'vec_pack_trunc_M' 26762 Narrow (demote) and merge the elements of two vectors. Operands 1 26763 and 2 are vectors of the same mode having N integral or floating 26764 point elements of size S. Operand 0 is the resulting vector in 26765 which 2*N elements of size S/2 are concatenated after narrowing 26766 them down using truncation. 26767 26768'vec_pack_sbool_trunc_M' 26769 Narrow and merge the elements of two vectors. Operands 1 and 2 are 26770 vectors of the same type having N boolean elements. Operand 0 is 26771 the resulting vector in which 2*N elements are concatenated. The 26772 last operand (operand 3) is the number of elements in the output 26773 vector 2*N as a 'CONST_INT'. This instruction pattern is used when 26774 all the vector input and output operands have the same scalar mode 26775 M and thus using 'vec_pack_trunc_M' would be ambiguous. 26776 26777'vec_pack_ssat_M', 'vec_pack_usat_M' 26778 Narrow (demote) and merge the elements of two vectors. Operands 1 26779 and 2 are vectors of the same mode having N integral elements of 26780 size S. Operand 0 is the resulting vector in which the elements of 26781 the two input vectors are concatenated after narrowing them down 26782 using signed/unsigned saturating arithmetic. 26783 26784'vec_pack_sfix_trunc_M', 'vec_pack_ufix_trunc_M' 26785 Narrow, convert to signed/unsigned integral type and merge the 26786 elements of two vectors. Operands 1 and 2 are vectors of the same 26787 mode having N floating point elements of size S. Operand 0 is the 26788 resulting vector in which 2*N elements of size S/2 are 26789 concatenated. 26790 26791'vec_packs_float_M', 'vec_packu_float_M' 26792 Narrow, convert to floating point type and merge the elements of 26793 two vectors. Operands 1 and 2 are vectors of the same mode having 26794 N signed/unsigned integral elements of size S. Operand 0 is the 26795 resulting vector in which 2*N elements of size S/2 are 26796 concatenated. 26797 26798'vec_unpacks_hi_M', 'vec_unpacks_lo_M' 26799 Extract and widen (promote) the high/low part of a vector of signed 26800 integral or floating point elements. The input vector (operand 1) 26801 has N elements of size S. Widen (promote) the high/low elements of 26802 the vector using signed or floating point extension and place the 26803 resulting N/2 values of size 2*S in the output vector (operand 0). 26804 26805'vec_unpacku_hi_M', 'vec_unpacku_lo_M' 26806 Extract and widen (promote) the high/low part of a vector of 26807 unsigned integral elements. The input vector (operand 1) has N 26808 elements of size S. Widen (promote) the high/low elements of the 26809 vector using zero extension and place the resulting N/2 values of 26810 size 2*S in the output vector (operand 0). 26811 26812'vec_unpacks_sbool_hi_M', 'vec_unpacks_sbool_lo_M' 26813 Extract the high/low part of a vector of boolean elements that have 26814 scalar mode M. The input vector (operand 1) has N elements, the 26815 output vector (operand 0) has N/2 elements. The last operand 26816 (operand 2) is the number of elements of the input vector N as a 26817 'CONST_INT'. These patterns are used if both the input and output 26818 vectors have the same scalar mode M and thus using 26819 'vec_unpacks_hi_M' or 'vec_unpacks_lo_M' would be ambiguous. 26820 26821'vec_unpacks_float_hi_M', 'vec_unpacks_float_lo_M' 26822'vec_unpacku_float_hi_M', 'vec_unpacku_float_lo_M' 26823 Extract, convert to floating point type and widen the high/low part 26824 of a vector of signed/unsigned integral elements. The input vector 26825 (operand 1) has N elements of size S. Convert the high/low 26826 elements of the vector using floating point conversion and place 26827 the resulting N/2 values of size 2*S in the output vector (operand 26828 0). 26829 26830'vec_unpack_sfix_trunc_hi_M', 26831'vec_unpack_sfix_trunc_lo_M' 26832'vec_unpack_ufix_trunc_hi_M' 26833'vec_unpack_ufix_trunc_lo_M' 26834 Extract, convert to signed/unsigned integer type and widen the 26835 high/low part of a vector of floating point elements. The input 26836 vector (operand 1) has N elements of size S. Convert the high/low 26837 elements of the vector to integers and place the resulting N/2 26838 values of size 2*S in the output vector (operand 0). 26839 26840'vec_widen_umult_hi_M', 'vec_widen_umult_lo_M' 26841'vec_widen_smult_hi_M', 'vec_widen_smult_lo_M' 26842'vec_widen_umult_even_M', 'vec_widen_umult_odd_M' 26843'vec_widen_smult_even_M', 'vec_widen_smult_odd_M' 26844 Signed/Unsigned widening multiplication. The two inputs (operands 26845 1 and 2) are vectors with N signed/unsigned elements of size S. 26846 Multiply the high/low or even/odd elements of the two vectors, and 26847 put the N/2 products of size 2*S in the output vector (operand 0). 26848 A target shouldn't implement even/odd pattern pair if it is less 26849 efficient than lo/hi one. 26850 26851'vec_widen_ushiftl_hi_M', 'vec_widen_ushiftl_lo_M' 26852'vec_widen_sshiftl_hi_M', 'vec_widen_sshiftl_lo_M' 26853 Signed/Unsigned widening shift left. The first input (operand 1) 26854 is a vector with N signed/unsigned elements of size S. Operand 2 26855 is a constant. Shift the high/low elements of operand 1, and put 26856 the N/2 results of size 2*S in the output vector (operand 0). 26857 26858'vec_widen_uaddl_hi_M', 'vec_widen_uaddl_lo_M' 26859'vec_widen_saddl_hi_M', 'vec_widen_saddl_lo_M' 26860 Signed/Unsigned widening add long. Operands 1 and 2 are vectors 26861 with N signed/unsigned elements of size S. Add the high/low 26862 elements of 1 and 2 together, widen the resulting elements and put 26863 the N/2 results of size 2*S in the output vector (operand 0). 26864 26865'vec_widen_usubl_hi_M', 'vec_widen_usubl_lo_M' 26866'vec_widen_ssubl_hi_M', 'vec_widen_ssubl_lo_M' 26867 Signed/Unsigned widening subtract long. Operands 1 and 2 are 26868 vectors with N signed/unsigned elements of size S. Subtract the 26869 high/low elements of 2 from 1 and widen the resulting elements. 26870 Put the N/2 results of size 2*S in the output vector (operand 0). 26871 26872'mulhisi3' 26873 Multiply operands 1 and 2, which have mode 'HImode', and store a 26874 'SImode' product in operand 0. 26875 26876'mulqihi3', 'mulsidi3' 26877 Similar widening-multiplication instructions of other widths. 26878 26879'umulqihi3', 'umulhisi3', 'umulsidi3' 26880 Similar widening-multiplication instructions that do unsigned 26881 multiplication. 26882 26883'usmulqihi3', 'usmulhisi3', 'usmulsidi3' 26884 Similar widening-multiplication instructions that interpret the 26885 first operand as unsigned and the second operand as signed, then do 26886 a signed multiplication. 26887 26888'smulM3_highpart' 26889 Perform a signed multiplication of operands 1 and 2, which have 26890 mode M, and store the most significant half of the product in 26891 operand 0. The least significant half of the product is discarded. 26892 26893'umulM3_highpart' 26894 Similar, but the multiplication is unsigned. 26895 26896'maddMN4' 26897 Multiply operands 1 and 2, sign-extend them to mode N, add operand 26898 3, and store the result in operand 0. Operands 1 and 2 have mode M 26899 and operands 0 and 3 have mode N. Both modes must be integer or 26900 fixed-point modes and N must be twice the size of M. 26901 26902 In other words, 'maddMN4' is like 'mulMN3' except that it also adds 26903 operand 3. 26904 26905 These instructions are not allowed to 'FAIL'. 26906 26907'umaddMN4' 26908 Like 'maddMN4', but zero-extend the multiplication operands instead 26909 of sign-extending them. 26910 26911'ssmaddMN4' 26912 Like 'maddMN4', but all involved operations must be 26913 signed-saturating. 26914 26915'usmaddMN4' 26916 Like 'umaddMN4', but all involved operations must be 26917 unsigned-saturating. 26918 26919'msubMN4' 26920 Multiply operands 1 and 2, sign-extend them to mode N, subtract the 26921 result from operand 3, and store the result in operand 0. Operands 26922 1 and 2 have mode M and operands 0 and 3 have mode N. Both modes 26923 must be integer or fixed-point modes and N must be twice the size 26924 of M. 26925 26926 In other words, 'msubMN4' is like 'mulMN3' except that it also 26927 subtracts the result from operand 3. 26928 26929 These instructions are not allowed to 'FAIL'. 26930 26931'umsubMN4' 26932 Like 'msubMN4', but zero-extend the multiplication operands instead 26933 of sign-extending them. 26934 26935'ssmsubMN4' 26936 Like 'msubMN4', but all involved operations must be 26937 signed-saturating. 26938 26939'usmsubMN4' 26940 Like 'umsubMN4', but all involved operations must be 26941 unsigned-saturating. 26942 26943'divmodM4' 26944 Signed division that produces both a quotient and a remainder. 26945 Operand 1 is divided by operand 2 to produce a quotient stored in 26946 operand 0 and a remainder stored in operand 3. 26947 26948 For machines with an instruction that produces both a quotient and 26949 a remainder, provide a pattern for 'divmodM4' but do not provide 26950 patterns for 'divM3' and 'modM3'. This allows optimization in the 26951 relatively common case when both the quotient and remainder are 26952 computed. 26953 26954 If an instruction that just produces a quotient or just a remainder 26955 exists and is more efficient than the instruction that produces 26956 both, write the output routine of 'divmodM4' to call 26957 'find_reg_note' and look for a 'REG_UNUSED' note on the quotient or 26958 remainder and generate the appropriate instruction. 26959 26960'udivmodM4' 26961 Similar, but does unsigned division. 26962 26963'ashlM3', 'ssashlM3', 'usashlM3' 26964 Arithmetic-shift operand 1 left by a number of bits specified by 26965 operand 2, and store the result in operand 0. Here M is the mode 26966 of operand 0 and operand 1; operand 2's mode is specified by the 26967 instruction pattern, and the compiler will convert the operand to 26968 that mode before generating the instruction. The shift or rotate 26969 expander or instruction pattern should explicitly specify the mode 26970 of the operand 2, it should never be 'VOIDmode'. The meaning of 26971 out-of-range shift counts can optionally be specified by 26972 'TARGET_SHIFT_TRUNCATION_MASK'. *Note 26973 TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type. 26974 26975'ashrM3', 'lshrM3', 'rotlM3', 'rotrM3' 26976 Other shift and rotate instructions, analogous to the 'ashlM3' 26977 instructions. Operand 2 is always a scalar type. 26978 26979'vashlM3', 'vashrM3', 'vlshrM3', 'vrotlM3', 'vrotrM3' 26980 Vector shift and rotate instructions that take vectors as operand 2 26981 instead of a scalar type. 26982 26983'avgM3_floor' 26984'uavgM3_floor' 26985 Signed and unsigned average instructions. These instructions add 26986 operands 1 and 2 without truncation, divide the result by 2, round 26987 towards -Inf, and store the result in operand 0. This is 26988 equivalent to the C code: 26989 narrow op0, op1, op2; 26990 ... 26991 op0 = (narrow) (((wide) op1 + (wide) op2) >> 1); 26992 where the sign of 'narrow' determines whether this is a signed or 26993 unsigned operation. 26994 26995'avgM3_ceil' 26996'uavgM3_ceil' 26997 Like 'avgM3_floor' and 'uavgM3_floor', but round towards +Inf. 26998 This is equivalent to the C code: 26999 narrow op0, op1, op2; 27000 ... 27001 op0 = (narrow) (((wide) op1 + (wide) op2 + 1) >> 1); 27002 27003'bswapM2' 27004 Reverse the order of bytes of operand 1 and store the result in 27005 operand 0. 27006 27007'negM2', 'ssnegM2', 'usnegM2' 27008 Negate operand 1 and store the result in operand 0. 27009 27010'negvM3' 27011 Like 'negM2' but takes a 'code_label' as operand 2 and emits code 27012 to jump to it if signed overflow occurs during the negation. 27013 27014'absM2' 27015 Store the absolute value of operand 1 into operand 0. 27016 27017'sqrtM2' 27018 Store the square root of operand 1 into operand 0. Both operands 27019 have mode M, which is a scalar or vector floating-point mode. 27020 27021 This pattern is not allowed to 'FAIL'. 27022 27023'rsqrtM2' 27024 Store the reciprocal of the square root of operand 1 into operand 27025 0. Both operands have mode M, which is a scalar or vector 27026 floating-point mode. 27027 27028 On most architectures this pattern is only approximate, so either 27029 its C condition or the 'TARGET_OPTAB_SUPPORTED_P' hook should check 27030 for the appropriate math flags. (Using the C condition is more 27031 direct, but using 'TARGET_OPTAB_SUPPORTED_P' can be useful if a 27032 target-specific built-in also uses the 'rsqrtM2' pattern.) 27033 27034 This pattern is not allowed to 'FAIL'. 27035 27036'fmodM3' 27037 Store the remainder of dividing operand 1 by operand 2 into operand 27038 0, rounded towards zero to an integer. All operands have mode M, 27039 which is a scalar or vector floating-point mode. 27040 27041 This pattern is not allowed to 'FAIL'. 27042 27043'remainderM3' 27044 Store the remainder of dividing operand 1 by operand 2 into operand 27045 0, rounded to the nearest integer. All operands have mode M, which 27046 is a scalar or vector floating-point mode. 27047 27048 This pattern is not allowed to 'FAIL'. 27049 27050'scalbM3' 27051 Raise 'FLT_RADIX' to the power of operand 2, multiply it by operand 27052 1, and store the result in operand 0. All operands have mode M, 27053 which is a scalar or vector floating-point mode. 27054 27055 This pattern is not allowed to 'FAIL'. 27056 27057'ldexpM3' 27058 Raise 2 to the power of operand 2, multiply it by operand 1, and 27059 store the result in operand 0. Operands 0 and 1 have mode M, which 27060 is a scalar or vector floating-point mode. Operand 2's mode has 27061 the same number of elements as M and each element is wide enough to 27062 store an 'int'. The integers are signed. 27063 27064 This pattern is not allowed to 'FAIL'. 27065 27066'cosM2' 27067 Store the cosine of operand 1 into operand 0. Both operands have 27068 mode M, which is a scalar or vector floating-point mode. 27069 27070 This pattern is not allowed to 'FAIL'. 27071 27072'sinM2' 27073 Store the sine of operand 1 into operand 0. Both operands have 27074 mode M, which is a scalar or vector floating-point mode. 27075 27076 This pattern is not allowed to 'FAIL'. 27077 27078'sincosM3' 27079 Store the cosine of operand 2 into operand 0 and the sine of 27080 operand 2 into operand 1. All operands have mode M, which is a 27081 scalar or vector floating-point mode. 27082 27083 Targets that can calculate the sine and cosine simultaneously can 27084 implement this pattern as opposed to implementing individual 27085 'sinM2' and 'cosM2' patterns. The 'sin' and 'cos' built-in 27086 functions will then be expanded to the 'sincosM3' pattern, with one 27087 of the output values left unused. 27088 27089'tanM2' 27090 Store the tangent of operand 1 into operand 0. Both operands have 27091 mode M, which is a scalar or vector floating-point mode. 27092 27093 This pattern is not allowed to 'FAIL'. 27094 27095'asinM2' 27096 Store the arc sine of operand 1 into operand 0. Both operands have 27097 mode M, which is a scalar or vector floating-point mode. 27098 27099 This pattern is not allowed to 'FAIL'. 27100 27101'acosM2' 27102 Store the arc cosine of operand 1 into operand 0. Both operands 27103 have mode M, which is a scalar or vector floating-point mode. 27104 27105 This pattern is not allowed to 'FAIL'. 27106 27107'atanM2' 27108 Store the arc tangent of operand 1 into operand 0. Both operands 27109 have mode M, which is a scalar or vector floating-point mode. 27110 27111 This pattern is not allowed to 'FAIL'. 27112 27113'expM2' 27114 Raise e (the base of natural logarithms) to the power of operand 1 27115 and store the result in operand 0. Both operands have mode M, 27116 which is a scalar or vector floating-point mode. 27117 27118 This pattern is not allowed to 'FAIL'. 27119 27120'expm1M2' 27121 Raise e (the base of natural logarithms) to the power of operand 1, 27122 subtract 1, and store the result in operand 0. Both operands have 27123 mode M, which is a scalar or vector floating-point mode. 27124 27125 For inputs close to zero, the pattern is expected to be more 27126 accurate than a separate 'expM2' and 'subM3' would be. 27127 27128 This pattern is not allowed to 'FAIL'. 27129 27130'exp10M2' 27131 Raise 10 to the power of operand 1 and store the result in operand 27132 0. Both operands have mode M, which is a scalar or vector 27133 floating-point mode. 27134 27135 This pattern is not allowed to 'FAIL'. 27136 27137'exp2M2' 27138 Raise 2 to the power of operand 1 and store the result in operand 27139 0. Both operands have mode M, which is a scalar or vector 27140 floating-point mode. 27141 27142 This pattern is not allowed to 'FAIL'. 27143 27144'logM2' 27145 Store the natural logarithm of operand 1 into operand 0. Both 27146 operands have mode M, which is a scalar or vector floating-point 27147 mode. 27148 27149 This pattern is not allowed to 'FAIL'. 27150 27151'log1pM2' 27152 Add 1 to operand 1, compute the natural logarithm, and store the 27153 result in operand 0. Both operands have mode M, which is a scalar 27154 or vector floating-point mode. 27155 27156 For inputs close to zero, the pattern is expected to be more 27157 accurate than a separate 'addM3' and 'logM2' would be. 27158 27159 This pattern is not allowed to 'FAIL'. 27160 27161'log10M2' 27162 Store the base-10 logarithm of operand 1 into operand 0. Both 27163 operands have mode M, which is a scalar or vector floating-point 27164 mode. 27165 27166 This pattern is not allowed to 'FAIL'. 27167 27168'log2M2' 27169 Store the base-2 logarithm of operand 1 into operand 0. Both 27170 operands have mode M, which is a scalar or vector floating-point 27171 mode. 27172 27173 This pattern is not allowed to 'FAIL'. 27174 27175'logbM2' 27176 Store the base-'FLT_RADIX' logarithm of operand 1 into operand 0. 27177 Both operands have mode M, which is a scalar or vector 27178 floating-point mode. 27179 27180 This pattern is not allowed to 'FAIL'. 27181 27182'significandM2' 27183 Store the significand of floating-point operand 1 in operand 0. 27184 Both operands have mode M, which is a scalar or vector 27185 floating-point mode. 27186 27187 This pattern is not allowed to 'FAIL'. 27188 27189'powM3' 27190 Store the value of operand 1 raised to the exponent operand 2 into 27191 operand 0. All operands have mode M, which is a scalar or vector 27192 floating-point mode. 27193 27194 This pattern is not allowed to 'FAIL'. 27195 27196'atan2M3' 27197 Store the arc tangent (inverse tangent) of operand 1 divided by 27198 operand 2 into operand 0, using the signs of both arguments to 27199 determine the quadrant of the result. All operands have mode M, 27200 which is a scalar or vector floating-point mode. 27201 27202 This pattern is not allowed to 'FAIL'. 27203 27204'floorM2' 27205 Store the largest integral value not greater than operand 1 in 27206 operand 0. Both operands have mode M, which is a scalar or vector 27207 floating-point mode. If '-ffp-int-builtin-inexact' is in effect, 27208 the "inexact" exception may be raised for noninteger operands; 27209 otherwise, it may not. 27210 27211 This pattern is not allowed to 'FAIL'. 27212 27213'btruncM2' 27214 Round operand 1 to an integer, towards zero, and store the result 27215 in operand 0. Both operands have mode M, which is a scalar or 27216 vector floating-point mode. If '-ffp-int-builtin-inexact' is in 27217 effect, the "inexact" exception may be raised for noninteger 27218 operands; otherwise, it may not. 27219 27220 This pattern is not allowed to 'FAIL'. 27221 27222'roundM2' 27223 Round operand 1 to the nearest integer, rounding away from zero in 27224 the event of a tie, and store the result in operand 0. Both 27225 operands have mode M, which is a scalar or vector floating-point 27226 mode. If '-ffp-int-builtin-inexact' is in effect, the "inexact" 27227 exception may be raised for noninteger operands; otherwise, it may 27228 not. 27229 27230 This pattern is not allowed to 'FAIL'. 27231 27232'ceilM2' 27233 Store the smallest integral value not less than operand 1 in 27234 operand 0. Both operands have mode M, which is a scalar or vector 27235 floating-point mode. If '-ffp-int-builtin-inexact' is in effect, 27236 the "inexact" exception may be raised for noninteger operands; 27237 otherwise, it may not. 27238 27239 This pattern is not allowed to 'FAIL'. 27240 27241'nearbyintM2' 27242 Round operand 1 to an integer, using the current rounding mode, and 27243 store the result in operand 0. Do not raise an inexact condition 27244 when the result is different from the argument. Both operands have 27245 mode M, which is a scalar or vector floating-point mode. 27246 27247 This pattern is not allowed to 'FAIL'. 27248 27249'rintM2' 27250 Round operand 1 to an integer, using the current rounding mode, and 27251 store the result in operand 0. Raise an inexact condition when the 27252 result is different from the argument. Both operands have mode M, 27253 which is a scalar or vector floating-point mode. 27254 27255 This pattern is not allowed to 'FAIL'. 27256 27257'lrintMN2' 27258 Convert operand 1 (valid for floating point mode M) to fixed point 27259 mode N as a signed number according to the current rounding mode 27260 and store in operand 0 (which has mode N). 27261 27262'lroundMN2' 27263 Convert operand 1 (valid for floating point mode M) to fixed point 27264 mode N as a signed number rounding to nearest and away from zero 27265 and store in operand 0 (which has mode N). 27266 27267'lfloorMN2' 27268 Convert operand 1 (valid for floating point mode M) to fixed point 27269 mode N as a signed number rounding down and store in operand 0 27270 (which has mode N). 27271 27272'lceilMN2' 27273 Convert operand 1 (valid for floating point mode M) to fixed point 27274 mode N as a signed number rounding up and store in operand 0 (which 27275 has mode N). 27276 27277'copysignM3' 27278 Store a value with the magnitude of operand 1 and the sign of 27279 operand 2 into operand 0. All operands have mode M, which is a 27280 scalar or vector floating-point mode. 27281 27282 This pattern is not allowed to 'FAIL'. 27283 27284'xorsignM3' 27285 Equivalent to 'op0 = op1 * copysign (1.0, op2)': store a value with 27286 the magnitude of operand 1 and the sign of operand 2 into operand 27287 0. All operands have mode M, which is a scalar or vector 27288 floating-point mode. 27289 27290 This pattern is not allowed to 'FAIL'. 27291 27292'cadd90M3' 27293 Perform vector add and subtract on even/odd number pairs. The 27294 operation being matched is semantically described as 27295 27296 for (int i = 0; i < N; i += 2) 27297 { 27298 c[i] = a[i] - b[i+1]; 27299 c[i+1] = a[i+1] + b[i]; 27300 } 27301 27302 This operation is semantically equivalent to performing a vector 27303 addition of complex numbers in operand 1 with operand 2 rotated by 27304 90 degrees around the argand plane and storing the result in 27305 operand 0. 27306 27307 In GCC lane ordering the real part of the number must be in the 27308 even lanes with the imaginary part in the odd lanes. 27309 27310 The operation is only supported for vector modes M. 27311 27312 This pattern is not allowed to 'FAIL'. 27313 27314'cadd270M3' 27315 Perform vector add and subtract on even/odd number pairs. The 27316 operation being matched is semantically described as 27317 27318 for (int i = 0; i < N; i += 2) 27319 { 27320 c[i] = a[i] + b[i+1]; 27321 c[i+1] = a[i+1] - b[i]; 27322 } 27323 27324 This operation is semantically equivalent to performing a vector 27325 addition of complex numbers in operand 1 with operand 2 rotated by 27326 270 degrees around the argand plane and storing the result in 27327 operand 0. 27328 27329 In GCC lane ordering the real part of the number must be in the 27330 even lanes with the imaginary part in the odd lanes. 27331 27332 The operation is only supported for vector modes M. 27333 27334 This pattern is not allowed to 'FAIL'. 27335 27336'cmlaM4' 27337 Perform a vector multiply and accumulate that is semantically the 27338 same as a multiply and accumulate of complex numbers. 27339 27340 complex TYPE c[N]; 27341 complex TYPE a[N]; 27342 complex TYPE b[N]; 27343 for (int i = 0; i < N; i += 1) 27344 { 27345 c[i] += a[i] * b[i]; 27346 } 27347 27348 In GCC lane ordering the real part of the number must be in the 27349 even lanes with the imaginary part in the odd lanes. 27350 27351 The operation is only supported for vector modes M. 27352 27353 This pattern is not allowed to 'FAIL'. 27354 27355'cmla_conjM4' 27356 Perform a vector multiply by conjugate and accumulate that is 27357 semantically the same as a multiply and accumulate of complex 27358 numbers where the second multiply arguments is conjugated. 27359 27360 complex TYPE c[N]; 27361 complex TYPE a[N]; 27362 complex TYPE b[N]; 27363 for (int i = 0; i < N; i += 1) 27364 { 27365 c[i] += a[i] * conj (b[i]); 27366 } 27367 27368 In GCC lane ordering the real part of the number must be in the 27369 even lanes with the imaginary part in the odd lanes. 27370 27371 The operation is only supported for vector modes M. 27372 27373 This pattern is not allowed to 'FAIL'. 27374 27375'cmlsM4' 27376 Perform a vector multiply and subtract that is semantically the 27377 same as a multiply and subtract of complex numbers. 27378 27379 complex TYPE c[N]; 27380 complex TYPE a[N]; 27381 complex TYPE b[N]; 27382 for (int i = 0; i < N; i += 1) 27383 { 27384 c[i] -= a[i] * b[i]; 27385 } 27386 27387 In GCC lane ordering the real part of the number must be in the 27388 even lanes with the imaginary part in the odd lanes. 27389 27390 The operation is only supported for vector modes M. 27391 27392 This pattern is not allowed to 'FAIL'. 27393 27394'cmls_conjM4' 27395 Perform a vector multiply by conjugate and subtract that is 27396 semantically the same as a multiply and subtract of complex numbers 27397 where the second multiply arguments is conjugated. 27398 27399 complex TYPE c[N]; 27400 complex TYPE a[N]; 27401 complex TYPE b[N]; 27402 for (int i = 0; i < N; i += 1) 27403 { 27404 c[i] -= a[i] * conj (b[i]); 27405 } 27406 27407 In GCC lane ordering the real part of the number must be in the 27408 even lanes with the imaginary part in the odd lanes. 27409 27410 The operation is only supported for vector modes M. 27411 27412 This pattern is not allowed to 'FAIL'. 27413 27414'cmulM4' 27415 Perform a vector multiply that is semantically the same as multiply 27416 of complex numbers. 27417 27418 complex TYPE c[N]; 27419 complex TYPE a[N]; 27420 complex TYPE b[N]; 27421 for (int i = 0; i < N; i += 1) 27422 { 27423 c[i] = a[i] * b[i]; 27424 } 27425 27426 In GCC lane ordering the real part of the number must be in the 27427 even lanes with the imaginary part in the odd lanes. 27428 27429 The operation is only supported for vector modes M. 27430 27431 This pattern is not allowed to 'FAIL'. 27432 27433'cmul_conjM4' 27434 Perform a vector multiply by conjugate that is semantically the 27435 same as a multiply of complex numbers where the second multiply 27436 arguments is conjugated. 27437 27438 complex TYPE c[N]; 27439 complex TYPE a[N]; 27440 complex TYPE b[N]; 27441 for (int i = 0; i < N; i += 1) 27442 { 27443 c[i] = a[i] * conj (b[i]); 27444 } 27445 27446 In GCC lane ordering the real part of the number must be in the 27447 even lanes with the imaginary part in the odd lanes. 27448 27449 The operation is only supported for vector modes M. 27450 27451 This pattern is not allowed to 'FAIL'. 27452 27453'ffsM2' 27454 Store into operand 0 one plus the index of the least significant 27455 1-bit of operand 1. If operand 1 is zero, store zero. 27456 27457 M is either a scalar or vector integer mode. When it is a scalar, 27458 operand 1 has mode M but operand 0 can have whatever scalar integer 27459 mode is suitable for the target. The compiler will insert 27460 conversion instructions as necessary (typically to convert the 27461 result to the same width as 'int'). When M is a vector, both 27462 operands must have mode M. 27463 27464 This pattern is not allowed to 'FAIL'. 27465 27466'clrsbM2' 27467 Count leading redundant sign bits. Store into operand 0 the number 27468 of redundant sign bits in operand 1, starting at the most 27469 significant bit position. A redundant sign bit is defined as any 27470 sign bit after the first. As such, this count will be one less 27471 than the count of leading sign bits. 27472 27473 M is either a scalar or vector integer mode. When it is a scalar, 27474 operand 1 has mode M but operand 0 can have whatever scalar integer 27475 mode is suitable for the target. The compiler will insert 27476 conversion instructions as necessary (typically to convert the 27477 result to the same width as 'int'). When M is a vector, both 27478 operands must have mode M. 27479 27480 This pattern is not allowed to 'FAIL'. 27481 27482'clzM2' 27483 Store into operand 0 the number of leading 0-bits in operand 1, 27484 starting at the most significant bit position. If operand 1 is 0, 27485 the 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 27486 result is undefined or has a useful value. 27487 27488 M is either a scalar or vector integer mode. When it is a scalar, 27489 operand 1 has mode M but operand 0 can have whatever scalar integer 27490 mode is suitable for the target. The compiler will insert 27491 conversion instructions as necessary (typically to convert the 27492 result to the same width as 'int'). When M is a vector, both 27493 operands must have mode M. 27494 27495 This pattern is not allowed to 'FAIL'. 27496 27497'ctzM2' 27498 Store into operand 0 the number of trailing 0-bits in operand 1, 27499 starting at the least significant bit position. If operand 1 is 0, 27500 the 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 27501 result is undefined or has a useful value. 27502 27503 M is either a scalar or vector integer mode. When it is a scalar, 27504 operand 1 has mode M but operand 0 can have whatever scalar integer 27505 mode is suitable for the target. The compiler will insert 27506 conversion instructions as necessary (typically to convert the 27507 result to the same width as 'int'). When M is a vector, both 27508 operands must have mode M. 27509 27510 This pattern is not allowed to 'FAIL'. 27511 27512'popcountM2' 27513 Store into operand 0 the number of 1-bits in operand 1. 27514 27515 M is either a scalar or vector integer mode. When it is a scalar, 27516 operand 1 has mode M but operand 0 can have whatever scalar integer 27517 mode is suitable for the target. The compiler will insert 27518 conversion instructions as necessary (typically to convert the 27519 result to the same width as 'int'). When M is a vector, both 27520 operands must have mode M. 27521 27522 This pattern is not allowed to 'FAIL'. 27523 27524'parityM2' 27525 Store into operand 0 the parity of operand 1, i.e. the number of 27526 1-bits in operand 1 modulo 2. 27527 27528 M is either a scalar or vector integer mode. When it is a scalar, 27529 operand 1 has mode M but operand 0 can have whatever scalar integer 27530 mode is suitable for the target. The compiler will insert 27531 conversion instructions as necessary (typically to convert the 27532 result to the same width as 'int'). When M is a vector, both 27533 operands must have mode M. 27534 27535 This pattern is not allowed to 'FAIL'. 27536 27537'one_cmplM2' 27538 Store the bitwise-complement of operand 1 into operand 0. 27539 27540'cpymemM' 27541 Block copy instruction. The destination and source blocks of 27542 memory are the first two operands, and both are 'mem:BLK's with an 27543 address in mode 'Pmode'. 27544 27545 The number of bytes to copy is the third operand, in mode M. 27546 Usually, you specify 'Pmode' for M. However, if you can generate 27547 better code knowing the range of valid lengths is smaller than 27548 those representable in a full Pmode pointer, you should provide a 27549 pattern with a mode corresponding to the range of values you can 27550 handle efficiently (e.g., 'QImode' for values in the range 0-127; 27551 note we avoid numbers that appear negative) and also a pattern with 27552 'Pmode'. 27553 27554 The fourth operand is the known shared alignment of the source and 27555 destination, in the form of a 'const_int' rtx. Thus, if the 27556 compiler knows that both source and destination are word-aligned, 27557 it may provide the value 4 for this operand. 27558 27559 Optional operands 5 and 6 specify expected alignment and size of 27560 block respectively. The expected alignment differs from alignment 27561 in operand 4 in a way that the blocks are not required to be 27562 aligned according to it in all cases. This expected alignment is 27563 also in bytes, just like operand 4. Expected size, when unknown, 27564 is set to '(const_int -1)'. 27565 27566 Descriptions of multiple 'cpymemM' patterns can only be beneficial 27567 if the patterns for smaller modes have fewer restrictions on their 27568 first, second and fourth operands. Note that the mode M in 27569 'cpymemM' does not impose any restriction on the mode of 27570 individually copied data units in the block. 27571 27572 The 'cpymemM' patterns need not give special consideration to the 27573 possibility that the source and destination strings might overlap. 27574 These patterns are used to do inline expansion of 27575 '__builtin_memcpy'. 27576 27577'movmemM' 27578 Block move instruction. The destination and source blocks of 27579 memory are the first two operands, and both are 'mem:BLK's with an 27580 address in mode 'Pmode'. 27581 27582 The number of bytes to copy is the third operand, in mode M. 27583 Usually, you specify 'Pmode' for M. However, if you can generate 27584 better code knowing the range of valid lengths is smaller than 27585 those representable in a full Pmode pointer, you should provide a 27586 pattern with a mode corresponding to the range of values you can 27587 handle efficiently (e.g., 'QImode' for values in the range 0-127; 27588 note we avoid numbers that appear negative) and also a pattern with 27589 'Pmode'. 27590 27591 The fourth operand is the known shared alignment of the source and 27592 destination, in the form of a 'const_int' rtx. Thus, if the 27593 compiler knows that both source and destination are word-aligned, 27594 it may provide the value 4 for this operand. 27595 27596 Optional operands 5 and 6 specify expected alignment and size of 27597 block respectively. The expected alignment differs from alignment 27598 in operand 4 in a way that the blocks are not required to be 27599 aligned according to it in all cases. This expected alignment is 27600 also in bytes, just like operand 4. Expected size, when unknown, 27601 is set to '(const_int -1)'. 27602 27603 Descriptions of multiple 'movmemM' patterns can only be beneficial 27604 if the patterns for smaller modes have fewer restrictions on their 27605 first, second and fourth operands. Note that the mode M in 27606 'movmemM' does not impose any restriction on the mode of 27607 individually copied data units in the block. 27608 27609 The 'movmemM' patterns must correctly handle the case where the 27610 source and destination strings overlap. These patterns are used to 27611 do inline expansion of '__builtin_memmove'. 27612 27613'movstr' 27614 String copy instruction, with 'stpcpy' semantics. Operand 0 is an 27615 output operand in mode 'Pmode'. The addresses of the destination 27616 and source strings are operands 1 and 2, and both are 'mem:BLK's 27617 with addresses in mode 'Pmode'. The execution of the expansion of 27618 this pattern should store in operand 0 the address in which the 27619 'NUL' terminator was stored in the destination string. 27620 27621 This pattern has also several optional operands that are same as in 27622 'setmem'. 27623 27624'setmemM' 27625 Block set instruction. The destination string is the first 27626 operand, given as a 'mem:BLK' whose address is in mode 'Pmode'. 27627 The number of bytes to set is the second operand, in mode M. The 27628 value to initialize the memory with is the third operand. Targets 27629 that only support the clearing of memory should reject any value 27630 that is not the constant 0. See 'cpymemM' for a discussion of the 27631 choice of mode. 27632 27633 The fourth operand is the known alignment of the destination, in 27634 the form of a 'const_int' rtx. Thus, if the compiler knows that 27635 the destination is word-aligned, it may provide the value 4 for 27636 this operand. 27637 27638 Optional operands 5 and 6 specify expected alignment and size of 27639 block respectively. The expected alignment differs from alignment 27640 in operand 4 in a way that the blocks are not required to be 27641 aligned according to it in all cases. This expected alignment is 27642 also in bytes, just like operand 4. Expected size, when unknown, 27643 is set to '(const_int -1)'. Operand 7 is the minimal size of the 27644 block and operand 8 is the maximal size of the block (NULL if it 27645 cannot be represented as CONST_INT). Operand 9 is the probable 27646 maximal size (i.e. we cannot rely on it for correctness, but it can 27647 be used for choosing proper code sequence for a given size). 27648 27649 The use for multiple 'setmemM' is as for 'cpymemM'. 27650 27651'cmpstrnM' 27652 String compare instruction, with five operands. Operand 0 is the 27653 output; it has mode M. The remaining four operands are like the 27654 operands of 'cpymemM'. The two memory blocks specified are 27655 compared byte by byte in lexicographic order starting at the 27656 beginning of each string. The instruction is not allowed to 27657 prefetch more than one byte at a time since either string may end 27658 in the first byte and reading past that may access an invalid page 27659 or segment and cause a fault. The comparison terminates early if 27660 the fetched bytes are different or if they are equal to zero. The 27661 effect of the instruction is to store a value in operand 0 whose 27662 sign indicates the result of the comparison. 27663 27664'cmpstrM' 27665 String compare instruction, without known maximum length. Operand 27666 0 is the output; it has mode M. The second and third operand are 27667 the blocks of memory to be compared; both are 'mem:BLK' with an 27668 address in mode 'Pmode'. 27669 27670 The fourth operand is the known shared alignment of the source and 27671 destination, in the form of a 'const_int' rtx. Thus, if the 27672 compiler knows that both source and destination are word-aligned, 27673 it may provide the value 4 for this operand. 27674 27675 The two memory blocks specified are compared byte by byte in 27676 lexicographic order starting at the beginning of each string. The 27677 instruction is not allowed to prefetch more than one byte at a time 27678 since either string may end in the first byte and reading past that 27679 may access an invalid page or segment and cause a fault. The 27680 comparison will terminate when the fetched bytes are different or 27681 if they are equal to zero. The effect of the instruction is to 27682 store a value in operand 0 whose sign indicates the result of the 27683 comparison. 27684 27685'cmpmemM' 27686 Block compare instruction, with five operands like the operands of 27687 'cmpstrM'. The two memory blocks specified are compared byte by 27688 byte in lexicographic order starting at the beginning of each 27689 block. Unlike 'cmpstrM' the instruction can prefetch any bytes in 27690 the two memory blocks. Also unlike 'cmpstrM' the comparison will 27691 not stop if both bytes are zero. The effect of the instruction is 27692 to store a value in operand 0 whose sign indicates the result of 27693 the comparison. 27694 27695'strlenM' 27696 Compute the length of a string, with three operands. Operand 0 is 27697 the result (of mode M), operand 1 is a 'mem' referring to the first 27698 character of the string, operand 2 is the character to search for 27699 (normally zero), and operand 3 is a constant describing the known 27700 alignment of the beginning of the string. 27701 27702'floatMN2' 27703 Convert signed integer operand 1 (valid for fixed point mode M) to 27704 floating point mode N and store in operand 0 (which has mode N). 27705 27706'floatunsMN2' 27707 Convert unsigned integer operand 1 (valid for fixed point mode M) 27708 to floating point mode N and store in operand 0 (which has mode N). 27709 27710'fixMN2' 27711 Convert operand 1 (valid for floating point mode M) to fixed point 27712 mode N as a signed number and store in operand 0 (which has mode 27713 N). This instruction's result is defined only when the value of 27714 operand 1 is an integer. 27715 27716 If the machine description defines this pattern, it also needs to 27717 define the 'ftrunc' pattern. 27718 27719'fixunsMN2' 27720 Convert operand 1 (valid for floating point mode M) to fixed point 27721 mode N as an unsigned number and store in operand 0 (which has mode 27722 N). This instruction's result is defined only when the value of 27723 operand 1 is an integer. 27724 27725'ftruncM2' 27726 Convert operand 1 (valid for floating point mode M) to an integer 27727 value, still represented in floating point mode M, and store it in 27728 operand 0 (valid for floating point mode M). 27729 27730'fix_truncMN2' 27731 Like 'fixMN2' but works for any floating point value of mode M by 27732 converting the value to an integer. 27733 27734'fixuns_truncMN2' 27735 Like 'fixunsMN2' but works for any floating point value of mode M 27736 by converting the value to an integer. 27737 27738'truncMN2' 27739 Truncate operand 1 (valid for mode M) to mode N and store in 27740 operand 0 (which has mode N). Both modes must be fixed point or 27741 both floating point. 27742 27743'extendMN2' 27744 Sign-extend operand 1 (valid for mode M) to mode N and store in 27745 operand 0 (which has mode N). Both modes must be fixed point or 27746 both floating point. 27747 27748'zero_extendMN2' 27749 Zero-extend operand 1 (valid for mode M) to mode N and store in 27750 operand 0 (which has mode N). Both modes must be fixed point. 27751 27752'fractMN2' 27753 Convert operand 1 of mode M to mode N and store in operand 0 (which 27754 has mode N). Mode M and mode N could be fixed-point to 27755 fixed-point, signed integer to fixed-point, fixed-point to signed 27756 integer, floating-point to fixed-point, or fixed-point to 27757 floating-point. When overflows or underflows happen, the results 27758 are undefined. 27759 27760'satfractMN2' 27761 Convert operand 1 of mode M to mode N and store in operand 0 (which 27762 has mode N). Mode M and mode N could be fixed-point to 27763 fixed-point, signed integer to fixed-point, or floating-point to 27764 fixed-point. When overflows or underflows happen, the instruction 27765 saturates the results to the maximum or the minimum. 27766 27767'fractunsMN2' 27768 Convert operand 1 of mode M to mode N and store in operand 0 (which 27769 has mode N). Mode M and mode N could be unsigned integer to 27770 fixed-point, or fixed-point to unsigned integer. When overflows or 27771 underflows happen, the results are undefined. 27772 27773'satfractunsMN2' 27774 Convert unsigned integer operand 1 of mode M to fixed-point mode N 27775 and store in operand 0 (which has mode N). When overflows or 27776 underflows happen, the instruction saturates the results to the 27777 maximum or the minimum. 27778 27779'extvM' 27780 Extract a bit-field from register operand 1, sign-extend it, and 27781 store it in operand 0. Operand 2 specifies the width of the field 27782 in bits and operand 3 the starting bit, which counts from the most 27783 significant bit if 'BITS_BIG_ENDIAN' is true and from the least 27784 significant bit otherwise. 27785 27786 Operands 0 and 1 both have mode M. Operands 2 and 3 have a 27787 target-specific mode. 27788 27789'extvmisalignM' 27790 Extract a bit-field from memory operand 1, sign extend it, and 27791 store it in operand 0. Operand 2 specifies the width in bits and 27792 operand 3 the starting bit. The starting bit is always somewhere 27793 in the first byte of operand 1; it counts from the most significant 27794 bit if 'BITS_BIG_ENDIAN' is true and from the least significant bit 27795 otherwise. 27796 27797 Operand 0 has mode M while operand 1 has 'BLK' mode. Operands 2 27798 and 3 have a target-specific mode. 27799 27800 The instruction must not read beyond the last byte of the 27801 bit-field. 27802 27803'extzvM' 27804 Like 'extvM' except that the bit-field value is zero-extended. 27805 27806'extzvmisalignM' 27807 Like 'extvmisalignM' except that the bit-field value is 27808 zero-extended. 27809 27810'insvM' 27811 Insert operand 3 into a bit-field of register operand 0. Operand 1 27812 specifies the width of the field in bits and operand 2 the starting 27813 bit, which counts from the most significant bit if 27814 'BITS_BIG_ENDIAN' is true and from the least significant bit 27815 otherwise. 27816 27817 Operands 0 and 3 both have mode M. Operands 1 and 2 have a 27818 target-specific mode. 27819 27820'insvmisalignM' 27821 Insert operand 3 into a bit-field of memory operand 0. Operand 1 27822 specifies the width of the field in bits and operand 2 the starting 27823 bit. The starting bit is always somewhere in the first byte of 27824 operand 0; it counts from the most significant bit if 27825 'BITS_BIG_ENDIAN' is true and from the least significant bit 27826 otherwise. 27827 27828 Operand 3 has mode M while operand 0 has 'BLK' mode. Operands 1 27829 and 2 have a target-specific mode. 27830 27831 The instruction must not read or write beyond the last byte of the 27832 bit-field. 27833 27834'extv' 27835 Extract a bit-field from operand 1 (a register or memory operand), 27836 where operand 2 specifies the width in bits and operand 3 the 27837 starting bit, and store it in operand 0. Operand 0 must have mode 27838 'word_mode'. Operand 1 may have mode 'byte_mode' or 'word_mode'; 27839 often 'word_mode' is allowed only for registers. Operands 2 and 3 27840 must be valid for 'word_mode'. 27841 27842 The RTL generation pass generates this instruction only with 27843 constants for operands 2 and 3 and the constant is never zero for 27844 operand 2. 27845 27846 The bit-field value is sign-extended to a full word integer before 27847 it is stored in operand 0. 27848 27849 This pattern is deprecated; please use 'extvM' and 'extvmisalignM' 27850 instead. 27851 27852'extzv' 27853 Like 'extv' except that the bit-field value is zero-extended. 27854 27855 This pattern is deprecated; please use 'extzvM' and 27856 'extzvmisalignM' instead. 27857 27858'insv' 27859 Store operand 3 (which must be valid for 'word_mode') into a 27860 bit-field in operand 0, where operand 1 specifies the width in bits 27861 and operand 2 the starting bit. Operand 0 may have mode 27862 'byte_mode' or 'word_mode'; often 'word_mode' is allowed only for 27863 registers. Operands 1 and 2 must be valid for 'word_mode'. 27864 27865 The RTL generation pass generates this instruction only with 27866 constants for operands 1 and 2 and the constant is never zero for 27867 operand 1. 27868 27869 This pattern is deprecated; please use 'insvM' and 'insvmisalignM' 27870 instead. 27871 27872'movMODEcc' 27873 Conditionally move operand 2 or operand 3 into operand 0 according 27874 to the comparison in operand 1. If the comparison is true, operand 27875 2 is moved into operand 0, otherwise operand 3 is moved. 27876 27877 The mode of the operands being compared need not be the same as the 27878 operands being moved. Some machines, sparc64 for example, have 27879 instructions that conditionally move an integer value based on the 27880 floating point condition codes and vice versa. 27881 27882 If the machine does not have conditional move instructions, do not 27883 define these patterns. 27884 27885'addMODEcc' 27886 Similar to 'movMODEcc' but for conditional addition. Conditionally 27887 move operand 2 or (operands 2 + operand 3) into operand 0 according 27888 to the comparison in operand 1. If the comparison is false, 27889 operand 2 is moved into operand 0, otherwise (operand 2 + operand 27890 3) is moved. 27891 27892'cond_addMODE' 27893'cond_subMODE' 27894'cond_mulMODE' 27895'cond_divMODE' 27896'cond_udivMODE' 27897'cond_modMODE' 27898'cond_umodMODE' 27899'cond_andMODE' 27900'cond_iorMODE' 27901'cond_xorMODE' 27902'cond_sminMODE' 27903'cond_smaxMODE' 27904'cond_uminMODE' 27905'cond_umaxMODE' 27906 When operand 1 is true, perform an operation on operands 2 and 3 27907 and store the result in operand 0, otherwise store operand 4 in 27908 operand 0. The operation works elementwise if the operands are 27909 vectors. 27910 27911 The scalar case is equivalent to: 27912 27913 op0 = op1 ? op2 OP op3 : op4; 27914 27915 while the vector case is equivalent to: 27916 27917 for (i = 0; i < GET_MODE_NUNITS (M); i++) 27918 op0[i] = op1[i] ? op2[i] OP op3[i] : op4[i]; 27919 27920 where, for example, OP is '+' for 'cond_addMODE'. 27921 27922 When defined for floating-point modes, the contents of 'op3[i]' are 27923 not interpreted if 'op1[i]' is false, just like they would not be 27924 in a normal C '?:' condition. 27925 27926 Operands 0, 2, 3 and 4 all have mode M. Operand 1 is a scalar 27927 integer if M is scalar, otherwise it has the mode returned by 27928 'TARGET_VECTORIZE_GET_MASK_MODE'. 27929 27930'cond_fmaMODE' 27931'cond_fmsMODE' 27932'cond_fnmaMODE' 27933'cond_fnmsMODE' 27934 Like 'cond_addM', except that the conditional operation takes 3 27935 operands rather than two. For example, the vector form of 27936 'cond_fmaMODE' is equivalent to: 27937 27938 for (i = 0; i < GET_MODE_NUNITS (M); i++) 27939 op0[i] = op1[i] ? fma (op2[i], op3[i], op4[i]) : op5[i]; 27940 27941'negMODEcc' 27942 Similar to 'movMODEcc' but for conditional negation. Conditionally 27943 move the negation of operand 2 or the unchanged operand 3 into 27944 operand 0 according to the comparison in operand 1. If the 27945 comparison is true, the negation of operand 2 is moved into operand 27946 0, otherwise operand 3 is moved. 27947 27948'notMODEcc' 27949 Similar to 'negMODEcc' but for conditional complement. 27950 Conditionally move the bitwise complement of operand 2 or the 27951 unchanged operand 3 into operand 0 according to the comparison in 27952 operand 1. If the comparison is true, the complement of operand 2 27953 is moved into operand 0, otherwise operand 3 is moved. 27954 27955'cstoreMODE4' 27956 Store zero or nonzero in operand 0 according to whether a 27957 comparison is true. Operand 1 is a comparison operator. Operand 2 27958 and operand 3 are the first and second operand of the comparison, 27959 respectively. You specify the mode that operand 0 must have when 27960 you write the 'match_operand' expression. The compiler 27961 automatically sees which mode you have used and supplies an operand 27962 of that mode. 27963 27964 The value stored for a true condition must have 1 as its low bit, 27965 or else must be negative. Otherwise the instruction is not 27966 suitable and you should omit it from the machine description. You 27967 describe to the compiler exactly which value is stored by defining 27968 the macro 'STORE_FLAG_VALUE' (*note Misc::). If a description 27969 cannot be found that can be used for all the possible comparison 27970 operators, you should pick one and use a 'define_expand' to map all 27971 results onto the one you chose. 27972 27973 These operations may 'FAIL', but should do so only in relatively 27974 uncommon cases; if they would 'FAIL' for common cases involving 27975 integer comparisons, it is best to restrict the predicates to not 27976 allow these operands. Likewise if a given comparison operator will 27977 always fail, independent of the operands (for floating-point modes, 27978 the 'ordered_comparison_operator' predicate is often useful in this 27979 case). 27980 27981 If this pattern is omitted, the compiler will generate a 27982 conditional branch--for example, it may copy a constant one to the 27983 target and branching around an assignment of zero to the target--or 27984 a libcall. If the predicate for operand 1 only rejects some 27985 operators, it will also try reordering the operands and/or 27986 inverting the result value (e.g. by an exclusive OR). These 27987 possibilities could be cheaper or equivalent to the instructions 27988 used for the 'cstoreMODE4' pattern followed by those required to 27989 convert a positive result from 'STORE_FLAG_VALUE' to 1; in this 27990 case, you can and should make operand 1's predicate reject some 27991 operators in the 'cstoreMODE4' pattern, or remove the pattern 27992 altogether from the machine description. 27993 27994'cbranchMODE4' 27995 Conditional branch instruction combined with a compare instruction. 27996 Operand 0 is a comparison operator. Operand 1 and operand 2 are 27997 the first and second operands of the comparison, respectively. 27998 Operand 3 is the 'code_label' to jump to. 27999 28000'jump' 28001 A jump inside a function; an unconditional branch. Operand 0 is 28002 the 'code_label' to jump to. This pattern name is mandatory on all 28003 machines. 28004 28005'call' 28006 Subroutine call instruction returning no value. Operand 0 is the 28007 function to call; operand 1 is the number of bytes of arguments 28008 pushed as a 'const_int'; operand 2 is the number of registers used 28009 as operands. 28010 28011 On most machines, operand 2 is not actually stored into the RTL 28012 pattern. It is supplied for the sake of some RISC machines which 28013 need to put this information into the assembler code; they can put 28014 it in the RTL instead of operand 1. 28015 28016 Operand 0 should be a 'mem' RTX whose address is the address of the 28017 function. Note, however, that this address can be a 'symbol_ref' 28018 expression even if it would not be a legitimate memory address on 28019 the target machine. If it is also not a valid argument for a call 28020 instruction, the pattern for this operation should be a 28021 'define_expand' (*note Expander Definitions::) that places the 28022 address into a register and uses that register in the call 28023 instruction. 28024 28025'call_value' 28026 Subroutine call instruction returning a value. Operand 0 is the 28027 hard register in which the value is returned. There are three more 28028 operands, the same as the three operands of the 'call' instruction 28029 (but with numbers increased by one). 28030 28031 Subroutines that return 'BLKmode' objects use the 'call' insn. 28032 28033'call_pop', 'call_value_pop' 28034 Similar to 'call' and 'call_value', except used if defined and if 28035 'RETURN_POPS_ARGS' is nonzero. They should emit a 'parallel' that 28036 contains both the function call and a 'set' to indicate the 28037 adjustment made to the frame pointer. 28038 28039 For machines where 'RETURN_POPS_ARGS' can be nonzero, the use of 28040 these patterns increases the number of functions for which the 28041 frame pointer can be eliminated, if desired. 28042 28043'untyped_call' 28044 Subroutine call instruction returning a value of any type. Operand 28045 0 is the function to call; operand 1 is a memory location where the 28046 result of calling the function is to be stored; operand 2 is a 28047 'parallel' expression where each element is a 'set' expression that 28048 indicates the saving of a function return value into the result 28049 block. 28050 28051 This instruction pattern should be defined to support 28052 '__builtin_apply' on machines where special instructions are needed 28053 to call a subroutine with arbitrary arguments or to save the value 28054 returned. This instruction pattern is required on machines that 28055 have multiple registers that can hold a return value (i.e. 28056 'FUNCTION_VALUE_REGNO_P' is true for more than one register). 28057 28058'return' 28059 Subroutine return instruction. This instruction pattern name 28060 should be defined only if a single instruction can do all the work 28061 of returning from a function. 28062 28063 Like the 'movM' patterns, this pattern is also used after the RTL 28064 generation phase. In this case it is to support machines where 28065 multiple instructions are usually needed to return from a function, 28066 but some class of functions only requires one instruction to 28067 implement a return. Normally, the applicable functions are those 28068 which do not need to save any registers or allocate stack space. 28069 28070 It is valid for this pattern to expand to an instruction using 28071 'simple_return' if no epilogue is required. 28072 28073'simple_return' 28074 Subroutine return instruction. This instruction pattern name 28075 should be defined only if a single instruction can do all the work 28076 of returning from a function on a path where no epilogue is 28077 required. This pattern is very similar to the 'return' instruction 28078 pattern, but it is emitted only by the shrink-wrapping optimization 28079 on paths where the function prologue has not been executed, and a 28080 function return should occur without any of the effects of the 28081 epilogue. Additional uses may be introduced on paths where both 28082 the prologue and the epilogue have executed. 28083 28084 For such machines, the condition specified in this pattern should 28085 only be true when 'reload_completed' is nonzero and the function's 28086 epilogue would only be a single instruction. For machines with 28087 register windows, the routine 'leaf_function_p' may be used to 28088 determine if a register window push is required. 28089 28090 Machines that have conditional return instructions should define 28091 patterns such as 28092 28093 (define_insn "" 28094 [(set (pc) 28095 (if_then_else (match_operator 28096 0 "comparison_operator" 28097 [(cc0) (const_int 0)]) 28098 (return) 28099 (pc)))] 28100 "CONDITION" 28101 "...") 28102 28103 where CONDITION would normally be the same condition specified on 28104 the named 'return' pattern. 28105 28106'untyped_return' 28107 Untyped subroutine return instruction. This instruction pattern 28108 should be defined to support '__builtin_return' on machines where 28109 special instructions are needed to return a value of any type. 28110 28111 Operand 0 is a memory location where the result of calling a 28112 function with '__builtin_apply' is stored; operand 1 is a 28113 'parallel' expression where each element is a 'set' expression that 28114 indicates the restoring of a function return value from the result 28115 block. 28116 28117'nop' 28118 No-op instruction. This instruction pattern name should always be 28119 defined to output a no-op in assembler code. '(const_int 0)' will 28120 do as an RTL pattern. 28121 28122'indirect_jump' 28123 An instruction to jump to an address which is operand zero. This 28124 pattern name is mandatory on all machines. 28125 28126'casesi' 28127 Instruction to jump through a dispatch table, including bounds 28128 checking. This instruction takes five operands: 28129 28130 1. The index to dispatch on, which has mode 'SImode'. 28131 28132 2. The lower bound for indices in the table, an integer constant. 28133 28134 3. The total range of indices in the table--the largest index 28135 minus the smallest one (both inclusive). 28136 28137 4. A label that precedes the table itself. 28138 28139 5. A label to jump to if the index has a value outside the 28140 bounds. 28141 28142 The table is an 'addr_vec' or 'addr_diff_vec' inside of a 28143 'jump_table_data'. The number of elements in the table is one plus 28144 the difference between the upper bound and the lower bound. 28145 28146'tablejump' 28147 Instruction to jump to a variable address. This is a low-level 28148 capability which can be used to implement a dispatch table when 28149 there is no 'casesi' pattern. 28150 28151 This pattern requires two operands: the address or offset, and a 28152 label which should immediately precede the jump table. If the 28153 macro 'CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 28154 the first operand is an offset which counts from the address of the 28155 table; otherwise, it is an absolute address to jump to. In either 28156 case, the first operand has mode 'Pmode'. 28157 28158 The 'tablejump' insn is always the last insn before the jump table 28159 it uses. Its assembler code normally has no need to use the second 28160 operand, but you should incorporate it in the RTL pattern so that 28161 the jump optimizer will not delete the table as unreachable code. 28162 28163'doloop_end' 28164 Conditional branch instruction that decrements a register and jumps 28165 if the register is nonzero. Operand 0 is the register to decrement 28166 and test; operand 1 is the label to jump to if the register is 28167 nonzero. *Note Looping Patterns::. 28168 28169 This optional instruction pattern should be defined for machines 28170 with low-overhead looping instructions as the loop optimizer will 28171 try to modify suitable loops to utilize it. The target hook 28172 'TARGET_CAN_USE_DOLOOP_P' controls the conditions under which 28173 low-overhead loops can be used. 28174 28175'doloop_begin' 28176 Companion instruction to 'doloop_end' required for machines that 28177 need to perform some initialization, such as loading a special 28178 counter register. Operand 1 is the associated 'doloop_end' pattern 28179 and operand 0 is the register that it decrements. 28180 28181 If initialization insns do not always need to be emitted, use a 28182 'define_expand' (*note Expander Definitions::) and make it fail. 28183 28184'canonicalize_funcptr_for_compare' 28185 Canonicalize the function pointer in operand 1 and store the result 28186 into operand 0. 28187 28188 Operand 0 is always a 'reg' and has mode 'Pmode'; operand 1 may be 28189 a 'reg', 'mem', 'symbol_ref', 'const_int', etc and also has mode 28190 'Pmode'. 28191 28192 Canonicalization of a function pointer usually involves computing 28193 the address of the function which would be called if the function 28194 pointer were used in an indirect call. 28195 28196 Only define this pattern if function pointers on the target machine 28197 can have different values but still call the same function when 28198 used in an indirect call. 28199 28200'save_stack_block' 28201'save_stack_function' 28202'save_stack_nonlocal' 28203'restore_stack_block' 28204'restore_stack_function' 28205'restore_stack_nonlocal' 28206 Most machines save and restore the stack pointer by copying it to 28207 or from an object of mode 'Pmode'. Do not define these patterns on 28208 such machines. 28209 28210 Some machines require special handling for stack pointer saves and 28211 restores. On those machines, define the patterns corresponding to 28212 the non-standard cases by using a 'define_expand' (*note Expander 28213 Definitions::) that produces the required insns. The three types 28214 of saves and restores are: 28215 28216 1. 'save_stack_block' saves the stack pointer at the start of a 28217 block that allocates a variable-sized object, and 28218 'restore_stack_block' restores the stack pointer when the 28219 block is exited. 28220 28221 2. 'save_stack_function' and 'restore_stack_function' do a 28222 similar job for the outermost block of a function and are used 28223 when the function allocates variable-sized objects or calls 28224 'alloca'. Only the epilogue uses the restored stack pointer, 28225 allowing a simpler save or restore sequence on some machines. 28226 28227 3. 'save_stack_nonlocal' is used in functions that contain labels 28228 branched to by nested functions. It saves the stack pointer 28229 in such a way that the inner function can use 28230 'restore_stack_nonlocal' to restore the stack pointer. The 28231 compiler generates code to restore the frame and argument 28232 pointer registers, but some machines require saving and 28233 restoring additional data such as register window information 28234 or stack backchains. Place insns in these patterns to save 28235 and restore any such required data. 28236 28237 When saving the stack pointer, operand 0 is the save area and 28238 operand 1 is the stack pointer. The mode used to allocate the save 28239 area defaults to 'Pmode' but you can override that choice by 28240 defining the 'STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 28241 You must specify an integral mode, or 'VOIDmode' if no save area is 28242 needed for a particular type of save (either because no save is 28243 needed or because a machine-specific save area can be used). 28244 Operand 0 is the stack pointer and operand 1 is the save area for 28245 restore operations. If 'save_stack_block' is defined, operand 0 28246 must not be 'VOIDmode' since these saves can be arbitrarily nested. 28247 28248 A save area is a 'mem' that is at a constant offset from 28249 'virtual_stack_vars_rtx' when the stack pointer is saved for use by 28250 nonlocal gotos and a 'reg' in the other two cases. 28251 28252'allocate_stack' 28253 Subtract (or add if 'STACK_GROWS_DOWNWARD' is undefined) operand 1 28254 from the stack pointer to create space for dynamically allocated 28255 data. 28256 28257 Store the resultant pointer to this space into operand 0. If you 28258 are allocating space from the main stack, do this by emitting a 28259 move insn to copy 'virtual_stack_dynamic_rtx' to operand 0. If you 28260 are allocating the space elsewhere, generate code to copy the 28261 location of the space to operand 0. In the latter case, you must 28262 ensure this space gets freed when the corresponding space on the 28263 main stack is free. 28264 28265 Do not define this pattern if all that must be done is the 28266 subtraction. Some machines require other operations such as stack 28267 probes or maintaining the back chain. Define this pattern to emit 28268 those operations in addition to updating the stack pointer. 28269 28270'check_stack' 28271 If stack checking (*note Stack Checking::) cannot be done on your 28272 system by probing the stack, define this pattern to perform the 28273 needed check and signal an error if the stack has overflowed. The 28274 single operand is the address in the stack farthest from the 28275 current stack pointer that you need to validate. Normally, on 28276 platforms where this pattern is needed, you would obtain the stack 28277 limit from a global or thread-specific variable or register. 28278 28279'probe_stack_address' 28280 If stack checking (*note Stack Checking::) can be done on your 28281 system by probing the stack but without the need to actually access 28282 it, define this pattern and signal an error if the stack has 28283 overflowed. The single operand is the memory address in the stack 28284 that needs to be probed. 28285 28286'probe_stack' 28287 If stack checking (*note Stack Checking::) can be done on your 28288 system by probing the stack but doing it with a "store zero" 28289 instruction is not valid or optimal, define this pattern to do the 28290 probing differently and signal an error if the stack has 28291 overflowed. The single operand is the memory reference in the 28292 stack that needs to be probed. 28293 28294'nonlocal_goto' 28295 Emit code to generate a non-local goto, e.g., a jump from one 28296 function to a label in an outer function. This pattern has four 28297 arguments, each representing a value to be used in the jump. The 28298 first argument is to be loaded into the frame pointer, the second 28299 is the address to branch to (code to dispatch to the actual label), 28300 the third is the address of a location where the stack is saved, 28301 and the last is the address of the label, to be placed in the 28302 location for the incoming static chain. 28303 28304 On most machines you need not define this pattern, since GCC will 28305 already generate the correct code, which is to load the frame 28306 pointer and static chain, restore the stack (using the 28307 'restore_stack_nonlocal' pattern, if defined), and jump indirectly 28308 to the dispatcher. You need only define this pattern if this code 28309 will not work on your machine. 28310 28311'nonlocal_goto_receiver' 28312 This pattern, if defined, contains code needed at the target of a 28313 nonlocal goto after the code already generated by GCC. You will 28314 not normally need to define this pattern. A typical reason why you 28315 might need this pattern is if some value, such as a pointer to a 28316 global table, must be restored when the frame pointer is restored. 28317 Note that a nonlocal goto only occurs within a unit-of-translation, 28318 so a global table pointer that is shared by all functions of a 28319 given module need not be restored. There are no arguments. 28320 28321'exception_receiver' 28322 This pattern, if defined, contains code needed at the site of an 28323 exception handler that isn't needed at the site of a nonlocal goto. 28324 You will not normally need to define this pattern. A typical 28325 reason why you might need this pattern is if some value, such as a 28326 pointer to a global table, must be restored after control flow is 28327 branched to the handler of an exception. There are no arguments. 28328 28329'builtin_setjmp_setup' 28330 This pattern, if defined, contains additional code needed to 28331 initialize the 'jmp_buf'. You will not normally need to define 28332 this pattern. A typical reason why you might need this pattern is 28333 if some value, such as a pointer to a global table, must be 28334 restored. Though it is preferred that the pointer value be 28335 recalculated if possible (given the address of a label for 28336 instance). The single argument is a pointer to the 'jmp_buf'. 28337 Note that the buffer is five words long and that the first three 28338 are normally used by the generic mechanism. 28339 28340'builtin_setjmp_receiver' 28341 This pattern, if defined, contains code needed at the site of a 28342 built-in setjmp that isn't needed at the site of a nonlocal goto. 28343 You will not normally need to define this pattern. A typical 28344 reason why you might need this pattern is if some value, such as a 28345 pointer to a global table, must be restored. It takes one 28346 argument, which is the label to which builtin_longjmp transferred 28347 control; this pattern may be emitted at a small offset from that 28348 label. 28349 28350'builtin_longjmp' 28351 This pattern, if defined, performs the entire action of the 28352 longjmp. You will not normally need to define this pattern unless 28353 you also define 'builtin_setjmp_setup'. The single argument is a 28354 pointer to the 'jmp_buf'. 28355 28356'eh_return' 28357 This pattern, if defined, affects the way '__builtin_eh_return', 28358 and thence the call frame exception handling library routines, are 28359 built. It is intended to handle non-trivial actions needed along 28360 the abnormal return path. 28361 28362 The address of the exception handler to which the function should 28363 return is passed as operand to this pattern. It will normally need 28364 to copied by the pattern to some special register or memory 28365 location. If the pattern needs to determine the location of the 28366 target call frame in order to do so, it may use 28367 'EH_RETURN_STACKADJ_RTX', if defined; it will have already been 28368 assigned. 28369 28370 If this pattern is not defined, the default action will be to 28371 simply copy the return address to 'EH_RETURN_HANDLER_RTX'. Either 28372 that macro or this pattern needs to be defined if call frame 28373 exception handling is to be used. 28374 28375'prologue' 28376 This pattern, if defined, emits RTL for entry to a function. The 28377 function entry is responsible for setting up the stack frame, 28378 initializing the frame pointer register, saving callee saved 28379 registers, etc. 28380 28381 Using a prologue pattern is generally preferred over defining 28382 'TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 28383 prologue. 28384 28385 The 'prologue' pattern is particularly useful for targets which 28386 perform instruction scheduling. 28387 28388'window_save' 28389 This pattern, if defined, emits RTL for a register window save. It 28390 should be defined if the target machine has register windows but 28391 the window events are decoupled from calls to subroutines. The 28392 canonical example is the SPARC architecture. 28393 28394'epilogue' 28395 This pattern emits RTL for exit from a function. The function exit 28396 is responsible for deallocating the stack frame, restoring callee 28397 saved registers and emitting the return instruction. 28398 28399 Using an epilogue pattern is generally preferred over defining 28400 'TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 28401 epilogue. 28402 28403 The 'epilogue' pattern is particularly useful for targets which 28404 perform instruction scheduling or which have delay slots for their 28405 return instruction. 28406 28407'sibcall_epilogue' 28408 This pattern, if defined, emits RTL for exit from a function 28409 without the final branch back to the calling function. This 28410 pattern will be emitted before any sibling call (aka tail call) 28411 sites. 28412 28413 The 'sibcall_epilogue' pattern must not clobber any arguments used 28414 for parameter passing or any stack slots for arguments passed to 28415 the current function. 28416 28417'trap' 28418 This pattern, if defined, signals an error, typically by causing 28419 some kind of signal to be raised. 28420 28421'ctrapMM4' 28422 Conditional trap instruction. Operand 0 is a piece of RTL which 28423 performs a comparison, and operands 1 and 2 are the arms of the 28424 comparison. Operand 3 is the trap code, an integer. 28425 28426 A typical 'ctrap' pattern looks like 28427 28428 (define_insn "ctrapsi4" 28429 [(trap_if (match_operator 0 "trap_operator" 28430 [(match_operand 1 "register_operand") 28431 (match_operand 2 "immediate_operand")]) 28432 (match_operand 3 "const_int_operand" "i"))] 28433 "" 28434 "...") 28435 28436'prefetch' 28437 This pattern, if defined, emits code for a non-faulting data 28438 prefetch instruction. Operand 0 is the address of the memory to 28439 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 28440 for a write to the memory address, or a constant 0 otherwise. 28441 Operand 2 is the expected degree of temporal locality of the data 28442 and is a value between 0 and 3, inclusive; 0 means that the data 28443 has no temporal locality, so it need not be left in the cache after 28444 the access; 3 means that the data has a high degree of temporal 28445 locality and should be left in all levels of cache possible; 1 and 28446 2 mean, respectively, a low or moderate degree of temporal 28447 locality. 28448 28449 Targets that do not support write prefetches or locality hints can 28450 ignore the values of operands 1 and 2. 28451 28452'blockage' 28453 This pattern defines a pseudo insn that prevents the instruction 28454 scheduler and other passes from moving instructions and using 28455 register equivalences across the boundary defined by the blockage 28456 insn. This needs to be an UNSPEC_VOLATILE pattern or a volatile 28457 ASM. 28458 28459'memory_blockage' 28460 This pattern, if defined, represents a compiler memory barrier, and 28461 will be placed at points across which RTL passes may not propagate 28462 memory accesses. This instruction needs to read and write volatile 28463 BLKmode memory. It does not need to generate any machine 28464 instruction. If this pattern is not defined, the compiler falls 28465 back to emitting an instruction corresponding to 'asm volatile ("" 28466 ::: "memory")'. 28467 28468'memory_barrier' 28469 If the target memory model is not fully synchronous, then this 28470 pattern should be defined to an instruction that orders both loads 28471 and stores before the instruction with respect to loads and stores 28472 after the instruction. This pattern has no operands. 28473 28474'speculation_barrier' 28475 If the target can support speculative execution, then this pattern 28476 should be defined to an instruction that will block subsequent 28477 execution until any prior speculation conditions has been resolved. 28478 The pattern must also ensure that the compiler cannot move memory 28479 operations past the barrier, so it needs to be an UNSPEC_VOLATILE 28480 pattern. The pattern has no operands. 28481 28482 If this pattern is not defined then the default expansion of 28483 '__builtin_speculation_safe_value' will emit a warning. You can 28484 suppress this warning by defining this pattern with a final 28485 condition of '0' (zero), which tells the compiler that a 28486 speculation barrier is not needed for this target. 28487 28488'sync_compare_and_swapMODE' 28489 This pattern, if defined, emits code for an atomic compare-and-swap 28490 operation. Operand 1 is the memory on which the atomic operation 28491 is performed. Operand 2 is the "old" value to be compared against 28492 the current contents of the memory location. Operand 3 is the 28493 "new" value to store in the memory if the compare succeeds. 28494 Operand 0 is the result of the operation; it should contain the 28495 contents of the memory before the operation. If the compare 28496 succeeds, this should obviously be a copy of operand 2. 28497 28498 This pattern must show that both operand 0 and operand 1 are 28499 modified. 28500 28501 This pattern must issue any memory barrier instructions such that 28502 all memory operations before the atomic operation occur before the 28503 atomic operation and all memory operations after the atomic 28504 operation occur after the atomic operation. 28505 28506 For targets where the success or failure of the compare-and-swap 28507 operation is available via the status flags, it is possible to 28508 avoid a separate compare operation and issue the subsequent branch 28509 or store-flag operation immediately after the compare-and-swap. To 28510 this end, GCC will look for a 'MODE_CC' set in the output of 28511 'sync_compare_and_swapMODE'; if the machine description includes 28512 such a set, the target should also define special 'cbranchcc4' 28513 and/or 'cstorecc4' instructions. GCC will then be able to take the 28514 destination of the 'MODE_CC' set and pass it to the 'cbranchcc4' or 28515 'cstorecc4' pattern as the first operand of the comparison (the 28516 second will be '(const_int 0)'). 28517 28518 For targets where the operating system may provide support for this 28519 operation via library calls, the 'sync_compare_and_swap_optab' may 28520 be initialized to a function with the same interface as the 28521 '__sync_val_compare_and_swap_N' built-in. If the entire set of 28522 __SYNC builtins are supported via library calls, the target can 28523 initialize all of the optabs at once with 'init_sync_libfuncs'. 28524 For the purposes of C++11 'std::atomic::is_lock_free', it is 28525 assumed that these library calls do _not_ use any kind of 28526 interruptable locking. 28527 28528'sync_addMODE', 'sync_subMODE' 28529'sync_iorMODE', 'sync_andMODE' 28530'sync_xorMODE', 'sync_nandMODE' 28531 These patterns emit code for an atomic operation on memory. 28532 Operand 0 is the memory on which the atomic operation is performed. 28533 Operand 1 is the second operand to the binary operator. 28534 28535 This pattern must issue any memory barrier instructions such that 28536 all memory operations before the atomic operation occur before the 28537 atomic operation and all memory operations after the atomic 28538 operation occur after the atomic operation. 28539 28540 If these patterns are not defined, the operation will be 28541 constructed from a compare-and-swap operation, if defined. 28542 28543'sync_old_addMODE', 'sync_old_subMODE' 28544'sync_old_iorMODE', 'sync_old_andMODE' 28545'sync_old_xorMODE', 'sync_old_nandMODE' 28546 These patterns emit code for an atomic operation on memory, and 28547 return the value that the memory contained before the operation. 28548 Operand 0 is the result value, operand 1 is the memory on which the 28549 atomic operation is performed, and operand 2 is the second operand 28550 to the binary operator. 28551 28552 This pattern must issue any memory barrier instructions such that 28553 all memory operations before the atomic operation occur before the 28554 atomic operation and all memory operations after the atomic 28555 operation occur after the atomic operation. 28556 28557 If these patterns are not defined, the operation will be 28558 constructed from a compare-and-swap operation, if defined. 28559 28560'sync_new_addMODE', 'sync_new_subMODE' 28561'sync_new_iorMODE', 'sync_new_andMODE' 28562'sync_new_xorMODE', 'sync_new_nandMODE' 28563 These patterns are like their 'sync_old_OP' counterparts, except 28564 that they return the value that exists in the memory location after 28565 the operation, rather than before the operation. 28566 28567'sync_lock_test_and_setMODE' 28568 This pattern takes two forms, based on the capabilities of the 28569 target. In either case, operand 0 is the result of the operand, 28570 operand 1 is the memory on which the atomic operation is performed, 28571 and operand 2 is the value to set in the lock. 28572 28573 In the ideal case, this operation is an atomic exchange operation, 28574 in which the previous value in memory operand is copied into the 28575 result operand, and the value operand is stored in the memory 28576 operand. 28577 28578 For less capable targets, any value operand that is not the 28579 constant 1 should be rejected with 'FAIL'. In this case the target 28580 may use an atomic test-and-set bit operation. The result operand 28581 should contain 1 if the bit was previously set and 0 if the bit was 28582 previously clear. The true contents of the memory operand are 28583 implementation defined. 28584 28585 This pattern must issue any memory barrier instructions such that 28586 the pattern as a whole acts as an acquire barrier, that is all 28587 memory operations after the pattern do not occur until the lock is 28588 acquired. 28589 28590 If this pattern is not defined, the operation will be constructed 28591 from a compare-and-swap operation, if defined. 28592 28593'sync_lock_releaseMODE' 28594 This pattern, if defined, releases a lock set by 28595 'sync_lock_test_and_setMODE'. Operand 0 is the memory that 28596 contains the lock; operand 1 is the value to store in the lock. 28597 28598 If the target doesn't implement full semantics for 28599 'sync_lock_test_and_setMODE', any value operand which is not the 28600 constant 0 should be rejected with 'FAIL', and the true contents of 28601 the memory operand are implementation defined. 28602 28603 This pattern must issue any memory barrier instructions such that 28604 the pattern as a whole acts as a release barrier, that is the lock 28605 is released only after all previous memory operations have 28606 completed. 28607 28608 If this pattern is not defined, then a 'memory_barrier' pattern 28609 will be emitted, followed by a store of the value to the memory 28610 operand. 28611 28612'atomic_compare_and_swapMODE' 28613 This pattern, if defined, emits code for an atomic compare-and-swap 28614 operation with memory model semantics. Operand 2 is the memory on 28615 which the atomic operation is performed. Operand 0 is an output 28616 operand which is set to true or false based on whether the 28617 operation succeeded. Operand 1 is an output operand which is set 28618 to the contents of the memory before the operation was attempted. 28619 Operand 3 is the value that is expected to be in memory. Operand 4 28620 is the value to put in memory if the expected value is found there. 28621 Operand 5 is set to 1 if this compare and swap is to be treated as 28622 a weak operation. Operand 6 is the memory model to be used if the 28623 operation is a success. Operand 7 is the memory model to be used 28624 if the operation fails. 28625 28626 If memory referred to in operand 2 contains the value in operand 3, 28627 then operand 4 is stored in memory pointed to by operand 2 and 28628 fencing based on the memory model in operand 6 is issued. 28629 28630 If memory referred to in operand 2 does not contain the value in 28631 operand 3, then fencing based on the memory model in operand 7 is 28632 issued. 28633 28634 If a target does not support weak compare-and-swap operations, or 28635 the port elects not to implement weak operations, the argument in 28636 operand 5 can be ignored. Note a strong implementation must be 28637 provided. 28638 28639 If this pattern is not provided, the '__atomic_compare_exchange' 28640 built-in functions will utilize the legacy 'sync_compare_and_swap' 28641 pattern with an '__ATOMIC_SEQ_CST' memory model. 28642 28643'atomic_loadMODE' 28644 This pattern implements an atomic load operation with memory model 28645 semantics. Operand 1 is the memory address being loaded from. 28646 Operand 0 is the result of the load. Operand 2 is the memory model 28647 to be used for the load operation. 28648 28649 If not present, the '__atomic_load' built-in function will either 28650 resort to a normal load with memory barriers, or a compare-and-swap 28651 operation if a normal load would not be atomic. 28652 28653'atomic_storeMODE' 28654 This pattern implements an atomic store operation with memory model 28655 semantics. Operand 0 is the memory address being stored to. 28656 Operand 1 is the value to be written. Operand 2 is the memory 28657 model to be used for the operation. 28658 28659 If not present, the '__atomic_store' built-in function will attempt 28660 to perform a normal store and surround it with any required memory 28661 fences. If the store would not be atomic, then an 28662 '__atomic_exchange' is attempted with the result being ignored. 28663 28664'atomic_exchangeMODE' 28665 This pattern implements an atomic exchange operation with memory 28666 model semantics. Operand 1 is the memory location the operation is 28667 performed on. Operand 0 is an output operand which is set to the 28668 original value contained in the memory pointed to by operand 1. 28669 Operand 2 is the value to be stored. Operand 3 is the memory model 28670 to be used. 28671 28672 If this pattern is not present, the built-in function 28673 '__atomic_exchange' will attempt to preform the operation with a 28674 compare and swap loop. 28675 28676'atomic_addMODE', 'atomic_subMODE' 28677'atomic_orMODE', 'atomic_andMODE' 28678'atomic_xorMODE', 'atomic_nandMODE' 28679 These patterns emit code for an atomic operation on memory with 28680 memory model semantics. Operand 0 is the memory on which the 28681 atomic operation is performed. Operand 1 is the second operand to 28682 the binary operator. Operand 2 is the memory model to be used by 28683 the operation. 28684 28685 If these patterns are not defined, attempts will be made to use 28686 legacy 'sync' patterns, or equivalent patterns which return a 28687 result. If none of these are available a compare-and-swap loop 28688 will be used. 28689 28690'atomic_fetch_addMODE', 'atomic_fetch_subMODE' 28691'atomic_fetch_orMODE', 'atomic_fetch_andMODE' 28692'atomic_fetch_xorMODE', 'atomic_fetch_nandMODE' 28693 These patterns emit code for an atomic operation on memory with 28694 memory model semantics, and return the original value. Operand 0 28695 is an output operand which contains the value of the memory 28696 location before the operation was performed. Operand 1 is the 28697 memory on which the atomic operation is performed. Operand 2 is 28698 the second operand to the binary operator. Operand 3 is the memory 28699 model to be used by the operation. 28700 28701 If these patterns are not defined, attempts will be made to use 28702 legacy 'sync' patterns. If none of these are available a 28703 compare-and-swap loop will be used. 28704 28705'atomic_add_fetchMODE', 'atomic_sub_fetchMODE' 28706'atomic_or_fetchMODE', 'atomic_and_fetchMODE' 28707'atomic_xor_fetchMODE', 'atomic_nand_fetchMODE' 28708 These patterns emit code for an atomic operation on memory with 28709 memory model semantics and return the result after the operation is 28710 performed. Operand 0 is an output operand which contains the value 28711 after the operation. Operand 1 is the memory on which the atomic 28712 operation is performed. Operand 2 is the second operand to the 28713 binary operator. Operand 3 is the memory model to be used by the 28714 operation. 28715 28716 If these patterns are not defined, attempts will be made to use 28717 legacy 'sync' patterns, or equivalent patterns which return the 28718 result before the operation followed by the arithmetic operation 28719 required to produce the result. If none of these are available a 28720 compare-and-swap loop will be used. 28721 28722'atomic_test_and_set' 28723 This pattern emits code for '__builtin_atomic_test_and_set'. 28724 Operand 0 is an output operand which is set to true if the previous 28725 previous contents of the byte was "set", and false otherwise. 28726 Operand 1 is the 'QImode' memory to be modified. Operand 2 is the 28727 memory model to be used. 28728 28729 The specific value that defines "set" is implementation defined, 28730 and is normally based on what is performed by the native atomic 28731 test and set instruction. 28732 28733'atomic_bit_test_and_setMODE' 28734'atomic_bit_test_and_complementMODE' 28735'atomic_bit_test_and_resetMODE' 28736 These patterns emit code for an atomic bitwise operation on memory 28737 with memory model semantics, and return the original value of the 28738 specified bit. Operand 0 is an output operand which contains the 28739 value of the specified bit from the memory location before the 28740 operation was performed. Operand 1 is the memory on which the 28741 atomic operation is performed. Operand 2 is the bit within the 28742 operand, starting with least significant bit. Operand 3 is the 28743 memory model to be used by the operation. Operand 4 is a flag - it 28744 is 'const1_rtx' if operand 0 should contain the original value of 28745 the specified bit in the least significant bit of the operand, and 28746 'const0_rtx' if the bit should be in its original position in the 28747 operand. 'atomic_bit_test_and_setMODE' atomically sets the 28748 specified bit after remembering its original value, 28749 'atomic_bit_test_and_complementMODE' inverts the specified bit and 28750 'atomic_bit_test_and_resetMODE' clears the specified bit. 28751 28752 If these patterns are not defined, attempts will be made to use 28753 'atomic_fetch_orMODE', 'atomic_fetch_xorMODE' or 28754 'atomic_fetch_andMODE' instruction patterns, or their 'sync' 28755 counterparts. If none of these are available a compare-and-swap 28756 loop will be used. 28757 28758'mem_thread_fence' 28759 This pattern emits code required to implement a thread fence with 28760 memory model semantics. Operand 0 is the memory model to be used. 28761 28762 For the '__ATOMIC_RELAXED' model no instructions need to be issued 28763 and this expansion is not invoked. 28764 28765 The compiler always emits a compiler memory barrier regardless of 28766 what expanding this pattern produced. 28767 28768 If this pattern is not defined, the compiler falls back to 28769 expanding the 'memory_barrier' pattern, then to emitting 28770 '__sync_synchronize' library call, and finally to just placing a 28771 compiler memory barrier. 28772 28773'get_thread_pointerMODE' 28774'set_thread_pointerMODE' 28775 These patterns emit code that reads/sets the TLS thread pointer. 28776 Currently, these are only needed if the target needs to support the 28777 '__builtin_thread_pointer' and '__builtin_set_thread_pointer' 28778 builtins. 28779 28780 The get/set patterns have a single output/input operand 28781 respectively, with MODE intended to be 'Pmode'. 28782 28783'stack_protect_combined_set' 28784 This pattern, if defined, moves a 'ptr_mode' value from an address 28785 whose declaration RTX is given in operand 1 to the memory in 28786 operand 0 without leaving the value in a register afterward. If 28787 several instructions are needed by the target to perform the 28788 operation (eg. to load the address from a GOT entry then load the 28789 'ptr_mode' value and finally store it), it is the backend's 28790 responsibility to ensure no intermediate result gets spilled. This 28791 is to avoid leaking the value some place that an attacker might use 28792 to rewrite the stack guard slot after having clobbered it. 28793 28794 If this pattern is not defined, then the address declaration is 28795 expanded first in the standard way and a 'stack_protect_set' 28796 pattern is then generated to move the value from that address to 28797 the address in operand 0. 28798 28799'stack_protect_set' 28800 This pattern, if defined, moves a 'ptr_mode' value from the valid 28801 memory location in operand 1 to the memory in operand 0 without 28802 leaving the value in a register afterward. This is to avoid 28803 leaking the value some place that an attacker might use to rewrite 28804 the stack guard slot after having clobbered it. 28805 28806 Note: on targets where the addressing modes do not allow to load 28807 directly from stack guard address, the address is expanded in a 28808 standard way first which could cause some spills. 28809 28810 If this pattern is not defined, then a plain move pattern is 28811 generated. 28812 28813'stack_protect_combined_test' 28814 This pattern, if defined, compares a 'ptr_mode' value from an 28815 address whose declaration RTX is given in operand 1 with the memory 28816 in operand 0 without leaving the value in a register afterward and 28817 branches to operand 2 if the values were equal. If several 28818 instructions are needed by the target to perform the operation (eg. 28819 to load the address from a GOT entry then load the 'ptr_mode' value 28820 and finally store it), it is the backend's responsibility to ensure 28821 no intermediate result gets spilled. This is to avoid leaking the 28822 value some place that an attacker might use to rewrite the stack 28823 guard slot after having clobbered it. 28824 28825 If this pattern is not defined, then the address declaration is 28826 expanded first in the standard way and a 'stack_protect_test' 28827 pattern is then generated to compare the value from that address to 28828 the value at the memory in operand 0. 28829 28830'stack_protect_test' 28831 This pattern, if defined, compares a 'ptr_mode' value from the 28832 valid memory location in operand 1 with the memory in operand 0 28833 without leaving the value in a register afterward and branches to 28834 operand 2 if the values were equal. 28835 28836 If this pattern is not defined, then a plain compare pattern and 28837 conditional branch pattern is used. 28838 28839'clear_cache' 28840 This pattern, if defined, flushes the instruction cache for a 28841 region of memory. The region is bounded to by the Pmode pointers 28842 in operand 0 inclusive and operand 1 exclusive. 28843 28844 If this pattern is not defined, a call to the library function 28845 '__clear_cache' is used. 28846 28847 28848File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 28849 2885017.10 When the Order of Patterns Matters 28851======================================== 28852 28853Sometimes an insn can match more than one instruction pattern. Then the 28854pattern that appears first in the machine description is the one used. 28855Therefore, more specific patterns (patterns that will match fewer 28856things) and faster instructions (those that will produce better code 28857when they do match) should usually go first in the description. 28858 28859 In some cases the effect of ordering the patterns can be used to hide a 28860pattern when it is not valid. For example, the 68000 has an instruction 28861for converting a fullword to floating point and another for converting a 28862byte to floating point. An instruction converting an integer to 28863floating point could match either one. We put the pattern to convert 28864the fullword first to make sure that one will be used rather than the 28865other. (Otherwise a large integer might be generated as a single-byte 28866immediate quantity, which would not work.) Instead of using this 28867pattern ordering it would be possible to make the pattern for 28868convert-a-byte smart enough to deal properly with any constant value. 28869 28870 28871File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 28872 2887317.11 Interdependence of Patterns 28874================================= 28875 28876In some cases machines support instructions identical except for the 28877machine mode of one or more operands. For example, there may be 28878"sign-extend halfword" and "sign-extend byte" instructions whose 28879patterns are 28880 28881 (set (match_operand:SI 0 ...) 28882 (extend:SI (match_operand:HI 1 ...))) 28883 28884 (set (match_operand:SI 0 ...) 28885 (extend:SI (match_operand:QI 1 ...))) 28886 28887Constant integers do not specify a machine mode, so an instruction to 28888extend a constant value could match either pattern. The pattern it 28889actually will match is the one that appears first in the file. For 28890correct results, this must be the one for the widest possible mode 28891('HImode', here). If the pattern matches the 'QImode' instruction, the 28892results will be incorrect if the constant value does not actually fit 28893that mode. 28894 28895 Such instructions to extend constants are rarely generated because they 28896are optimized away, but they do occasionally happen in nonoptimized 28897compilations. 28898 28899 If a constraint in a pattern allows a constant, the reload pass may 28900replace a register with a constant permitted by the constraint in some 28901cases. Similarly for memory references. Because of this substitution, 28902you should not provide separate patterns for increment and decrement 28903instructions. Instead, they should be generated from the same pattern 28904that supports register-register add insns by examining the operands and 28905generating the appropriate machine instruction. 28906 28907 28908File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 28909 2891017.12 Defining Jump Instruction Patterns 28911======================================== 28912 28913GCC does not assume anything about how the machine realizes jumps. The 28914machine description should define a single pattern, usually a 28915'define_expand', which expands to all the required insns. 28916 28917 Usually, this would be a comparison insn to set the condition code and 28918a separate branch insn testing the condition code and branching or not 28919according to its value. For many machines, however, separating compares 28920and branches is limiting, which is why the more flexible approach with 28921one 'define_expand' is used in GCC. The machine description becomes 28922clearer for architectures that have compare-and-branch instructions but 28923no condition code. It also works better when different sets of 28924comparison operators are supported by different kinds of conditional 28925branches (e.g. integer vs. floating-point), or by conditional branches 28926with respect to conditional stores. 28927 28928 Two separate insns are always used if the machine description 28929represents a condition code register using the legacy RTL expression 28930'(cc0)', and on most machines that use a separate condition code 28931register (*note Condition Code::). For machines that use '(cc0)', in 28932fact, the set and use of the condition code must be separate and 28933adjacent(1), thus allowing flags in 'cc_status' to be used (*note 28934Condition Code::) and so that the comparison and branch insns could be 28935located from each other by using the functions 'prev_cc0_setter' and 28936'next_cc0_user'. 28937 28938 Even in this case having a single entry point for conditional branches 28939is advantageous, because it handles equally well the case where a single 28940comparison instruction records the results of both signed and unsigned 28941comparison of the given operands (with the branch insns coming in 28942distinct signed and unsigned flavors) as in the x86 or SPARC, and the 28943case where there are distinct signed and unsigned compare instructions 28944and only one set of conditional branch instructions as in the PowerPC. 28945 28946 ---------- Footnotes ---------- 28947 28948 (1) 'note' insns can separate them, though. 28949 28950 28951File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 28952 2895317.13 Defining Looping Instruction Patterns 28954=========================================== 28955 28956Some machines have special jump instructions that can be utilized to 28957make loops more efficient. A common example is the 68000 'dbra' 28958instruction which performs a decrement of a register and a branch if the 28959result was greater than zero. Other machines, in particular digital 28960signal processors (DSPs), have special block repeat instructions to 28961provide low-overhead loop support. For example, the TI TMS320C3x/C4x 28962DSPs have a block repeat instruction that loads special registers to 28963mark the top and end of a loop and to count the number of loop 28964iterations. This avoids the need for fetching and executing a 28965'dbra'-like instruction and avoids pipeline stalls associated with the 28966jump. 28967 28968 GCC has two special named patterns to support low overhead looping. 28969They are 'doloop_begin' and 'doloop_end'. These are emitted by the loop 28970optimizer for certain well-behaved loops with a finite number of loop 28971iterations using information collected during strength reduction. 28972 28973 The 'doloop_end' pattern describes the actual looping instruction (or 28974the implicit looping operation) and the 'doloop_begin' pattern is an 28975optional companion pattern that can be used for initialization needed 28976for some low-overhead looping instructions. 28977 28978 Note that some machines require the actual looping instruction to be 28979emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 28980the true RTL for a looping instruction at the top of the loop can cause 28981problems with flow analysis. So instead, a dummy 'doloop' insn is 28982emitted at the end of the loop. The machine dependent reorg pass checks 28983for the presence of this 'doloop' insn and then searches back to the top 28984of the loop, where it inserts the true looping insn (provided there are 28985no instructions in the loop which would cause problems). Any additional 28986labels can be emitted at this point. In addition, if the desired 28987special iteration counter register was not allocated, this machine 28988dependent reorg pass could emit a traditional compare and jump 28989instruction pair. 28990 28991 For the 'doloop_end' pattern, the loop optimizer allocates an 28992additional pseudo register as an iteration counter. This pseudo 28993register cannot be used within the loop (i.e., general induction 28994variables cannot be derived from it), however, in many cases the loop 28995induction variable may become redundant and removed by the flow pass. 28996 28997 The 'doloop_end' pattern must have a specific structure to be handled 28998correctly by GCC. The example below is taken (slightly simplified) from 28999the PDP-11 target: 29000 29001 (define_expand "doloop_end" 29002 [(parallel [(set (pc) 29003 (if_then_else 29004 (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m") 29005 (const_int 1)) 29006 (label_ref (match_operand 1 "" "")) 29007 (pc))) 29008 (set (match_dup 0) 29009 (plus:HI (match_dup 0) 29010 (const_int -1)))])] 29011 "" 29012 "{ 29013 if (GET_MODE (operands[0]) != HImode) 29014 FAIL; 29015 }") 29016 29017 (define_insn "doloop_end_insn" 29018 [(set (pc) 29019 (if_then_else 29020 (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m") 29021 (const_int 1)) 29022 (label_ref (match_operand 1 "" "")) 29023 (pc))) 29024 (set (match_dup 0) 29025 (plus:HI (match_dup 0) 29026 (const_int -1)))] 29027 "" 29028 29029 { 29030 if (which_alternative == 0) 29031 return "sob %0,%l1"; 29032 29033 /* emulate sob */ 29034 output_asm_insn ("dec %0", operands); 29035 return "bne %l1"; 29036 }) 29037 29038 The first part of the pattern describes the branch condition. GCC 29039supports three cases for the way the target machine handles the loop 29040counter: 29041 * Loop terminates when the loop register decrements to zero. This is 29042 represented by a 'ne' comparison of the register (its old value) 29043 with constant 1 (as in the example above). 29044 * Loop terminates when the loop register decrements to -1. This is 29045 represented by a 'ne' comparison of the register with constant 29046 zero. 29047 * Loop terminates when the loop register decrements to a negative 29048 value. This is represented by a 'ge' comparison of the register 29049 with constant zero. For this case, GCC will attach a 'REG_NONNEG' 29050 note to the 'doloop_end' insn if it can determine that the register 29051 will be non-negative. 29052 29053 Since the 'doloop_end' insn is a jump insn that also has an output, the 29054reload pass does not handle the output operand. Therefore, the 29055constraint must allow for that operand to be in memory rather than a 29056register. In the example shown above, that is handled (in the 29057'doloop_end_insn' pattern) by using a loop instruction sequence that can 29058handle memory operands when the memory alternative appears. 29059 29060 GCC does not check the mode of the loop register operand when 29061generating the 'doloop_end' pattern. If the pattern is only valid for 29062some modes but not others, the pattern should be a 'define_expand' 29063pattern that checks the operand mode in the preparation code, and issues 29064'FAIL' if an unsupported mode is found. The example above does this, 29065since the machine instruction to be used only exists for 'HImode'. 29066 29067 If the 'doloop_end' pattern is a 'define_expand', there must also be a 29068'define_insn' or 'define_insn_and_split' matching the generated pattern. 29069Otherwise, the compiler will fail during loop optimization. 29070 29071 29072File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 29073 2907417.14 Canonicalization of Instructions 29075====================================== 29076 29077There are often cases where multiple RTL expressions could represent an 29078operation performed by a single machine instruction. This situation is 29079most commonly encountered with logical, branch, and multiply-accumulate 29080instructions. In such cases, the compiler attempts to convert these 29081multiple RTL expressions into a single canonical form to reduce the 29082number of insn patterns required. 29083 29084 In addition to algebraic simplifications, following canonicalizations 29085are performed: 29086 29087 * For commutative and comparison operators, a constant is always made 29088 the second operand. If a machine only supports a constant as the 29089 second operand, only patterns that match a constant in the second 29090 operand need be supplied. 29091 29092 * For associative operators, a sequence of operators will always 29093 chain to the left; for instance, only the left operand of an 29094 integer 'plus' can itself be a 'plus'. 'and', 'ior', 'xor', 29095 'plus', 'mult', 'smin', 'smax', 'umin', and 'umax' are associative 29096 when applied to integers, and sometimes to floating-point. 29097 29098 * For these operators, if only one operand is a 'neg', 'not', 'mult', 29099 'plus', or 'minus' expression, it will be the first operand. 29100 29101 * In combinations of 'neg', 'mult', 'plus', and 'minus', the 'neg' 29102 operations (if any) will be moved inside the operations as far as 29103 possible. For instance, '(neg (mult A B))' is canonicalized as 29104 '(mult (neg A) B)', but '(plus (mult (neg B) C) A)' is 29105 canonicalized as '(minus A (mult B C))'. 29106 29107 * For the 'compare' operator, a constant is always the second operand 29108 if the first argument is a condition code register or '(cc0)'. 29109 29110 * For instructions that inherently set a condition code register, the 29111 'compare' operator is always written as the first RTL expression of 29112 the 'parallel' instruction pattern. For example, 29113 29114 (define_insn "" 29115 [(set (reg:CCZ FLAGS_REG) 29116 (compare:CCZ 29117 (plus:SI 29118 (match_operand:SI 1 "register_operand" "%r") 29119 (match_operand:SI 2 "register_operand" "r")) 29120 (const_int 0))) 29121 (set (match_operand:SI 0 "register_operand" "=r") 29122 (plus:SI (match_dup 1) (match_dup 2)))] 29123 "" 29124 "addl %0, %1, %2") 29125 29126 * An operand of 'neg', 'not', 'mult', 'plus', or 'minus' is made the 29127 first operand under the same conditions as above. 29128 29129 * '(ltu (plus A B) B)' is converted to '(ltu (plus A B) A)'. 29130 Likewise with 'geu' instead of 'ltu'. 29131 29132 * '(minus X (const_int N))' is converted to '(plus X (const_int 29133 -N))'. 29134 29135 * Within address computations (i.e., inside 'mem'), a left shift is 29136 converted into the appropriate multiplication by a power of two. 29137 29138 * De Morgan's Law is used to move bitwise negation inside a bitwise 29139 logical-and or logical-or operation. If this results in only one 29140 operand being a 'not' expression, it will be the first one. 29141 29142 A machine that has an instruction that performs a bitwise 29143 logical-and of one operand with the bitwise negation of the other 29144 should specify the pattern for that instruction as 29145 29146 (define_insn "" 29147 [(set (match_operand:M 0 ...) 29148 (and:M (not:M (match_operand:M 1 ...)) 29149 (match_operand:M 2 ...)))] 29150 "..." 29151 "...") 29152 29153 Similarly, a pattern for a "NAND" instruction should be written 29154 29155 (define_insn "" 29156 [(set (match_operand:M 0 ...) 29157 (ior:M (not:M (match_operand:M 1 ...)) 29158 (not:M (match_operand:M 2 ...))))] 29159 "..." 29160 "...") 29161 29162 In both cases, it is not necessary to include patterns for the many 29163 logically equivalent RTL expressions. 29164 29165 * The only possible RTL expressions involving both bitwise 29166 exclusive-or and bitwise negation are '(xor:M X Y)' and '(not:M 29167 (xor:M X Y))'. 29168 29169 * The sum of three items, one of which is a constant, will only 29170 appear in the form 29171 29172 (plus:M (plus:M X Y) CONSTANT) 29173 29174 * Equality comparisons of a group of bits (usually a single bit) with 29175 zero will be written using 'zero_extract' rather than the 29176 equivalent 'and' or 'sign_extract' operations. 29177 29178 * '(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))' 29179 is converted to '(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))', 29180 and likewise for 'zero_extend'. 29181 29182 * '(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))' 29183 is converted to '(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S)) 29184 (sign_extend:M1 Y))', and likewise for patterns using 'zero_extend' 29185 and 'lshiftrt'. If the second operand of 'mult' is also a shift, 29186 then that is extended also. This transformation is only applied 29187 when it can be proven that the original operation had sufficient 29188 precision to prevent overflow. 29189 29190 Further canonicalization rules are defined in the function 29191'commutative_operand_precedence' in 'gcc/rtlanal.c'. 29192 29193 29194File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 29195 2919617.15 Defining RTL Sequences for Code Generation 29197================================================ 29198 29199On some target machines, some standard pattern names for RTL generation 29200cannot be handled with single insn, but a sequence of RTL insns can 29201represent them. For these target machines, you can write a 29202'define_expand' to specify how to generate the sequence of RTL. 29203 29204 A 'define_expand' is an RTL expression that looks almost like a 29205'define_insn'; but, unlike the latter, a 'define_expand' is used only 29206for RTL generation and it can produce more than one RTL insn. 29207 29208 A 'define_expand' RTX has four operands: 29209 29210 * The name. Each 'define_expand' must have a name, since the only 29211 use for it is to refer to it by name. 29212 29213 * The RTL template. This is a vector of RTL expressions representing 29214 a sequence of separate instructions. Unlike 'define_insn', there 29215 is no implicit surrounding 'PARALLEL'. 29216 29217 * The condition, a string containing a C expression. This expression 29218 is used to express how the availability of this pattern depends on 29219 subclasses of target machine, selected by command-line options when 29220 GCC is run. This is just like the condition of a 'define_insn' 29221 that has a standard name. Therefore, the condition (if present) 29222 may not depend on the data in the insn being matched, but only the 29223 target-machine-type flags. The compiler needs to test these 29224 conditions during initialization in order to learn exactly which 29225 named instructions are available in a particular run. 29226 29227 * The preparation statements, a string containing zero or more C 29228 statements which are to be executed before RTL code is generated 29229 from the RTL template. 29230 29231 Usually these statements prepare temporary registers for use as 29232 internal operands in the RTL template, but they can also generate 29233 RTL insns directly by calling routines such as 'emit_insn', etc. 29234 Any such insns precede the ones that come from the RTL template. 29235 29236 * Optionally, a vector containing the values of attributes. *Note 29237 Insn Attributes::. 29238 29239 Every RTL insn emitted by a 'define_expand' must match some 29240'define_insn' in the machine description. Otherwise, the compiler will 29241crash when trying to generate code for the insn or trying to optimize 29242it. 29243 29244 The RTL template, in addition to controlling generation of RTL insns, 29245also describes the operands that need to be specified when this pattern 29246is used. In particular, it gives a predicate for each operand. 29247 29248 A true operand, which needs to be specified in order to generate RTL 29249from the pattern, should be described with a 'match_operand' in its 29250first occurrence in the RTL template. This enters information on the 29251operand's predicate into the tables that record such things. GCC uses 29252the information to preload the operand into a register if that is 29253required for valid RTL code. If the operand is referred to more than 29254once, subsequent references should use 'match_dup'. 29255 29256 The RTL template may also refer to internal "operands" which are 29257temporary registers or labels used only within the sequence made by the 29258'define_expand'. Internal operands are substituted into the RTL 29259template with 'match_dup', never with 'match_operand'. The values of 29260the internal operands are not passed in as arguments by the compiler 29261when it requests use of this pattern. Instead, they are computed within 29262the pattern, in the preparation statements. These statements compute 29263the values and store them into the appropriate elements of 'operands' so 29264that 'match_dup' can find them. 29265 29266 There are two special macros defined for use in the preparation 29267statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 29268a statement. 29269 29270'DONE' 29271 Use the 'DONE' macro to end RTL generation for the pattern. The 29272 only RTL insns resulting from the pattern on this occasion will be 29273 those already emitted by explicit calls to 'emit_insn' within the 29274 preparation statements; the RTL template will not be generated. 29275 29276'FAIL' 29277 Make the pattern fail on this occasion. When a pattern fails, it 29278 means that the pattern was not truly available. The calling 29279 routines in the compiler will try other strategies for code 29280 generation using other patterns. 29281 29282 Failure is currently supported only for binary (addition, 29283 multiplication, shifting, etc.) and bit-field ('extv', 'extzv', 29284 and 'insv') operations. 29285 29286 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 29287then the 'define_expand' acts like a 'define_insn' in that the RTL 29288template is used to generate the insn. 29289 29290 The RTL template is not used for matching, only for generating the 29291initial insn list. If the preparation statement always invokes 'DONE' 29292or 'FAIL', the RTL template may be reduced to a simple list of operands, 29293such as this example: 29294 29295 (define_expand "addsi3" 29296 [(match_operand:SI 0 "register_operand" "") 29297 (match_operand:SI 1 "register_operand" "") 29298 (match_operand:SI 2 "register_operand" "")] 29299 "" 29300 " 29301 { 29302 handle_add (operands[0], operands[1], operands[2]); 29303 DONE; 29304 }") 29305 29306 Here is an example, the definition of left-shift for the SPUR chip: 29307 29308 (define_expand "ashlsi3" 29309 [(set (match_operand:SI 0 "register_operand" "") 29310 (ashift:SI 29311 (match_operand:SI 1 "register_operand" "") 29312 (match_operand:SI 2 "nonmemory_operand" "")))] 29313 "" 29314 " 29315 29316 { 29317 if (GET_CODE (operands[2]) != CONST_INT 29318 || (unsigned) INTVAL (operands[2]) > 3) 29319 FAIL; 29320 }") 29321 29322This example uses 'define_expand' so that it can generate an RTL insn 29323for shifting when the shift-count is in the supported range of 0 to 3 29324but fail in other cases where machine insns aren't available. When it 29325fails, the compiler tries another strategy using different patterns 29326(such as, a library call). 29327 29328 If the compiler were able to handle nontrivial condition-strings in 29329patterns with names, then it would be possible to use a 'define_insn' in 29330that case. Here is another case (zero-extension on the 68000) which 29331makes more use of the power of 'define_expand': 29332 29333 (define_expand "zero_extendhisi2" 29334 [(set (match_operand:SI 0 "general_operand" "") 29335 (const_int 0)) 29336 (set (strict_low_part 29337 (subreg:HI 29338 (match_dup 0) 29339 0)) 29340 (match_operand:HI 1 "general_operand" ""))] 29341 "" 29342 "operands[1] = make_safe_from (operands[1], operands[0]);") 29343 29344Here two RTL insns are generated, one to clear the entire output operand 29345and the other to copy the input operand into its low half. This 29346sequence is incorrect if the input operand refers to [the old value of] 29347the output operand, so the preparation statement makes sure this isn't 29348so. The function 'make_safe_from' copies the 'operands[1]' into a 29349temporary register if it refers to 'operands[0]'. It does this by 29350emitting another RTL insn. 29351 29352 Finally, a third example shows the use of an internal operand. 29353Zero-extension on the SPUR chip is done by 'and'-ing the result against 29354a halfword mask. But this mask cannot be represented by a 'const_int' 29355because the constant value is too large to be legitimate on this 29356machine. So it must be copied into a register with 'force_reg' and then 29357the register used in the 'and'. 29358 29359 (define_expand "zero_extendhisi2" 29360 [(set (match_operand:SI 0 "register_operand" "") 29361 (and:SI (subreg:SI 29362 (match_operand:HI 1 "register_operand" "") 29363 0) 29364 (match_dup 2)))] 29365 "" 29366 "operands[2] 29367 = force_reg (SImode, GEN_INT (65535)); ") 29368 29369 _Note:_ If the 'define_expand' is used to serve a standard binary or 29370unary arithmetic operation or a bit-field operation, then the last insn 29371it generates must not be a 'code_label', 'barrier' or 'note'. It must 29372be an 'insn', 'jump_insn' or 'call_insn'. If you don't need a real insn 29373at the end, emit an insn to copy the result of the operation into 29374itself. Such an insn will generate no code, but it can avoid problems 29375in the compiler. 29376 29377 29378File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 29379 2938017.16 Defining How to Split Instructions 29381======================================== 29382 29383There are two cases where you should specify how to split a pattern into 29384multiple insns. On machines that have instructions requiring delay 29385slots (*note Delay Slots::) or that have instructions whose output is 29386not available for multiple cycles (*note Processor pipeline 29387description::), the compiler phases that optimize these cases need to be 29388able to move insns into one-instruction delay slots. However, some 29389insns may generate more than one machine instruction. These insns 29390cannot be placed into a delay slot. 29391 29392 Often you can rewrite the single insn as a list of individual insns, 29393each corresponding to one machine instruction. The disadvantage of 29394doing so is that it will cause the compilation to be slower and require 29395more space. If the resulting insns are too complex, it may also 29396suppress some optimizations. The compiler splits the insn if there is a 29397reason to believe that it might improve instruction or delay slot 29398scheduling. 29399 29400 The insn combiner phase also splits putative insns. If three insns are 29401merged into one insn with a complex expression that cannot be matched by 29402some 'define_insn' pattern, the combiner phase attempts to split the 29403complex pattern into two insns that are recognized. Usually it can 29404break the complex pattern into two patterns by splitting out some 29405subexpression. However, in some other cases, such as performing an 29406addition of a large constant in two insns on a RISC machine, the way to 29407split the addition into two insns is machine-dependent. 29408 29409 The 'define_split' definition tells the compiler how to split a complex 29410insn into several simpler insns. It looks like this: 29411 29412 (define_split 29413 [INSN-PATTERN] 29414 "CONDITION" 29415 [NEW-INSN-PATTERN-1 29416 NEW-INSN-PATTERN-2 29417 ...] 29418 "PREPARATION-STATEMENTS") 29419 29420 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 29421final condition to be tested, as in a 'define_insn'. When an insn 29422matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 29423in the insn list with the insns given by NEW-INSN-PATTERN-1, 29424NEW-INSN-PATTERN-2, etc. 29425 29426 The PREPARATION-STATEMENTS are similar to those statements that are 29427specified for 'define_expand' (*note Expander Definitions::) and are 29428executed before the new RTL is generated to prepare for the generated 29429code or emit some insns whose pattern is not fixed. Unlike those in 29430'define_expand', however, these statements must not generate any new 29431pseudo-registers. Once reload has completed, they also must not 29432allocate any space in the stack frame. 29433 29434 There are two special macros defined for use in the preparation 29435statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 29436a statement. 29437 29438'DONE' 29439 Use the 'DONE' macro to end RTL generation for the splitter. The 29440 only RTL insns generated as replacement for the matched input insn 29441 will be those already emitted by explicit calls to 'emit_insn' 29442 within the preparation statements; the replacement pattern is not 29443 used. 29444 29445'FAIL' 29446 Make the 'define_split' fail on this occasion. When a 29447 'define_split' fails, it means that the splitter was not truly 29448 available for the inputs it was given, and the input insn will not 29449 be split. 29450 29451 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 29452then the 'define_split' uses the replacement template. 29453 29454 Patterns are matched against INSN-PATTERN in two different 29455circumstances. If an insn needs to be split for delay slot scheduling 29456or insn scheduling, the insn is already known to be valid, which means 29457that it must have been matched by some 'define_insn' and, if 29458'reload_completed' is nonzero, is known to satisfy the constraints of 29459that 'define_insn'. In that case, the new insn patterns must also be 29460insns that are matched by some 'define_insn' and, if 'reload_completed' 29461is nonzero, must also satisfy the constraints of those definitions. 29462 29463 As an example of this usage of 'define_split', consider the following 29464example from 'a29k.md', which splits a 'sign_extend' from 'HImode' to 29465'SImode' into a pair of shift insns: 29466 29467 (define_split 29468 [(set (match_operand:SI 0 "gen_reg_operand" "") 29469 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 29470 "" 29471 [(set (match_dup 0) 29472 (ashift:SI (match_dup 1) 29473 (const_int 16))) 29474 (set (match_dup 0) 29475 (ashiftrt:SI (match_dup 0) 29476 (const_int 16)))] 29477 " 29478 { operands[1] = gen_lowpart (SImode, operands[1]); }") 29479 29480 When the combiner phase tries to split an insn pattern, it is always 29481the case that the pattern is _not_ matched by any 'define_insn'. The 29482combiner pass first tries to split a single 'set' expression and then 29483the same 'set' expression inside a 'parallel', but followed by a 29484'clobber' of a pseudo-reg to use as a scratch register. In these cases, 29485the combiner expects exactly one or two new insn patterns to be 29486generated. It will verify that these patterns match some 'define_insn' 29487definitions, so you need not do this test in the 'define_split' (of 29488course, there is no point in writing a 'define_split' that will never 29489produce insns that match). 29490 29491 Here is an example of this use of 'define_split', taken from 29492'rs6000.md': 29493 29494 (define_split 29495 [(set (match_operand:SI 0 "gen_reg_operand" "") 29496 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 29497 (match_operand:SI 2 "non_add_cint_operand" "")))] 29498 "" 29499 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 29500 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 29501 " 29502 { 29503 int low = INTVAL (operands[2]) & 0xffff; 29504 int high = (unsigned) INTVAL (operands[2]) >> 16; 29505 29506 if (low & 0x8000) 29507 high++, low |= 0xffff0000; 29508 29509 operands[3] = GEN_INT (high << 16); 29510 operands[4] = GEN_INT (low); 29511 }") 29512 29513 Here the predicate 'non_add_cint_operand' matches any 'const_int' that 29514is _not_ a valid operand of a single add insn. The add with the smaller 29515displacement is written so that it can be substituted into the address 29516of a subsequent operation. 29517 29518 An example that uses a scratch register, from the same file, generates 29519an equality comparison of a register and a large constant: 29520 29521 (define_split 29522 [(set (match_operand:CC 0 "cc_reg_operand" "") 29523 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 29524 (match_operand:SI 2 "non_short_cint_operand" ""))) 29525 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 29526 "find_single_use (operands[0], insn, 0) 29527 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 29528 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 29529 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 29530 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 29531 " 29532 { 29533 /* Get the constant we are comparing against, C, and see what it 29534 looks like sign-extended to 16 bits. Then see what constant 29535 could be XOR'ed with C to get the sign-extended value. */ 29536 29537 int c = INTVAL (operands[2]); 29538 int sextc = (c << 16) >> 16; 29539 int xorv = c ^ sextc; 29540 29541 operands[4] = GEN_INT (xorv); 29542 operands[5] = GEN_INT (sextc); 29543 }") 29544 29545 To avoid confusion, don't write a single 'define_split' that accepts 29546some insns that match some 'define_insn' as well as some insns that 29547don't. Instead, write two separate 'define_split' definitions, one for 29548the insns that are valid and one for the insns that are not valid. 29549 29550 The splitter is allowed to split jump instructions into sequence of 29551jumps or create new jumps in while splitting non-jump instructions. As 29552the control flow graph and branch prediction information needs to be 29553updated, several restriction apply. 29554 29555 Splitting of jump instruction into sequence that over by another jump 29556instruction is always valid, as compiler expect identical behavior of 29557new jump. When new sequence contains multiple jump instructions or new 29558labels, more assistance is needed. Splitter is required to create only 29559unconditional jumps, or simple conditional jump instructions. 29560Additionally it must attach a 'REG_BR_PROB' note to each conditional 29561jump. A global variable 'split_branch_probability' holds the 29562probability of the original branch in case it was a simple conditional 29563jump, -1 otherwise. To simplify recomputing of edge frequencies, the 29564new sequence is required to have only forward jumps to the newly created 29565labels. 29566 29567 For the common case where the pattern of a define_split exactly matches 29568the pattern of a define_insn, use 'define_insn_and_split'. It looks 29569like this: 29570 29571 (define_insn_and_split 29572 [INSN-PATTERN] 29573 "CONDITION" 29574 "OUTPUT-TEMPLATE" 29575 "SPLIT-CONDITION" 29576 [NEW-INSN-PATTERN-1 29577 NEW-INSN-PATTERN-2 29578 ...] 29579 "PREPARATION-STATEMENTS" 29580 [INSN-ATTRIBUTES]) 29581 29582 29583 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 29584as in 'define_insn'. The NEW-INSN-PATTERN vector and the 29585PREPARATION-STATEMENTS are used as in a 'define_split'. The 29586SPLIT-CONDITION is also used as in 'define_split', with the additional 29587behavior that if the condition starts with '&&', the condition used for 29588the split will be the constructed as a logical "and" of the split 29589condition with the insn condition. For example, from i386.md: 29590 29591 (define_insn_and_split "zero_extendhisi2_and" 29592 [(set (match_operand:SI 0 "register_operand" "=r") 29593 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 29594 (clobber (reg:CC 17))] 29595 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 29596 "#" 29597 "&& reload_completed" 29598 [(parallel [(set (match_dup 0) 29599 (and:SI (match_dup 0) (const_int 65535))) 29600 (clobber (reg:CC 17))])] 29601 "" 29602 [(set_attr "type" "alu1")]) 29603 29604 29605 In this case, the actual split condition will be 29606'TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 29607 29608 The 'define_insn_and_split' construction provides exactly the same 29609functionality as two separate 'define_insn' and 'define_split' patterns. 29610It exists for compactness, and as a maintenance tool to prevent having 29611to ensure the two patterns' templates match. 29612 29613 It is sometimes useful to have a 'define_insn_and_split' that replaces 29614specific operands of an instruction but leaves the rest of the 29615instruction pattern unchanged. You can do this directly with a 29616'define_insn_and_split', but it requires a NEW-INSN-PATTERN-1 that 29617repeats most of the original INSN-PATTERN. There is also the 29618complication that an implicit 'parallel' in INSN-PATTERN must become an 29619explicit 'parallel' in NEW-INSN-PATTERN-1, which is easy to overlook. A 29620simpler alternative is to use 'define_insn_and_rewrite', which is a form 29621of 'define_insn_and_split' that automatically generates 29622NEW-INSN-PATTERN-1 by replacing each 'match_operand' in INSN-PATTERN 29623with a corresponding 'match_dup', and each 'match_operator' in the 29624pattern with a corresponding 'match_op_dup'. The arguments are 29625otherwise identical to 'define_insn_and_split': 29626 29627 (define_insn_and_rewrite 29628 [INSN-PATTERN] 29629 "CONDITION" 29630 "OUTPUT-TEMPLATE" 29631 "SPLIT-CONDITION" 29632 "PREPARATION-STATEMENTS" 29633 [INSN-ATTRIBUTES]) 29634 29635 The 'match_dup's and 'match_op_dup's in the new instruction pattern use 29636any new operand values that the PREPARATION-STATEMENTS store in the 29637'operands' array, as for a normal 'define_insn_and_split'. 29638PREPARATION-STATEMENTS can also emit additional instructions before the 29639new instruction. They can even emit an entirely different sequence of 29640instructions and use 'DONE' to avoid emitting a new form of the original 29641instruction. 29642 29643 The split in a 'define_insn_and_rewrite' is only intended to apply to 29644existing instructions that match INSN-PATTERN. SPLIT-CONDITION must 29645therefore start with '&&', so that the split condition applies on top of 29646CONDITION. 29647 29648 Here is an example from the AArch64 SVE port, in which operand 1 is 29649known to be equivalent to an all-true constant and isn't used by the 29650output template: 29651 29652 (define_insn_and_rewrite "*while_ult<GPI:mode><PRED_ALL:mode>_cc" 29653 [(set (reg:CC CC_REGNUM) 29654 (compare:CC 29655 (unspec:SI [(match_operand:PRED_ALL 1) 29656 (unspec:PRED_ALL 29657 [(match_operand:GPI 2 "aarch64_reg_or_zero" "rZ") 29658 (match_operand:GPI 3 "aarch64_reg_or_zero" "rZ")] 29659 UNSPEC_WHILE_LO)] 29660 UNSPEC_PTEST_PTRUE) 29661 (const_int 0))) 29662 (set (match_operand:PRED_ALL 0 "register_operand" "=Upa") 29663 (unspec:PRED_ALL [(match_dup 2) 29664 (match_dup 3)] 29665 UNSPEC_WHILE_LO))] 29666 "TARGET_SVE" 29667 "whilelo\t%0.<PRED_ALL:Vetype>, %<w>2, %<w>3" 29668 ;; Force the compiler to drop the unused predicate operand, so that we 29669 ;; don't have an unnecessary PTRUE. 29670 "&& !CONSTANT_P (operands[1])" 29671 { 29672 operands[1] = CONSTM1_RTX (<MODE>mode); 29673 } 29674 ) 29675 29676 The splitter in this case simply replaces operand 1 with the constant 29677value that it is known to have. The equivalent 'define_insn_and_split' 29678would be: 29679 29680 (define_insn_and_split "*while_ult<GPI:mode><PRED_ALL:mode>_cc" 29681 [(set (reg:CC CC_REGNUM) 29682 (compare:CC 29683 (unspec:SI [(match_operand:PRED_ALL 1) 29684 (unspec:PRED_ALL 29685 [(match_operand:GPI 2 "aarch64_reg_or_zero" "rZ") 29686 (match_operand:GPI 3 "aarch64_reg_or_zero" "rZ")] 29687 UNSPEC_WHILE_LO)] 29688 UNSPEC_PTEST_PTRUE) 29689 (const_int 0))) 29690 (set (match_operand:PRED_ALL 0 "register_operand" "=Upa") 29691 (unspec:PRED_ALL [(match_dup 2) 29692 (match_dup 3)] 29693 UNSPEC_WHILE_LO))] 29694 "TARGET_SVE" 29695 "whilelo\t%0.<PRED_ALL:Vetype>, %<w>2, %<w>3" 29696 ;; Force the compiler to drop the unused predicate operand, so that we 29697 ;; don't have an unnecessary PTRUE. 29698 "&& !CONSTANT_P (operands[1])" 29699 [(parallel 29700 [(set (reg:CC CC_REGNUM) 29701 (compare:CC 29702 (unspec:SI [(match_dup 1) 29703 (unspec:PRED_ALL [(match_dup 2) 29704 (match_dup 3)] 29705 UNSPEC_WHILE_LO)] 29706 UNSPEC_PTEST_PTRUE) 29707 (const_int 0))) 29708 (set (match_dup 0) 29709 (unspec:PRED_ALL [(match_dup 2) 29710 (match_dup 3)] 29711 UNSPEC_WHILE_LO))])] 29712 { 29713 operands[1] = CONSTM1_RTX (<MODE>mode); 29714 } 29715 ) 29716 29717 29718File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 29719 2972017.17 Including Patterns in Machine Descriptions. 29721================================================= 29722 29723The 'include' pattern tells the compiler tools where to look for 29724patterns that are in files other than in the file '.md'. This is used 29725only at build time and there is no preprocessing allowed. 29726 29727 It looks like: 29728 29729 29730 (include 29731 PATHNAME) 29732 29733 For example: 29734 29735 29736 (include "filestuff") 29737 29738 29739 Where PATHNAME is a string that specifies the location of the file, 29740specifies the include file to be in 'gcc/config/target/filestuff'. The 29741directory 'gcc/config/target' is regarded as the default directory. 29742 29743 Machine descriptions may be split up into smaller more manageable 29744subsections and placed into subdirectories. 29745 29746 By specifying: 29747 29748 29749 (include "BOGUS/filestuff") 29750 29751 29752 the include file is specified to be in 29753'gcc/config/TARGET/BOGUS/filestuff'. 29754 29755 Specifying an absolute path for the include file such as; 29756 29757 (include "/u2/BOGUS/filestuff") 29758 29759 is permitted but is not encouraged. 29760 2976117.17.1 RTL Generation Tool Options for Directory Search 29762-------------------------------------------------------- 29763 29764The '-IDIR' option specifies directories to search for machine 29765descriptions. For example: 29766 29767 29768 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 29769 29770 29771 Add the directory DIR to the head of the list of directories to be 29772searched for header files. This can be used to override a system 29773machine definition file, substituting your own version, since these 29774directories are searched before the default machine description file 29775directories. If you use more than one '-I' option, the directories are 29776scanned in left-to-right order; the standard default directory come 29777after. 29778 29779 29780File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 29781 2978217.18 Machine-Specific Peephole Optimizers 29783========================================== 29784 29785In addition to instruction patterns the 'md' file may contain 29786definitions of machine-specific peephole optimizations. 29787 29788 The combiner does not notice certain peephole optimizations when the 29789data flow in the program does not suggest that it should try them. For 29790example, sometimes two consecutive insns related in purpose can be 29791combined even though the second one does not appear to use a register 29792computed in the first one. A machine-specific peephole optimizer can 29793detect such opportunities. 29794 29795 There are two forms of peephole definitions that may be used. The 29796original 'define_peephole' is run at assembly output time to match insns 29797and substitute assembly text. Use of 'define_peephole' is deprecated. 29798 29799 A newer 'define_peephole2' matches insns and substitutes new insns. 29800The 'peephole2' pass is run after register allocation but before 29801scheduling, which may result in much better code for targets that do 29802scheduling. 29803 29804* Menu: 29805 29806* define_peephole:: RTL to Text Peephole Optimizers 29807* define_peephole2:: RTL to RTL Peephole Optimizers 29808 29809 29810File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 29811 2981217.18.1 RTL to Text Peephole Optimizers 29813--------------------------------------- 29814 29815A definition looks like this: 29816 29817 (define_peephole 29818 [INSN-PATTERN-1 29819 INSN-PATTERN-2 29820 ...] 29821 "CONDITION" 29822 "TEMPLATE" 29823 "OPTIONAL-INSN-ATTRIBUTES") 29824 29825The last string operand may be omitted if you are not using any 29826machine-specific information in this machine description. If present, 29827it must obey the same rules as in a 'define_insn'. 29828 29829 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 29830consecutive insns. The optimization applies to a sequence of insns when 29831INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 29832and so on. 29833 29834 Each of the insns matched by a peephole must also match a 29835'define_insn'. Peepholes are checked only at the last stage just before 29836code generation, and only optionally. Therefore, any insn which would 29837match a peephole but no 'define_insn' will cause a crash in code 29838generation in an unoptimized compilation, or at various optimization 29839stages. 29840 29841 The operands of the insns are matched with 'match_operands', 29842'match_operator', and 'match_dup', as usual. What is not usual is that 29843the operand numbers apply to all the insn patterns in the definition. 29844So, you can check for identical operands in two insns by using 29845'match_operand' in one insn and 'match_dup' in the other. 29846 29847 The operand constraints used in 'match_operand' patterns do not have 29848any direct effect on the applicability of the peephole, but they will be 29849validated afterward, so make sure your constraints are general enough to 29850apply whenever the peephole matches. If the peephole matches but the 29851constraints are not satisfied, the compiler will crash. 29852 29853 It is safe to omit constraints in all the operands of the peephole; or 29854you can write constraints which serve as a double-check on the criteria 29855previously tested. 29856 29857 Once a sequence of insns matches the patterns, the CONDITION is 29858checked. This is a C expression which makes the final decision whether 29859to perform the optimization (we do so if the expression is nonzero). If 29860CONDITION is omitted (in other words, the string is empty) then the 29861optimization is applied to every sequence of insns that matches the 29862patterns. 29863 29864 The defined peephole optimizations are applied after register 29865allocation is complete. Therefore, the peephole definition can check 29866which operands have ended up in which kinds of registers, just by 29867looking at the operands. 29868 29869 The way to refer to the operands in CONDITION is to write 'operands[I]' 29870for operand number I (as matched by '(match_operand I ...)'). Use the 29871variable 'insn' to refer to the last of the insns being matched; use 29872'prev_active_insn' to find the preceding insns. 29873 29874 When optimizing computations with intermediate results, you can use 29875CONDITION to match only when the intermediate results are not used 29876elsewhere. Use the C expression 'dead_or_set_p (INSN, OP)', where INSN 29877is the insn in which you expect the value to be used for the last time 29878(from the value of 'insn', together with use of 'prev_nonnote_insn'), 29879and OP is the intermediate value (from 'operands[I]'). 29880 29881 Applying the optimization means replacing the sequence of insns with 29882one new insn. The TEMPLATE controls ultimate output of assembler code 29883for this combined insn. It works exactly like the template of a 29884'define_insn'. Operand numbers in this template are the same ones used 29885in matching the original sequence of insns. 29886 29887 The result of a defined peephole optimizer does not need to match any 29888of the insn patterns in the machine description; it does not even have 29889an opportunity to match them. The peephole optimizer definition itself 29890serves as the insn pattern to control how the insn is output. 29891 29892 Defined peephole optimizers are run as assembler code is being output, 29893so the insns they produce are never combined or rearranged in any way. 29894 29895 Here is an example, taken from the 68000 machine description: 29896 29897 (define_peephole 29898 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 29899 (set (match_operand:DF 0 "register_operand" "=f") 29900 (match_operand:DF 1 "register_operand" "ad"))] 29901 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 29902 { 29903 rtx xoperands[2]; 29904 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 29905 #ifdef MOTOROLA 29906 output_asm_insn ("move.l %1,(sp)", xoperands); 29907 output_asm_insn ("move.l %1,-(sp)", operands); 29908 return "fmove.d (sp)+,%0"; 29909 #else 29910 output_asm_insn ("movel %1,sp@", xoperands); 29911 output_asm_insn ("movel %1,sp@-", operands); 29912 return "fmoved sp@+,%0"; 29913 #endif 29914 }) 29915 29916 The effect of this optimization is to change 29917 29918 jbsr _foobar 29919 addql #4,sp 29920 movel d1,sp@- 29921 movel d0,sp@- 29922 fmoved sp@+,fp0 29923 29924into 29925 29926 jbsr _foobar 29927 movel d1,sp@ 29928 movel d0,sp@- 29929 fmoved sp@+,fp0 29930 29931 INSN-PATTERN-1 and so on look _almost_ like the second operand of 29932'define_insn'. There is one important difference: the second operand of 29933'define_insn' consists of one or more RTX's enclosed in square brackets. 29934Usually, there is only one: then the same action can be written as an 29935element of a 'define_peephole'. But when there are multiple actions in 29936a 'define_insn', they are implicitly enclosed in a 'parallel'. Then you 29937must explicitly write the 'parallel', and the square brackets within it, 29938in the 'define_peephole'. Thus, if an insn pattern looks like this, 29939 29940 (define_insn "divmodsi4" 29941 [(set (match_operand:SI 0 "general_operand" "=d") 29942 (div:SI (match_operand:SI 1 "general_operand" "0") 29943 (match_operand:SI 2 "general_operand" "dmsK"))) 29944 (set (match_operand:SI 3 "general_operand" "=d") 29945 (mod:SI (match_dup 1) (match_dup 2)))] 29946 "TARGET_68020" 29947 "divsl%.l %2,%3:%0") 29948 29949then the way to mention this insn in a peephole is as follows: 29950 29951 (define_peephole 29952 [... 29953 (parallel 29954 [(set (match_operand:SI 0 "general_operand" "=d") 29955 (div:SI (match_operand:SI 1 "general_operand" "0") 29956 (match_operand:SI 2 "general_operand" "dmsK"))) 29957 (set (match_operand:SI 3 "general_operand" "=d") 29958 (mod:SI (match_dup 1) (match_dup 2)))]) 29959 ...] 29960 ...) 29961 29962 29963File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 29964 2996517.18.2 RTL to RTL Peephole Optimizers 29966-------------------------------------- 29967 29968The 'define_peephole2' definition tells the compiler how to substitute 29969one sequence of instructions for another sequence, what additional 29970scratch registers may be needed and what their lifetimes must be. 29971 29972 (define_peephole2 29973 [INSN-PATTERN-1 29974 INSN-PATTERN-2 29975 ...] 29976 "CONDITION" 29977 [NEW-INSN-PATTERN-1 29978 NEW-INSN-PATTERN-2 29979 ...] 29980 "PREPARATION-STATEMENTS") 29981 29982 The definition is almost identical to 'define_split' (*note Insn 29983Splitting::) except that the pattern to match is not a single 29984instruction, but a sequence of instructions. 29985 29986 It is possible to request additional scratch registers for use in the 29987output template. If appropriate registers are not free, the pattern 29988will simply not match. 29989 29990 Scratch registers are requested with a 'match_scratch' pattern at the 29991top level of the input pattern. The allocated register (initially) will 29992be dead at the point requested within the original sequence. If the 29993scratch is used at more than a single point, a 'match_dup' pattern at 29994the top level of the input pattern marks the last position in the input 29995sequence at which the register must be available. 29996 29997 Here is an example from the IA-32 machine description: 29998 29999 (define_peephole2 30000 [(match_scratch:SI 2 "r") 30001 (parallel [(set (match_operand:SI 0 "register_operand" "") 30002 (match_operator:SI 3 "arith_or_logical_operator" 30003 [(match_dup 0) 30004 (match_operand:SI 1 "memory_operand" "")])) 30005 (clobber (reg:CC 17))])] 30006 "! optimize_size && ! TARGET_READ_MODIFY" 30007 [(set (match_dup 2) (match_dup 1)) 30008 (parallel [(set (match_dup 0) 30009 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 30010 (clobber (reg:CC 17))])] 30011 "") 30012 30013This pattern tries to split a load from its use in the hopes that we'll 30014be able to schedule around the memory load latency. It allocates a 30015single 'SImode' register of class 'GENERAL_REGS' ('"r"') that needs to 30016be live only at the point just before the arithmetic. 30017 30018 A real example requiring extended scratch lifetimes is harder to come 30019by, so here's a silly made-up example: 30020 30021 (define_peephole2 30022 [(match_scratch:SI 4 "r") 30023 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 30024 (set (match_operand:SI 2 "" "") (match_dup 1)) 30025 (match_dup 4) 30026 (set (match_operand:SI 3 "" "") (match_dup 1))] 30027 "/* determine 1 does not overlap 0 and 2 */" 30028 [(set (match_dup 4) (match_dup 1)) 30029 (set (match_dup 0) (match_dup 4)) 30030 (set (match_dup 2) (match_dup 4)) 30031 (set (match_dup 3) (match_dup 4))] 30032 "") 30033 30034 There are two special macros defined for use in the preparation 30035statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 30036a statement. 30037 30038'DONE' 30039 Use the 'DONE' macro to end RTL generation for the peephole. The 30040 only RTL insns generated as replacement for the matched input insn 30041 will be those already emitted by explicit calls to 'emit_insn' 30042 within the preparation statements; the replacement pattern is not 30043 used. 30044 30045'FAIL' 30046 Make the 'define_peephole2' fail on this occasion. When a 30047 'define_peephole2' fails, it means that the replacement was not 30048 truly available for the particular inputs it was given. In that 30049 case, GCC may still apply a later 'define_peephole2' that also 30050 matches the given insn pattern. (Note that this is different from 30051 'define_split', where 'FAIL' prevents the input insn from being 30052 split at all.) 30053 30054 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 30055then the 'define_peephole2' uses the replacement template. 30056 30057If we had not added the '(match_dup 4)' in the middle of the input 30058sequence, it might have been the case that the register we chose at the 30059beginning of the sequence is killed by the first or second 'set'. 30060 30061 30062File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 30063 3006417.19 Instruction Attributes 30065============================ 30066 30067In addition to describing the instruction supported by the target 30068machine, the 'md' file also defines a group of "attributes" and a set of 30069values for each. Every generated insn is assigned a value for each 30070attribute. One possible attribute would be the effect that the insn has 30071on the machine's condition code. This attribute can then be used by 30072'NOTICE_UPDATE_CC' to track the condition codes. 30073 30074* Menu: 30075 30076* Defining Attributes:: Specifying attributes and their values. 30077* Expressions:: Valid expressions for attribute values. 30078* Tagging Insns:: Assigning attribute values to insns. 30079* Attr Example:: An example of assigning attributes. 30080* Insn Lengths:: Computing the length of insns. 30081* Constant Attributes:: Defining attributes that are constant. 30082* Mnemonic Attribute:: Obtain the instruction mnemonic as attribute value. 30083* Delay Slots:: Defining delay slots required for a machine. 30084* Processor pipeline description:: Specifying information for insn scheduling. 30085 30086 30087File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 30088 3008917.19.1 Defining Attributes and their Values 30090-------------------------------------------- 30091 30092The 'define_attr' expression is used to define each attribute required 30093by the target machine. It looks like: 30094 30095 (define_attr NAME LIST-OF-VALUES DEFAULT) 30096 30097 NAME is a string specifying the name of the attribute being defined. 30098Some attributes are used in a special way by the rest of the compiler. 30099The 'enabled' attribute can be used to conditionally enable or disable 30100insn alternatives (*note Disable Insn Alternatives::). The 'predicable' 30101attribute, together with a suitable 'define_cond_exec' (*note 30102Conditional Execution::), can be used to automatically generate 30103conditional variants of instruction patterns. The 'mnemonic' attribute 30104can be used to check for the instruction mnemonic (*note Mnemonic 30105Attribute::). The compiler internally uses the names 'ce_enabled' and 30106'nonce_enabled', so they should not be used elsewhere as alternative 30107names. 30108 30109 LIST-OF-VALUES is either a string that specifies a comma-separated list 30110of values that can be assigned to the attribute, or a null string to 30111indicate that the attribute takes numeric values. 30112 30113 DEFAULT is an attribute expression that gives the value of this 30114attribute for insns that match patterns whose definition does not 30115include an explicit value for this attribute. *Note Attr Example::, for 30116more information on the handling of defaults. *Note Constant 30117Attributes::, for information on attributes that do not depend on any 30118particular insn. 30119 30120 For each defined attribute, a number of definitions are written to the 30121'insn-attr.h' file. For cases where an explicit set of values is 30122specified for an attribute, the following are defined: 30123 30124 * A '#define' is written for the symbol 'HAVE_ATTR_NAME'. 30125 30126 * An enumerated class is defined for 'attr_NAME' with elements of the 30127 form 'UPPER-NAME_UPPER-VALUE' where the attribute name and value 30128 are first converted to uppercase. 30129 30130 * A function 'get_attr_NAME' is defined that is passed an insn and 30131 returns the attribute value for that insn. 30132 30133 For example, if the following is present in the 'md' file: 30134 30135 (define_attr "type" "branch,fp,load,store,arith" ...) 30136 30137the following lines will be written to the file 'insn-attr.h'. 30138 30139 #define HAVE_ATTR_type 1 30140 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 30141 TYPE_STORE, TYPE_ARITH}; 30142 extern enum attr_type get_attr_type (); 30143 30144 If the attribute takes numeric values, no 'enum' type will be defined 30145and the function to obtain the attribute's value will return 'int'. 30146 30147 There are attributes which are tied to a specific meaning. These 30148attributes are not free to use for other purposes: 30149 30150'length' 30151 The 'length' attribute is used to calculate the length of emitted 30152 code chunks. This is especially important when verifying branch 30153 distances. *Note Insn Lengths::. 30154 30155'enabled' 30156 The 'enabled' attribute can be defined to prevent certain 30157 alternatives of an insn definition from being used during code 30158 generation. *Note Disable Insn Alternatives::. 30159 30160'mnemonic' 30161 The 'mnemonic' attribute can be defined to implement instruction 30162 specific checks in e.g. the pipeline description. *Note Mnemonic 30163 Attribute::. 30164 30165 For each of these special attributes, the corresponding 30166'HAVE_ATTR_NAME' '#define' is also written when the attribute is not 30167defined; in that case, it is defined as '0'. 30168 30169 Another way of defining an attribute is to use: 30170 30171 (define_enum_attr "ATTR" "ENUM" DEFAULT) 30172 30173 This works in just the same way as 'define_attr', except that the list 30174of values is taken from a separate enumeration called ENUM (*note 30175define_enum::). This form allows you to use the same list of values for 30176several attributes without having to repeat the list each time. For 30177example: 30178 30179 (define_enum "processor" [ 30180 model_a 30181 model_b 30182 ... 30183 ]) 30184 (define_enum_attr "arch" "processor" 30185 (const (symbol_ref "target_arch"))) 30186 (define_enum_attr "tune" "processor" 30187 (const (symbol_ref "target_tune"))) 30188 30189 defines the same attributes as: 30190 30191 (define_attr "arch" "model_a,model_b,..." 30192 (const (symbol_ref "target_arch"))) 30193 (define_attr "tune" "model_a,model_b,..." 30194 (const (symbol_ref "target_tune"))) 30195 30196 but without duplicating the processor list. The second example defines 30197two separate C enums ('attr_arch' and 'attr_tune') whereas the first 30198defines a single C enum ('processor'). 30199 30200 30201File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 30202 3020317.19.2 Attribute Expressions 30204----------------------------- 30205 30206RTL expressions used to define attributes use the codes described above 30207plus a few specific to attribute definitions, to be discussed below. 30208Attribute value expressions must have one of the following forms: 30209 30210'(const_int I)' 30211 The integer I specifies the value of a numeric attribute. I must 30212 be non-negative. 30213 30214 The value of a numeric attribute can be specified either with a 30215 'const_int', or as an integer represented as a string in 30216 'const_string', 'eq_attr' (see below), 'attr', 'symbol_ref', simple 30217 arithmetic expressions, and 'set_attr' overrides on specific 30218 instructions (*note Tagging Insns::). 30219 30220'(const_string VALUE)' 30221 The string VALUE specifies a constant attribute value. If VALUE is 30222 specified as '"*"', it means that the default value of the 30223 attribute is to be used for the insn containing this expression. 30224 '"*"' obviously cannot be used in the DEFAULT expression of a 30225 'define_attr'. 30226 30227 If the attribute whose value is being specified is numeric, VALUE 30228 must be a string containing a non-negative integer (normally 30229 'const_int' would be used in this case). Otherwise, it must 30230 contain one of the valid values for the attribute. 30231 30232'(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 30233 TEST specifies an attribute test, whose format is defined below. 30234 The value of this expression is TRUE-VALUE if TEST is true, 30235 otherwise it is FALSE-VALUE. 30236 30237'(cond [TEST1 VALUE1 ...] DEFAULT)' 30238 The first operand of this expression is a vector containing an even 30239 number of expressions and consisting of pairs of TEST and VALUE 30240 expressions. The value of the 'cond' expression is that of the 30241 VALUE corresponding to the first true TEST expression. If none of 30242 the TEST expressions are true, the value of the 'cond' expression 30243 is that of the DEFAULT expression. 30244 30245 TEST expressions can have one of the following forms: 30246 30247'(const_int I)' 30248 This test is true if I is nonzero and false otherwise. 30249 30250'(not TEST)' 30251'(ior TEST1 TEST2)' 30252'(and TEST1 TEST2)' 30253 These tests are true if the indicated logical function is true. 30254 30255'(match_operand:M N PRED CONSTRAINTS)' 30256 This test is true if operand N of the insn whose attribute value is 30257 being determined has mode M (this part of the test is ignored if M 30258 is 'VOIDmode') and the function specified by the string PRED 30259 returns a nonzero value when passed operand N and mode M (this part 30260 of the test is ignored if PRED is the null string). 30261 30262 The CONSTRAINTS operand is ignored and should be the null string. 30263 30264'(match_test C-EXPR)' 30265 The test is true if C expression C-EXPR is true. In non-constant 30266 attributes, C-EXPR has access to the following variables: 30267 30268 INSN 30269 The rtl instruction under test. 30270 WHICH_ALTERNATIVE 30271 The 'define_insn' alternative that INSN matches. *Note Output 30272 Statement::. 30273 OPERANDS 30274 An array of INSN's rtl operands. 30275 30276 C-EXPR behaves like the condition in a C 'if' statement, so there 30277 is no need to explicitly convert the expression into a boolean 0 or 30278 1 value. For example, the following two tests are equivalent: 30279 30280 (match_test "x & 2") 30281 (match_test "(x & 2) != 0") 30282 30283'(le ARITH1 ARITH2)' 30284'(leu ARITH1 ARITH2)' 30285'(lt ARITH1 ARITH2)' 30286'(ltu ARITH1 ARITH2)' 30287'(gt ARITH1 ARITH2)' 30288'(gtu ARITH1 ARITH2)' 30289'(ge ARITH1 ARITH2)' 30290'(geu ARITH1 ARITH2)' 30291'(ne ARITH1 ARITH2)' 30292'(eq ARITH1 ARITH2)' 30293 These tests are true if the indicated comparison of the two 30294 arithmetic expressions is true. Arithmetic expressions are formed 30295 with 'plus', 'minus', 'mult', 'div', 'mod', 'abs', 'neg', 'and', 30296 'ior', 'xor', 'not', 'ashift', 'lshiftrt', and 'ashiftrt' 30297 expressions. 30298 30299 'const_int' and 'symbol_ref' are always valid terms (*note Insn 30300 Lengths::,for additional forms). 'symbol_ref' is a string denoting 30301 a C expression that yields an 'int' when evaluated by the 30302 'get_attr_...' routine. It should normally be a global variable. 30303 30304'(eq_attr NAME VALUE)' 30305 NAME is a string specifying the name of an attribute. 30306 30307 VALUE is a string that is either a valid value for attribute NAME, 30308 a comma-separated list of values, or '!' followed by a value or 30309 list. If VALUE does not begin with a '!', this test is true if the 30310 value of the NAME attribute of the current insn is in the list 30311 specified by VALUE. If VALUE begins with a '!', this test is true 30312 if the attribute's value is _not_ in the specified list. 30313 30314 For example, 30315 30316 (eq_attr "type" "load,store") 30317 30318 is equivalent to 30319 30320 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 30321 30322 If NAME specifies an attribute of 'alternative', it refers to the 30323 value of the compiler variable 'which_alternative' (*note Output 30324 Statement::) and the values must be small integers. For example, 30325 30326 (eq_attr "alternative" "2,3") 30327 30328 is equivalent to 30329 30330 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 30331 (eq (symbol_ref "which_alternative") (const_int 3))) 30332 30333 Note that, for most attributes, an 'eq_attr' test is simplified in 30334 cases where the value of the attribute being tested is known for 30335 all insns matching a particular pattern. This is by far the most 30336 common case. 30337 30338'(attr_flag NAME)' 30339 The value of an 'attr_flag' expression is true if the flag 30340 specified by NAME is true for the 'insn' currently being scheduled. 30341 30342 NAME is a string specifying one of a fixed set of flags to test. 30343 Test the flags 'forward' and 'backward' to determine the direction 30344 of a conditional branch. 30345 30346 This example describes a conditional branch delay slot which can be 30347 nullified for forward branches that are taken (annul-true) or for 30348 backward branches which are not taken (annul-false). 30349 30350 (define_delay (eq_attr "type" "cbranch") 30351 [(eq_attr "in_branch_delay" "true") 30352 (and (eq_attr "in_branch_delay" "true") 30353 (attr_flag "forward")) 30354 (and (eq_attr "in_branch_delay" "true") 30355 (attr_flag "backward"))]) 30356 30357 The 'forward' and 'backward' flags are false if the current 'insn' 30358 being scheduled is not a conditional branch. 30359 30360 'attr_flag' is only used during delay slot scheduling and has no 30361 meaning to other passes of the compiler. 30362 30363'(attr NAME)' 30364 The value of another attribute is returned. This is most useful 30365 for numeric attributes, as 'eq_attr' and 'attr_flag' produce more 30366 efficient code for non-numeric attributes. 30367 30368 30369File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 30370 3037117.19.3 Assigning Attribute Values to Insns 30372------------------------------------------- 30373 30374The value assigned to an attribute of an insn is primarily determined by 30375which pattern is matched by that insn (or which 'define_peephole' 30376generated it). Every 'define_insn' and 'define_peephole' can have an 30377optional last argument to specify the values of attributes for matching 30378insns. The value of any attribute not specified in a particular insn is 30379set to the default value for that attribute, as specified in its 30380'define_attr'. Extensive use of default values for attributes permits 30381the specification of the values for only one or two attributes in the 30382definition of most insn patterns, as seen in the example in the next 30383section. 30384 30385 The optional last argument of 'define_insn' and 'define_peephole' is a 30386vector of expressions, each of which defines the value for a single 30387attribute. The most general way of assigning an attribute's value is to 30388use a 'set' expression whose first operand is an 'attr' expression 30389giving the name of the attribute being set. The second operand of the 30390'set' is an attribute expression (*note Expressions::) giving the value 30391of the attribute. 30392 30393 When the attribute value depends on the 'alternative' attribute (i.e., 30394which is the applicable alternative in the constraint of the insn), the 30395'set_attr_alternative' expression can be used. It allows the 30396specification of a vector of attribute expressions, one for each 30397alternative. 30398 30399 When the generality of arbitrary attribute expressions is not required, 30400the simpler 'set_attr' expression can be used, which allows specifying a 30401string giving either a single attribute value or a list of attribute 30402values, one for each alternative. 30403 30404 The form of each of the above specifications is shown below. In each 30405case, NAME is a string specifying the attribute to be set. 30406 30407'(set_attr NAME VALUE-STRING)' 30408 VALUE-STRING is either a string giving the desired attribute value, 30409 or a string containing a comma-separated list giving the values for 30410 succeeding alternatives. The number of elements must match the 30411 number of alternatives in the constraint of the insn pattern. 30412 30413 Note that it may be useful to specify '*' for some alternative, in 30414 which case the attribute will assume its default value for insns 30415 matching that alternative. 30416 30417'(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 30418 Depending on the alternative of the insn, the value will be one of 30419 the specified values. This is a shorthand for using a 'cond' with 30420 tests on the 'alternative' attribute. 30421 30422'(set (attr NAME) VALUE)' 30423 The first operand of this 'set' must be the special RTL expression 30424 'attr', whose sole operand is a string giving the name of the 30425 attribute being set. VALUE is the value of the attribute. 30426 30427 The following shows three different ways of representing the same 30428attribute value specification: 30429 30430 (set_attr "type" "load,store,arith") 30431 30432 (set_attr_alternative "type" 30433 [(const_string "load") (const_string "store") 30434 (const_string "arith")]) 30435 30436 (set (attr "type") 30437 (cond [(eq_attr "alternative" "1") (const_string "load") 30438 (eq_attr "alternative" "2") (const_string "store")] 30439 (const_string "arith"))) 30440 30441 The 'define_asm_attributes' expression provides a mechanism to specify 30442the attributes assigned to insns produced from an 'asm' statement. It 30443has the form: 30444 30445 (define_asm_attributes [ATTR-SETS]) 30446 30447where ATTR-SETS is specified the same as for both the 'define_insn' and 30448the 'define_peephole' expressions. 30449 30450 These values will typically be the "worst case" attribute values. For 30451example, they might indicate that the condition code will be clobbered. 30452 30453 A specification for a 'length' attribute is handled specially. The way 30454to compute the length of an 'asm' insn is to multiply the length 30455specified in the expression 'define_asm_attributes' by the number of 30456machine instructions specified in the 'asm' statement, determined by 30457counting the number of semicolons and newlines in the string. 30458Therefore, the value of the 'length' attribute specified in a 30459'define_asm_attributes' should be the maximum possible length of a 30460single machine instruction. 30461 30462 30463File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 30464 3046517.19.4 Example of Attribute Specifications 30466------------------------------------------- 30467 30468The judicious use of defaulting is important in the efficient use of 30469insn attributes. Typically, insns are divided into "types" and an 30470attribute, customarily called 'type', is used to represent this value. 30471This attribute is normally used only to define the default value for 30472other attributes. An example will clarify this usage. 30473 30474 Assume we have a RISC machine with a condition code and in which only 30475full-word operations are performed in registers. Let us assume that we 30476can divide all insns into loads, stores, (integer) arithmetic 30477operations, floating point operations, and branches. 30478 30479 Here we will concern ourselves with determining the effect of an insn 30480on the condition code and will limit ourselves to the following possible 30481effects: The condition code can be set unpredictably (clobbered), not be 30482changed, be set to agree with the results of the operation, or only 30483changed if the item previously set into the condition code has been 30484modified. 30485 30486 Here is part of a sample 'md' file for such a machine: 30487 30488 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 30489 30490 (define_attr "cc" "clobber,unchanged,set,change0" 30491 (cond [(eq_attr "type" "load") 30492 (const_string "change0") 30493 (eq_attr "type" "store,branch") 30494 (const_string "unchanged") 30495 (eq_attr "type" "arith") 30496 (if_then_else (match_operand:SI 0 "" "") 30497 (const_string "set") 30498 (const_string "clobber"))] 30499 (const_string "clobber"))) 30500 30501 (define_insn "" 30502 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 30503 (match_operand:SI 1 "general_operand" "r,m,r"))] 30504 "" 30505 "@ 30506 move %0,%1 30507 load %0,%1 30508 store %0,%1" 30509 [(set_attr "type" "arith,load,store")]) 30510 30511 Note that we assume in the above example that arithmetic operations 30512performed on quantities smaller than a machine word clobber the 30513condition code since they will set the condition code to a value 30514corresponding to the full-word result. 30515 30516 30517File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 30518 3051917.19.5 Computing the Length of an Insn 30520--------------------------------------- 30521 30522For many machines, multiple types of branch instructions are provided, 30523each for different length branch displacements. In most cases, the 30524assembler will choose the correct instruction to use. However, when the 30525assembler cannot do so, GCC can when a special attribute, the 'length' 30526attribute, is defined. This attribute must be defined to have numeric 30527values by specifying a null string in its 'define_attr'. 30528 30529 In the case of the 'length' attribute, two additional forms of 30530arithmetic terms are allowed in test expressions: 30531 30532'(match_dup N)' 30533 This refers to the address of operand N of the current insn, which 30534 must be a 'label_ref'. 30535 30536'(pc)' 30537 For non-branch instructions and backward branch instructions, this 30538 refers to the address of the current insn. But for forward branch 30539 instructions, this refers to the address of the next insn, because 30540 the length of the current insn is to be computed. 30541 30542 For normal insns, the length will be determined by value of the 30543'length' attribute. In the case of 'addr_vec' and 'addr_diff_vec' insn 30544patterns, the length is computed as the number of vectors multiplied by 30545the size of each vector. 30546 30547 Lengths are measured in addressable storage units (bytes). 30548 30549 Note that it is possible to call functions via the 'symbol_ref' 30550mechanism to compute the length of an insn. However, if you use this 30551mechanism you must provide dummy clauses to express the maximum length 30552without using the function call. You can an example of this in the 'pa' 30553machine description for the 'call_symref' pattern. 30554 30555 The following macros can be used to refine the length computation: 30556 30557'ADJUST_INSN_LENGTH (INSN, LENGTH)' 30558 If defined, modifies the length assigned to instruction INSN as a 30559 function of the context in which it is used. LENGTH is an lvalue 30560 that contains the initially computed length of the insn and should 30561 be updated with the correct length of the insn. 30562 30563 This macro will normally not be required. A case in which it is 30564 required is the ROMP. On this machine, the size of an 'addr_vec' 30565 insn must be increased by two to compensate for the fact that 30566 alignment may be required. 30567 30568 The routine that returns 'get_attr_length' (the value of the 'length' 30569attribute) can be used by the output routine to determine the form of 30570the branch instruction to be written, as the example below illustrates. 30571 30572 As an example of the specification of variable-length branches, 30573consider the IBM 360. If we adopt the convention that a register will 30574be set to the starting address of a function, we can jump to labels 30575within 4k of the start using a four-byte instruction. Otherwise, we 30576need a six-byte sequence to load the address from memory and then branch 30577to it. 30578 30579 On such a machine, a pattern for a branch instruction might be 30580specified as follows: 30581 30582 (define_insn "jump" 30583 [(set (pc) 30584 (label_ref (match_operand 0 "" "")))] 30585 "" 30586 { 30587 return (get_attr_length (insn) == 4 30588 ? "b %l0" : "l r15,=a(%l0); br r15"); 30589 } 30590 [(set (attr "length") 30591 (if_then_else (lt (match_dup 0) (const_int 4096)) 30592 (const_int 4) 30593 (const_int 6)))]) 30594 30595 30596File: gccint.info, Node: Constant Attributes, Next: Mnemonic Attribute, Prev: Insn Lengths, Up: Insn Attributes 30597 3059817.19.6 Constant Attributes 30599--------------------------- 30600 30601A special form of 'define_attr', where the expression for the default 30602value is a 'const' expression, indicates an attribute that is constant 30603for a given run of the compiler. Constant attributes may be used to 30604specify which variety of processor is used. For example, 30605 30606 (define_attr "cpu" "m88100,m88110,m88000" 30607 (const 30608 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 30609 (symbol_ref "TARGET_88110") (const_string "m88110")] 30610 (const_string "m88000")))) 30611 30612 (define_attr "memory" "fast,slow" 30613 (const 30614 (if_then_else (symbol_ref "TARGET_FAST_MEM") 30615 (const_string "fast") 30616 (const_string "slow")))) 30617 30618 The routine generated for constant attributes has no parameters as it 30619does not depend on any particular insn. RTL expressions used to define 30620the value of a constant attribute may use the 'symbol_ref' form, but may 30621not use either the 'match_operand' form or 'eq_attr' forms involving 30622insn attributes. 30623 30624 30625File: gccint.info, Node: Mnemonic Attribute, Next: Delay Slots, Prev: Constant Attributes, Up: Insn Attributes 30626 3062717.19.7 Mnemonic Attribute 30628-------------------------- 30629 30630The 'mnemonic' attribute is a string type attribute holding the 30631instruction mnemonic for an insn alternative. The attribute values will 30632automatically be generated by the machine description parser if there is 30633an attribute definition in the md file: 30634 30635 (define_attr "mnemonic" "unknown" (const_string "unknown")) 30636 30637 The default value can be freely chosen as long as it does not collide 30638with any of the instruction mnemonics. This value will be used whenever 30639the machine description parser is not able to determine the mnemonic 30640string. This might be the case for output templates containing more 30641than a single instruction as in '"mvcle\t%0,%1,0\;jo\t.-4"'. 30642 30643 The 'mnemonic' attribute set is not generated automatically if the 30644instruction string is generated via C code. 30645 30646 An existing 'mnemonic' attribute set in an insn definition will not be 30647overriden by the md file parser. That way it is possible to manually 30648set the instruction mnemonics for the cases where the md file parser 30649fails to determine it automatically. 30650 30651 The 'mnemonic' attribute is useful for dealing with instruction 30652specific properties in the pipeline description without defining 30653additional insn attributes. 30654 30655 (define_attr "ooo_expanded" "" 30656 (cond [(eq_attr "mnemonic" "dlr,dsgr,d,dsgf,stam,dsgfr,dlgr") 30657 (const_int 1)] 30658 (const_int 0))) 30659 30660 30661File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Mnemonic Attribute, Up: Insn Attributes 30662 3066317.19.8 Delay Slot Scheduling 30664----------------------------- 30665 30666The insn attribute mechanism can be used to specify the requirements for 30667delay slots, if any, on a target machine. An instruction is said to 30668require a "delay slot" if some instructions that are physically after 30669the instruction are executed as if they were located before it. Classic 30670examples are branch and call instructions, which often execute the 30671following instruction before the branch or call is performed. 30672 30673 On some machines, conditional branch instructions can optionally 30674"annul" instructions in the delay slot. This means that the instruction 30675will not be executed for certain branch outcomes. Both instructions 30676that annul if the branch is true and instructions that annul if the 30677branch is false are supported. 30678 30679 Delay slot scheduling differs from instruction scheduling in that 30680determining whether an instruction needs a delay slot is dependent only 30681on the type of instruction being generated, not on data flow between the 30682instructions. See the next section for a discussion of data-dependent 30683instruction scheduling. 30684 30685 The requirement of an insn needing one or more delay slots is indicated 30686via the 'define_delay' expression. It has the following form: 30687 30688 (define_delay TEST 30689 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 30690 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 30691 ...]) 30692 30693 TEST is an attribute test that indicates whether this 'define_delay' 30694applies to a particular insn. If so, the number of required delay slots 30695is determined by the length of the vector specified as the second 30696argument. An insn placed in delay slot N must satisfy attribute test 30697DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 30698may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 30699specifies which insns in the delay slot may be annulled if the branch is 30700false. If annulling is not supported for that delay slot, '(nil)' 30701should be coded. 30702 30703 For example, in the common case where branch and call insns require a 30704single delay slot, which may contain any insn other than a branch or 30705call, the following would be placed in the 'md' file: 30706 30707 (define_delay (eq_attr "type" "branch,call") 30708 [(eq_attr "type" "!branch,call") (nil) (nil)]) 30709 30710 Multiple 'define_delay' expressions may be specified. In this case, 30711each such expression specifies different delay slot requirements and 30712there must be no insn for which tests in two 'define_delay' expressions 30713are both true. 30714 30715 For example, if we have a machine that requires one delay slot for 30716branches but two for calls, no delay slot can contain a branch or call 30717insn, and any valid insn in the delay slot for the branch can be 30718annulled if the branch is true, we might represent this as follows: 30719 30720 (define_delay (eq_attr "type" "branch") 30721 [(eq_attr "type" "!branch,call") 30722 (eq_attr "type" "!branch,call") 30723 (nil)]) 30724 30725 (define_delay (eq_attr "type" "call") 30726 [(eq_attr "type" "!branch,call") (nil) (nil) 30727 (eq_attr "type" "!branch,call") (nil) (nil)]) 30728 30729 30730File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 30731 3073217.19.9 Specifying processor pipeline description 30733------------------------------------------------- 30734 30735To achieve better performance, most modern processors (super-pipelined, 30736superscalar RISC, and VLIW processors) have many "functional units" on 30737which several instructions can be executed simultaneously. An 30738instruction starts execution if its issue conditions are satisfied. If 30739not, the instruction is stalled until its conditions are satisfied. 30740Such "interlock (pipeline) delay" causes interruption of the fetching of 30741successor instructions (or demands nop instructions, e.g. for some MIPS 30742processors). 30743 30744 There are two major kinds of interlock delays in modern processors. 30745The first one is a data dependence delay determining "instruction 30746latency time". The instruction execution is not started until all 30747source data have been evaluated by prior instructions (there are more 30748complex cases when the instruction execution starts even when the data 30749are not available but will be ready in given time after the instruction 30750execution start). Taking the data dependence delays into account is 30751simple. The data dependence (true, output, and anti-dependence) delay 30752between two instructions is given by a constant. In most cases this 30753approach is adequate. The second kind of interlock delays is a 30754reservation delay. The reservation delay means that two instructions 30755under execution will be in need of shared processors resources, i.e. 30756buses, internal registers, and/or functional units, which are reserved 30757for some time. Taking this kind of delay into account is complex 30758especially for modern RISC processors. 30759 30760 The task of exploiting more processor parallelism is solved by an 30761instruction scheduler. For a better solution to this problem, the 30762instruction scheduler has to have an adequate description of the 30763processor parallelism (or "pipeline description"). GCC machine 30764descriptions describe processor parallelism and functional unit 30765reservations for groups of instructions with the aid of "regular 30766expressions". 30767 30768 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 30769figure out the possibility of the instruction issue by the processor on 30770a given simulated processor cycle. The pipeline hazard recognizer is 30771automatically generated from the processor pipeline description. The 30772pipeline hazard recognizer generated from the machine description is 30773based on a deterministic finite state automaton (DFA): the instruction 30774issue is possible if there is a transition from one automaton state to 30775another one. This algorithm is very fast, and furthermore, its speed is 30776not dependent on processor complexity(1). 30777 30778 The rest of this section describes the directives that constitute an 30779automaton-based processor pipeline description. The order of these 30780constructions within the machine description file is not important. 30781 30782 The following optional construction describes names of automata 30783generated and used for the pipeline hazards recognition. Sometimes the 30784generated finite state automaton used by the pipeline hazard recognizer 30785is large. If we use more than one automaton and bind functional units 30786to the automata, the total size of the automata is usually less than the 30787size of the single automaton. If there is no one such construction, 30788only one finite state automaton is generated. 30789 30790 (define_automaton AUTOMATA-NAMES) 30791 30792 AUTOMATA-NAMES is a string giving names of the automata. The names are 30793separated by commas. All the automata should have unique names. The 30794automaton name is used in the constructions 'define_cpu_unit' and 30795'define_query_cpu_unit'. 30796 30797 Each processor functional unit used in the description of instruction 30798reservations should be described by the following construction. 30799 30800 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 30801 30802 UNIT-NAMES is a string giving the names of the functional units 30803separated by commas. Don't use name 'nothing', it is reserved for other 30804goals. 30805 30806 AUTOMATON-NAME is a string giving the name of the automaton with which 30807the unit is bound. The automaton should be described in construction 30808'define_automaton'. You should give "automaton-name", if there is a 30809defined automaton. 30810 30811 The assignment of units to automata are constrained by the uses of the 30812units in insn reservations. The most important constraint is: if a unit 30813reservation is present on a particular cycle of an alternative for an 30814insn reservation, then some unit from the same automaton must be present 30815on the same cycle for the other alternatives of the insn reservation. 30816The rest of the constraints are mentioned in the description of the 30817subsequent constructions. 30818 30819 The following construction describes CPU functional units analogously 30820to 'define_cpu_unit'. The reservation of such units can be queried for 30821an automaton state. The instruction scheduler never queries reservation 30822of functional units for given automaton state. So as a rule, you don't 30823need this construction. This construction could be used for future code 30824generation goals (e.g. to generate VLIW insn templates). 30825 30826 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 30827 30828 UNIT-NAMES is a string giving names of the functional units separated 30829by commas. 30830 30831 AUTOMATON-NAME is a string giving the name of the automaton with which 30832the unit is bound. 30833 30834 The following construction is the major one to describe pipeline 30835characteristics of an instruction. 30836 30837 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 30838 CONDITION REGEXP) 30839 30840 DEFAULT_LATENCY is a number giving latency time of the instruction. 30841There is an important difference between the old description and the 30842automaton based pipeline description. The latency time is used for all 30843dependencies when we use the old description. In the automaton based 30844pipeline description, the given latency time is only used for true 30845dependencies. The cost of anti-dependencies is always zero and the cost 30846of output dependencies is the difference between latency times of the 30847producing and consuming insns (if the difference is negative, the cost 30848is considered to be zero). You can always change the default costs for 30849any description by using the target hook 'TARGET_SCHED_ADJUST_COST' 30850(*note Scheduling::). 30851 30852 INSN-NAME is a string giving the internal name of the insn. The 30853internal names are used in constructions 'define_bypass' and in the 30854automaton description file generated for debugging. The internal name 30855has nothing in common with the names in 'define_insn'. It is a good 30856practice to use insn classes described in the processor manual. 30857 30858 CONDITION defines what RTL insns are described by this construction. 30859You should remember that you will be in trouble if CONDITION for two or 30860more different 'define_insn_reservation' constructions is TRUE for an 30861insn. In this case what reservation will be used for the insn is not 30862defined. Such cases are not checked during generation of the pipeline 30863hazards recognizer because in general recognizing that two conditions 30864may have the same value is quite difficult (especially if the conditions 30865contain 'symbol_ref'). It is also not checked during the pipeline 30866hazard recognizer work because it would slow down the recognizer 30867considerably. 30868 30869 REGEXP is a string describing the reservation of the cpu's functional 30870units by the instruction. The reservations are described by a regular 30871expression according to the following syntax: 30872 30873 regexp = regexp "," oneof 30874 | oneof 30875 30876 oneof = oneof "|" allof 30877 | allof 30878 30879 allof = allof "+" repeat 30880 | repeat 30881 30882 repeat = element "*" number 30883 | element 30884 30885 element = cpu_function_unit_name 30886 | reservation_name 30887 | result_name 30888 | "nothing" 30889 | "(" regexp ")" 30890 30891 * ',' is used for describing the start of the next cycle in the 30892 reservation. 30893 30894 * '|' is used for describing a reservation described by the first 30895 regular expression *or* a reservation described by the second 30896 regular expression *or* etc. 30897 30898 * '+' is used for describing a reservation described by the first 30899 regular expression *and* a reservation described by the second 30900 regular expression *and* etc. 30901 30902 * '*' is used for convenience and simply means a sequence in which 30903 the regular expression are repeated NUMBER times with cycle 30904 advancing (see ','). 30905 30906 * 'cpu_function_unit_name' denotes reservation of the named 30907 functional unit. 30908 30909 * 'reservation_name' -- see description of construction 30910 'define_reservation'. 30911 30912 * 'nothing' denotes no unit reservations. 30913 30914 Sometimes unit reservations for different insns contain common parts. 30915In such case, you can simplify the pipeline description by describing 30916the common part by the following construction 30917 30918 (define_reservation RESERVATION-NAME REGEXP) 30919 30920 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 30921names and reservation names are in the same name space. So the 30922reservation names should be different from the functional unit names and 30923cannot be the reserved name 'nothing'. 30924 30925 The following construction is used to describe exceptions in the 30926latency time for given instruction pair. This is so called bypasses. 30927 30928 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 30929 [GUARD]) 30930 30931 NUMBER defines when the result generated by the instructions given in 30932string OUT_INSN_NAMES will be ready for the instructions given in string 30933IN_INSN_NAMES. Each of these strings is a comma-separated list of 30934filename-style globs and they refer to the names of 30935'define_insn_reservation's. For example: 30936 (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*") 30937 defines a bypass between instructions that start with 'cpu1_load_' or 30938'cpu1_store_' and those that start with 'cpu1_load_'. 30939 30940 GUARD is an optional string giving the name of a C function which 30941defines an additional guard for the bypass. The function will get the 30942two insns as parameters. If the function returns zero the bypass will 30943be ignored for this case. The additional guard is necessary to 30944recognize complicated bypasses, e.g. when the consumer is only an 30945address of insn 'store' (not a stored value). 30946 30947 If there are more one bypass with the same output and input insns, the 30948chosen bypass is the first bypass with a guard in description whose 30949guard function returns nonzero. If there is no such bypass, then bypass 30950without the guard function is chosen. 30951 30952 The following five constructions are usually used to describe VLIW 30953processors, or more precisely, to describe a placement of small 30954instructions into VLIW instruction slots. They can be used for RISC 30955processors, too. 30956 30957 (exclusion_set UNIT-NAMES UNIT-NAMES) 30958 (presence_set UNIT-NAMES PATTERNS) 30959 (final_presence_set UNIT-NAMES PATTERNS) 30960 (absence_set UNIT-NAMES PATTERNS) 30961 (final_absence_set UNIT-NAMES PATTERNS) 30962 30963 UNIT-NAMES is a string giving names of functional units separated by 30964commas. 30965 30966 PATTERNS is a string giving patterns of functional units separated by 30967comma. Currently pattern is one unit or units separated by 30968white-spaces. 30969 30970 The first construction ('exclusion_set') means that each functional 30971unit in the first string cannot be reserved simultaneously with a unit 30972whose name is in the second string and vice versa. For example, the 30973construction is useful for describing processors (e.g. some SPARC 30974processors) with a fully pipelined floating point functional unit which 30975can execute simultaneously only single floating point insns or only 30976double floating point insns. 30977 30978 The second construction ('presence_set') means that each functional 30979unit in the first string cannot be reserved unless at least one of 30980pattern of units whose names are in the second string is reserved. This 30981is an asymmetric relation. For example, it is useful for description 30982that VLIW 'slot1' is reserved after 'slot0' reservation. We could 30983describe it by the following construction 30984 30985 (presence_set "slot1" "slot0") 30986 30987 Or 'slot1' is reserved only after 'slot0' and unit 'b0' reservation. 30988In this case we could write 30989 30990 (presence_set "slot1" "slot0 b0") 30991 30992 The third construction ('final_presence_set') is analogous to 30993'presence_set'. The difference between them is when checking is done. 30994When an instruction is issued in given automaton state reflecting all 30995current and planned unit reservations, the automaton state is changed. 30996The first state is a source state, the second one is a result state. 30997Checking for 'presence_set' is done on the source state reservation, 30998checking for 'final_presence_set' is done on the result reservation. 30999This construction is useful to describe a reservation which is actually 31000two subsequent reservations. For example, if we use 31001 31002 (presence_set "slot1" "slot0") 31003 31004 the following insn will be never issued (because 'slot1' requires 31005'slot0' which is absent in the source state). 31006 31007 (define_reservation "insn_and_nop" "slot0 + slot1") 31008 31009 but it can be issued if we use analogous 'final_presence_set'. 31010 31011 The forth construction ('absence_set') means that each functional unit 31012in the first string can be reserved only if each pattern of units whose 31013names are in the second string is not reserved. This is an asymmetric 31014relation (actually 'exclusion_set' is analogous to this one but it is 31015symmetric). For example it might be useful in a VLIW description to say 31016that 'slot0' cannot be reserved after either 'slot1' or 'slot2' have 31017been reserved. This can be described as: 31018 31019 (absence_set "slot0" "slot1, slot2") 31020 31021 Or 'slot2' cannot be reserved if 'slot0' and unit 'b0' are reserved or 31022'slot1' and unit 'b1' are reserved. In this case we could write 31023 31024 (absence_set "slot2" "slot0 b0, slot1 b1") 31025 31026 All functional units mentioned in a set should belong to the same 31027automaton. 31028 31029 The last construction ('final_absence_set') is analogous to 31030'absence_set' but checking is done on the result (state) reservation. 31031See comments for 'final_presence_set'. 31032 31033 You can control the generator of the pipeline hazard recognizer with 31034the following construction. 31035 31036 (automata_option OPTIONS) 31037 31038 OPTIONS is a string giving options which affect the generated code. 31039Currently there are the following options: 31040 31041 * "no-minimization" makes no minimization of the automaton. This is 31042 only worth to do when we are debugging the description and need to 31043 look more accurately at reservations of states. 31044 31045 * "time" means printing time statistics about the generation of 31046 automata. 31047 31048 * "stats" means printing statistics about the generated automata such 31049 as the number of DFA states, NDFA states and arcs. 31050 31051 * "v" means a generation of the file describing the result automata. 31052 The file has suffix '.dfa' and can be used for the description 31053 verification and debugging. 31054 31055 * "w" means a generation of warning instead of error for non-critical 31056 errors. 31057 31058 * "no-comb-vect" prevents the automaton generator from generating two 31059 data structures and comparing them for space efficiency. Using a 31060 comb vector to represent transitions may be better, but it can be 31061 very expensive to construct. This option is useful if the build 31062 process spends an unacceptably long time in genautomata. 31063 31064 * "ndfa" makes nondeterministic finite state automata. This affects 31065 the treatment of operator '|' in the regular expressions. The 31066 usual treatment of the operator is to try the first alternative 31067 and, if the reservation is not possible, the second alternative. 31068 The nondeterministic treatment means trying all alternatives, some 31069 of them may be rejected by reservations in the subsequent insns. 31070 31071 * "collapse-ndfa" modifies the behavior of the generator when 31072 producing an automaton. An additional state transition to collapse 31073 a nondeterministic NDFA state to a deterministic DFA state is 31074 generated. It can be triggered by passing 'const0_rtx' to 31075 state_transition. In such an automaton, cycle advance transitions 31076 are available only for these collapsed states. This option is 31077 useful for ports that want to use the 'ndfa' option, but also want 31078 to use 'define_query_cpu_unit' to assign units to insns issued in a 31079 cycle. 31080 31081 * "progress" means output of a progress bar showing how many states 31082 were generated so far for automaton being processed. This is 31083 useful during debugging a DFA description. If you see too many 31084 generated states, you could interrupt the generator of the pipeline 31085 hazard recognizer and try to figure out a reason for generation of 31086 the huge automaton. 31087 31088 As an example, consider a superscalar RISC machine which can issue 31089three insns (two integer insns and one floating point insn) on the cycle 31090but can finish only two insns. To describe this, we define the 31091following functional units. 31092 31093 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 31094 (define_cpu_unit "port0, port1") 31095 31096 All simple integer insns can be executed in any integer pipeline and 31097their result is ready in two cycles. The simple integer insns are 31098issued into the first pipeline unless it is reserved, otherwise they are 31099issued into the second pipeline. Integer division and multiplication 31100insns can be executed only in the second integer pipeline and their 31101results are ready correspondingly in 9 and 4 cycles. The integer 31102division is not pipelined, i.e. the subsequent integer division insn 31103cannot be issued until the current division insn finished. Floating 31104point insns are fully pipelined and their results are ready in 3 cycles. 31105Where the result of a floating point insn is used by an integer insn, an 31106additional delay of one cycle is incurred. To describe all of this we 31107could specify 31108 31109 (define_cpu_unit "div") 31110 31111 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 31112 "(i0_pipeline | i1_pipeline), (port0 | port1)") 31113 31114 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 31115 "i1_pipeline, nothing*2, (port0 | port1)") 31116 31117 (define_insn_reservation "div" 9 (eq_attr "type" "div") 31118 "i1_pipeline, div*7, div + (port0 | port1)") 31119 31120 (define_insn_reservation "float" 3 (eq_attr "type" "float") 31121 "f_pipeline, nothing, (port0 | port1)) 31122 31123 (define_bypass 4 "float" "simple,mult,div") 31124 31125 To simplify the description we could describe the following reservation 31126 31127 (define_reservation "finish" "port0|port1") 31128 31129 and use it in all 'define_insn_reservation' as in the following 31130construction 31131 31132 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 31133 "(i0_pipeline | i1_pipeline), finish") 31134 31135 ---------- Footnotes ---------- 31136 31137 (1) However, the size of the automaton depends on processor 31138complexity. To limit this effect, machine descriptions can split 31139orthogonal parts of the machine description among several automata: but 31140then, since each of these must be stepped independently, this does cause 31141a small decrease in the algorithm's performance. 31142 31143 31144File: gccint.info, Node: Conditional Execution, Next: Define Subst, Prev: Insn Attributes, Up: Machine Desc 31145 3114617.20 Conditional Execution 31147=========================== 31148 31149A number of architectures provide for some form of conditional 31150execution, or predication. The hallmark of this feature is the ability 31151to nullify most of the instructions in the instruction set. When the 31152instruction set is large and not entirely symmetric, it can be quite 31153tedious to describe these forms directly in the '.md' file. An 31154alternative is the 'define_cond_exec' template. 31155 31156 (define_cond_exec 31157 [PREDICATE-PATTERN] 31158 "CONDITION" 31159 "OUTPUT-TEMPLATE" 31160 "OPTIONAL-INSN-ATTRIBUES") 31161 31162 PREDICATE-PATTERN is the condition that must be true for the insn to be 31163executed at runtime and should match a relational operator. One can use 31164'match_operator' to match several relational operators at once. Any 31165'match_operand' operands must have no more than one alternative. 31166 31167 CONDITION is a C expression that must be true for the generated pattern 31168to match. 31169 31170 OUTPUT-TEMPLATE is a string similar to the 'define_insn' output 31171template (*note Output Template::), except that the '*' and '@' special 31172cases do not apply. This is only useful if the assembly text for the 31173predicate is a simple prefix to the main insn. In order to handle the 31174general case, there is a global variable 'current_insn_predicate' that 31175will contain the entire predicate if the current insn is predicated, and 31176will otherwise be 'NULL'. 31177 31178 OPTIONAL-INSN-ATTRIBUTES is an optional vector of attributes that gets 31179appended to the insn attributes of the produced cond_exec rtx. It can 31180be used to add some distinguishing attribute to cond_exec rtxs produced 31181that way. An example usage would be to use this attribute in 31182conjunction with attributes on the main pattern to disable particular 31183alternatives under certain conditions. 31184 31185 When 'define_cond_exec' is used, an implicit reference to the 31186'predicable' instruction attribute is made. *Note Insn Attributes::. 31187This attribute must be a boolean (i.e. have exactly two elements in its 31188LIST-OF-VALUES), with the possible values being 'no' and 'yes'. The 31189default and all uses in the insns must be a simple constant, not a 31190complex expressions. It may, however, depend on the alternative, by 31191using a comma-separated list of values. If that is the case, the port 31192should also define an 'enabled' attribute (*note Disable Insn 31193Alternatives::), which should also allow only 'no' and 'yes' as its 31194values. 31195 31196 For each 'define_insn' for which the 'predicable' attribute is true, a 31197new 'define_insn' pattern will be generated that matches a predicated 31198version of the instruction. For example, 31199 31200 (define_insn "addsi" 31201 [(set (match_operand:SI 0 "register_operand" "r") 31202 (plus:SI (match_operand:SI 1 "register_operand" "r") 31203 (match_operand:SI 2 "register_operand" "r")))] 31204 "TEST1" 31205 "add %2,%1,%0") 31206 31207 (define_cond_exec 31208 [(ne (match_operand:CC 0 "register_operand" "c") 31209 (const_int 0))] 31210 "TEST2" 31211 "(%0)") 31212 31213generates a new pattern 31214 31215 (define_insn "" 31216 [(cond_exec 31217 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 31218 (set (match_operand:SI 0 "register_operand" "r") 31219 (plus:SI (match_operand:SI 1 "register_operand" "r") 31220 (match_operand:SI 2 "register_operand" "r"))))] 31221 "(TEST2) && (TEST1)" 31222 "(%3) add %2,%1,%0") 31223 31224 31225File: gccint.info, Node: Define Subst, Next: Constant Definitions, Prev: Conditional Execution, Up: Machine Desc 31226 3122717.21 RTL Templates Transformations 31228=================================== 31229 31230For some hardware architectures there are common cases when the RTL 31231templates for the instructions can be derived from the other RTL 31232templates using simple transformations. E.g., 'i386.md' contains an RTL 31233template for the ordinary 'sub' instruction-- '*subsi_1', and for the 31234'sub' instruction with subsequent zero-extension--'*subsi_1_zext'. Such 31235cases can be easily implemented by a single meta-template capable of 31236generating a modified case based on the initial one: 31237 31238 (define_subst "NAME" 31239 [INPUT-TEMPLATE] 31240 "CONDITION" 31241 [OUTPUT-TEMPLATE]) 31242 INPUT-TEMPLATE is a pattern describing the source RTL template, which 31243will be transformed. 31244 31245 CONDITION is a C expression that is conjunct with the condition from 31246the input-template to generate a condition to be used in the 31247output-template. 31248 31249 OUTPUT-TEMPLATE is a pattern that will be used in the resulting 31250template. 31251 31252 'define_subst' mechanism is tightly coupled with the notion of the 31253subst attribute (*note Subst Iterators::). The use of 'define_subst' is 31254triggered by a reference to a subst attribute in the transforming RTL 31255template. This reference initiates duplication of the source RTL 31256template and substitution of the attributes with their values. The 31257source RTL template is left unchanged, while the copy is transformed by 31258'define_subst'. This transformation can fail in the case when the 31259source RTL template is not matched against the input-template of the 31260'define_subst'. In such case the copy is deleted. 31261 31262 'define_subst' can be used only in 'define_insn' and 'define_expand', 31263it cannot be used in other expressions (e.g. in 31264'define_insn_and_split'). 31265 31266* Menu: 31267 31268* Define Subst Example:: Example of 'define_subst' work. 31269* Define Subst Pattern Matching:: Process of template comparison. 31270* Define Subst Output Template:: Generation of output template. 31271 31272 31273File: gccint.info, Node: Define Subst Example, Next: Define Subst Pattern Matching, Up: Define Subst 31274 3127517.21.1 'define_subst' Example 31276------------------------------ 31277 31278To illustrate how 'define_subst' works, let us examine a simple template 31279transformation. 31280 31281 Suppose there are two kinds of instructions: one that touches flags and 31282the other that does not. The instructions of the second type could be 31283generated with the following 'define_subst': 31284 31285 (define_subst "add_clobber_subst" 31286 [(set (match_operand:SI 0 "" "") 31287 (match_operand:SI 1 "" ""))] 31288 "" 31289 [(set (match_dup 0) 31290 (match_dup 1)) 31291 (clobber (reg:CC FLAGS_REG))]) 31292 31293 This 'define_subst' can be applied to any RTL pattern containing 'set' 31294of mode SI and generates a copy with clobber when it is applied. 31295 31296 Assume there is an RTL template for a 'max' instruction to be used in 31297'define_subst' mentioned above: 31298 31299 (define_insn "maxsi" 31300 [(set (match_operand:SI 0 "register_operand" "=r") 31301 (max:SI 31302 (match_operand:SI 1 "register_operand" "r") 31303 (match_operand:SI 2 "register_operand" "r")))] 31304 "" 31305 "max\t{%2, %1, %0|%0, %1, %2}" 31306 [...]) 31307 31308 To mark the RTL template for 'define_subst' application, 31309subst-attributes are used. They should be declared in advance: 31310 31311 (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber") 31312 31313 Here 'add_clobber_name' is the attribute name, 'add_clobber_subst' is 31314the name of the corresponding 'define_subst', the third argument 31315('_noclobber') is the attribute value that would be substituted into the 31316unchanged version of the source RTL template, and the last argument 31317('_clobber') is the value that would be substituted into the second, 31318transformed, version of the RTL template. 31319 31320 Once the subst-attribute has been defined, it should be used in RTL 31321templates which need to be processed by the 'define_subst'. So, the 31322original RTL template should be changed: 31323 31324 (define_insn "maxsi<add_clobber_name>" 31325 [(set (match_operand:SI 0 "register_operand" "=r") 31326 (max:SI 31327 (match_operand:SI 1 "register_operand" "r") 31328 (match_operand:SI 2 "register_operand" "r")))] 31329 "" 31330 "max\t{%2, %1, %0|%0, %1, %2}" 31331 [...]) 31332 31333 The result of the 'define_subst' usage would look like the following: 31334 31335 (define_insn "maxsi_noclobber" 31336 [(set (match_operand:SI 0 "register_operand" "=r") 31337 (max:SI 31338 (match_operand:SI 1 "register_operand" "r") 31339 (match_operand:SI 2 "register_operand" "r")))] 31340 "" 31341 "max\t{%2, %1, %0|%0, %1, %2}" 31342 [...]) 31343 (define_insn "maxsi_clobber" 31344 [(set (match_operand:SI 0 "register_operand" "=r") 31345 (max:SI 31346 (match_operand:SI 1 "register_operand" "r") 31347 (match_operand:SI 2 "register_operand" "r"))) 31348 (clobber (reg:CC FLAGS_REG))] 31349 "" 31350 "max\t{%2, %1, %0|%0, %1, %2}" 31351 [...]) 31352 31353 31354File: gccint.info, Node: Define Subst Pattern Matching, Next: Define Subst Output Template, Prev: Define Subst Example, Up: Define Subst 31355 3135617.21.2 Pattern Matching in 'define_subst' 31357------------------------------------------ 31358 31359All expressions, allowed in 'define_insn' or 'define_expand', are 31360allowed in the input-template of 'define_subst', except 'match_par_dup', 31361'match_scratch', 'match_parallel'. The meanings of expressions in the 31362input-template were changed: 31363 31364 'match_operand' matches any expression (possibly, a subtree in 31365RTL-template), if modes of the 'match_operand' and this expression are 31366the same, or mode of the 'match_operand' is 'VOIDmode', or this 31367expression is 'match_dup', 'match_op_dup'. If the expression is 31368'match_operand' too, and predicate of 'match_operand' from the input 31369pattern is not empty, then the predicates are compared. That can be 31370used for more accurate filtering of accepted RTL-templates. 31371 31372 'match_operator' matches common operators (like 'plus', 'minus'), 31373'unspec', 'unspec_volatile' operators and 'match_operator's from the 31374original pattern if the modes match and 'match_operator' from the input 31375pattern has the same number of operands as the operator from the 31376original pattern. 31377 31378 31379File: gccint.info, Node: Define Subst Output Template, Prev: Define Subst Pattern Matching, Up: Define Subst 31380 3138117.21.3 Generation of output template in 'define_subst' 31382------------------------------------------------------- 31383 31384If all necessary checks for 'define_subst' application pass, a new 31385RTL-pattern, based on the output-template, is created to replace the old 31386template. Like in input-patterns, meanings of some RTL expressions are 31387changed when they are used in output-patterns of a 'define_subst'. 31388Thus, 'match_dup' is used for copying the whole expression from the 31389original pattern, which matched corresponding 'match_operand' from the 31390input pattern. 31391 31392 'match_dup N' is used in the output template to be replaced with the 31393expression from the original pattern, which matched 'match_operand N' 31394from the input pattern. As a consequence, 'match_dup' cannot be used to 31395point to 'match_operand's from the output pattern, it should always 31396refer to a 'match_operand' from the input pattern. If a 'match_dup N' 31397occurs more than once in the output template, its first occurrence is 31398replaced with the expression from the original pattern, and the 31399subsequent expressions are replaced with 'match_dup N', i.e., a 31400reference to the first expression. 31401 31402 In the output template one can refer to the expressions from the 31403original pattern and create new ones. For instance, some operands could 31404be added by means of standard 'match_operand'. 31405 31406 After replacing 'match_dup' with some RTL-subtree from the original 31407pattern, it could happen that several 'match_operand's in the output 31408pattern have the same indexes. It is unknown, how many and what indexes 31409would be used in the expression which would replace 'match_dup', so such 31410conflicts in indexes are inevitable. To overcome this issue, 31411'match_operands' and 'match_operators', which were introduced into the 31412output pattern, are renumerated when all 'match_dup's are replaced. 31413 31414 Number of alternatives in 'match_operand's introduced into the output 31415template 'M' could differ from the number of alternatives in the 31416original pattern 'N', so in the resultant pattern there would be 'N*M' 31417alternatives. Thus, constraints from the original pattern would be 31418duplicated 'N' times, constraints from the output pattern would be 31419duplicated 'M' times, producing all possible combinations. 31420 31421 31422File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Define Subst, Up: Machine Desc 31423 3142417.22 Constant Definitions 31425========================== 31426 31427Using literal constants inside instruction patterns reduces legibility 31428and can be a maintenance problem. 31429 31430 To overcome this problem, you may use the 'define_constants' 31431expression. It contains a vector of name-value pairs. From that point 31432on, wherever any of the names appears in the MD file, it is as if the 31433corresponding value had been written instead. You may use 31434'define_constants' multiple times; each appearance adds more constants 31435to the table. It is an error to redefine a constant with a different 31436value. 31437 31438 To come back to the a29k load multiple example, instead of 31439 31440 (define_insn "" 31441 [(match_parallel 0 "load_multiple_operation" 31442 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 31443 (match_operand:SI 2 "memory_operand" "m")) 31444 (use (reg:SI 179)) 31445 (clobber (reg:SI 179))])] 31446 "" 31447 "loadm 0,0,%1,%2") 31448 31449 You could write: 31450 31451 (define_constants [ 31452 (R_BP 177) 31453 (R_FC 178) 31454 (R_CR 179) 31455 (R_Q 180) 31456 ]) 31457 31458 (define_insn "" 31459 [(match_parallel 0 "load_multiple_operation" 31460 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 31461 (match_operand:SI 2 "memory_operand" "m")) 31462 (use (reg:SI R_CR)) 31463 (clobber (reg:SI R_CR))])] 31464 "" 31465 "loadm 0,0,%1,%2") 31466 31467 The constants that are defined with a define_constant are also output 31468in the insn-codes.h header file as #defines. 31469 31470 You can also use the machine description file to define enumerations. 31471Like the constants defined by 'define_constant', these enumerations are 31472visible to both the machine description file and the main C code. 31473 31474 The syntax is as follows: 31475 31476 (define_c_enum "NAME" [ 31477 VALUE0 31478 VALUE1 31479 ... 31480 VALUEN 31481 ]) 31482 31483 This definition causes the equivalent of the following C code to appear 31484in 'insn-constants.h': 31485 31486 enum NAME { 31487 VALUE0 = 0, 31488 VALUE1 = 1, 31489 ... 31490 VALUEN = N 31491 }; 31492 #define NUM_CNAME_VALUES (N + 1) 31493 31494 where CNAME is the capitalized form of NAME. It also makes each VALUEI 31495available in the machine description file, just as if it had been 31496declared with: 31497 31498 (define_constants [(VALUEI I)]) 31499 31500 Each VALUEI is usually an upper-case identifier and usually begins with 31501CNAME. 31502 31503 You can split the enumeration definition into as many statements as you 31504like. The above example is directly equivalent to: 31505 31506 (define_c_enum "NAME" [VALUE0]) 31507 (define_c_enum "NAME" [VALUE1]) 31508 ... 31509 (define_c_enum "NAME" [VALUEN]) 31510 31511 Splitting the enumeration helps to improve the modularity of each 31512individual '.md' file. For example, if a port defines its 31513synchronization instructions in a separate 'sync.md' file, it is 31514convenient to define all synchronization-specific enumeration values in 31515'sync.md' rather than in the main '.md' file. 31516 31517 Some enumeration names have special significance to GCC: 31518 31519'unspecv' 31520 If an enumeration called 'unspecv' is defined, GCC will use it when 31521 printing out 'unspec_volatile' expressions. For example: 31522 31523 (define_c_enum "unspecv" [ 31524 UNSPECV_BLOCKAGE 31525 ]) 31526 31527 causes GCC to print '(unspec_volatile ... 0)' as: 31528 31529 (unspec_volatile ... UNSPECV_BLOCKAGE) 31530 31531'unspec' 31532 If an enumeration called 'unspec' is defined, GCC will use it when 31533 printing out 'unspec' expressions. GCC will also use it when 31534 printing out 'unspec_volatile' expressions unless an 'unspecv' 31535 enumeration is also defined. You can therefore decide whether to 31536 keep separate enumerations for volatile and non-volatile 31537 expressions or whether to use the same enumeration for both. 31538 31539 Another way of defining an enumeration is to use 'define_enum': 31540 31541 (define_enum "NAME" [ 31542 VALUE0 31543 VALUE1 31544 ... 31545 VALUEN 31546 ]) 31547 31548 This directive implies: 31549 31550 (define_c_enum "NAME" [ 31551 CNAME_CVALUE0 31552 CNAME_CVALUE1 31553 ... 31554 CNAME_CVALUEN 31555 ]) 31556 31557 where CVALUEI is the capitalized form of VALUEI. However, unlike 31558'define_c_enum', the enumerations defined by 'define_enum' can be used 31559in attribute specifications (*note define_enum_attr::). 31560 31561 31562File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc 31563 3156417.23 Iterators 31565=============== 31566 31567Ports often need to define similar patterns for more than one machine 31568mode or for more than one rtx code. GCC provides some simple iterator 31569facilities to make this process easier. 31570 31571* Menu: 31572 31573* Mode Iterators:: Generating variations of patterns for different modes. 31574* Code Iterators:: Doing the same for codes. 31575* Int Iterators:: Doing the same for integers. 31576* Subst Iterators:: Generating variations of patterns for define_subst. 31577* Parameterized Names:: Specifying iterator values in C++ code. 31578 31579 31580File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators 31581 3158217.23.1 Mode Iterators 31583---------------------- 31584 31585Ports often need to define similar patterns for two or more different 31586modes. For example: 31587 31588 * If a processor has hardware support for both single and double 31589 floating-point arithmetic, the 'SFmode' patterns tend to be very 31590 similar to the 'DFmode' ones. 31591 31592 * If a port uses 'SImode' pointers in one configuration and 'DImode' 31593 pointers in another, it will usually have very similar 'SImode' and 31594 'DImode' patterns for manipulating pointers. 31595 31596 Mode iterators allow several patterns to be instantiated from one '.md' 31597file template. They can be used with any type of rtx-based construct, 31598such as a 'define_insn', 'define_split', or 'define_peephole2'. 31599 31600* Menu: 31601 31602* Defining Mode Iterators:: Defining a new mode iterator. 31603* Substitutions:: Combining mode iterators with substitutions 31604* Examples:: Examples 31605 31606 31607File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators 31608 3160917.23.1.1 Defining Mode Iterators 31610................................. 31611 31612The syntax for defining a mode iterator is: 31613 31614 (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 31615 31616 This allows subsequent '.md' file constructs to use the mode suffix 31617':NAME'. Every construct that does so will be expanded N times, once 31618with every use of ':NAME' replaced by ':MODE1', once with every use 31619replaced by ':MODE2', and so on. In the expansion for a particular 31620MODEI, every C condition will also require that CONDI be true. 31621 31622 For example: 31623 31624 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 31625 31626 defines a new mode suffix ':P'. Every construct that uses ':P' will be 31627expanded twice, once with every ':P' replaced by ':SI' and once with 31628every ':P' replaced by ':DI'. The ':SI' version will only apply if 31629'Pmode == SImode' and the ':DI' version will only apply if 'Pmode == 31630DImode'. 31631 31632 As with other '.md' conditions, an empty string is treated as "always 31633true". '(MODE "")' can also be abbreviated to 'MODE'. For example: 31634 31635 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 31636 31637 means that the ':DI' expansion only applies if 'TARGET_64BIT' but that 31638the ':SI' expansion has no such constraint. 31639 31640 Iterators are applied in the order they are defined. This can be 31641significant if two iterators are used in a construct that requires 31642substitutions. *Note Substitutions::. 31643 31644 31645File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators 31646 3164717.23.1.2 Substitution in Mode Iterators 31648........................................ 31649 31650If an '.md' file construct uses mode iterators, each version of the 31651construct will often need slightly different strings or modes. For 31652example: 31653 31654 * When a 'define_expand' defines several 'addM3' patterns (*note 31655 Standard Names::), each expander will need to use the appropriate 31656 mode name for M. 31657 31658 * When a 'define_insn' defines several instruction patterns, each 31659 instruction will often use a different assembler mnemonic. 31660 31661 * When a 'define_insn' requires operands with different modes, using 31662 an iterator for one of the operand modes usually requires a 31663 specific mode for the other operand(s). 31664 31665 GCC supports such variations through a system of "mode attributes". 31666There are two standard attributes: 'mode', which is the name of the mode 31667in lower case, and 'MODE', which is the same thing in upper case. You 31668can define other attributes using: 31669 31670 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 31671 31672 where NAME is the name of the attribute and VALUEI is the value 31673associated with MODEI. 31674 31675 When GCC replaces some :ITERATOR with :MODE, it will scan each string 31676and mode in the pattern for sequences of the form '<ITERATOR:ATTR>', 31677where ATTR is the name of a mode attribute. If the attribute is defined 31678for MODE, the whole '<...>' sequence will be replaced by the appropriate 31679attribute value. 31680 31681 For example, suppose an '.md' file has: 31682 31683 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 31684 (define_mode_attr load [(SI "lw") (DI "ld")]) 31685 31686 If one of the patterns that uses ':P' contains the string 31687'"<P:load>\t%0,%1"', the 'SI' version of that pattern will use 31688'"lw\t%0,%1"' and the 'DI' version will use '"ld\t%0,%1"'. 31689 31690 Here is an example of using an attribute for a mode: 31691 31692 (define_mode_iterator LONG [SI DI]) 31693 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 31694 (define_insn ... 31695 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 31696 31697 The 'ITERATOR:' prefix may be omitted, in which case the substitution 31698will be attempted for every iterator expansion. 31699 31700 31701File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators 31702 3170317.23.1.3 Mode Iterator Examples 31704................................ 31705 31706Here is an example from the MIPS port. It defines the following modes 31707and attributes (among others): 31708 31709 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 31710 (define_mode_attr d [(SI "") (DI "d")]) 31711 31712 and uses the following template to define both 'subsi3' and 'subdi3': 31713 31714 (define_insn "sub<mode>3" 31715 [(set (match_operand:GPR 0 "register_operand" "=d") 31716 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 31717 (match_operand:GPR 2 "register_operand" "d")))] 31718 "" 31719 "<d>subu\t%0,%1,%2" 31720 [(set_attr "type" "arith") 31721 (set_attr "mode" "<MODE>")]) 31722 31723 This is exactly equivalent to: 31724 31725 (define_insn "subsi3" 31726 [(set (match_operand:SI 0 "register_operand" "=d") 31727 (minus:SI (match_operand:SI 1 "register_operand" "d") 31728 (match_operand:SI 2 "register_operand" "d")))] 31729 "" 31730 "subu\t%0,%1,%2" 31731 [(set_attr "type" "arith") 31732 (set_attr "mode" "SI")]) 31733 31734 (define_insn "subdi3" 31735 [(set (match_operand:DI 0 "register_operand" "=d") 31736 (minus:DI (match_operand:DI 1 "register_operand" "d") 31737 (match_operand:DI 2 "register_operand" "d")))] 31738 "" 31739 "dsubu\t%0,%1,%2" 31740 [(set_attr "type" "arith") 31741 (set_attr "mode" "DI")]) 31742 31743 31744File: gccint.info, Node: Code Iterators, Next: Int Iterators, Prev: Mode Iterators, Up: Iterators 31745 3174617.23.2 Code Iterators 31747---------------------- 31748 31749Code iterators operate in a similar way to mode iterators. *Note Mode 31750Iterators::. 31751 31752 The construct: 31753 31754 (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 31755 31756 defines a pseudo rtx code NAME that can be instantiated as CODEI if 31757condition CONDI is true. Each CODEI must have the same rtx format. 31758*Note RTL Classes::. 31759 31760 As with mode iterators, each pattern that uses NAME will be expanded N 31761times, once with all uses of NAME replaced by CODE1, once with all uses 31762replaced by CODE2, and so on. *Note Defining Mode Iterators::. 31763 31764 It is possible to define attributes for codes as well as for modes. 31765There are two standard code attributes: 'code', the name of the code in 31766lower case, and 'CODE', the name of the code in upper case. Other 31767attributes are defined using: 31768 31769 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 31770 31771 Instruction patterns can use code attributes as rtx codes, which can be 31772useful if two sets of codes act in tandem. For example, the following 31773'define_insn' defines two patterns, one calculating a signed absolute 31774difference and another calculating an unsigned absolute difference: 31775 31776 (define_code_iterator any_max [smax umax]) 31777 (define_code_attr paired_min [(smax "smin") (umax "umin")]) 31778 (define_insn ... 31779 [(set (match_operand:SI 0 ...) 31780 (minus:SI (any_max:SI (match_operand:SI 1 ...) 31781 (match_operand:SI 2 ...)) 31782 (<paired_min>:SI (match_dup 1) (match_dup 2))))] 31783 ...) 31784 31785 The signed version of the instruction uses 'smax' and 'smin' while the 31786unsigned version uses 'umax' and 'umin'. There are no versions that 31787pair 'smax' with 'umin' or 'umax' with 'smin'. 31788 31789 Here's an example of code iterators in action, taken from the MIPS 31790port: 31791 31792 (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt 31793 eq ne gt ge lt le gtu geu ltu leu]) 31794 31795 (define_expand "b<code>" 31796 [(set (pc) 31797 (if_then_else (any_cond:CC (cc0) 31798 (const_int 0)) 31799 (label_ref (match_operand 0 "")) 31800 (pc)))] 31801 "" 31802 { 31803 gen_conditional_branch (operands, <CODE>); 31804 DONE; 31805 }) 31806 31807 This is equivalent to: 31808 31809 (define_expand "bunordered" 31810 [(set (pc) 31811 (if_then_else (unordered:CC (cc0) 31812 (const_int 0)) 31813 (label_ref (match_operand 0 "")) 31814 (pc)))] 31815 "" 31816 { 31817 gen_conditional_branch (operands, UNORDERED); 31818 DONE; 31819 }) 31820 31821 (define_expand "bordered" 31822 [(set (pc) 31823 (if_then_else (ordered:CC (cc0) 31824 (const_int 0)) 31825 (label_ref (match_operand 0 "")) 31826 (pc)))] 31827 "" 31828 { 31829 gen_conditional_branch (operands, ORDERED); 31830 DONE; 31831 }) 31832 31833 ... 31834 31835 31836File: gccint.info, Node: Int Iterators, Next: Subst Iterators, Prev: Code Iterators, Up: Iterators 31837 3183817.23.3 Int Iterators 31839--------------------- 31840 31841Int iterators operate in a similar way to code iterators. *Note Code 31842Iterators::. 31843 31844 The construct: 31845 31846 (define_int_iterator NAME [(INT1 "COND1") ... (INTN "CONDN")]) 31847 31848 defines a pseudo integer constant NAME that can be instantiated as INTI 31849if condition CONDI is true. Each INT must have the same rtx format. 31850*Note RTL Classes::. Int iterators can appear in only those rtx fields 31851that have 'i', 'n', 'w', or 'p' as the specifier. This means that each 31852INT has to be a constant defined using define_constant or define_c_enum. 31853 31854 As with mode and code iterators, each pattern that uses NAME will be 31855expanded N times, once with all uses of NAME replaced by INT1, once with 31856all uses replaced by INT2, and so on. *Note Defining Mode Iterators::. 31857 31858 It is possible to define attributes for ints as well as for codes and 31859modes. Attributes are defined using: 31860 31861 (define_int_attr NAME [(INT1 "VALUE1") ... (INTN "VALUEN")]) 31862 31863 Here's an example of int iterators in action, taken from the ARM port: 31864 31865 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 31866 31867 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 31868 31869 (define_insn "neon_vq<absneg><mode>" 31870 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 31871 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 31872 (match_operand:SI 2 "immediate_operand" "i")] 31873 QABSNEG))] 31874 "TARGET_NEON" 31875 "vq<absneg>.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 31876 [(set_attr "type" "neon_vqneg_vqabs")] 31877 ) 31878 31879 31880 This is equivalent to: 31881 31882 (define_insn "neon_vqabs<mode>" 31883 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 31884 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 31885 (match_operand:SI 2 "immediate_operand" "i")] 31886 UNSPEC_VQABS))] 31887 "TARGET_NEON" 31888 "vqabs.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 31889 [(set_attr "type" "neon_vqneg_vqabs")] 31890 ) 31891 31892 (define_insn "neon_vqneg<mode>" 31893 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 31894 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 31895 (match_operand:SI 2 "immediate_operand" "i")] 31896 UNSPEC_VQNEG))] 31897 "TARGET_NEON" 31898 "vqneg.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 31899 [(set_attr "type" "neon_vqneg_vqabs")] 31900 ) 31901 31902 31903 31904File: gccint.info, Node: Subst Iterators, Next: Parameterized Names, Prev: Int Iterators, Up: Iterators 31905 3190617.23.4 Subst Iterators 31907----------------------- 31908 31909Subst iterators are special type of iterators with the following 31910restrictions: they could not be declared explicitly, they always have 31911only two values, and they do not have explicit dedicated name. 31912Subst-iterators are triggered only when corresponding subst-attribute is 31913used in RTL-pattern. 31914 31915 Subst iterators transform templates in the following way: the templates 31916are duplicated, the subst-attributes in these templates are replaced 31917with the corresponding values, and a new attribute is implicitly added 31918to the given 'define_insn'/'define_expand'. The name of the added 31919attribute matches the name of 'define_subst'. Such attributes are 31920declared implicitly, and it is not allowed to have a 'define_attr' named 31921as a 'define_subst'. 31922 31923 Each subst iterator is linked to a 'define_subst'. It is declared 31924implicitly by the first appearance of the corresponding 31925'define_subst_attr', and it is not allowed to define it explicitly. 31926 31927 Declarations of subst-attributes have the following syntax: 31928 31929 (define_subst_attr "NAME" 31930 "SUBST-NAME" 31931 "NO-SUBST-VALUE" 31932 "SUBST-APPLIED-VALUE") 31933 31934 NAME is a string with which the given subst-attribute could be referred 31935to. 31936 31937 SUBST-NAME shows which 'define_subst' should be applied to an 31938RTL-template if the given subst-attribute is present in the 31939RTL-template. 31940 31941 NO-SUBST-VALUE is a value with which subst-attribute would be replaced 31942in the first copy of the original RTL-template. 31943 31944 SUBST-APPLIED-VALUE is a value with which subst-attribute would be 31945replaced in the second copy of the original RTL-template. 31946 31947 31948File: gccint.info, Node: Parameterized Names, Prev: Subst Iterators, Up: Iterators 31949 3195017.23.5 Parameterized Names 31951--------------------------- 31952 31953Ports sometimes need to apply iterators using C++ code, in order to get 31954the code or RTL pattern for a specific instruction. For example, 31955suppose we have the 'neon_vq<absneg><mode>' pattern given above: 31956 31957 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 31958 31959 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 31960 31961 (define_insn "neon_vq<absneg><mode>" 31962 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 31963 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 31964 (match_operand:SI 2 "immediate_operand" "i")] 31965 QABSNEG))] 31966 ... 31967 ) 31968 31969 A port might need to generate this pattern for a variable 'QABSNEG' 31970value and a variable 'VDQIW' mode. There are two ways of doing this. 31971The first is to build the rtx for the pattern directly from C++ code; 31972this is a valid technique and avoids any risk of combinatorial 31973explosion. The second is to prefix the instruction name with the 31974special character '@', which tells GCC to generate the four additional 31975functions below. In each case, NAME is the name of the instruction 31976without the leading '@' character, without the '<...>' placeholders, and 31977with any underscore before a '<...>' placeholder removed if keeping it 31978would lead to a double or trailing underscore. 31979 31980'insn_code maybe_code_for_NAME (I1, I2, ...)' 31981 See whether replacing the first '<...>' placeholder with iterator 31982 value I1, the second with iterator value I2, and so on, gives a 31983 valid instruction. Return its code if so, otherwise return 31984 'CODE_FOR_nothing'. 31985 31986'insn_code code_for_NAME (I1, I2, ...)' 31987 Same, but abort the compiler if the requested instruction does not 31988 exist. 31989 31990'rtx maybe_gen_NAME (I1, I2, ..., OP0, OP1, ...)' 31991 Check for a valid instruction in the same way as 31992 'maybe_code_for_NAME'. If the instruction exists, generate an 31993 instance of it using the operand values given by OP0, OP1, and so 31994 on, otherwise return null. 31995 31996'rtx gen_NAME (I1, I2, ..., OP0, OP1, ...)' 31997 Same, but abort the compiler if the requested instruction does not 31998 exist, or if the instruction generator invoked the 'FAIL' macro. 31999 32000 For example, changing the pattern above to: 32001 32002 (define_insn "@neon_vq<absneg><mode>" 32003 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 32004 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 32005 (match_operand:SI 2 "immediate_operand" "i")] 32006 QABSNEG))] 32007 ... 32008 ) 32009 32010 would define the same patterns as before, but in addition would 32011generate the four functions below: 32012 32013 insn_code maybe_code_for_neon_vq (int, machine_mode); 32014 insn_code code_for_neon_vq (int, machine_mode); 32015 rtx maybe_gen_neon_vq (int, machine_mode, rtx, rtx, rtx); 32016 rtx gen_neon_vq (int, machine_mode, rtx, rtx, rtx); 32017 32018 Calling 'code_for_neon_vq (UNSPEC_VQABS, V8QImode)' would then give 32019'CODE_FOR_neon_vqabsv8qi'. 32020 32021 It is possible to have multiple '@' patterns with the same name and 32022same types of iterator. For example: 32023 32024 (define_insn "@some_arithmetic_op<mode>" 32025 [(set (match_operand:INTEGER_MODES 0 "register_operand") ...)] 32026 ... 32027 ) 32028 32029 (define_insn "@some_arithmetic_op<mode>" 32030 [(set (match_operand:FLOAT_MODES 0 "register_operand") ...)] 32031 ... 32032 ) 32033 32034 would produce a single set of functions that handles both 32035'INTEGER_MODES' and 'FLOAT_MODES'. 32036 32037 It is also possible for these '@' patterns to have different numbers of 32038operands from each other. For example, patterns with a binary rtl code 32039might take three operands (one output and two inputs) while patterns 32040with a ternary rtl code might take four operands (one output and three 32041inputs). This combination would produce separate 'maybe_gen_NAME' and 32042'gen_NAME' functions for each operand count, but it would still produce 32043a single 'maybe_code_for_NAME' and a single 'code_for_NAME'. 32044 32045 32046File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 32047 3204818 Target Description Macros and Functions 32049****************************************** 32050 32051In addition to the file 'MACHINE.md', a machine description includes a C 32052header file conventionally given the name 'MACHINE.h' and a C source 32053file named 'MACHINE.c'. The header file defines numerous macros that 32054convey the information about the target machine that does not fit into 32055the scheme of the '.md' file. The file 'tm.h' should be a link to 32056'MACHINE.h'. The header file 'config.h' includes 'tm.h' and most 32057compiler source files include 'config.h'. The source file defines a 32058variable 'targetm', which is a structure containing pointers to 32059functions and data relating to the target machine. 'MACHINE.c' should 32060also contain their definitions, if they are not defined elsewhere in 32061GCC, and other functions called through the macros defined in the '.h' 32062file. 32063 32064* Menu: 32065 32066* Target Structure:: The 'targetm' variable. 32067* Driver:: Controlling how the driver runs the compilation passes. 32068* Run-time Target:: Defining '-m' options like '-m68000' and '-m68020'. 32069* Per-Function Data:: Defining data structures for per-function information. 32070* Storage Layout:: Defining sizes and alignments of data. 32071* Type Layout:: Defining sizes and properties of basic user data types. 32072* Registers:: Naming and describing the hardware registers. 32073* Register Classes:: Defining the classes of hardware registers. 32074* Stack and Calling:: Defining which way the stack grows and by how much. 32075* Varargs:: Defining the varargs macros. 32076* Trampolines:: Code set up at run time to enter a nested function. 32077* Library Calls:: Controlling how library routines are implicitly called. 32078* Addressing Modes:: Defining addressing modes valid for memory operands. 32079* Anchored Addresses:: Defining how '-fsection-anchors' should work. 32080* Condition Code:: Defining how insns update the condition code. 32081* Costs:: Defining relative costs of different operations. 32082* Scheduling:: Adjusting the behavior of the instruction scheduler. 32083* Sections:: Dividing storage into text, data, and other sections. 32084* PIC:: Macros for position independent code. 32085* Assembler Format:: Defining how to write insns and pseudo-ops to output. 32086* Debugging Info:: Defining the format of debugging output. 32087* Floating Point:: Handling floating point for cross-compilers. 32088* Mode Switching:: Insertion of mode-switching instructions. 32089* Target Attributes:: Defining target-specific uses of '__attribute__'. 32090* Emulated TLS:: Emulated TLS support. 32091* MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 32092* PCH Target:: Validity checking for precompiled headers. 32093* C++ ABI:: Controlling C++ ABI changes. 32094* D Language and ABI:: Controlling D ABI changes. 32095* Named Address Spaces:: Adding support for named address spaces 32096* Misc:: Everything else. 32097 32098 32099File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 32100 3210118.1 The Global 'targetm' Variable 32102================================== 32103 32104 -- Variable: struct gcc_target targetm 32105 The target '.c' file must define the global 'targetm' variable 32106 which contains pointers to functions and data relating to the 32107 target machine. The variable is declared in 'target.h'; 32108 'target-def.h' defines the macro 'TARGET_INITIALIZER' which is used 32109 to initialize the variable, and macros for the default initializers 32110 for elements of the structure. The '.c' file should override those 32111 macros for which the default definition is inappropriate. For 32112 example: 32113 #include "target.h" 32114 #include "target-def.h" 32115 32116 /* Initialize the GCC target structure. */ 32117 32118 #undef TARGET_COMP_TYPE_ATTRIBUTES 32119 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 32120 32121 struct gcc_target targetm = TARGET_INITIALIZER; 32122 32123 Where a macro should be defined in the '.c' file in this manner to form 32124part of the 'targetm' structure, it is documented below as a "Target 32125Hook" with a prototype. Many macros will change in future from being 32126defined in the '.h' file to being part of the 'targetm' structure. 32127 32128 Similarly, there is a 'targetcm' variable for hooks that are specific 32129to front ends for C-family languages, documented as "C Target Hook". 32130This is declared in 'c-family/c-target.h', the initializer 32131'TARGETCM_INITIALIZER' in 'c-family/c-target-def.h'. If targets 32132initialize 'targetcm' themselves, they should set 32133'target_has_targetcm=yes' in 'config.gcc'; otherwise a default 32134definition is used. 32135 32136 Similarly, there is a 'targetm_common' variable for hooks that are 32137shared between the compiler driver and the compilers proper, documented 32138as "Common Target Hook". This is declared in 'common/common-target.h', 32139the initializer 'TARGETM_COMMON_INITIALIZER' in 32140'common/common-target-def.h'. If targets initialize 'targetm_common' 32141themselves, they should set 'target_has_targetm_common=yes' in 32142'config.gcc'; otherwise a default definition is used. 32143 32144 Similarly, there is a 'targetdm' variable for hooks that are specific 32145to the D language front end, documented as "D Target Hook". This is 32146declared in 'd/d-target.h', the initializer 'TARGETDM_INITIALIZER' in 32147'd/d-target-def.h'. If targets initialize 'targetdm' themselves, they 32148should set 'target_has_targetdm=yes' in 'config.gcc'; otherwise a 32149default definition is used. 32150 32151 32152File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 32153 3215418.2 Controlling the Compilation Driver, 'gcc' 32155============================================== 32156 32157You can control the compilation driver. 32158 32159 -- Macro: DRIVER_SELF_SPECS 32160 A list of specs for the driver itself. It should be a suitable 32161 initializer for an array of strings, with no surrounding braces. 32162 32163 The driver applies these specs to its own command line between 32164 loading default 'specs' files (but not command-line specified ones) 32165 and choosing the multilib directory or running any subcommands. It 32166 applies them in the order given, so each spec can depend on the 32167 options added by earlier ones. It is also possible to remove 32168 options using '%<OPTION' in the usual way. 32169 32170 This macro can be useful when a port has several interdependent 32171 target options. It provides a way of standardizing the command 32172 line so that the other specs are easier to write. 32173 32174 Do not define this macro if it does not need to do anything. 32175 32176 -- Macro: OPTION_DEFAULT_SPECS 32177 A list of specs used to support configure-time default options 32178 (i.e. '--with' options) in the driver. It should be a suitable 32179 initializer for an array of structures, each containing two 32180 strings, without the outermost pair of surrounding braces. 32181 32182 The first item in the pair is the name of the default. This must 32183 match the code in 'config.gcc' for the target. The second item is 32184 a spec to apply if a default with this name was specified. The 32185 string '%(VALUE)' in the spec will be replaced by the value of the 32186 default everywhere it occurs. 32187 32188 The driver will apply these specs to its own command line between 32189 loading default 'specs' files and processing 'DRIVER_SELF_SPECS', 32190 using the same mechanism as 'DRIVER_SELF_SPECS'. 32191 32192 Do not define this macro if it does not need to do anything. 32193 32194 -- Macro: CPP_SPEC 32195 A C string constant that tells the GCC driver program options to 32196 pass to CPP. It can also specify how to translate options you give 32197 to GCC into options for GCC to pass to the CPP. 32198 32199 Do not define this macro if it does not need to do anything. 32200 32201 -- Macro: CPLUSPLUS_CPP_SPEC 32202 This macro is just like 'CPP_SPEC', but is used for C++, rather 32203 than C. If you do not define this macro, then the value of 32204 'CPP_SPEC' (if any) will be used instead. 32205 32206 -- Macro: CC1_SPEC 32207 A C string constant that tells the GCC driver program options to 32208 pass to 'cc1', 'cc1plus', 'f771', and the other language front 32209 ends. It can also specify how to translate options you give to GCC 32210 into options for GCC to pass to front ends. 32211 32212 Do not define this macro if it does not need to do anything. 32213 32214 -- Macro: CC1PLUS_SPEC 32215 A C string constant that tells the GCC driver program options to 32216 pass to 'cc1plus'. It can also specify how to translate options 32217 you give to GCC into options for GCC to pass to the 'cc1plus'. 32218 32219 Do not define this macro if it does not need to do anything. Note 32220 that everything defined in CC1_SPEC is already passed to 'cc1plus' 32221 so there is no need to duplicate the contents of CC1_SPEC in 32222 CC1PLUS_SPEC. 32223 32224 -- Macro: ASM_SPEC 32225 A C string constant that tells the GCC driver program options to 32226 pass to the assembler. It can also specify how to translate 32227 options you give to GCC into options for GCC to pass to the 32228 assembler. See the file 'sun3.h' for an example of this. 32229 32230 Do not define this macro if it does not need to do anything. 32231 32232 -- Macro: ASM_FINAL_SPEC 32233 A C string constant that tells the GCC driver program how to run 32234 any programs which cleanup after the normal assembler. Normally, 32235 this is not needed. See the file 'mips.h' for an example of this. 32236 32237 Do not define this macro if it does not need to do anything. 32238 32239 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 32240 Define this macro, with no value, if the driver should give the 32241 assembler an argument consisting of a single dash, '-', to instruct 32242 it to read from its standard input (which will be a pipe connected 32243 to the output of the compiler proper). This argument is given 32244 after any '-o' option specifying the name of the output file. 32245 32246 If you do not define this macro, the assembler is assumed to read 32247 its standard input if given no non-option arguments. If your 32248 assembler cannot read standard input at all, use a '%{pipe:%e}' 32249 construct; see 'mips.h' for instance. 32250 32251 -- Macro: LINK_SPEC 32252 A C string constant that tells the GCC driver program options to 32253 pass to the linker. It can also specify how to translate options 32254 you give to GCC into options for GCC to pass to the linker. 32255 32256 Do not define this macro if it does not need to do anything. 32257 32258 -- Macro: LIB_SPEC 32259 Another C string constant used much like 'LINK_SPEC'. The 32260 difference between the two is that 'LIB_SPEC' is used at the end of 32261 the command given to the linker. 32262 32263 If this macro is not defined, a default is provided that loads the 32264 standard C library from the usual place. See 'gcc.c'. 32265 32266 -- Macro: LIBGCC_SPEC 32267 Another C string constant that tells the GCC driver program how and 32268 when to place a reference to 'libgcc.a' into the linker command 32269 line. This constant is placed both before and after the value of 32270 'LIB_SPEC'. 32271 32272 If this macro is not defined, the GCC driver provides a default 32273 that passes the string '-lgcc' to the linker. 32274 32275 -- Macro: REAL_LIBGCC_SPEC 32276 By default, if 'ENABLE_SHARED_LIBGCC' is defined, the 'LIBGCC_SPEC' 32277 is not directly used by the driver program but is instead modified 32278 to refer to different versions of 'libgcc.a' depending on the 32279 values of the command line flags '-static', '-shared', 32280 '-static-libgcc', and '-shared-libgcc'. On targets where these 32281 modifications are inappropriate, define 'REAL_LIBGCC_SPEC' instead. 32282 'REAL_LIBGCC_SPEC' tells the driver how to place a reference to 32283 'libgcc' on the link command line, but, unlike 'LIBGCC_SPEC', it is 32284 used unmodified. 32285 32286 -- Macro: USE_LD_AS_NEEDED 32287 A macro that controls the modifications to 'LIBGCC_SPEC' mentioned 32288 in 'REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 32289 uses '--as-needed' or equivalent options and the shared 'libgcc' in 32290 place of the static exception handler library, when linking without 32291 any of '-static', '-static-libgcc', or '-shared-libgcc'. 32292 32293 -- Macro: LINK_EH_SPEC 32294 If defined, this C string constant is added to 'LINK_SPEC'. When 32295 'USE_LD_AS_NEEDED' is zero or undefined, it also affects the 32296 modifications to 'LIBGCC_SPEC' mentioned in 'REAL_LIBGCC_SPEC'. 32297 32298 -- Macro: STARTFILE_SPEC 32299 Another C string constant used much like 'LINK_SPEC'. The 32300 difference between the two is that 'STARTFILE_SPEC' is used at the 32301 very beginning of the command given to the linker. 32302 32303 If this macro is not defined, a default is provided that loads the 32304 standard C startup file from the usual place. See 'gcc.c'. 32305 32306 -- Macro: ENDFILE_SPEC 32307 Another C string constant used much like 'LINK_SPEC'. The 32308 difference between the two is that 'ENDFILE_SPEC' is used at the 32309 very end of the command given to the linker. 32310 32311 Do not define this macro if it does not need to do anything. 32312 32313 -- Macro: THREAD_MODEL_SPEC 32314 GCC '-v' will print the thread model GCC was configured to use. 32315 However, this doesn't work on platforms that are multilibbed on 32316 thread models, such as AIX 4.3. On such platforms, define 32317 'THREAD_MODEL_SPEC' such that it evaluates to a string without 32318 blanks that names one of the recognized thread models. '%*', the 32319 default value of this macro, will expand to the value of 32320 'thread_file' set in 'config.gcc'. 32321 32322 -- Macro: SYSROOT_SUFFIX_SPEC 32323 Define this macro to add a suffix to the target sysroot when GCC is 32324 configured with a sysroot. This will cause GCC to search for 32325 usr/lib, et al, within sysroot+suffix. 32326 32327 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 32328 Define this macro to add a headers_suffix to the target sysroot 32329 when GCC is configured with a sysroot. This will cause GCC to pass 32330 the updated sysroot+headers_suffix to CPP, causing it to search for 32331 usr/include, et al, within sysroot+headers_suffix. 32332 32333 -- Macro: EXTRA_SPECS 32334 Define this macro to provide additional specifications to put in 32335 the 'specs' file that can be used in various specifications like 32336 'CC1_SPEC'. 32337 32338 The definition should be an initializer for an array of structures, 32339 containing a string constant, that defines the specification name, 32340 and a string constant that provides the specification. 32341 32342 Do not define this macro if it does not need to do anything. 32343 32344 'EXTRA_SPECS' is useful when an architecture contains several 32345 related targets, which have various '..._SPECS' which are similar 32346 to each other, and the maintainer would like one central place to 32347 keep these definitions. 32348 32349 For example, the PowerPC System V.4 targets use 'EXTRA_SPECS' to 32350 define either '_CALL_SYSV' when the System V calling sequence is 32351 used or '_CALL_AIX' when the older AIX-based calling sequence is 32352 used. 32353 32354 The 'config/rs6000/rs6000.h' target file defines: 32355 32356 #define EXTRA_SPECS \ 32357 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 32358 32359 #define CPP_SYS_DEFAULT "" 32360 32361 The 'config/rs6000/sysv.h' target file defines: 32362 #undef CPP_SPEC 32363 #define CPP_SPEC \ 32364 "%{posix: -D_POSIX_SOURCE } \ 32365 %{mcall-sysv: -D_CALL_SYSV } \ 32366 %{!mcall-sysv: %(cpp_sysv_default) } \ 32367 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 32368 32369 #undef CPP_SYSV_DEFAULT 32370 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 32371 32372 while the 'config/rs6000/eabiaix.h' target file defines 32373 'CPP_SYSV_DEFAULT' as: 32374 32375 #undef CPP_SYSV_DEFAULT 32376 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 32377 32378 -- Macro: LINK_LIBGCC_SPECIAL_1 32379 Define this macro if the driver program should find the library 32380 'libgcc.a'. If you do not define this macro, the driver program 32381 will pass the argument '-lgcc' to tell the linker to do the search. 32382 32383 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 32384 The sequence in which libgcc and libc are specified to the linker. 32385 By default this is '%G %L %G'. 32386 32387 -- Macro: POST_LINK_SPEC 32388 Define this macro to add additional steps to be executed after 32389 linker. The default value of this macro is empty string. 32390 32391 -- Macro: LINK_COMMAND_SPEC 32392 A C string constant giving the complete command line need to 32393 execute the linker. When you do this, you will need to update your 32394 port each time a change is made to the link command line within 32395 'gcc.c'. Therefore, define this macro only if you need to 32396 completely redefine the command line for invoking the linker and 32397 there is no other way to accomplish the effect you need. 32398 Overriding this macro may be avoidable by overriding 32399 'LINK_GCC_C_SEQUENCE_SPEC' instead. 32400 32401 -- Common Target Hook: bool TARGET_ALWAYS_STRIP_DOTDOT 32402 True if '..' components should always be removed from directory 32403 names computed relative to GCC's internal directories, false 32404 (default) if such components should be preserved and directory 32405 names containing them passed to other tools such as the linker. 32406 32407 -- Macro: MULTILIB_DEFAULTS 32408 Define this macro as a C expression for the initializer of an array 32409 of string to tell the driver program which options are defaults for 32410 this target and thus do not need to be handled specially when using 32411 'MULTILIB_OPTIONS'. 32412 32413 Do not define this macro if 'MULTILIB_OPTIONS' is not defined in 32414 the target makefile fragment or if none of the options listed in 32415 'MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 32416 32417 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 32418 Define this macro to tell 'gcc' that it should only translate a 32419 '-B' prefix into a '-L' linker option if the prefix indicates an 32420 absolute file name. 32421 32422 -- Macro: MD_EXEC_PREFIX 32423 If defined, this macro is an additional prefix to try after 32424 'STANDARD_EXEC_PREFIX'. 'MD_EXEC_PREFIX' is not searched when the 32425 compiler is built as a cross compiler. If you define 32426 'MD_EXEC_PREFIX', then be sure to add it to the list of directories 32427 used to find the assembler in 'configure.ac'. 32428 32429 -- Macro: STANDARD_STARTFILE_PREFIX 32430 Define this macro as a C string constant if you wish to override 32431 the standard choice of 'libdir' as the default prefix to try when 32432 searching for startup files such as 'crt0.o'. 32433 'STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 32434 built as a cross compiler. 32435 32436 -- Macro: STANDARD_STARTFILE_PREFIX_1 32437 Define this macro as a C string constant if you wish to override 32438 the standard choice of '/lib' as a prefix to try after the default 32439 prefix when searching for startup files such as 'crt0.o'. 32440 'STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 32441 built as a cross compiler. 32442 32443 -- Macro: STANDARD_STARTFILE_PREFIX_2 32444 Define this macro as a C string constant if you wish to override 32445 the standard choice of '/lib' as yet another prefix to try after 32446 the default prefix when searching for startup files such as 32447 'crt0.o'. 'STANDARD_STARTFILE_PREFIX_2' is not searched when the 32448 compiler is built as a cross compiler. 32449 32450 -- Macro: MD_STARTFILE_PREFIX 32451 If defined, this macro supplies an additional prefix to try after 32452 the standard prefixes. 'MD_EXEC_PREFIX' is not searched when the 32453 compiler is built as a cross compiler. 32454 32455 -- Macro: MD_STARTFILE_PREFIX_1 32456 If defined, this macro supplies yet another prefix to try after the 32457 standard prefixes. It is not searched when the compiler is built 32458 as a cross compiler. 32459 32460 -- Macro: INIT_ENVIRONMENT 32461 Define this macro as a C string constant if you wish to set 32462 environment variables for programs called by the driver, such as 32463 the assembler and loader. The driver passes the value of this 32464 macro to 'putenv' to initialize the necessary environment 32465 variables. 32466 32467 -- Macro: LOCAL_INCLUDE_DIR 32468 Define this macro as a C string constant if you wish to override 32469 the standard choice of '/usr/local/include' as the default prefix 32470 to try when searching for local header files. 'LOCAL_INCLUDE_DIR' 32471 comes before 'NATIVE_SYSTEM_HEADER_DIR' (set in 'config.gcc', 32472 normally '/usr/include') in the search order. 32473 32474 Cross compilers do not search either '/usr/local/include' or its 32475 replacement. 32476 32477 -- Macro: NATIVE_SYSTEM_HEADER_COMPONENT 32478 The "component" corresponding to 'NATIVE_SYSTEM_HEADER_DIR'. See 32479 'INCLUDE_DEFAULTS', below, for the description of components. If 32480 you do not define this macro, no component is used. 32481 32482 -- Macro: INCLUDE_DEFAULTS 32483 Define this macro if you wish to override the entire default search 32484 path for include files. For a native compiler, the default search 32485 path usually consists of 'GCC_INCLUDE_DIR', 'LOCAL_INCLUDE_DIR', 32486 'GPLUSPLUS_INCLUDE_DIR', and 'NATIVE_SYSTEM_HEADER_DIR'. In 32487 addition, 'GPLUSPLUS_INCLUDE_DIR' and 'GCC_INCLUDE_DIR' are defined 32488 automatically by 'Makefile', and specify private search areas for 32489 GCC. The directory 'GPLUSPLUS_INCLUDE_DIR' is used only for C++ 32490 programs. 32491 32492 The definition should be an initializer for an array of structures. 32493 Each array element should have four elements: the directory name (a 32494 string constant), the component name (also a string constant), a 32495 flag for C++-only directories, and a flag showing that the includes 32496 in the directory don't need to be wrapped in 'extern 'C'' when 32497 compiling C++. Mark the end of the array with a null element. 32498 32499 The component name denotes what GNU package the include file is 32500 part of, if any, in all uppercase letters. For example, it might 32501 be 'GCC' or 'BINUTILS'. If the package is part of a 32502 vendor-supplied operating system, code the component name as '0'. 32503 32504 For example, here is the definition used for VAX/VMS: 32505 32506 #define INCLUDE_DEFAULTS \ 32507 { \ 32508 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 32509 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 32510 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 32511 { ".", 0, 0, 0}, \ 32512 { 0, 0, 0, 0} \ 32513 } 32514 32515 Here is the order of prefixes tried for exec files: 32516 32517 1. Any prefixes specified by the user with '-B'. 32518 32519 2. The environment variable 'GCC_EXEC_PREFIX' or, if 'GCC_EXEC_PREFIX' 32520 is not set and the compiler has not been installed in the 32521 configure-time PREFIX, the location in which the compiler has 32522 actually been installed. 32523 32524 3. The directories specified by the environment variable 32525 'COMPILER_PATH'. 32526 32527 4. The macro 'STANDARD_EXEC_PREFIX', if the compiler has been 32528 installed in the configured-time PREFIX. 32529 32530 5. The location '/usr/libexec/gcc/', but only if this is a native 32531 compiler. 32532 32533 6. The location '/usr/lib/gcc/', but only if this is a native 32534 compiler. 32535 32536 7. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 32537 native compiler. 32538 32539 Here is the order of prefixes tried for startfiles: 32540 32541 1. Any prefixes specified by the user with '-B'. 32542 32543 2. The environment variable 'GCC_EXEC_PREFIX' or its automatically 32544 determined value based on the installed toolchain location. 32545 32546 3. The directories specified by the environment variable 32547 'LIBRARY_PATH' (or port-specific name; native only, cross compilers 32548 do not use this). 32549 32550 4. The macro 'STANDARD_EXEC_PREFIX', but only if the toolchain is 32551 installed in the configured PREFIX or this is a native compiler. 32552 32553 5. The location '/usr/lib/gcc/', but only if this is a native 32554 compiler. 32555 32556 6. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 32557 native compiler. 32558 32559 7. The macro 'MD_STARTFILE_PREFIX', if defined, but only if this is a 32560 native compiler, or we have a target system root. 32561 32562 8. The macro 'MD_STARTFILE_PREFIX_1', if defined, but only if this is 32563 a native compiler, or we have a target system root. 32564 32565 9. The macro 'STANDARD_STARTFILE_PREFIX', with any sysroot 32566 modifications. If this path is relative it will be prefixed by 32567 'GCC_EXEC_PREFIX' and the machine suffix or 'STANDARD_EXEC_PREFIX' 32568 and the machine suffix. 32569 32570 10. The macro 'STANDARD_STARTFILE_PREFIX_1', but only if this is a 32571 native compiler, or we have a target system root. The default for 32572 this macro is '/lib/'. 32573 32574 11. The macro 'STANDARD_STARTFILE_PREFIX_2', but only if this is a 32575 native compiler, or we have a target system root. The default for 32576 this macro is '/usr/lib/'. 32577 32578 32579File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 32580 3258118.3 Run-time Target Specification 32582================================== 32583 32584Here are run-time target specifications. 32585 32586 -- Macro: TARGET_CPU_CPP_BUILTINS () 32587 This function-like macro expands to a block of code that defines 32588 built-in preprocessor macros and assertions for the target CPU, 32589 using the functions 'builtin_define', 'builtin_define_std' and 32590 'builtin_assert'. When the front end calls this macro it provides 32591 a trailing semicolon, and since it has finished command line option 32592 processing your code can use those results freely. 32593 32594 'builtin_assert' takes a string in the form you pass to the 32595 command-line option '-A', such as 'cpu=mips', and creates the 32596 assertion. 'builtin_define' takes a string in the form accepted by 32597 option '-D' and unconditionally defines the macro. 32598 32599 'builtin_define_std' takes a string representing the name of an 32600 object-like macro. If it doesn't lie in the user's namespace, 32601 'builtin_define_std' defines it unconditionally. Otherwise, it 32602 defines a version with two leading underscores, and another version 32603 with two leading and trailing underscores, and defines the original 32604 only if an ISO standard was not requested on the command line. For 32605 example, passing 'unix' defines '__unix', '__unix__' and possibly 32606 'unix'; passing '_mips' defines '__mips', '__mips__' and possibly 32607 '_mips', and passing '_ABI64' defines only '_ABI64'. 32608 32609 You can also test for the C dialect being compiled. The variable 32610 'c_language' is set to one of 'clk_c', 'clk_cplusplus' or 32611 'clk_objective_c'. Note that if we are preprocessing assembler, 32612 this variable will be 'clk_c' but the function-like macro 32613 'preprocessing_asm_p()' will return true, so you might want to 32614 check for that first. If you need to check for strict ANSI, the 32615 variable 'flag_iso' can be used. The function-like macro 32616 'preprocessing_trad_p()' can be used to check for traditional 32617 preprocessing. 32618 32619 -- Macro: TARGET_OS_CPP_BUILTINS () 32620 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 32621 and is used for the target operating system instead. 32622 32623 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 32624 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 32625 and is used for the target object format. 'elfos.h' uses this 32626 macro to define '__ELF__', so you probably do not need to define it 32627 yourself. 32628 32629 -- Variable: extern int target_flags 32630 This variable is declared in 'options.h', which is included before 32631 any target-specific headers. 32632 32633 -- Common Target Hook: int TARGET_DEFAULT_TARGET_FLAGS 32634 This variable specifies the initial value of 'target_flags'. Its 32635 default setting is 0. 32636 32637 -- Common Target Hook: bool TARGET_HANDLE_OPTION (struct gcc_options 32638 *OPTS, struct gcc_options *OPTS_SET, const struct 32639 cl_decoded_option *DECODED, location_t LOC) 32640 This hook is called whenever the user specifies one of the 32641 target-specific options described by the '.opt' definition files 32642 (*note Options::). It has the opportunity to do some 32643 option-specific processing and should return true if the option is 32644 valid. The default definition does nothing but return true. 32645 32646 DECODED specifies the option and its arguments. OPTS and OPTS_SET 32647 are the 'gcc_options' structures to be used for storing option 32648 state, and LOC is the location at which the option was passed 32649 ('UNKNOWN_LOCATION' except for options passed via attributes). 32650 32651 -- C Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char 32652 *ARG, int VALUE) 32653 This target hook is called whenever the user specifies one of the 32654 target-specific C language family options described by the '.opt' 32655 definition files(*note Options::). It has the opportunity to do 32656 some option-specific processing and should return true if the 32657 option is valid. The arguments are like for 32658 'TARGET_HANDLE_OPTION'. The default definition does nothing but 32659 return false. 32660 32661 In general, you should use 'TARGET_HANDLE_OPTION' to handle 32662 options. However, if processing an option requires routines that 32663 are only available in the C (and related language) front ends, then 32664 you should use 'TARGET_HANDLE_C_OPTION' instead. 32665 32666 -- C Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree 32667 STRING) 32668 Targets may provide a string object type that can be used within 32669 and between C, C++ and their respective Objective-C dialects. A 32670 string object might, for example, embed encoding and length 32671 information. These objects are considered opaque to the compiler 32672 and handled as references. An ideal implementation makes the 32673 composition of the string object match that of the Objective-C 32674 'NSString' ('NXString' for GNUStep), allowing efficient 32675 interworking between C-only and Objective-C code. If a target 32676 implements string objects then this hook should return a reference 32677 to such an object constructed from the normal 'C' string 32678 representation provided in STRING. At present, the hook is used by 32679 Objective-C only, to obtain a common-format string object when the 32680 target provides one. 32681 32682 -- C Target Hook: void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE 32683 (const char *CLASSNAME) 32684 Declare that Objective C class CLASSNAME is referenced by the 32685 current TU. 32686 32687 -- C Target Hook: void TARGET_OBJC_DECLARE_CLASS_DEFINITION (const char 32688 *CLASSNAME) 32689 Declare that Objective C class CLASSNAME is defined by the current 32690 TU. 32691 32692 -- C Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree 32693 STRINGREF) 32694 If a target implements string objects then this hook should return 32695 'true' if STRINGREF is a valid reference to such an object. 32696 32697 -- C Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree 32698 FORMAT_ARG, tree ARGS_LIST) 32699 If a target implements string objects then this hook should should 32700 provide a facility to check the function arguments in ARGS_LIST 32701 against the format specifiers in FORMAT_ARG where the type of 32702 FORMAT_ARG is one recognized as a valid string reference type. 32703 32704 -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void) 32705 This target function is similar to the hook 32706 'TARGET_OPTION_OVERRIDE' but is called when the optimize level is 32707 changed via an attribute or pragma or when it is reset at the end 32708 of the code affected by the attribute or pragma. It is not called 32709 at the beginning of compilation when 'TARGET_OPTION_OVERRIDE' is 32710 called so if you want to perform these actions then, you should 32711 have 'TARGET_OPTION_OVERRIDE' call 32712 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'. 32713 32714 -- Macro: C_COMMON_OVERRIDE_OPTIONS 32715 This is similar to the 'TARGET_OPTION_OVERRIDE' hook but is only 32716 used in the C language frontends (C, Objective-C, C++, 32717 Objective-C++) and so can be used to alter option flag variables 32718 which only exist in those frontends. 32719 32720 -- Common Target Hook: const struct default_options * 32721 TARGET_OPTION_OPTIMIZATION_TABLE 32722 Some machines may desire to change what optimizations are performed 32723 for various optimization levels. This variable, if defined, 32724 describes options to enable at particular sets of optimization 32725 levels. These options are processed once just after the 32726 optimization level is determined and before the remainder of the 32727 command options have been parsed, so may be overridden by other 32728 options passed explicitly. 32729 32730 This processing is run once at program startup and when the 32731 optimization options are changed via '#pragma GCC optimize' or by 32732 using the 'optimize' attribute. 32733 32734 -- Common Target Hook: void TARGET_OPTION_INIT_STRUCT (struct 32735 gcc_options *OPTS) 32736 Set target-dependent initial values of fields in OPTS. 32737 32738 -- Macro: SWITCHABLE_TARGET 32739 Some targets need to switch between substantially different 32740 subtargets during compilation. For example, the MIPS target has 32741 one subtarget for the traditional MIPS architecture and another for 32742 MIPS16. Source code can switch between these two subarchitectures 32743 using the 'mips16' and 'nomips16' attributes. 32744 32745 Such subtargets can differ in things like the set of available 32746 registers, the set of available instructions, the costs of various 32747 operations, and so on. GCC caches a lot of this type of 32748 information in global variables, and recomputing them for each 32749 subtarget takes a significant amount of time. The compiler 32750 therefore provides a facility for maintaining several versions of 32751 the global variables and quickly switching between them; see 32752 'target-globals.h' for details. 32753 32754 Define this macro to 1 if your target needs this facility. The 32755 default is 0. 32756 32757 -- Target Hook: bool TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P 32758 (void) 32759 Returns true if the target supports IEEE 754 floating-point 32760 exceptions and rounding modes, false otherwise. This is intended 32761 to relate to the 'float' and 'double' types, but not necessarily 32762 'long double'. By default, returns true if the 'adddf3' 32763 instruction pattern is available and false otherwise, on the 32764 assumption that hardware floating point supports exceptions and 32765 rounding modes but software floating point does not. 32766 32767 32768File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 32769 3277018.4 Defining data structures for per-function information. 32771=========================================================== 32772 32773If the target needs to store information on a per-function basis, GCC 32774provides a macro and a couple of variables to allow this. Note, just 32775using statics to store the information is a bad idea, since GCC supports 32776nested functions, so you can be halfway through encoding one function 32777when another one comes along. 32778 32779 GCC defines a data structure called 'struct function' which contains 32780all of the data specific to an individual function. This structure 32781contains a field called 'machine' whose type is 'struct machine_function 32782*', which can be used by targets to point to their own specific data. 32783 32784 If a target needs per-function specific data it should define the type 32785'struct machine_function' and also the macro 'INIT_EXPANDERS'. This 32786macro should be used to initialize the function pointer 32787'init_machine_status'. This pointer is explained below. 32788 32789 One typical use of per-function, target specific data is to create an 32790RTX to hold the register containing the function's return address. This 32791RTX can then be used to implement the '__builtin_return_address' 32792function, for level 0. 32793 32794 Note--earlier implementations of GCC used a single data area to hold 32795all of the per-function information. Thus when processing of a nested 32796function began the old per-function data had to be pushed onto a stack, 32797and when the processing was finished, it had to be popped off the stack. 32798GCC used to provide function pointers called 'save_machine_status' and 32799'restore_machine_status' to handle the saving and restoring of the 32800target specific information. Since the single data area approach is no 32801longer used, these pointers are no longer supported. 32802 32803 -- Macro: INIT_EXPANDERS 32804 Macro called to initialize any target specific information. This 32805 macro is called once per function, before generation of any RTL has 32806 begun. The intention of this macro is to allow the initialization 32807 of the function pointer 'init_machine_status'. 32808 32809 -- Variable: void (*)(struct function *) init_machine_status 32810 If this function pointer is non-'NULL' it will be called once per 32811 function, before function compilation starts, in order to allow the 32812 target to perform any target specific initialization of the 'struct 32813 function' structure. It is intended that this would be used to 32814 initialize the 'machine' of that structure. 32815 32816 'struct machine_function' structures are expected to be freed by 32817 GC. Generally, any memory that they reference must be allocated by 32818 using GC allocation, including the structure itself. 32819 32820 32821File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 32822 3282318.5 Storage Layout 32824=================== 32825 32826Note that the definitions of the macros in this table which are sizes or 32827alignments measured in bits do not need to be constant. They can be C 32828expressions that refer to static variables, such as the 'target_flags'. 32829*Note Run-time Target::. 32830 32831 -- Macro: BITS_BIG_ENDIAN 32832 Define this macro to have the value 1 if the most significant bit 32833 in a byte has the lowest number; otherwise define it to have the 32834 value zero. This means that bit-field instructions count from the 32835 most significant bit. If the machine has no bit-field 32836 instructions, then this must still be defined, but it doesn't 32837 matter which value it is defined to. This macro need not be a 32838 constant. 32839 32840 This macro does not affect the way structure fields are packed into 32841 bytes or words; that is controlled by 'BYTES_BIG_ENDIAN'. 32842 32843 -- Macro: BYTES_BIG_ENDIAN 32844 Define this macro to have the value 1 if the most significant byte 32845 in a word has the lowest number. This macro need not be a 32846 constant. 32847 32848 -- Macro: WORDS_BIG_ENDIAN 32849 Define this macro to have the value 1 if, in a multiword object, 32850 the most significant word has the lowest number. This applies to 32851 both memory locations and registers; see 'REG_WORDS_BIG_ENDIAN' if 32852 the order of words in memory is not the same as the order in 32853 registers. This macro need not be a constant. 32854 32855 -- Macro: REG_WORDS_BIG_ENDIAN 32856 On some machines, the order of words in a multiword object differs 32857 between registers in memory. In such a situation, define this 32858 macro to describe the order of words in a register. The macro 32859 'WORDS_BIG_ENDIAN' controls the order of words in memory. 32860 32861 -- Macro: FLOAT_WORDS_BIG_ENDIAN 32862 Define this macro to have the value 1 if 'DFmode', 'XFmode' or 32863 'TFmode' floating point numbers are stored in memory with the word 32864 containing the sign bit at the lowest address; otherwise define it 32865 to have the value 0. This macro need not be a constant. 32866 32867 You need not define this macro if the ordering is the same as for 32868 multi-word integers. 32869 32870 -- Macro: BITS_PER_WORD 32871 Number of bits in a word. If you do not define this macro, the 32872 default is 'BITS_PER_UNIT * UNITS_PER_WORD'. 32873 32874 -- Macro: MAX_BITS_PER_WORD 32875 Maximum number of bits in a word. If this is undefined, the 32876 default is 'BITS_PER_WORD'. Otherwise, it is the constant value 32877 that is the largest value that 'BITS_PER_WORD' can have at 32878 run-time. 32879 32880 -- Macro: UNITS_PER_WORD 32881 Number of storage units in a word; normally the size of a 32882 general-purpose register, a power of two from 1 or 8. 32883 32884 -- Macro: MIN_UNITS_PER_WORD 32885 Minimum number of units in a word. If this is undefined, the 32886 default is 'UNITS_PER_WORD'. Otherwise, it is the constant value 32887 that is the smallest value that 'UNITS_PER_WORD' can have at 32888 run-time. 32889 32890 -- Macro: POINTER_SIZE 32891 Width of a pointer, in bits. You must specify a value no wider 32892 than the width of 'Pmode'. If it is not equal to the width of 32893 'Pmode', you must define 'POINTERS_EXTEND_UNSIGNED'. If you do not 32894 specify a value the default is 'BITS_PER_WORD'. 32895 32896 -- Macro: POINTERS_EXTEND_UNSIGNED 32897 A C expression that determines how pointers should be extended from 32898 'ptr_mode' to either 'Pmode' or 'word_mode'. It is greater than 32899 zero if pointers should be zero-extended, zero if they should be 32900 sign-extended, and negative if some other sort of conversion is 32901 needed. In the last case, the extension is done by the target's 32902 'ptr_extend' instruction. 32903 32904 You need not define this macro if the 'ptr_mode', 'Pmode' and 32905 'word_mode' are all the same width. 32906 32907 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 32908 A macro to update M and UNSIGNEDP when an object whose type is TYPE 32909 and which has the specified mode and signedness is to be stored in 32910 a register. This macro is only called when TYPE is a scalar type. 32911 32912 On most RISC machines, which only have operations that operate on a 32913 full register, define this macro to set M to 'word_mode' if M is an 32914 integer mode narrower than 'BITS_PER_WORD'. In most cases, only 32915 integer modes should be widened because wider-precision 32916 floating-point operations are usually more expensive than their 32917 narrower counterparts. 32918 32919 For most machines, the macro definition does not change UNSIGNEDP. 32920 However, some machines, have instructions that preferentially 32921 handle either signed or unsigned quantities of certain modes. For 32922 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 32923 instructions sign-extend the result to 64 bits. On such machines, 32924 set UNSIGNEDP according to which kind of extension is more 32925 efficient. 32926 32927 Do not define this macro if it would never modify M. 32928 32929 -- Target Hook: enum flt_eval_method TARGET_C_EXCESS_PRECISION (enum 32930 excess_precision_type TYPE) 32931 Return a value, with the same meaning as the C99 macro 32932 'FLT_EVAL_METHOD' that describes which excess precision should be 32933 applied. TYPE is either 'EXCESS_PRECISION_TYPE_IMPLICIT', 32934 'EXCESS_PRECISION_TYPE_FAST', or 'EXCESS_PRECISION_TYPE_STANDARD'. 32935 For 'EXCESS_PRECISION_TYPE_IMPLICIT', the target should return 32936 which precision and range operations will be implictly evaluated in 32937 regardless of the excess precision explicitly added. For 32938 'EXCESS_PRECISION_TYPE_STANDARD' and 'EXCESS_PRECISION_TYPE_FAST', 32939 the target should return the explicit excess precision that should 32940 be added depending on the value set for 32941 '-fexcess-precision=[standard|fast]'. Note that unpredictable 32942 explicit excess precision does not make sense, so a target should 32943 never return 'FLT_EVAL_METHOD_UNPREDICTABLE' when TYPE is 32944 'EXCESS_PRECISION_TYPE_STANDARD' or 'EXCESS_PRECISION_TYPE_FAST'. 32945 32946 -- Target Hook: machine_mode TARGET_PROMOTE_FUNCTION_MODE (const_tree 32947 TYPE, machine_mode MODE, int *PUNSIGNEDP, const_tree FUNTYPE, 32948 int FOR_RETURN) 32949 Like 'PROMOTE_MODE', but it is applied to outgoing function 32950 arguments or function return values. The target hook should return 32951 the new mode and possibly change '*PUNSIGNEDP' if the promotion 32952 should change signedness. This function is called only for scalar 32953 _or pointer_ types. 32954 32955 FOR_RETURN allows to distinguish the promotion of arguments and 32956 return values. If it is '1', a return value is being promoted and 32957 'TARGET_FUNCTION_VALUE' must perform the same promotions done here. 32958 If it is '2', the returned mode should be that of the register in 32959 which an incoming parameter is copied, or the outgoing result is 32960 computed; then the hook should return the same mode as 32961 'promote_mode', though the signedness may be different. 32962 32963 TYPE can be NULL when promoting function arguments of libcalls. 32964 32965 The default is to not promote arguments and return values. You can 32966 also define the hook to 32967 'default_promote_function_mode_always_promote' if you would like to 32968 apply the same rules given by 'PROMOTE_MODE'. 32969 32970 -- Macro: PARM_BOUNDARY 32971 Normal alignment required for function parameters on the stack, in 32972 bits. All stack parameters receive at least this much alignment 32973 regardless of data type. On most machines, this is the same as the 32974 size of an integer. 32975 32976 -- Macro: STACK_BOUNDARY 32977 Define this macro to the minimum alignment enforced by hardware for 32978 the stack pointer on this machine. The definition is a C 32979 expression for the desired alignment (measured in bits). This 32980 value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not 32981 defined. On most machines, this should be the same as 32982 'PARM_BOUNDARY'. 32983 32984 -- Macro: PREFERRED_STACK_BOUNDARY 32985 Define this macro if you wish to preserve a certain alignment for 32986 the stack pointer, greater than what the hardware enforces. The 32987 definition is a C expression for the desired alignment (measured in 32988 bits). This macro must evaluate to a value equal to or larger than 32989 'STACK_BOUNDARY'. 32990 32991 -- Macro: INCOMING_STACK_BOUNDARY 32992 Define this macro if the incoming stack boundary may be different 32993 from 'PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a 32994 value equal to or larger than 'STACK_BOUNDARY'. 32995 32996 -- Macro: FUNCTION_BOUNDARY 32997 Alignment required for a function entry point, in bits. 32998 32999 -- Macro: BIGGEST_ALIGNMENT 33000 Biggest alignment that any data type can require on this machine, 33001 in bits. Note that this is not the biggest alignment that is 33002 supported, just the biggest alignment that, when violated, may 33003 cause a fault. 33004 33005 -- Target Hook: HOST_WIDE_INT TARGET_ABSOLUTE_BIGGEST_ALIGNMENT 33006 If defined, this target hook specifies the absolute biggest 33007 alignment that a type or variable can have on this machine, 33008 otherwise, 'BIGGEST_ALIGNMENT' is used. 33009 33010 -- Macro: MALLOC_ABI_ALIGNMENT 33011 Alignment, in bits, a C conformant malloc implementation has to 33012 provide. If not defined, the default value is 'BITS_PER_WORD'. 33013 33014 -- Macro: ATTRIBUTE_ALIGNED_VALUE 33015 Alignment used by the '__attribute__ ((aligned))' construct. If 33016 not defined, the default value is 'BIGGEST_ALIGNMENT'. 33017 33018 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 33019 If defined, the smallest alignment, in bits, that can be given to 33020 an object that can be referenced in one operation, without 33021 disturbing any nearby object. Normally, this is 'BITS_PER_UNIT', 33022 but may be larger on machines that don't have byte or half-word 33023 store operations. 33024 33025 -- Macro: BIGGEST_FIELD_ALIGNMENT 33026 Biggest alignment that any structure or union field can require on 33027 this machine, in bits. If defined, this overrides 33028 'BIGGEST_ALIGNMENT' for structure and union fields only, unless the 33029 field alignment has been set by the '__attribute__ ((aligned (N)))' 33030 construct. 33031 33032 -- Macro: ADJUST_FIELD_ALIGN (FIELD, TYPE, COMPUTED) 33033 An expression for the alignment of a structure field FIELD of type 33034 TYPE if the alignment computed in the usual way (including applying 33035 of 'BIGGEST_ALIGNMENT' and 'BIGGEST_FIELD_ALIGNMENT' to the 33036 alignment) is COMPUTED. It overrides alignment only if the field 33037 alignment has not been set by the '__attribute__ ((aligned (N)))' 33038 construct. Note that FIELD may be 'NULL_TREE' in case we just 33039 query for the minimum alignment of a field of type TYPE in 33040 structure context. 33041 33042 -- Macro: MAX_STACK_ALIGNMENT 33043 Biggest stack alignment guaranteed by the backend. Use this macro 33044 to specify the maximum alignment of a variable on stack. 33045 33046 If not defined, the default value is 'STACK_BOUNDARY'. 33047 33048 -- Macro: MAX_OFILE_ALIGNMENT 33049 Biggest alignment supported by the object file format of this 33050 machine. Use this macro to limit the alignment which can be 33051 specified using the '__attribute__ ((aligned (N)))' construct for 33052 functions and objects with static storage duration. The alignment 33053 of automatic objects may exceed the object file format maximum up 33054 to the maximum supported by GCC. If not defined, the default value 33055 is 'BIGGEST_ALIGNMENT'. 33056 33057 On systems that use ELF, the default (in 'config/elfos.h') is the 33058 largest supported 32-bit ELF section alignment representable on a 33059 32-bit host e.g. '(((uint64_t) 1 << 28) * 8)'. On 32-bit ELF the 33060 largest supported section alignment in bits is '(0x80000000 * 8)', 33061 but this is not representable on 32-bit hosts. 33062 33063 -- Target Hook: void TARGET_LOWER_LOCAL_DECL_ALIGNMENT (tree DECL) 33064 Define this hook to lower alignment of local, parm or result decl 33065 '(DECL)'. 33066 33067 -- Target Hook: HOST_WIDE_INT TARGET_STATIC_RTX_ALIGNMENT (machine_mode 33068 MODE) 33069 This hook returns the preferred alignment in bits for a 33070 statically-allocated rtx, such as a constant pool entry. MODE is 33071 the mode of the rtx. The default implementation returns 33072 'GET_MODE_ALIGNMENT (MODE)'. 33073 33074 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 33075 If defined, a C expression to compute the alignment for a variable 33076 in the static store. TYPE is the data type, and BASIC-ALIGN is the 33077 alignment that the object would ordinarily have. The value of this 33078 macro is used instead of that alignment to align the object. 33079 33080 If this macro is not defined, then BASIC-ALIGN is used. 33081 33082 One use of this macro is to increase alignment of medium-size data 33083 to make it all fit in fewer cache lines. Another is to cause 33084 character arrays to be word-aligned so that 'strcpy' calls that 33085 copy constants to character arrays can be done inline. 33086 33087 -- Macro: DATA_ABI_ALIGNMENT (TYPE, BASIC-ALIGN) 33088 Similar to 'DATA_ALIGNMENT', but for the cases where the ABI 33089 mandates some alignment increase, instead of optimization only 33090 purposes. E.g. AMD x86-64 psABI says that variables with array 33091 type larger than 15 bytes must be aligned to 16 byte boundaries. 33092 33093 If this macro is not defined, then BASIC-ALIGN is used. 33094 33095 -- Target Hook: HOST_WIDE_INT TARGET_CONSTANT_ALIGNMENT (const_tree 33096 CONSTANT, HOST_WIDE_INT BASIC_ALIGN) 33097 This hook returns the alignment in bits of a constant that is being 33098 placed in memory. CONSTANT is the constant and BASIC_ALIGN is the 33099 alignment that the object would ordinarily have. 33100 33101 The default definition just returns BASIC_ALIGN. 33102 33103 The typical use of this hook is to increase alignment for string 33104 constants to be word aligned so that 'strcpy' calls that copy 33105 constants can be done inline. The function 33106 'constant_alignment_word_strings' provides such a definition. 33107 33108 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 33109 If defined, a C expression to compute the alignment for a variable 33110 in the local store. TYPE is the data type, and BASIC-ALIGN is the 33111 alignment that the object would ordinarily have. The value of this 33112 macro is used instead of that alignment to align the object. 33113 33114 If this macro is not defined, then BASIC-ALIGN is used. 33115 33116 One use of this macro is to increase alignment of medium-size data 33117 to make it all fit in fewer cache lines. 33118 33119 If the value of this macro has a type, it should be an unsigned 33120 type. 33121 33122 -- Target Hook: HOST_WIDE_INT TARGET_VECTOR_ALIGNMENT (const_tree TYPE) 33123 This hook can be used to define the alignment for a vector of type 33124 TYPE, in order to comply with a platform ABI. The default is to 33125 require natural alignment for vector types. The alignment returned 33126 by this hook must be a power-of-two multiple of the default 33127 alignment of the vector element type. 33128 33129 -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN) 33130 If defined, a C expression to compute the alignment for stack slot. 33131 TYPE is the data type, MODE is the widest mode available, and 33132 BASIC-ALIGN is the alignment that the slot would ordinarily have. 33133 The value of this macro is used instead of that alignment to align 33134 the slot. 33135 33136 If this macro is not defined, then BASIC-ALIGN is used when TYPE is 33137 'NULL'. Otherwise, 'LOCAL_ALIGNMENT' will be used. 33138 33139 This macro is to set alignment of stack slot to the maximum 33140 alignment of all possible modes which the slot may have. 33141 33142 If the value of this macro has a type, it should be an unsigned 33143 type. 33144 33145 -- Macro: LOCAL_DECL_ALIGNMENT (DECL) 33146 If defined, a C expression to compute the alignment for a local 33147 variable DECL. 33148 33149 If this macro is not defined, then 'LOCAL_ALIGNMENT (TREE_TYPE 33150 (DECL), DECL_ALIGN (DECL))' is used. 33151 33152 One use of this macro is to increase alignment of medium-size data 33153 to make it all fit in fewer cache lines. 33154 33155 If the value of this macro has a type, it should be an unsigned 33156 type. 33157 33158 -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN) 33159 If defined, a C expression to compute the minimum required 33160 alignment for dynamic stack realignment purposes for EXP (a type or 33161 decl), MODE, assuming normal alignment ALIGN. 33162 33163 If this macro is not defined, then ALIGN will be used. 33164 33165 -- Macro: EMPTY_FIELD_BOUNDARY 33166 Alignment in bits to be given to a structure bit-field that follows 33167 an empty field such as 'int : 0;'. 33168 33169 If 'PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 33170 33171 -- Macro: STRUCTURE_SIZE_BOUNDARY 33172 Number of bits which any structure or union's size must be a 33173 multiple of. Each structure or union's size is rounded up to a 33174 multiple of this. 33175 33176 If you do not define this macro, the default is the same as 33177 'BITS_PER_UNIT'. 33178 33179 -- Macro: STRICT_ALIGNMENT 33180 Define this macro to be the value 1 if instructions will fail to 33181 work if given data not on the nominal alignment. If instructions 33182 will merely go slower in that case, define this macro as 0. 33183 33184 -- Macro: PCC_BITFIELD_TYPE_MATTERS 33185 Define this if you wish to imitate the way many other C compilers 33186 handle alignment of bit-fields and the structures that contain 33187 them. 33188 33189 The behavior is that the type written for a named bit-field ('int', 33190 'short', or other integer type) imposes an alignment for the entire 33191 structure, as if the structure really did contain an ordinary field 33192 of that type. In addition, the bit-field is placed within the 33193 structure so that it would fit within such a field, not crossing a 33194 boundary for it. 33195 33196 Thus, on most machines, a named bit-field whose type is written as 33197 'int' would not cross a four-byte boundary, and would force 33198 four-byte alignment for the whole structure. (The alignment used 33199 may not be four bytes; it is controlled by the other alignment 33200 parameters.) 33201 33202 An unnamed bit-field will not affect the alignment of the 33203 containing structure. 33204 33205 If the macro is defined, its definition should be a C expression; a 33206 nonzero value for the expression enables this behavior. 33207 33208 Note that if this macro is not defined, or its value is zero, some 33209 bit-fields may cross more than one alignment boundary. The 33210 compiler can support such references if there are 'insv', 'extv', 33211 and 'extzv' insns that can directly reference memory. 33212 33213 The other known way of making bit-fields work is to define 33214 'STRUCTURE_SIZE_BOUNDARY' as large as 'BIGGEST_ALIGNMENT'. Then 33215 every structure can be accessed with fullwords. 33216 33217 Unless the machine has bit-field instructions or you define 33218 'STRUCTURE_SIZE_BOUNDARY' that way, you must define 33219 'PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 33220 33221 If your aim is to make GCC use the same conventions for laying out 33222 bit-fields as are used by another compiler, here is how to 33223 investigate what the other compiler does. Compile and run this 33224 program: 33225 33226 struct foo1 33227 { 33228 char x; 33229 char :0; 33230 char y; 33231 }; 33232 33233 struct foo2 33234 { 33235 char x; 33236 int :0; 33237 char y; 33238 }; 33239 33240 main () 33241 { 33242 printf ("Size of foo1 is %d\n", 33243 sizeof (struct foo1)); 33244 printf ("Size of foo2 is %d\n", 33245 sizeof (struct foo2)); 33246 exit (0); 33247 } 33248 33249 If this prints 2 and 5, then the compiler's behavior is what you 33250 would get from 'PCC_BITFIELD_TYPE_MATTERS'. 33251 33252 -- Macro: BITFIELD_NBYTES_LIMITED 33253 Like 'PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 33254 to aligning a bit-field within the structure. 33255 33256 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void) 33257 When 'PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 33258 whether unnamed bitfields affect the alignment of the containing 33259 structure. The hook should return true if the structure should 33260 inherit the alignment requirements of an unnamed bitfield's type. 33261 33262 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void) 33263 This target hook should return 'true' if accesses to volatile 33264 bitfields should use the narrowest mode possible. It should return 33265 'false' if these accesses should use the bitfield container type. 33266 33267 The default is 'false'. 33268 33269 -- Target Hook: bool TARGET_MEMBER_TYPE_FORCES_BLK (const_tree FIELD, 33270 machine_mode MODE) 33271 Return true if a structure, union or array containing FIELD should 33272 be accessed using 'BLKMODE'. 33273 33274 If FIELD is the only field in the structure, MODE is its mode, 33275 otherwise MODE is VOIDmode. MODE is provided in the case where 33276 structures of one field would require the structure's mode to 33277 retain the field's mode. 33278 33279 Normally, this is not needed. 33280 33281 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 33282 Define this macro as an expression for the alignment of a type 33283 (given by TYPE as a tree node) if the alignment computed in the 33284 usual way is COMPUTED and the alignment explicitly specified was 33285 SPECIFIED. 33286 33287 The default is to use SPECIFIED if it is larger; otherwise, use the 33288 smaller of COMPUTED and 'BIGGEST_ALIGNMENT' 33289 33290 -- Macro: MAX_FIXED_MODE_SIZE 33291 An integer expression for the size in bits of the largest integer 33292 machine mode that should actually be used. All integer machine 33293 modes of this size or smaller can be used for structures and unions 33294 with the appropriate sizes. If this macro is undefined, 33295 'GET_MODE_BITSIZE (DImode)' is assumed. 33296 33297 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 33298 If defined, an expression of type 'machine_mode' that specifies the 33299 mode of the save area operand of a 'save_stack_LEVEL' named pattern 33300 (*note Standard Names::). SAVE_LEVEL is one of 'SAVE_BLOCK', 33301 'SAVE_FUNCTION', or 'SAVE_NONLOCAL' and selects which of the three 33302 named patterns is having its mode specified. 33303 33304 You need not define this macro if it always returns 'Pmode'. You 33305 would most commonly define this macro if the 'save_stack_LEVEL' 33306 patterns need to support both a 32- and a 64-bit mode. 33307 33308 -- Macro: STACK_SIZE_MODE 33309 If defined, an expression of type 'machine_mode' that specifies the 33310 mode of the size increment operand of an 'allocate_stack' named 33311 pattern (*note Standard Names::). 33312 33313 You need not define this macro if it always returns 'word_mode'. 33314 You would most commonly define this macro if the 'allocate_stack' 33315 pattern needs to support both a 32- and a 64-bit mode. 33316 33317 -- Target Hook: scalar_int_mode TARGET_LIBGCC_CMP_RETURN_MODE (void) 33318 This target hook should return the mode to be used for the return 33319 value of compare instructions expanded to libgcc calls. If not 33320 defined 'word_mode' is returned which is the right choice for a 33321 majority of targets. 33322 33323 -- Target Hook: scalar_int_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void) 33324 This target hook should return the mode to be used for the shift 33325 count operand of shift instructions expanded to libgcc calls. If 33326 not defined 'word_mode' is returned which is the right choice for a 33327 majority of targets. 33328 33329 -- Target Hook: scalar_int_mode TARGET_UNWIND_WORD_MODE (void) 33330 Return machine mode to be used for '_Unwind_Word' type. The 33331 default is to use 'word_mode'. 33332 33333 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 33334 RECORD_TYPE) 33335 This target hook returns 'true' if bit-fields in the given 33336 RECORD_TYPE are to be laid out following the rules of Microsoft 33337 Visual C/C++, namely: (i) a bit-field won't share the same storage 33338 unit with the previous bit-field if their underlying types have 33339 different sizes, and the bit-field will be aligned to the highest 33340 alignment of the underlying types of itself and of the previous 33341 bit-field; (ii) a zero-sized bit-field will affect the alignment of 33342 the whole enclosing structure, even if it is unnamed; except that 33343 (iii) a zero-sized bit-field will be disregarded unless it follows 33344 another bit-field of nonzero size. If this hook returns 'true', 33345 other macros that control bit-field layout are ignored. 33346 33347 When a bit-field is inserted into a packed record, the whole size 33348 of the underlying type is used by one or more same-size adjacent 33349 bit-fields (that is, if its long:3, 32 bits is used in the record, 33350 and any additional adjacent long bit-fields are packed into the 33351 same chunk of 32 bits. However, if the size changes, a new field 33352 of that size is allocated). In an unpacked record, this is the 33353 same as using alignment, but not equivalent when packing. 33354 33355 If both MS bit-fields and '__attribute__((packed))' are used, the 33356 latter will take precedence. If '__attribute__((packed))' is used 33357 on a single field when MS bit-fields are in use, it will take 33358 precedence for that field, but the alignment of the rest of the 33359 structure may affect its placement. 33360 33361 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 33362 Returns true if the target supports decimal floating point. 33363 33364 -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void) 33365 Returns true if the target supports fixed-point arithmetic. 33366 33367 -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void) 33368 This hook is called just before expansion into rtl, allowing the 33369 target to perform additional initializations or analysis before the 33370 expansion. For example, the rs6000 port uses it to allocate a 33371 scratch stack slot for use in copying SDmode values between memory 33372 and floating point registers whenever the function being expanded 33373 has any SDmode usage. 33374 33375 -- Target Hook: void TARGET_INSTANTIATE_DECLS (void) 33376 This hook allows the backend to perform additional instantiations 33377 on rtl that are not actually in any insns yet, but will be later. 33378 33379 -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE) 33380 If your target defines any fundamental types, or any types your 33381 target uses should be mangled differently from the default, define 33382 this hook to return the appropriate encoding for these types as 33383 part of a C++ mangled name. The TYPE argument is the tree 33384 structure representing the type to be mangled. The hook may be 33385 applied to trees which are not target-specific fundamental types; 33386 it should return 'NULL' for all such types, as well as arguments it 33387 does not recognize. If the return value is not 'NULL', it must 33388 point to a statically-allocated string constant. 33389 33390 Target-specific fundamental types might be new fundamental types or 33391 qualified versions of ordinary fundamental types. Encode new 33392 fundamental types as 'u N NAME', where NAME is the name used for 33393 the type in source code, and N is the length of NAME in decimal. 33394 Encode qualified versions of ordinary types as 'U N NAME CODE', 33395 where NAME is the name used for the type qualifier in source code, 33396 N is the length of NAME as above, and CODE is the code used to 33397 represent the unqualified version of this type. (See 33398 'write_builtin_type' in 'cp/mangle.c' for the list of codes.) In 33399 both cases the spaces are for clarity; do not include any spaces in 33400 your string. 33401 33402 This hook is applied to types prior to typedef resolution. If the 33403 mangled name for a particular type depends only on that type's main 33404 variant, you can perform typedef resolution yourself using 33405 'TYPE_MAIN_VARIANT' before mangling. 33406 33407 The default version of this hook always returns 'NULL', which is 33408 appropriate for a target that does not define any new fundamental 33409 types. 33410 33411 33412File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 33413 3341418.6 Layout of Source Language Data Types 33415========================================= 33416 33417These macros define the sizes and other characteristics of the standard 33418basic data types used in programs being compiled. Unlike the macros in 33419the previous section, these apply to specific features of C and related 33420languages, rather than to fundamental aspects of storage layout. 33421 33422 -- Macro: INT_TYPE_SIZE 33423 A C expression for the size in bits of the type 'int' on the target 33424 machine. If you don't define this, the default is one word. 33425 33426 -- Macro: SHORT_TYPE_SIZE 33427 A C expression for the size in bits of the type 'short' on the 33428 target machine. If you don't define this, the default is half a 33429 word. (If this would be less than one storage unit, it is rounded 33430 up to one unit.) 33431 33432 -- Macro: LONG_TYPE_SIZE 33433 A C expression for the size in bits of the type 'long' on the 33434 target machine. If you don't define this, the default is one word. 33435 33436 -- Macro: ADA_LONG_TYPE_SIZE 33437 On some machines, the size used for the Ada equivalent of the type 33438 'long' by a native Ada compiler differs from that used by C. In 33439 that situation, define this macro to be a C expression to be used 33440 for the size of that type. If you don't define this, the default 33441 is the value of 'LONG_TYPE_SIZE'. 33442 33443 -- Macro: LONG_LONG_TYPE_SIZE 33444 A C expression for the size in bits of the type 'long long' on the 33445 target machine. If you don't define this, the default is two 33446 words. If you want to support GNU Ada on your machine, the value 33447 of this macro must be at least 64. 33448 33449 -- Macro: CHAR_TYPE_SIZE 33450 A C expression for the size in bits of the type 'char' on the 33451 target machine. If you don't define this, the default is 33452 'BITS_PER_UNIT'. 33453 33454 -- Macro: BOOL_TYPE_SIZE 33455 A C expression for the size in bits of the C++ type 'bool' and C99 33456 type '_Bool' on the target machine. If you don't define this, and 33457 you probably shouldn't, the default is 'CHAR_TYPE_SIZE'. 33458 33459 -- Macro: FLOAT_TYPE_SIZE 33460 A C expression for the size in bits of the type 'float' on the 33461 target machine. If you don't define this, the default is one word. 33462 33463 -- Macro: DOUBLE_TYPE_SIZE 33464 A C expression for the size in bits of the type 'double' on the 33465 target machine. If you don't define this, the default is two 33466 words. 33467 33468 -- Macro: LONG_DOUBLE_TYPE_SIZE 33469 A C expression for the size in bits of the type 'long double' on 33470 the target machine. If you don't define this, the default is two 33471 words. 33472 33473 -- Macro: SHORT_FRACT_TYPE_SIZE 33474 A C expression for the size in bits of the type 'short _Fract' on 33475 the target machine. If you don't define this, the default is 33476 'BITS_PER_UNIT'. 33477 33478 -- Macro: FRACT_TYPE_SIZE 33479 A C expression for the size in bits of the type '_Fract' on the 33480 target machine. If you don't define this, the default is 33481 'BITS_PER_UNIT * 2'. 33482 33483 -- Macro: LONG_FRACT_TYPE_SIZE 33484 A C expression for the size in bits of the type 'long _Fract' on 33485 the target machine. If you don't define this, the default is 33486 'BITS_PER_UNIT * 4'. 33487 33488 -- Macro: LONG_LONG_FRACT_TYPE_SIZE 33489 A C expression for the size in bits of the type 'long long _Fract' 33490 on the target machine. If you don't define this, the default is 33491 'BITS_PER_UNIT * 8'. 33492 33493 -- Macro: SHORT_ACCUM_TYPE_SIZE 33494 A C expression for the size in bits of the type 'short _Accum' on 33495 the target machine. If you don't define this, the default is 33496 'BITS_PER_UNIT * 2'. 33497 33498 -- Macro: ACCUM_TYPE_SIZE 33499 A C expression for the size in bits of the type '_Accum' on the 33500 target machine. If you don't define this, the default is 33501 'BITS_PER_UNIT * 4'. 33502 33503 -- Macro: LONG_ACCUM_TYPE_SIZE 33504 A C expression for the size in bits of the type 'long _Accum' on 33505 the target machine. If you don't define this, the default is 33506 'BITS_PER_UNIT * 8'. 33507 33508 -- Macro: LONG_LONG_ACCUM_TYPE_SIZE 33509 A C expression for the size in bits of the type 'long long _Accum' 33510 on the target machine. If you don't define this, the default is 33511 'BITS_PER_UNIT * 16'. 33512 33513 -- Macro: LIBGCC2_GNU_PREFIX 33514 This macro corresponds to the 'TARGET_LIBFUNC_GNU_PREFIX' target 33515 hook and should be defined if that hook is overriden to be true. 33516 It causes function names in libgcc to be changed to use a '__gnu_' 33517 prefix for their name rather than the default '__'. A port which 33518 uses this macro should also arrange to use 't-gnu-prefix' in the 33519 libgcc 'config.host'. 33520 33521 -- Macro: WIDEST_HARDWARE_FP_SIZE 33522 A C expression for the size in bits of the widest floating-point 33523 format supported by the hardware. If you define this macro, you 33524 must specify a value less than or equal to the value of 33525 'LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 33526 value of 'LONG_DOUBLE_TYPE_SIZE' is the default. 33527 33528 -- Macro: DEFAULT_SIGNED_CHAR 33529 An expression whose value is 1 or 0, according to whether the type 33530 'char' should be signed or unsigned by default. The user can 33531 always override this default with the options '-fsigned-char' and 33532 '-funsigned-char'. 33533 33534 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 33535 This target hook should return true if the compiler should give an 33536 'enum' type only as many bytes as it takes to represent the range 33537 of possible values of that type. It should return false if all 33538 'enum' types should be allocated like 'int'. 33539 33540 The default is to return false. 33541 33542 -- Macro: SIZE_TYPE 33543 A C expression for a string describing the name of the data type to 33544 use for size values. The typedef name 'size_t' is defined using 33545 the contents of the string. 33546 33547 The string can contain more than one keyword. If so, separate them 33548 with spaces, and write first any length keyword, then 'unsigned' if 33549 appropriate, and finally 'int'. The string must exactly match one 33550 of the data type names defined in the function 33551 'c_common_nodes_and_builtins' in the file 'c-family/c-common.c'. 33552 You may not omit 'int' or change the order--that would cause the 33553 compiler to crash on startup. 33554 33555 If you don't define this macro, the default is '"long unsigned 33556 int"'. 33557 33558 -- Macro: SIZETYPE 33559 GCC defines internal types ('sizetype', 'ssizetype', 'bitsizetype' 33560 and 'sbitsizetype') for expressions dealing with size. This macro 33561 is a C expression for a string describing the name of the data type 33562 from which the precision of 'sizetype' is extracted. 33563 33564 The string has the same restrictions as 'SIZE_TYPE' string. 33565 33566 If you don't define this macro, the default is 'SIZE_TYPE'. 33567 33568 -- Macro: PTRDIFF_TYPE 33569 A C expression for a string describing the name of the data type to 33570 use for the result of subtracting two pointers. The typedef name 33571 'ptrdiff_t' is defined using the contents of the string. See 33572 'SIZE_TYPE' above for more information. 33573 33574 If you don't define this macro, the default is '"long int"'. 33575 33576 -- Macro: WCHAR_TYPE 33577 A C expression for a string describing the name of the data type to 33578 use for wide characters. The typedef name 'wchar_t' is defined 33579 using the contents of the string. See 'SIZE_TYPE' above for more 33580 information. 33581 33582 If you don't define this macro, the default is '"int"'. 33583 33584 -- Macro: WCHAR_TYPE_SIZE 33585 A C expression for the size in bits of the data type for wide 33586 characters. This is used in 'cpp', which cannot make use of 33587 'WCHAR_TYPE'. 33588 33589 -- Macro: WINT_TYPE 33590 A C expression for a string describing the name of the data type to 33591 use for wide characters passed to 'printf' and returned from 33592 'getwc'. The typedef name 'wint_t' is defined using the contents 33593 of the string. See 'SIZE_TYPE' above for more information. 33594 33595 If you don't define this macro, the default is '"unsigned int"'. 33596 33597 -- Macro: INTMAX_TYPE 33598 A C expression for a string describing the name of the data type 33599 that can represent any value of any standard or extended signed 33600 integer type. The typedef name 'intmax_t' is defined using the 33601 contents of the string. See 'SIZE_TYPE' above for more 33602 information. 33603 33604 If you don't define this macro, the default is the first of 33605 '"int"', '"long int"', or '"long long int"' that has as much 33606 precision as 'long long int'. 33607 33608 -- Macro: UINTMAX_TYPE 33609 A C expression for a string describing the name of the data type 33610 that can represent any value of any standard or extended unsigned 33611 integer type. The typedef name 'uintmax_t' is defined using the 33612 contents of the string. See 'SIZE_TYPE' above for more 33613 information. 33614 33615 If you don't define this macro, the default is the first of 33616 '"unsigned int"', '"long unsigned int"', or '"long long unsigned 33617 int"' that has as much precision as 'long long unsigned int'. 33618 33619 -- Macro: SIG_ATOMIC_TYPE 33620 -- Macro: INT8_TYPE 33621 -- Macro: INT16_TYPE 33622 -- Macro: INT32_TYPE 33623 -- Macro: INT64_TYPE 33624 -- Macro: UINT8_TYPE 33625 -- Macro: UINT16_TYPE 33626 -- Macro: UINT32_TYPE 33627 -- Macro: UINT64_TYPE 33628 -- Macro: INT_LEAST8_TYPE 33629 -- Macro: INT_LEAST16_TYPE 33630 -- Macro: INT_LEAST32_TYPE 33631 -- Macro: INT_LEAST64_TYPE 33632 -- Macro: UINT_LEAST8_TYPE 33633 -- Macro: UINT_LEAST16_TYPE 33634 -- Macro: UINT_LEAST32_TYPE 33635 -- Macro: UINT_LEAST64_TYPE 33636 -- Macro: INT_FAST8_TYPE 33637 -- Macro: INT_FAST16_TYPE 33638 -- Macro: INT_FAST32_TYPE 33639 -- Macro: INT_FAST64_TYPE 33640 -- Macro: UINT_FAST8_TYPE 33641 -- Macro: UINT_FAST16_TYPE 33642 -- Macro: UINT_FAST32_TYPE 33643 -- Macro: UINT_FAST64_TYPE 33644 -- Macro: INTPTR_TYPE 33645 -- Macro: UINTPTR_TYPE 33646 C expressions for the standard types 'sig_atomic_t', 'int8_t', 33647 'int16_t', 'int32_t', 'int64_t', 'uint8_t', 'uint16_t', 'uint32_t', 33648 'uint64_t', 'int_least8_t', 'int_least16_t', 'int_least32_t', 33649 'int_least64_t', 'uint_least8_t', 'uint_least16_t', 33650 'uint_least32_t', 'uint_least64_t', 'int_fast8_t', 'int_fast16_t', 33651 'int_fast32_t', 'int_fast64_t', 'uint_fast8_t', 'uint_fast16_t', 33652 'uint_fast32_t', 'uint_fast64_t', 'intptr_t', and 'uintptr_t'. See 33653 'SIZE_TYPE' above for more information. 33654 33655 If any of these macros evaluates to a null pointer, the 33656 corresponding type is not supported; if GCC is configured to 33657 provide '<stdint.h>' in such a case, the header provided may not 33658 conform to C99, depending on the type in question. The defaults 33659 for all of these macros are null pointers. 33660 33661 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 33662 The C++ compiler represents a pointer-to-member-function with a 33663 struct that looks like: 33664 33665 struct { 33666 union { 33667 void (*fn)(); 33668 ptrdiff_t vtable_index; 33669 }; 33670 ptrdiff_t delta; 33671 }; 33672 33673 The C++ compiler must use one bit to indicate whether the function 33674 that will be called through a pointer-to-member-function is 33675 virtual. Normally, we assume that the low-order bit of a function 33676 pointer must always be zero. Then, by ensuring that the 33677 vtable_index is odd, we can distinguish which variant of the union 33678 is in use. But, on some platforms function pointers can be odd, 33679 and so this doesn't work. In that case, we use the low-order bit 33680 of the 'delta' field, and shift the remainder of the 'delta' field 33681 to the left. 33682 33683 GCC will automatically make the right selection about where to 33684 store this bit using the 'FUNCTION_BOUNDARY' setting for your 33685 platform. However, some platforms such as ARM/Thumb have 33686 'FUNCTION_BOUNDARY' set such that functions always start at even 33687 addresses, but the lowest bit of pointers to functions indicate 33688 whether the function at that address is in ARM or Thumb mode. If 33689 this is the case of your architecture, you should define this macro 33690 to 'ptrmemfunc_vbit_in_delta'. 33691 33692 In general, you should not have to define this macro. On 33693 architectures in which function addresses are always even, 33694 according to 'FUNCTION_BOUNDARY', GCC will automatically define 33695 this macro to 'ptrmemfunc_vbit_in_pfn'. 33696 33697 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 33698 Normally, the C++ compiler uses function pointers in vtables. This 33699 macro allows the target to change to use "function descriptors" 33700 instead. Function descriptors are found on targets for whom a 33701 function pointer is actually a small data structure. Normally the 33702 data structure consists of the actual code address plus a data 33703 pointer to which the function's data is relative. 33704 33705 If vtables are used, the value of this macro should be the number 33706 of words that the function descriptor occupies. 33707 33708 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 33709 By default, the vtable entries are void pointers, the so the 33710 alignment is the same as pointer alignment. The value of this 33711 macro specifies the alignment of the vtable entry in bits. It 33712 should be defined only when special alignment is necessary. */ 33713 33714 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 33715 There are a few non-descriptor entries in the vtable at offsets 33716 below zero. If these entries must be padded (say, to preserve the 33717 alignment specified by 'TARGET_VTABLE_ENTRY_ALIGN'), set this to 33718 the number of words in each data entry. 33719 33720 33721File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 33722 3372318.7 Register Usage 33724=================== 33725 33726This section explains how to describe what registers the target machine 33727has, and how (in general) they can be used. 33728 33729 The description of which registers a specific instruction can use is 33730done with register classes; see *note Register Classes::. For 33731information on using registers to access a stack frame, see *note Frame 33732Registers::. For passing values in registers, see *note Register 33733Arguments::. For returning values in registers, see *note Scalar 33734Return::. 33735 33736* Menu: 33737 33738* Register Basics:: Number and kinds of registers. 33739* Allocation Order:: Order in which registers are allocated. 33740* Values in Registers:: What kinds of values each reg can hold. 33741* Leaf Functions:: Renumbering registers for leaf functions. 33742* Stack Registers:: Handling a register stack such as 80387. 33743 33744 33745File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 33746 3374718.7.1 Basic Characteristics of Registers 33748----------------------------------------- 33749 33750Registers have various characteristics. 33751 33752 -- Macro: FIRST_PSEUDO_REGISTER 33753 Number of hardware registers known to the compiler. They receive 33754 numbers 0 through 'FIRST_PSEUDO_REGISTER-1'; thus, the first pseudo 33755 register's number really is assigned the number 33756 'FIRST_PSEUDO_REGISTER'. 33757 33758 -- Macro: FIXED_REGISTERS 33759 An initializer that says which registers are used for fixed 33760 purposes all throughout the compiled code and are therefore not 33761 available for general allocation. These would include the stack 33762 pointer, the frame pointer (except on machines where that can be 33763 used as a general register when no frame pointer is needed), the 33764 program counter on machines where that is considered one of the 33765 addressable registers, and any other numbered register with a 33766 standard use. 33767 33768 This information is expressed as a sequence of numbers, separated 33769 by commas and surrounded by braces. The Nth number is 1 if 33770 register N is fixed, 0 otherwise. 33771 33772 The table initialized from this macro, and the table initialized by 33773 the following one, may be overridden at run time either 33774 automatically, by the actions of the macro 33775 'CONDITIONAL_REGISTER_USAGE', or by the user with the command 33776 options '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG'. 33777 33778 -- Macro: CALL_USED_REGISTERS 33779 Like 'FIXED_REGISTERS' but has 1 for each register that is 33780 clobbered (in general) by function calls as well as for fixed 33781 registers. This macro therefore identifies the registers that are 33782 not available for general allocation of values that must live 33783 across function calls. 33784 33785 If a register has 0 in 'CALL_USED_REGISTERS', the compiler 33786 automatically saves it on function entry and restores it on 33787 function exit, if the register is used within the function. 33788 33789 Exactly one of 'CALL_USED_REGISTERS' and 33790 'CALL_REALLY_USED_REGISTERS' must be defined. Modern ports should 33791 define 'CALL_REALLY_USED_REGISTERS'. 33792 33793 -- Macro: CALL_REALLY_USED_REGISTERS 33794 Like 'CALL_USED_REGISTERS' except this macro doesn't require that 33795 the entire set of 'FIXED_REGISTERS' be included. 33796 ('CALL_USED_REGISTERS' must be a superset of 'FIXED_REGISTERS'). 33797 33798 Exactly one of 'CALL_USED_REGISTERS' and 33799 'CALL_REALLY_USED_REGISTERS' must be defined. Modern ports should 33800 define 'CALL_REALLY_USED_REGISTERS'. 33801 33802 -- Target Hook: const predefined_function_abi & TARGET_FNTYPE_ABI 33803 (const_tree TYPE) 33804 Return the ABI used by a function with type TYPE; see the 33805 definition of 'predefined_function_abi' for details of the ABI 33806 descriptor. Targets only need to define this hook if they support 33807 interoperability between several ABIs in the same translation unit. 33808 33809 -- Target Hook: const predefined_function_abi & TARGET_INSN_CALLEE_ABI 33810 (const rtx_insn *INSN) 33811 This hook returns a description of the ABI used by the target of 33812 call instruction INSN; see the definition of 33813 'predefined_function_abi' for details of the ABI descriptor. Only 33814 the global function 'insn_callee_abi' should call this hook 33815 directly. 33816 33817 Targets only need to define this hook if they support 33818 interoperability between several ABIs in the same translation unit. 33819 33820 -- Target Hook: bool TARGET_HARD_REGNO_CALL_PART_CLOBBERED (unsigned 33821 int ABI_ID, unsigned int REGNO, machine_mode MODE) 33822 ABIs usually specify that calls must preserve the full contents of 33823 a particular register, or that calls can alter any part of a 33824 particular register. This information is captured by the target 33825 macro 'CALL_REALLY_USED_REGISTERS'. However, some ABIs specify 33826 that calls must preserve certain bits of a particular register but 33827 can alter others. This hook should return true if this applies to 33828 at least one of the registers in '(reg:MODE REGNO)', and if as a 33829 result the call would alter part of the MODE value. For example, 33830 if a call preserves the low 32 bits of a 64-bit hard register REGNO 33831 but can clobber the upper 32 bits, this hook should return true for 33832 a 64-bit mode but false for a 32-bit mode. 33833 33834 The value of ABI_ID comes from the 'predefined_function_abi' 33835 structure that describes the ABI of the call; see the definition of 33836 the structure for more details. If (as is usual) the target uses 33837 the same ABI for all functions in a translation unit, ABI_ID is 33838 always 0. 33839 33840 The default implementation returns false, which is correct for 33841 targets that don't have partly call-clobbered registers. 33842 33843 -- Target Hook: const char * TARGET_GET_MULTILIB_ABI_NAME (void) 33844 This hook returns name of multilib ABI name. 33845 33846 -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void) 33847 This hook may conditionally modify five variables 'fixed_regs', 33848 'call_used_regs', 'global_regs', 'reg_names', and 33849 'reg_class_contents', to take into account any dependence of these 33850 register sets on target flags. The first three of these are of 33851 type 'char []' (interpreted as boolean vectors). 'global_regs' is 33852 a 'const char *[]', and 'reg_class_contents' is a 'HARD_REG_SET'. 33853 Before the macro is called, 'fixed_regs', 'call_used_regs', 33854 'reg_class_contents', and 'reg_names' have been initialized from 33855 'FIXED_REGISTERS', 'CALL_USED_REGISTERS', 'REG_CLASS_CONTENTS', and 33856 'REGISTER_NAMES', respectively. 'global_regs' has been cleared, 33857 and any '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG' 33858 command options have been applied. 33859 33860 If the usage of an entire class of registers depends on the target 33861 flags, you may indicate this to GCC by using this macro to modify 33862 'fixed_regs' and 'call_used_regs' to 1 for each of the registers in 33863 the classes which should not be used by GCC. Also make 33864 'define_register_constraint's return 'NO_REGS' for constraints that 33865 shouldn't be used. 33866 33867 (However, if this class is not included in 'GENERAL_REGS' and all 33868 of the insn patterns whose constraints permit this class are 33869 controlled by target switches, then GCC will automatically avoid 33870 using these registers when the target switches are opposed to 33871 them.) 33872 33873 -- Macro: INCOMING_REGNO (OUT) 33874 Define this macro if the target machine has register windows. This 33875 C expression returns the register number as seen by the called 33876 function corresponding to the register number OUT as seen by the 33877 calling function. Return OUT if register number OUT is not an 33878 outbound register. 33879 33880 -- Macro: OUTGOING_REGNO (IN) 33881 Define this macro if the target machine has register windows. This 33882 C expression returns the register number as seen by the calling 33883 function corresponding to the register number IN as seen by the 33884 called function. Return IN if register number IN is not an inbound 33885 register. 33886 33887 -- Macro: LOCAL_REGNO (REGNO) 33888 Define this macro if the target machine has register windows. This 33889 C expression returns true if the register is call-saved but is in 33890 the register window. Unlike most call-saved registers, such 33891 registers need not be explicitly restored on function exit or 33892 during non-local gotos. 33893 33894 -- Macro: PC_REGNUM 33895 If the program counter has a register number, define this as that 33896 register number. Otherwise, do not define it. 33897 33898 33899File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 33900 3390118.7.2 Order of Allocation of Registers 33902--------------------------------------- 33903 33904Registers are allocated in order. 33905 33906 -- Macro: REG_ALLOC_ORDER 33907 If defined, an initializer for a vector of integers, containing the 33908 numbers of hard registers in the order in which GCC should prefer 33909 to use them (from most preferred to least). 33910 33911 If this macro is not defined, registers are used lowest numbered 33912 first (all else being equal). 33913 33914 One use of this macro is on machines where the highest numbered 33915 registers must always be saved and the save-multiple-registers 33916 instruction supports only sequences of consecutive registers. On 33917 such machines, define 'REG_ALLOC_ORDER' to be an initializer that 33918 lists the highest numbered allocable register first. 33919 33920 -- Macro: ADJUST_REG_ALLOC_ORDER 33921 A C statement (sans semicolon) to choose the order in which to 33922 allocate hard registers for pseudo-registers local to a basic 33923 block. 33924 33925 Store the desired register order in the array 'reg_alloc_order'. 33926 Element 0 should be the register to allocate first; element 1, the 33927 next register; and so on. 33928 33929 The macro body should not assume anything about the contents of 33930 'reg_alloc_order' before execution of the macro. 33931 33932 On most machines, it is not necessary to define this macro. 33933 33934 -- Macro: HONOR_REG_ALLOC_ORDER 33935 Normally, IRA tries to estimate the costs for saving a register in 33936 the prologue and restoring it in the epilogue. This discourages it 33937 from using call-saved registers. If a machine wants to ensure that 33938 IRA allocates registers in the order given by REG_ALLOC_ORDER even 33939 if some call-saved registers appear earlier than call-used ones, 33940 then define this macro as a C expression to nonzero. Default is 0. 33941 33942 -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO) 33943 In some case register allocation order is not enough for the 33944 Integrated Register Allocator (IRA) to generate a good code. If 33945 this macro is defined, it should return a floating point value 33946 based on REGNO. The cost of using REGNO for a pseudo will be 33947 increased by approximately the pseudo's usage frequency times the 33948 value returned by this macro. Not defining this macro is 33949 equivalent to having it always return '0.0'. 33950 33951 On most machines, it is not necessary to define this macro. 33952 33953 33954File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 33955 3395618.7.3 How Values Fit in Registers 33957---------------------------------- 33958 33959This section discusses the macros that describe which kinds of values 33960(specifically, which machine modes) each register can hold, and how many 33961consecutive registers are needed for a given mode. 33962 33963 -- Target Hook: unsigned int TARGET_HARD_REGNO_NREGS (unsigned int 33964 REGNO, machine_mode MODE) 33965 This hook returns the number of consecutive hard registers, 33966 starting at register number REGNO, required to hold a value of mode 33967 MODE. This hook must never return zero, even if a register cannot 33968 hold the requested mode - indicate that with 33969 'TARGET_HARD_REGNO_MODE_OK' and/or 'TARGET_CAN_CHANGE_MODE_CLASS' 33970 instead. 33971 33972 The default definition returns the number of words in MODE. 33973 33974 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 33975 A C expression that is nonzero if a value of mode MODE, stored in 33976 memory, ends with padding that causes it to take up more space than 33977 in registers starting at register number REGNO (as determined by 33978 multiplying GCC's notion of the size of the register when 33979 containing this mode by the number of registers returned by 33980 'TARGET_HARD_REGNO_NREGS'). By default this is zero. 33981 33982 For example, if a floating-point value is stored in three 32-bit 33983 registers but takes up 128 bits in memory, then this would be 33984 nonzero. 33985 33986 This macros only needs to be defined if there are cases where 33987 'subreg_get_info' would otherwise wrongly determine that a 'subreg' 33988 can be represented by an offset to the register number, when in 33989 fact such a 'subreg' would contain some of the padding not stored 33990 in registers and so not be representable. 33991 33992 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 33993 For values of REGNO and MODE for which 33994 'HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 33995 returning the greater number of registers required to hold the 33996 value including any padding. In the example above, the value would 33997 be four. 33998 33999 -- Macro: REGMODE_NATURAL_SIZE (MODE) 34000 Define this macro if the natural size of registers that hold values 34001 of mode MODE is not the word size. It is a C expression that 34002 should give the natural size in bytes for the specified mode. It 34003 is used by the register allocator to try to optimize its results. 34004 This happens for example on SPARC 64-bit where the natural size of 34005 floating-point registers is still 32-bit. 34006 34007 -- Target Hook: bool TARGET_HARD_REGNO_MODE_OK (unsigned int REGNO, 34008 machine_mode MODE) 34009 This hook returns true if it is permissible to store a value of 34010 mode MODE in hard register number REGNO (or in several registers 34011 starting with that one). The default definition returns true 34012 unconditionally. 34013 34014 You need not include code to check for the numbers of fixed 34015 registers, because the allocation mechanism considers them to be 34016 always occupied. 34017 34018 On some machines, double-precision values must be kept in even/odd 34019 register pairs. You can implement that by defining this hook to 34020 reject odd register numbers for such modes. 34021 34022 The minimum requirement for a mode to be OK in a register is that 34023 the 'movMODE' instruction pattern support moves between the 34024 register and other hard register in the same class and that moving 34025 a value into the register and back out not alter it. 34026 34027 Since the same instruction used to move 'word_mode' will work for 34028 all narrower integer modes, it is not necessary on any machine for 34029 this hook to distinguish between these modes, provided you define 34030 patterns 'movhi', etc., to take advantage of this. This is useful 34031 because of the interaction between 'TARGET_HARD_REGNO_MODE_OK' and 34032 'TARGET_MODES_TIEABLE_P'; it is very desirable for all integer 34033 modes to be tieable. 34034 34035 Many machines have special registers for floating point arithmetic. 34036 Often people assume that floating point machine modes are allowed 34037 only in floating point registers. This is not true. Any registers 34038 that can hold integers can safely _hold_ a floating point machine 34039 mode, whether or not floating arithmetic can be done on it in those 34040 registers. Integer move instructions can be used to move the 34041 values. 34042 34043 On some machines, though, the converse is true: fixed-point machine 34044 modes may not go in floating registers. This is true if the 34045 floating registers normalize any value stored in them, because 34046 storing a non-floating value there would garble it. In this case, 34047 'TARGET_HARD_REGNO_MODE_OK' should reject fixed-point machine modes 34048 in floating registers. But if the floating registers do not 34049 automatically normalize, if you can store any bit pattern in one 34050 and retrieve it unchanged without a trap, then any machine mode may 34051 go in a floating register, so you can define this hook to say so. 34052 34053 The primary significance of special floating registers is rather 34054 that they are the registers acceptable in floating point arithmetic 34055 instructions. However, this is of no concern to 34056 'TARGET_HARD_REGNO_MODE_OK'. You handle it by writing the proper 34057 constraints for those instructions. 34058 34059 On some machines, the floating registers are especially slow to 34060 access, so that it is better to store a value in a stack frame than 34061 in such a register if floating point arithmetic is not being done. 34062 As long as the floating registers are not in class 'GENERAL_REGS', 34063 they will not be used unless some pattern's constraint asks for 34064 one. 34065 34066 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 34067 A C expression that is nonzero if it is OK to rename a hard 34068 register FROM to another hard register TO. 34069 34070 One common use of this macro is to prevent renaming of a register 34071 to another register that is not saved by a prologue in an interrupt 34072 handler. 34073 34074 The default is always nonzero. 34075 34076 -- Target Hook: bool TARGET_MODES_TIEABLE_P (machine_mode MODE1, 34077 machine_mode MODE2) 34078 This hook returns true if a value of mode MODE1 is accessible in 34079 mode MODE2 without copying. 34080 34081 If 'TARGET_HARD_REGNO_MODE_OK (R, MODE1)' and 34082 'TARGET_HARD_REGNO_MODE_OK (R, MODE2)' are always the same for any 34083 R, then 'TARGET_MODES_TIEABLE_P (MODE1, MODE2)' should be true. If 34084 they differ for any R, you should define this hook to return false 34085 unless some other mechanism ensures the accessibility of the value 34086 in a narrower mode. 34087 34088 You should define this hook to return true in as many cases as 34089 possible since doing so will allow GCC to perform better register 34090 allocation. The default definition returns true unconditionally. 34091 34092 -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO) 34093 This target hook should return 'true' if it is OK to use a hard 34094 register REGNO as scratch reg in peephole2. 34095 34096 One common use of this macro is to prevent using of a register that 34097 is not saved by a prologue in an interrupt handler. 34098 34099 The default version of this hook always returns 'true'. 34100 34101 -- Macro: AVOID_CCMODE_COPIES 34102 Define this macro if the compiler should avoid copies to/from 34103 'CCmode' registers. You should only define this macro if support 34104 for copying to/from 'CCmode' is incomplete. 34105 34106 34107File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 34108 3410918.7.4 Handling Leaf Functions 34110------------------------------ 34111 34112On some machines, a leaf function (i.e., one which makes no calls) can 34113run more efficiently if it does not make its own register window. Often 34114this means it is required to receive its arguments in the registers 34115where they are passed by the caller, instead of the registers where they 34116would normally arrive. 34117 34118 The special treatment for leaf functions generally applies only when 34119other conditions are met; for example, often they may use only those 34120registers for its own variables and temporaries. We use the term "leaf 34121function" to mean a function that is suitable for this special handling, 34122so that functions with no calls are not necessarily "leaf functions". 34123 34124 GCC assigns register numbers before it knows whether the function is 34125suitable for leaf function treatment. So it needs to renumber the 34126registers in order to output a leaf function. The following macros 34127accomplish this. 34128 34129 -- Macro: LEAF_REGISTERS 34130 Name of a char vector, indexed by hard register number, which 34131 contains 1 for a register that is allowable in a candidate for leaf 34132 function treatment. 34133 34134 If leaf function treatment involves renumbering the registers, then 34135 the registers marked here should be the ones before 34136 renumbering--those that GCC would ordinarily allocate. The 34137 registers which will actually be used in the assembler code, after 34138 renumbering, should not be marked with 1 in this vector. 34139 34140 Define this macro only if the target machine offers a way to 34141 optimize the treatment of leaf functions. 34142 34143 -- Macro: LEAF_REG_REMAP (REGNO) 34144 A C expression whose value is the register number to which REGNO 34145 should be renumbered, when a function is treated as a leaf 34146 function. 34147 34148 If REGNO is a register number which should not appear in a leaf 34149 function before renumbering, then the expression should yield -1, 34150 which will cause the compiler to abort. 34151 34152 Define this macro only if the target machine offers a way to 34153 optimize the treatment of leaf functions, and registers need to be 34154 renumbered to do this. 34155 34156 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' must 34157usually treat leaf functions specially. They can test the C variable 34158'current_function_is_leaf' which is nonzero for leaf functions. 34159'current_function_is_leaf' is set prior to local register allocation and 34160is valid for the remaining compiler passes. They can also test the C 34161variable 'current_function_uses_only_leaf_regs' which is nonzero for 34162leaf functions which only use leaf registers. 34163'current_function_uses_only_leaf_regs' is valid after all passes that 34164modify the instructions have been run and is only useful if 34165'LEAF_REGISTERS' is defined. 34166 34167 34168File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 34169 3417018.7.5 Registers That Form a Stack 34171---------------------------------- 34172 34173There are special features to handle computers where some of the 34174"registers" form a stack. Stack registers are normally written by 34175pushing onto the stack, and are numbered relative to the top of the 34176stack. 34177 34178 Currently, GCC can only handle one group of stack-like registers, and 34179they must be consecutively numbered. Furthermore, the existing support 34180for stack-like registers is specific to the 80387 floating point 34181coprocessor. If you have a new architecture that uses stack-like 34182registers, you will need to do substantial work on 'reg-stack.c' and 34183write your machine description to cooperate with it, as well as defining 34184these macros. 34185 34186 -- Macro: STACK_REGS 34187 Define this if the machine has any stack-like registers. 34188 34189 -- Macro: STACK_REG_COVER_CLASS 34190 This is a cover class containing the stack registers. Define this 34191 if the machine has any stack-like registers. 34192 34193 -- Macro: FIRST_STACK_REG 34194 The number of the first stack-like register. This one is the top 34195 of the stack. 34196 34197 -- Macro: LAST_STACK_REG 34198 The number of the last stack-like register. This one is the bottom 34199 of the stack. 34200 34201 34202File: gccint.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros 34203 3420418.8 Register Classes 34205===================== 34206 34207On many machines, the numbered registers are not all equivalent. For 34208example, certain registers may not be allowed for indexed addressing; 34209certain registers may not be allowed in some instructions. These 34210machine restrictions are described to the compiler using "register 34211classes". 34212 34213 You define a number of register classes, giving each one a name and 34214saying which of the registers belong to it. Then you can specify 34215register classes that are allowed as operands to particular instruction 34216patterns. 34217 34218 In general, each register will belong to several classes. In fact, one 34219class must be named 'ALL_REGS' and contain all the registers. Another 34220class must be named 'NO_REGS' and contain no registers. Often the union 34221of two classes will be another class; however, this is not required. 34222 34223 One of the classes must be named 'GENERAL_REGS'. There is nothing 34224terribly special about the name, but the operand constraint letters 'r' 34225and 'g' specify this class. If 'GENERAL_REGS' is the same as 34226'ALL_REGS', just define it as a macro which expands to 'ALL_REGS'. 34227 34228 Order the classes so that if class X is contained in class Y then X has 34229a lower class number than Y. 34230 34231 The way classes other than 'GENERAL_REGS' are specified in operand 34232constraints is through machine-dependent operand constraint letters. 34233You can define such letters to correspond to various classes, then use 34234them in operand constraints. 34235 34236 You must define the narrowest register classes for allocatable 34237registers, so that each class either has no subclasses, or that for some 34238mode, the move cost between registers within the class is cheaper than 34239moving a register in the class to or from memory (*note Costs::). 34240 34241 You should define a class for the union of two classes whenever some 34242instruction allows both classes. For example, if an instruction allows 34243either a floating point (coprocessor) register or a general register for 34244a certain operand, you should define a class 'FLOAT_OR_GENERAL_REGS' 34245which includes both of them. Otherwise you will get suboptimal code, or 34246even internal compiler errors when reload cannot find a register in the 34247class computed via 'reg_class_subunion'. 34248 34249 You must also specify certain redundant information about the register 34250classes: for each class, which classes contain it and which ones are 34251contained in it; for each pair of classes, the largest class contained 34252in their union. 34253 34254 When a value occupying several consecutive registers is expected in a 34255certain class, all the registers used must belong to that class. 34256Therefore, register classes cannot be used to enforce a requirement for 34257a register pair to start with an even-numbered register. The way to 34258specify this requirement is with 'TARGET_HARD_REGNO_MODE_OK'. 34259 34260 Register classes used for input-operands of bitwise-and or shift 34261instructions have a special requirement: each such class must have, for 34262each fixed-point machine mode, a subclass whose registers can transfer 34263that mode to or from memory. For example, on some machines, the 34264operations for single-byte values ('QImode') are limited to certain 34265registers. When this is so, each register class that is used in a 34266bitwise-and or shift instruction must have a subclass consisting of 34267registers from which single-byte values can be loaded or stored. This 34268is so that 'PREFERRED_RELOAD_CLASS' can always have a possible value to 34269return. 34270 34271 -- Data type: enum reg_class 34272 An enumerated type that must be defined with all the register class 34273 names as enumerated values. 'NO_REGS' must be first. 'ALL_REGS' 34274 must be the last register class, followed by one more enumerated 34275 value, 'LIM_REG_CLASSES', which is not a register class but rather 34276 tells how many classes there are. 34277 34278 Each register class has a number, which is the value of casting the 34279 class name to type 'int'. The number serves as an index in many of 34280 the tables described below. 34281 34282 -- Macro: N_REG_CLASSES 34283 The number of distinct register classes, defined as follows: 34284 34285 #define N_REG_CLASSES (int) LIM_REG_CLASSES 34286 34287 -- Macro: REG_CLASS_NAMES 34288 An initializer containing the names of the register classes as C 34289 string constants. These names are used in writing some of the 34290 debugging dumps. 34291 34292 -- Macro: REG_CLASS_CONTENTS 34293 An initializer containing the contents of the register classes, as 34294 integers which are bit masks. The Nth integer specifies the 34295 contents of class N. The way the integer MASK is interpreted is 34296 that register R is in the class if 'MASK & (1 << R)' is 1. 34297 34298 When the machine has more than 32 registers, an integer does not 34299 suffice. Then the integers are replaced by sub-initializers, 34300 braced groupings containing several integers. Each sub-initializer 34301 must be suitable as an initializer for the type 'HARD_REG_SET' 34302 which is defined in 'hard-reg-set.h'. In this situation, the first 34303 integer in each sub-initializer corresponds to registers 0 through 34304 31, the second integer to registers 32 through 63, and so on. 34305 34306 -- Macro: REGNO_REG_CLASS (REGNO) 34307 A C expression whose value is a register class containing hard 34308 register REGNO. In general there is more than one such class; 34309 choose a class which is "minimal", meaning that no smaller class 34310 also contains the register. 34311 34312 -- Macro: BASE_REG_CLASS 34313 A macro whose definition is the name of the class to which a valid 34314 base register must belong. A base register is one used in an 34315 address which is the register value plus a displacement. 34316 34317 -- Macro: MODE_BASE_REG_CLASS (MODE) 34318 This is a variation of the 'BASE_REG_CLASS' macro which allows the 34319 selection of a base register in a mode dependent manner. If MODE 34320 is VOIDmode then it should return the same value as 34321 'BASE_REG_CLASS'. 34322 34323 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 34324 A C expression whose value is the register class to which a valid 34325 base register must belong in order to be used in a base plus index 34326 register address. You should define this macro if base plus index 34327 addresses have different requirements than other base register 34328 uses. 34329 34330 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, ADDRESS_SPACE, OUTER_CODE, 34331 INDEX_CODE) 34332 A C expression whose value is the register class to which a valid 34333 base register for a memory reference in mode MODE to address space 34334 ADDRESS_SPACE must belong. OUTER_CODE and INDEX_CODE define the 34335 context in which the base register occurs. OUTER_CODE is the code 34336 of the immediately enclosing expression ('MEM' for the top level of 34337 an address, 'ADDRESS' for something that occurs in an 34338 'address_operand'). INDEX_CODE is the code of the corresponding 34339 index expression if OUTER_CODE is 'PLUS'; 'SCRATCH' otherwise. 34340 34341 -- Macro: INDEX_REG_CLASS 34342 A macro whose definition is the name of the class to which a valid 34343 index register must belong. An index register is one used in an 34344 address where its value is either multiplied by a scale factor or 34345 added to another register (as well as added to a displacement). 34346 34347 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 34348 A C expression which is nonzero if register number NUM is suitable 34349 for use as a base register in operand addresses. 34350 34351 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 34352 A C expression that is just like 'REGNO_OK_FOR_BASE_P', except that 34353 that expression may examine the mode of the memory reference in 34354 MODE. You should define this macro if the mode of the memory 34355 reference affects whether a register may be used as a base 34356 register. If you define this macro, the compiler will use it 34357 instead of 'REGNO_OK_FOR_BASE_P'. The mode may be 'VOIDmode' for 34358 addresses that appear outside a 'MEM', i.e., as an 34359 'address_operand'. 34360 34361 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 34362 A C expression which is nonzero if register number NUM is suitable 34363 for use as a base register in base plus index operand addresses, 34364 accessing memory in mode MODE. It may be either a suitable hard 34365 register or a pseudo register that has been allocated such a hard 34366 register. You should define this macro if base plus index 34367 addresses have different requirements than other base register 34368 uses. 34369 34370 Use of this macro is deprecated; please use the more general 34371 'REGNO_MODE_CODE_OK_FOR_BASE_P'. 34372 34373 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE, 34374 OUTER_CODE, INDEX_CODE) 34375 A C expression which is nonzero if register number NUM is suitable 34376 for use as a base register in operand addresses, accessing memory 34377 in mode MODE in address space ADDRESS_SPACE. This is similar to 34378 'REGNO_MODE_OK_FOR_BASE_P', except that that expression may examine 34379 the context in which the register appears in the memory reference. 34380 OUTER_CODE is the code of the immediately enclosing expression 34381 ('MEM' if at the top level of the address, 'ADDRESS' for something 34382 that occurs in an 'address_operand'). INDEX_CODE is the code of 34383 the corresponding index expression if OUTER_CODE is 'PLUS'; 34384 'SCRATCH' otherwise. The mode may be 'VOIDmode' for addresses that 34385 appear outside a 'MEM', i.e., as an 'address_operand'. 34386 34387 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 34388 A C expression which is nonzero if register number NUM is suitable 34389 for use as an index register in operand addresses. It may be 34390 either a suitable hard register or a pseudo register that has been 34391 allocated such a hard register. 34392 34393 The difference between an index register and a base register is 34394 that the index register may be scaled. If an address involves the 34395 sum of two registers, neither one of them scaled, then either one 34396 may be labeled the "base" and the other the "index"; but whichever 34397 labeling is used must fit the machine's constraints of which 34398 registers may serve in each capacity. The compiler will try both 34399 labelings, looking for one that is valid, and will reload one or 34400 both registers only if neither labeling works. 34401 34402 -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t 34403 RCLASS) 34404 A target hook that places additional preference on the register 34405 class to use when it is necessary to rename a register in class 34406 RCLASS to another class, or perhaps NO_REGS, if no preferred 34407 register class is found or hook 'preferred_rename_class' is not 34408 implemented. Sometimes returning a more restrictive class makes 34409 better code. For example, on ARM, thumb-2 instructions using 34410 'LO_REGS' may be smaller than instructions using 'GENERIC_REGS'. 34411 By returning 'LO_REGS' from 'preferred_rename_class', code size can 34412 be reduced. 34413 34414 -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X, 34415 reg_class_t RCLASS) 34416 A target hook that places additional restrictions on the register 34417 class to use when it is necessary to copy value X into a register 34418 in class RCLASS. The value is a register class; perhaps RCLASS, or 34419 perhaps another, smaller class. 34420 34421 The default version of this hook always returns value of 'rclass' 34422 argument. 34423 34424 Sometimes returning a more restrictive class makes better code. 34425 For example, on the 68000, when X is an integer constant that is in 34426 range for a 'moveq' instruction, the value of this macro is always 34427 'DATA_REGS' as long as RCLASS includes the data registers. 34428 Requiring a data register guarantees that a 'moveq' will be used. 34429 34430 One case where 'TARGET_PREFERRED_RELOAD_CLASS' must not return 34431 RCLASS is if X is a legitimate constant which cannot be loaded into 34432 some register class. By returning 'NO_REGS' you can force X into a 34433 memory location. For example, rs6000 can load immediate values 34434 into general-purpose registers, but does not have an instruction 34435 for loading an immediate value into a floating-point register, so 34436 'TARGET_PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 34437 floating-point constant. If the constant can't be loaded into any 34438 kind of register, code generation will be better if 34439 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 34440 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 34441 34442 If an insn has pseudos in it after register allocation, reload will 34443 go through the alternatives and call repeatedly 34444 'TARGET_PREFERRED_RELOAD_CLASS' to find the best one. Returning 34445 'NO_REGS', in this case, makes reload add a '!' in front of the 34446 constraint: the x86 back-end uses this feature to discourage usage 34447 of 387 registers when math is done in the SSE registers (and vice 34448 versa). 34449 34450 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 34451 A C expression that places additional restrictions on the register 34452 class to use when it is necessary to copy value X into a register 34453 in class CLASS. The value is a register class; perhaps CLASS, or 34454 perhaps another, smaller class. On many machines, the following 34455 definition is safe: 34456 34457 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 34458 34459 Sometimes returning a more restrictive class makes better code. 34460 For example, on the 68000, when X is an integer constant that is in 34461 range for a 'moveq' instruction, the value of this macro is always 34462 'DATA_REGS' as long as CLASS includes the data registers. 34463 Requiring a data register guarantees that a 'moveq' will be used. 34464 34465 One case where 'PREFERRED_RELOAD_CLASS' must not return CLASS is if 34466 X is a legitimate constant which cannot be loaded into some 34467 register class. By returning 'NO_REGS' you can force X into a 34468 memory location. For example, rs6000 can load immediate values 34469 into general-purpose registers, but does not have an instruction 34470 for loading an immediate value into a floating-point register, so 34471 'PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 34472 floating-point constant. If the constant cannot be loaded into any 34473 kind of register, code generation will be better if 34474 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 34475 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 34476 34477 If an insn has pseudos in it after register allocation, reload will 34478 go through the alternatives and call repeatedly 34479 'PREFERRED_RELOAD_CLASS' to find the best one. Returning 34480 'NO_REGS', in this case, makes reload add a '!' in front of the 34481 constraint: the x86 back-end uses this feature to discourage usage 34482 of 387 registers when math is done in the SSE registers (and vice 34483 versa). 34484 34485 -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx 34486 X, reg_class_t RCLASS) 34487 Like 'TARGET_PREFERRED_RELOAD_CLASS', but for output reloads 34488 instead of input reloads. 34489 34490 The default version of this hook always returns value of 'rclass' 34491 argument. 34492 34493 You can also use 'TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to 34494 discourage reload from using some alternatives, like 34495 'TARGET_PREFERRED_RELOAD_CLASS'. 34496 34497 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 34498 A C expression that places additional restrictions on the register 34499 class to use when it is necessary to be able to hold a value of 34500 mode MODE in a reload register for which class CLASS would 34501 ordinarily be used. 34502 34503 Unlike 'PREFERRED_RELOAD_CLASS', this macro should be used when 34504 there are certain modes that simply cannot go in certain reload 34505 classes. 34506 34507 The value is a register class; perhaps CLASS, or perhaps another, 34508 smaller class. 34509 34510 Don't define this macro unless the target machine has limitations 34511 which require the macro to do something nontrivial. 34512 34513 -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X, 34514 reg_class_t RELOAD_CLASS, machine_mode RELOAD_MODE, 34515 secondary_reload_info *SRI) 34516 Many machines have some registers that cannot be copied directly to 34517 or from memory or even from other types of registers. An example 34518 is the 'MQ' register, which on most machines, can only be copied to 34519 or from general registers, but not memory. Below, we shall be 34520 using the term 'intermediate register' when a move operation cannot 34521 be performed directly, but has to be done by copying the source 34522 into the intermediate register first, and then copying the 34523 intermediate register to the destination. An intermediate register 34524 always has the same mode as source and destination. Since it holds 34525 the actual value being copied, reload might apply optimizations to 34526 re-use an intermediate register and eliding the copy from the 34527 source when it can determine that the intermediate register still 34528 holds the required value. 34529 34530 Another kind of secondary reload is required on some machines which 34531 allow copying all registers to and from memory, but require a 34532 scratch register for stores to some memory locations (e.g., those 34533 with symbolic address on the RT, and those with certain symbolic 34534 address on the SPARC when compiling PIC). Scratch registers need 34535 not have the same mode as the value being copied, and usually hold 34536 a different value than that being copied. Special patterns in the 34537 md file are needed to describe how the copy is performed with the 34538 help of the scratch register; these patterns also describe the 34539 number, register class(es) and mode(s) of the scratch register(s). 34540 34541 In some cases, both an intermediate and a scratch register are 34542 required. 34543 34544 For input reloads, this target hook is called with nonzero IN_P, 34545 and X is an rtx that needs to be copied to a register of class 34546 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 34547 is called with zero IN_P, and a register of class RELOAD_CLASS 34548 needs to be copied to rtx X in RELOAD_MODE. 34549 34550 If copying a register of RELOAD_CLASS from/to X requires an 34551 intermediate register, the hook 'secondary_reload' should return 34552 the register class required for this intermediate register. If no 34553 intermediate register is required, it should return NO_REGS. If 34554 more than one intermediate register is required, describe the one 34555 that is closest in the copy chain to the reload register. 34556 34557 If scratch registers are needed, you also have to describe how to 34558 perform the copy from/to the reload register to/from this closest 34559 intermediate register. Or if no intermediate register is required, 34560 but still a scratch register is needed, describe the copy from/to 34561 the reload register to/from the reload operand X. 34562 34563 You do this by setting 'sri->icode' to the instruction code of a 34564 pattern in the md file which performs the move. Operands 0 and 1 34565 are the output and input of this copy, respectively. Operands from 34566 operand 2 onward are for scratch operands. These scratch operands 34567 must have a mode, and a single-register-class output constraint. 34568 34569 When an intermediate register is used, the 'secondary_reload' hook 34570 will be called again to determine how to copy the intermediate 34571 register to/from the reload operand X, so your hook must also have 34572 code to handle the register class of the intermediate operand. 34573 34574 X might be a pseudo-register or a 'subreg' of a pseudo-register, 34575 which could either be in a hard register or in memory. Use 34576 'true_regnum' to find out; it will return -1 if the pseudo is in 34577 memory and the hard register number if it is in a register. 34578 34579 Scratch operands in memory (constraint '"=m"' / '"=&m"') are 34580 currently not supported. For the time being, you will have to 34581 continue to use 'TARGET_SECONDARY_MEMORY_NEEDED' for that purpose. 34582 34583 'copy_cost' also uses this target hook to find out how values are 34584 copied. If you want it to include some extra cost for the need to 34585 allocate (a) scratch register(s), set 'sri->extra_cost' to the 34586 additional cost. Or if two dependent moves are supposed to have a 34587 lower cost than the sum of the individual moves due to expected 34588 fortuitous scheduling and/or special forwarding logic, you can set 34589 'sri->extra_cost' to a negative amount. 34590 34591 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 34592 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 34593 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 34594 These macros are obsolete, new ports should use the target hook 34595 'TARGET_SECONDARY_RELOAD' instead. 34596 34597 These are obsolete macros, replaced by the 34598 'TARGET_SECONDARY_RELOAD' target hook. Older ports still define 34599 these macros to indicate to the reload phase that it may need to 34600 allocate at least one register for a reload in addition to the 34601 register to contain the data. Specifically, if copying X to a 34602 register CLASS in MODE requires an intermediate register, you were 34603 supposed to define 'SECONDARY_INPUT_RELOAD_CLASS' to return the 34604 largest register class all of whose registers can be used as 34605 intermediate registers or scratch registers. 34606 34607 If copying a register CLASS in MODE to X requires an intermediate 34608 or scratch register, 'SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 34609 to be defined be defined to return the largest register class 34610 required. If the requirements for input and output reloads were 34611 the same, the macro 'SECONDARY_RELOAD_CLASS' should have been used 34612 instead of defining both macros identically. 34613 34614 The values returned by these macros are often 'GENERAL_REGS'. 34615 Return 'NO_REGS' if no spare register is needed; i.e., if X can be 34616 directly copied to or from a register of CLASS in MODE without 34617 requiring a scratch register. Do not define this macro if it would 34618 always return 'NO_REGS'. 34619 34620 If a scratch register is required (either with or without an 34621 intermediate register), you were supposed to define patterns for 34622 'reload_inM' or 'reload_outM', as required (*note Standard Names::. 34623 These patterns, which were normally implemented with a 34624 'define_expand', should be similar to the 'movM' patterns, except 34625 that operand 2 is the scratch register. 34626 34627 These patterns need constraints for the reload register and scratch 34628 register that contain a single register class. If the original 34629 reload register (whose class is CLASS) can meet the constraint 34630 given in the pattern, the value returned by these macros is used 34631 for the class of the scratch register. Otherwise, two additional 34632 reload registers are required. Their classes are obtained from the 34633 constraints in the insn pattern. 34634 34635 X might be a pseudo-register or a 'subreg' of a pseudo-register, 34636 which could either be in a hard register or in memory. Use 34637 'true_regnum' to find out; it will return -1 if the pseudo is in 34638 memory and the hard register number if it is in a register. 34639 34640 These macros should not be used in the case where a particular 34641 class of registers can only be copied to memory and not to another 34642 class of registers. In that case, secondary reload registers are 34643 not needed and would not be helpful. Instead, a stack location 34644 must be used to perform the copy and the 'movM' pattern should use 34645 memory as an intermediate storage. This case often occurs between 34646 floating-point and general registers. 34647 34648 -- Target Hook: bool TARGET_SECONDARY_MEMORY_NEEDED (machine_mode MODE, 34649 reg_class_t CLASS1, reg_class_t CLASS2) 34650 Certain machines have the property that some registers cannot be 34651 copied to some other registers without using memory. Define this 34652 hook on those machines to return true if objects of mode M in 34653 registers of CLASS1 can only be copied to registers of class CLASS2 34654 by storing a register of CLASS1 into memory and loading that memory 34655 location into a register of CLASS2. The default definition returns 34656 false for all inputs. 34657 34658 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 34659 Normally when 'TARGET_SECONDARY_MEMORY_NEEDED' is defined, the 34660 compiler allocates a stack slot for a memory location needed for 34661 register copies. If this macro is defined, the compiler instead 34662 uses the memory location defined by this macro. 34663 34664 Do not define this macro if you do not define 34665 'TARGET_SECONDARY_MEMORY_NEEDED'. 34666 34667 -- Target Hook: machine_mode TARGET_SECONDARY_MEMORY_NEEDED_MODE 34668 (machine_mode MODE) 34669 If 'TARGET_SECONDARY_MEMORY_NEEDED' tells the compiler to use 34670 memory when moving between two particular registers of mode MODE, 34671 this hook specifies the mode that the memory should have. 34672 34673 The default depends on 'TARGET_LRA_P'. Without LRA, the default is 34674 to use a word-sized mode for integral modes that are smaller than a 34675 a word. This is right thing to do on most machines because it 34676 ensures that all bits of the register are copied and prevents 34677 accesses to the registers in a narrower mode, which some machines 34678 prohibit for floating-point registers. 34679 34680 However, this default behavior is not correct on some machines, 34681 such as the DEC Alpha, that store short integers in floating-point 34682 registers differently than in integer registers. On those 34683 machines, the default widening will not work correctly and you must 34684 define this hook to suppress that widening in some cases. See the 34685 file 'alpha.c' for details. 34686 34687 With LRA, the default is to use MODE unmodified. 34688 34689 -- Target Hook: void TARGET_SELECT_EARLY_REMAT_MODES (sbitmap MODES) 34690 On some targets, certain modes cannot be held in registers around a 34691 standard ABI call and are relatively expensive to spill to the 34692 stack. The early rematerialization pass can help in such cases by 34693 aggressively recomputing values after calls, so that they don't 34694 need to be spilled. 34695 34696 This hook returns the set of such modes by setting the associated 34697 bits in MODES. The default implementation selects no modes, which 34698 has the effect of disabling the early rematerialization pass. 34699 34700 -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS) 34701 A target hook which returns 'true' if pseudos that have been 34702 assigned to registers of class RCLASS would likely be spilled 34703 because registers of RCLASS are needed for spill registers. 34704 34705 The default version of this target hook returns 'true' if RCLASS 34706 has exactly one register and 'false' otherwise. On most machines, 34707 this default should be used. For generally register-starved 34708 machines, such as i386, or machines with right register 34709 constraints, such as SH, this hook can be used to avoid excessive 34710 spilling. 34711 34712 This hook is also used by some of the global intra-procedural code 34713 transformations to throtle code motion, to avoid increasing 34714 register pressure. 34715 34716 -- Target Hook: unsigned char TARGET_CLASS_MAX_NREGS (reg_class_t 34717 RCLASS, machine_mode MODE) 34718 A target hook returns the maximum number of consecutive registers 34719 of class RCLASS needed to hold a value of mode MODE. 34720 34721 This is closely related to the macro 'TARGET_HARD_REGNO_NREGS'. In 34722 fact, the value returned by 'TARGET_CLASS_MAX_NREGS (RCLASS, MODE)' 34723 target hook should be the maximum value of 'TARGET_HARD_REGNO_NREGS 34724 (REGNO, MODE)' for all REGNO values in the class RCLASS. 34725 34726 This target hook helps control the handling of multiple-word values 34727 in the reload pass. 34728 34729 The default version of this target hook returns the size of MODE in 34730 words. 34731 34732 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 34733 A C expression for the maximum number of consecutive registers of 34734 class CLASS needed to hold a value of mode MODE. 34735 34736 This is closely related to the macro 'TARGET_HARD_REGNO_NREGS'. In 34737 fact, the value of the macro 'CLASS_MAX_NREGS (CLASS, MODE)' should 34738 be the maximum value of 'TARGET_HARD_REGNO_NREGS (REGNO, MODE)' for 34739 all REGNO values in the class CLASS. 34740 34741 This macro helps control the handling of multiple-word values in 34742 the reload pass. 34743 34744 -- Target Hook: bool TARGET_CAN_CHANGE_MODE_CLASS (machine_mode FROM, 34745 machine_mode TO, reg_class_t RCLASS) 34746 This hook returns true if it is possible to bitcast values held in 34747 registers of class RCLASS from mode FROM to mode TO and if doing so 34748 preserves the low-order bits that are common to both modes. The 34749 result is only meaningful if RCLASS has registers that can hold 34750 both 'from' and 'to'. The default implementation returns true. 34751 34752 As an example of when such bitcasting is invalid, loading 32-bit 34753 integer or floating-point objects into floating-point registers on 34754 Alpha extends them to 64 bits. Therefore loading a 64-bit object 34755 and then storing it as a 32-bit object does not store the low-order 34756 32 bits, as would be the case for a normal register. Therefore, 34757 'alpha.h' defines 'TARGET_CAN_CHANGE_MODE_CLASS' to return: 34758 34759 (GET_MODE_SIZE (from) == GET_MODE_SIZE (to) 34760 || !reg_classes_intersect_p (FLOAT_REGS, rclass)) 34761 34762 Even if storing from a register in mode TO would be valid, if both 34763 FROM and 'raw_reg_mode' for RCLASS are wider than 'word_mode', then 34764 we must prevent TO narrowing the mode. This happens when the 34765 middle-end assumes that it can load or store pieces of an N-word 34766 pseudo, and that the pseudo will eventually be allocated to N 34767 'word_mode' hard registers. Failure to prevent this kind of mode 34768 change will result in the entire 'raw_reg_mode' being modified 34769 instead of the partial value that the middle-end intended. 34770 34771 -- Target Hook: reg_class_t TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS 34772 (int, REG_CLASS_T, REG_CLASS_T) 34773 A target hook which can change allocno class for given pseudo from 34774 allocno and best class calculated by IRA. 34775 34776 The default version of this target hook always returns given class. 34777 34778 -- Target Hook: bool TARGET_LRA_P (void) 34779 A target hook which returns true if we use LRA instead of reload 34780 pass. The default version of this target hook returns true. New 34781 ports should use LRA, and existing ports are encouraged to convert. 34782 34783 -- Target Hook: int TARGET_REGISTER_PRIORITY (int) 34784 A target hook which returns the register priority number to which 34785 the register HARD_REGNO belongs to. The bigger the number, the 34786 more preferable the hard register usage (when all other conditions 34787 are the same). This hook can be used to prefer some hard register 34788 over others in LRA. For example, some x86-64 register usage needs 34789 additional prefix which makes instructions longer. The hook can 34790 return lower priority number for such registers make them less 34791 favorable and as result making the generated code smaller. The 34792 default version of this target hook returns always zero. 34793 34794 -- Target Hook: bool TARGET_REGISTER_USAGE_LEVELING_P (void) 34795 A target hook which returns true if we need register usage 34796 leveling. That means if a few hard registers are equally good for 34797 the assignment, we choose the least used hard register. The 34798 register usage leveling may be profitable for some targets. Don't 34799 use the usage leveling for targets with conditional execution or 34800 targets with big register files as it hurts if-conversion and 34801 cross-jumping optimizations. The default version of this target 34802 hook returns always false. 34803 34804 -- Target Hook: bool TARGET_DIFFERENT_ADDR_DISPLACEMENT_P (void) 34805 A target hook which returns true if an address with the same 34806 structure can have different maximal legitimate displacement. For 34807 example, the displacement can depend on memory mode or on operand 34808 combinations in the insn. The default version of this target hook 34809 returns always false. 34810 34811 -- Target Hook: bool TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P (rtx SUBST) 34812 A target hook which returns 'true' if SUBST can't substitute safely 34813 pseudos with equivalent memory values during register allocation. 34814 The default version of this target hook returns 'false'. On most 34815 machines, this default should be used. For generally machines with 34816 non orthogonal register usage for addressing, such as SH, this hook 34817 can be used to avoid excessive spilling. 34818 34819 -- Target Hook: bool TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT (rtx 34820 *OFFSET1, rtx *OFFSET2, poly_int64 ORIG_OFFSET, machine_mode 34821 MODE) 34822 This hook tries to split address offset ORIG_OFFSET into two parts: 34823 one that should be added to the base address to create a local 34824 anchor point, and an additional offset that can be applied to the 34825 anchor to address a value of mode MODE. The idea is that the local 34826 anchor could be shared by other accesses to nearby locations. 34827 34828 The hook returns true if it succeeds, storing the offset of the 34829 anchor from the base in OFFSET1 and the offset of the final address 34830 from the anchor in OFFSET2. The default implementation returns 34831 false. 34832 34833 -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t, 34834 MACHINE_MODE) 34835 This hook defines a class of registers which could be used for 34836 spilling pseudos of the given mode and class, or 'NO_REGS' if only 34837 memory should be used. Not defining this hook is equivalent to 34838 returning 'NO_REGS' for all inputs. 34839 34840 -- Target Hook: bool TARGET_ADDITIONAL_ALLOCNO_CLASS_P (reg_class_t) 34841 This hook should return 'true' if given class of registers should 34842 be an allocno class in any way. Usually RA uses only one register 34843 class from all classes containing the same register set. In some 34844 complicated cases, you need to have two or more such classes as 34845 allocno ones for RA correct work. Not defining this hook is 34846 equivalent to returning 'false' for all inputs. 34847 34848 -- Target Hook: scalar_int_mode TARGET_CSTORE_MODE (enum insn_code 34849 ICODE) 34850 This hook defines the machine mode to use for the boolean result of 34851 conditional store patterns. The ICODE argument is the instruction 34852 code for the cstore being performed. Not definiting this hook is 34853 the same as accepting the mode encoded into operand 0 of the cstore 34854 expander patterns. 34855 34856 -- Target Hook: int TARGET_COMPUTE_PRESSURE_CLASSES (enum reg_class 34857 *PRESSURE_CLASSES) 34858 A target hook which lets a backend compute the set of pressure 34859 classes to be used by those optimization passes which take register 34860 pressure into account, as opposed to letting IRA compute them. It 34861 returns the number of register classes stored in the array 34862 PRESSURE_CLASSES. 34863 34864 34865File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros 34866 3486718.9 Stack Layout and Calling Conventions 34868========================================= 34869 34870This describes the stack layout and calling conventions. 34871 34872* Menu: 34873 34874* Frame Layout:: 34875* Exception Handling:: 34876* Stack Checking:: 34877* Frame Registers:: 34878* Elimination:: 34879* Stack Arguments:: 34880* Register Arguments:: 34881* Scalar Return:: 34882* Aggregate Return:: 34883* Caller Saves:: 34884* Function Entry:: 34885* Profiling:: 34886* Tail Calls:: 34887* Shrink-wrapping separate components:: 34888* Stack Smashing Protection:: 34889* Miscellaneous Register Hooks:: 34890 34891 34892File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 34893 3489418.9.1 Basic Stack Layout 34895------------------------- 34896 34897Here is the basic stack layout. 34898 34899 -- Macro: STACK_GROWS_DOWNWARD 34900 Define this macro to be true if pushing a word onto the stack moves 34901 the stack pointer to a smaller address, and false otherwise. 34902 34903 -- Macro: STACK_PUSH_CODE 34904 This macro defines the operation used when something is pushed on 34905 the stack. In RTL, a push operation will be '(set (mem 34906 (STACK_PUSH_CODE (reg sp))) ...)' 34907 34908 The choices are 'PRE_DEC', 'POST_DEC', 'PRE_INC', and 'POST_INC'. 34909 Which of these is correct depends on the stack direction and on 34910 whether the stack pointer points to the last item on the stack or 34911 whether it points to the space for the next item on the stack. 34912 34913 The default is 'PRE_DEC' when 'STACK_GROWS_DOWNWARD' is true, which 34914 is almost always right, and 'PRE_INC' otherwise, which is often 34915 wrong. 34916 34917 -- Macro: FRAME_GROWS_DOWNWARD 34918 Define this macro to nonzero value if the addresses of local 34919 variable slots are at negative offsets from the frame pointer. 34920 34921 -- Macro: ARGS_GROW_DOWNWARD 34922 Define this macro if successive arguments to a function occupy 34923 decreasing addresses on the stack. 34924 34925 -- Target Hook: HOST_WIDE_INT TARGET_STARTING_FRAME_OFFSET (void) 34926 This hook returns the offset from the frame pointer to the first 34927 local variable slot to be allocated. If 'FRAME_GROWS_DOWNWARD', it 34928 is the offset to _end_ of the first slot allocated, otherwise it is 34929 the offset to _beginning_ of the first slot allocated. The default 34930 implementation returns 0. 34931 34932 -- Macro: STACK_ALIGNMENT_NEEDED 34933 Define to zero to disable final alignment of the stack during 34934 reload. The nonzero default for this macro is suitable for most 34935 ports. 34936 34937 On ports where 'TARGET_STARTING_FRAME_OFFSET' is nonzero or where 34938 there is a register save block following the local block that 34939 doesn't require alignment to 'STACK_BOUNDARY', it may be beneficial 34940 to disable stack alignment and do it in the backend. 34941 34942 -- Macro: STACK_POINTER_OFFSET 34943 Offset from the stack pointer register to the first location at 34944 which outgoing arguments are placed. If not specified, the default 34945 value of zero is used. This is the proper value for most machines. 34946 34947 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 34948 the first location at which outgoing arguments are placed. 34949 34950 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 34951 Offset from the argument pointer register to the first argument's 34952 address. On some machines it may depend on the data type of the 34953 function. 34954 34955 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 34956 the first argument's address. 34957 34958 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 34959 Offset from the stack pointer register to an item dynamically 34960 allocated on the stack, e.g., by 'alloca'. 34961 34962 The default value for this macro is 'STACK_POINTER_OFFSET' plus the 34963 length of the outgoing arguments. The default is correct for most 34964 machines. See 'function.c' for details. 34965 34966 -- Macro: INITIAL_FRAME_ADDRESS_RTX 34967 A C expression whose value is RTL representing the address of the 34968 initial stack frame. This address is passed to 'RETURN_ADDR_RTX' 34969 and 'DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 34970 reasonable default value will be used. Define this macro in order 34971 to make frame pointer elimination work in the presence of 34972 '__builtin_frame_address (count)' and '__builtin_return_address 34973 (count)' for 'count' not equal to zero. 34974 34975 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 34976 A C expression whose value is RTL representing the address in a 34977 stack frame where the pointer to the caller's frame is stored. 34978 Assume that FRAMEADDR is an RTL expression for the address of the 34979 stack frame itself. 34980 34981 If you don't define this macro, the default is to return the value 34982 of FRAMEADDR--that is, the stack frame address is also the address 34983 of the stack word that points to the previous frame. 34984 34985 -- Macro: SETUP_FRAME_ADDRESSES 34986 A C expression that produces the machine-specific code to setup the 34987 stack so that arbitrary frames can be accessed. For example, on 34988 the SPARC, we must flush all of the register windows to the stack 34989 before we can access arbitrary stack frames. You will seldom need 34990 to define this macro. The default is to do nothing. 34991 34992 -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void) 34993 This target hook should return an rtx that is used to store the 34994 address of the current frame into the built in 'setjmp' buffer. 34995 The default value, 'virtual_stack_vars_rtx', is correct for most 34996 machines. One reason you may need to define this target hook is if 34997 'hard_frame_pointer_rtx' is the appropriate value on your machine. 34998 34999 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 35000 A C expression whose value is RTL representing the value of the 35001 frame address for the current frame. FRAMEADDR is the frame 35002 pointer of the current frame. This is used for 35003 __builtin_frame_address. You need only define this macro if the 35004 frame address is not the same as the frame pointer. Most machines 35005 do not need to define it. 35006 35007 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 35008 A C expression whose value is RTL representing the value of the 35009 return address for the frame COUNT steps up from the current frame, 35010 after the prologue. FRAMEADDR is the frame pointer of the COUNT 35011 frame, or the frame pointer of the COUNT - 1 frame if 35012 'RETURN_ADDR_IN_PREVIOUS_FRAME' is nonzero. 35013 35014 The value of the expression must always be the correct address when 35015 COUNT is zero, but may be 'NULL_RTX' if there is no way to 35016 determine the return address of other frames. 35017 35018 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 35019 Define this macro to nonzero value if the return address of a 35020 particular stack frame is accessed from the frame pointer of the 35021 previous stack frame. The zero default for this macro is suitable 35022 for most ports. 35023 35024 -- Macro: INCOMING_RETURN_ADDR_RTX 35025 A C expression whose value is RTL representing the location of the 35026 incoming return address at the beginning of any function, before 35027 the prologue. This RTL is either a 'REG', indicating that the 35028 return value is saved in 'REG', or a 'MEM' representing a location 35029 in the stack. 35030 35031 You only need to define this macro if you want to support call 35032 frame debugging information like that provided by DWARF 2. 35033 35034 If this RTL is a 'REG', you should also define 35035 'DWARF_FRAME_RETURN_COLUMN' to 'DWARF_FRAME_REGNUM (REGNO)'. 35036 35037 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 35038 A C expression whose value is an integer giving a DWARF 2 column 35039 number that may be used as an alternative return column. The 35040 column must not correspond to any gcc hard register (that is, it 35041 must not be in the range of 'DWARF_FRAME_REGNUM'). 35042 35043 This macro can be useful if 'DWARF_FRAME_RETURN_COLUMN' is set to a 35044 general register, but an alternative column needs to be used for 35045 signal frames. Some targets have also used different frame return 35046 columns over time. 35047 35048 -- Macro: DWARF_ZERO_REG 35049 A C expression whose value is an integer giving a DWARF 2 register 35050 number that is considered to always have the value zero. This 35051 should only be defined if the target has an architected zero 35052 register, and someone decided it was a good idea to use that 35053 register number to terminate the stack backtrace. New ports should 35054 avoid this. 35055 35056 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 35057 *LABEL, rtx PATTERN, int INDEX) 35058 This target hook allows the backend to emit frame-related insns 35059 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 35060 debugging info engine will invoke it on insns of the form 35061 (set (reg) (unspec [...] UNSPEC_INDEX)) 35062 and 35063 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 35064 to let the backend emit the call frame instructions. LABEL is the 35065 CFI label attached to the insn, PATTERN is the pattern of the insn 35066 and INDEX is 'UNSPEC_INDEX' or 'UNSPECV_INDEX'. 35067 35068 -- Target Hook: unsigned int TARGET_DWARF_POLY_INDETERMINATE_VALUE 35069 (unsigned int I, unsigned int *FACTOR, int *OFFSET) 35070 Express the value of 'poly_int' indeterminate I as a DWARF 35071 expression, with I counting from 1. Return the number of a DWARF 35072 register R and set '*FACTOR' and '*OFFSET' such that the value of 35073 the indeterminate is: 35074 value_of(R) / FACTOR - OFFSET 35075 35076 A target only needs to define this hook if it sets 35077 'NUM_POLY_INT_COEFFS' to a value greater than 1. 35078 35079 -- Macro: INCOMING_FRAME_SP_OFFSET 35080 A C expression whose value is an integer giving the offset, in 35081 bytes, from the value of the stack pointer register to the top of 35082 the stack frame at the beginning of any function, before the 35083 prologue. The top of the frame is defined to be the value of the 35084 stack pointer in the previous frame, just before the call 35085 instruction. 35086 35087 You only need to define this macro if you want to support call 35088 frame debugging information like that provided by DWARF 2. 35089 35090 -- Macro: DEFAULT_INCOMING_FRAME_SP_OFFSET 35091 Like 'INCOMING_FRAME_SP_OFFSET', but must be the same for all 35092 functions of the same ABI, and when using GAS '.cfi_*' directives 35093 must also agree with the default CFI GAS emits. Define this macro 35094 only if 'INCOMING_FRAME_SP_OFFSET' can have different values 35095 between different functions of the same ABI or when 35096 'INCOMING_FRAME_SP_OFFSET' does not agree with GAS default CFI. 35097 35098 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 35099 A C expression whose value is an integer giving the offset, in 35100 bytes, from the argument pointer to the canonical frame address 35101 (cfa). The final value should coincide with that calculated by 35102 'INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 35103 during virtual register instantiation. 35104 35105 The default value for this macro is 'FIRST_PARM_OFFSET (fundecl) + 35106 crtl->args.pretend_args_size', which is correct for most machines; 35107 in general, the arguments are found immediately before the stack 35108 frame. Note that this is not the case on some targets that save 35109 registers into the caller's frame, such as SPARC and rs6000, and so 35110 such targets need to define this macro. 35111 35112 You only need to define this macro if the default is incorrect, and 35113 you want to support call frame debugging information like that 35114 provided by DWARF 2. 35115 35116 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 35117 If defined, a C expression whose value is an integer giving the 35118 offset in bytes from the frame pointer to the canonical frame 35119 address (cfa). The final value should coincide with that 35120 calculated by 'INCOMING_FRAME_SP_OFFSET'. 35121 35122 Normally the CFA is calculated as an offset from the argument 35123 pointer, via 'ARG_POINTER_CFA_OFFSET', but if the argument pointer 35124 is variable due to the ABI, this may not be possible. If this 35125 macro is defined, it implies that the virtual register 35126 instantiation should be based on the frame pointer instead of the 35127 argument pointer. Only one of 'FRAME_POINTER_CFA_OFFSET' and 35128 'ARG_POINTER_CFA_OFFSET' should be defined. 35129 35130 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 35131 If defined, a C expression whose value is an integer giving the 35132 offset in bytes from the canonical frame address (cfa) to the frame 35133 base used in DWARF 2 debug information. The default is zero. A 35134 different value may reduce the size of debug information on some 35135 ports. 35136 35137 35138File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 35139 3514018.9.2 Exception Handling Support 35141--------------------------------- 35142 35143 -- Macro: EH_RETURN_DATA_REGNO (N) 35144 A C expression whose value is the Nth register number used for data 35145 by exception handlers, or 'INVALID_REGNUM' if fewer than N 35146 registers are usable. 35147 35148 The exception handling library routines communicate with the 35149 exception handlers via a set of agreed upon registers. Ideally 35150 these registers should be call-clobbered; it is possible to use 35151 call-saved registers, but may negatively impact code size. The 35152 target must support at least 2 data registers, but should define 4 35153 if there are enough free registers. 35154 35155 You must define this macro if you want to support call frame 35156 exception handling like that provided by DWARF 2. 35157 35158 -- Macro: EH_RETURN_STACKADJ_RTX 35159 A C expression whose value is RTL representing a location in which 35160 to store a stack adjustment to be applied before function return. 35161 This is used to unwind the stack to an exception handler's call 35162 frame. It will be assigned zero on code paths that return 35163 normally. 35164 35165 Typically this is a call-clobbered hard register that is otherwise 35166 untouched by the epilogue, but could also be a stack slot. 35167 35168 Do not define this macro if the stack pointer is saved and restored 35169 by the regular prolog and epilog code in the call frame itself; in 35170 this case, the exception handling library routines will update the 35171 stack location to be restored in place. Otherwise, you must define 35172 this macro if you want to support call frame exception handling 35173 like that provided by DWARF 2. 35174 35175 -- Macro: EH_RETURN_HANDLER_RTX 35176 A C expression whose value is RTL representing a location in which 35177 to store the address of an exception handler to which we should 35178 return. It will not be assigned on code paths that return 35179 normally. 35180 35181 Typically this is the location in the call frame at which the 35182 normal return address is stored. For targets that return by 35183 popping an address off the stack, this might be a memory address 35184 just below the _target_ call frame rather than inside the current 35185 call frame. If defined, 'EH_RETURN_STACKADJ_RTX' will have already 35186 been assigned, so it may be used to calculate the location of the 35187 target call frame. 35188 35189 Some targets have more complex requirements than storing to an 35190 address calculable during initial code generation. In that case 35191 the 'eh_return' instruction pattern should be used instead. 35192 35193 If you want to support call frame exception handling, you must 35194 define either this macro or the 'eh_return' instruction pattern. 35195 35196 -- Macro: RETURN_ADDR_OFFSET 35197 If defined, an integer-valued C expression for which rtl will be 35198 generated to add it to the exception handler address before it is 35199 searched in the exception handling tables, and to subtract it again 35200 from the address before using it to return to the exception 35201 handler. 35202 35203 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 35204 This macro chooses the encoding of pointers embedded in the 35205 exception handling sections. If at all possible, this should be 35206 defined such that the exception handling section will not require 35207 dynamic relocations, and so may be read-only. 35208 35209 CODE is 0 for data, 1 for code labels, 2 for function pointers. 35210 GLOBAL is true if the symbol may be affected by dynamic 35211 relocations. The macro should return a combination of the 35212 'DW_EH_PE_*' defines as found in 'dwarf2.h'. 35213 35214 If this macro is not defined, pointers will not be encoded but 35215 represented directly. 35216 35217 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 35218 ADDR, DONE) 35219 This macro allows the target to emit whatever special magic is 35220 required to represent the encoding chosen by 35221 'ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 35222 pc-relative and indirect encodings; this must be defined if the 35223 target uses text-relative or data-relative encodings. 35224 35225 This is a C statement that branches to DONE if the format was 35226 handled. ENCODING is the format chosen, SIZE is the number of 35227 bytes that the format occupies, ADDR is the 'SYMBOL_REF' to be 35228 emitted. 35229 35230 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 35231 This macro allows the target to add CPU and operating system 35232 specific code to the call-frame unwinder for use when there is no 35233 unwind data available. The most common reason to implement this 35234 macro is to unwind through signal frames. 35235 35236 This macro is called from 'uw_frame_state_for' in 'unwind-dw2.c', 35237 'unwind-dw2-xtensa.c' and 'unwind-ia64.c'. CONTEXT is an 35238 '_Unwind_Context'; FS is an '_Unwind_FrameState'. Examine 35239 'context->ra' for the address of the code being executed and 35240 'context->cfa' for the stack pointer value. If the frame can be 35241 decoded, the register save addresses should be updated in FS and 35242 the macro should evaluate to '_URC_NO_REASON'. If the frame cannot 35243 be decoded, the macro should evaluate to '_URC_END_OF_STACK'. 35244 35245 For proper signal handling in Java this macro is accompanied by 35246 'MAKE_THROW_FRAME', defined in 'libjava/include/*-signal.h' 35247 headers. 35248 35249 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 35250 This macro allows the target to add operating system specific code 35251 to the call-frame unwinder to handle the IA-64 '.unwabi' unwinding 35252 directive, usually used for signal or interrupt frames. 35253 35254 This macro is called from 'uw_update_context' in libgcc's 35255 'unwind-ia64.c'. CONTEXT is an '_Unwind_Context'; FS is an 35256 '_Unwind_FrameState'. Examine 'fs->unwabi' for the abi and context 35257 in the '.unwabi' directive. If the '.unwabi' directive can be 35258 handled, the register save addresses should be updated in FS. 35259 35260 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 35261 A C expression that evaluates to true if the target requires unwind 35262 info to be given comdat linkage. Define it to be '1' if comdat 35263 linkage is necessary. The default is '0'. 35264 35265 35266File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 35267 3526818.9.3 Specifying How Stack Checking is Done 35269-------------------------------------------- 35270 35271GCC will check that stack references are within the boundaries of the 35272stack, if the option '-fstack-check' is specified, in one of three ways: 35273 35274 1. If the value of the 'STACK_CHECK_BUILTIN' macro is nonzero, GCC 35275 will assume that you have arranged for full stack checking to be 35276 done at appropriate places in the configuration files. GCC will 35277 not do other special processing. 35278 35279 2. If 'STACK_CHECK_BUILTIN' is zero and the value of the 35280 'STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume that 35281 you have arranged for static stack checking (checking of the static 35282 stack frame of functions) to be done at appropriate places in the 35283 configuration files. GCC will only emit code to do dynamic stack 35284 checking (checking on dynamic stack allocations) using the third 35285 approach below. 35286 35287 3. If neither of the above are true, GCC will generate code to 35288 periodically "probe" the stack pointer using the values of the 35289 macros defined below. 35290 35291 If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is 35292defined, GCC will change its allocation strategy for large objects if 35293the option '-fstack-check' is specified: they will always be allocated 35294dynamically if their size exceeds 'STACK_CHECK_MAX_VAR_SIZE' bytes. 35295 35296 -- Macro: STACK_CHECK_BUILTIN 35297 A nonzero value if stack checking is done by the configuration 35298 files in a machine-dependent manner. You should define this macro 35299 if stack checking is required by the ABI of your machine or if you 35300 would like to do stack checking in some more efficient way than the 35301 generic approach. The default value of this macro is zero. 35302 35303 -- Macro: STACK_CHECK_STATIC_BUILTIN 35304 A nonzero value if static stack checking is done by the 35305 configuration files in a machine-dependent manner. You should 35306 define this macro if you would like to do static stack checking in 35307 some more efficient way than the generic approach. The default 35308 value of this macro is zero. 35309 35310 -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP 35311 An integer specifying the interval at which GCC must generate stack 35312 probe instructions, defined as 2 raised to this integer. You will 35313 normally define this macro so that the interval be no larger than 35314 the size of the "guard pages" at the end of a stack area. The 35315 default value of 12 (4096-byte interval) is suitable for most 35316 systems. 35317 35318 -- Macro: STACK_CHECK_MOVING_SP 35319 An integer which is nonzero if GCC should move the stack pointer 35320 page by page when doing probes. This can be necessary on systems 35321 where the stack pointer contains the bottom address of the memory 35322 area accessible to the executing thread at any point in time. In 35323 this situation an alternate signal stack is required in order to be 35324 able to recover from a stack overflow. The default value of this 35325 macro is zero. 35326 35327 -- Macro: STACK_CHECK_PROTECT 35328 The number of bytes of stack needed to recover from a stack 35329 overflow, for languages where such a recovery is supported. The 35330 default value of 4KB/8KB with the 'setjmp'/'longjmp'-based 35331 exception handling mechanism and 8KB/12KB with other exception 35332 handling mechanisms should be adequate for most architectures and 35333 operating systems. 35334 35335 The following macros are relevant only if neither STACK_CHECK_BUILTIN 35336nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether 35337in the opposite case. 35338 35339 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 35340 The maximum size of a stack frame, in bytes. GCC will generate 35341 probe instructions in non-leaf functions to ensure at least this 35342 many bytes of stack are available. If a stack frame is larger than 35343 this size, stack checking will not be reliable and GCC will issue a 35344 warning. The default is chosen so that GCC only generates one 35345 instruction on most systems. You should normally not change the 35346 default value of this macro. 35347 35348 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 35349 GCC uses this value to generate the above warning message. It 35350 represents the amount of fixed frame used by a function, not 35351 including space for any callee-saved registers, temporaries and 35352 user variables. You need only specify an upper bound for this 35353 amount and will normally use the default of four words. 35354 35355 -- Macro: STACK_CHECK_MAX_VAR_SIZE 35356 The maximum size, in bytes, of an object that GCC will place in the 35357 fixed area of the stack frame when the user specifies 35358 '-fstack-check'. GCC computed the default from the values of the 35359 above macros and you will normally not need to override that 35360 default. 35361 35362 -- Target Hook: HOST_WIDE_INT 35363 TARGET_STACK_CLASH_PROTECTION_ALLOCA_PROBE_RANGE (void) 35364 Some targets have an ABI defined interval for which no probing 35365 needs to be done. When a probe does need to be done this same 35366 interval is used as the probe distance up when doing stack clash 35367 protection for alloca. On such targets this value can be set to 35368 override the default probing up interval. Define this variable to 35369 return nonzero if such a probe range is required or zero otherwise. 35370 Defining this hook also requires your functions which make use of 35371 alloca to have at least 8 byesof outgoing arguments. If this is 35372 not the case the stack will be corrupted. You need not define this 35373 macro if it would always have the value zero. 35374 35375 35376File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 35377 3537818.9.4 Registers That Address the Stack Frame 35379--------------------------------------------- 35380 35381This discusses registers that address the stack frame. 35382 35383 -- Macro: STACK_POINTER_REGNUM 35384 The register number of the stack pointer register, which must also 35385 be a fixed register according to 'FIXED_REGISTERS'. On most 35386 machines, the hardware determines which register this is. 35387 35388 -- Macro: FRAME_POINTER_REGNUM 35389 The register number of the frame pointer register, which is used to 35390 access automatic variables in the stack frame. On some machines, 35391 the hardware determines which register this is. On other machines, 35392 you can choose any register you wish for this purpose. 35393 35394 -- Macro: HARD_FRAME_POINTER_REGNUM 35395 On some machines the offset between the frame pointer and starting 35396 offset of the automatic variables is not known until after register 35397 allocation has been done (for example, because the saved registers 35398 are between these two locations). On those machines, define 35399 'FRAME_POINTER_REGNUM' the number of a special, fixed register to 35400 be used internally until the offset is known, and define 35401 'HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 35402 used for the frame pointer. 35403 35404 You should define this macro only in the very rare circumstances 35405 when it is not possible to calculate the offset between the frame 35406 pointer and the automatic variables until after register allocation 35407 has been completed. When this macro is defined, you must also 35408 indicate in your definition of 'ELIMINABLE_REGS' how to eliminate 35409 'FRAME_POINTER_REGNUM' into either 'HARD_FRAME_POINTER_REGNUM' or 35410 'STACK_POINTER_REGNUM'. 35411 35412 Do not define this macro if it would be the same as 35413 'FRAME_POINTER_REGNUM'. 35414 35415 -- Macro: ARG_POINTER_REGNUM 35416 The register number of the arg pointer register, which is used to 35417 access the function's argument list. On some machines, this is the 35418 same as the frame pointer register. On some machines, the hardware 35419 determines which register this is. On other machines, you can 35420 choose any register you wish for this purpose. If this is not the 35421 same register as the frame pointer register, then you must mark it 35422 as a fixed register according to 'FIXED_REGISTERS', or arrange to 35423 be able to eliminate it (*note Elimination::). 35424 35425 -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER 35426 Define this to a preprocessor constant that is nonzero if 35427 'hard_frame_pointer_rtx' and 'frame_pointer_rtx' should be the 35428 same. The default definition is '(HARD_FRAME_POINTER_REGNUM == 35429 FRAME_POINTER_REGNUM)'; you only need to define this macro if that 35430 definition is not suitable for use in preprocessor conditionals. 35431 35432 -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER 35433 Define this to a preprocessor constant that is nonzero if 35434 'hard_frame_pointer_rtx' and 'arg_pointer_rtx' should be the same. 35435 The default definition is '(HARD_FRAME_POINTER_REGNUM == 35436 ARG_POINTER_REGNUM)'; you only need to define this macro if that 35437 definition is not suitable for use in preprocessor conditionals. 35438 35439 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 35440 The register number of the return address pointer register, which 35441 is used to access the current function's return address from the 35442 stack. On some machines, the return address is not at a fixed 35443 offset from the frame pointer or stack pointer or argument pointer. 35444 This register can be defined to point to the return address on the 35445 stack, and then be converted by 'ELIMINABLE_REGS' into either the 35446 frame pointer or stack pointer. 35447 35448 Do not define this macro unless there is no other way to get the 35449 return address from the stack. 35450 35451 -- Macro: STATIC_CHAIN_REGNUM 35452 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 35453 Register numbers used for passing a function's static chain 35454 pointer. If register windows are used, the register number as seen 35455 by the called function is 'STATIC_CHAIN_INCOMING_REGNUM', while the 35456 register number as seen by the calling function is 35457 'STATIC_CHAIN_REGNUM'. If these registers are the same, 35458 'STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 35459 35460 The static chain register need not be a fixed register. 35461 35462 If the static chain is passed in memory, these macros should not be 35463 defined; instead, the 'TARGET_STATIC_CHAIN' hook should be used. 35464 35465 -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL_OR_TYPE, 35466 bool INCOMING_P) 35467 This hook replaces the use of 'STATIC_CHAIN_REGNUM' et al for 35468 targets that may use different static chain locations for different 35469 nested functions. This may be required if the target has function 35470 attributes that affect the calling conventions of the function and 35471 those calling conventions use different static chain locations. 35472 35473 The default version of this hook uses 'STATIC_CHAIN_REGNUM' et al. 35474 35475 If the static chain is passed in memory, this hook should be used 35476 to provide rtx giving 'mem' expressions that denote where they are 35477 stored. Often the 'mem' expression as seen by the caller will be 35478 at an offset from the stack pointer and the 'mem' expression as 35479 seen by the callee will be at an offset from the frame pointer. 35480 The variables 'stack_pointer_rtx', 'frame_pointer_rtx', and 35481 'arg_pointer_rtx' will have been initialized and should be used to 35482 refer to those items. 35483 35484 -- Macro: DWARF_FRAME_REGISTERS 35485 This macro specifies the maximum number of hard registers that can 35486 be saved in a call frame. This is used to size data structures 35487 used in DWARF2 exception handling. 35488 35489 Prior to GCC 3.0, this macro was needed in order to establish a 35490 stable exception handling ABI in the face of adding new hard 35491 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 35492 insulated from changes in the number of hard registers. 35493 Nevertheless, this macro can still be used to reduce the runtime 35494 memory requirements of the exception handling routines, which can 35495 be substantial if the ISA contains a lot of registers that are not 35496 call-saved. 35497 35498 If this macro is not defined, it defaults to 35499 'FIRST_PSEUDO_REGISTER'. 35500 35501 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 35502 35503 This macro is similar to 'DWARF_FRAME_REGISTERS', but is provided 35504 for backward compatibility in pre GCC 3.0 compiled code. 35505 35506 If this macro is not defined, it defaults to 35507 'DWARF_FRAME_REGISTERS'. 35508 35509 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 35510 35511 Define this macro if the target's representation for dwarf 35512 registers is different than the internal representation for unwind 35513 column. Given a dwarf register, this macro should return the 35514 internal unwind column number to use instead. 35515 35516 -- Macro: DWARF_FRAME_REGNUM (REGNO) 35517 35518 Define this macro if the target's representation for dwarf 35519 registers used in .eh_frame or .debug_frame is different from that 35520 used in other debug info sections. Given a GCC hard register 35521 number, this macro should return the .eh_frame register number. 35522 The default is 'DBX_REGISTER_NUMBER (REGNO)'. 35523 35524 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 35525 35526 Define this macro to map register numbers held in the call frame 35527 info that GCC has collected using 'DWARF_FRAME_REGNUM' to those 35528 that should be output in .debug_frame ('FOR_EH' is zero) and 35529 .eh_frame ('FOR_EH' is nonzero). The default is to return 'REGNO'. 35530 35531 -- Macro: REG_VALUE_IN_UNWIND_CONTEXT 35532 35533 Define this macro if the target stores register values as 35534 '_Unwind_Word' type in unwind context. It should be defined if 35535 target register size is larger than the size of 'void *'. The 35536 default is to store register values as 'void *' type. 35537 35538 -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT 35539 35540 Define this macro to be 1 if the target always uses extended unwind 35541 context with version, args_size and by_value fields. If it is 35542 undefined, it will be defined to 1 when 35543 'REG_VALUE_IN_UNWIND_CONTEXT' is defined and 0 otherwise. 35544 35545 -- Macro: DWARF_LAZY_REGISTER_VALUE (REGNO, VALUE) 35546 Define this macro if the target has pseudo DWARF registers whose 35547 values need to be computed lazily on demand by the unwinder (such 35548 as when referenced in a CFA expression). The macro returns true if 35549 REGNO is such a register and stores its value in '*VALUE' if so. 35550 35551 35552File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 35553 3555418.9.5 Eliminating Frame Pointer and Arg Pointer 35555------------------------------------------------ 35556 35557This is about eliminating the frame pointer and arg pointer. 35558 35559 -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void) 35560 This target hook should return 'true' if a function must have and 35561 use a frame pointer. This target hook is called in the reload 35562 pass. If its return value is 'true' the function will have a frame 35563 pointer. 35564 35565 This target hook can in principle examine the current function and 35566 decide according to the facts, but on most machines the constant 35567 'false' or the constant 'true' suffices. Use 'false' when the 35568 machine allows code to be generated with no frame pointer, and 35569 doing so saves some time or space. Use 'true' when there is no 35570 possible advantage to avoiding a frame pointer. 35571 35572 In certain cases, the compiler does not know how to produce valid 35573 code without a frame pointer. The compiler recognizes those cases 35574 and automatically gives the function a frame pointer regardless of 35575 what 'targetm.frame_pointer_required' returns. You don't need to 35576 worry about them. 35577 35578 In a function that does not require a frame pointer, the frame 35579 pointer register can be allocated for ordinary usage, unless you 35580 mark it as a fixed register. See 'FIXED_REGISTERS' for more 35581 information. 35582 35583 Default return value is 'false'. 35584 35585 -- Macro: ELIMINABLE_REGS 35586 This macro specifies a table of register pairs used to eliminate 35587 unneeded registers that point into the stack frame. 35588 35589 The definition of this macro is a list of structure 35590 initializations, each of which specifies an original and 35591 replacement register. 35592 35593 On some machines, the position of the argument pointer is not known 35594 until the compilation is completed. In such a case, a separate 35595 hard register must be used for the argument pointer. This register 35596 can be eliminated by replacing it with either the frame pointer or 35597 the argument pointer, depending on whether or not the frame pointer 35598 has been eliminated. 35599 35600 In this case, you might specify: 35601 #define ELIMINABLE_REGS \ 35602 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 35603 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 35604 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 35605 35606 Note that the elimination of the argument pointer with the stack 35607 pointer is specified first since that is the preferred elimination. 35608 35609 -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const 35610 int TO_REG) 35611 This target hook should return 'true' if the compiler is allowed to 35612 try to replace register number FROM_REG with register number 35613 TO_REG. This target hook will usually be 'true', since most of the 35614 cases preventing register elimination are things that the compiler 35615 already knows about. 35616 35617 Default return value is 'true'. 35618 35619 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 35620 This macro returns the initial difference between the specified 35621 pair of registers. The value would be computed from information 35622 such as the result of 'get_frame_size ()' and the tables of 35623 registers 'df_regs_ever_live_p' and 'call_used_regs'. 35624 35625 -- Target Hook: void TARGET_COMPUTE_FRAME_LAYOUT (void) 35626 This target hook is called once each time the frame layout needs to 35627 be recalculated. The calculations can be cached by the target and 35628 can then be used by 'INITIAL_ELIMINATION_OFFSET' instead of 35629 re-computing the layout on every invocation of that hook. This is 35630 particularly useful for targets that have an expensive frame layout 35631 function. Implementing this callback is optional. 35632 35633 35634File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 35635 3563618.9.6 Passing Function Arguments on the Stack 35637---------------------------------------------- 35638 35639The macros in this section control how arguments are passed on the 35640stack. See the following section for other macros that control passing 35641certain arguments in registers. 35642 35643 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE) 35644 This target hook returns 'true' if an argument declared in a 35645 prototype as an integral type smaller than 'int' should actually be 35646 passed as an 'int'. In addition to avoiding errors in certain 35647 cases of mismatch, it also makes for better code on certain 35648 machines. The default is to not promote prototypes. 35649 35650 -- Macro: PUSH_ARGS 35651 A C expression. If nonzero, push insns will be used to pass 35652 outgoing arguments. If the target machine does not have a push 35653 instruction, set it to zero. That directs GCC to use an alternate 35654 strategy: to allocate the entire argument block and then store the 35655 arguments into it. When 'PUSH_ARGS' is nonzero, 'PUSH_ROUNDING' 35656 must be defined too. 35657 35658 -- Macro: PUSH_ARGS_REVERSED 35659 A C expression. If nonzero, function arguments will be evaluated 35660 from last to first, rather than from first to last. If this macro 35661 is not defined, it defaults to 'PUSH_ARGS' on targets where the 35662 stack and args grow in opposite directions, and 0 otherwise. 35663 35664 -- Macro: PUSH_ROUNDING (NPUSHED) 35665 A C expression that is the number of bytes actually pushed onto the 35666 stack when an instruction attempts to push NPUSHED bytes. 35667 35668 On some machines, the definition 35669 35670 #define PUSH_ROUNDING(BYTES) (BYTES) 35671 35672 will suffice. But on other machines, instructions that appear to 35673 push one byte actually push two bytes in an attempt to maintain 35674 alignment. Then the definition should be 35675 35676 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 35677 35678 If the value of this macro has a type, it should be an unsigned 35679 type. 35680 35681 -- Macro: ACCUMULATE_OUTGOING_ARGS 35682 A C expression. If nonzero, the maximum amount of space required 35683 for outgoing arguments will be computed and placed into 35684 'crtl->outgoing_args_size'. No space will be pushed onto the stack 35685 for each call; instead, the function prologue should increase the 35686 stack frame size by this amount. 35687 35688 Setting both 'PUSH_ARGS' and 'ACCUMULATE_OUTGOING_ARGS' is not 35689 proper. 35690 35691 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 35692 Define this macro if functions should assume that stack space has 35693 been allocated for arguments even when their values are passed in 35694 registers. 35695 35696 The value of this macro is the size, in bytes, of the area reserved 35697 for arguments passed in registers for the function represented by 35698 FNDECL, which can be zero if GCC is calling a library function. 35699 The argument FNDECL can be the FUNCTION_DECL, or the type itself of 35700 the function. 35701 35702 This space can be allocated by the caller, or be a part of the 35703 machine-dependent stack frame: 'OUTGOING_REG_PARM_STACK_SPACE' says 35704 which. 35705 35706 -- Macro: INCOMING_REG_PARM_STACK_SPACE (FNDECL) 35707 Like 'REG_PARM_STACK_SPACE', but for incoming register arguments. 35708 Define this macro if space guaranteed when compiling a function 35709 body is different to space required when making a call, a situation 35710 that can arise with K&R style function definitions. 35711 35712 -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE) 35713 Define this to a nonzero value if it is the responsibility of the 35714 caller to allocate the area reserved for arguments passed in 35715 registers when calling a function of FNTYPE. FNTYPE may be NULL if 35716 the function called is a library function. 35717 35718 If 'ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 35719 whether the space for these arguments counts in the value of 35720 'crtl->outgoing_args_size'. 35721 35722 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 35723 Define this macro if 'REG_PARM_STACK_SPACE' is defined, but the 35724 stack parameters don't skip the area specified by it. 35725 35726 Normally, when a parameter is not passed in registers, it is placed 35727 on the stack beyond the 'REG_PARM_STACK_SPACE' area. Defining this 35728 macro suppresses this behavior and causes the parameter to be 35729 passed on the stack in its natural location. 35730 35731 -- Target Hook: poly_int64 TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree 35732 FUNTYPE, poly_int64 SIZE) 35733 This target hook returns the number of bytes of its own arguments 35734 that a function pops on returning, or 0 if the function pops no 35735 arguments and the caller must therefore pop them all after the 35736 function returns. 35737 35738 FUNDECL is a C variable whose value is a tree node that describes 35739 the function in question. Normally it is a node of type 35740 'FUNCTION_DECL' that describes the declaration of the function. 35741 From this you can obtain the 'DECL_ATTRIBUTES' of the function. 35742 35743 FUNTYPE is a C variable whose value is a tree node that describes 35744 the function in question. Normally it is a node of type 35745 'FUNCTION_TYPE' that describes the data type of the function. From 35746 this it is possible to obtain the data types of the value and 35747 arguments (if known). 35748 35749 When a call to a library function is being considered, FUNDECL will 35750 contain an identifier node for the library function. Thus, if you 35751 need to distinguish among various library functions, you can do so 35752 by their names. Note that "library function" in this context means 35753 a function used to perform arithmetic, whose name is known 35754 specially in the compiler and was not mentioned in the C code being 35755 compiled. 35756 35757 SIZE is the number of bytes of arguments passed on the stack. If a 35758 variable number of bytes is passed, it is zero, and argument 35759 popping will always be the responsibility of the calling function. 35760 35761 On the VAX, all functions always pop their arguments, so the 35762 definition of this macro is SIZE. On the 68000, using the standard 35763 calling convention, no functions pop their arguments, so the value 35764 of the macro is always 0 in this case. But an alternative calling 35765 convention is available in which functions that take a fixed number 35766 of arguments pop them but other functions (such as 'printf') pop 35767 nothing (the caller pops all). When this convention is in use, 35768 FUNTYPE is examined to determine whether a function takes a fixed 35769 number of arguments. 35770 35771 -- Macro: CALL_POPS_ARGS (CUM) 35772 A C expression that should indicate the number of bytes a call 35773 sequence pops off the stack. It is added to the value of 35774 'RETURN_POPS_ARGS' when compiling a function call. 35775 35776 CUM is the variable in which all arguments to the called function 35777 have been accumulated. 35778 35779 On certain architectures, such as the SH5, a call trampoline is 35780 used that pops certain registers off the stack, depending on the 35781 arguments that have been passed to the function. Since this is a 35782 property of the call site, not of the called function, 35783 'RETURN_POPS_ARGS' is not appropriate. 35784 35785 35786File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 35787 3578818.9.7 Passing Arguments in Registers 35789------------------------------------- 35790 35791This section describes the macros which let you control how various 35792types of arguments are passed in registers or how they are arranged in 35793the stack. 35794 35795 -- Target Hook: rtx TARGET_FUNCTION_ARG (cumulative_args_t CA, const 35796 function_arg_info &ARG) 35797 Return an RTX indicating whether function argument ARG is passed in 35798 a register and if so, which register. Argument CA summarizes all 35799 the previous arguments. 35800 35801 The return value is usually either a 'reg' RTX for the hard 35802 register in which to pass the argument, or zero to pass the 35803 argument on the stack. 35804 35805 The return value can be a 'const_int' which means argument is 35806 passed in a target specific slot with specified number. Target 35807 hooks should be used to store or load argument in such case. See 35808 'TARGET_STORE_BOUNDS_FOR_ARG' and 'TARGET_LOAD_BOUNDS_FOR_ARG' for 35809 more information. 35810 35811 The value of the expression can also be a 'parallel' RTX. This is 35812 used when an argument is passed in multiple locations. The mode of 35813 the 'parallel' should be the mode of the entire argument. The 35814 'parallel' holds any number of 'expr_list' pairs; each one 35815 describes where part of the argument is passed. In each 35816 'expr_list' the first operand must be a 'reg' RTX for the hard 35817 register in which to pass this part of the argument, and the mode 35818 of the register RTX indicates how large this part of the argument 35819 is. The second operand of the 'expr_list' is a 'const_int' which 35820 gives the offset in bytes into the entire argument of where this 35821 part starts. As a special exception the first 'expr_list' in the 35822 'parallel' RTX may have a first operand of zero. This indicates 35823 that the entire argument is also stored on the stack. 35824 35825 The last time this hook is called, it is called with 'MODE == 35826 VOIDmode', and its result is passed to the 'call' or 'call_value' 35827 pattern as operands 2 and 3 respectively. 35828 35829 The usual way to make the ISO library 'stdarg.h' work on a machine 35830 where some arguments are usually passed in registers, is to cause 35831 nameless arguments to be passed on the stack instead. This is done 35832 by making 'TARGET_FUNCTION_ARG' return 0 whenever NAMED is 'false'. 35833 35834 You may use the hook 'targetm.calls.must_pass_in_stack' in the 35835 definition of this macro to determine if this argument is of a type 35836 that must be passed in the stack. If 'REG_PARM_STACK_SPACE' is not 35837 defined and 'TARGET_FUNCTION_ARG' returns nonzero for such an 35838 argument, the compiler will abort. If 'REG_PARM_STACK_SPACE' is 35839 defined, the argument will be computed in the stack and then loaded 35840 into a register. 35841 35842 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (const function_arg_info 35843 &ARG) 35844 This target hook should return 'true' if we should not pass ARG 35845 solely in registers. The file 'expr.h' defines a definition that 35846 is usually appropriate, refer to 'expr.h' for additional 35847 documentation. 35848 35849 -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t CA, 35850 const function_arg_info &ARG) 35851 Define this hook if the caller and callee on the target have 35852 different views of where arguments are passed. Also define this 35853 hook if there are functions that are never directly called, but are 35854 invoked by the hardware and which have nonstandard calling 35855 conventions. 35856 35857 In this case 'TARGET_FUNCTION_ARG' computes the register in which 35858 the caller passes the value, and 'TARGET_FUNCTION_INCOMING_ARG' 35859 should be defined in a similar fashion to tell the function being 35860 called where the arguments will arrive. 35861 35862 'TARGET_FUNCTION_INCOMING_ARG' can also return arbitrary address 35863 computation using hard register, which can be forced into a 35864 register, so that it can be used to pass special arguments. 35865 35866 If 'TARGET_FUNCTION_INCOMING_ARG' is not defined, 35867 'TARGET_FUNCTION_ARG' serves both purposes. 35868 35869 -- Target Hook: bool TARGET_USE_PSEUDO_PIC_REG (void) 35870 This hook should return 1 in case pseudo register should be created 35871 for pic_offset_table_rtx during function expand. 35872 35873 -- Target Hook: void TARGET_INIT_PIC_REG (void) 35874 Perform a target dependent initialization of pic_offset_table_rtx. 35875 This hook is called at the start of register allocation. 35876 35877 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (cumulative_args_t CUM, 35878 const function_arg_info &ARG) 35879 This target hook returns the number of bytes at the beginning of an 35880 argument that must be put in registers. The value must be zero for 35881 arguments that are passed entirely in registers or that are 35882 entirely pushed on the stack. 35883 35884 On some machines, certain arguments must be passed partially in 35885 registers and partially in memory. On these machines, typically 35886 the first few words of arguments are passed in registers, and the 35887 rest on the stack. If a multi-word argument (a 'double' or a 35888 structure) crosses that boundary, its first few words must be 35889 passed in registers and the rest must be pushed. This macro tells 35890 the compiler when this occurs, and how many bytes should go in 35891 registers. 35892 35893 'TARGET_FUNCTION_ARG' for these arguments should return the first 35894 register to be used by the caller for this argument; likewise 35895 'TARGET_FUNCTION_INCOMING_ARG', for the called function. 35896 35897 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM, 35898 const function_arg_info &ARG) 35899 This target hook should return 'true' if argument ARG at the 35900 position indicated by CUM should be passed by reference. This 35901 predicate is queried after target independent reasons for being 35902 passed by reference, such as 'TREE_ADDRESSABLE (ARG.type)'. 35903 35904 If the hook returns true, a copy of that argument is made in memory 35905 and a pointer to the argument is passed instead of the argument 35906 itself. The pointer is passed in whatever way is appropriate for 35907 passing a pointer to that type. 35908 35909 -- Target Hook: bool TARGET_CALLEE_COPIES (cumulative_args_t CUM, const 35910 function_arg_info &ARG) 35911 The function argument described by the parameters to this hook is 35912 known to be passed by reference. The hook should return true if 35913 the function argument should be copied by the callee instead of 35914 copied by the caller. 35915 35916 For any argument for which the hook returns true, if it can be 35917 determined that the argument is not modified, then a copy need not 35918 be generated. 35919 35920 The default version of this hook always returns false. 35921 35922 -- Macro: CUMULATIVE_ARGS 35923 A C type for declaring a variable that is used as the first 35924 argument of 'TARGET_FUNCTION_ARG' and other related values. For 35925 some target machines, the type 'int' suffices and can hold the 35926 number of bytes of argument so far. 35927 35928 There is no need to record in 'CUMULATIVE_ARGS' anything about the 35929 arguments that have been passed on the stack. The compiler has 35930 other variables to keep track of that. For target machines on 35931 which all arguments are passed on the stack, there is no need to 35932 store anything in 'CUMULATIVE_ARGS'; however, the data structure 35933 must exist and should not be empty, so use 'int'. 35934 35935 -- Macro: OVERRIDE_ABI_FORMAT (FNDECL) 35936 If defined, this macro is called before generating any code for a 35937 function, but after the CFUN descriptor for the function has been 35938 created. The back end may use this macro to update CFUN to reflect 35939 an ABI other than that which would normally be used by default. If 35940 the compiler is generating code for a compiler-generated function, 35941 FNDECL may be 'NULL'. 35942 35943 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 35944 N_NAMED_ARGS) 35945 A C statement (sans semicolon) for initializing the variable CUM 35946 for the state at the beginning of the argument list. The variable 35947 has type 'CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 35948 for the data type of the function which will receive the args, or 0 35949 if the args are to a compiler support library function. For direct 35950 calls that are not libcalls, FNDECL contain the declaration node of 35951 the function. FNDECL is also set when 'INIT_CUMULATIVE_ARGS' is 35952 used to find arguments for the function being compiled. 35953 N_NAMED_ARGS is set to the number of named arguments, including a 35954 structure return address if it is passed as a parameter, when 35955 making a call. When processing incoming arguments, N_NAMED_ARGS is 35956 set to -1. 35957 35958 When processing a call to a compiler support library function, 35959 LIBNAME identifies which one. It is a 'symbol_ref' rtx which 35960 contains the name of the function, as a string. LIBNAME is 0 when 35961 an ordinary C function call is being processed. Thus, each time 35962 this macro is called, either LIBNAME or FNTYPE is nonzero, but 35963 never both of them at once. 35964 35965 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 35966 Like 'INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, it 35967 gets a 'MODE' argument instead of FNTYPE, that would be 'NULL'. 35968 INDIRECT would always be zero, too. If this macro is not defined, 35969 'INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead. 35970 35971 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 35972 Like 'INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 35973 finding the arguments for the function being compiled. If this 35974 macro is undefined, 'INIT_CUMULATIVE_ARGS' is used instead. 35975 35976 The value passed for LIBNAME is always 0, since library routines 35977 with special calling conventions are never compiled with GCC. The 35978 argument LIBNAME exists for symmetry with 'INIT_CUMULATIVE_ARGS'. 35979 35980 -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t CA, 35981 const function_arg_info &ARG) 35982 This hook updates the summarizer variable pointed to by CA to 35983 advance past argument ARG in the argument list. Once this is done, 35984 the variable CUM is suitable for analyzing the _following_ argument 35985 with 'TARGET_FUNCTION_ARG', etc. 35986 35987 This hook need not do anything if the argument in question was 35988 passed on the stack. The compiler knows how to track the amount of 35989 stack space used for arguments without any special help. 35990 35991 -- Target Hook: HOST_WIDE_INT TARGET_FUNCTION_ARG_OFFSET (machine_mode 35992 MODE, const_tree TYPE) 35993 This hook returns the number of bytes to add to the offset of an 35994 argument of type TYPE and mode MODE when passed in memory. This is 35995 needed for the SPU, which passes 'char' and 'short' arguments in 35996 the preferred slot that is in the middle of the quad word instead 35997 of starting at the top. The default implementation returns 0. 35998 35999 -- Target Hook: pad_direction TARGET_FUNCTION_ARG_PADDING (machine_mode 36000 MODE, const_tree TYPE) 36001 This hook determines whether, and in which direction, to pad out an 36002 argument of mode MODE and type TYPE. It returns 'PAD_UPWARD' to 36003 insert padding above the argument, 'PAD_DOWNWARD' to insert padding 36004 below the argument, or 'PAD_NONE' to inhibit padding. 36005 36006 The _amount_ of padding is not controlled by this hook, but by 36007 'TARGET_FUNCTION_ARG_ROUND_BOUNDARY'. It is always just enough to 36008 reach the next multiple of that boundary. 36009 36010 This hook has a default definition that is right for most systems. 36011 For little-endian machines, the default is to pad upward. For 36012 big-endian machines, the default is to pad downward for an argument 36013 of constant size shorter than an 'int', and upward otherwise. 36014 36015 -- Macro: PAD_VARARGS_DOWN 36016 If defined, a C expression which determines whether the default 36017 implementation of va_arg will attempt to pad down before reading 36018 the next argument, if that argument is smaller than its aligned 36019 space as controlled by 'PARM_BOUNDARY'. If this macro is not 36020 defined, all such arguments are padded down if 'BYTES_BIG_ENDIAN' 36021 is true. 36022 36023 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 36024 Specify padding for the last element of a block move between 36025 registers and memory. FIRST is nonzero if this is the only 36026 element. Defining this macro allows better control of register 36027 function parameters on big-endian machines, without using 36028 'PARALLEL' rtl. In particular, 'MUST_PASS_IN_STACK' need not test 36029 padding and mode of types in registers, as there is no longer a 36030 "wrong" part of a register; For example, a three byte aggregate may 36031 be passed in the high part of a register if so required. 36032 36033 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY (machine_mode 36034 MODE, const_tree TYPE) 36035 This hook returns the alignment boundary, in bits, of an argument 36036 with the specified mode and type. The default hook returns 36037 'PARM_BOUNDARY' for all arguments. 36038 36039 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY 36040 (machine_mode MODE, const_tree TYPE) 36041 Normally, the size of an argument is rounded up to 'PARM_BOUNDARY', 36042 which is the default value for this hook. You can define this hook 36043 to return a different value if an argument size must be rounded to 36044 a larger value. 36045 36046 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 36047 A C expression that is nonzero if REGNO is the number of a hard 36048 register in which function arguments are sometimes passed. This 36049 does _not_ include implicit arguments such as the static chain and 36050 the structure-value address. On many machines, no registers can be 36051 used for this purpose since all function arguments are pushed on 36052 the stack. 36053 36054 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE) 36055 This hook should return true if parameter of type TYPE are passed 36056 as two scalar parameters. By default, GCC will attempt to pack 36057 complex arguments into the target's word size. Some ABIs require 36058 complex arguments to be split and treated as their individual 36059 components. For example, on AIX64, complex floats should be passed 36060 in a pair of floating point registers, even though a complex float 36061 would fit in one 64-bit floating point register. 36062 36063 The default value of this hook is 'NULL', which is treated as 36064 always false. 36065 36066 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 36067 This hook returns a type node for 'va_list' for the target. The 36068 default version of the hook returns 'void*'. 36069 36070 -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char **PNAME, 36071 tree *PTREE) 36072 This target hook is used in function 'c_common_nodes_and_builtins' 36073 to iterate through the target specific builtin types for va_list. 36074 The variable IDX is used as iterator. PNAME has to be a pointer to 36075 a 'const char *' and PTREE a pointer to a 'tree' typed variable. 36076 The arguments PNAME and PTREE are used to store the result of this 36077 macro and are set to the name of the va_list builtin type and its 36078 internal type. If the return value of this macro is zero, then 36079 there is no more element. Otherwise the IDX should be increased 36080 for the next call of this macro to iterate through all types. 36081 36082 -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL) 36083 This hook returns the va_list type of the calling convention 36084 specified by FNDECL. The default version of this hook returns 36085 'va_list_type_node'. 36086 36087 -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE) 36088 This hook returns the va_list type of the calling convention 36089 specified by the type of TYPE. If TYPE is not a valid va_list 36090 type, it returns 'NULL_TREE'. 36091 36092 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 36093 TYPE, gimple_seq *PRE_P, gimple_seq *POST_P) 36094 This hook performs target-specific gimplification of 'VA_ARG_EXPR'. 36095 The first two parameters correspond to the arguments to 'va_arg'; 36096 the latter two are as in 'gimplify.c:gimplify_expr'. 36097 36098 -- Target Hook: bool TARGET_VALID_POINTER_MODE (scalar_int_mode MODE) 36099 Define this to return nonzero if the port can handle pointers with 36100 machine mode MODE. The default version of this hook returns true 36101 for both 'ptr_mode' and 'Pmode'. 36102 36103 -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (ao_ref *REF) 36104 Define this to return nonzero if the memory reference REF may alias 36105 with the system C library errno location. The default version of 36106 this hook assumes the system C library errno location is either a 36107 declaration of type int or accessed by dereferencing a pointer to 36108 int. 36109 36110 -- Target Hook: machine_mode TARGET_TRANSLATE_MODE_ATTRIBUTE 36111 (machine_mode MODE) 36112 Define this hook if during mode attribute processing, the port 36113 should translate machine_mode MODE to another mode. For example, 36114 rs6000's 'KFmode', when it is the same as 'TFmode'. 36115 36116 The default version of the hook returns that mode that was passed 36117 in. 36118 36119 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (scalar_mode MODE) 36120 Define this to return nonzero if the port is prepared to handle 36121 insns involving scalar mode MODE. For a scalar mode to be 36122 considered supported, all the basic arithmetic and comparisons must 36123 work. 36124 36125 The default version of this hook returns true for any mode required 36126 to handle the basic C types (as defined by the port). Included 36127 here are the double-word arithmetic supported by the code in 36128 'optabs.c'. 36129 36130 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE) 36131 Define this to return nonzero if the port is prepared to handle 36132 insns involving vector mode MODE. At the very least, it must have 36133 move patterns for this mode. 36134 36135 -- Target Hook: bool TARGET_COMPATIBLE_VECTOR_TYPES_P (const_tree 36136 TYPE1, const_tree TYPE2) 36137 Return true if there is no target-specific reason for treating 36138 vector types TYPE1 and TYPE2 as distinct types. The caller has 36139 already checked for target-independent reasons, meaning that the 36140 types are known to have the same mode, to have the same number of 36141 elements, and to have what the caller considers to be compatible 36142 element types. 36143 36144 The main reason for defining this hook is to reject pairs of types 36145 that are handled differently by the target's calling convention. 36146 For example, when a new N-bit vector architecture is added to a 36147 target, the target may want to handle normal N-bit 'VECTOR_TYPE' 36148 arguments and return values in the same way as before, to maintain 36149 backwards compatibility. However, it may also provide new, 36150 architecture-specific 'VECTOR_TYPE's that are passed and returned 36151 in a more efficient way. It is then important to maintain a 36152 distinction between the "normal" 'VECTOR_TYPE's and the new 36153 architecture-specific ones. 36154 36155 The default implementation returns true, which is correct for most 36156 targets. 36157 36158 -- Target Hook: opt_machine_mode TARGET_ARRAY_MODE (machine_mode MODE, 36159 unsigned HOST_WIDE_INT NELEMS) 36160 Return the mode that GCC should use for an array that has NELEMS 36161 elements, with each element having mode MODE. Return no mode if 36162 the target has no special requirements. In the latter case, GCC 36163 looks for an integer mode of the appropriate size if available and 36164 uses BLKmode otherwise. Usually the search for the integer mode is 36165 limited to 'MAX_FIXED_MODE_SIZE', but the 36166 'TARGET_ARRAY_MODE_SUPPORTED_P' hook allows a larger mode to be 36167 used in specific cases. 36168 36169 The main use of this hook is to specify that an array of vectors 36170 should also have a vector mode. The default implementation returns 36171 no mode. 36172 36173 -- Target Hook: bool TARGET_ARRAY_MODE_SUPPORTED_P (machine_mode MODE, 36174 unsigned HOST_WIDE_INT NELEMS) 36175 Return true if GCC should try to use a scalar mode to store an 36176 array of NELEMS elements, given that each element has mode MODE. 36177 Returning true here overrides the usual 'MAX_FIXED_MODE' limit and 36178 allows GCC to use any defined integer mode. 36179 36180 One use of this hook is to support vector load and store operations 36181 that operate on several homogeneous vectors. For example, ARM NEON 36182 has operations like: 36183 36184 int8x8x3_t vld3_s8 (const int8_t *) 36185 36186 where the return type is defined as: 36187 36188 typedef struct int8x8x3_t 36189 { 36190 int8x8_t val[3]; 36191 } int8x8x3_t; 36192 36193 If this hook allows 'val' to have a scalar mode, then 'int8x8x3_t' 36194 can have the same mode. GCC can then store 'int8x8x3_t's in 36195 registers rather than forcing them onto the stack. 36196 36197 -- Target Hook: bool TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 36198 (scalar_float_mode MODE) 36199 Define this to return nonzero if libgcc provides support for the 36200 floating-point mode MODE, which is known to pass 36201 'TARGET_SCALAR_MODE_SUPPORTED_P'. The default version of this hook 36202 returns true for all of 'SFmode', 'DFmode', 'XFmode' and 'TFmode', 36203 if such modes exist. 36204 36205 -- Target Hook: opt_scalar_float_mode TARGET_FLOATN_MODE (int N, bool 36206 EXTENDED) 36207 Define this to return the machine mode to use for the type 36208 '_FloatN', if EXTENDED is false, or the type '_FloatNx', if 36209 EXTENDED is true. If such a type is not supported, return 36210 'opt_scalar_float_mode ()'. The default version of this hook 36211 returns 'SFmode' for '_Float32', 'DFmode' for '_Float64' and 36212 '_Float32x' and 'TFmode' for '_Float128', if those modes exist and 36213 satisfy the requirements for those types and pass 36214 'TARGET_SCALAR_MODE_SUPPORTED_P' and 36215 'TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P'; for '_Float64x', it 36216 returns the first of 'XFmode' and 'TFmode' that exists and 36217 satisfies the same requirements; for other types, it returns 36218 'opt_scalar_float_mode ()'. The hook is only called for values of 36219 N and EXTENDED that are valid according to ISO/IEC TS 18661-3:2015; 36220 that is, N is one of 32, 64, 128, or, if EXTENDED is false, 16 or 36221 greater than 128 and a multiple of 32. 36222 36223 -- Target Hook: bool TARGET_FLOATN_BUILTIN_P (int FUNC) 36224 Define this to return true if the '_FloatN' and '_FloatNx' built-in 36225 functions should implicitly enable the built-in function without 36226 the '__builtin_' prefix in addition to the normal built-in function 36227 with the '__builtin_' prefix. The default is to only enable 36228 built-in functions without the '__builtin_' prefix for the GNU C 36229 langauge. In strict ANSI/ISO mode, the built-in function without 36230 the '__builtin_' prefix is not enabled. The argument 'FUNC' is the 36231 'enum built_in_function' id of the function to be enabled. 36232 36233 -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P 36234 (machine_mode MODE) 36235 Define this to return nonzero for machine modes for which the port 36236 has small register classes. If this target hook returns nonzero 36237 for a given MODE, the compiler will try to minimize the lifetime of 36238 registers in MODE. The hook may be called with 'VOIDmode' as 36239 argument. In this case, the hook is expected to return nonzero if 36240 it returns nonzero for any mode. 36241 36242 On some machines, it is risky to let hard registers live across 36243 arbitrary insns. Typically, these machines have instructions that 36244 require values to be in specific registers (like an accumulator), 36245 and reload will fail if the required hard register is used for 36246 another purpose across such an insn. 36247 36248 Passes before reload do not know which hard registers will be used 36249 in an instruction, but the machine modes of the registers set or 36250 used in the instruction are already known. And for some machines, 36251 register classes are small for, say, integer registers but not for 36252 floating point registers. For example, the AMD x86-64 architecture 36253 requires specific registers for the legacy x86 integer 36254 instructions, but there are many SSE registers for floating point 36255 operations. On such targets, a good strategy may be to return 36256 nonzero from this hook for 'INTEGRAL_MODE_P' machine modes but zero 36257 for the SSE register classes. 36258 36259 The default version of this hook returns false for any mode. It is 36260 always safe to redefine this hook to return with a nonzero value. 36261 But if you unnecessarily define it, you will reduce the amount of 36262 optimizations that can be performed in some cases. If you do not 36263 define this hook to return a nonzero value when it is required, the 36264 compiler will run out of spill registers and print a fatal error 36265 message. 36266 36267 36268File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 36269 3627018.9.8 How Scalar Function Values Are Returned 36271---------------------------------------------- 36272 36273This section discusses the macros that control returning scalars as 36274values--values that can fit in registers. 36275 36276 -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE, 36277 const_tree FN_DECL_OR_TYPE, bool OUTGOING) 36278 36279 Define this to return an RTX representing the place where a 36280 function returns or receives a value of data type RET_TYPE, a tree 36281 node representing a data type. FN_DECL_OR_TYPE is a tree node 36282 representing 'FUNCTION_DECL' or 'FUNCTION_TYPE' of a function being 36283 called. If OUTGOING is false, the hook should compute the register 36284 in which the caller will see the return value. Otherwise, the hook 36285 should return an RTX representing the place where a function 36286 returns a value. 36287 36288 On many machines, only 'TYPE_MODE (RET_TYPE)' is relevant. 36289 (Actually, on most machines, scalar values are returned in the same 36290 place regardless of mode.) The value of the expression is usually 36291 a 'reg' RTX for the hard register where the return value is stored. 36292 The value can also be a 'parallel' RTX, if the return value is in 36293 multiple places. See 'TARGET_FUNCTION_ARG' for an explanation of 36294 the 'parallel' form. Note that the callee will populate every 36295 location specified in the 'parallel', but if the first element of 36296 the 'parallel' contains the whole return value, callers will use 36297 that element as the canonical location and ignore the others. The 36298 m68k port uses this type of 'parallel' to return pointers in both 36299 '%a0' (the canonical location) and '%d0'. 36300 36301 If 'TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 36302 the same promotion rules specified in 'PROMOTE_MODE' if VALTYPE is 36303 a scalar type. 36304 36305 If the precise function being called is known, FUNC is a tree node 36306 ('FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 36307 makes it possible to use a different value-returning convention for 36308 specific functions when all their calls are known. 36309 36310 Some target machines have "register windows" so that the register 36311 in which a function returns its value is not the same as the one in 36312 which the caller sees the value. For such machines, you should 36313 return different RTX depending on OUTGOING. 36314 36315 'TARGET_FUNCTION_VALUE' is not used for return values with 36316 aggregate data types, because these are returned in another way. 36317 See 'TARGET_STRUCT_VALUE_RTX' and related macros, below. 36318 36319 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 36320 This macro has been deprecated. Use 'TARGET_FUNCTION_VALUE' for a 36321 new target instead. 36322 36323 -- Macro: LIBCALL_VALUE (MODE) 36324 A C expression to create an RTX representing the place where a 36325 library function returns a value of mode MODE. 36326 36327 Note that "library function" in this context means a compiler 36328 support routine, used to perform arithmetic, whose name is known 36329 specially by the compiler and was not mentioned in the C code being 36330 compiled. 36331 36332 -- Target Hook: rtx TARGET_LIBCALL_VALUE (machine_mode MODE, const_rtx 36333 FUN) 36334 Define this hook if the back-end needs to know the name of the 36335 libcall function in order to determine where the result should be 36336 returned. 36337 36338 The mode of the result is given by MODE and the name of the called 36339 library function is given by FUN. The hook should return an RTX 36340 representing the place where the library function result will be 36341 returned. 36342 36343 If this hook is not defined, then LIBCALL_VALUE will be used. 36344 36345 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 36346 A C expression that is nonzero if REGNO is the number of a hard 36347 register in which the values of called function may come back. 36348 36349 A register whose use for returning values is limited to serving as 36350 the second of a pair (for a value of type 'double', say) need not 36351 be recognized by this macro. So for most machines, this definition 36352 suffices: 36353 36354 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 36355 36356 If the machine has register windows, so that the caller and the 36357 called function use different registers for the return value, this 36358 macro should recognize only the caller's register numbers. 36359 36360 This macro has been deprecated. Use 36361 'TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead. 36362 36363 -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int 36364 REGNO) 36365 A target hook that return 'true' if REGNO is the number of a hard 36366 register in which the values of called function may come back. 36367 36368 A register whose use for returning values is limited to serving as 36369 the second of a pair (for a value of type 'double', say) need not 36370 be recognized by this target hook. 36371 36372 If the machine has register windows, so that the caller and the 36373 called function use different registers for the return value, this 36374 target hook should recognize only the caller's register numbers. 36375 36376 If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be 36377 used. 36378 36379 -- Macro: APPLY_RESULT_SIZE 36380 Define this macro if 'untyped_call' and 'untyped_return' need more 36381 space than is implied by 'FUNCTION_VALUE_REGNO_P' for saving and 36382 restoring an arbitrary return value. 36383 36384 -- Target Hook: bool TARGET_OMIT_STRUCT_RETURN_REG 36385 Normally, when a function returns a structure by memory, the 36386 address is passed as an invisible pointer argument, but the 36387 compiler also arranges to return the address from the function like 36388 it would a normal pointer return value. Define this to true if 36389 that behavior is undesirable on your target. 36390 36391 -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE) 36392 This hook should return true if values of type TYPE are returned at 36393 the most significant end of a register (in other words, if they are 36394 padded at the least significant end). You can assume that TYPE is 36395 returned in a register; the caller is required to check this. 36396 36397 Note that the register provided by 'TARGET_FUNCTION_VALUE' must be 36398 able to hold the complete return value. For example, if a 1-, 2- 36399 or 3-byte structure is returned at the most significant end of a 36400 4-byte register, 'TARGET_FUNCTION_VALUE' should provide an 'SImode' 36401 rtx. 36402 36403 36404File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 36405 3640618.9.9 How Large Values Are Returned 36407------------------------------------ 36408 36409When a function value's mode is 'BLKmode' (and in some other cases), the 36410value is not returned according to 'TARGET_FUNCTION_VALUE' (*note Scalar 36411Return::). Instead, the caller passes the address of a block of memory 36412in which the value should be stored. This address is called the 36413"structure value address". 36414 36415 This section describes how to control returning structure values in 36416memory. 36417 36418 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE, 36419 const_tree FNTYPE) 36420 This target hook should return a nonzero value to say to return the 36421 function value in memory, just as large structures are always 36422 returned. Here TYPE will be the data type of the value, and FNTYPE 36423 will be the type of the function doing the returning, or 'NULL' for 36424 libcalls. 36425 36426 Note that values of mode 'BLKmode' must be explicitly handled by 36427 this function. Also, the option '-fpcc-struct-return' takes effect 36428 regardless of this macro. On most systems, it is possible to leave 36429 the hook undefined; this causes a default definition to be used, 36430 whose value is the constant 1 for 'BLKmode' values, and 0 36431 otherwise. 36432 36433 Do not use this hook to indicate that structures and unions should 36434 always be returned in memory. You should instead use 36435 'DEFAULT_PCC_STRUCT_RETURN' to indicate this. 36436 36437 -- Macro: DEFAULT_PCC_STRUCT_RETURN 36438 Define this macro to be 1 if all structure and union return values 36439 must be in memory. Since this results in slower code, this should 36440 be defined only if needed for compatibility with other compilers or 36441 with an ABI. If you define this macro to be 0, then the 36442 conventions used for structure and union return values are decided 36443 by the 'TARGET_RETURN_IN_MEMORY' target hook. 36444 36445 If not defined, this defaults to the value 1. 36446 36447 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 36448 This target hook should return the location of the structure value 36449 address (normally a 'mem' or 'reg'), or 0 if the address is passed 36450 as an "invisible" first argument. Note that FNDECL may be 'NULL', 36451 for libcalls. You do not need to define this target hook if the 36452 address is always passed as an "invisible" first argument. 36453 36454 On some architectures the place where the structure value address 36455 is found by the called function is not the same place that the 36456 caller put it. This can be due to register windows, or it could be 36457 because the function prologue moves it to a different place. 36458 INCOMING is '1' or '2' when the location is needed in the context 36459 of the called function, and '0' in the context of the caller. 36460 36461 If INCOMING is nonzero and the address is to be found on the stack, 36462 return a 'mem' which refers to the frame pointer. If INCOMING is 36463 '2', the result is being used to fetch the structure value address 36464 at the beginning of a function. If you need to emit adjusting 36465 code, you should do it at this point. 36466 36467 -- Macro: PCC_STATIC_STRUCT_RETURN 36468 Define this macro if the usual system convention on the target 36469 machine for returning structures and unions is for the called 36470 function to return the address of a static variable containing the 36471 value. 36472 36473 Do not define this if the usual system convention is for the caller 36474 to pass an address to the subroutine. 36475 36476 This macro has effect in '-fpcc-struct-return' mode, but it does 36477 nothing when you use '-freg-struct-return' mode. 36478 36479 -- Target Hook: fixed_size_mode TARGET_GET_RAW_RESULT_MODE (int REGNO) 36480 This target hook returns the mode to be used when accessing raw 36481 return registers in '__builtin_return'. Define this macro if the 36482 value in REG_RAW_MODE is not correct. 36483 36484 -- Target Hook: fixed_size_mode TARGET_GET_RAW_ARG_MODE (int REGNO) 36485 This target hook returns the mode to be used when accessing raw 36486 argument registers in '__builtin_apply_args'. Define this macro if 36487 the value in REG_RAW_MODE is not correct. 36488 36489 -- Target Hook: bool TARGET_EMPTY_RECORD_P (const_tree TYPE) 36490 This target hook returns true if the type is an empty record. The 36491 default is to return 'false'. 36492 36493 -- Target Hook: void TARGET_WARN_PARAMETER_PASSING_ABI 36494 (cumulative_args_t CA, tree TYPE) 36495 This target hook warns about the change in empty class parameter 36496 passing ABI. 36497 36498 36499File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 36500 3650118.9.10 Caller-Saves Register Allocation 36502---------------------------------------- 36503 36504If you enable it, GCC can save registers around function calls. This 36505makes it possible to use call-clobbered registers to hold variables that 36506must live across calls. 36507 36508 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 36509 A C expression specifying which mode is required for saving NREGS 36510 of a pseudo-register in call-clobbered hard register REGNO. If 36511 REGNO is unsuitable for caller save, 'VOIDmode' should be returned. 36512 For most machines this macro need not be defined since GCC will 36513 select the smallest suitable mode. 36514 36515 36516File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 36517 3651818.9.11 Function Entry and Exit 36519------------------------------- 36520 36521This section describes the macros that output function entry 36522("prologue") and exit ("epilogue") code. 36523 36524 -- Target Hook: void TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY (FILE 36525 *FILE, unsigned HOST_WIDE_INT PATCH_AREA_SIZE, bool RECORD_P) 36526 Generate a patchable area at the function start, consisting of 36527 PATCH_AREA_SIZE NOP instructions. If the target supports named 36528 sections and if RECORD_P is true, insert a pointer to the current 36529 location in the table of patchable functions. The default 36530 implementation of the hook places the table of pointers in the 36531 special section named '__patchable_function_entries'. 36532 36533 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE) 36534 If defined, a function that outputs the assembler code for entry to 36535 a function. The prologue is responsible for setting up the stack 36536 frame, initializing the frame pointer register, saving registers 36537 that must be saved, and allocating SIZE additional bytes of storage 36538 for the local variables. FILE is a stdio stream to which the 36539 assembler code should be output. 36540 36541 The label for the beginning of the function need not be output by 36542 this macro. That has already been done when the macro is run. 36543 36544 To determine which registers to save, the macro can refer to the 36545 array 'regs_ever_live': element R is nonzero if hard register R is 36546 used anywhere within the function. This implies the function 36547 prologue should save register R, provided it is not one of the 36548 call-used registers. ('TARGET_ASM_FUNCTION_EPILOGUE' must likewise 36549 use 'regs_ever_live'.) 36550 36551 On machines that have "register windows", the function entry code 36552 does not save on the stack the registers that are in the windows, 36553 even if they are supposed to be preserved by function calls; 36554 instead it takes appropriate steps to "push" the register stack, if 36555 any non-call-used registers are used in the function. 36556 36557 On machines where functions may or may not have frame-pointers, the 36558 function entry code must vary accordingly; it must set up the frame 36559 pointer if one is wanted, and not otherwise. To determine whether 36560 a frame pointer is in wanted, the macro can refer to the variable 36561 'frame_pointer_needed'. The variable's value will be 1 at run time 36562 in a function that needs a frame pointer. *Note Elimination::. 36563 36564 The function entry code is responsible for allocating any stack 36565 space required for the function. This stack space consists of the 36566 regions listed below. In most cases, these regions are allocated 36567 in the order listed, with the last listed region closest to the top 36568 of the stack (the lowest address if 'STACK_GROWS_DOWNWARD' is 36569 defined, and the highest address if it is not defined). You can 36570 use a different order for a machine if doing so is more convenient 36571 or required for compatibility reasons. Except in cases where 36572 required by standard or by a debugger, there is no reason why the 36573 stack layout used by GCC need agree with that used by other 36574 compilers for a machine. 36575 36576 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 36577 If defined, a function that outputs assembler code at the end of a 36578 prologue. This should be used when the function prologue is being 36579 emitted as RTL, and you have some extra assembler that needs to be 36580 emitted. *Note prologue instruction pattern::. 36581 36582 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 36583 If defined, a function that outputs assembler code at the start of 36584 an epilogue. This should be used when the function epilogue is 36585 being emitted as RTL, and you have some extra assembler that needs 36586 to be emitted. *Note epilogue instruction pattern::. 36587 36588 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE) 36589 If defined, a function that outputs the assembler code for exit 36590 from a function. The epilogue is responsible for restoring the 36591 saved registers and stack pointer to their values when the function 36592 was called, and returning control to the caller. This macro takes 36593 the same argument as the macro 'TARGET_ASM_FUNCTION_PROLOGUE', and 36594 the registers to restore are determined from 'regs_ever_live' and 36595 'CALL_USED_REGISTERS' in the same way. 36596 36597 On some machines, there is a single instruction that does all the 36598 work of returning from the function. On these machines, give that 36599 instruction the name 'return' and do not define the macro 36600 'TARGET_ASM_FUNCTION_EPILOGUE' at all. 36601 36602 Do not define a pattern named 'return' if you want the 36603 'TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 36604 switches to control whether return instructions or epilogues are 36605 used, define a 'return' pattern with a validity condition that 36606 tests the target switches appropriately. If the 'return' pattern's 36607 validity condition is false, epilogues will be used. 36608 36609 On machines where functions may or may not have frame-pointers, the 36610 function exit code must vary accordingly. Sometimes the code for 36611 these two cases is completely different. To determine whether a 36612 frame pointer is wanted, the macro can refer to the variable 36613 'frame_pointer_needed'. The variable's value will be 1 when 36614 compiling a function that needs a frame pointer. 36615 36616 Normally, 'TARGET_ASM_FUNCTION_PROLOGUE' and 36617 'TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 36618 The C variable 'current_function_is_leaf' is nonzero for such a 36619 function. *Note Leaf Functions::. 36620 36621 On some machines, some functions pop their arguments on exit while 36622 others leave that for the caller to do. For example, the 68020 36623 when given '-mrtd' pops arguments in functions that take a fixed 36624 number of arguments. 36625 36626 Your definition of the macro 'RETURN_POPS_ARGS' decides which 36627 functions pop their own arguments. 'TARGET_ASM_FUNCTION_EPILOGUE' 36628 needs to know what was decided. The number of bytes of the current 36629 function's arguments that this function should pop is available in 36630 'crtl->args.pops_args'. *Note Scalar Return::. 36631 36632 * A region of 'crtl->args.pretend_args_size' bytes of uninitialized 36633 space just underneath the first argument arriving on the stack. 36634 (This may not be at the very start of the allocated stack region if 36635 the calling sequence has pushed anything else since pushing the 36636 stack arguments. But usually, on such machines, nothing else has 36637 been pushed yet, because the function prologue itself does all the 36638 pushing.) This region is used on machines where an argument may be 36639 passed partly in registers and partly in memory, and, in some cases 36640 to support the features in '<stdarg.h>'. 36641 36642 * An area of memory used to save certain registers used by the 36643 function. The size of this area, which may also include space for 36644 such things as the return address and pointers to previous stack 36645 frames, is machine-specific and usually depends on which registers 36646 have been used in the function. Machines with register windows 36647 often do not require a save area. 36648 36649 * A region of at least SIZE bytes, possibly rounded up to an 36650 allocation boundary, to contain the local variables of the 36651 function. On some machines, this region and the save area may 36652 occur in the opposite order, with the save area closer to the top 36653 of the stack. 36654 36655 * Optionally, when 'ACCUMULATE_OUTGOING_ARGS' is defined, a region of 36656 'crtl->outgoing_args_size' bytes to be used for outgoing argument 36657 lists of the function. *Note Stack Arguments::. 36658 36659 -- Macro: EXIT_IGNORE_STACK 36660 Define this macro as a C expression that is nonzero if the return 36661 instruction or the function epilogue ignores the value of the stack 36662 pointer; in other words, if it is safe to delete an instruction to 36663 adjust the stack pointer before a return from the function. The 36664 default is 0. 36665 36666 Note that this macro's value is relevant only for functions for 36667 which frame pointers are maintained. It is never safe to delete a 36668 final stack adjustment in a function that has no frame pointer, and 36669 the compiler knows this regardless of 'EXIT_IGNORE_STACK'. 36670 36671 -- Macro: EPILOGUE_USES (REGNO) 36672 Define this macro as a C expression that is nonzero for registers 36673 that are used by the epilogue or the 'return' pattern. The stack 36674 and frame pointer registers are already assumed to be used as 36675 needed. 36676 36677 -- Macro: EH_USES (REGNO) 36678 Define this macro as a C expression that is nonzero for registers 36679 that are used by the exception handling mechanism, and so should be 36680 considered live on entry to an exception edge. 36681 36682 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 36683 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 36684 tree FUNCTION) 36685 A function that outputs the assembler code for a thunk function, 36686 used to implement C++ virtual function calls with multiple 36687 inheritance. The thunk acts as a wrapper around a virtual 36688 function, adjusting the implicit object parameter before handing 36689 control off to the real function. 36690 36691 First, emit code to add the integer DELTA to the location that 36692 contains the incoming first argument. Assume that this argument 36693 contains a pointer, and is the one used to pass the 'this' pointer 36694 in C++. This is the incoming argument _before_ the function 36695 prologue, e.g. '%o0' on a sparc. The addition must preserve the 36696 values of all other incoming arguments. 36697 36698 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 36699 be made after adding 'delta'. In particular, if P is the adjusted 36700 pointer, the following adjustment should be made: 36701 36702 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 36703 36704 After the additions, emit code to jump to FUNCTION, which is a 36705 'FUNCTION_DECL'. This is a direct pure jump, not a call, and does 36706 not touch the return address. Hence returning from FUNCTION will 36707 return to whoever called the current 'thunk'. 36708 36709 The effect must be as if FUNCTION had been called directly with the 36710 adjusted first argument. This macro is responsible for emitting 36711 all of the code for a thunk function; 36712 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' 36713 are not invoked. 36714 36715 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 36716 been extracted from it.) It might possibly be useful on some 36717 targets, but probably not. 36718 36719 If you do not define this macro, the target-independent code in the 36720 C++ front end will generate a less efficient heavyweight thunk that 36721 calls FUNCTION instead of jumping to it. The generic approach does 36722 not support varargs. 36723 36724 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree 36725 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 36726 const_tree FUNCTION) 36727 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would be 36728 able to output the assembler code for the thunk function specified 36729 by the arguments it is passed, and false otherwise. In the latter 36730 case, the generic approach will be used by the C++ front end, with 36731 the limitations previously exposed. 36732 36733 36734File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 36735 3673618.9.12 Generating Code for Profiling 36737------------------------------------- 36738 36739These macros will help you generate code for profiling. 36740 36741 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 36742 A C statement or compound statement to output to FILE some 36743 assembler code to call the profiling subroutine 'mcount'. 36744 36745 The details of how 'mcount' expects to be called are determined by 36746 your operating system environment, not by GCC. To figure them out, 36747 compile a small program for profiling using the system's installed 36748 C compiler and look at the assembler code that results. 36749 36750 Older implementations of 'mcount' expect the address of a counter 36751 variable to be loaded into some register. The name of this 36752 variable is 'LP' followed by the number LABELNO, so you would 36753 generate the name using 'LP%d' in a 'fprintf'. 36754 36755 -- Macro: PROFILE_HOOK 36756 A C statement or compound statement to output to FILE some assembly 36757 code to call the profiling subroutine 'mcount' even the target does 36758 not support profiling. 36759 36760 -- Macro: NO_PROFILE_COUNTERS 36761 Define this macro to be an expression with a nonzero value if the 36762 'mcount' subroutine on your system does not need a counter variable 36763 allocated for each function. This is true for almost all modern 36764 implementations. If you define this macro, you must not use the 36765 LABELNO argument to 'FUNCTION_PROFILER'. 36766 36767 -- Macro: PROFILE_BEFORE_PROLOGUE 36768 Define this macro if the code for function profiling should come 36769 before the function prologue. Normally, the profiling code comes 36770 after. 36771 36772 -- Target Hook: bool TARGET_KEEP_LEAF_WHEN_PROFILED (void) 36773 This target hook returns true if the target wants the leaf flag for 36774 the current function to stay true even if it calls mcount. This 36775 might make sense for targets using the leaf flag only to determine 36776 whether a stack frame needs to be generated or not and for which 36777 the call to mcount is generated before the function prologue. 36778 36779 36780File: gccint.info, Node: Tail Calls, Next: Shrink-wrapping separate components, Prev: Profiling, Up: Stack and Calling 36781 3678218.9.13 Permitting tail calls 36783----------------------------- 36784 36785 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 36786 EXP) 36787 True if it is OK to do sibling call optimization for the specified 36788 call expression EXP. DECL will be the called function, or 'NULL' 36789 if this is an indirect call. 36790 36791 It is not uncommon for limitations of calling conventions to 36792 prevent tail calls to functions outside the current unit of 36793 translation, or during PIC compilation. The hook is used to 36794 enforce these restrictions, as the 'sibcall' md pattern cannot 36795 fail, or fall over to a "normal" call. The criteria for successful 36796 sibling call optimization may vary greatly between different 36797 architectures. 36798 36799 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS) 36800 Add any hard registers to REGS that are live on entry to the 36801 function. This hook only needs to be defined to provide registers 36802 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 36803 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 36804 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, FRAME_POINTER_REGNUM, 36805 EH_USES, FRAME_POINTER_REGNUM, ARG_POINTER_REGNUM, and the 36806 PIC_OFFSET_TABLE_REGNUM. 36807 36808 -- Target Hook: void TARGET_SET_UP_BY_PROLOGUE (struct 36809 hard_reg_set_container *) 36810 This hook should add additional registers that are computed by the 36811 prologue to the hard regset for shrink-wrapping optimization 36812 purposes. 36813 36814 -- Target Hook: bool TARGET_WARN_FUNC_RETURN (tree) 36815 True if a function's return statements should be checked for 36816 matching the function's return type. This includes checking for 36817 falling off the end of a non-void function. Return false if no 36818 such check should be made. 36819 36820 36821File: gccint.info, Node: Shrink-wrapping separate components, Next: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling 36822 3682318.9.14 Shrink-wrapping separate components 36824------------------------------------------- 36825 36826The prologue may perform a variety of target dependent tasks such as 36827saving callee-saved registers, saving the return address, aligning the 36828stack, creating a stack frame, initializing the PIC register, setting up 36829the static chain, etc. 36830 36831 On some targets some of these tasks may be independent of others and 36832thus may be shrink-wrapped separately. These independent tasks are 36833referred to as components and are handled generically by the target 36834independent parts of GCC. 36835 36836 Using the following hooks those prologue or epilogue components can be 36837shrink-wrapped separately, so that the initialization (and possibly 36838teardown) those components do is not done as frequently on execution 36839paths where this would unnecessary. 36840 36841 What exactly those components are is up to the target code; the generic 36842code treats them abstractly, as a bit in an 'sbitmap'. These 'sbitmap's 36843are allocated by the 'shrink_wrap.get_separate_components' and 36844'shrink_wrap.components_for_bb' hooks, and deallocated by the generic 36845code. 36846 36847 -- Target Hook: sbitmap TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS 36848 (void) 36849 This hook should return an 'sbitmap' with the bits set for those 36850 components that can be separately shrink-wrapped in the current 36851 function. Return 'NULL' if the current function should not get any 36852 separate shrink-wrapping. Don't define this hook if it would 36853 always return 'NULL'. If it is defined, the other hooks in this 36854 group have to be defined as well. 36855 36856 -- Target Hook: sbitmap TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB 36857 (basic_block) 36858 This hook should return an 'sbitmap' with the bits set for those 36859 components where either the prologue component has to be executed 36860 before the 'basic_block', or the epilogue component after it, or 36861 both. 36862 36863 -- Target Hook: void TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS (sbitmap 36864 COMPONENTS, edge E, sbitmap EDGE_COMPONENTS, bool IS_PROLOGUE) 36865 This hook should clear the bits in the COMPONENTS bitmap for those 36866 components in EDGE_COMPONENTS that the target cannot handle on edge 36867 E, where IS_PROLOGUE says if this is for a prologue or an epilogue 36868 instead. 36869 36870 -- Target Hook: void TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS 36871 (sbitmap) 36872 Emit prologue insns for the components indicated by the parameter. 36873 36874 -- Target Hook: void TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS 36875 (sbitmap) 36876 Emit epilogue insns for the components indicated by the parameter. 36877 36878 -- Target Hook: void TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS 36879 (sbitmap) 36880 Mark the components in the parameter as handled, so that the 36881 'prologue' and 'epilogue' named patterns know to ignore those 36882 components. The target code should not hang on to the 'sbitmap', 36883 it will be deleted after this call. 36884 36885 36886File: gccint.info, Node: Stack Smashing Protection, Next: Miscellaneous Register Hooks, Prev: Shrink-wrapping separate components, Up: Stack and Calling 36887 3688818.9.15 Stack smashing protection 36889--------------------------------- 36890 36891 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 36892 This hook returns a 'DECL' node for the external variable to use 36893 for the stack protection guard. This variable is initialized by 36894 the runtime to some random value and is used to initialize the 36895 guard value that is placed at the top of the local stack frame. 36896 The type of this variable must be 'ptr_type_node'. 36897 36898 The default version of this hook creates a variable called 36899 '__stack_chk_guard', which is normally defined in 'libgcc2.c'. 36900 36901 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 36902 This hook returns a 'CALL_EXPR' that alerts the runtime that the 36903 stack protect guard variable has been modified. This expression 36904 should involve a call to a 'noreturn' function. 36905 36906 The default version of this hook invokes a function called 36907 '__stack_chk_fail', taking no arguments. This function is normally 36908 defined in 'libgcc2.c'. 36909 36910 -- Target Hook: bool TARGET_STACK_PROTECT_RUNTIME_ENABLED_P (void) 36911 Returns true if the target wants GCC's default stack protect 36912 runtime support, otherwise return false. The default 36913 implementation always returns true. 36914 36915 -- Common Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT, 36916 struct gcc_options *OPTS) 36917 Whether this target supports splitting the stack when the options 36918 described in OPTS have been passed. This is called after options 36919 have been parsed, so the target may reject splitting the stack in 36920 some configurations. The default version of this hook returns 36921 false. If REPORT is true, this function may issue a warning or 36922 error; if REPORT is false, it must simply return a value 36923 36924 -- Common Target Hook: vec<const char *> TARGET_GET_VALID_OPTION_VALUES 36925 (int OPTION_CODE, const char *PREFIX) 36926 The hook is used for options that have a non-trivial list of 36927 possible option values. OPTION_CODE is option code of opt_code 36928 enum type. PREFIX is used for bash completion and allows an 36929 implementation to return more specific completion based on the 36930 prefix. All string values should be allocated from heap memory and 36931 consumers should release them. The result will be pruned to cases 36932 with PREFIX if not NULL. 36933 36934 36935File: gccint.info, Node: Miscellaneous Register Hooks, Prev: Stack Smashing Protection, Up: Stack and Calling 36936 3693718.9.16 Miscellaneous register hooks 36938------------------------------------ 36939 36940 -- Target Hook: bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS 36941 Set to true if each call that binds to a local definition 36942 explicitly clobbers or sets all non-fixed registers modified by 36943 performing the call. That is, by the call pattern itself, or by 36944 code that might be inserted by the linker (e.g. stubs, veneers, 36945 branch islands), but not including those modifiable by the callee. 36946 The affected registers may be mentioned explicitly in the call 36947 pattern, or included as clobbers in CALL_INSN_FUNCTION_USAGE. The 36948 default version of this hook is set to false. The purpose of this 36949 hook is to enable the fipa-ra optimization. 36950 36951 36952File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 36953 3695418.10 Implementing the Varargs Macros 36955===================================== 36956 36957GCC comes with an implementation of '<varargs.h>' and '<stdarg.h>' that 36958work without change on machines that pass arguments on the stack. Other 36959machines require their own implementations of varargs, and the two 36960machine independent header files must have conditionals to include it. 36961 36962 ISO '<stdarg.h>' differs from traditional '<varargs.h>' mainly in the 36963calling convention for 'va_start'. The traditional implementation takes 36964just one argument, which is the variable in which to store the argument 36965pointer. The ISO implementation of 'va_start' takes an additional 36966second argument. The user is supposed to write the last named argument 36967of the function here. 36968 36969 However, 'va_start' should not use this argument. The way to find the 36970end of the named arguments is with the built-in functions described 36971below. 36972 36973 -- Macro: __builtin_saveregs () 36974 Use this built-in function to save the argument registers in memory 36975 so that the varargs mechanism can access them. Both ISO and 36976 traditional versions of 'va_start' must use '__builtin_saveregs', 36977 unless you use 'TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 36978 36979 On some machines, '__builtin_saveregs' is open-coded under the 36980 control of the target hook 'TARGET_EXPAND_BUILTIN_SAVEREGS'. On 36981 other machines, it calls a routine written in assembler language, 36982 found in 'libgcc2.c'. 36983 36984 Code generated for the call to '__builtin_saveregs' appears at the 36985 beginning of the function, as opposed to where the call to 36986 '__builtin_saveregs' is written, regardless of what the code is. 36987 This is because the registers must be saved before the function 36988 starts to use them for its own purposes. 36989 36990 -- Macro: __builtin_next_arg (LASTARG) 36991 This builtin returns the address of the first anonymous stack 36992 argument, as type 'void *'. If 'ARGS_GROW_DOWNWARD', it returns 36993 the address of the location above the first anonymous stack 36994 argument. Use it in 'va_start' to initialize the pointer for 36995 fetching arguments from the stack. Also use it in 'va_start' to 36996 verify that the second parameter LASTARG is the last named argument 36997 of the current function. 36998 36999 -- Macro: __builtin_classify_type (OBJECT) 37000 Since each machine has its own conventions for which data types are 37001 passed in which kind of register, your implementation of 'va_arg' 37002 has to embody these conventions. The easiest way to categorize the 37003 specified data type is to use '__builtin_classify_type' together 37004 with 'sizeof' and '__alignof__'. 37005 37006 '__builtin_classify_type' ignores the value of OBJECT, considering 37007 only its data type. It returns an integer describing what kind of 37008 type that is--integer, floating, pointer, structure, and so on. 37009 37010 The file 'typeclass.h' defines an enumeration that you can use to 37011 interpret the values of '__builtin_classify_type'. 37012 37013 These machine description macros help implement varargs: 37014 37015 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 37016 If defined, this hook produces the machine-specific code for a call 37017 to '__builtin_saveregs'. This code will be moved to the very 37018 beginning of the function, before any parameter access are made. 37019 The return value of this function should be an RTX that contains 37020 the value to use as the return of '__builtin_saveregs'. 37021 37022 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t 37023 ARGS_SO_FAR, const function_arg_info &ARG, int 37024 *PRETEND_ARGS_SIZE, int SECOND_TIME) 37025 This target hook offers an alternative to using 37026 '__builtin_saveregs' and defining the hook 37027 'TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 37028 register arguments into the stack so that all the arguments appear 37029 to have been passed consecutively on the stack. Once this is done, 37030 you can use the standard implementation of varargs that works for 37031 machines that pass all their arguments on the stack. 37032 37033 The argument ARGS_SO_FAR points to the 'CUMULATIVE_ARGS' data 37034 structure, containing the values that are obtained after processing 37035 the named arguments. The argument ARG describes the last of these 37036 named arguments. 37037 37038 The target hook should do two things: first, push onto the stack 37039 all the argument registers _not_ used for the named arguments, and 37040 second, store the size of the data thus pushed into the 37041 'int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 37042 that you store here will serve as additional offset for setting up 37043 the stack frame. 37044 37045 Because you must generate code to push the anonymous arguments at 37046 compile time without knowing their data types, 37047 'TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 37048 have just a single category of argument register and use it 37049 uniformly for all data types. 37050 37051 If the argument SECOND_TIME is nonzero, it means that the arguments 37052 of the function are being analyzed for the second time. This 37053 happens for an inline function, which is not actually compiled 37054 until the end of the source file. The hook 37055 'TARGET_SETUP_INCOMING_VARARGS' should not generate any 37056 instructions in this case. 37057 37058 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t 37059 CA) 37060 Define this hook to return 'true' if the location where a function 37061 argument is passed depends on whether or not it is a named 37062 argument. 37063 37064 This hook controls how the NAMED argument to 'TARGET_FUNCTION_ARG' 37065 is set for varargs and stdarg functions. If this hook returns 37066 'true', the NAMED argument is always true for named arguments, and 37067 false for unnamed arguments. If it returns 'false', but 37068 'TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns 'true', then all 37069 arguments are treated as named. Otherwise, all named arguments 37070 except the last are treated as named. 37071 37072 You need not define this hook if it always returns 'false'. 37073 37074 -- Target Hook: void TARGET_CALL_ARGS (rtx, TREE) 37075 While generating RTL for a function call, this target hook is 37076 invoked once for each argument passed to the function, either a 37077 register returned by 'TARGET_FUNCTION_ARG' or a memory location. 37078 It is called just before the point where argument registers are 37079 stored. The type of the function to be called is also passed as 37080 the second argument; it is 'NULL_TREE' for libcalls. The 37081 'TARGET_END_CALL_ARGS' hook is invoked just after the code to copy 37082 the return reg has been emitted. This functionality can be used to 37083 perform special setup of call argument registers if a target needs 37084 it. For functions without arguments, the hook is called once with 37085 'pc_rtx' passed instead of an argument register. Most ports do not 37086 need to implement anything for this hook. 37087 37088 -- Target Hook: void TARGET_END_CALL_ARGS (void) 37089 This target hook is invoked while generating RTL for a function 37090 call, just after the point where the return reg is copied into a 37091 pseudo. It signals that all the call argument and return registers 37092 for the just emitted call are now no longer in use. Most ports do 37093 not need to implement anything for this hook. 37094 37095 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 37096 (cumulative_args_t CA) 37097 If you need to conditionally change ABIs so that one works with 37098 'TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 37099 'TARGET_SETUP_INCOMING_VARARGS' nor 'TARGET_STRICT_ARGUMENT_NAMING' 37100 was defined, then define this hook to return 'true' if 37101 'TARGET_SETUP_INCOMING_VARARGS' is used, 'false' otherwise. 37102 Otherwise, you should not define this hook. 37103 37104 -- Target Hook: rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx SLOT, rtx ARG, rtx 37105 SLOT_NO) 37106 This hook is used by expand pass to emit insn to load bounds of ARG 37107 passed in SLOT. Expand pass uses this hook in case bounds of ARG 37108 are not passed in register. If SLOT is a memory, then bounds are 37109 loaded as for regular pointer loaded from memory. If SLOT is not a 37110 memory then SLOT_NO is an integer constant holding number of the 37111 target dependent special slot which should be used to obtain 37112 bounds. Hook returns RTX holding loaded bounds. 37113 37114 -- Target Hook: void TARGET_STORE_BOUNDS_FOR_ARG (rtx ARG, rtx SLOT, 37115 rtx BOUNDS, rtx SLOT_NO) 37116 This hook is used by expand pass to emit insns to store BOUNDS of 37117 ARG passed in SLOT. Expand pass uses this hook in case BOUNDS of 37118 ARG are not passed in register. If SLOT is a memory, then BOUNDS 37119 are stored as for regular pointer stored in memory. If SLOT is not 37120 a memory then SLOT_NO is an integer constant holding number of the 37121 target dependent special slot which should be used to store BOUNDS. 37122 37123 -- Target Hook: rtx TARGET_LOAD_RETURNED_BOUNDS (rtx SLOT) 37124 This hook is used by expand pass to emit insn to load bounds 37125 returned by function call in SLOT. Hook returns RTX holding loaded 37126 bounds. 37127 37128 -- Target Hook: void TARGET_STORE_RETURNED_BOUNDS (rtx SLOT, rtx 37129 BOUNDS) 37130 This hook is used by expand pass to emit insn to store BOUNDS 37131 returned by function call into SLOT. 37132 37133 37134File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 37135 3713618.11 Support for Nested Functions 37137================================== 37138 37139Taking the address of a nested function requires special compiler 37140handling to ensure that the static chain register is loaded when the 37141function is invoked via an indirect call. 37142 37143 GCC has traditionally supported nested functions by creating an 37144executable "trampoline" at run time when the address of a nested 37145function is taken. This is a small piece of code which normally resides 37146on the stack, in the stack frame of the containing function. The 37147trampoline loads the static chain register and then jumps to the real 37148address of the nested function. 37149 37150 The use of trampolines requires an executable stack, which is a 37151security risk. To avoid this problem, GCC also supports another 37152strategy: using descriptors for nested functions. Under this model, 37153taking the address of a nested function results in a pointer to a 37154non-executable function descriptor object. Initializing the static 37155chain from the descriptor is handled at indirect call sites. 37156 37157 On some targets, including HPPA and IA-64, function descriptors may be 37158mandated by the ABI or be otherwise handled in a target-specific way by 37159the back end in its code generation strategy for indirect calls. GCC 37160also provides its own generic descriptor implementation to support the 37161'-fno-trampolines' option. In this case runtime detection of function 37162descriptors at indirect call sites relies on descriptor pointers being 37163tagged with a bit that is never set in bare function addresses. Since 37164GCC's generic function descriptors are not ABI-compliant, this option is 37165typically used only on a per-language basis (notably by Ada) or when it 37166can otherwise be applied to the whole program. 37167 37168 Define the following hook if your backend either implements 37169ABI-specified descriptor support, or can use GCC's generic descriptor 37170implementation for nested functions. 37171 37172 -- Target Hook: int TARGET_CUSTOM_FUNCTION_DESCRIPTORS 37173 If the target can use GCC's generic descriptor mechanism for nested 37174 functions, define this hook to a power of 2 representing an unused 37175 bit in function pointers which can be used to differentiate 37176 descriptors at run time. This value gives the number of bytes by 37177 which descriptor pointers are misaligned compared to function 37178 pointers. For example, on targets that require functions to be 37179 aligned to a 4-byte boundary, a value of either 1 or 2 is 37180 appropriate unless the architecture already reserves the bit for 37181 another purpose, such as on ARM. 37182 37183 Define this hook to 0 if the target implements ABI support for 37184 function descriptors in its standard calling sequence, like for 37185 example HPPA or IA-64. 37186 37187 Using descriptors for nested functions eliminates the need for 37188 trampolines that reside on the stack and require it to be made 37189 executable. 37190 37191 The following macros tell GCC how to generate code to allocate and 37192initialize an executable trampoline. You can also use this interface if 37193your back end needs to create ABI-specified non-executable descriptors; 37194in this case the "trampoline" created is the descriptor containing data 37195only. 37196 37197 The instructions in an executable trampoline must do two things: load a 37198constant address into the static chain register, and jump to the real 37199address of the nested function. On CISC machines such as the m68k, this 37200requires two instructions, a move immediate and a jump. Then the two 37201addresses exist in the trampoline as word-long immediate operands. On 37202RISC machines, it is often necessary to load each address into a 37203register in two parts. Then pieces of each address form separate 37204immediate operands. 37205 37206 The code generated to initialize the trampoline must store the variable 37207parts--the static chain value and the function address--into the 37208immediate operands of the instructions. On a CISC machine, this is 37209simply a matter of copying each address to a memory reference at the 37210proper offset from the start of the trampoline. On a RISC machine, it 37211may be necessary to take out pieces of the address and store them 37212separately. 37213 37214 -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F) 37215 This hook is called by 'assemble_trampoline_template' to output, on 37216 the stream F, assembler code for a block of data that contains the 37217 constant parts of a trampoline. This code should not include a 37218 label--the label is taken care of automatically. 37219 37220 If you do not define this hook, it means no template is needed for 37221 the target. Do not define this hook on systems where the block 37222 move code to copy the trampoline into place would be larger than 37223 the code to generate it on the spot. 37224 37225 -- Macro: TRAMPOLINE_SECTION 37226 Return the section into which the trampoline template is to be 37227 placed (*note Sections::). The default value is 37228 'readonly_data_section'. 37229 37230 -- Macro: TRAMPOLINE_SIZE 37231 A C expression for the size in bytes of the trampoline, as an 37232 integer. 37233 37234 -- Macro: TRAMPOLINE_ALIGNMENT 37235 Alignment required for trampolines, in bits. 37236 37237 If you don't define this macro, the value of 'FUNCTION_ALIGNMENT' 37238 is used for aligning trampolines. 37239 37240 -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL, 37241 rtx STATIC_CHAIN) 37242 This hook is called to initialize a trampoline. M_TRAMP is an RTX 37243 for the memory block for the trampoline; FNDECL is the 37244 'FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX for 37245 the static chain value that should be passed to the function when 37246 it is called. 37247 37248 If the target defines 'TARGET_ASM_TRAMPOLINE_TEMPLATE', then the 37249 first thing this hook should do is emit a block move into M_TRAMP 37250 from the memory block returned by 'assemble_trampoline_template'. 37251 Note that the block move need only cover the constant parts of the 37252 trampoline. If the target isolates the variable parts of the 37253 trampoline to the end, not all 'TRAMPOLINE_SIZE' bytes need be 37254 copied. 37255 37256 If the target requires any other actions, such as flushing caches 37257 (possibly calling function maybe_emit_call_builtin___clear_cache) 37258 or enabling stack execution, these actions should be performed 37259 after initializing the trampoline proper. 37260 37261 -- Target Hook: void TARGET_EMIT_CALL_BUILTIN___CLEAR_CACHE (rtx BEGIN, 37262 rtx END) 37263 On targets that do not define a 'clear_cache' insn expander, but 37264 that define the 'CLEAR_CACHE_INSN' macro, 37265 maybe_emit_call_builtin___clear_cache relies on this target hook to 37266 clear an address range in the instruction cache. 37267 37268 The default implementation calls the '__clear_cache' builtin, 37269 taking the assembler name from the builtin declaration. Overriding 37270 definitions may call alternate functions, with alternate calling 37271 conventions, or emit alternate RTX to perform the job. 37272 37273 -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR) 37274 This hook should perform any machine-specific adjustment in the 37275 address of the trampoline. Its argument contains the address of 37276 the memory block that was passed to 'TARGET_TRAMPOLINE_INIT'. In 37277 case the address to be used for a function call should be different 37278 from the address at which the template was stored, the different 37279 address should be returned; otherwise ADDR should be returned 37280 unchanged. If this hook is not defined, ADDR will be used for 37281 function calls. 37282 37283 Implementing trampolines is difficult on many machines because they 37284have separate instruction and data caches. Writing into a stack 37285location fails to clear the memory in the instruction cache, so when the 37286program jumps to that location, it executes the old contents. 37287 37288 Here are two possible solutions. One is to clear the relevant parts of 37289the instruction cache whenever a trampoline is set up. The other is to 37290make all trampolines identical, by having them jump to a standard 37291subroutine. The former technique makes trampoline execution faster; the 37292latter makes initialization faster. 37293 37294 To clear the instruction cache when a trampoline is initialized, define 37295the following macro. 37296 37297 -- Macro: CLEAR_INSN_CACHE (BEG, END) 37298 If defined, expands to a C expression clearing the _instruction 37299 cache_ in the specified interval. The definition of this macro 37300 would typically be a series of 'asm' statements. Both BEG and END 37301 are pointer expressions. 37302 37303 To use a standard subroutine, define the following macro. In addition, 37304you must make sure that the instructions in a trampoline fill an entire 37305cache line with identical instructions, or else ensure that the 37306beginning of the trampoline code is always aligned at the same point in 37307its cache line. Look in 'm68k.h' as a guide. 37308 37309 -- Macro: TRANSFER_FROM_TRAMPOLINE 37310 Define this macro if trampolines need a special subroutine to do 37311 their work. The macro should expand to a series of 'asm' 37312 statements which will be compiled with GCC. They go in a library 37313 function named '__transfer_from_trampoline'. 37314 37315 If you need to avoid executing the ordinary prologue code of a 37316 compiled C function when you jump to the subroutine, you can do so 37317 by placing a special label of your own in the assembler code. Use 37318 one 'asm' statement to generate an assembler label, and another to 37319 make the label global. Then trampolines can use that label to jump 37320 directly to your special assembler code. 37321 37322 37323File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 37324 3732518.12 Implicit Calls to Library Routines 37326======================================== 37327 37328Here is an explanation of implicit calls to library routines. 37329 37330 -- Macro: DECLARE_LIBRARY_RENAMES 37331 This macro, if defined, should expand to a piece of C code that 37332 will get expanded when compiling functions for libgcc.a. It can be 37333 used to provide alternate names for GCC's internal library 37334 functions if there are ABI-mandated names that the compiler should 37335 provide. 37336 37337 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 37338 This hook should declare additional library routines or rename 37339 existing ones, using the functions 'set_optab_libfunc' and 37340 'init_one_libfunc' defined in 'optabs.c'. 'init_optabs' calls this 37341 macro after initializing all the normal library routines. 37342 37343 The default is to do nothing. Most ports don't need to define this 37344 hook. 37345 37346 -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX 37347 If false (the default), internal library routines start with two 37348 underscores. If set to true, these routines start with '__gnu_' 37349 instead. E.g., '__muldi3' changes to '__gnu_muldi3'. This 37350 currently only affects functions defined in 'libgcc2.c'. If this 37351 is set to true, the 'tm.h' file must also '#define 37352 LIBGCC2_GNU_PREFIX'. 37353 37354 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 37355 This macro should return 'true' if the library routine that 37356 implements the floating point comparison operator COMPARISON in 37357 mode MODE will return a boolean, and FALSE if it will return a 37358 tristate. 37359 37360 GCC's own floating point libraries return tristates from the 37361 comparison operators, so the default returns false always. Most 37362 ports don't need to define this macro. 37363 37364 -- Macro: TARGET_LIB_INT_CMP_BIASED 37365 This macro should evaluate to 'true' if the integer comparison 37366 functions (like '__cmpdi2') return 0 to indicate that the first 37367 operand is smaller than the second, 1 to indicate that they are 37368 equal, and 2 to indicate that the first operand is greater than the 37369 second. If this macro evaluates to 'false' the comparison 37370 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 37371 target uses the routines in 'libgcc.a', you do not need to define 37372 this macro. 37373 37374 -- Macro: TARGET_HAS_NO_HW_DIVIDE 37375 This macro should be defined if the target has no hardware divide 37376 instructions. If this macro is defined, GCC will use an algorithm 37377 which make use of simple logical and arithmetic operations for 37378 64-bit division. If the macro is not defined, GCC will use an 37379 algorithm which make use of a 64-bit by 32-bit divide primitive. 37380 37381 -- Macro: TARGET_EDOM 37382 The value of 'EDOM' on the target machine, as a C integer constant 37383 expression. If you don't define this macro, GCC does not attempt 37384 to deposit the value of 'EDOM' into 'errno' directly. Look in 37385 '/usr/include/errno.h' to find the value of 'EDOM' on your system. 37386 37387 If you do not define 'TARGET_EDOM', then compiled code reports 37388 domain errors by calling the library function and letting it report 37389 the error. If mathematical functions on your system use 'matherr' 37390 when there is an error, then you should leave 'TARGET_EDOM' 37391 undefined so that 'matherr' is used normally. 37392 37393 -- Macro: GEN_ERRNO_RTX 37394 Define this macro as a C expression to create an rtl expression 37395 that refers to the global "variable" 'errno'. (On certain systems, 37396 'errno' may not actually be a variable.) If you don't define this 37397 macro, a reasonable default is used. 37398 37399 -- Target Hook: bool TARGET_LIBC_HAS_FUNCTION (enum function_class 37400 FN_CLASS, tree TYPE) 37401 This hook determines whether a function from a class of functions 37402 FN_CLASS is present in the target C library. If TYPE is NULL, the 37403 caller asks for support for all standard (float, double, long 37404 double) types. If TYPE is non-NULL, the caller asks for support 37405 for a specific type. 37406 37407 -- Target Hook: bool TARGET_LIBC_HAS_FAST_FUNCTION (int FCODE) 37408 This hook determines whether a function from a class of functions 37409 '(enum function_class)'FCODE has a fast implementation. 37410 37411 -- Macro: NEXT_OBJC_RUNTIME 37412 Set this macro to 1 to use the "NeXT" Objective-C message sending 37413 conventions by default. This calling convention involves passing 37414 the object, the selector and the method arguments all at once to 37415 the method-lookup library function. This is the usual setting when 37416 targeting Darwin/Mac OS X systems, which have the NeXT runtime 37417 installed. 37418 37419 If the macro is set to 0, the "GNU" Objective-C message sending 37420 convention will be used by default. This convention passes just 37421 the object and the selector to the method-lookup function, which 37422 returns a pointer to the method. 37423 37424 In either case, it remains possible to select code-generation for 37425 the alternate scheme, by means of compiler command line switches. 37426 37427 37428File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 37429 3743018.13 Addressing Modes 37431====================== 37432 37433This is about addressing modes. 37434 37435 -- Macro: HAVE_PRE_INCREMENT 37436 -- Macro: HAVE_PRE_DECREMENT 37437 -- Macro: HAVE_POST_INCREMENT 37438 -- Macro: HAVE_POST_DECREMENT 37439 A C expression that is nonzero if the machine supports 37440 pre-increment, pre-decrement, post-increment, or post-decrement 37441 addressing respectively. 37442 37443 -- Macro: HAVE_PRE_MODIFY_DISP 37444 -- Macro: HAVE_POST_MODIFY_DISP 37445 A C expression that is nonzero if the machine supports pre- or 37446 post-address side-effect generation involving constants other than 37447 the size of the memory operand. 37448 37449 -- Macro: HAVE_PRE_MODIFY_REG 37450 -- Macro: HAVE_POST_MODIFY_REG 37451 A C expression that is nonzero if the machine supports pre- or 37452 post-address side-effect generation involving a register 37453 displacement. 37454 37455 -- Macro: CONSTANT_ADDRESS_P (X) 37456 A C expression that is 1 if the RTX X is a constant which is a 37457 valid address. On most machines the default definition of 37458 '(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable, 37459 but a few machines are more restrictive as to which constant 37460 addresses are supported. 37461 37462 -- Macro: CONSTANT_P (X) 37463 'CONSTANT_P', which is defined by target-independent code, accepts 37464 integer-values expressions whose values are not explicitly known, 37465 such as 'symbol_ref', 'label_ref', and 'high' expressions and 37466 'const' arithmetic expressions, in addition to 'const_int' and 37467 'const_double' expressions. 37468 37469 -- Macro: MAX_REGS_PER_ADDRESS 37470 A number, the maximum number of registers that can appear in a 37471 valid memory address. Note that it is up to you to specify a value 37472 equal to the maximum number that 'TARGET_LEGITIMATE_ADDRESS_P' 37473 would ever accept. 37474 37475 -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (machine_mode MODE, 37476 rtx X, bool STRICT) 37477 A function that returns whether X (an RTX) is a legitimate memory 37478 address on the target machine for a memory operand of mode MODE. 37479 37480 Legitimate addresses are defined in two variants: a strict variant 37481 and a non-strict one. The STRICT parameter chooses which variant 37482 is desired by the caller. 37483 37484 The strict variant is used in the reload pass. It must be defined 37485 so that any pseudo-register that has not been allocated a hard 37486 register is considered a memory reference. This is because in 37487 contexts where some kind of register is required, a pseudo-register 37488 with no hard register must be rejected. For non-hard registers, 37489 the strict variant should look up the 'reg_renumber' array; it 37490 should then proceed using the hard register number in the array, or 37491 treat the pseudo as a memory reference if the array holds '-1'. 37492 37493 The non-strict variant is used in other passes. It must be defined 37494 to accept all pseudo-registers in every context where some kind of 37495 register is required. 37496 37497 Normally, constant addresses which are the sum of a 'symbol_ref' 37498 and an integer are stored inside a 'const' RTX to mark them as 37499 constant. Therefore, there is no need to recognize such sums 37500 specifically as legitimate addresses. Normally you would simply 37501 recognize any 'const' as legitimate. 37502 37503 Usually 'PRINT_OPERAND_ADDRESS' is not prepared to handle constant 37504 sums that are not marked with 'const'. It assumes that a naked 37505 'plus' indicates indexing. If so, then you _must_ reject such 37506 naked constant sums as illegitimate addresses, so that none of them 37507 will be given to 'PRINT_OPERAND_ADDRESS'. 37508 37509 On some machines, whether a symbolic address is legitimate depends 37510 on the section that the address refers to. On these machines, 37511 define the target hook 'TARGET_ENCODE_SECTION_INFO' to store the 37512 information into the 'symbol_ref', and then check for it here. 37513 When you see a 'const', you will have to look inside it to find the 37514 'symbol_ref' in order to determine the section. *Note Assembler 37515 Format::. 37516 37517 Some ports are still using a deprecated legacy substitute for this 37518 hook, the 'GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this 37519 syntax: 37520 37521 #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 37522 37523 and should 'goto LABEL' if the address X is a valid address on the 37524 target machine for a memory operand of mode MODE. 37525 37526 Compiler source files that want to use the strict variant of this 37527 macro define the macro 'REG_OK_STRICT'. You should use an '#ifdef 37528 REG_OK_STRICT' conditional to define the strict variant in that 37529 case and the non-strict variant otherwise. 37530 37531 Using the hook is usually simpler because it limits the number of 37532 files that are recompiled when changes are made. 37533 37534 -- Macro: TARGET_MEM_CONSTRAINT 37535 A single character to be used instead of the default ''m'' 37536 character for general memory addresses. This defines the 37537 constraint letter which matches the memory addresses accepted by 37538 'TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to 37539 support new address formats in your back end without changing the 37540 semantics of the ''m'' constraint. This is necessary in order to 37541 preserve functionality of inline assembly constructs using the 37542 ''m'' constraint. 37543 37544 -- Macro: FIND_BASE_TERM (X) 37545 A C expression to determine the base term of address X, or to 37546 provide a simplified version of X from which 'alias.c' can easily 37547 find the base term. This macro is used in only two places: 37548 'find_base_value' and 'find_base_term' in 'alias.c'. 37549 37550 It is always safe for this macro to not be defined. It exists so 37551 that alias analysis can understand machine-dependent addresses. 37552 37553 The typical use of this macro is to handle addresses containing a 37554 label_ref or symbol_ref within an UNSPEC. 37555 37556 -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, 37557 machine_mode MODE) 37558 This hook is given an invalid memory address X for an operand of 37559 mode MODE and should try to return a valid memory address. 37560 37561 X will always be the result of a call to 'break_out_memory_refs', 37562 and OLDX will be the operand that was given to that function to 37563 produce X. 37564 37565 The code of the hook should not alter the substructure of X. If it 37566 transforms X into a more legitimate form, it should return the new 37567 X. 37568 37569 It is not necessary for this hook to come up with a legitimate 37570 address, with the exception of native TLS addresses (*note Emulated 37571 TLS::). The compiler has standard ways of doing so in all cases. 37572 In fact, if the target supports only emulated TLS, it is safe to 37573 omit this hook or make it return X if it cannot find a valid way to 37574 legitimize the address. But often a machine-dependent strategy can 37575 generate better code. 37576 37577 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 37578 WIN) 37579 A C compound statement that attempts to replace X, which is an 37580 address that needs reloading, with a valid memory address for an 37581 operand of mode MODE. WIN will be a C statement label elsewhere in 37582 the code. It is not necessary to define this macro, but it might 37583 be useful for performance reasons. 37584 37585 For example, on the i386, it is sometimes possible to use a single 37586 reload register instead of two by reloading a sum of two pseudo 37587 registers into a register. On the other hand, for number of RISC 37588 processors offsets are limited so that often an intermediate 37589 address needs to be generated in order to address a stack slot. By 37590 defining 'LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 37591 intermediate addresses generated for adjacent some stack slots can 37592 be made identical, and thus be shared. 37593 37594 _Note_: This macro should be used with caution. It is necessary to 37595 know something of how reload works in order to effectively use 37596 this, and it is quite easy to produce macros that build in too much 37597 knowledge of reload internals. 37598 37599 _Note_: This macro must be able to reload an address created by a 37600 previous invocation of this macro. If it fails to handle such 37601 addresses then the compiler may generate incorrect code or abort. 37602 37603 The macro definition should use 'push_reload' to indicate parts 37604 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 37605 suitable to be passed unaltered to 'push_reload'. 37606 37607 The code generated by this macro must not alter the substructure of 37608 X. If it transforms X into a more legitimate form, it should 37609 assign X (which will always be a C variable) a new value. This 37610 also applies to parts that you change indirectly by calling 37611 'push_reload'. 37612 37613 The macro definition may use 'strict_memory_address_p' to test if 37614 the address has become legitimate. 37615 37616 If you want to change only a part of X, one standard way of doing 37617 this is to use 'copy_rtx'. Note, however, that it unshares only a 37618 single level of rtl. Thus, if the part to be changed is not at the 37619 top level, you'll need to replace first the top level. It is not 37620 necessary for this macro to come up with a legitimate address; but 37621 often a machine-dependent strategy can generate better code. 37622 37623 -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR, 37624 addr_space_t ADDRSPACE) 37625 This hook returns 'true' if memory address ADDR in address space 37626 ADDRSPACE can have different meanings depending on the machine mode 37627 of the memory reference it is used for or if the address is valid 37628 for some modes but not others. 37629 37630 Autoincrement and autodecrement addresses typically have 37631 mode-dependent effects because the amount of the increment or 37632 decrement is the size of the operand being addressed. Some 37633 machines have other mode-dependent addresses. Many RISC machines 37634 have no mode-dependent addresses. 37635 37636 You may assume that ADDR is a valid address for the machine. 37637 37638 The default version of this hook returns 'false'. 37639 37640 -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (machine_mode MODE, 37641 rtx X) 37642 This hook returns true if X is a legitimate constant for a 37643 MODE-mode immediate operand on the target machine. You can assume 37644 that X satisfies 'CONSTANT_P', so you need not check this. 37645 37646 The default definition returns true. 37647 37648 -- Target Hook: bool TARGET_PRECOMPUTE_TLS_P (machine_mode MODE, rtx X) 37649 This hook returns true if X is a TLS operand on the target machine 37650 that should be pre-computed when used as the argument in a call. 37651 You can assume that X satisfies 'CONSTANT_P', so you need not check 37652 this. 37653 37654 The default definition returns false. 37655 37656 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 37657 This hook is used to undo the possibly obfuscating effects of the 37658 'LEGITIMIZE_ADDRESS' and 'LEGITIMIZE_RELOAD_ADDRESS' target macros. 37659 Some backend implementations of these macros wrap symbol references 37660 inside an 'UNSPEC' rtx to represent PIC or similar addressing 37661 modes. This target hook allows GCC's optimizers to understand the 37662 semantics of these opaque 'UNSPEC's by converting them back into 37663 their original form. 37664 37665 -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X) 37666 This hook should return true if X should not be emitted into debug 37667 sections. 37668 37669 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (machine_mode MODE, 37670 rtx X) 37671 This hook should return true if X is of a form that cannot (or 37672 should not) be spilled to the constant pool. MODE is the mode of 37673 X. 37674 37675 The default version of this hook returns false. 37676 37677 The primary reason to define this hook is to prevent reload from 37678 deciding that a non-legitimate constant would be better reloaded 37679 from the constant pool instead of spilling and reloading a register 37680 holding the constant. This restriction is often true of addresses 37681 of TLS symbols for various targets. 37682 37683 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (machine_mode 37684 MODE, const_rtx X) 37685 This hook should return true if pool entries for constant X can be 37686 placed in an 'object_block' structure. MODE is the mode of X. 37687 37688 The default version returns false for all constants. 37689 37690 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL) 37691 This hook should return true if pool entries for DECL should be 37692 placed in an 'object_block' structure. 37693 37694 The default version returns true for all decls. 37695 37696 -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (tree FNDECL) 37697 This hook should return the DECL of a function that implements the 37698 reciprocal of the machine-specific builtin function FNDECL, or 37699 'NULL_TREE' if such a function is not available. 37700 37701 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 37702 This hook should return the DECL of a function F that given an 37703 address ADDR as an argument returns a mask M that can be used to 37704 extract from two vectors the relevant data that resides in ADDR in 37705 case ADDR is not properly aligned. 37706 37707 The autovectorizer, when vectorizing a load operation from an 37708 address ADDR that may be unaligned, will generate two vector loads 37709 from the two aligned addresses around ADDR. It then generates a 37710 'REALIGN_LOAD' operation to extract the relevant data from the two 37711 loaded vectors. The first two arguments to 'REALIGN_LOAD', V1 and 37712 V2, are the two vectors, each of size VS, and the third argument, 37713 OFF, defines how the data will be extracted from these two vectors: 37714 if OFF is 0, then the returned vector is V2; otherwise, the 37715 returned vector is composed from the last VS-OFF elements of V1 37716 concatenated to the first OFF elements of V2. 37717 37718 If this hook is defined, the autovectorizer will generate a call to 37719 F (using the DECL tree that this hook returns) and will use the 37720 return value of F as the argument OFF to 'REALIGN_LOAD'. 37721 Therefore, the mask M returned by F should comply with the 37722 semantics expected by 'REALIGN_LOAD' described above. If this hook 37723 is not defined, then ADDR will be used as the argument OFF to 37724 'REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR 37725 will be considered. 37726 37727 -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum 37728 vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN) 37729 Returns cost of different scalar or vector statements for 37730 vectorization cost model. For vector memory operations the cost 37731 may depend on type (VECTYPE) and misalignment value (MISALIGN). 37732 37733 -- Target Hook: poly_uint64 TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT 37734 (const_tree TYPE) 37735 This hook returns the preferred alignment in bits for accesses to 37736 vectors of type TYPE in vectorized code. This might be less than 37737 or greater than the ABI-defined value returned by 37738 'TARGET_VECTOR_ALIGNMENT'. It can be equal to the alignment of a 37739 single element, in which case the vectorizer will not try to 37740 optimize for alignment. 37741 37742 The default hook returns 'TYPE_ALIGN (TYPE)', which is correct for 37743 most targets. 37744 37745 -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE 37746 (const_tree TYPE, bool IS_PACKED) 37747 Return true if vector alignment is reachable (by peeling N 37748 iterations) for the given scalar type TYPE. IS_PACKED is false if 37749 the scalar access using TYPE is known to be naturally aligned. 37750 37751 -- Target Hook: bool TARGET_VECTORIZE_VEC_PERM_CONST (machine_mode 37752 MODE, rtx OUTPUT, rtx IN0, rtx IN1, const vec_perm_indices 37753 &SEL) 37754 This hook is used to test whether the target can permute up to two 37755 vectors of mode MODE using the permutation vector 'sel', and also 37756 to emit such a permutation. In the former case IN0, IN1 and OUT 37757 are all null. In the latter case IN0 and IN1 are the source 37758 vectors and OUT is the destination vector; all three are registers 37759 of mode MODE. IN1 is the same as IN0 if SEL describes a 37760 permutation on one vector instead of two. 37761 37762 Return true if the operation is possible, emitting instructions for 37763 it if rtxes are provided. 37764 37765 If the hook returns false for a mode with multibyte elements, GCC 37766 will try the equivalent byte operation. If that also fails, it 37767 will try forcing the selector into a register and using the 37768 VEC_PERMMODE instruction pattern. There is no need for the hook to 37769 handle these two implementation approaches itself. 37770 37771 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION 37772 (unsigned CODE, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 37773 This hook should return the decl of a function that implements the 37774 vectorized variant of the function with the 'combined_fn' code CODE 37775 or 'NULL_TREE' if such a function is not available. The return 37776 type of the vectorized function shall be of vector type 37777 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 37778 37779 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION 37780 (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 37781 This hook should return the decl of a function that implements the 37782 vectorized variant of target built-in function 'fndecl'. The 37783 return type of the vectorized function shall be of vector type 37784 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 37785 37786 -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT 37787 (machine_mode MODE, const_tree TYPE, int MISALIGNMENT, bool 37788 IS_PACKED) 37789 This hook should return true if the target supports misaligned 37790 vector store/load of a specific factor denoted in the MISALIGNMENT 37791 parameter. The vector store/load should be of machine mode MODE 37792 and the elements in the vectors should be of type TYPE. IS_PACKED 37793 parameter is true if the memory access is defined in a packed 37794 struct. 37795 37796 -- Target Hook: machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE 37797 (scalar_mode MODE) 37798 This hook should return the preferred mode for vectorizing scalar 37799 mode MODE. The default is equal to 'word_mode', because the 37800 vectorizer can do some transformations even in absence of 37801 specialized SIMD hardware. 37802 37803 -- Target Hook: machine_mode TARGET_VECTORIZE_SPLIT_REDUCTION 37804 (machine_mode) 37805 This hook should return the preferred mode to split the final 37806 reduction step on MODE to. The reduction is then carried out 37807 reducing upper against lower halves of vectors recursively until 37808 the specified mode is reached. The default is MODE which means no 37809 splitting. 37810 37811 -- Target Hook: unsigned int 37812 TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES (vector_modes 37813 *MODES, bool ALL) 37814 If using the mode returned by 37815 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' is not the only approach 37816 worth considering, this hook should add one mode to MODES for each 37817 useful alternative approach. These modes are then passed to 37818 'TARGET_VECTORIZE_RELATED_MODE' to obtain the vector mode for a 37819 given element mode. 37820 37821 The modes returned in MODES should use the smallest element mode 37822 possible for the vectorization approach that they represent, 37823 preferring integer modes over floating-poing modes in the event of 37824 a tie. The first mode should be the 37825 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' for its element mode. 37826 37827 If ALL is true, add suitable vector modes even when they are 37828 generally not expected to be worthwhile. 37829 37830 The hook returns a bitmask of flags that control how the modes in 37831 MODES are used. The flags are: 37832 'VECT_COMPARE_COSTS' 37833 Tells the loop vectorizer to try all the provided modes and 37834 pick the one with the lowest cost. By default the vectorizer 37835 will choose the first mode that works. 37836 37837 The hook does not need to do anything if the vector returned by 37838 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' is the only one relevant for 37839 autovectorization. The default implementation adds no modes and 37840 returns 0. 37841 37842 -- Target Hook: opt_machine_mode TARGET_VECTORIZE_RELATED_MODE 37843 (machine_mode VECTOR_MODE, scalar_mode ELEMENT_MODE, 37844 poly_uint64 NUNITS) 37845 If a piece of code is using vector mode VECTOR_MODE and also wants 37846 to operate on elements of mode ELEMENT_MODE, return the vector mode 37847 it should use for those elements. If NUNITS is nonzero, ensure 37848 that the mode has exactly NUNITS elements, otherwise pick whichever 37849 vector size pairs the most naturally with VECTOR_MODE. Return an 37850 empty 'opt_machine_mode' if there is no supported vector mode with 37851 the required properties. 37852 37853 There is no prescribed way of handling the case in which NUNITS is 37854 zero. One common choice is to pick a vector mode with the same 37855 size as VECTOR_MODE; this is the natural choice if the target has a 37856 fixed vector size. Another option is to choose a vector mode with 37857 the same number of elements as VECTOR_MODE; this is the natural 37858 choice if the target has a fixed number of elements. 37859 Alternatively, the hook might choose a middle ground, such as 37860 trying to keep the number of elements as similar as possible while 37861 applying maximum and minimum vector sizes. 37862 37863 The default implementation uses 'mode_for_vector' to find the 37864 requested mode, returning a mode with the same size as VECTOR_MODE 37865 when NUNITS is zero. This is the correct behavior for most 37866 targets. 37867 37868 -- Target Hook: opt_machine_mode TARGET_VECTORIZE_GET_MASK_MODE 37869 (machine_mode MODE) 37870 Return the mode to use for a vector mask that holds one boolean 37871 result for each element of vector mode MODE. The returned mask 37872 mode can be a vector of integers (class 'MODE_VECTOR_INT'), a 37873 vector of booleans (class 'MODE_VECTOR_BOOL') or a scalar integer 37874 (class 'MODE_INT'). Return an empty 'opt_machine_mode' if no such 37875 mask mode exists. 37876 37877 The default implementation returns a 'MODE_VECTOR_INT' with the 37878 same size and number of elements as MODE, if such a mode exists. 37879 37880 -- Target Hook: bool TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE (unsigned 37881 IFN) 37882 This hook returns true if masked internal function IFN (really of 37883 type 'internal_fn') should be considered expensive when the mask is 37884 all zeros. GCC can then try to branch around the instruction 37885 instead. 37886 37887 -- Target Hook: void * TARGET_VECTORIZE_INIT_COST (class loop 37888 *LOOP_INFO) 37889 This hook should initialize target-specific data structures in 37890 preparation for modeling the costs of vectorizing a loop or basic 37891 block. The default allocates three unsigned integers for 37892 accumulating costs for the prologue, body, and epilogue of the loop 37893 or basic block. If LOOP_INFO is non-NULL, it identifies the loop 37894 being vectorized; otherwise a single block is being vectorized. 37895 37896 -- Target Hook: unsigned TARGET_VECTORIZE_ADD_STMT_COST (class vec_info 37897 *, void *DATA, int COUNT, enum vect_cost_for_stmt KIND, class 37898 _stmt_vec_info *STMT_INFO, tree VECTYPE, int MISALIGN, enum 37899 vect_cost_model_location WHERE) 37900 This hook should update the target-specific DATA in response to 37901 adding COUNT copies of the given KIND of statement to a loop or 37902 basic block. The default adds the builtin vectorizer cost for the 37903 copies of the statement to the accumulator specified by WHERE, (the 37904 prologue, body, or epilogue) and returns the amount added. The 37905 return value should be viewed as a tentative cost that may later be 37906 revised. 37907 37908 -- Target Hook: void TARGET_VECTORIZE_FINISH_COST (void *DATA, unsigned 37909 *PROLOGUE_COST, unsigned *BODY_COST, unsigned *EPILOGUE_COST) 37910 This hook should complete calculations of the cost of vectorizing a 37911 loop or basic block based on DATA, and return the prologue, body, 37912 and epilogue costs as unsigned integers. The default returns the 37913 value of the three accumulators. 37914 37915 -- Target Hook: void TARGET_VECTORIZE_DESTROY_COST_DATA (void *DATA) 37916 This hook should release DATA and any related data structures 37917 allocated by TARGET_VECTORIZE_INIT_COST. The default releases the 37918 accumulator. 37919 37920 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_GATHER (const_tree 37921 MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE) 37922 Target builtin that implements vector gather operation. 37923 MEM_VECTYPE is the vector type of the load and INDEX_TYPE is scalar 37924 type of the index, scaled by SCALE. The default is 'NULL_TREE' 37925 which means to not vectorize gather loads. 37926 37927 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_SCATTER (const_tree 37928 VECTYPE, const_tree INDEX_TYPE, int SCALE) 37929 Target builtin that implements vector scatter operation. VECTYPE 37930 is the vector type of the store and INDEX_TYPE is scalar type of 37931 the index, scaled by SCALE. The default is 'NULL_TREE' which means 37932 to not vectorize scatter stores. 37933 37934 -- Target Hook: int TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN 37935 (struct cgraph_node *, struct cgraph_simd_clone *, TREE, INT) 37936 This hook should set VECSIZE_MANGLE, VECSIZE_INT, VECSIZE_FLOAT 37937 fields in SIMD_CLONE structure pointed by CLONE_INFO argument and 37938 also SIMDLEN field if it was previously 0. The hook should return 37939 0 if SIMD clones shouldn't be emitted, or number of VECSIZE_MANGLE 37940 variants that should be emitted. 37941 37942 -- Target Hook: void TARGET_SIMD_CLONE_ADJUST (struct cgraph_node *) 37943 This hook should add implicit 'attribute(target("..."))' attribute 37944 to SIMD clone NODE if needed. 37945 37946 -- Target Hook: int TARGET_SIMD_CLONE_USABLE (struct cgraph_node *) 37947 This hook should return -1 if SIMD clone NODE shouldn't be used in 37948 vectorized loops in current function, or non-negative number if it 37949 is usable. In that case, the smaller the number is, the more 37950 desirable it is to use it. 37951 37952 -- Target Hook: int TARGET_SIMT_VF (void) 37953 Return number of threads in SIMT thread group on the target. 37954 37955 -- Target Hook: int TARGET_OMP_DEVICE_KIND_ARCH_ISA (enum 37956 omp_device_kind_arch_isa TRAIT, const char *NAME) 37957 Return 1 if TRAIT NAME is present in the OpenMP context's device 37958 trait set, return 0 if not present in any OpenMP context in the 37959 whole translation unit, or -1 if not present in the current OpenMP 37960 context but might be present in another OpenMP context in the same 37961 TU. 37962 37963 -- Target Hook: bool TARGET_GOACC_VALIDATE_DIMS (tree DECL, int *DIMS, 37964 int FN_LEVEL, unsigned USED) 37965 This hook should check the launch dimensions provided for an 37966 OpenACC compute region, or routine. Defaulted values are 37967 represented as -1 and non-constant values as 0. The FN_LEVEL is 37968 negative for the function corresponding to the compute region. For 37969 a routine it is the outermost level at which partitioned execution 37970 may be spawned. The hook should verify non-default values. If 37971 DECL is NULL, global defaults are being validated and unspecified 37972 defaults should be filled in. Diagnostics should be issued as 37973 appropriate. Return true, if changes have been made. You must 37974 override this hook to provide dimensions larger than 1. 37975 37976 -- Target Hook: int TARGET_GOACC_DIM_LIMIT (int AXIS) 37977 This hook should return the maximum size of a particular dimension, 37978 or zero if unbounded. 37979 37980 -- Target Hook: bool TARGET_GOACC_FORK_JOIN (gcall *CALL, const int 37981 *DIMS, bool IS_FORK) 37982 This hook can be used to convert IFN_GOACC_FORK and IFN_GOACC_JOIN 37983 function calls to target-specific gimple, or indicate whether they 37984 should be retained. It is executed during the oacc_device_lower 37985 pass. It should return true, if the call should be retained. It 37986 should return false, if it is to be deleted (either because 37987 target-specific gimple has been inserted before it, or there is no 37988 need for it). The default hook returns false, if there are no RTL 37989 expanders for them. 37990 37991 -- Target Hook: void TARGET_GOACC_REDUCTION (gcall *CALL) 37992 This hook is used by the oacc_transform pass to expand calls to the 37993 GOACC_REDUCTION internal function, into a sequence of gimple 37994 instructions. CALL is gimple statement containing the call to the 37995 function. This hook removes statement CALL after the expanded 37996 sequence has been inserted. This hook is also responsible for 37997 allocating any storage for reductions when necessary. 37998 37999 -- Target Hook: tree TARGET_PREFERRED_ELSE_VALUE (unsigned IFN, tree 38000 TYPE, unsigned NOPS, tree *OPS) 38001 This hook returns the target's preferred final argument for a call 38002 to conditional internal function IFN (really of type 38003 'internal_fn'). TYPE specifies the return type of the function and 38004 OPS are the operands to the conditional operation, of which there 38005 are NOPS. 38006 38007 For example, if IFN is 'IFN_COND_ADD', the hook returns a value of 38008 type TYPE that should be used when 'OPS[0]' and 'OPS[1]' are 38009 conditionally added together. 38010 38011 This hook is only relevant if the target supports conditional 38012 patterns like 'cond_addM'. The default implementation returns a 38013 zero constant of type TYPE. 38014 38015 38016File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 38017 3801818.14 Anchored Addresses 38019======================== 38020 38021GCC usually addresses every static object as a separate entity. For 38022example, if we have: 38023 38024 static int a, b, c; 38025 int foo (void) { return a + b + c; } 38026 38027 the code for 'foo' will usually calculate three separate symbolic 38028addresses: those of 'a', 'b' and 'c'. On some targets, it would be 38029better to calculate just one symbolic address and access the three 38030variables relative to it. The equivalent pseudocode would be something 38031like: 38032 38033 int foo (void) 38034 { 38035 register int *xr = &x; 38036 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 38037 } 38038 38039 (which isn't valid C). We refer to shared addresses like 'x' as 38040"section anchors". Their use is controlled by '-fsection-anchors'. 38041 38042 The hooks below describe the target properties that GCC needs to know 38043in order to make effective use of section anchors. It won't use section 38044anchors at all unless either 'TARGET_MIN_ANCHOR_OFFSET' or 38045'TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 38046 38047 -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 38048 The minimum offset that should be applied to a section anchor. On 38049 most targets, it should be the smallest offset that can be applied 38050 to a base register while still giving a legitimate address for 38051 every mode. The default value is 0. 38052 38053 -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 38054 Like 'TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) offset 38055 that should be applied to section anchors. The default value is 0. 38056 38057 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 38058 Write the assembly code to define section anchor X, which is a 38059 'SYMBOL_REF' for which 'SYMBOL_REF_ANCHOR_P (X)' is true. The hook 38060 is called with the assembly output position set to the beginning of 38061 'SYMBOL_REF_BLOCK (X)'. 38062 38063 If 'ASM_OUTPUT_DEF' is available, the hook's default definition 38064 uses it to define the symbol as '. + SYMBOL_REF_BLOCK_OFFSET (X)'. 38065 If 'ASM_OUTPUT_DEF' is not available, the hook's default definition 38066 is 'NULL', which disables the use of section anchors altogether. 38067 38068 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X) 38069 Return true if GCC should attempt to use anchors to access 38070 'SYMBOL_REF' X. You can assume 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 38071 and '!SYMBOL_REF_ANCHOR_P (X)'. 38072 38073 The default version is correct for most targets, but you might need 38074 to intercept this hook to handle things like target-specific 38075 attributes or target-specific sections. 38076 38077 38078File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 38079 3808018.15 Condition Code Status 38081=========================== 38082 38083The macros in this section can be split in two families, according to 38084the two ways of representing condition codes in GCC. 38085 38086 The first representation is the so called '(cc0)' representation (*note 38087Jump Patterns::), where all instructions can have an implicit clobber of 38088the condition codes. The second is the condition code register 38089representation, which provides better schedulability for architectures 38090that do have a condition code register, but on which most instructions 38091do not affect it. The latter category includes most RISC machines. 38092 38093 The implicit clobbering poses a strong restriction on the placement of 38094the definition and use of the condition code. In the past the 38095definition and use were always adjacent. However, recent changes to 38096support trapping arithmatic may result in the definition and user being 38097in different blocks. Thus, there may be a 'NOTE_INSN_BASIC_BLOCK' 38098between them. Additionally, the definition may be the source of 38099exception handling edges. 38100 38101 These restrictions can prevent important optimizations on some 38102machines. For example, on the IBM RS/6000, there is a delay for taken 38103branches unless the condition code register is set three instructions 38104earlier than the conditional branch. The instruction scheduler cannot 38105perform this optimization if it is not permitted to separate the 38106definition and use of the condition code register. 38107 38108 For this reason, it is possible and suggested to use a register to 38109represent the condition code for new ports. If there is a specific 38110condition code register in the machine, use a hard register. If the 38111condition code or comparison result can be placed in any general 38112register, or if there are multiple condition registers, use a pseudo 38113register. Registers used to store the condition code value will usually 38114have a mode that is in class 'MODE_CC'. 38115 38116 Alternatively, you can use 'BImode' if the comparison operator is 38117specified already in the compare instruction. In this case, you are not 38118interested in most macros in this section. 38119 38120* Menu: 38121 38122* CC0 Condition Codes:: Old style representation of condition codes. 38123* MODE_CC Condition Codes:: Modern representation of condition codes. 38124 38125 38126File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code 38127 3812818.15.1 Representation of condition codes using '(cc0)' 38129------------------------------------------------------- 38130 38131The file 'conditions.h' defines a variable 'cc_status' to describe how 38132the condition code was computed (in case the interpretation of the 38133condition code depends on the instruction that it was set by). This 38134variable contains the RTL expressions on which the condition code is 38135currently based, and several standard flags. 38136 38137 Sometimes additional machine-specific flags must be defined in the 38138machine description header file. It can also add additional 38139machine-specific information by defining 'CC_STATUS_MDEP'. 38140 38141 -- Macro: CC_STATUS_MDEP 38142 C code for a data type which is used for declaring the 'mdep' 38143 component of 'cc_status'. It defaults to 'int'. 38144 38145 This macro is not used on machines that do not use 'cc0'. 38146 38147 -- Macro: CC_STATUS_MDEP_INIT 38148 A C expression to initialize the 'mdep' field to "empty". The 38149 default definition does nothing, since most machines don't use the 38150 field anyway. If you want to use the field, you should probably 38151 define this macro to initialize it. 38152 38153 This macro is not used on machines that do not use 'cc0'. 38154 38155 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 38156 A C compound statement to set the components of 'cc_status' 38157 appropriately for an insn INSN whose body is EXP. It is this 38158 macro's responsibility to recognize insns that set the condition 38159 code as a byproduct of other activity as well as those that 38160 explicitly set '(cc0)'. 38161 38162 This macro is not used on machines that do not use 'cc0'. 38163 38164 If there are insns that do not set the condition code but do alter 38165 other machine registers, this macro must check to see whether they 38166 invalidate the expressions that the condition code is recorded as 38167 reflecting. For example, on the 68000, insns that store in address 38168 registers do not set the condition code, which means that usually 38169 'NOTICE_UPDATE_CC' can leave 'cc_status' unaltered for such insns. 38170 But suppose that the previous insn set the condition code based on 38171 location 'a4@(102)' and the current insn stores a new value in 38172 'a4'. Although the condition code is not changed by this, it will 38173 no longer be true that it reflects the contents of 'a4@(102)'. 38174 Therefore, 'NOTICE_UPDATE_CC' must alter 'cc_status' in this case 38175 to say that nothing is known about the condition code value. 38176 38177 The definition of 'NOTICE_UPDATE_CC' must be prepared to deal with 38178 the results of peephole optimization: insns whose patterns are 38179 'parallel' RTXs containing various 'reg', 'mem' or constants which 38180 are just the operands. The RTL structure of these insns is not 38181 sufficient to indicate what the insns actually do. What 38182 'NOTICE_UPDATE_CC' should do when it sees one is just to run 38183 'CC_STATUS_INIT'. 38184 38185 A possible definition of 'NOTICE_UPDATE_CC' is to call a function 38186 that looks at an attribute (*note Insn Attributes::) named, for 38187 example, 'cc'. This avoids having detailed information about 38188 patterns in two places, the 'md' file and in 'NOTICE_UPDATE_CC'. 38189 38190 38191File: gccint.info, Node: MODE_CC Condition Codes, Prev: CC0 Condition Codes, Up: Condition Code 38192 3819318.15.2 Representation of condition codes using registers 38194--------------------------------------------------------- 38195 38196 -- Macro: SELECT_CC_MODE (OP, X, Y) 38197 On many machines, the condition code may be produced by other 38198 instructions than compares, for example the branch can use directly 38199 the condition code set by a subtract instruction. However, on some 38200 machines when the condition code is set this way some bits (such as 38201 the overflow bit) are not set in the same way as a test 38202 instruction, so that a different branch instruction must be used 38203 for some conditional branches. When this happens, use the machine 38204 mode of the condition code register to record different formats of 38205 the condition code register. Modes can also be used to record 38206 which compare instruction (e.g. a signed or an unsigned comparison) 38207 produced the condition codes. 38208 38209 If other modes than 'CCmode' are required, add them to 38210 'MACHINE-modes.def' and define 'SELECT_CC_MODE' to choose a mode 38211 given an operand of a compare. This is needed because the modes 38212 have to be chosen not only during RTL generation but also, for 38213 example, by instruction combination. The result of 38214 'SELECT_CC_MODE' should be consistent with the mode used in the 38215 patterns; for example to support the case of the add on the SPARC 38216 discussed above, we have the pattern 38217 38218 (define_insn "" 38219 [(set (reg:CCNZ 0) 38220 (compare:CCNZ 38221 (plus:SI (match_operand:SI 0 "register_operand" "%r") 38222 (match_operand:SI 1 "arith_operand" "rI")) 38223 (const_int 0)))] 38224 "" 38225 "...") 38226 38227 together with a 'SELECT_CC_MODE' that returns 'CCNZmode' for 38228 comparisons whose argument is a 'plus': 38229 38230 #define SELECT_CC_MODE(OP,X,Y) \ 38231 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 38232 ? ((OP == LT || OP == LE || OP == GT || OP == GE) \ 38233 ? CCFPEmode : CCFPmode) \ 38234 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 38235 || GET_CODE (X) == NEG || GET_CODE (x) == ASHIFT) \ 38236 ? CCNZmode : CCmode)) 38237 38238 Another reason to use modes is to retain information on which 38239 operands were used by the comparison; see 'REVERSIBLE_CC_MODE' 38240 later in this section. 38241 38242 You should define this macro if and only if you define extra CC 38243 modes in 'MACHINE-modes.def'. 38244 38245 -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx 38246 *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE) 38247 On some machines not all possible comparisons are defined, but you 38248 can convert an invalid comparison into a valid one. For example, 38249 the Alpha does not have a 'GT' comparison, but you can use an 'LT' 38250 comparison instead and swap the order of the operands. 38251 38252 On such machines, implement this hook to do any required 38253 conversions. CODE is the initial comparison code and OP0 and OP1 38254 are the left and right operands of the comparison, respectively. 38255 If OP0_PRESERVE_VALUE is 'true' the implementation is not allowed 38256 to change the value of OP0 since the value might be used in RTXs 38257 which aren't comparisons. E.g. the implementation is not allowed 38258 to swap operands in that case. 38259 38260 GCC will not assume that the comparison resulting from this macro 38261 is valid but will see if the resulting insn matches a pattern in 38262 the 'md' file. 38263 38264 You need not to implement this hook if it would never change the 38265 comparison code or operands. 38266 38267 -- Macro: REVERSIBLE_CC_MODE (MODE) 38268 A C expression whose value is one if it is always safe to reverse a 38269 comparison whose mode is MODE. If 'SELECT_CC_MODE' can ever return 38270 MODE for a floating-point inequality comparison, then 38271 'REVERSIBLE_CC_MODE (MODE)' must be zero. 38272 38273 You need not define this macro if it would always returns zero or 38274 if the floating-point format is anything other than 38275 'IEEE_FLOAT_FORMAT'. For example, here is the definition used on 38276 the SPARC, where floating-point inequality comparisons are given 38277 either 'CCFPEmode' or 'CCFPmode': 38278 38279 #define REVERSIBLE_CC_MODE(MODE) \ 38280 ((MODE) != CCFPEmode && (MODE) != CCFPmode) 38281 38282 -- Macro: REVERSE_CONDITION (CODE, MODE) 38283 A C expression whose value is reversed condition code of the CODE 38284 for comparison done in CC_MODE MODE. The macro is used only in 38285 case 'REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 38286 case machine has some non-standard way how to reverse certain 38287 conditionals. For instance in case all floating point conditions 38288 are non-trapping, compiler may freely convert unordered compares to 38289 ordered ones. Then definition may look like: 38290 38291 #define REVERSE_CONDITION(CODE, MODE) \ 38292 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 38293 : reverse_condition_maybe_unordered (CODE)) 38294 38295 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int 38296 *P1, unsigned int *P2) 38297 On targets which do not use '(cc0)', and which use a hard register 38298 rather than a pseudo-register to hold condition codes, the regular 38299 CSE passes are often not able to identify cases in which the hard 38300 register is set to a common value. Use this hook to enable a small 38301 pass which optimizes such cases. This hook should return true to 38302 enable this pass, and it should set the integers to which its 38303 arguments point to the hard register numbers used for condition 38304 codes. When there is only one such register, as is true on most 38305 systems, the integer pointed to by P2 should be set to 38306 'INVALID_REGNUM'. 38307 38308 The default version of this hook returns false. 38309 38310 -- Target Hook: machine_mode TARGET_CC_MODES_COMPATIBLE (machine_mode 38311 M1, machine_mode M2) 38312 On targets which use multiple condition code modes in class 38313 'MODE_CC', it is sometimes the case that a comparison can be 38314 validly done in more than one mode. On such a system, define this 38315 target hook to take two mode arguments and to return a mode in 38316 which both comparisons may be validly done. If there is no such 38317 mode, return 'VOIDmode'. 38318 38319 The default version of this hook checks whether the modes are the 38320 same. If they are, it returns that mode. If they are different, 38321 it returns 'VOIDmode'. 38322 38323 -- Target Hook: unsigned int TARGET_FLAGS_REGNUM 38324 If the target has a dedicated flags register, and it needs to use 38325 the post-reload comparison elimination pass, or the delay slot 38326 filler pass, then this value should be set appropriately. 38327 38328 38329File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 38330 3833118.16 Describing Relative Costs of Operations 38332============================================= 38333 38334These macros let you describe the relative speed of various operations 38335on the target machine. 38336 38337 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 38338 A C expression for the cost of moving data of mode MODE from a 38339 register in class FROM to one in class TO. The classes are 38340 expressed using the enumeration values such as 'GENERAL_REGS'. A 38341 value of 2 is the default; other values are interpreted relative to 38342 that. 38343 38344 It is not required that the cost always equal 2 when FROM is the 38345 same as TO; on some machines it is expensive to move between 38346 registers if they are not general registers. 38347 38348 If reload sees an insn consisting of a single 'set' between two 38349 hard registers, and if 'REGISTER_MOVE_COST' applied to their 38350 classes returns a value of 2, reload does not check to ensure that 38351 the constraints of the insn are met. Setting a cost of other than 38352 2 will allow reload to verify that the constraints are met. You 38353 should do this if the 'movM' pattern's constraints do not allow 38354 such copying. 38355 38356 These macros are obsolete, new ports should use the target hook 38357 'TARGET_REGISTER_MOVE_COST' instead. 38358 38359 -- Target Hook: int TARGET_REGISTER_MOVE_COST (machine_mode MODE, 38360 reg_class_t FROM, reg_class_t TO) 38361 This target hook should return the cost of moving data of mode MODE 38362 from a register in class FROM to one in class TO. The classes are 38363 expressed using the enumeration values such as 'GENERAL_REGS'. A 38364 value of 2 is the default; other values are interpreted relative to 38365 that. 38366 38367 It is not required that the cost always equal 2 when FROM is the 38368 same as TO; on some machines it is expensive to move between 38369 registers if they are not general registers. 38370 38371 If reload sees an insn consisting of a single 'set' between two 38372 hard registers, and if 'TARGET_REGISTER_MOVE_COST' applied to their 38373 classes returns a value of 2, reload does not check to ensure that 38374 the constraints of the insn are met. Setting a cost of other than 38375 2 will allow reload to verify that the constraints are met. You 38376 should do this if the 'movM' pattern's constraints do not allow 38377 such copying. 38378 38379 The default version of this function returns 2. 38380 38381 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 38382 A C expression for the cost of moving data of mode MODE between a 38383 register of class CLASS and memory; IN is zero if the value is to 38384 be written to memory, nonzero if it is to be read in. This cost is 38385 relative to those in 'REGISTER_MOVE_COST'. If moving between 38386 registers and memory is more expensive than between two registers, 38387 you should define this macro to express the relative cost. 38388 38389 If you do not define this macro, GCC uses a default cost of 4 plus 38390 the cost of copying via a secondary reload register, if one is 38391 needed. If your machine requires a secondary reload register to 38392 copy between memory and a register of CLASS but the reload 38393 mechanism is more complex than copying via an intermediate, define 38394 this macro to reflect the actual cost of the move. 38395 38396 GCC defines the function 'memory_move_secondary_cost' if secondary 38397 reloads are needed. It computes the costs due to copying via a 38398 secondary register. If your machine copies from memory using a 38399 secondary register in the conventional way but the default base 38400 value of 4 is not correct for your machine, define this macro to 38401 add some other value to the result of that function. The arguments 38402 to that function are the same as to this macro. 38403 38404 These macros are obsolete, new ports should use the target hook 38405 'TARGET_MEMORY_MOVE_COST' instead. 38406 38407 -- Target Hook: int TARGET_MEMORY_MOVE_COST (machine_mode MODE, 38408 reg_class_t RCLASS, bool IN) 38409 This target hook should return the cost of moving data of mode MODE 38410 between a register of class RCLASS and memory; IN is 'false' if the 38411 value is to be written to memory, 'true' if it is to be read in. 38412 This cost is relative to those in 'TARGET_REGISTER_MOVE_COST'. If 38413 moving between registers and memory is more expensive than between 38414 two registers, you should add this target hook to express the 38415 relative cost. 38416 38417 If you do not add this target hook, GCC uses a default cost of 4 38418 plus the cost of copying via a secondary reload register, if one is 38419 needed. If your machine requires a secondary reload register to 38420 copy between memory and a register of RCLASS but the reload 38421 mechanism is more complex than copying via an intermediate, use 38422 this target hook to reflect the actual cost of the move. 38423 38424 GCC defines the function 'memory_move_secondary_cost' if secondary 38425 reloads are needed. It computes the costs due to copying via a 38426 secondary register. If your machine copies from memory using a 38427 secondary register in the conventional way but the default base 38428 value of 4 is not correct for your machine, use this target hook to 38429 add some other value to the result of that function. The arguments 38430 to that function are the same as to this target hook. 38431 38432 -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P) 38433 A C expression for the cost of a branch instruction. A value of 1 38434 is the default; other values are interpreted relative to that. 38435 Parameter SPEED_P is true when the branch in question should be 38436 optimized for speed. When it is false, 'BRANCH_COST' should return 38437 a value optimal for code size rather than performance. 38438 PREDICTABLE_P is true for well-predicted branches. On many 38439 architectures the 'BRANCH_COST' can be reduced then. 38440 38441 Here are additional macros which do not specify precise relative costs, 38442but only that certain actions are more expensive than GCC would 38443ordinarily expect. 38444 38445 -- Macro: SLOW_BYTE_ACCESS 38446 Define this macro as a C expression which is nonzero if accessing 38447 less than a word of memory (i.e. a 'char' or a 'short') is no 38448 faster than accessing a word of memory, i.e., if such access 38449 require more than one instruction or if there is no difference in 38450 cost between byte and (aligned) word loads. 38451 38452 When this macro is not defined, the compiler will access a field by 38453 finding the smallest containing object; when it is defined, a 38454 fullword load will be used if alignment permits. Unless bytes 38455 accesses are faster than word accesses, using word accesses is 38456 preferable since it may eliminate subsequent memory access if 38457 subsequent accesses occur to other fields in the same word of the 38458 structure, but to different bytes. 38459 38460 -- Target Hook: bool TARGET_SLOW_UNALIGNED_ACCESS (machine_mode MODE, 38461 unsigned int ALIGN) 38462 This hook returns true if memory accesses described by the MODE and 38463 ALIGNMENT parameters have a cost many times greater than aligned 38464 accesses, for example if they are emulated in a trap handler. This 38465 hook is invoked only for unaligned accesses, i.e. when 'ALIGNMENT < 38466 GET_MODE_ALIGNMENT (MODE)'. 38467 38468 When this hook returns true, the compiler will act as if 38469 'STRICT_ALIGNMENT' were true when generating code for block moves. 38470 This can cause significantly more instructions to be produced. 38471 Therefore, do not make this hook return true if unaligned accesses 38472 only add a cycle or two to the time for a memory access. 38473 38474 The hook must return true whenever 'STRICT_ALIGNMENT' is true. The 38475 default implementation returns 'STRICT_ALIGNMENT'. 38476 38477 -- Macro: MOVE_RATIO (SPEED) 38478 The threshold of number of scalar memory-to-memory move insns, 38479 _below_ which a sequence of insns should be generated instead of a 38480 string move insn or a library call. Increasing the value will 38481 always make code faster, but eventually incurs high cost in 38482 increased code size. 38483 38484 Note that on machines where the corresponding move insn is a 38485 'define_expand' that emits a sequence of insns, this macro counts 38486 the number of such sequences. 38487 38488 The parameter SPEED is true if the code is currently being 38489 optimized for speed rather than size. 38490 38491 If you don't define this, a reasonable default is used. 38492 38493 -- Target Hook: bool TARGET_USE_BY_PIECES_INFRASTRUCTURE_P (unsigned 38494 HOST_WIDE_INT SIZE, unsigned int ALIGNMENT, enum 38495 by_pieces_operation OP, bool SPEED_P) 38496 GCC will attempt several strategies when asked to copy between two 38497 areas of memory, or to set, clear or store to memory, for example 38498 when copying a 'struct'. The 'by_pieces' infrastructure implements 38499 such memory operations as a sequence of load, store or move insns. 38500 Alternate strategies are to expand the 'cpymem' or 'setmem' optabs, 38501 to emit a library call, or to emit unit-by-unit, loop-based 38502 operations. 38503 38504 This target hook should return true if, for a memory operation with 38505 a given SIZE and ALIGNMENT, using the 'by_pieces' infrastructure is 38506 expected to result in better code generation. Both SIZE and 38507 ALIGNMENT are measured in terms of storage units. 38508 38509 The parameter OP is one of: 'CLEAR_BY_PIECES', 'MOVE_BY_PIECES', 38510 'SET_BY_PIECES', 'STORE_BY_PIECES' or 'COMPARE_BY_PIECES'. These 38511 describe the type of memory operation under consideration. 38512 38513 The parameter SPEED_P is true if the code is currently being 38514 optimized for speed rather than size. 38515 38516 Returning true for higher values of SIZE can improve code 38517 generation for speed if the target does not provide an 38518 implementation of the 'cpymem' or 'setmem' standard names, if the 38519 'cpymem' or 'setmem' implementation would be more expensive than a 38520 sequence of insns, or if the overhead of a library call would 38521 dominate that of the body of the memory operation. 38522 38523 Returning true for higher values of 'size' may also cause an 38524 increase in code size, for example where the number of insns 38525 emitted to perform a move would be greater than that of a library 38526 call. 38527 38528 -- Target Hook: int TARGET_COMPARE_BY_PIECES_BRANCH_RATIO (machine_mode 38529 MODE) 38530 When expanding a block comparison in MODE, gcc can try to reduce 38531 the number of branches at the expense of more memory operations. 38532 This hook allows the target to override the default choice. It 38533 should return the factor by which branches should be reduced over 38534 the plain expansion with one comparison per MODE-sized piece. A 38535 port can also prevent a particular mode from being used for block 38536 comparisons by returning a negative number from this hook. 38537 38538 -- Macro: MOVE_MAX_PIECES 38539 A C expression used by 'move_by_pieces' to determine the largest 38540 unit a load or store used to copy memory is. Defaults to 38541 'MOVE_MAX'. 38542 38543 -- Macro: STORE_MAX_PIECES 38544 A C expression used by 'store_by_pieces' to determine the largest 38545 unit a store used to memory is. Defaults to 'MOVE_MAX_PIECES', or 38546 two times the size of 'HOST_WIDE_INT', whichever is smaller. 38547 38548 -- Macro: COMPARE_MAX_PIECES 38549 A C expression used by 'compare_by_pieces' to determine the largest 38550 unit a load or store used to compare memory is. Defaults to 38551 'MOVE_MAX_PIECES'. 38552 38553 -- Macro: CLEAR_RATIO (SPEED) 38554 The threshold of number of scalar move insns, _below_ which a 38555 sequence of insns should be generated to clear memory instead of a 38556 string clear insn or a library call. Increasing the value will 38557 always make code faster, but eventually incurs high cost in 38558 increased code size. 38559 38560 The parameter SPEED is true if the code is currently being 38561 optimized for speed rather than size. 38562 38563 If you don't define this, a reasonable default is used. 38564 38565 -- Macro: SET_RATIO (SPEED) 38566 The threshold of number of scalar move insns, _below_ which a 38567 sequence of insns should be generated to set memory to a constant 38568 value, instead of a block set insn or a library call. Increasing 38569 the value will always make code faster, but eventually incurs high 38570 cost in increased code size. 38571 38572 The parameter SPEED is true if the code is currently being 38573 optimized for speed rather than size. 38574 38575 If you don't define this, it defaults to the value of 'MOVE_RATIO'. 38576 38577 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 38578 A C expression used to determine whether a load postincrement is a 38579 good thing to use for a given mode. Defaults to the value of 38580 'HAVE_POST_INCREMENT'. 38581 38582 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 38583 A C expression used to determine whether a load postdecrement is a 38584 good thing to use for a given mode. Defaults to the value of 38585 'HAVE_POST_DECREMENT'. 38586 38587 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 38588 A C expression used to determine whether a load preincrement is a 38589 good thing to use for a given mode. Defaults to the value of 38590 'HAVE_PRE_INCREMENT'. 38591 38592 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 38593 A C expression used to determine whether a load predecrement is a 38594 good thing to use for a given mode. Defaults to the value of 38595 'HAVE_PRE_DECREMENT'. 38596 38597 -- Macro: USE_STORE_POST_INCREMENT (MODE) 38598 A C expression used to determine whether a store postincrement is a 38599 good thing to use for a given mode. Defaults to the value of 38600 'HAVE_POST_INCREMENT'. 38601 38602 -- Macro: USE_STORE_POST_DECREMENT (MODE) 38603 A C expression used to determine whether a store postdecrement is a 38604 good thing to use for a given mode. Defaults to the value of 38605 'HAVE_POST_DECREMENT'. 38606 38607 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 38608 This macro is used to determine whether a store preincrement is a 38609 good thing to use for a given mode. Defaults to the value of 38610 'HAVE_PRE_INCREMENT'. 38611 38612 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 38613 This macro is used to determine whether a store predecrement is a 38614 good thing to use for a given mode. Defaults to the value of 38615 'HAVE_PRE_DECREMENT'. 38616 38617 -- Macro: NO_FUNCTION_CSE 38618 Define this macro to be true if it is as good or better to call a 38619 constant function address than to call an address kept in a 38620 register. 38621 38622 -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT 38623 Define this macro if a non-short-circuit operation produced by 38624 'fold_range_test ()' is optimal. This macro defaults to true if 38625 'BRANCH_COST' is greater than or equal to the value 2. 38626 38627 -- Target Hook: bool TARGET_OPTAB_SUPPORTED_P (int OP, machine_mode 38628 MODE1, machine_mode MODE2, optimization_type OPT_TYPE) 38629 Return true if the optimizers should use optab OP with modes MODE1 38630 and MODE2 for optimization type OPT_TYPE. The optab is known to 38631 have an associated '.md' instruction whose C condition is true. 38632 MODE2 is only meaningful for conversion optabs; for direct optabs 38633 it is a copy of MODE1. 38634 38635 For example, when called with OP equal to 'rint_optab' and MODE1 38636 equal to 'DFmode', the hook should say whether the optimizers 38637 should use optab 'rintdf2'. 38638 38639 The default hook returns true for all inputs. 38640 38641 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, machine_mode MODE, int 38642 OUTER_CODE, int OPNO, int *TOTAL, bool SPEED) 38643 This target hook describes the relative costs of RTL expressions. 38644 38645 The cost may depend on the precise form of the expression, which is 38646 available for examination in X, and the fact that X appears as 38647 operand OPNO of an expression with rtx code OUTER_CODE. That is, 38648 the hook can assume that there is some rtx Y such that 'GET_CODE 38649 (Y) == OUTER_CODE' and such that either (a) 'XEXP (Y, OPNO) == X' 38650 or (b) 'XVEC (Y, OPNO)' contains X. 38651 38652 MODE is X's machine mode, or for cases like 'const_int' that do not 38653 have a mode, the mode in which X is used. 38654 38655 In implementing this hook, you can use the construct 'COSTS_N_INSNS 38656 (N)' to specify a cost equal to N fast instructions. 38657 38658 On entry to the hook, '*TOTAL' contains a default estimate for the 38659 cost of the expression. The hook should modify this value as 38660 necessary. Traditionally, the default costs are 'COSTS_N_INSNS 38661 (5)' for multiplications, 'COSTS_N_INSNS (7)' for division and 38662 modulus operations, and 'COSTS_N_INSNS (1)' for all other 38663 operations. 38664 38665 When optimizing for code size, i.e. when 'speed' is false, this 38666 target hook should be used to estimate the relative size cost of an 38667 expression, again relative to 'COSTS_N_INSNS'. 38668 38669 The hook returns true when all subexpressions of X have been 38670 processed, and false when 'rtx_cost' should recurse. 38671 38672 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, machine_mode 38673 MODE, addr_space_t AS, bool SPEED) 38674 This hook computes the cost of an addressing mode that contains 38675 ADDRESS. If not defined, the cost is computed from the ADDRESS 38676 expression and the 'TARGET_RTX_COST' hook. 38677 38678 For most CISC machines, the default cost is a good approximation of 38679 the true cost of the addressing mode. However, on RISC machines, 38680 all instructions normally have the same length and execution time. 38681 Hence all addresses will have equal costs. 38682 38683 In cases where more than one form of an address is known, the form 38684 with the lowest cost will be used. If multiple forms have the 38685 same, lowest, cost, the one that is the most complex will be used. 38686 38687 For example, suppose an address that is equal to the sum of a 38688 register and a constant is used twice in the same basic block. 38689 When this macro is not defined, the address will be computed in a 38690 register and memory references will be indirect through that 38691 register. On machines where the cost of the addressing mode 38692 containing the sum is no higher than that of a simple indirect 38693 reference, this will produce an additional instruction and possibly 38694 require an additional register. Proper specification of this macro 38695 eliminates this overhead for such machines. 38696 38697 This hook is never called with an invalid address. 38698 38699 On machines where an address involving more than one register is as 38700 cheap as an address computation involving only one register, 38701 defining 'TARGET_ADDRESS_COST' to reflect this can cause two 38702 registers to be live over a region of code where only one would 38703 have been if 'TARGET_ADDRESS_COST' were not defined in that manner. 38704 This effect should be considered in the definition of this macro. 38705 Equivalent costs should probably only be given to addresses with 38706 different numbers of registers on machines with lots of registers. 38707 38708 -- Target Hook: int TARGET_INSN_COST (rtx_insn *INSN, bool SPEED) 38709 This target hook describes the relative costs of RTL instructions. 38710 38711 In implementing this hook, you can use the construct 'COSTS_N_INSNS 38712 (N)' to specify a cost equal to N fast instructions. 38713 38714 When optimizing for code size, i.e. when 'speed' is false, this 38715 target hook should be used to estimate the relative size cost of an 38716 expression, again relative to 'COSTS_N_INSNS'. 38717 38718 -- Target Hook: unsigned int TARGET_MAX_NOCE_IFCVT_SEQ_COST (edge E) 38719 This hook returns a value in the same units as 'TARGET_RTX_COSTS', 38720 giving the maximum acceptable cost for a sequence generated by the 38721 RTL if-conversion pass when conditional execution is not available. 38722 The RTL if-conversion pass attempts to convert conditional 38723 operations that would require a branch to a series of unconditional 38724 operations and 'movMODEcc' insns. This hook returns the maximum 38725 cost of the unconditional instructions and the 'movMODEcc' insns. 38726 RTL if-conversion is cancelled if the cost of the converted 38727 sequence is greater than the value returned by this hook. 38728 38729 'e' is the edge between the basic block containing the conditional 38730 branch to the basic block which would be executed if the condition 38731 were true. 38732 38733 The default implementation of this hook uses the 38734 'max-rtl-if-conversion-[un]predictable' parameters if they are set, 38735 and uses a multiple of 'BRANCH_COST' otherwise. 38736 38737 -- Target Hook: bool TARGET_NOCE_CONVERSION_PROFITABLE_P (rtx_insn 38738 *SEQ, struct noce_if_info *IF_INFO) 38739 This hook returns true if the instruction sequence 'seq' is a good 38740 candidate as a replacement for the if-convertible sequence 38741 described in 'if_info'. 38742 38743 -- Target Hook: bool TARGET_NEW_ADDRESS_PROFITABLE_P (rtx MEMREF, 38744 rtx_insn * INSN, rtx NEW_ADDR) 38745 Return 'true' if it is profitable to replace the address in MEMREF 38746 with NEW_ADDR. This allows targets to prevent the scheduler from 38747 undoing address optimizations. The instruction containing the 38748 memref is INSN. The default implementation returns 'true'. 38749 38750 -- Target Hook: bool TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P (void) 38751 This predicate controls the use of the eager delay slot filler to 38752 disallow speculatively executed instructions being placed in delay 38753 slots. Targets such as certain MIPS architectures possess both 38754 branches with and without delay slots. As the eager delay slot 38755 filler can decrease performance, disabling it is beneficial when 38756 ordinary branches are available. Use of delay slot branches filled 38757 using the basic filler is often still desirable as the delay slot 38758 can hide a pipeline bubble. 38759 38760 -- Target Hook: HOST_WIDE_INT TARGET_ESTIMATED_POLY_VALUE (poly_int64 38761 VAL, poly_value_estimate_kind KIND) 38762 Return an estimate of the runtime value of VAL, for use in things 38763 like cost calculations or profiling frequencies. KIND is used to 38764 ask for the minimum, maximum, and likely estimates of the value 38765 through the 'POLY_VALUE_MIN', 'POLY_VALUE_MAX' and 38766 'POLY_VALUE_LIKELY' values. The default implementation returns the 38767 lowest possible value of VAL. 38768 38769 38770File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 38771 3877218.17 Adjusting the Instruction Scheduler 38773========================================= 38774 38775The instruction scheduler may need a fair amount of machine-specific 38776adjustment in order to produce good code. GCC provides several target 38777hooks for this purpose. It is usually enough to define just a few of 38778them: try the first ones in this list first. 38779 38780 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 38781 This hook returns the maximum number of instructions that can ever 38782 issue at the same time on the target machine. The default is one. 38783 Although the insn scheduler can define itself the possibility of 38784 issue an insn on the same cycle, the value can serve as an 38785 additional constraint to issue insns on the same simulated 38786 processor cycle (see hooks 'TARGET_SCHED_REORDER' and 38787 'TARGET_SCHED_REORDER2'). This value must be constant over the 38788 entire compilation. If you need it to vary depending on what the 38789 instructions are, you must use 'TARGET_SCHED_VARIABLE_ISSUE'. 38790 38791 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 38792 VERBOSE, rtx_insn *INSN, int MORE) 38793 This hook is executed by the scheduler after it has scheduled an 38794 insn from the ready list. It should return the number of insns 38795 which can still be issued in the current cycle. The default is 38796 'MORE - 1' for insns other than 'CLOBBER' and 'USE', which normally 38797 are not counted against the issue rate. You should define this 38798 hook if some insns take more machine resources than others, so that 38799 fewer insns can follow them in the same cycle. FILE is either a 38800 null pointer, or a stdio stream to write any debug output to. 38801 VERBOSE is the verbose level provided by '-fsched-verbose-N'. INSN 38802 is the instruction that was scheduled. 38803 38804 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx_insn *INSN, int 38805 DEP_TYPE1, rtx_insn *DEP_INSN, int COST, unsigned int DW) 38806 This function corrects the value of COST based on the relationship 38807 between INSN and DEP_INSN through a dependence of type dep_type, 38808 and strength DW. It should return the new value. The default is 38809 to make no adjustment to COST. This can be used for example to 38810 specify to the scheduler using the traditional pipeline description 38811 that an output- or anti-dependence does not incur the same cost as 38812 a data-dependence. If the scheduler using the automaton based 38813 pipeline description, the cost of anti-dependence is zero and the 38814 cost of output-dependence is maximum of one and the difference of 38815 latency times of the first and the second insns. If these values 38816 are not acceptable, you could use the hook to modify them too. See 38817 also *note Processor pipeline description::. 38818 38819 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx_insn *INSN, int 38820 PRIORITY) 38821 This hook adjusts the integer scheduling priority PRIORITY of INSN. 38822 It should return the new priority. Increase the priority to 38823 execute INSN earlier, reduce the priority to execute INSN later. 38824 Do not define this hook if you do not need to adjust the scheduling 38825 priorities of insns. 38826 38827 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, 38828 rtx_insn **READY, int *N_READYP, int CLOCK) 38829 This hook is executed by the scheduler after it has scheduled the 38830 ready list, to allow the machine description to reorder it (for 38831 example to combine two small instructions together on 'VLIW' 38832 machines). FILE is either a null pointer, or a stdio stream to 38833 write any debug output to. VERBOSE is the verbose level provided 38834 by '-fsched-verbose-N'. READY is a pointer to the ready list of 38835 instructions that are ready to be scheduled. N_READYP is a pointer 38836 to the number of elements in the ready list. The scheduler reads 38837 the ready list in reverse order, starting with READY[*N_READYP - 1] 38838 and going to READY[0]. CLOCK is the timer tick of the scheduler. 38839 You may modify the ready list and the number of ready insns. The 38840 return value is the number of insns that can issue this cycle; 38841 normally this is just 'issue_rate'. See also 38842 'TARGET_SCHED_REORDER2'. 38843 38844 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 38845 rtx_insn **READY, int *N_READYP, int CLOCK) 38846 Like 'TARGET_SCHED_REORDER', but called at a different time. That 38847 function is called whenever the scheduler starts a new cycle. This 38848 one is called once per iteration over a cycle, immediately after 38849 'TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list and 38850 return the number of insns to be scheduled in the same cycle. 38851 Defining this hook can be useful if there are frequent situations 38852 where scheduling one insn causes other insns to become ready in the 38853 same cycle. These other insns can then be taken into account 38854 properly. 38855 38856 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_P (void) 38857 This hook is used to check whether target platform supports macro 38858 fusion. 38859 38860 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_PAIR_P (rtx_insn *PREV, 38861 rtx_insn *CURR) 38862 This hook is used to check whether two insns should be macro fused 38863 for a target microarchitecture. If this hook returns true for the 38864 given insn pair (PREV and CURR), the scheduler will put them into a 38865 sched group, and they will not be scheduled apart. The two insns 38866 will be either two SET insns or a compare and a conditional jump 38867 and this hook should validate any dependencies needed to fuse the 38868 two insns together. 38869 38870 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK 38871 (rtx_insn *HEAD, rtx_insn *TAIL) 38872 This hook is called after evaluation forward dependencies of insns 38873 in chain given by two parameter values (HEAD and TAIL 38874 correspondingly) but before insns scheduling of the insn chain. 38875 For example, it can be used for better insn classification if it 38876 requires analysis of dependencies. This hook can use backward and 38877 forward dependencies of the insn scheduler because they are already 38878 calculated. 38879 38880 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 38881 MAX_READY) 38882 This hook is executed by the scheduler at the beginning of each 38883 block of instructions that are to be scheduled. FILE is either a 38884 null pointer, or a stdio stream to write any debug output to. 38885 VERBOSE is the verbose level provided by '-fsched-verbose-N'. 38886 MAX_READY is the maximum number of insns in the current scheduling 38887 region that can be live at the same time. This can be used to 38888 allocate scratch space if it is needed, e.g. by 38889 'TARGET_SCHED_REORDER'. 38890 38891 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 38892 This hook is executed by the scheduler at the end of each block of 38893 instructions that are to be scheduled. It can be used to perform 38894 cleanup of any actions done by the other scheduling hooks. FILE is 38895 either a null pointer, or a stdio stream to write any debug output 38896 to. VERBOSE is the verbose level provided by '-fsched-verbose-N'. 38897 38898 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int VERBOSE, 38899 int OLD_MAX_UID) 38900 This hook is executed by the scheduler after function level 38901 initializations. FILE is either a null pointer, or a stdio stream 38902 to write any debug output to. VERBOSE is the verbose level 38903 provided by '-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 38904 uid when scheduling begins. 38905 38906 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 38907 VERBOSE) 38908 This is the cleanup hook corresponding to 38909 'TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 38910 stdio stream to write any debug output to. VERBOSE is the verbose 38911 level provided by '-fsched-verbose-N'. 38912 38913 -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 38914 The hook returns an RTL insn. The automaton state used in the 38915 pipeline hazard recognizer is changed as if the insn were scheduled 38916 when the new simulated processor cycle starts. Usage of the hook 38917 may simplify the automaton pipeline description for some VLIW 38918 processors. If the hook is defined, it is used only for the 38919 automaton based pipeline description. The default is not to change 38920 the state when the new simulated processor cycle starts. 38921 38922 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 38923 The hook can be used to initialize data used by the previous hook. 38924 38925 -- Target Hook: rtx_insn * TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 38926 The hook is analogous to 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 38927 to changed the state as if the insn were scheduled when the new 38928 simulated processor cycle finishes. 38929 38930 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 38931 The hook is analogous to 'TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 38932 used to initialize data used by the previous hook. 38933 38934 -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void) 38935 The hook to notify target that the current simulated cycle is about 38936 to finish. The hook is analogous to 38937 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in 38938 more complicated situations - e.g., when advancing state on a 38939 single insn is not enough. 38940 38941 -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void) 38942 The hook to notify target that new simulated cycle has just 38943 started. The hook is analogous to 38944 'TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in 38945 more complicated situations - e.g., when advancing state on a 38946 single insn is not enough. 38947 38948 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 38949 (void) 38950 This hook controls better choosing an insn from the ready insn 38951 queue for the DFA-based insn scheduler. Usually the scheduler 38952 chooses the first insn from the queue. If the hook returns a 38953 positive value, an additional scheduler code tries all permutations 38954 of 'TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD ()' subsequent 38955 ready insns to choose an insn whose issue will result in maximal 38956 number of issued insns on the same cycle. For the VLIW processor, 38957 the code could actually solve the problem of packing simple insns 38958 into the VLIW insn. Of course, if the rules of VLIW packing are 38959 described in the automaton. 38960 38961 This code also could be used for superscalar RISC processors. Let 38962 us consider a superscalar RISC processor with 3 pipelines. Some 38963 insns can be executed in pipelines A or B, some insns can be 38964 executed only in pipelines B or C, and one insn can be executed in 38965 pipeline B. The processor may issue the 1st insn into A and the 38966 2nd one into B. In this case, the 3rd insn will wait for freeing B 38967 until the next cycle. If the scheduler issues the 3rd insn the 38968 first, the processor could issue all 3 insns per cycle. 38969 38970 Actually this code demonstrates advantages of the automaton based 38971 pipeline hazard recognizer. We try quickly and easy many insn 38972 schedules to choose the best one. 38973 38974 The default is no multipass scheduling. 38975 38976 -- Target Hook: int 38977 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD 38978 (rtx_insn *INSN, int READY_INDEX) 38979 38980 This hook controls what insns from the ready insn queue will be 38981 considered for the multipass insn scheduling. If the hook returns 38982 zero for INSN, the insn will be considered in multipass scheduling. 38983 Positive return values will remove INSN from consideration on the 38984 current round of multipass scheduling. Negative return values will 38985 remove INSN from consideration for given number of cycles. 38986 Backends should be careful about returning non-zero for highest 38987 priority instruction at position 0 in the ready list. READY_INDEX 38988 is passed to allow backends make correct judgements. 38989 38990 The default is that any ready insns can be chosen to be issued. 38991 38992 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void 38993 *DATA, signed char *READY_TRY, int N_READY, bool 38994 FIRST_CYCLE_INSN_P) 38995 This hook prepares the target backend for a new round of multipass 38996 scheduling. 38997 38998 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void 38999 *DATA, signed char *READY_TRY, int N_READY, rtx_insn *INSN, 39000 const void *PREV_DATA) 39001 This hook is called when multipass scheduling evaluates instruction 39002 INSN. 39003 39004 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK 39005 (const void *DATA, signed char *READY_TRY, int N_READY) 39006 This is called when multipass scheduling backtracks from evaluation 39007 of an instruction. 39008 39009 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const void 39010 *DATA) 39011 This hook notifies the target about the result of the concluded 39012 current round of multipass scheduling. 39013 39014 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void 39015 *DATA) 39016 This hook initializes target-specific data used in multipass 39017 scheduling. 39018 39019 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void 39020 *DATA) 39021 This hook finalizes target-specific data used in multipass 39022 scheduling. 39023 39024 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int 39025 VERBOSE, rtx_insn *INSN, int LAST_CLOCK, int CLOCK, int 39026 *SORT_P) 39027 This hook is called by the insn scheduler before issuing INSN on 39028 cycle CLOCK. If the hook returns nonzero, INSN is not issued on 39029 this processor cycle. Instead, the processor cycle is advanced. 39030 If *SORT_P is zero, the insn ready queue is not sorted on the new 39031 cycle start as usually. DUMP and VERBOSE specify the file and 39032 verbosity level to use for debugging output. LAST_CLOCK and CLOCK 39033 are, respectively, the processor cycle on which the previous insn 39034 has been issued, and the current processor cycle. 39035 39036 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep 39037 *_DEP, int COST, int DISTANCE) 39038 This hook is used to define which dependences are considered costly 39039 by the target, so costly that it is not advisable to schedule the 39040 insns that are involved in the dependence too close to one another. 39041 The parameters to this hook are as follows: The first parameter 39042 _DEP is the dependence being evaluated. The second parameter COST 39043 is the cost of the dependence as estimated by the scheduler, and 39044 the third parameter DISTANCE is the distance in cycles between the 39045 two insns. The hook returns 'true' if considering the distance 39046 between the two insns the dependence between them is considered 39047 costly by the target, and 'false' otherwise. 39048 39049 Defining this hook can be useful in multiple-issue out-of-order 39050 machines, where (a) it's practically hopeless to predict the actual 39051 data/resource delays, however: (b) there's a better chance to 39052 predict the actual grouping that will be formed, and (c) correctly 39053 emulating the grouping can be very important. In such targets one 39054 may want to allow issuing dependent insns closer to one 39055 another--i.e., closer than the dependence distance; however, not in 39056 cases of "costly dependences", which this hooks allows to define. 39057 39058 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 39059 This hook is called by the insn scheduler after emitting a new 39060 instruction to the instruction stream. The hook notifies a target 39061 backend to extend its per instruction data structures. 39062 39063 -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void) 39064 Return a pointer to a store large enough to hold target scheduling 39065 context. 39066 39067 -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool 39068 CLEAN_P) 39069 Initialize store pointed to by TC to hold target scheduling 39070 context. It CLEAN_P is true then initialize TC as if scheduler is 39071 at the beginning of the block. Otherwise, copy the current context 39072 into TC. 39073 39074 -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC) 39075 Copy target scheduling context pointed to by TC to the current 39076 context. 39077 39078 -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC) 39079 Deallocate internal data in target scheduling context pointed to by 39080 TC. 39081 39082 -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC) 39083 Deallocate a store for target scheduling context pointed to by TC. 39084 39085 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx_insn *INSN, 39086 unsigned int DEP_STATUS, rtx *NEW_PAT) 39087 This hook is called by the insn scheduler when INSN has only 39088 speculative dependencies and therefore can be scheduled 39089 speculatively. The hook is used to check if the pattern of INSN 39090 has a speculative version and, in case of successful check, to 39091 generate that speculative pattern. The hook should return 1, if 39092 the instruction has a speculative form, or -1, if it doesn't. 39093 REQUEST describes the type of requested speculation. If the return 39094 value equals 1 then NEW_PAT is assigned the generated speculative 39095 pattern. 39096 39097 -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (unsigned int 39098 DEP_STATUS) 39099 This hook is called by the insn scheduler during generation of 39100 recovery code for INSN. It should return 'true', if the 39101 corresponding check instruction should branch to recovery code, or 39102 'false' otherwise. 39103 39104 -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx_insn *INSN, 39105 rtx_insn *LABEL, unsigned int DS) 39106 This hook is called by the insn scheduler to generate a pattern for 39107 recovery check instruction. If MUTATE_P is zero, then INSN is a 39108 speculative instruction for which the check should be generated. 39109 LABEL is either a label of a basic block, where recovery code 39110 should be emitted, or a null pointer, when requested check doesn't 39111 branch to recovery code (a simple check). If MUTATE_P is nonzero, 39112 then a pattern for a branchy check corresponding to a simple check 39113 denoted by INSN should be generated. In this case LABEL can't be 39114 null. 39115 39116 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct spec_info_def 39117 *SPEC_INFO) 39118 This hook is used by the insn scheduler to find out what features 39119 should be enabled/used. The structure *SPEC_INFO should be filled 39120 in by the target. The structure describes speculation types that 39121 can be used in the scheduler. 39122 39123 -- Target Hook: bool TARGET_SCHED_CAN_SPECULATE_INSN (rtx_insn *INSN) 39124 Some instructions should never be speculated by the schedulers, 39125 usually because the instruction is too expensive to get this wrong. 39126 Often such instructions have long latency, and often they are not 39127 fully modeled in the pipeline descriptions. This hook should 39128 return 'false' if INSN should not be speculated. 39129 39130 -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G) 39131 This hook is called by the swing modulo scheduler to calculate a 39132 resource-based lower bound which is based on the resources 39133 available in the machine and the resources required by each 39134 instruction. The target backend can use G to calculate such bound. 39135 A very simple lower bound will be used in case this hook is not 39136 implemented: the total number of instructions divided by the issue 39137 rate. 39138 39139 -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx_insn *INSN, int X) 39140 This hook is called by Haifa Scheduler. It returns true if 39141 dispatch scheduling is supported in hardware and the condition 39142 specified in the parameter is true. 39143 39144 -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx_insn *INSN, int X) 39145 This hook is called by Haifa Scheduler. It performs the operation 39146 specified in its second parameter. 39147 39148 -- Target Hook: bool TARGET_SCHED_EXPOSED_PIPELINE 39149 True if the processor has an exposed pipeline, which means that not 39150 just the order of instructions is important for correctness when 39151 scheduling, but also the latencies of operations. 39152 39153 -- Target Hook: int TARGET_SCHED_REASSOCIATION_WIDTH (unsigned int OPC, 39154 machine_mode MODE) 39155 This hook is called by tree reassociator to determine a level of 39156 parallelism required in output calculations chain. 39157 39158 -- Target Hook: void TARGET_SCHED_FUSION_PRIORITY (rtx_insn *INSN, int 39159 MAX_PRI, int *FUSION_PRI, int *PRI) 39160 This hook is called by scheduling fusion pass. It calculates 39161 fusion priorities for each instruction passed in by parameter. The 39162 priorities are returned via pointer parameters. 39163 39164 INSN is the instruction whose priorities need to be calculated. 39165 MAX_PRI is the maximum priority can be returned in any cases. 39166 FUSION_PRI is the pointer parameter through which INSN's fusion 39167 priority should be calculated and returned. PRI is the pointer 39168 parameter through which INSN's priority should be calculated and 39169 returned. 39170 39171 Same FUSION_PRI should be returned for instructions which should be 39172 scheduled together. Different PRI should be returned for 39173 instructions with same FUSION_PRI. FUSION_PRI is the major sort 39174 key, PRI is the minor sort key. All instructions will be scheduled 39175 according to the two priorities. All priorities calculated should 39176 be between 0 (exclusive) and MAX_PRI (inclusive). To avoid false 39177 dependencies, FUSION_PRI of instructions which need to be scheduled 39178 together should be smaller than FUSION_PRI of irrelevant 39179 instructions. 39180 39181 Given below example: 39182 39183 ldr r10, [r1, 4] 39184 add r4, r4, r10 39185 ldr r15, [r2, 8] 39186 sub r5, r5, r15 39187 ldr r11, [r1, 0] 39188 add r4, r4, r11 39189 ldr r16, [r2, 12] 39190 sub r5, r5, r16 39191 39192 On targets like ARM/AArch64, the two pairs of consecutive loads 39193 should be merged. Since peephole2 pass can't help in this case 39194 unless consecutive loads are actually next to each other in 39195 instruction flow. That's where this scheduling fusion pass works. 39196 This hook calculates priority for each instruction based on its 39197 fustion type, like: 39198 39199 ldr r10, [r1, 4] ; fusion_pri=99, pri=96 39200 add r4, r4, r10 ; fusion_pri=100, pri=100 39201 ldr r15, [r2, 8] ; fusion_pri=98, pri=92 39202 sub r5, r5, r15 ; fusion_pri=100, pri=100 39203 ldr r11, [r1, 0] ; fusion_pri=99, pri=100 39204 add r4, r4, r11 ; fusion_pri=100, pri=100 39205 ldr r16, [r2, 12] ; fusion_pri=98, pri=88 39206 sub r5, r5, r16 ; fusion_pri=100, pri=100 39207 39208 Scheduling fusion pass then sorts all ready to issue instructions 39209 according to the priorities. As a result, instructions of same 39210 fusion type will be pushed together in instruction flow, like: 39211 39212 ldr r11, [r1, 0] 39213 ldr r10, [r1, 4] 39214 ldr r15, [r2, 8] 39215 ldr r16, [r2, 12] 39216 add r4, r4, r10 39217 sub r5, r5, r15 39218 add r4, r4, r11 39219 sub r5, r5, r16 39220 39221 Now peephole2 pass can simply merge the two pairs of loads. 39222 39223 Since scheduling fusion pass relies on peephole2 to do real fusion 39224 work, it is only enabled by default when peephole2 is in effect. 39225 39226 This is firstly introduced on ARM/AArch64 targets, please refer to 39227 the hook implementation for how different fusion types are 39228 supported. 39229 39230 -- Target Hook: void TARGET_EXPAND_DIVMOD_LIBFUNC (rtx LIBFUNC, 39231 machine_mode MODE, rtx OP0, rtx OP1, rtx *QUOT, rtx *REM) 39232 Define this hook for enabling divmod transform if the port does not 39233 have hardware divmod insn but defines target-specific divmod 39234 libfuncs. 39235 39236 39237File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 39238 3923918.18 Dividing the Output into Sections (Texts, Data, ...) 39240========================================================== 39241 39242An object file is divided into sections containing different types of 39243data. In the most common case, there are three sections: the "text 39244section", which holds instructions and read-only data; the "data 39245section", which holds initialized writable data; and the "bss section", 39246which holds uninitialized data. Some systems have other kinds of 39247sections. 39248 39249 'varasm.c' provides several well-known sections, such as 39250'text_section', 'data_section' and 'bss_section'. The normal way of 39251controlling a 'FOO_section' variable is to define the associated 39252'FOO_SECTION_ASM_OP' macro, as described below. The macros are only 39253read once, when 'varasm.c' initializes itself, so their values must be 39254run-time constants. They may however depend on command-line flags. 39255 39256 _Note:_ Some run-time files, such 'crtstuff.c', also make use of the 39257'FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 39258 39259 Some assemblers require a different string to be written every time a 39260section is selected. If your assembler falls into this category, you 39261should define the 'TARGET_ASM_INIT_SECTIONS' hook and use 39262'get_unnamed_section' to set up the sections. 39263 39264 You must always create a 'text_section', either by defining 39265'TEXT_SECTION_ASM_OP' or by initializing 'text_section' in 39266'TARGET_ASM_INIT_SECTIONS'. The same is true of 'data_section' and 39267'DATA_SECTION_ASM_OP'. If you do not create a distinct 39268'readonly_data_section', the default is to reuse 'text_section'. 39269 39270 All the other 'varasm.c' sections are optional, and are null if the 39271target does not provide them. 39272 39273 -- Macro: TEXT_SECTION_ASM_OP 39274 A C expression whose value is a string, including spacing, 39275 containing the assembler operation that should precede instructions 39276 and read-only data. Normally '"\t.text"' is right. 39277 39278 -- Macro: HOT_TEXT_SECTION_NAME 39279 If defined, a C string constant for the name of the section 39280 containing most frequently executed functions of the program. If 39281 not defined, GCC will provide a default definition if the target 39282 supports named sections. 39283 39284 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 39285 If defined, a C string constant for the name of the section 39286 containing unlikely executed functions in the program. 39287 39288 -- Macro: DATA_SECTION_ASM_OP 39289 A C expression whose value is a string, including spacing, 39290 containing the assembler operation to identify the following data 39291 as writable initialized data. Normally '"\t.data"' is right. 39292 39293 -- Macro: SDATA_SECTION_ASM_OP 39294 If defined, a C expression whose value is a string, including 39295 spacing, containing the assembler operation to identify the 39296 following data as initialized, writable small data. 39297 39298 -- Macro: READONLY_DATA_SECTION_ASM_OP 39299 A C expression whose value is a string, including spacing, 39300 containing the assembler operation to identify the following data 39301 as read-only initialized data. 39302 39303 -- Macro: BSS_SECTION_ASM_OP 39304 If defined, a C expression whose value is a string, including 39305 spacing, containing the assembler operation to identify the 39306 following data as uninitialized global data. If not defined, and 39307 'ASM_OUTPUT_ALIGNED_BSS' not defined, uninitialized global data 39308 will be output in the data section if '-fno-common' is passed, 39309 otherwise 'ASM_OUTPUT_COMMON' will be used. 39310 39311 -- Macro: SBSS_SECTION_ASM_OP 39312 If defined, a C expression whose value is a string, including 39313 spacing, containing the assembler operation to identify the 39314 following data as uninitialized, writable small data. 39315 39316 -- Macro: TLS_COMMON_ASM_OP 39317 If defined, a C expression whose value is a string containing the 39318 assembler operation to identify the following data as thread-local 39319 common data. The default is '".tls_common"'. 39320 39321 -- Macro: TLS_SECTION_ASM_FLAG 39322 If defined, a C expression whose value is a character constant 39323 containing the flag used to mark a section as a TLS section. The 39324 default is ''T''. 39325 39326 -- Macro: INIT_SECTION_ASM_OP 39327 If defined, a C expression whose value is a string, including 39328 spacing, containing the assembler operation to identify the 39329 following data as initialization code. If not defined, GCC will 39330 assume such a section does not exist. This section has no 39331 corresponding 'init_section' variable; it is used entirely in 39332 runtime code. 39333 39334 -- Macro: FINI_SECTION_ASM_OP 39335 If defined, a C expression whose value is a string, including 39336 spacing, containing the assembler operation to identify the 39337 following data as finalization code. If not defined, GCC will 39338 assume such a section does not exist. This section has no 39339 corresponding 'fini_section' variable; it is used entirely in 39340 runtime code. 39341 39342 -- Macro: INIT_ARRAY_SECTION_ASM_OP 39343 If defined, a C expression whose value is a string, including 39344 spacing, containing the assembler operation to identify the 39345 following data as part of the '.init_array' (or equivalent) 39346 section. If not defined, GCC will assume such a section does not 39347 exist. Do not define both this macro and 'INIT_SECTION_ASM_OP'. 39348 39349 -- Macro: FINI_ARRAY_SECTION_ASM_OP 39350 If defined, a C expression whose value is a string, including 39351 spacing, containing the assembler operation to identify the 39352 following data as part of the '.fini_array' (or equivalent) 39353 section. If not defined, GCC will assume such a section does not 39354 exist. Do not define both this macro and 'FINI_SECTION_ASM_OP'. 39355 39356 -- Macro: MACH_DEP_SECTION_ASM_FLAG 39357 If defined, a C expression whose value is a character constant 39358 containing the flag used to mark a machine-dependent section. This 39359 corresponds to the 'SECTION_MACH_DEP' section flag. 39360 39361 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 39362 If defined, an ASM statement that switches to a different section 39363 via SECTION_OP, calls FUNCTION, and switches back to the text 39364 section. This is used in 'crtstuff.c' if 'INIT_SECTION_ASM_OP' or 39365 'FINI_SECTION_ASM_OP' to calls to initialization and finalization 39366 functions from the init and fini sections. By default, this macro 39367 uses a simple function call. Some ports need hand-crafted assembly 39368 code to avoid dependencies on registers initialized in the function 39369 prologue or to ensure that constant pools don't end up too far way 39370 in the text section. 39371 39372 -- Macro: TARGET_LIBGCC_SDATA_SECTION 39373 If defined, a string which names the section into which small 39374 variables defined in crtstuff and libgcc should go. This is useful 39375 when the target has options for optimizing access to small data, 39376 and you want the crtstuff and libgcc routines to be conservative in 39377 what they expect of your application yet liberal in what your 39378 application expects. For example, for targets with a '.sdata' 39379 section (like MIPS), you could compile crtstuff with '-G 0' so that 39380 it doesn't require small data support from your application, but 39381 use this macro to put small data into '.sdata' so that your 39382 application can access these variables whether it uses small data 39383 or not. 39384 39385 -- Macro: FORCE_CODE_SECTION_ALIGN 39386 If defined, an ASM statement that aligns a code section to some 39387 arbitrary boundary. This is used to force all fragments of the 39388 '.init' and '.fini' sections to have to same alignment and thus 39389 prevent the linker from having to add any padding. 39390 39391 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 39392 Define this macro to be an expression with a nonzero value if jump 39393 tables (for 'tablejump' insns) should be output in the text 39394 section, along with the assembler instructions. Otherwise, the 39395 readonly data section is used. 39396 39397 This macro is irrelevant if there is no separate readonly data 39398 section. 39399 39400 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 39401 Define this hook if you need to do something special to set up the 39402 'varasm.c' sections, or if your target has some special sections of 39403 its own that you need to create. 39404 39405 GCC calls this hook after processing the command line, but before 39406 writing any assembly code, and before calling any of the 39407 section-returning hooks described below. 39408 39409 -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void) 39410 Return a mask describing how relocations should be treated when 39411 selecting sections. Bit 1 should be set if global relocations 39412 should be placed in a read-write section; bit 0 should be set if 39413 local relocations should be placed in a read-write section. 39414 39415 The default version of this function returns 3 when '-fpic' is in 39416 effect, and 0 otherwise. The hook is typically redefined when the 39417 target cannot support (some kinds of) dynamic relocations in 39418 read-only sections even in executables. 39419 39420 -- Target Hook: bool TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC (void) 39421 Return true to generate ADDR_DIF_VEC table or false to generate 39422 ADDR_VEC table for jumps in case of -fPIC. 39423 39424 The default version of this function returns true if flag_pic 39425 equals true and false otherwise 39426 39427 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 39428 RELOC, unsigned HOST_WIDE_INT ALIGN) 39429 Return the section into which EXP should be placed. You can assume 39430 that EXP is either a 'VAR_DECL' node or a constant of some sort. 39431 RELOC indicates whether the initial value of EXP requires link-time 39432 relocations. Bit 0 is set when variable contains local relocations 39433 only, while bit 1 is set for global relocations. ALIGN is the 39434 constant alignment in bits. 39435 39436 The default version of this function takes care of putting 39437 read-only variables in 'readonly_data_section'. 39438 39439 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 39440 39441 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 39442 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 39443 called for 'FUNCTION_DECL's as well as for variables and constants. 39444 39445 In the case of a 'FUNCTION_DECL', RELOC will be zero if the 39446 function has been determined to be likely to be called, and nonzero 39447 if it is unlikely to be called. 39448 39449 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 39450 Build up a unique section name, expressed as a 'STRING_CST' node, 39451 and assign it to 'DECL_SECTION_NAME (DECL)'. As with 39452 'TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 39453 value of EXP requires link-time relocations. 39454 39455 The default version of this function appends the symbol name to the 39456 ELF section name that would normally be used for the symbol. For 39457 example, the function 'foo' would be placed in '.text.foo'. 39458 Whatever the actual target object format, this is often good 39459 enough. 39460 39461 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 39462 DECL, bool RELOCATABLE) 39463 Return the readonly data or reloc readonly data section associated 39464 with 'DECL_SECTION_NAME (DECL)'. RELOCATABLE selects the latter 39465 over the former. The default version of this function selects 39466 '.gnu.linkonce.r.name' if the function's section is 39467 '.gnu.linkonce.t.name', '.rodata.name' or '.data.rel.ro.name' if 39468 function is in '.text.name', and the normal readonly-data or reloc 39469 readonly data section otherwise. 39470 39471 -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX 39472 Usually, the compiler uses the prefix '".rodata"' to construct 39473 section names for mergeable constant data. Define this macro to 39474 override the string if a different section name should be used. 39475 39476 -- Target Hook: section * TARGET_ASM_TM_CLONE_TABLE_SECTION (void) 39477 Return the section that should be used for transactional memory 39478 clone tables. 39479 39480 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (machine_mode 39481 MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 39482 Return the section into which a constant X, of mode MODE, should be 39483 placed. You can assume that X is some kind of constant in RTL. 39484 The argument MODE is redundant except in the case of a 'const_int' 39485 rtx. ALIGN is the constant alignment in bits. 39486 39487 The default version of this function takes care of putting symbolic 39488 constants in 'flag_pic' mode in 'data_section' and everything else 39489 in 'readonly_data_section'. 39490 39491 -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, tree 39492 ID) 39493 Define this hook if you need to postprocess the assembler name 39494 generated by target-independent code. The ID provided to this hook 39495 will be the computed name (e.g., the macro 'DECL_NAME' of the DECL 39496 in C, or the mangled name of the DECL in C++). The return value of 39497 the hook is an 'IDENTIFIER_NODE' for the appropriate mangled name 39498 on your target system. The default implementation of this hook 39499 just returns the ID provided. 39500 39501 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 39502 int NEW_DECL_P) 39503 Define this hook if references to a symbol or a constant must be 39504 treated differently depending on something about the variable or 39505 function named by the symbol (such as what section it is in). 39506 39507 The hook is executed immediately after rtl has been created for 39508 DECL, which may be a variable or function declaration or an entry 39509 in the constant pool. In either case, RTL is the rtl in question. 39510 Do _not_ use 'DECL_RTL (DECL)' in this hook; that field may not 39511 have been initialized yet. 39512 39513 In the case of a constant, it is safe to assume that the rtl is a 39514 'mem' whose address is a 'symbol_ref'. Most decls will also have 39515 this form, but that is not guaranteed. Global register variables, 39516 for instance, will have a 'reg' for their rtl. (Normally the right 39517 thing to do with such unusual rtl is leave it alone.) 39518 39519 The NEW_DECL_P argument will be true if this is the first time that 39520 'TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. It 39521 will be false for subsequent invocations, which will happen for 39522 duplicate declarations. Whether or not anything must be done for 39523 the duplicate declaration depends on whether the hook examines 39524 'DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 39525 called for a constant. 39526 39527 The usual thing for this hook to do is to record flags in the 39528 'symbol_ref', using 'SYMBOL_REF_FLAG' or 'SYMBOL_REF_FLAGS'. 39529 Historically, the name string was modified if it was necessary to 39530 encode more than one bit of information, but this practice is now 39531 discouraged; use 'SYMBOL_REF_FLAGS'. 39532 39533 The default definition of this hook, 'default_encode_section_info' 39534 in 'varasm.c', sets a number of commonly-useful bits in 39535 'SYMBOL_REF_FLAGS'. Check whether the default does what you need 39536 before overriding it. 39537 39538 -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char 39539 *NAME) 39540 Decode NAME and return the real name part, sans the characters that 39541 'TARGET_ENCODE_SECTION_INFO' may have added. 39542 39543 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP) 39544 Returns true if EXP should be placed into a "small data" section. 39545 The default version of this hook always returns false. 39546 39547 -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION 39548 Contains the value true if the target places read-only "small data" 39549 into a separate section. The default value is false. 39550 39551 -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void) 39552 It returns true if target wants profile code emitted before 39553 prologue. 39554 39555 The default version of this hook use the target macro 39556 'PROFILE_BEFORE_PROLOGUE'. 39557 39558 -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP) 39559 Returns true if EXP names an object for which name resolution rules 39560 must resolve to the current "module" (dynamic shared library or 39561 executable image). 39562 39563 The default version of this hook implements the name resolution 39564 rules for ELF, which has a looser model of global name binding than 39565 other currently supported object file formats. 39566 39567 -- Target Hook: bool TARGET_HAVE_TLS 39568 Contains the value true if the target supports thread-local 39569 storage. The default value is false. 39570 39571 39572File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 39573 3957418.19 Position Independent Code 39575=============================== 39576 39577This section describes macros that help implement generation of position 39578independent code. Simply defining these macros is not enough to 39579generate valid PIC; you must also add support to the hook 39580'TARGET_LEGITIMATE_ADDRESS_P' and to the macro 'PRINT_OPERAND_ADDRESS', 39581as well as 'LEGITIMIZE_ADDRESS'. You must modify the definition of 39582'movsi' to do something appropriate when the source operand contains a 39583symbolic address. You may also need to alter the handling of switch 39584statements so that they use relative addresses. 39585 39586 -- Macro: PIC_OFFSET_TABLE_REGNUM 39587 The register number of the register used to address a table of 39588 static data addresses in memory. In some cases this register is 39589 defined by a processor's "application binary interface" (ABI). 39590 When this macro is defined, RTL is generated for this register 39591 once, as with the stack pointer and frame pointer registers. If 39592 this macro is not defined, it is up to the machine-dependent files 39593 to allocate such a register (if necessary). Note that this 39594 register must be fixed when in use (e.g. when 'flag_pic' is true). 39595 39596 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 39597 A C expression that is nonzero if the register defined by 39598 'PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. If not defined, 39599 the default is zero. Do not define this macro if 39600 'PIC_OFFSET_TABLE_REGNUM' is not defined. 39601 39602 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 39603 A C expression that is nonzero if X is a legitimate immediate 39604 operand on the target machine when generating position independent 39605 code. You can assume that X satisfies 'CONSTANT_P', so you need 39606 not check this. You can also assume FLAG_PIC is true, so you need 39607 not check it either. You need not define this macro if all 39608 constants (including 'SYMBOL_REF') can be immediate operands when 39609 generating position independent code. 39610 39611 39612File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 39613 3961418.20 Defining the Output Assembler Language 39615============================================ 39616 39617This section describes macros whose principal purpose is to describe how 39618to write instructions in assembler language--rather than what the 39619instructions do. 39620 39621* Menu: 39622 39623* File Framework:: Structural information for the assembler file. 39624* Data Output:: Output of constants (numbers, strings, addresses). 39625* Uninitialized Data:: Output of uninitialized variables. 39626* Label Output:: Output and generation of labels. 39627* Initialization:: General principles of initialization 39628 and termination routines. 39629* Macros for Initialization:: 39630 Specific macros that control the handling of 39631 initialization and termination routines. 39632* Instruction Output:: Output of actual instructions. 39633* Dispatch Tables:: Output of jump tables. 39634* Exception Region Output:: Output of exception region code. 39635* Alignment Output:: Pseudo ops for alignment and skipping data. 39636 39637 39638File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 39639 3964018.20.1 The Overall Framework of an Assembler File 39641-------------------------------------------------- 39642 39643This describes the overall framework of an assembly file. 39644 39645 -- Target Hook: void TARGET_ASM_FILE_START (void) 39646 Output to 'asm_out_file' any text which the assembler expects to 39647 find at the beginning of a file. The default behavior is 39648 controlled by two flags, documented below. Unless your target's 39649 assembler is quite unusual, if you override the default, you should 39650 call 'default_file_start' at some point in your target hook. This 39651 lets other target files rely on these variables. 39652 39653 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 39654 If this flag is true, the text of the macro 'ASM_APP_OFF' will be 39655 printed as the very first line in the assembly file, unless 39656 '-fverbose-asm' is in effect. (If that macro has been defined to 39657 the empty string, this variable has no effect.) With the normal 39658 definition of 'ASM_APP_OFF', the effect is to notify the GNU 39659 assembler that it need not bother stripping comments or extra 39660 whitespace from its input. This allows it to work a bit faster. 39661 39662 The default is false. You should not set it to true unless you 39663 have verified that your port does not generate any extra whitespace 39664 or comments that will cause GAS to issue errors in NO_APP mode. 39665 39666 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 39667 If this flag is true, 'output_file_directive' will be called for 39668 the primary source file, immediately after printing 'ASM_APP_OFF' 39669 (if that is enabled). Most ELF assemblers expect this to be done. 39670 The default is false. 39671 39672 -- Target Hook: void TARGET_ASM_FILE_END (void) 39673 Output to 'asm_out_file' any text which the assembler expects to 39674 find at the end of a file. The default is to output nothing. 39675 39676 -- Function: void file_end_indicate_exec_stack () 39677 Some systems use a common convention, the '.note.GNU-stack' special 39678 section, to indicate whether or not an object file relies on the 39679 stack being executable. If your system uses this convention, you 39680 should define 'TARGET_ASM_FILE_END' to this function. If you need 39681 to do other things in that hook, have your hook function call this 39682 function. 39683 39684 -- Target Hook: void TARGET_ASM_LTO_START (void) 39685 Output to 'asm_out_file' any text which the assembler expects to 39686 find at the start of an LTO section. The default is to output 39687 nothing. 39688 39689 -- Target Hook: void TARGET_ASM_LTO_END (void) 39690 Output to 'asm_out_file' any text which the assembler expects to 39691 find at the end of an LTO section. The default is to output 39692 nothing. 39693 39694 -- Target Hook: void TARGET_ASM_CODE_END (void) 39695 Output to 'asm_out_file' any text which is needed before emitting 39696 unwind info and debug info at the end of a file. Some targets emit 39697 here PIC setup thunks that cannot be emitted at the end of file, 39698 because they couldn't have unwind info then. The default is to 39699 output nothing. 39700 39701 -- Macro: ASM_COMMENT_START 39702 A C string constant describing how to begin a comment in the target 39703 assembler language. The compiler assumes that the comment will end 39704 at the end of the line. 39705 39706 -- Macro: ASM_APP_ON 39707 A C string constant for text to be output before each 'asm' 39708 statement or group of consecutive ones. Normally this is '"#APP"', 39709 which is a comment that has no effect on most assemblers but tells 39710 the GNU assembler that it must check the lines that follow for all 39711 valid assembler constructs. 39712 39713 -- Macro: ASM_APP_OFF 39714 A C string constant for text to be output after each 'asm' 39715 statement or group of consecutive ones. Normally this is 39716 '"#NO_APP"', which tells the GNU assembler to resume making the 39717 time-saving assumptions that are valid for ordinary compiler 39718 output. 39719 39720 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 39721 A C statement to output COFF information or DWARF debugging 39722 information which indicates that filename NAME is the current 39723 source file to the stdio stream STREAM. 39724 39725 This macro need not be defined if the standard form of output for 39726 the file format in use is appropriate. 39727 39728 -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE, 39729 const char *NAME) 39730 Output DWARF debugging information which indicates that filename 39731 NAME is the current source file to the stdio stream FILE. 39732 39733 This target hook need not be defined if the standard form of output 39734 for the file format in use is appropriate. 39735 39736 -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME) 39737 Output a string based on NAME, suitable for the '#ident' directive, 39738 or the equivalent directive or pragma in non-C-family languages. 39739 If this hook is not defined, nothing is output for the '#ident' 39740 directive. 39741 39742 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 39743 A C statement to output the string STRING to the stdio stream 39744 STREAM. If you do not call the function 'output_quoted_string' in 39745 your config files, GCC will only call it to output filenames to the 39746 assembler source. So you can use it to canonicalize the format of 39747 the filename using this macro. 39748 39749 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 39750 unsigned int FLAGS, tree DECL) 39751 Output assembly directives to switch to section NAME. The section 39752 should have attributes as specified by FLAGS, which is a bit mask 39753 of the 'SECTION_*' flags defined in 'output.h'. If DECL is 39754 non-NULL, it is the 'VAR_DECL' or 'FUNCTION_DECL' with which this 39755 section is associated. 39756 39757 -- Target Hook: bool TARGET_ASM_ELF_FLAGS_NUMERIC (unsigned int FLAGS, 39758 unsigned int *NUM) 39759 This hook can be used to encode ELF section flags for which no 39760 letter code has been defined in the assembler. It is called by 39761 'default_asm_named_section' whenever the section flags need to be 39762 emitted in the assembler output. If the hook returns true, then 39763 the numerical value for ELF section flags should be calculated from 39764 FLAGS and saved in *NUM; the value is printed out instead of the 39765 normal sequence of letter codes. If the hook is not defined, or if 39766 it returns false, then NUM is ignored and the traditional letter 39767 sequence is emitted. 39768 39769 -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum 39770 node_frequency FREQ, bool STARTUP, bool EXIT) 39771 Return preferred text (sub)section for function DECL. Main purpose 39772 of this function is to separate cold, normal and hot functions. 39773 STARTUP is true when function is known to be used only at startup 39774 (from static constructors or it is 'main()'). EXIT is true when 39775 function is known to be used only at exit (from static 39776 destructors). Return NULL if function should go to default text 39777 section. 39778 39779 -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE 39780 *FILE, tree DECL, bool NEW_IS_COLD) 39781 Used by the target to emit any assembler directives or additional 39782 labels needed when a function is partitioned between different 39783 sections. Output should be written to FILE. The function decl is 39784 available as DECL and the new section is 'cold' if NEW_IS_COLD is 39785 'true'. 39786 39787 -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 39788 This flag is true if the target supports 39789 'TARGET_ASM_NAMED_SECTION'. It must not be modified by 39790 command-line option processing. 39791 39792 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 39793 This flag is true if we can create zeroed data by switching to a 39794 BSS section and then using 'ASM_OUTPUT_SKIP' to allocate the space. 39795 This is true on most ELF targets. 39796 39797 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 39798 const char *NAME, int RELOC) 39799 Choose a set of section attributes for use by 39800 'TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 39801 section name, and whether or not the declaration's initializer may 39802 contain runtime relocations. DECL may be null, in which case 39803 read-write data should be assumed. 39804 39805 The default version of this function handles choosing code vs data, 39806 read-only vs read-write data, and 'flag_pic'. You should only need 39807 to override this if your target has special flags that might be set 39808 via '__attribute__'. 39809 39810 -- Target Hook: void TARGET_ASM_RECORD_GCC_SWITCHES (const char *) 39811 Provides the target with the ability to record the gcc command line 39812 switches provided as argument. 39813 39814 By default this hook is set to NULL, but an example implementation 39815 is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES, 39816 it records the switches as ASCII text inside a new, string 39817 mergeable section in the assembler output file. The name of the 39818 new section is provided by the 39819 'TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook. 39820 39821 -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION 39822 This is the name of the section that will be created by the example 39823 ELF implementation of the 'TARGET_ASM_RECORD_GCC_SWITCHES' target 39824 hook. 39825 39826 39827File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 39828 3982918.20.2 Output of Data 39830---------------------- 39831 39832 -- Target Hook: const char * TARGET_ASM_BYTE_OP 39833 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 39834 -- Target Hook: const char * TARGET_ASM_ALIGNED_PSI_OP 39835 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 39836 -- Target Hook: const char * TARGET_ASM_ALIGNED_PDI_OP 39837 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 39838 -- Target Hook: const char * TARGET_ASM_ALIGNED_PTI_OP 39839 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 39840 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 39841 -- Target Hook: const char * TARGET_ASM_UNALIGNED_PSI_OP 39842 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 39843 -- Target Hook: const char * TARGET_ASM_UNALIGNED_PDI_OP 39844 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 39845 -- Target Hook: const char * TARGET_ASM_UNALIGNED_PTI_OP 39846 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 39847 These hooks specify assembly directives for creating certain kinds 39848 of integer object. The 'TARGET_ASM_BYTE_OP' directive creates a 39849 byte-sized object, the 'TARGET_ASM_ALIGNED_HI_OP' one creates an 39850 aligned two-byte object, and so on. Any of the hooks may be 39851 'NULL', indicating that no suitable directive is available. 39852 39853 The compiler will print these strings at the start of a new line, 39854 followed immediately by the object's initial value. In most cases, 39855 the string should contain a tab, a pseudo-op, and then another tab. 39856 39857 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 39858 ALIGNED_P) 39859 The 'assemble_integer' function uses this hook to output an integer 39860 object. X is the object's value, SIZE is its size in bytes and 39861 ALIGNED_P indicates whether it is aligned. The function should 39862 return 'true' if it was able to output the object. If it returns 39863 false, 'assemble_integer' will try to split the object into smaller 39864 parts. 39865 39866 The default implementation of this hook will use the 39867 'TARGET_ASM_BYTE_OP' family of strings, returning 'false' when the 39868 relevant string is 'NULL'. 39869 39870 -- Target Hook: void TARGET_ASM_DECL_END (void) 39871 Define this hook if the target assembler requires a special marker 39872 to terminate an initialized variable declaration. 39873 39874 -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE, 39875 rtx X) 39876 A target hook to recognize RTX patterns that 'output_addr_const' 39877 can't deal with, and output assembly code to FILE corresponding to 39878 the pattern X. This may be used to allow machine-dependent 39879 'UNSPEC's to appear within constants. 39880 39881 If target hook fails to recognize a pattern, it must return 39882 'false', so that a standard error message is printed. If it prints 39883 an error message itself, by calling, for example, 39884 'output_operand_lossage', it may just return 'true'. 39885 39886 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 39887 A C statement to output to the stdio stream STREAM an assembler 39888 instruction to assemble a string constant containing the LEN bytes 39889 at PTR. PTR will be a C expression of type 'char *' and LEN a C 39890 expression of type 'int'. 39891 39892 If the assembler has a '.ascii' pseudo-op as found in the Berkeley 39893 Unix assembler, do not define the macro 'ASM_OUTPUT_ASCII'. 39894 39895 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 39896 A C statement to output word N of a function descriptor for DECL. 39897 This must be defined if 'TARGET_VTABLE_USES_DESCRIPTORS' is 39898 defined, and is otherwise unused. 39899 39900 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 39901 You may define this macro as a C expression. You should define the 39902 expression to have a nonzero value if GCC should output the 39903 constant pool for a function before the code for the function, or a 39904 zero value if GCC should output the constant pool after the 39905 function. If you do not define this macro, the usual case, GCC 39906 will output the constant pool before the function. 39907 39908 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 39909 A C statement to output assembler commands to define the start of 39910 the constant pool for a function. FUNNAME is a string giving the 39911 name of the function. Should the return type of the function be 39912 required, it can be obtained via FUNDECL. SIZE is the size, in 39913 bytes, of the constant pool that will be written immediately after 39914 this call. 39915 39916 If no constant-pool prefix is required, the usual case, this macro 39917 need not be defined. 39918 39919 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO, 39920 JUMPTO) 39921 A C statement (with or without semicolon) to output a constant in 39922 the constant pool, if it needs special treatment. (This macro need 39923 not do anything for RTL expressions that can be output normally.) 39924 39925 The argument FILE is the standard I/O stream to output the 39926 assembler code on. X is the RTL expression for the constant to 39927 output, and MODE is the machine mode (in case X is a 'const_int'). 39928 ALIGN is the required alignment for the value X; you should output 39929 an assembler directive to force this much alignment. 39930 39931 The argument LABELNO is a number to use in an internal label for 39932 the address of this pool entry. The definition of this macro is 39933 responsible for outputting the label definition at the proper 39934 place. Here is how to do this: 39935 39936 (*targetm.asm_out.internal_label) (FILE, "LC", LABELNO); 39937 39938 When you output a pool entry specially, you should end with a 39939 'goto' to the label JUMPTO. This will prevent the same pool entry 39940 from being output a second time in the usual manner. 39941 39942 You need not define this macro if it would do nothing. 39943 39944 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 39945 A C statement to output assembler commands to at the end of the 39946 constant pool for a function. FUNNAME is a string giving the name 39947 of the function. Should the return type of the function be 39948 required, you can obtain it via FUNDECL. SIZE is the size, in 39949 bytes, of the constant pool that GCC wrote immediately before this 39950 call. 39951 39952 If no constant-pool epilogue is required, the usual case, you need 39953 not define this macro. 39954 39955 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR) 39956 Define this macro as a C expression which is nonzero if C is used 39957 as a logical line separator by the assembler. STR points to the 39958 position in the string where C was found; this can be used if a 39959 line separator uses multiple characters. 39960 39961 If you do not define this macro, the default is that only the 39962 character ';' is treated as a logical line separator. 39963 39964 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 39965 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 39966 These target hooks are C string constants, describing the syntax in 39967 the assembler for grouping arithmetic expressions. If not 39968 overridden, they default to normal parentheses, which is correct 39969 for most assemblers. 39970 39971 These macros are provided by 'real.h' for writing the definitions of 39972'ASM_OUTPUT_DOUBLE' and the like: 39973 39974 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 39975 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 39976 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 39977 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 39978 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 39979 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 39980 These translate X, of type 'REAL_VALUE_TYPE', to the target's 39981 floating point representation, and store its bit pattern in the 39982 variable L. For 'REAL_VALUE_TO_TARGET_SINGLE' and 39983 'REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 39984 'long int'. For the others, it should be an array of 'long int'. 39985 The number of elements in this array is determined by the size of 39986 the desired target floating point data type: 32 bits of it go in 39987 each 'long int' array element. Each array element holds 32 bits of 39988 the result, even if 'long int' is wider than 32 bits on the host 39989 machine. 39990 39991 The array element values are designed so that you can print them 39992 out using 'fprintf' in the order they should appear in the target 39993 machine's memory. 39994 39995 39996File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 39997 3999818.20.3 Output of Uninitialized Variables 39999----------------------------------------- 40000 40001Each of the macros in this section is used to do the whole job of 40002outputting a single uninitialized variable. 40003 40004 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 40005 A C statement (sans semicolon) to output to the stdio stream STREAM 40006 the assembler definition of a common-label named NAME whose size is 40007 SIZE bytes. The variable ROUNDED is the size rounded up to 40008 whatever alignment the caller wants. It is possible that SIZE may 40009 be zero, for instance if a struct with no other member than a 40010 zero-length array is defined. In this case, the backend must 40011 output a symbol definition that allocates at least one byte, both 40012 so that the address of the resulting object does not compare equal 40013 to any other, and because some object formats cannot even express 40014 the concept of a zero-sized common symbol, as that is how they 40015 represent an ordinary undefined external. 40016 40017 Use the expression 'assemble_name (STREAM, NAME)' to output the 40018 name itself; before and after that, output the additional assembler 40019 syntax for defining the name, and a newline. 40020 40021 This macro controls how the assembler definitions of uninitialized 40022 common global variables are output. 40023 40024 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 40025 Like 'ASM_OUTPUT_COMMON' except takes the required alignment as a 40026 separate, explicit argument. If you define this macro, it is used 40027 in place of 'ASM_OUTPUT_COMMON', and gives you more flexibility in 40028 handling the required alignment of the variable. The alignment is 40029 specified as the number of bits. 40030 40031 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 40032 ALIGNMENT) 40033 Like 'ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 40034 to be output, if there is one, or 'NULL_TREE' if there is no 40035 corresponding variable. If you define this macro, GCC will use it 40036 in place of both 'ASM_OUTPUT_COMMON' and 40037 'ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 40038 see the variable's decl in order to chose what to output. 40039 40040 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 40041 A C statement (sans semicolon) to output to the stdio stream STREAM 40042 the assembler definition of uninitialized global DECL named NAME 40043 whose size is SIZE bytes. The variable ALIGNMENT is the alignment 40044 specified as the number of bits. 40045 40046 Try to use function 'asm_output_aligned_bss' defined in file 40047 'varasm.c' when defining this macro. If unable, use the expression 40048 'assemble_name (STREAM, NAME)' to output the name itself; before 40049 and after that, output the additional assembler syntax for defining 40050 the name, and a newline. 40051 40052 There are two ways of handling global BSS. One is to define this 40053 macro. The other is to have 'TARGET_ASM_SELECT_SECTION' return a 40054 switchable BSS section (*note 40055 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 40056 both. 40057 40058 Some languages do not have 'common' data, and require a non-common 40059 form of global BSS in order to handle uninitialized globals 40060 efficiently. C++ is one example of this. However, if the target 40061 does not support global BSS, the front end may choose to make 40062 globals common in order to save space in the object file. 40063 40064 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 40065 A C statement (sans semicolon) to output to the stdio stream STREAM 40066 the assembler definition of a local-common-label named NAME whose 40067 size is SIZE bytes. The variable ROUNDED is the size rounded up to 40068 whatever alignment the caller wants. 40069 40070 Use the expression 'assemble_name (STREAM, NAME)' to output the 40071 name itself; before and after that, output the additional assembler 40072 syntax for defining the name, and a newline. 40073 40074 This macro controls how the assembler definitions of uninitialized 40075 static variables are output. 40076 40077 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 40078 Like 'ASM_OUTPUT_LOCAL' except takes the required alignment as a 40079 separate, explicit argument. If you define this macro, it is used 40080 in place of 'ASM_OUTPUT_LOCAL', and gives you more flexibility in 40081 handling the required alignment of the variable. The alignment is 40082 specified as the number of bits. 40083 40084 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 40085 ALIGNMENT) 40086 Like 'ASM_OUTPUT_ALIGNED_LOCAL' except that DECL of the variable to 40087 be output, if there is one, or 'NULL_TREE' if there is no 40088 corresponding variable. If you define this macro, GCC will use it 40089 in place of both 'ASM_OUTPUT_LOCAL' and 'ASM_OUTPUT_ALIGNED_LOCAL'. 40090 Define this macro when you need to see the variable's decl in order 40091 to chose what to output. 40092 40093 40094File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 40095 4009618.20.4 Output and Generation of Labels 40097--------------------------------------- 40098 40099This is about outputting labels. 40100 40101 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 40102 A C statement (sans semicolon) to output to the stdio stream STREAM 40103 the assembler definition of a label named NAME. Use the expression 40104 'assemble_name (STREAM, NAME)' to output the name itself; before 40105 and after that, output the additional assembler syntax for defining 40106 the name, and a newline. A default definition of this macro is 40107 provided which is correct for most systems. 40108 40109 -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL) 40110 A C statement (sans semicolon) to output to the stdio stream STREAM 40111 the assembler definition of a label named NAME of a function. Use 40112 the expression 'assemble_name (STREAM, NAME)' to output the name 40113 itself; before and after that, output the additional assembler 40114 syntax for defining the name, and a newline. A default definition 40115 of this macro is provided which is correct for most systems. 40116 40117 If this macro is not defined, then the function name is defined in 40118 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 40119 40120 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 40121 Identical to 'ASM_OUTPUT_LABEL', except that NAME is known to refer 40122 to a compiler-generated label. The default definition uses 40123 'assemble_name_raw', which is like 'assemble_name' except that it 40124 is more efficient. 40125 40126 -- Macro: SIZE_ASM_OP 40127 A C string containing the appropriate assembler directive to 40128 specify the size of a symbol, without any arguments. On systems 40129 that use ELF, the default (in 'config/elfos.h') is '"\t.size\t"'; 40130 on other systems, the default is not to define this macro. 40131 40132 Define this macro only if it is correct to use the default 40133 definitions of 'ASM_OUTPUT_SIZE_DIRECTIVE' and 40134 'ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 40135 custom definitions of those macros, or if you do not need explicit 40136 symbol sizes at all, do not define this macro. 40137 40138 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 40139 A C statement (sans semicolon) to output to the stdio stream STREAM 40140 a directive telling the assembler that the size of the symbol NAME 40141 is SIZE. SIZE is a 'HOST_WIDE_INT'. If you define 'SIZE_ASM_OP', 40142 a default definition of this macro is provided. 40143 40144 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 40145 A C statement (sans semicolon) to output to the stdio stream STREAM 40146 a directive telling the assembler to calculate the size of the 40147 symbol NAME by subtracting its address from the current address. 40148 40149 If you define 'SIZE_ASM_OP', a default definition of this macro is 40150 provided. The default assumes that the assembler recognizes a 40151 special '.' symbol as referring to the current address, and can 40152 calculate the difference between this and another symbol. If your 40153 assembler does not recognize '.' or cannot do calculations with it, 40154 you will need to redefine 'ASM_OUTPUT_MEASURED_SIZE' to use some 40155 other technique. 40156 40157 -- Macro: NO_DOLLAR_IN_LABEL 40158 Define this macro if the assembler does not accept the character 40159 '$' in label names. By default constructors and destructors in G++ 40160 have '$' in the identifiers. If this macro is defined, '.' is used 40161 instead. 40162 40163 -- Macro: NO_DOT_IN_LABEL 40164 Define this macro if the assembler does not accept the character 40165 '.' in label names. By default constructors and destructors in G++ 40166 have names that use '.'. If this macro is defined, these names are 40167 rewritten to avoid '.'. 40168 40169 -- Macro: TYPE_ASM_OP 40170 A C string containing the appropriate assembler directive to 40171 specify the type of a symbol, without any arguments. On systems 40172 that use ELF, the default (in 'config/elfos.h') is '"\t.type\t"'; 40173 on other systems, the default is not to define this macro. 40174 40175 Define this macro only if it is correct to use the default 40176 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 40177 need your own custom definition of this macro, or if you do not 40178 need explicit symbol types at all, do not define this macro. 40179 40180 -- Macro: TYPE_OPERAND_FMT 40181 A C string which specifies (using 'printf' syntax) the format of 40182 the second operand to 'TYPE_ASM_OP'. On systems that use ELF, the 40183 default (in 'config/elfos.h') is '"@%s"'; on other systems, the 40184 default is not to define this macro. 40185 40186 Define this macro only if it is correct to use the default 40187 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 40188 need your own custom definition of this macro, or if you do not 40189 need explicit symbol types at all, do not define this macro. 40190 40191 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 40192 A C statement (sans semicolon) to output to the stdio stream STREAM 40193 a directive telling the assembler that the type of the symbol NAME 40194 is TYPE. TYPE is a C string; currently, that string is always 40195 either '"function"' or '"object"', but you should not count on 40196 this. 40197 40198 If you define 'TYPE_ASM_OP' and 'TYPE_OPERAND_FMT', a default 40199 definition of this macro is provided. 40200 40201 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 40202 A C statement (sans semicolon) to output to the stdio stream STREAM 40203 any text necessary for declaring the name NAME of a function which 40204 is being defined. This macro is responsible for outputting the 40205 label definition (perhaps using 'ASM_OUTPUT_FUNCTION_LABEL'). The 40206 argument DECL is the 'FUNCTION_DECL' tree node representing the 40207 function. 40208 40209 If this macro is not defined, then the function name is defined in 40210 the usual manner as a label (by means of 40211 'ASM_OUTPUT_FUNCTION_LABEL'). 40212 40213 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 40214 of this macro. 40215 40216 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 40217 A C statement (sans semicolon) to output to the stdio stream STREAM 40218 any text necessary for declaring the size of a function which is 40219 being defined. The argument NAME is the name of the function. The 40220 argument DECL is the 'FUNCTION_DECL' tree node representing the 40221 function. 40222 40223 If this macro is not defined, then the function size is not 40224 defined. 40225 40226 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 40227 this macro. 40228 40229 -- Macro: ASM_DECLARE_COLD_FUNCTION_NAME (STREAM, NAME, DECL) 40230 A C statement (sans semicolon) to output to the stdio stream STREAM 40231 any text necessary for declaring the name NAME of a cold function 40232 partition which is being defined. This macro is responsible for 40233 outputting the label definition (perhaps using 40234 'ASM_OUTPUT_FUNCTION_LABEL'). The argument DECL is the 40235 'FUNCTION_DECL' tree node representing the function. 40236 40237 If this macro is not defined, then the cold partition name is 40238 defined in the usual manner as a label (by means of 40239 'ASM_OUTPUT_LABEL'). 40240 40241 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 40242 of this macro. 40243 40244 -- Macro: ASM_DECLARE_COLD_FUNCTION_SIZE (STREAM, NAME, DECL) 40245 A C statement (sans semicolon) to output to the stdio stream STREAM 40246 any text necessary for declaring the size of a cold function 40247 partition which is being defined. The argument NAME is the name of 40248 the cold partition of the function. The argument DECL is the 40249 'FUNCTION_DECL' tree node representing the function. 40250 40251 If this macro is not defined, then the partition size is not 40252 defined. 40253 40254 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 40255 this macro. 40256 40257 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 40258 A C statement (sans semicolon) to output to the stdio stream STREAM 40259 any text necessary for declaring the name NAME of an initialized 40260 variable which is being defined. This macro must output the label 40261 definition (perhaps using 'ASM_OUTPUT_LABEL'). The argument DECL 40262 is the 'VAR_DECL' tree node representing the variable. 40263 40264 If this macro is not defined, then the variable name is defined in 40265 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 40266 40267 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' and/or 40268 'ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 40269 40270 -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE, 40271 const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE) 40272 A target hook to output to the stdio stream FILE any text necessary 40273 for declaring the name NAME of a constant which is being defined. 40274 This target hook is responsible for outputting the label definition 40275 (perhaps using 'assemble_label'). The argument EXP is the value of 40276 the constant, and SIZE is the size of the constant in bytes. The 40277 NAME will be an internal label. 40278 40279 The default version of this target hook, define the NAME in the 40280 usual manner as a label (by means of 'assemble_label'). 40281 40282 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in this target 40283 hook. 40284 40285 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 40286 A C statement (sans semicolon) to output to the stdio stream STREAM 40287 any text necessary for claiming a register REGNO for a global 40288 variable DECL with name NAME. 40289 40290 If you don't define this macro, that is equivalent to defining it 40291 to do nothing. 40292 40293 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 40294 A C statement (sans semicolon) to finish up declaring a variable 40295 name once the compiler has processed its initializer fully and thus 40296 has had a chance to determine the size of an array when controlled 40297 by an initializer. This is used on systems where it's necessary to 40298 declare something about the size of the object. 40299 40300 If you don't define this macro, that is equivalent to defining it 40301 to do nothing. 40302 40303 You may wish to use 'ASM_OUTPUT_SIZE_DIRECTIVE' and/or 40304 'ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 40305 40306 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 40307 char *NAME) 40308 This target hook is a function to output to the stdio stream STREAM 40309 some commands that will make the label NAME global; that is, 40310 available for reference from other files. 40311 40312 The default implementation relies on a proper definition of 40313 'GLOBAL_ASM_OP'. 40314 40315 -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, tree 40316 DECL) 40317 This target hook is a function to output to the stdio stream STREAM 40318 some commands that will make the name associated with DECL global; 40319 that is, available for reference from other files. 40320 40321 The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL 40322 target hook. 40323 40324 -- Target Hook: void TARGET_ASM_ASSEMBLE_UNDEFINED_DECL (FILE *STREAM, 40325 const char *NAME, const_tree DECL) 40326 This target hook is a function to output to the stdio stream STREAM 40327 some commands that will declare the name associated with DECL which 40328 is not defined in the current translation unit. Most assemblers do 40329 not require anything to be output in this case. 40330 40331 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 40332 A C statement (sans semicolon) to output to the stdio stream STREAM 40333 some commands that will make the label NAME weak; that is, 40334 available for reference from other files but only used if no other 40335 definition is available. Use the expression 'assemble_name 40336 (STREAM, NAME)' to output the name itself; before and after that, 40337 output the additional assembler syntax for making that name weak, 40338 and a newline. 40339 40340 If you don't define this macro or 'ASM_WEAKEN_DECL', GCC will not 40341 support weak symbols and you should not define the 'SUPPORTS_WEAK' 40342 macro. 40343 40344 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 40345 Combines (and replaces) the function of 'ASM_WEAKEN_LABEL' and 40346 'ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 40347 or variable decl. If VALUE is not 'NULL', this C statement should 40348 output to the stdio stream STREAM assembler code which defines 40349 (equates) the weak symbol NAME to have the value VALUE. If VALUE 40350 is 'NULL', it should output commands to make NAME weak. 40351 40352 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 40353 Outputs a directive that enables NAME to be used to refer to symbol 40354 VALUE with weak-symbol semantics. 'decl' is the declaration of 40355 'name'. 40356 40357 -- Macro: SUPPORTS_WEAK 40358 A preprocessor constant expression which evaluates to true if the 40359 target supports weak symbols. 40360 40361 If you don't define this macro, 'defaults.h' provides a default 40362 definition. If either 'ASM_WEAKEN_LABEL' or 'ASM_WEAKEN_DECL' is 40363 defined, the default definition is '1'; otherwise, it is '0'. 40364 40365 -- Macro: TARGET_SUPPORTS_WEAK 40366 A C expression which evaluates to true if the target supports weak 40367 symbols. 40368 40369 If you don't define this macro, 'defaults.h' provides a default 40370 definition. The default definition is '(SUPPORTS_WEAK)'. Define 40371 this macro if you want to control weak symbol support with a 40372 compiler flag such as '-melf'. 40373 40374 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 40375 A C statement (sans semicolon) to mark DECL to be emitted as a 40376 public symbol such that extra copies in multiple translation units 40377 will be discarded by the linker. Define this macro if your object 40378 file format provides support for this concept, such as the 'COMDAT' 40379 section flags in the Microsoft Windows PE/COFF format, and this 40380 support requires changes to DECL, such as putting it in a separate 40381 section. 40382 40383 -- Macro: SUPPORTS_ONE_ONLY 40384 A C expression which evaluates to true if the target supports 40385 one-only semantics. 40386 40387 If you don't define this macro, 'varasm.c' provides a default 40388 definition. If 'MAKE_DECL_ONE_ONLY' is defined, the default 40389 definition is '1'; otherwise, it is '0'. Define this macro if you 40390 want to control one-only symbol support with a compiler flag, or if 40391 setting the 'DECL_ONE_ONLY' flag is enough to mark a declaration to 40392 be emitted as one-only. 40393 40394 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int 40395 VISIBILITY) 40396 This target hook is a function to output to ASM_OUT_FILE some 40397 commands that will make the symbol(s) associated with DECL have 40398 hidden, protected or internal visibility as specified by 40399 VISIBILITY. 40400 40401 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 40402 A C expression that evaluates to true if the target's linker 40403 expects that weak symbols do not appear in a static archive's table 40404 of contents. The default is '0'. 40405 40406 Leaving weak symbols out of an archive's table of contents means 40407 that, if a symbol will only have a definition in one translation 40408 unit and will have undefined references from other translation 40409 units, that symbol should not be weak. Defining this macro to be 40410 nonzero will thus have the effect that certain symbols that would 40411 normally be weak (explicit template instantiations, and vtables for 40412 polymorphic classes with noninline key methods) will instead be 40413 nonweak. 40414 40415 The C++ ABI requires this macro to be zero. Define this macro for 40416 targets where full C++ ABI compliance is impossible and where 40417 linker restrictions require weak symbols to be left out of a static 40418 archive's table of contents. 40419 40420 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 40421 A C statement (sans semicolon) to output to the stdio stream STREAM 40422 any text necessary for declaring the name of an external symbol 40423 named NAME which is referenced in this compilation but not defined. 40424 The value of DECL is the tree node for the declaration. 40425 40426 This macro need not be defined if it does not need to output 40427 anything. The GNU assembler and most Unix assemblers don't require 40428 anything. 40429 40430 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 40431 This target hook is a function to output to ASM_OUT_FILE an 40432 assembler pseudo-op to declare a library function name external. 40433 The name of the library function is given by SYMREF, which is a 40434 'symbol_ref'. 40435 40436 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char 40437 *SYMBOL) 40438 This target hook is a function to output to ASM_OUT_FILE an 40439 assembler directive to annotate SYMBOL as used. The Darwin target 40440 uses the .no_dead_code_strip directive. 40441 40442 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 40443 A C statement (sans semicolon) to output to the stdio stream STREAM 40444 a reference in assembler syntax to a label named NAME. This should 40445 add '_' to the front of the name, if that is customary on your 40446 operating system, as it is in most Berkeley Unix systems. This 40447 macro is used in 'assemble_name'. 40448 40449 -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME) 40450 Given a symbol NAME, perform same mangling as 'varasm.c''s 40451 'assemble_name', but in memory rather than to a file stream, 40452 returning result as an 'IDENTIFIER_NODE'. Required for correct LTO 40453 symtabs. The default implementation calls the 40454 'TARGET_STRIP_NAME_ENCODING' hook and then prepends the 40455 'USER_LABEL_PREFIX', if any. 40456 40457 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 40458 A C statement (sans semicolon) to output a reference to 40459 'SYMBOL_REF' SYM. If not defined, 'assemble_name' will be used to 40460 output the name of the symbol. This macro may be used to modify 40461 the way a symbol is referenced depending on information encoded by 40462 'TARGET_ENCODE_SECTION_INFO'. 40463 40464 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 40465 A C statement (sans semicolon) to output a reference to BUF, the 40466 result of 'ASM_GENERATE_INTERNAL_LABEL'. If not defined, 40467 'assemble_name' will be used to output the name of the symbol. 40468 This macro is not used by 'output_asm_label', or the '%l' specifier 40469 that calls it; the intention is that this macro should be set when 40470 it is necessary to output a label differently when its address is 40471 being taken. 40472 40473 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 40474 char *PREFIX, unsigned long LABELNO) 40475 A function to output to the stdio stream STREAM a label whose name 40476 is made from the string PREFIX and the number LABELNO. 40477 40478 It is absolutely essential that these labels be distinct from the 40479 labels used for user-level functions and variables. Otherwise, 40480 certain programs will have name conflicts with internal labels. 40481 40482 It is desirable to exclude internal labels from the symbol table of 40483 the object file. Most assemblers have a naming convention for 40484 labels that should be excluded; on many systems, the letter 'L' at 40485 the beginning of a label has this effect. You should find out what 40486 convention your system uses, and follow it. 40487 40488 The default version of this function utilizes 40489 'ASM_GENERATE_INTERNAL_LABEL'. 40490 40491 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 40492 A C statement to output to the stdio stream STREAM a debug info 40493 label whose name is made from the string PREFIX and the number NUM. 40494 This is useful for VLIW targets, where debug info labels may need 40495 to be treated differently than branch target labels. On some 40496 systems, branch target labels must be at the beginning of 40497 instruction bundles, but debug info labels can occur in the middle 40498 of instruction bundles. 40499 40500 If this macro is not defined, then 40501 '(*targetm.asm_out.internal_label)' will be used. 40502 40503 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 40504 A C statement to store into the string STRING a label whose name is 40505 made from the string PREFIX and the number NUM. 40506 40507 This string, when output subsequently by 'assemble_name', should 40508 produce the output that '(*targetm.asm_out.internal_label)' would 40509 produce with the same PREFIX and NUM. 40510 40511 If the string begins with '*', then 'assemble_name' will output the 40512 rest of the string unchanged. It is often convenient for 40513 'ASM_GENERATE_INTERNAL_LABEL' to use '*' in this way. If the 40514 string doesn't start with '*', then 'ASM_OUTPUT_LABELREF' gets to 40515 output the string, and may change it. (Of course, 40516 'ASM_OUTPUT_LABELREF' is also part of your machine description, so 40517 you should know what it does on your machine.) 40518 40519 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 40520 A C expression to assign to OUTVAR (which is a variable of type 40521 'char *') a newly allocated string made from the string NAME and 40522 the number NUMBER, with some suitable punctuation added. Use 40523 'alloca' to get space for the string. 40524 40525 The string will be used as an argument to 'ASM_OUTPUT_LABELREF' to 40526 produce an assembler label for an internal static variable whose 40527 name is NAME. Therefore, the string must be such as to result in 40528 valid assembler code. The argument NUMBER is different each time 40529 this macro is executed; it prevents conflicts between 40530 similarly-named internal static variables in different scopes. 40531 40532 Ideally this string should not be a valid C identifier, to prevent 40533 any conflict with the user's own symbols. Most assemblers allow 40534 periods or percent signs in assembler symbols; putting at least one 40535 of these between the name and the number will suffice. 40536 40537 If this macro is not defined, a default definition will be provided 40538 which is correct for most systems. 40539 40540 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 40541 A C statement to output to the stdio stream STREAM assembler code 40542 which defines (equates) the symbol NAME to have the value VALUE. 40543 40544 If 'SET_ASM_OP' is defined, a default definition is provided which 40545 is correct for most systems. 40546 40547 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 40548 DECL_OF_VALUE) 40549 A C statement to output to the stdio stream STREAM assembler code 40550 which defines (equates) the symbol whose tree node is DECL_OF_NAME 40551 to have the value of the tree node DECL_OF_VALUE. This macro will 40552 be used in preference to 'ASM_OUTPUT_DEF' if it is defined and if 40553 the tree nodes are available. 40554 40555 If 'SET_ASM_OP' is defined, a default definition is provided which 40556 is correct for most systems. 40557 40558 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 40559 A C statement that evaluates to true if the assembler code which 40560 defines (equates) the symbol whose tree node is DECL_OF_NAME to 40561 have the value of the tree node DECL_OF_VALUE should be emitted 40562 near the end of the current compilation unit. The default is to 40563 not defer output of defines. This macro affects defines output by 40564 'ASM_OUTPUT_DEF' and 'ASM_OUTPUT_DEF_FROM_DECLS'. 40565 40566 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 40567 A C statement to output to the stdio stream STREAM assembler code 40568 which defines (equates) the weak symbol NAME to have the value 40569 VALUE. If VALUE is 'NULL', it defines NAME as an undefined weak 40570 symbol. 40571 40572 Define this macro if the target only supports weak aliases; define 40573 'ASM_OUTPUT_DEF' instead if possible. 40574 40575 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 40576 SEL_NAME) 40577 Define this macro to override the default assembler names used for 40578 Objective-C methods. 40579 40580 The default name is a unique method number followed by the name of 40581 the class (e.g. '_1_Foo'). For methods in categories, the name of 40582 the category is also included in the assembler name (e.g. 40583 '_1_Foo_Bar'). 40584 40585 These names are safe on most systems, but make debugging difficult 40586 since the method's selector is not present in the name. Therefore, 40587 particular systems define other ways of computing names. 40588 40589 BUF is an expression of type 'char *' which gives you a buffer in 40590 which to store the name; its length is as long as CLASS_NAME, 40591 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 40592 40593 The argument IS_INST specifies whether the method is an instance 40594 method or a class method; CLASS_NAME is the name of the class; 40595 CAT_NAME is the name of the category (or 'NULL' if the method is 40596 not in a category); and SEL_NAME is the name of the selector. 40597 40598 On systems where the assembler can handle quoted names, you can use 40599 this macro to provide more human-readable names. 40600 40601 40602File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 40603 4060418.20.5 How Initialization Functions Are Handled 40605------------------------------------------------ 40606 40607The compiled code for certain languages includes "constructors" (also 40608called "initialization routines")--functions to initialize data in the 40609program when the program is started. These functions need to be called 40610before the program is "started"--that is to say, before 'main' is 40611called. 40612 40613 Compiling some languages generates "destructors" (also called 40614"termination routines") that should be called when the program 40615terminates. 40616 40617 To make the initialization and termination functions work, the compiler 40618must output something in the assembler code to cause those functions to 40619be called at the appropriate time. When you port the compiler to a new 40620system, you need to specify how to do this. 40621 40622 There are two major ways that GCC currently supports the execution of 40623initialization and termination functions. Each way has two variants. 40624Much of the structure is common to all four variations. 40625 40626 The linker must build two lists of these functions--a list of 40627initialization functions, called '__CTOR_LIST__', and a list of 40628termination functions, called '__DTOR_LIST__'. 40629 40630 Each list always begins with an ignored function pointer (which may 40631hold 0, -1, or a count of the function pointers after it, depending on 40632the environment). This is followed by a series of zero or more function 40633pointers to constructors (or destructors), followed by a function 40634pointer containing zero. 40635 40636 Depending on the operating system and its executable file format, 40637either 'crtstuff.c' or 'libgcc2.c' traverses these lists at startup time 40638and exit time. Constructors are called in reverse order of the list; 40639destructors in forward order. 40640 40641 The best way to handle static constructors works only for object file 40642formats which provide arbitrarily-named sections. A section is set 40643aside for a list of constructors, and another for a list of destructors. 40644Traditionally these are called '.ctors' and '.dtors'. Each object file 40645that defines an initialization function also puts a word in the 40646constructor section to point to that function. The linker accumulates 40647all these words into one contiguous '.ctors' section. Termination 40648functions are handled similarly. 40649 40650 This method will be chosen as the default by 'target-def.h' if 40651'TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 40652arbitrary sections, but does support special designated constructor and 40653destructor sections may define 'CTORS_SECTION_ASM_OP' and 40654'DTORS_SECTION_ASM_OP' to achieve the same effect. 40655 40656 When arbitrary sections are available, there are two variants, 40657depending upon how the code in 'crtstuff.c' is called. On systems that 40658support a ".init" section which is executed at program startup, parts of 40659'crtstuff.c' are compiled into that section. The program is linked by 40660the 'gcc' driver like this: 40661 40662 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 40663 40664 The prologue of a function ('__init') appears in the '.init' section of 40665'crti.o'; the epilogue appears in 'crtn.o'. Likewise for the function 40666'__fini' in the ".fini" section. Normally these files are provided by 40667the operating system or by the GNU C library, but are provided by GCC 40668for a few targets. 40669 40670 The objects 'crtbegin.o' and 'crtend.o' are (for most targets) compiled 40671from 'crtstuff.c'. They contain, among other things, code fragments 40672within the '.init' and '.fini' sections that branch to routines in the 40673'.text' section. The linker will pull all parts of a section together, 40674which results in a complete '__init' function that invokes the routines 40675we need at startup. 40676 40677 To use this variant, you must define the 'INIT_SECTION_ASM_OP' macro 40678properly. 40679 40680 If no init section is available, when GCC compiles any function called 40681'main' (or more accurately, any function designated as a program entry 40682point by the language front end calling 'expand_main_function'), it 40683inserts a procedure call to '__main' as the first executable code after 40684the function prologue. The '__main' function is defined in 'libgcc2.c' 40685and runs the global constructors. 40686 40687 In file formats that don't support arbitrary sections, there are again 40688two variants. In the simplest variant, the GNU linker (GNU 'ld') and an 40689'a.out' format must be used. In this case, 'TARGET_ASM_CONSTRUCTOR' is 40690defined to produce a '.stabs' entry of type 'N_SETT', referencing the 40691name '__CTOR_LIST__', and with the address of the void function 40692containing the initialization code as its value. The GNU linker 40693recognizes this as a request to add the value to a "set"; the values are 40694accumulated, and are eventually placed in the executable as a vector in 40695the format described above, with a leading (ignored) count and a 40696trailing zero element. 'TARGET_ASM_DESTRUCTOR' is handled similarly. 40697Since no init section is available, the absence of 'INIT_SECTION_ASM_OP' 40698causes the compilation of 'main' to call '__main' as above, starting the 40699initialization process. 40700 40701 The last variant uses neither arbitrary sections nor the GNU linker. 40702This is preferable when you want to do dynamic linking and when using 40703file formats which the GNU linker does not support, such as 'ECOFF'. In 40704this case, 'TARGET_HAVE_CTORS_DTORS' is false, initialization and 40705termination functions are recognized simply by their names. This 40706requires an extra program in the linkage step, called 'collect2'. This 40707program pretends to be the linker, for use with GCC; it does its job by 40708running the ordinary linker, but also arranges to include the vectors of 40709initialization and termination functions. These functions are called 40710via '__main' as described above. In order to use this method, 40711'use_collect2' must be defined in the target in 'config.gcc'. 40712 40713 The following section describes the specific macros that control and 40714customize the handling of initialization and termination functions. 40715 40716 40717File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 40718 4071918.20.6 Macros Controlling Initialization Routines 40720-------------------------------------------------- 40721 40722Here are the macros that control how the compiler handles initialization 40723and termination functions: 40724 40725 -- Macro: INIT_SECTION_ASM_OP 40726 If defined, a C string constant, including spacing, for the 40727 assembler operation to identify the following data as 40728 initialization code. If not defined, GCC will assume such a 40729 section does not exist. When you are using special sections for 40730 initialization and termination functions, this macro also controls 40731 how 'crtstuff.c' and 'libgcc2.c' arrange to run the initialization 40732 functions. 40733 40734 -- Macro: HAS_INIT_SECTION 40735 If defined, 'main' will not call '__main' as described above. This 40736 macro should be defined for systems that control start-up code on a 40737 symbol-by-symbol basis, such as OSF/1, and should not be defined 40738 explicitly for systems that support 'INIT_SECTION_ASM_OP'. 40739 40740 -- Macro: LD_INIT_SWITCH 40741 If defined, a C string constant for a switch that tells the linker 40742 that the following symbol is an initialization routine. 40743 40744 -- Macro: LD_FINI_SWITCH 40745 If defined, a C string constant for a switch that tells the linker 40746 that the following symbol is a finalization routine. 40747 40748 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 40749 If defined, a C statement that will write a function that can be 40750 automatically called when a shared library is loaded. The function 40751 should call FUNC, which takes no arguments. If not defined, and 40752 the object format requires an explicit initialization function, 40753 then a function called '_GLOBAL__DI' will be generated. 40754 40755 This function and the following one are used by collect2 when 40756 linking a shared library that needs constructors or destructors, or 40757 has DWARF2 exception tables embedded in the code. 40758 40759 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 40760 If defined, a C statement that will write a function that can be 40761 automatically called when a shared library is unloaded. The 40762 function should call FUNC, which takes no arguments. If not 40763 defined, and the object format requires an explicit finalization 40764 function, then a function called '_GLOBAL__DD' will be generated. 40765 40766 -- Macro: INVOKE__main 40767 If defined, 'main' will call '__main' despite the presence of 40768 'INIT_SECTION_ASM_OP'. This macro should be defined for systems 40769 where the init section is not actually run automatically, but is 40770 still useful for collecting the lists of constructors and 40771 destructors. 40772 40773 -- Macro: SUPPORTS_INIT_PRIORITY 40774 If nonzero, the C++ 'init_priority' attribute is supported and the 40775 compiler should emit instructions to control the order of 40776 initialization of objects. If zero, the compiler will issue an 40777 error message upon encountering an 'init_priority' attribute. 40778 40779 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 40780 This value is true if the target supports some "native" method of 40781 collecting constructors and destructors to be run at startup and 40782 exit. It is false if we must use 'collect2'. 40783 40784 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 40785 If defined, a function that outputs assembler code to arrange to 40786 call the function referenced by SYMBOL at initialization time. 40787 40788 Assume that SYMBOL is a 'SYMBOL_REF' for a function taking no 40789 arguments and with no return value. If the target supports 40790 initialization priorities, PRIORITY is a value between 0 and 40791 'MAX_INIT_PRIORITY'; otherwise it must be 'DEFAULT_INIT_PRIORITY'. 40792 40793 If this macro is not defined by the target, a suitable default will 40794 be chosen if (1) the target supports arbitrary section names, (2) 40795 the target defines 'CTORS_SECTION_ASM_OP', or (3) 'USE_COLLECT2' is 40796 not defined. 40797 40798 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 40799 This is like 'TARGET_ASM_CONSTRUCTOR' but used for termination 40800 functions rather than initialization functions. 40801 40802 If 'TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 40803generated for the generated object file will have static linkage. 40804 40805 If your system uses 'collect2' as the means of processing constructors, 40806then that program normally uses 'nm' to scan an object file for 40807constructor functions to be called. 40808 40809 On certain kinds of systems, you can define this macro to make 40810'collect2' work faster (and, in some cases, make it work at all): 40811 40812 -- Macro: OBJECT_FORMAT_COFF 40813 Define this macro if the system uses COFF (Common Object File 40814 Format) object files, so that 'collect2' can assume this format and 40815 scan object files directly for dynamic constructor/destructor 40816 functions. 40817 40818 This macro is effective only in a native compiler; 'collect2' as 40819 part of a cross compiler always uses 'nm' for the target machine. 40820 40821 -- Macro: REAL_NM_FILE_NAME 40822 Define this macro as a C string constant containing the file name 40823 to use to execute 'nm'. The default is to search the path normally 40824 for 'nm'. 40825 40826 -- Macro: NM_FLAGS 40827 'collect2' calls 'nm' to scan object files for static constructors 40828 and destructors and LTO info. By default, '-n' is passed. Define 40829 'NM_FLAGS' to a C string constant if other options are needed to 40830 get the same output format as GNU 'nm -n' produces. 40831 40832 If your system supports shared libraries and has a program to list the 40833dynamic dependencies of a given library or executable, you can define 40834these macros to enable support for running initialization and 40835termination functions in shared libraries: 40836 40837 -- Macro: LDD_SUFFIX 40838 Define this macro to a C string constant containing the name of the 40839 program which lists dynamic dependencies, like 'ldd' under SunOS 4. 40840 40841 -- Macro: PARSE_LDD_OUTPUT (PTR) 40842 Define this macro to be C code that extracts filenames from the 40843 output of the program denoted by 'LDD_SUFFIX'. PTR is a variable 40844 of type 'char *' that points to the beginning of a line of output 40845 from 'LDD_SUFFIX'. If the line lists a dynamic dependency, the 40846 code must advance PTR to the beginning of the filename on that 40847 line. Otherwise, it must set PTR to 'NULL'. 40848 40849 -- Macro: SHLIB_SUFFIX 40850 Define this macro to a C string constant containing the default 40851 shared library extension of the target (e.g., '".so"'). 'collect2' 40852 strips version information after this suffix when generating global 40853 constructor and destructor names. This define is only needed on 40854 targets that use 'collect2' to process constructors and 40855 destructors. 40856 40857 40858File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 40859 4086018.20.7 Output of Assembler Instructions 40861---------------------------------------- 40862 40863This describes assembler instruction output. 40864 40865 -- Macro: REGISTER_NAMES 40866 A C initializer containing the assembler's names for the machine 40867 registers, each one as a C string constant. This is what 40868 translates register numbers in the compiler into assembler 40869 language. 40870 40871 -- Macro: ADDITIONAL_REGISTER_NAMES 40872 If defined, a C initializer for an array of structures containing a 40873 name and a register number. This macro defines additional names 40874 for hard registers, thus allowing the 'asm' option in declarations 40875 to refer to registers using alternate names. 40876 40877 -- Macro: OVERLAPPING_REGISTER_NAMES 40878 If defined, a C initializer for an array of structures containing a 40879 name, a register number and a count of the number of consecutive 40880 machine registers the name overlaps. This macro defines additional 40881 names for hard registers, thus allowing the 'asm' option in 40882 declarations to refer to registers using alternate names. Unlike 40883 'ADDITIONAL_REGISTER_NAMES', this macro should be used when the 40884 register name implies multiple underlying registers. 40885 40886 This macro should be used when it is important that a clobber in an 40887 'asm' statement clobbers all the underlying values implied by the 40888 register name. For example, on ARM, clobbering the 40889 double-precision VFP register "d0" implies clobbering both 40890 single-precision registers "s0" and "s1". 40891 40892 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 40893 Define this macro if you are using an unusual assembler that 40894 requires different names for the machine instructions. 40895 40896 The definition is a C statement or statements which output an 40897 assembler instruction opcode to the stdio stream STREAM. The 40898 macro-operand PTR is a variable of type 'char *' which points to 40899 the opcode name in its "internal" form--the form that is written in 40900 the machine description. The definition should output the opcode 40901 name to STREAM, performing any translation you desire, and 40902 increment the variable PTR to point at the end of the opcode so 40903 that it will not be output twice. 40904 40905 In fact, your macro definition may process less than the entire 40906 opcode name, or more than the opcode name; but if you want to 40907 process text that includes '%'-sequences to substitute operands, 40908 you must take care of the substitution yourself. Just be sure to 40909 increment PTR over whatever text should not be output normally. 40910 40911 If you need to look at the operand values, they can be found as the 40912 elements of 'recog_data.operand'. 40913 40914 If the macro definition does nothing, the instruction is output in 40915 the usual way. 40916 40917 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 40918 If defined, a C statement to be executed just prior to the output 40919 of assembler code for INSN, to modify the extracted operands so 40920 they will be output differently. 40921 40922 Here the argument OPVEC is the vector containing the operands 40923 extracted from INSN, and NOPERANDS is the number of elements of the 40924 vector which contain meaningful data for this insn. The contents 40925 of this vector are what will be used to convert the insn template 40926 into assembler code, so you can change the assembler output by 40927 changing the contents of the vector. 40928 40929 This macro is useful when various assembler syntaxes share a single 40930 file of instruction patterns; by defining this macro differently, 40931 you can cause a large class of instructions to be output 40932 differently (such as with rearranged operands). Naturally, 40933 variations in assembler syntax affecting individual insn patterns 40934 ought to be handled by writing conditional output routines in those 40935 patterns. 40936 40937 If this macro is not defined, it is equivalent to a null statement. 40938 40939 -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, 40940 rtx_insn *INSN, rtx *OPVEC, int NOPERANDS) 40941 If defined, this target hook is a function which is executed just 40942 after the output of assembler code for INSN, to change the mode of 40943 the assembler if necessary. 40944 40945 Here the argument OPVEC is the vector containing the operands 40946 extracted from INSN, and NOPERANDS is the number of elements of the 40947 vector which contain meaningful data for this insn. The contents 40948 of this vector are what was used to convert the insn template into 40949 assembler code, so you can change the assembler mode by checking 40950 the contents of the vector. 40951 40952 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 40953 A C compound statement to output to stdio stream STREAM the 40954 assembler syntax for an instruction operand X. X is an RTL 40955 expression. 40956 40957 CODE is a value that can be used to specify one of several ways of 40958 printing the operand. It is used when identical operands must be 40959 printed differently depending on the context. CODE comes from the 40960 '%' specification that was used to request printing of the operand. 40961 If the specification was just '%DIGIT' then CODE is 0; if the 40962 specification was '%LTR DIGIT' then CODE is the ASCII code for LTR. 40963 40964 If X is a register, this macro should print the register's name. 40965 The names can be found in an array 'reg_names' whose type is 'char 40966 *[]'. 'reg_names' is initialized from 'REGISTER_NAMES'. 40967 40968 When the machine description has a specification '%PUNCT' (a '%' 40969 followed by a punctuation character), this macro is called with a 40970 null pointer for X and the punctuation character for CODE. 40971 40972 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 40973 A C expression which evaluates to true if CODE is a valid 40974 punctuation character for use in the 'PRINT_OPERAND' macro. If 40975 'PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 40976 punctuation characters (except for the standard one, '%') are used 40977 in this way. 40978 40979 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 40980 A C compound statement to output to stdio stream STREAM the 40981 assembler syntax for an instruction operand that is a memory 40982 reference whose address is X. X is an RTL expression. 40983 40984 On some machines, the syntax for a symbolic address depends on the 40985 section that the address refers to. On these machines, define the 40986 hook 'TARGET_ENCODE_SECTION_INFO' to store the information into the 40987 'symbol_ref', and then check for it here. *Note Assembler 40988 Format::. 40989 40990 -- Macro: DBR_OUTPUT_SEQEND (FILE) 40991 A C statement, to be executed after all slot-filler instructions 40992 have been output. If necessary, call 'dbr_sequence_length' to 40993 determine the number of slots filled in a sequence (zero if not 40994 currently outputting a sequence), to decide how many no-ops to 40995 output, or whatever. 40996 40997 Don't define this macro if it has nothing to do, but it is helpful 40998 in reading assembly output if the extent of the delay sequence is 40999 made explicit (e.g. with white space). 41000 41001 Note that output routines for instructions with delay slots must be 41002prepared to deal with not being output as part of a sequence (i.e. when 41003the scheduling pass is not run, or when no slot fillers could be found.) 41004The variable 'final_sequence' is null when not processing a sequence, 41005otherwise it contains the 'sequence' rtx being output. 41006 41007 -- Macro: REGISTER_PREFIX 41008 -- Macro: LOCAL_LABEL_PREFIX 41009 -- Macro: USER_LABEL_PREFIX 41010 -- Macro: IMMEDIATE_PREFIX 41011 If defined, C string expressions to be used for the '%R', '%L', 41012 '%U', and '%I' options of 'asm_fprintf' (see 'final.c'). These are 41013 useful when a single 'md' file must support multiple assembler 41014 formats. In that case, the various 'tm.h' files can define these 41015 macros differently. 41016 41017 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 41018 If defined this macro should expand to a series of 'case' 41019 statements which will be parsed inside the 'switch' statement of 41020 the 'asm_fprintf' function. This allows targets to define extra 41021 printf formats which may useful when generating their assembler 41022 statements. Note that uppercase letters are reserved for future 41023 generic extensions to asm_fprintf, and so are not available to 41024 target specific code. The output file is given by the parameter 41025 FILE. The varargs input pointer is ARGPTR and the rest of the 41026 format string, starting the character after the one that is being 41027 switched upon, is pointed to by FORMAT. 41028 41029 -- Macro: ASSEMBLER_DIALECT 41030 If your target supports multiple dialects of assembler language 41031 (such as different opcodes), define this macro as a C expression 41032 that gives the numeric index of the assembler language dialect to 41033 use, with zero as the first variant. 41034 41035 If this macro is defined, you may use constructs of the form 41036 '{option0|option1|option2...}' 41037 in the output templates of patterns (*note Output Template::) or in 41038 the first argument of 'asm_fprintf'. This construct outputs 41039 'option0', 'option1', 'option2', etc., if the value of 41040 'ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 41041 within these strings retain their usual meaning. If there are 41042 fewer alternatives within the braces than the value of 41043 'ASSEMBLER_DIALECT', the construct outputs nothing. If it's needed 41044 to print curly braces or '|' character in assembler output 41045 directly, '%{', '%}' and '%|' can be used. 41046 41047 If you do not define this macro, the characters '{', '|' and '}' do 41048 not have any special meaning when used in templates or operands to 41049 'asm_fprintf'. 41050 41051 Define the macros 'REGISTER_PREFIX', 'LOCAL_LABEL_PREFIX', 41052 'USER_LABEL_PREFIX' and 'IMMEDIATE_PREFIX' if you can express the 41053 variations in assembler language syntax with that mechanism. 41054 Define 'ASSEMBLER_DIALECT' and use the '{option0|option1}' syntax 41055 if the syntax variant are larger and involve such things as 41056 different opcodes or operand order. 41057 41058 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 41059 A C expression to output to STREAM some assembler code which will 41060 push hard register number REGNO onto the stack. The code need not 41061 be optimal, since this macro is used only when profiling. 41062 41063 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 41064 A C expression to output to STREAM some assembler code which will 41065 pop hard register number REGNO off of the stack. The code need not 41066 be optimal, since this macro is used only when profiling. 41067 41068 41069File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 41070 4107118.20.8 Output of Dispatch Tables 41072--------------------------------- 41073 41074This concerns dispatch tables. 41075 41076 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 41077 A C statement to output to the stdio stream STREAM an assembler 41078 pseudo-instruction to generate a difference between two labels. 41079 VALUE and REL are the numbers of two internal labels. The 41080 definitions of these labels are output using 41081 '(*targetm.asm_out.internal_label)', and they must be printed in 41082 the same way here. For example, 41083 41084 fprintf (STREAM, "\t.word L%d-L%d\n", 41085 VALUE, REL) 41086 41087 You must provide this macro on machines where the addresses in a 41088 dispatch table are relative to the table's own address. If 41089 defined, GCC will also use this macro on all machines when 41090 producing PIC. BODY is the body of the 'ADDR_DIFF_VEC'; it is 41091 provided so that the mode and flags can be read. 41092 41093 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 41094 This macro should be provided on machines where the addresses in a 41095 dispatch table are absolute. 41096 41097 The definition should be a C statement to output to the stdio 41098 stream STREAM an assembler pseudo-instruction to generate a 41099 reference to a label. VALUE is the number of an internal label 41100 whose definition is output using 41101 '(*targetm.asm_out.internal_label)'. For example, 41102 41103 fprintf (STREAM, "\t.word L%d\n", VALUE) 41104 41105 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 41106 Define this if the label before a jump-table needs to be output 41107 specially. The first three arguments are the same as for 41108 '(*targetm.asm_out.internal_label)'; the fourth argument is the 41109 jump-table which follows (a 'jump_table_data' containing an 41110 'addr_vec' or 'addr_diff_vec'). 41111 41112 This feature is used on system V to output a 'swbeg' statement for 41113 the table. 41114 41115 If this macro is not defined, these labels are output with 41116 '(*targetm.asm_out.internal_label)'. 41117 41118 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 41119 Define this if something special must be output at the end of a 41120 jump-table. The definition should be a C statement to be executed 41121 after the assembler code for the table is written. It should write 41122 the appropriate code to stdio stream STREAM. The argument TABLE is 41123 the jump-table insn, and NUM is the label-number of the preceding 41124 label. 41125 41126 If this macro is not defined, nothing special is output at the end 41127 of the jump-table. 41128 41129 -- Target Hook: void TARGET_ASM_POST_CFI_STARTPROC (FILE *, TREE) 41130 This target hook is used to emit assembly strings required by the 41131 target after the .cfi_startproc directive. The first argument is 41132 the file stream to write the strings to and the second argument is 41133 the function's declaration. The expected use is to add more .cfi_* 41134 directives. 41135 41136 The default is to not output any assembly strings. 41137 41138 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree 41139 DECL, int FOR_EH, int EMPTY) 41140 This target hook emits a label at the beginning of each FDE. It 41141 should be defined on targets where FDEs need special labels, and it 41142 should write the appropriate label, for the FDE associated with the 41143 function declaration DECL, to the stdio stream STREAM. The third 41144 argument, FOR_EH, is a boolean: true if this is for an exception 41145 table. The fourth argument, EMPTY, is a boolean: true if this is a 41146 placeholder label for an omitted FDE. 41147 41148 The default is that FDEs are not given nonlocal labels. 41149 41150 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM) 41151 This target hook emits a label at the beginning of the exception 41152 table. It should be defined on targets where it is desirable for 41153 the table to be broken up according to function. 41154 41155 The default is that no label is emitted. 41156 41157 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx 41158 PERSONALITY) 41159 If the target implements 'TARGET_ASM_UNWIND_EMIT', this hook may be 41160 used to emit a directive to install a personality hook into the 41161 unwind info. This hook should not be used if dwarf2 unwind info is 41162 used. 41163 41164 -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx_insn 41165 *INSN) 41166 This target hook emits assembly directives required to unwind the 41167 given instruction. This is only used when 41168 'TARGET_EXCEPT_UNWIND_INFO' returns 'UI_TARGET'. 41169 41170 -- Target Hook: rtx TARGET_ASM_MAKE_EH_SYMBOL_INDIRECT (rtx ORIGSYMBOL, 41171 bool PUBVIS) 41172 If necessary, modify personality and LSDA references to handle 41173 indirection. The original symbol is in 'origsymbol' and if 41174 'pubvis' is true the symbol is visible outside the TU. 41175 41176 -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN 41177 True if the 'TARGET_ASM_UNWIND_EMIT' hook should be called before 41178 the assembly for INSN has been emitted, false if the hook should be 41179 called afterward. 41180 41181 -- Target Hook: bool TARGET_ASM_SHOULD_RESTORE_CFA_STATE (void) 41182 For DWARF-based unwind frames, two CFI instructions provide for 41183 save and restore of register state. GCC maintains the current 41184 frame address (CFA) separately from the register bank but the 41185 unwinder in libgcc preserves this state along with the registers 41186 (and this is expected by the code that writes the unwind frames). 41187 This hook allows the target to specify that the CFA data is not 41188 saved/restored along with the registers by the target unwinder so 41189 that suitable additional instructions should be emitted to restore 41190 it. 41191 41192 41193File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 41194 4119518.20.9 Assembler Commands for Exception Regions 41196------------------------------------------------ 41197 41198This describes commands marking the start and the end of an exception 41199region. 41200 41201 -- Macro: EH_FRAME_SECTION_NAME 41202 If defined, a C string constant for the name of the section 41203 containing exception handling frame unwind information. If not 41204 defined, GCC will provide a default definition if the target 41205 supports named sections. 'crtstuff.c' uses this macro to switch to 41206 the appropriate section. 41207 41208 You should define this symbol if your target supports DWARF 2 frame 41209 unwind information and the default definition does not work. 41210 41211 -- Macro: EH_FRAME_THROUGH_COLLECT2 41212 If defined, DWARF 2 frame unwind information will identified by 41213 specially named labels. The collect2 process will locate these 41214 labels and generate code to register the frames. 41215 41216 This might be necessary, for instance, if the system linker will 41217 not place the eh_frames in-between the sentinals from 'crtstuff.c', 41218 or if the system linker does garbage collection and sections cannot 41219 be marked as not to be collected. 41220 41221 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 41222 Define this macro to 1 if your target is such that no frame unwind 41223 information encoding used with non-PIC code will ever require a 41224 runtime relocation, but the linker may not support merging 41225 read-only and read-write sections into a single read-write section. 41226 41227 -- Macro: MASK_RETURN_ADDR 41228 An rtx used to mask the return address found via 'RETURN_ADDR_RTX', 41229 so that it does not contain any extraneous set bits in it. 41230 41231 -- Macro: DWARF2_UNWIND_INFO 41232 Define this macro to 0 if your target supports DWARF 2 frame unwind 41233 information, but it does not yet work with exception handling. 41234 Otherwise, if your target supports this information (if it defines 41235 'INCOMING_RETURN_ADDR_RTX' and 'OBJECT_FORMAT_ELF'), GCC will 41236 provide a default definition of 1. 41237 41238 -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO 41239 (struct gcc_options *OPTS) 41240 This hook defines the mechanism that will be used for exception 41241 handling by the target. If the target has ABI specified unwind 41242 tables, the hook should return 'UI_TARGET'. If the target is to 41243 use the 'setjmp'/'longjmp'-based exception handling scheme, the 41244 hook should return 'UI_SJLJ'. If the target supports DWARF 2 frame 41245 unwind information, the hook should return 'UI_DWARF2'. 41246 41247 A target may, if exceptions are disabled, choose to return 41248 'UI_NONE'. This may end up simplifying other parts of 41249 target-specific code. The default implementation of this hook 41250 never returns 'UI_NONE'. 41251 41252 Note that the value returned by this hook should be constant. It 41253 should not depend on anything except the command-line switches 41254 described by OPTS. In particular, the setting 'UI_SJLJ' must be 41255 fixed at compiler start-up as C pre-processor macros and builtin 41256 functions related to exception handling are set up depending on 41257 this setting. 41258 41259 The default implementation of the hook first honors the 41260 '--enable-sjlj-exceptions' configure option, then 41261 'DWARF2_UNWIND_INFO', and finally defaults to 'UI_SJLJ'. If 41262 'DWARF2_UNWIND_INFO' depends on command-line options, the target 41263 must define this hook so that OPTS is used correctly. 41264 41265 -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT 41266 This variable should be set to 'true' if the target ABI requires 41267 unwinding tables even when exceptions are not used. It must not be 41268 modified by command-line option processing. 41269 41270 -- Macro: DONT_USE_BUILTIN_SETJMP 41271 Define this macro to 1 if the 'setjmp'/'longjmp'-based scheme 41272 should use the 'setjmp'/'longjmp' functions from the C library 41273 instead of the '__builtin_setjmp'/'__builtin_longjmp' machinery. 41274 41275 -- Macro: JMP_BUF_SIZE 41276 This macro has no effect unless 'DONT_USE_BUILTIN_SETJMP' is also 41277 defined. Define this macro if the default size of 'jmp_buf' buffer 41278 for the 'setjmp'/'longjmp'-based exception handling mechanism is 41279 not large enough, or if it is much too large. The default size is 41280 'FIRST_PSEUDO_REGISTER * sizeof(void *)'. 41281 41282 -- Macro: DWARF_CIE_DATA_ALIGNMENT 41283 This macro need only be defined if the target might save registers 41284 in the function prologue at an offset to the stack pointer that is 41285 not aligned to 'UNITS_PER_WORD'. The definition should be the 41286 negative minimum alignment if 'STACK_GROWS_DOWNWARD' is true, and 41287 the positive minimum alignment otherwise. *Note DWARF::. Only 41288 applicable if the target supports DWARF 2 frame unwind information. 41289 41290 -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 41291 Contains the value true if the target should add a zero word onto 41292 the end of a Dwarf-2 frame info section when used for exception 41293 handling. Default value is false if 'EH_FRAME_SECTION_NAME' is 41294 defined, and true otherwise. 41295 41296 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 41297 Given a register, this hook should return a parallel of registers 41298 to represent where to find the register pieces. Define this hook 41299 if the register and its mode are represented in Dwarf in 41300 non-contiguous locations, or if the register should be represented 41301 in more than one register in Dwarf. Otherwise, this hook should 41302 return 'NULL_RTX'. If not defined, the default is to return 41303 'NULL_RTX'. 41304 41305 -- Target Hook: machine_mode TARGET_DWARF_FRAME_REG_MODE (int REGNO) 41306 Given a register, this hook should return the mode which the 41307 corresponding Dwarf frame register should have. This is normally 41308 used to return a smaller mode than the raw mode to prevent call 41309 clobbered parts of a register altering the frame register size 41310 41311 -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS) 41312 If some registers are represented in Dwarf-2 unwind information in 41313 multiple pieces, define this hook to fill in information about the 41314 sizes of those pieces in the table used by the unwinder at runtime. 41315 It will be called by 'expand_builtin_init_dwarf_reg_sizes' after 41316 filling in a single size corresponding to each hard register; 41317 ADDRESS is the address of the table. 41318 41319 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 41320 This hook is used to output a reference from a frame unwinding 41321 table to the type_info object identified by SYM. It should return 41322 'true' if the reference was output. Returning 'false' will cause 41323 the reference to be output using the normal Dwarf2 routines. 41324 41325 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 41326 This flag should be set to 'true' on targets that use an ARM EABI 41327 based unwinding library, and 'false' on other targets. This 41328 effects the format of unwinding tables, and how the unwinder in 41329 entered after running a cleanup. The default is 'false'. 41330 41331 41332File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 41333 4133418.20.10 Assembler Commands for Alignment 41335----------------------------------------- 41336 41337This describes commands for alignment. 41338 41339 -- Macro: JUMP_ALIGN (LABEL) 41340 The alignment (log base 2) to put in front of LABEL, which is a 41341 common destination of jumps and has no fallthru incoming edge. 41342 41343 This macro need not be defined if you don't want any special 41344 alignment to be done at such a time. Most machine descriptions do 41345 not currently define the macro. 41346 41347 Unless it's necessary to inspect the LABEL parameter, it is better 41348 to set the variable ALIGN_JUMPS in the target's 41349 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 41350 user's selection in ALIGN_JUMPS in a 'JUMP_ALIGN' implementation. 41351 41352 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 41353 The alignment (log base 2) to put in front of LABEL, which follows 41354 a 'BARRIER'. 41355 41356 This macro need not be defined if you don't want any special 41357 alignment to be done at such a time. Most machine descriptions do 41358 not currently define the macro. 41359 41360 -- Macro: LOOP_ALIGN (LABEL) 41361 The alignment (log base 2) to put in front of LABEL that heads a 41362 frequently executed basic block (usually the header of a loop). 41363 41364 This macro need not be defined if you don't want any special 41365 alignment to be done at such a time. Most machine descriptions do 41366 not currently define the macro. 41367 41368 Unless it's necessary to inspect the LABEL parameter, it is better 41369 to set the variable 'align_loops' in the target's 41370 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 41371 user's selection in 'align_loops' in a 'LOOP_ALIGN' implementation. 41372 41373 -- Macro: LABEL_ALIGN (LABEL) 41374 The alignment (log base 2) to put in front of LABEL. If 41375 'LABEL_ALIGN_AFTER_BARRIER' / 'LOOP_ALIGN' specify a different 41376 alignment, the maximum of the specified values is used. 41377 41378 Unless it's necessary to inspect the LABEL parameter, it is better 41379 to set the variable 'align_labels' in the target's 41380 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 41381 user's selection in 'align_labels' in a 'LABEL_ALIGN' 41382 implementation. 41383 41384 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 41385 A C statement to output to the stdio stream STREAM an assembler 41386 instruction to advance the location counter by NBYTES bytes. Those 41387 bytes should be zero when loaded. NBYTES will be a C expression of 41388 type 'unsigned HOST_WIDE_INT'. 41389 41390 -- Macro: ASM_NO_SKIP_IN_TEXT 41391 Define this macro if 'ASM_OUTPUT_SKIP' should not be used in the 41392 text section because it fails to put zeros in the bytes that are 41393 skipped. This is true on many Unix systems, where the pseudo-op to 41394 skip bytes produces no-op instructions rather than zeros when used 41395 in the text section. 41396 41397 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 41398 A C statement to output to the stdio stream STREAM an assembler 41399 command to advance the location counter to a multiple of 2 to the 41400 POWER bytes. POWER will be a C expression of type 'int'. 41401 41402 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 41403 Like 'ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 41404 for padding, if necessary. 41405 41406 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 41407 A C statement to output to the stdio stream STREAM an assembler 41408 command to advance the location counter to a multiple of 2 to the 41409 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 41410 satisfy the alignment request. POWER and MAX_SKIP will be a C 41411 expression of type 'int'. 41412 41413 41414File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 41415 4141618.21 Controlling Debugging Information Format 41417============================================== 41418 41419This describes how to specify debugging information. 41420 41421* Menu: 41422 41423* All Debuggers:: Macros that affect all debugging formats uniformly. 41424* DBX Options:: Macros enabling specific options in DBX format. 41425* DBX Hooks:: Hook macros for varying DBX format. 41426* File Names and DBX:: Macros controlling output of file names in DBX format. 41427* DWARF:: Macros for DWARF format. 41428* VMS Debug:: Macros for VMS debug format. 41429 41430 41431File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 41432 4143318.21.1 Macros Affecting All Debugging Formats 41434---------------------------------------------- 41435 41436These macros affect all debugging formats. 41437 41438 -- Macro: DBX_REGISTER_NUMBER (REGNO) 41439 A C expression that returns the DBX register number for the 41440 compiler register number REGNO. In the default macro provided, the 41441 value of this expression will be REGNO itself. But sometimes there 41442 are some registers that the compiler knows about and DBX does not, 41443 or vice versa. In such cases, some register may need to have one 41444 number in the compiler and another for DBX. 41445 41446 If two registers have consecutive numbers inside GCC, and they can 41447 be used as a pair to hold a multiword value, then they _must_ have 41448 consecutive numbers after renumbering with 'DBX_REGISTER_NUMBER'. 41449 Otherwise, debuggers will be unable to access such a pair, because 41450 they expect register pairs to be consecutive in their own numbering 41451 scheme. 41452 41453 If you find yourself defining 'DBX_REGISTER_NUMBER' in way that 41454 does not preserve register pairs, then what you must do instead is 41455 redefine the actual register numbering scheme. 41456 41457 -- Macro: DEBUGGER_AUTO_OFFSET (X) 41458 A C expression that returns the integer offset value for an 41459 automatic variable having address X (an RTL expression). The 41460 default computation assumes that X is based on the frame-pointer 41461 and gives the offset from the frame-pointer. This is required for 41462 targets that produce debugging output for DBX and allow the 41463 frame-pointer to be eliminated when the '-g' option is used. 41464 41465 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 41466 A C expression that returns the integer offset value for an 41467 argument having address X (an RTL expression). The nominal offset 41468 is OFFSET. 41469 41470 -- Macro: PREFERRED_DEBUGGING_TYPE 41471 A C expression that returns the type of debugging output GCC should 41472 produce when the user specifies just '-g'. Define this if you have 41473 arranged for GCC to support more than one format of debugging 41474 output. Currently, the allowable values are 'DBX_DEBUG', 41475 'DWARF2_DEBUG', 'XCOFF_DEBUG', 'VMS_DEBUG', and 41476 'VMS_AND_DWARF2_DEBUG'. 41477 41478 When the user specifies '-ggdb', GCC normally also uses the value 41479 of this macro to select the debugging output format, but with two 41480 exceptions. If 'DWARF2_DEBUGGING_INFO' is defined, GCC uses the 41481 value 'DWARF2_DEBUG'. Otherwise, if 'DBX_DEBUGGING_INFO' is 41482 defined, GCC uses 'DBX_DEBUG'. 41483 41484 The value of this macro only affects the default debugging output; 41485 the user can always get a specific type of output by using 41486 '-gstabs', '-gdwarf-2', '-gxcoff', or '-gvms'. 41487 41488 41489File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 41490 4149118.21.2 Specific Options for DBX Output 41492--------------------------------------- 41493 41494These are specific options for DBX output. 41495 41496 -- Macro: DBX_DEBUGGING_INFO 41497 Define this macro if GCC should produce debugging output for DBX in 41498 response to the '-g' option. 41499 41500 -- Macro: XCOFF_DEBUGGING_INFO 41501 Define this macro if GCC should produce XCOFF format debugging 41502 output in response to the '-g' option. This is a variant of DBX 41503 format. 41504 41505 -- Macro: DEFAULT_GDB_EXTENSIONS 41506 Define this macro to control whether GCC should by default generate 41507 GDB's extended version of DBX debugging information (assuming 41508 DBX-format debugging information is enabled at all). If you don't 41509 define the macro, the default is 1: always generate the extended 41510 information if there is any occasion to. 41511 41512 -- Macro: DEBUG_SYMS_TEXT 41513 Define this macro if all '.stabs' commands should be output while 41514 in the text section. 41515 41516 -- Macro: ASM_STABS_OP 41517 A C string constant, including spacing, naming the assembler pseudo 41518 op to use instead of '"\t.stabs\t"' to define an ordinary debugging 41519 symbol. If you don't define this macro, '"\t.stabs\t"' is used. 41520 This macro applies only to DBX debugging information format. 41521 41522 -- Macro: ASM_STABD_OP 41523 A C string constant, including spacing, naming the assembler pseudo 41524 op to use instead of '"\t.stabd\t"' to define a debugging symbol 41525 whose value is the current location. If you don't define this 41526 macro, '"\t.stabd\t"' is used. This macro applies only to DBX 41527 debugging information format. 41528 41529 -- Macro: ASM_STABN_OP 41530 A C string constant, including spacing, naming the assembler pseudo 41531 op to use instead of '"\t.stabn\t"' to define a debugging symbol 41532 with no name. If you don't define this macro, '"\t.stabn\t"' is 41533 used. This macro applies only to DBX debugging information format. 41534 41535 -- Macro: DBX_NO_XREFS 41536 Define this macro if DBX on your system does not support the 41537 construct 'xsTAGNAME'. On some systems, this construct is used to 41538 describe a forward reference to a structure named TAGNAME. On 41539 other systems, this construct is not supported at all. 41540 41541 -- Macro: DBX_CONTIN_LENGTH 41542 A symbol name in DBX-format debugging information is normally 41543 continued (split into two separate '.stabs' directives) when it 41544 exceeds a certain length (by default, 80 characters). On some 41545 operating systems, DBX requires this splitting; on others, 41546 splitting must not be done. You can inhibit splitting by defining 41547 this macro with the value zero. You can override the default 41548 splitting-length by defining this macro as an expression for the 41549 length you desire. 41550 41551 -- Macro: DBX_CONTIN_CHAR 41552 Normally continuation is indicated by adding a '\' character to the 41553 end of a '.stabs' string when a continuation follows. To use a 41554 different character instead, define this macro as a character 41555 constant for the character you want to use. Do not define this 41556 macro if backslash is correct for your system. 41557 41558 -- Macro: DBX_STATIC_STAB_DATA_SECTION 41559 Define this macro if it is necessary to go to the data section 41560 before outputting the '.stabs' pseudo-op for a non-global static 41561 variable. 41562 41563 -- Macro: DBX_TYPE_DECL_STABS_CODE 41564 The value to use in the "code" field of the '.stabs' directive for 41565 a typedef. The default is 'N_LSYM'. 41566 41567 -- Macro: DBX_STATIC_CONST_VAR_CODE 41568 The value to use in the "code" field of the '.stabs' directive for 41569 a static variable located in the text section. DBX format does not 41570 provide any "right" way to do this. The default is 'N_FUN'. 41571 41572 -- Macro: DBX_REGPARM_STABS_CODE 41573 The value to use in the "code" field of the '.stabs' directive for 41574 a parameter passed in registers. DBX format does not provide any 41575 "right" way to do this. The default is 'N_RSYM'. 41576 41577 -- Macro: DBX_REGPARM_STABS_LETTER 41578 The letter to use in DBX symbol data to identify a symbol as a 41579 parameter passed in registers. DBX format does not customarily 41580 provide any way to do this. The default is ''P''. 41581 41582 -- Macro: DBX_FUNCTION_FIRST 41583 Define this macro if the DBX information for a function and its 41584 arguments should precede the assembler code for the function. 41585 Normally, in DBX format, the debugging information entirely follows 41586 the assembler code. 41587 41588 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 41589 Define this macro, with value 1, if the value of a symbol 41590 describing the scope of a block ('N_LBRAC' or 'N_RBRAC') should be 41591 relative to the start of the enclosing function. Normally, GCC 41592 uses an absolute address. 41593 41594 -- Macro: DBX_LINES_FUNCTION_RELATIVE 41595 Define this macro, with value 1, if the value of a symbol 41596 indicating the current line number ('N_SLINE') should be relative 41597 to the start of the enclosing function. Normally, GCC uses an 41598 absolute address. 41599 41600 -- Macro: DBX_USE_BINCL 41601 Define this macro if GCC should generate 'N_BINCL' and 'N_EINCL' 41602 stabs for included header files, as on Sun systems. This macro 41603 also directs GCC to output a type number as a pair of a file number 41604 and a type number within the file. Normally, GCC does not generate 41605 'N_BINCL' or 'N_EINCL' stabs, and it outputs a single number for a 41606 type number. 41607 41608 41609File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 41610 4161118.21.3 Open-Ended Hooks for DBX Format 41612--------------------------------------- 41613 41614These are hooks for DBX format. 41615 41616 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 41617 A C statement to output DBX debugging information before code for 41618 line number LINE of the current source file to the stdio stream 41619 STREAM. COUNTER is the number of time the macro was invoked, 41620 including the current invocation; it is intended to generate unique 41621 labels in the assembly output. 41622 41623 This macro should not be defined if the default output is correct, 41624 or if it can be made correct by defining 41625 'DBX_LINES_FUNCTION_RELATIVE'. 41626 41627 -- Macro: NO_DBX_FUNCTION_END 41628 Some stabs encapsulation formats (in particular ECOFF), cannot 41629 handle the '.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 41630 extension construct. On those machines, define this macro to turn 41631 this feature off without disturbing the rest of the gdb extensions. 41632 41633 -- Macro: NO_DBX_BNSYM_ENSYM 41634 Some assemblers cannot handle the '.stabd BNSYM/ENSYM,0,0' gdb dbx 41635 extension construct. On those machines, define this macro to turn 41636 this feature off without disturbing the rest of the gdb extensions. 41637 41638 41639File: gccint.info, Node: File Names and DBX, Next: DWARF, Prev: DBX Hooks, Up: Debugging Info 41640 4164118.21.4 File Names in DBX Format 41642-------------------------------- 41643 41644This describes file names in DBX format. 41645 41646 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 41647 A C statement to output DBX debugging information to the stdio 41648 stream STREAM, which indicates that file NAME is the main source 41649 file--the file specified as the input file for compilation. This 41650 macro is called only once, at the beginning of compilation. 41651 41652 This macro need not be defined if the standard form of output for 41653 DBX debugging information is appropriate. 41654 41655 It may be necessary to refer to a label equal to the beginning of 41656 the text section. You can use 'assemble_name (stream, 41657 ltext_label_name)' to do so. If you do this, you must also set the 41658 variable USED_LTEXT_LABEL_NAME to 'true'. 41659 41660 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 41661 Define this macro, with value 1, if GCC should not emit an 41662 indication of the current directory for compilation and current 41663 source language at the beginning of the file. 41664 41665 -- Macro: NO_DBX_GCC_MARKER 41666 Define this macro, with value 1, if GCC should not emit an 41667 indication that this object file was compiled by GCC. The default 41668 is to emit an 'N_OPT' stab at the beginning of every source file, 41669 with 'gcc2_compiled.' for the string and value 0. 41670 41671 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 41672 A C statement to output DBX debugging information at the end of 41673 compilation of the main source file NAME. Output should be written 41674 to the stdio stream STREAM. 41675 41676 If you don't define this macro, nothing special is output at the 41677 end of compilation, which is correct for most machines. 41678 41679 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 41680 Define this macro _instead of_ defining 41681 'DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 41682 the end of compilation is an 'N_SO' stab with an empty string, 41683 whose value is the highest absolute text address in the file. 41684 41685 41686File: gccint.info, Node: DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 41687 4168818.21.5 Macros for DWARF Output 41689------------------------------- 41690 41691Here are macros for DWARF output. 41692 41693 -- Macro: DWARF2_DEBUGGING_INFO 41694 Define this macro if GCC should produce dwarf version 2 format 41695 debugging output in response to the '-g' option. 41696 41697 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree 41698 FUNCTION) 41699 Define this to enable the dwarf attribute 41700 'DW_AT_calling_convention' to be emitted for each function. 41701 Instead of an integer return the enum value for the 'DW_CC_' 41702 tag. 41703 41704 To support optional call frame debugging information, you must also 41705 define 'INCOMING_RETURN_ADDR_RTX' and either set 41706 'RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 41707 prologue, or call 'dwarf2out_def_cfa' and 'dwarf2out_reg_save' as 41708 appropriate from 'TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 41709 41710 -- Macro: DWARF2_FRAME_INFO 41711 Define this macro to a nonzero value if GCC should always output 41712 Dwarf 2 frame information. If 'TARGET_EXCEPT_UNWIND_INFO' (*note 41713 Exception Region Output::) returns 'UI_DWARF2', and exceptions are 41714 enabled, GCC will output this information not matter how you define 41715 'DWARF2_FRAME_INFO'. 41716 41717 -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void) 41718 This hook defines the mechanism that will be used for describing 41719 frame unwind information to the debugger. Normally the hook will 41720 return 'UI_DWARF2' if DWARF 2 debug information is enabled, and 41721 return 'UI_NONE' otherwise. 41722 41723 A target may return 'UI_DWARF2' even when DWARF 2 debug information 41724 is disabled in order to always output DWARF 2 frame information. 41725 41726 A target may return 'UI_TARGET' if it has ABI specified unwind 41727 tables. This will suppress generation of the normal debug frame 41728 unwind information. 41729 41730 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 41731 Define this macro to be a nonzero value if the assembler can 41732 generate Dwarf 2 line debug info sections. This will result in 41733 much more compact line number tables, and hence is desirable if it 41734 works. 41735 41736 -- Macro: DWARF2_ASM_VIEW_DEBUG_INFO 41737 Define this macro to be a nonzero value if the assembler supports 41738 view assignment and verification in '.loc'. If it does not, but 41739 the user enables location views, the compiler may have to fallback 41740 to internal line number tables. 41741 41742 -- Target Hook: int TARGET_RESET_LOCATION_VIEW (rtx_insn *) 41743 This hook, if defined, enables -ginternal-reset-location-views, and 41744 uses its result to override cases in which the estimated min insn 41745 length might be nonzero even when a PC advance (i.e., a view reset) 41746 cannot be taken for granted. 41747 41748 If the hook is defined, it must return a positive value to indicate 41749 the insn definitely advances the PC, and so the view number can be 41750 safely assumed to be reset; a negative value to mean the insn 41751 definitely does not advance the PC, and os the view number must not 41752 be reset; or zero to decide based on the estimated insn length. 41753 41754 If insn length is to be regarded as reliable, set the hook to 41755 'hook_int_rtx_insn_0'. 41756 41757 -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS 41758 True if the '.debug_pubtypes' and '.debug_pubnames' sections should 41759 be emitted. These sections are not used on most platforms, and in 41760 particular GDB does not use them. 41761 41762 -- Target Hook: bool TARGET_DELAY_SCHED2 41763 True if sched2 is not to be run at its normal place. This usually 41764 means it will be run as part of machine-specific reorg. 41765 41766 -- Target Hook: bool TARGET_DELAY_VARTRACK 41767 True if vartrack is not to be run at its normal place. This 41768 usually means it will be run as part of machine-specific reorg. 41769 41770 -- Target Hook: bool TARGET_NO_REGISTER_ALLOCATION 41771 True if register allocation and the passes following it should not 41772 be run. Usually true only for virtual assembler targets. 41773 41774 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 41775 A C statement to issue assembly directives that create a difference 41776 LAB1 minus LAB2, using an integer of the given SIZE. 41777 41778 -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2) 41779 A C statement to issue assembly directives that create a difference 41780 between the two given labels in system defined units, e.g. 41781 instruction slots on IA64 VMS, using an integer of the given size. 41782 41783 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, OFFSET, 41784 SECTION) 41785 A C statement to issue assembly directives that create a 41786 section-relative reference to the given LABEL plus OFFSET, using an 41787 integer of the given SIZE. The label is known to be defined in the 41788 given SECTION. 41789 41790 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 41791 A C statement to issue assembly directives that create a 41792 self-relative reference to the given LABEL, using an integer of the 41793 given SIZE. 41794 41795 -- Macro: ASM_OUTPUT_DWARF_DATAREL (STREAM, SIZE, LABEL) 41796 A C statement to issue assembly directives that create a reference 41797 to the given LABEL relative to the dbase, using an integer of the 41798 given SIZE. 41799 41800 -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL) 41801 A C statement to issue assembly directives that create a reference 41802 to the DWARF table identifier LABEL from the current section. This 41803 is used on some systems to avoid garbage collecting a DWARF table 41804 which is referenced by a function. 41805 41806 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 41807 SIZE, rtx X) 41808 If defined, this target hook is a function which outputs a 41809 DTP-relative reference to the given TLS symbol of the specified 41810 size. 41811 41812 41813File: gccint.info, Node: VMS Debug, Prev: DWARF, Up: Debugging Info 41814 4181518.21.6 Macros for VMS Debug Format 41816----------------------------------- 41817 41818Here are macros for VMS debug format. 41819 41820 -- Macro: VMS_DEBUGGING_INFO 41821 Define this macro if GCC should produce debugging output for VMS in 41822 response to the '-g' option. The default behavior for VMS is to 41823 generate minimal debug info for a traceback in the absence of '-g' 41824 unless explicitly overridden with '-g0'. This behavior is 41825 controlled by 'TARGET_OPTION_OPTIMIZATION' and 41826 'TARGET_OPTION_OVERRIDE'. 41827 41828 41829File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 41830 4183118.22 Cross Compilation and Floating Point 41832========================================== 41833 41834While all modern machines use twos-complement representation for 41835integers, there are a variety of representations for floating point 41836numbers. This means that in a cross-compiler the representation of 41837floating point numbers in the compiled program may be different from 41838that used in the machine doing the compilation. 41839 41840 Because different representation systems may offer different amounts of 41841range and precision, all floating point constants must be represented in 41842the target machine's format. Therefore, the cross compiler cannot 41843safely use the host machine's floating point arithmetic; it must emulate 41844the target's arithmetic. To ensure consistency, GCC always uses 41845emulation to work with floating point values, even when the host and 41846target floating point formats are identical. 41847 41848 The following macros are provided by 'real.h' for the compiler to use. 41849All parts of the compiler which generate or optimize floating-point 41850calculations must use these macros. They may evaluate their operands 41851more than once, so operands must not have side effects. 41852 41853 -- Macro: REAL_VALUE_TYPE 41854 The C data type to be used to hold a floating point value in the 41855 target machine's format. Typically this is a 'struct' containing 41856 an array of 'HOST_WIDE_INT', but all code should treat it as an 41857 opaque quantity. 41858 41859 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 41860 Truncates X to a signed integer, rounding toward zero. 41861 41862 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 41863 (REAL_VALUE_TYPE X) 41864 Truncates X to an unsigned integer, rounding toward zero. If X is 41865 negative, returns zero. 41866 41867 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, 41868 machine_mode MODE) 41869 Converts STRING into a floating point number in the target 41870 machine's representation for mode MODE. This routine can handle 41871 both decimal and hexadecimal floating point constants, using the 41872 syntax defined by the C language for both. 41873 41874 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 41875 Returns 1 if X is negative (including negative zero), 0 otherwise. 41876 41877 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 41878 Determines whether X represents infinity (positive or negative). 41879 41880 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 41881 Determines whether X represents a "NaN" (not-a-number). 41882 41883 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 41884 Returns the negative of the floating point value X. 41885 41886 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 41887 Returns the absolute value of X. 41888 41889 41890File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 41891 4189218.23 Mode Switching Instructions 41893================================= 41894 41895The following macros control mode switching optimizations: 41896 41897 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 41898 Define this macro if the port needs extra instructions inserted for 41899 mode switching in an optimizing compilation. 41900 41901 For an example, the SH4 can perform both single and double 41902 precision floating point operations, but to perform a single 41903 precision operation, the FPSCR PR bit has to be cleared, while for 41904 a double precision operation, this bit has to be set. Changing the 41905 PR bit requires a general purpose register as a scratch register, 41906 hence these FPSCR sets have to be inserted before reload, i.e. you 41907 cannot put this into instruction emitting or 41908 'TARGET_MACHINE_DEPENDENT_REORG'. 41909 41910 You can have multiple entities that are mode-switched, and select 41911 at run time which entities actually need it. 41912 'OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY that 41913 needs mode-switching. If you define this macro, you also have to 41914 define 'NUM_MODES_FOR_MODE_SWITCHING', 'TARGET_MODE_NEEDED', 41915 'TARGET_MODE_PRIORITY' and 'TARGET_MODE_EMIT'. 41916 'TARGET_MODE_AFTER', 'TARGET_MODE_ENTRY', and 'TARGET_MODE_EXIT' 41917 are optional. 41918 41919 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 41920 If you define 'OPTIMIZE_MODE_SWITCHING', you have to define this as 41921 initializer for an array of integers. Each initializer element N 41922 refers to an entity that needs mode switching, and specifies the 41923 number of different modes that might need to be set for this 41924 entity. The position of the initializer in the 41925 initializer--starting counting at zero--determines the integer that 41926 is used to refer to the mode-switched entity in question. In 41927 macros that take mode arguments / yield a mode result, modes are 41928 represented as numbers 0 ... N - 1. N is used to specify that no 41929 mode switch is needed / supplied. 41930 41931 -- Target Hook: void TARGET_MODE_EMIT (int ENTITY, int MODE, int 41932 PREV_MODE, HARD_REG_SET REGS_LIVE) 41933 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE is 41934 the set of hard registers live at the point where the insn(s) are 41935 to be inserted. PREV_MOXDE indicates the mode to switch from. 41936 Sets of a lower numbered entity will be emitted before sets of a 41937 higher numbered entity to a mode of the same or lower priority. 41938 41939 -- Target Hook: int TARGET_MODE_NEEDED (int ENTITY, rtx_insn *INSN) 41940 ENTITY is an integer specifying a mode-switched entity. If 41941 'OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 41942 return an integer value not larger than the corresponding element 41943 in 'NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 41944 must be switched into prior to the execution of INSN. 41945 41946 -- Target Hook: int TARGET_MODE_AFTER (int ENTITY, int MODE, rtx_insn 41947 *INSN) 41948 ENTITY is an integer specifying a mode-switched entity. If this 41949 macro is defined, it is evaluated for every INSN during mode 41950 switching. It determines the mode that an insn results in (if 41951 different from the incoming mode). 41952 41953 -- Target Hook: int TARGET_MODE_ENTRY (int ENTITY) 41954 If this macro is defined, it is evaluated for every ENTITY that 41955 needs mode switching. It should evaluate to an integer, which is a 41956 mode that ENTITY is assumed to be switched to at function entry. 41957 If 'TARGET_MODE_ENTRY' is defined then 'TARGET_MODE_EXIT' must be 41958 defined. 41959 41960 -- Target Hook: int TARGET_MODE_EXIT (int ENTITY) 41961 If this macro is defined, it is evaluated for every ENTITY that 41962 needs mode switching. It should evaluate to an integer, which is a 41963 mode that ENTITY is assumed to be switched to at function exit. If 41964 'TARGET_MODE_EXIT' is defined then 'TARGET_MODE_ENTRY' must be 41965 defined. 41966 41967 -- Target Hook: int TARGET_MODE_PRIORITY (int ENTITY, int N) 41968 This macro specifies the order in which modes for ENTITY are 41969 processed. 0 is the highest priority, 41970 'NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 41971 of the macro should be an integer designating a mode for ENTITY. 41972 For any fixed ENTITY, 'mode_priority' (ENTITY, N) shall be a 41973 bijection in 0 ... 'num_modes_for_mode_switching[ENTITY] - 1'. 41974 41975 41976File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros 41977 4197818.24 Defining target-specific uses of '__attribute__' 41979====================================================== 41980 41981Target-specific attributes may be defined for functions, data and types. 41982These are described using the following target hooks; they also need to 41983be documented in 'extend.texi'. 41984 41985 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 41986 If defined, this target hook points to an array of 'struct 41987 attribute_spec' (defined in 'tree-core.h') specifying the machine 41988 specific attributes for this target and some of the restrictions on 41989 the entities to which these attributes are applied and the 41990 arguments they take. 41991 41992 -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree 41993 NAME) 41994 If defined, this target hook is a function which returns true if 41995 the machine-specific attribute named NAME expects an identifier 41996 given as its first argument to be passed on as a plain identifier, 41997 not subjected to name lookup. If this is not defined, the default 41998 is false for all machine-specific attributes. 41999 42000 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1, 42001 const_tree TYPE2) 42002 If defined, this target hook is a function which returns zero if 42003 the attributes on TYPE1 and TYPE2 are incompatible, one if they are 42004 compatible, and two if they are nearly compatible (which causes a 42005 warning to be generated). If this is not defined, machine-specific 42006 attributes are supposed always to be compatible. 42007 42008 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 42009 If defined, this target hook is a function which assigns default 42010 attributes to the newly defined TYPE. 42011 42012 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 42013 TYPE2) 42014 Define this target hook if the merging of type attributes needs 42015 special handling. If defined, the result is a list of the combined 42016 'TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 42017 'comptypes' has already been called and returned 1. This function 42018 may call 'merge_attributes' to handle machine-independent merging. 42019 42020 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 42021 NEWDECL) 42022 Define this target hook if the merging of decl attributes needs 42023 special handling. If defined, the result is a list of the combined 42024 'DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 42025 declaration of OLDDECL. Examples of when this is needed are when 42026 one attribute overrides another, or when an attribute is nullified 42027 by a subsequent definition. This function may call 42028 'merge_attributes' to handle machine-independent merging. 42029 42030 If the only target-specific handling you require is 'dllimport' for 42031 Microsoft Windows targets, you should define the macro 42032 'TARGET_DLLIMPORT_DECL_ATTRIBUTES' to '1'. The compiler will then 42033 define a function called 'merge_dllimport_decl_attributes' which 42034 can then be defined as the expansion of 42035 'TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 42036 'handle_dll_attribute' in the attribute table for your port to 42037 perform initial processing of the 'dllimport' and 'dllexport' 42038 attributes. This is done in 'i386/cygwin.h' and 'i386/i386.c', for 42039 example. 42040 42041 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree 42042 DECL) 42043 DECL is a variable or function with '__attribute__((dllimport))' 42044 specified. Use this hook if the target needs to add extra 42045 validation checks to 'handle_dll_attribute'. 42046 42047 -- Macro: TARGET_DECLSPEC 42048 Define this macro to a nonzero value if you want to treat 42049 '__declspec(X)' as equivalent to '__attribute((X))'. By default, 42050 this behavior is enabled only for targets that define 42051 'TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 42052 '__declspec' is via a built-in macro, but you should not rely on 42053 this implementation detail. 42054 42055 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 42056 *ATTR_PTR) 42057 Define this target hook if you want to be able to add attributes to 42058 a decl when it is being created. This is normally useful for back 42059 ends which wish to implement a pragma by using the attributes which 42060 correspond to the pragma's effect. The NODE argument is the decl 42061 which is being created. The ATTR_PTR argument is a pointer to the 42062 attribute list for this decl. The list itself should not be 42063 modified, since it may be shared with other decls, but attributes 42064 may be chained on the head of the list and '*ATTR_PTR' modified to 42065 point to the new attributes, or a copy of the list may be made if 42066 further changes are needed. 42067 42068 -- Target Hook: tree TARGET_HANDLE_GENERIC_ATTRIBUTE (tree *NODE, tree 42069 NAME, tree ARGS, int FLAGS, bool *NO_ADD_ATTRS) 42070 Define this target hook if you want to be able to perform 42071 additional target-specific processing of an attribute which is 42072 handled generically by a front end. The arguments are the same as 42073 those which are passed to attribute handlers. So far this only 42074 affects the NOINIT and SECTION attribute. 42075 42076 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree 42077 FNDECL) 42078 This target hook returns 'true' if it is OK to inline FNDECL into 42079 the current function, despite its having target-specific 42080 attributes, 'false' otherwise. By default, if a function has a 42081 target specific attribute attached to it, it will not be inlined. 42082 42083 -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, tree 42084 NAME, tree ARGS, int FLAGS) 42085 This hook is called to parse 'attribute(target("..."))', which 42086 allows setting target-specific options on individual functions. 42087 These function-specific options may differ from the options 42088 specified on the command line. The hook should return 'true' if 42089 the options are valid. 42090 42091 The hook should set the 'DECL_FUNCTION_SPECIFIC_TARGET' field in 42092 the function declaration to hold a pointer to a target-specific 42093 'struct cl_target_option' structure. 42094 42095 -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR, 42096 struct gcc_options *OPTS, struct gcc_options *OPTS_SET) 42097 This hook is called to save any additional target-specific 42098 information in the 'struct cl_target_option' structure for 42099 function-specific options from the 'struct gcc_options' structure. 42100 *Note Option file format::. 42101 42102 -- Target Hook: void TARGET_OPTION_RESTORE (struct gcc_options *OPTS, 42103 struct gcc_options *OPTS_SET, struct cl_target_option *PTR) 42104 This hook is called to restore any additional target-specific 42105 information in the 'struct cl_target_option' structure for 42106 function-specific options to the 'struct gcc_options' structure. 42107 42108 -- Target Hook: void TARGET_OPTION_POST_STREAM_IN (struct 42109 cl_target_option *PTR) 42110 This hook is called to update target-specific information in the 42111 'struct cl_target_option' structure after it is streamed in from 42112 LTO bytecode. 42113 42114 -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT, 42115 struct cl_target_option *PTR) 42116 This hook is called to print any additional target-specific 42117 information in the 'struct cl_target_option' structure for 42118 function-specific options. 42119 42120 -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree 42121 POP_TARGET) 42122 This target hook parses the options for '#pragma GCC target', which 42123 sets the target-specific options for functions that occur later in 42124 the input stream. The options accepted should be the same as those 42125 handled by the 'TARGET_OPTION_VALID_ATTRIBUTE_P' hook. 42126 42127 -- Target Hook: void TARGET_OPTION_OVERRIDE (void) 42128 Sometimes certain combinations of command options do not make sense 42129 on a particular target machine. You can override the hook 42130 'TARGET_OPTION_OVERRIDE' to take account of this. This hooks is 42131 called once just after all the command options have been parsed. 42132 42133 Don't use this hook to turn on various extra optimizations for 42134 '-O'. That is what 'TARGET_OPTION_OPTIMIZATION' is for. 42135 42136 If you need to do something whenever the optimization level is 42137 changed via the optimize attribute or pragma, see 42138 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' 42139 42140 -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree 42141 DECL2) 42142 This target hook returns 'true' if DECL1 and DECL2 are versions of 42143 the same function. DECL1 and DECL2 are function versions if and 42144 only if they have the same function signature and different target 42145 specific attributes, that is, they are compiled for different 42146 target machines. 42147 42148 -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE) 42149 This target hook returns 'false' if the CALLER function cannot 42150 inline CALLEE, based on target specific information. By default, 42151 inlining is not allowed if the callee function has function 42152 specific target options and the caller does not use the same 42153 options. 42154 42155 -- Target Hook: void TARGET_RELAYOUT_FUNCTION (tree FNDECL) 42156 This target hook fixes function FNDECL after attributes are 42157 processed. Default does nothing. On ARM, the default function's 42158 alignment is updated with the attribute target. 42159 42160 42161File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros 42162 4216318.25 Emulating TLS 42164=================== 42165 42166For targets whose psABI does not provide Thread Local Storage via 42167specific relocations and instruction sequences, an emulation layer is 42168used. A set of target hooks allows this emulation layer to be 42169configured for the requirements of a particular target. For instance 42170the psABI may in fact specify TLS support in terms of an emulation 42171layer. 42172 42173 The emulation layer works by creating a control object for every TLS 42174object. To access the TLS object, a lookup function is provided which, 42175when given the address of the control object, will return the address of 42176the current thread's instance of the TLS object. 42177 42178 -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS 42179 Contains the name of the helper function that uses a TLS control 42180 object to locate a TLS instance. The default causes libgcc's 42181 emulated TLS helper function to be used. 42182 42183 -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON 42184 Contains the name of the helper function that should be used at 42185 program startup to register TLS objects that are implicitly 42186 initialized to zero. If this is 'NULL', all TLS objects will have 42187 explicit initializers. The default causes libgcc's emulated TLS 42188 registration function to be used. 42189 42190 -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION 42191 Contains the name of the section in which TLS control variables 42192 should be placed. The default of 'NULL' allows these to be placed 42193 in any section. 42194 42195 -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION 42196 Contains the name of the section in which TLS initializers should 42197 be placed. The default of 'NULL' allows these to be placed in any 42198 section. 42199 42200 -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX 42201 Contains the prefix to be prepended to TLS control variable names. 42202 The default of 'NULL' uses a target-specific prefix. 42203 42204 -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX 42205 Contains the prefix to be prepended to TLS initializer objects. 42206 The default of 'NULL' uses a target-specific prefix. 42207 42208 -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME) 42209 Specifies a function that generates the FIELD_DECLs for a TLS 42210 control object type. TYPE is the RECORD_TYPE the fields are for 42211 and NAME should be filled with the structure tag, if the default of 42212 '__emutls_object' is unsuitable. The default creates a type 42213 suitable for libgcc's emulated TLS function. 42214 42215 -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree 42216 TMPL_ADDR) 42217 Specifies a function that generates the CONSTRUCTOR to initialize a 42218 TLS control object. VAR is the TLS control object, DECL is the TLS 42219 object and TMPL_ADDR is the address of the initializer. The 42220 default initializes libgcc's emulated TLS control object. 42221 42222 -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED 42223 Specifies whether the alignment of TLS control variable objects is 42224 fixed and should not be increased as some backends may do to 42225 optimize single objects. The default is false. 42226 42227 -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS 42228 Specifies whether a DWARF 'DW_OP_form_tls_address' location 42229 descriptor may be used to describe emulated TLS control objects. 42230 42231 42232File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros 42233 4223418.26 Defining coprocessor specifics for MIPS targets. 42235====================================================== 42236 42237The MIPS specification allows MIPS implementations to have as many as 4 42238coprocessors, each with as many as 32 private registers. GCC supports 42239accessing these registers and transferring values between the registers 42240and memory using asm-ized variables. For example: 42241 42242 register unsigned int cp0count asm ("c0r1"); 42243 unsigned int d; 42244 42245 d = cp0count + 3; 42246 42247 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 42248names may be added as described below, or the default names may be 42249overridden entirely in 'SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 42250 42251 Coprocessor registers are assumed to be epilogue-used; sets to them 42252will be preserved even if it does not appear that the register is used 42253again later in the function. 42254 42255 Another note: according to the MIPS spec, coprocessor 1 (if present) is 42256the FPU. One accesses COP1 registers through standard mips 42257floating-point support; they are not included in this mechanism. 42258 42259 42260File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 42261 4226218.27 Parameters for Precompiled Header Validity Checking 42263========================================================= 42264 42265 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ) 42266 This hook returns a pointer to the data needed by 42267 'TARGET_PCH_VALID_P' and sets '*SZ' to the size of the data in 42268 bytes. 42269 42270 -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA, 42271 size_t SZ) 42272 This hook checks whether the options used to create a PCH file are 42273 compatible with the current settings. It returns 'NULL' if so and 42274 a suitable error message if not. Error messages will be presented 42275 to the user and must be localized using '_(MSG)'. 42276 42277 DATA is the data that was returned by 'TARGET_GET_PCH_VALIDITY' 42278 when the PCH file was created and SZ is the size of that data in 42279 bytes. It's safe to assume that the data was created by the same 42280 version of the compiler, so no format checking is needed. 42281 42282 The default definition of 'default_pch_valid_p' should be suitable 42283 for most targets. 42284 42285 -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int 42286 PCH_FLAGS) 42287 If this hook is nonnull, the default implementation of 42288 'TARGET_PCH_VALID_P' will use it to check for compatible values of 42289 'target_flags'. PCH_FLAGS specifies the value that 'target_flags' 42290 had when the PCH file was created. The return value is the same as 42291 for 'TARGET_PCH_VALID_P'. 42292 42293 -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void) 42294 Called before writing out a PCH file. If the target has some 42295 garbage-collected data that needs to be in a particular state on 42296 PCH loads, it can use this hook to enforce that state. Very few 42297 targets need to do anything here. 42298 42299 42300File: gccint.info, Node: C++ ABI, Next: D Language and ABI, Prev: PCH Target, Up: Target Macros 42301 4230218.28 C++ ABI parameters 42303======================== 42304 42305 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 42306 Define this hook to override the integer type used for guard 42307 variables. These are used to implement one-time construction of 42308 static objects. The default is long_long_integer_type_node. 42309 42310 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 42311 This hook determines how guard variables are used. It should 42312 return 'false' (the default) if the first byte should be used. A 42313 return value of 'true' indicates that only the least significant 42314 bit should be used. 42315 42316 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 42317 This hook returns the size of the cookie to use when allocating an 42318 array whose elements have the indicated TYPE. Assumes that it is 42319 already known that a cookie is needed. The default is 'max(sizeof 42320 (size_t), alignof(type))', as defined in section 2.7 of the 42321 IA64/Generic C++ ABI. 42322 42323 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 42324 This hook should return 'true' if the element size should be stored 42325 in array cookies. The default is to return 'false'. 42326 42327 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 42328 IMPORT_EXPORT) 42329 If defined by a backend this hook allows the decision made to 42330 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 42331 contain 1 if the class is going to be exported, -1 if it is going 42332 to be imported and 0 otherwise. This function should return the 42333 modified value and perform any other actions necessary to support 42334 the backend's targeted operating system. 42335 42336 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 42337 This hook should return 'true' if constructors and destructors 42338 return the address of the object created/destroyed. The default is 42339 to return 'false'. 42340 42341 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 42342 This hook returns true if the key method for a class (i.e., the 42343 method which, if defined in the current translation unit, causes 42344 the virtual table to be emitted) may be an inline function. Under 42345 the standard Itanium C++ ABI the key method may be an inline 42346 function so long as the function is not declared inline in the 42347 class definition. Under some variants of the ABI, an inline 42348 function can never be the key method. The default is to return 42349 'true'. 42350 42351 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 42352 DECL) 42353 DECL is a virtual table, virtual table table, typeinfo object, or 42354 other similar implicit class data object that will be emitted with 42355 external linkage in this translation unit. No ELF visibility has 42356 been explicitly specified. If the target needs to specify a 42357 visibility other than that of the containing class, use this hook 42358 to set 'DECL_VISIBILITY' and 'DECL_VISIBILITY_SPECIFIED'. 42359 42360 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 42361 This hook returns true (the default) if virtual tables and other 42362 similar implicit class data objects are always COMDAT if they have 42363 external linkage. If this hook returns false, then class data for 42364 classes whose virtual table will be emitted in only one translation 42365 unit will not be COMDAT. 42366 42367 -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void) 42368 This hook returns true (the default) if the RTTI information for 42369 the basic types which is defined in the C++ runtime should always 42370 be COMDAT, false if it should not be COMDAT. 42371 42372 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 42373 This hook returns true if '__aeabi_atexit' (as defined by the ARM 42374 EABI) should be used to register static destructors when 42375 '-fuse-cxa-atexit' is in effect. The default is to return false to 42376 use '__cxa_atexit'. 42377 42378 -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void) 42379 This hook returns true if the target 'atexit' function can be used 42380 in the same manner as '__cxa_atexit' to register C++ static 42381 destructors. This requires that 'atexit'-registered functions in 42382 shared libraries are run in the correct order when the libraries 42383 are unloaded. The default is to return false. 42384 42385 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 42386 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has just 42387 been defined. Use this hook to make adjustments to the class (eg, 42388 tweak visibility or perform any other required target 42389 modifications). 42390 42391 -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL) 42392 Return target-specific mangling context of DECL or 'NULL_TREE'. 42393 42394 42395File: gccint.info, Node: D Language and ABI, Next: Named Address Spaces, Prev: C++ ABI, Up: Target Macros 42396 4239718.29 D ABI parameters 42398====================== 42399 42400 -- D Target Hook: void TARGET_D_CPU_VERSIONS (void) 42401 Declare all environmental version identifiers relating to the 42402 target CPU using the function 'builtin_version', which takes a 42403 string representing the name of the version. Version identifiers 42404 predefined by this hook apply to all modules that are being 42405 compiled and imported. 42406 42407 -- D Target Hook: void TARGET_D_OS_VERSIONS (void) 42408 Similarly to 'TARGET_D_CPU_VERSIONS', but is used for versions 42409 relating to the target operating system. 42410 42411 -- D Target Hook: void TARGET_D_REGISTER_CPU_TARGET_INFO (void) 42412 Register all target information keys relating to the target CPU 42413 using the function 'd_add_target_info_handlers', which takes a 42414 'struct d_target_info_spec' (defined in 'd/d-target.h'). The keys 42415 added by this hook are made available at compile time by the 42416 '__traits(getTargetInfo)' extension, the result is an expression 42417 describing the requested target information. 42418 42419 -- D Target Hook: void TARGET_D_REGISTER_OS_TARGET_INFO (void) 42420 Same as 'TARGET_D_CPU_TARGET_INFO', but is used for keys relating 42421 to the target operating system. 42422 42423 -- D Target Hook: const char * TARGET_D_MINFO_SECTION 42424 Contains the name of the section in which module info references 42425 should be placed. This section is expected to be bracketed by two 42426 symbols to indicate the start and end address of the section, so 42427 that the runtime library can collect all modules for each loaded 42428 shared library and executable. The default value of 'NULL' 42429 disables the use of sections altogether. 42430 42431 -- D Target Hook: const char * TARGET_D_MINFO_START_NAME 42432 If 'TARGET_D_MINFO_SECTION' is defined, then this must also be 42433 defined as the name of the symbol indicating the start address of 42434 the module info section 42435 42436 -- D Target Hook: const char * TARGET_D_MINFO_END_NAME 42437 If 'TARGET_D_MINFO_SECTION' is defined, then this must also be 42438 defined as the name of the symbol indicating the end address of the 42439 module info section 42440 42441 -- D Target Hook: bool TARGET_D_HAS_STDCALL_CONVENTION (unsigned int 42442 *LINK_SYSTEM, unsigned int *LINK_WINDOWS) 42443 Returns 'true' if the target supports the stdcall calling 42444 convention. The hook should also set LINK_SYSTEM to '1' if the 42445 'stdcall' attribute should be applied to functions with 42446 'extern(System)' linkage, and LINK_WINDOWS to '1' to apply 42447 'stdcall' to functions with 'extern(Windows)' linkage. 42448 42449 -- D Target Hook: bool TARGET_D_TEMPLATES_ALWAYS_COMDAT 42450 This flag is true if instantiated functions and variables are 42451 always COMDAT if they have external linkage. If this flag is 42452 false, then instantiated decls will be emitted as weak symbols. 42453 The default is 'false'. 42454 42455 42456File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: D Language and ABI, Up: Target Macros 42457 4245818.30 Adding support for named address spaces 42459============================================= 42460 42461The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards 42462committee, 'Programming Languages - C - Extensions to support embedded 42463processors', specifies a syntax for embedded processors to specify 42464alternate address spaces. You can configure a GCC port to support 42465section 5.1 of the draft report to add support for address spaces other 42466than the default address space. These address spaces are new keywords 42467that are similar to the 'volatile' and 'const' type attributes. 42468 42469 Pointers to named address spaces can have a different size than 42470pointers to the generic address space. 42471 42472 For example, the SPU port uses the '__ea' address space to refer to 42473memory in the host processor, rather than memory local to the SPU 42474processor. Access to memory in the '__ea' address space involves 42475issuing DMA operations to move data between the host processor and the 42476local processor memory address space. Pointers in the '__ea' address 42477space are either 32 bits or 64 bits based on the '-mea32' or '-mea64' 42478switches (native SPU pointers are always 32 bits). 42479 42480 Internally, address spaces are represented as a small integer in the 42481range 0 to 15 with address space 0 being reserved for the generic 42482address space. 42483 42484 To register a named address space qualifier keyword with the C front 42485end, the target may call the 'c_register_addr_space' routine. For 42486example, the SPU port uses the following to declare '__ea' as the 42487keyword for named address space #1: 42488 #define ADDR_SPACE_EA 1 42489 c_register_addr_space ("__ea", ADDR_SPACE_EA); 42490 42491 -- Target Hook: scalar_int_mode TARGET_ADDR_SPACE_POINTER_MODE 42492 (addr_space_t ADDRESS_SPACE) 42493 Define this to return the machine mode to use for pointers to 42494 ADDRESS_SPACE if the target supports named address spaces. The 42495 default version of this hook returns 'ptr_mode'. 42496 42497 -- Target Hook: scalar_int_mode TARGET_ADDR_SPACE_ADDRESS_MODE 42498 (addr_space_t ADDRESS_SPACE) 42499 Define this to return the machine mode to use for addresses in 42500 ADDRESS_SPACE if the target supports named address spaces. The 42501 default version of this hook returns 'Pmode'. 42502 42503 -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE 42504 (scalar_int_mode MODE, addr_space_t AS) 42505 Define this to return nonzero if the port can handle pointers with 42506 machine mode MODE to address space AS. This target hook is the 42507 same as the 'TARGET_VALID_POINTER_MODE' target hook, except that it 42508 includes explicit named address space support. The default version 42509 of this hook returns true for the modes returned by either the 42510 'TARGET_ADDR_SPACE_POINTER_MODE' or 42511 'TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given address 42512 space. 42513 42514 -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P 42515 (machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS) 42516 Define this to return true if EXP is a valid address for mode MODE 42517 in the named address space AS. The STRICT parameter says whether 42518 strict addressing is in effect after reload has finished. This 42519 target hook is the same as the 'TARGET_LEGITIMATE_ADDRESS_P' target 42520 hook, except that it includes explicit named address space support. 42521 42522 -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx 42523 OLDX, machine_mode MODE, addr_space_t AS) 42524 Define this to modify an invalid address X to be a valid address 42525 with mode MODE in the named address space AS. This target hook is 42526 the same as the 'TARGET_LEGITIMIZE_ADDRESS' target hook, except 42527 that it includes explicit named address space support. 42528 42529 -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET, 42530 addr_space_t SUPERSET) 42531 Define this to return whether the SUBSET named address space is 42532 contained within the SUPERSET named address space. Pointers to a 42533 named address space that is a subset of another named address space 42534 will be converted automatically without a cast if used together in 42535 arithmetic operations. Pointers to a superset address space can be 42536 converted to pointers to a subset address space via explicit casts. 42537 42538 -- Target Hook: bool TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID (addr_space_t 42539 AS) 42540 Define this to modify the default handling of address 0 for the 42541 address space. Return true if 0 should be considered a valid 42542 address. 42543 42544 -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE, 42545 tree TO_TYPE) 42546 Define this to convert the pointer expression represented by the 42547 RTL OP with type FROM_TYPE that points to a named address space to 42548 a new pointer expression with type TO_TYPE that points to a 42549 different named address space. When this hook it called, it is 42550 guaranteed that one of the two address spaces is a subset of the 42551 other, as determined by the 'TARGET_ADDR_SPACE_SUBSET_P' target 42552 hook. 42553 42554 -- Target Hook: int TARGET_ADDR_SPACE_DEBUG (addr_space_t AS) 42555 Define this to define how the address space is encoded in dwarf. 42556 The result is the value to be used with 'DW_AT_address_class'. 42557 42558 -- Target Hook: void TARGET_ADDR_SPACE_DIAGNOSE_USAGE (addr_space_t AS, 42559 location_t LOC) 42560 Define this hook if the availability of an address space depends on 42561 command line options and some diagnostics should be printed when 42562 the address space is used. This hook is called during parsing and 42563 allows to emit a better diagnostic compared to the case where the 42564 address space was not registered with 'c_register_addr_space'. AS 42565 is the address space as registered with 'c_register_addr_space'. 42566 LOC is the location of the address space qualifier token. The 42567 default implementation does nothing. 42568 42569 42570File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros 42571 4257218.31 Miscellaneous Parameters 42573============================== 42574 42575Here are several miscellaneous parameters. 42576 42577 -- Macro: HAS_LONG_COND_BRANCH 42578 Define this boolean macro to indicate whether or not your 42579 architecture has conditional branches that can span all of memory. 42580 It is used in conjunction with an optimization that partitions hot 42581 and cold basic blocks into separate sections of the executable. If 42582 this macro is set to false, gcc will convert any conditional 42583 branches that attempt to cross between sections into unconditional 42584 branches or indirect jumps. 42585 42586 -- Macro: HAS_LONG_UNCOND_BRANCH 42587 Define this boolean macro to indicate whether or not your 42588 architecture has unconditional branches that can span all of 42589 memory. It is used in conjunction with an optimization that 42590 partitions hot and cold basic blocks into separate sections of the 42591 executable. If this macro is set to false, gcc will convert any 42592 unconditional branches that attempt to cross between sections into 42593 indirect jumps. 42594 42595 -- Macro: CASE_VECTOR_MODE 42596 An alias for a machine mode name. This is the machine mode that 42597 elements of a jump-table should have. 42598 42599 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 42600 Optional: return the preferred mode for an 'addr_diff_vec' when the 42601 minimum and maximum offset are known. If you define this, it 42602 enables extra code in branch shortening to deal with 42603 'addr_diff_vec'. To make this work, you also have to define 42604 'INSN_ALIGN' and make the alignment for 'addr_diff_vec' explicit. 42605 The BODY argument is provided so that the offset_unsigned and scale 42606 flags can be updated. 42607 42608 -- Macro: CASE_VECTOR_PC_RELATIVE 42609 Define this macro to be a C expression to indicate when jump-tables 42610 should contain relative addresses. You need not define this macro 42611 if jump-tables never contain relative addresses, or jump-tables 42612 should contain relative addresses only when '-fPIC' or '-fPIC' is 42613 in effect. 42614 42615 -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void) 42616 This function return the smallest number of different values for 42617 which it is best to use a jump-table instead of a tree of 42618 conditional branches. The default is four for machines with a 42619 'casesi' instruction and five otherwise. This is best for most 42620 machines. 42621 42622 -- Macro: WORD_REGISTER_OPERATIONS 42623 Define this macro to 1 if operations between registers with 42624 integral mode smaller than a word are always performed on the 42625 entire register. To be more explicit, if you start with a pair of 42626 'word_mode' registers with known values and you do a subword, for 42627 example 'QImode', addition on the low part of the registers, then 42628 the compiler may consider that the result has a known value in 42629 'word_mode' too if the macro is defined to 1. Most RISC machines 42630 have this property and most CISC machines do not. 42631 42632 -- Target Hook: unsigned int TARGET_MIN_ARITHMETIC_PRECISION (void) 42633 On some RISC architectures with 64-bit registers, the processor 42634 also maintains 32-bit condition codes that make it possible to do 42635 real 32-bit arithmetic, although the operations are performed on 42636 the full registers. 42637 42638 On such architectures, defining this hook to 32 tells the compiler 42639 to try using 32-bit arithmetical operations setting the condition 42640 codes instead of doing full 64-bit arithmetic. 42641 42642 More generally, define this hook on RISC architectures if you want 42643 the compiler to try using arithmetical operations setting the 42644 condition codes with a precision lower than the word precision. 42645 42646 You need not define this hook if 'WORD_REGISTER_OPERATIONS' is not 42647 defined to 1. 42648 42649 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 42650 Define this macro to be a C expression indicating when insns that 42651 read memory in MEM_MODE, an integral mode narrower than a word, set 42652 the bits outside of MEM_MODE to be either the sign-extension or the 42653 zero-extension of the data read. Return 'SIGN_EXTEND' for values 42654 of MEM_MODE for which the insn sign-extends, 'ZERO_EXTEND' for 42655 which it zero-extends, and 'UNKNOWN' for other modes. 42656 42657 This macro is not called with MEM_MODE non-integral or with a width 42658 greater than or equal to 'BITS_PER_WORD', so you may return any 42659 value in this case. Do not define this macro if it would always 42660 return 'UNKNOWN'. On machines where this macro is defined, you 42661 will normally define it as the constant 'SIGN_EXTEND' or 42662 'ZERO_EXTEND'. 42663 42664 You may return a non-'UNKNOWN' value even if for some hard 42665 registers the sign extension is not performed, if for the 42666 'REGNO_REG_CLASS' of these hard registers 42667 'TARGET_CAN_CHANGE_MODE_CLASS' returns false when the FROM mode is 42668 MEM_MODE and the TO mode is any integral mode larger than this but 42669 not larger than 'word_mode'. 42670 42671 You must return 'UNKNOWN' if for some hard registers that allow 42672 this mode, 'TARGET_CAN_CHANGE_MODE_CLASS' says that they cannot 42673 change to 'word_mode', but that they can change to another integral 42674 mode that is larger then MEM_MODE but still smaller than 42675 'word_mode'. 42676 42677 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 42678 Define this macro to 1 if loading short immediate values into 42679 registers sign extends. 42680 42681 -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL 42682 (machine_mode MODE) 42683 When '-ffast-math' is in effect, GCC tries to optimize divisions by 42684 the same divisor, by turning them into multiplications by the 42685 reciprocal. This target hook specifies the minimum number of 42686 divisions that should be there for GCC to perform the optimization 42687 for a variable of mode MODE. The default implementation returns 3 42688 if the machine has an instruction for the division, and 2 if it 42689 does not. 42690 42691 -- Macro: MOVE_MAX 42692 The maximum number of bytes that a single instruction can move 42693 quickly between memory and registers or between two memory 42694 locations. 42695 42696 -- Macro: MAX_MOVE_MAX 42697 The maximum number of bytes that a single instruction can move 42698 quickly between memory and registers or between two memory 42699 locations. If this is undefined, the default is 'MOVE_MAX'. 42700 Otherwise, it is the constant value that is the largest value that 42701 'MOVE_MAX' can have at run-time. 42702 42703 -- Macro: SHIFT_COUNT_TRUNCATED 42704 A C expression that is nonzero if on this machine the number of 42705 bits actually used for the count of a shift operation is equal to 42706 the number of bits needed to represent the size of the object being 42707 shifted. When this macro is nonzero, the compiler will assume that 42708 it is safe to omit a sign-extend, zero-extend, and certain bitwise 42709 'and' instructions that truncates the count of a shift operation. 42710 On machines that have instructions that act on bit-fields at 42711 variable positions, which may include 'bit test' instructions, a 42712 nonzero 'SHIFT_COUNT_TRUNCATED' also enables deletion of 42713 truncations of the values that serve as arguments to bit-field 42714 instructions. 42715 42716 If both types of instructions truncate the count (for shifts) and 42717 position (for bit-field operations), or if no variable-position 42718 bit-field instructions exist, you should define this macro. 42719 42720 However, on some machines, such as the 80386 and the 680x0, 42721 truncation only applies to shift operations and not the (real or 42722 pretended) bit-field operations. Define 'SHIFT_COUNT_TRUNCATED' to 42723 be zero on such machines. Instead, add patterns to the 'md' file 42724 that include the implied truncation of the shift instructions. 42725 42726 You need not define this macro if it would always have the value of 42727 zero. 42728 42729 -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK 42730 (machine_mode MODE) 42731 This function describes how the standard shift patterns for MODE 42732 deal with shifts by negative amounts or by more than the width of 42733 the mode. *Note shift patterns::. 42734 42735 On many machines, the shift patterns will apply a mask M to the 42736 shift count, meaning that a fixed-width shift of X by Y is 42737 equivalent to an arbitrary-width shift of X by Y & M. If this is 42738 true for mode MODE, the function should return M, otherwise it 42739 should return 0. A return value of 0 indicates that no particular 42740 behavior is guaranteed. 42741 42742 Note that, unlike 'SHIFT_COUNT_TRUNCATED', this function does _not_ 42743 apply to general shift rtxes; it applies only to instructions that 42744 are generated by the named shift patterns. 42745 42746 The default implementation of this function returns 42747 'GET_MODE_BITSIZE (MODE) - 1' if 'SHIFT_COUNT_TRUNCATED' and 0 42748 otherwise. This definition is always safe, but if 42749 'SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 42750 nevertheless truncate the shift count, you may get better code by 42751 overriding it. 42752 42753 -- Target Hook: bool TARGET_TRULY_NOOP_TRUNCATION (poly_uint64 OUTPREC, 42754 poly_uint64 INPREC) 42755 This hook returns true if it is safe to "convert" a value of INPREC 42756 bits to one of OUTPREC bits (where OUTPREC is smaller than INPREC) 42757 by merely operating on it as if it had only OUTPREC bits. The 42758 default returns true unconditionally, which is correct for most 42759 machines. When 'TARGET_TRULY_NOOP_TRUNCATION' returns false, the 42760 machine description should provide a 'trunc' optab to specify the 42761 RTL that performs the required truncation. 42762 42763 If 'TARGET_MODES_TIEABLE_P' returns false for a pair of modes, 42764 suboptimal code can result if this hook returns true for the 42765 corresponding mode sizes. Making this hook return false in such 42766 cases may improve things. 42767 42768 -- Target Hook: int TARGET_MODE_REP_EXTENDED (scalar_int_mode MODE, 42769 scalar_int_mode REP_MODE) 42770 The representation of an integral mode can be such that the values 42771 are always extended to a wider integral mode. Return 'SIGN_EXTEND' 42772 if values of MODE are represented in sign-extended form to 42773 REP_MODE. Return 'UNKNOWN' otherwise. (Currently, none of the 42774 targets use zero-extended representation this way so unlike 42775 'LOAD_EXTEND_OP', 'TARGET_MODE_REP_EXTENDED' is expected to return 42776 either 'SIGN_EXTEND' or 'UNKNOWN'. Also no target extends MODE to 42777 REP_MODE so that REP_MODE is not the next widest integral mode and 42778 currently we take advantage of this fact.) 42779 42780 Similarly to 'LOAD_EXTEND_OP' you may return a non-'UNKNOWN' value 42781 even if the extension is not performed on certain hard registers as 42782 long as for the 'REGNO_REG_CLASS' of these hard registers 42783 'TARGET_CAN_CHANGE_MODE_CLASS' returns false. 42784 42785 Note that 'TARGET_MODE_REP_EXTENDED' and 'LOAD_EXTEND_OP' describe 42786 two related properties. If you define 'TARGET_MODE_REP_EXTENDED 42787 (mode, word_mode)' you probably also want to define 'LOAD_EXTEND_OP 42788 (mode)' to return the same type of extension. 42789 42790 In order to enforce the representation of 'mode', 42791 'TARGET_TRULY_NOOP_TRUNCATION' should return false when truncating 42792 to 'mode'. 42793 42794 -- Target Hook: bool TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P (void) 42795 On some targets, it is assumed that the compiler will spill all 42796 pseudos that are live across a call to 'setjmp', while other 42797 targets treat 'setjmp' calls as normal function calls. 42798 42799 This hook returns false if 'setjmp' calls do not preserve all 42800 non-volatile registers so that gcc that must spill all pseudos that 42801 are live across 'setjmp' calls. Define this to return true if the 42802 target does not need to spill all pseudos live across 'setjmp' 42803 calls. The default implementation conservatively assumes all 42804 pseudos must be spilled across 'setjmp' calls. 42805 42806 -- Macro: STORE_FLAG_VALUE 42807 A C expression describing the value returned by a comparison 42808 operator with an integral mode and stored by a store-flag 42809 instruction ('cstoreMODE4') when the condition is true. This 42810 description must apply to _all_ the 'cstoreMODE4' patterns and all 42811 the comparison operators whose results have a 'MODE_INT' mode. 42812 42813 A value of 1 or -1 means that the instruction implementing the 42814 comparison operator returns exactly 1 or -1 when the comparison is 42815 true and 0 when the comparison is false. Otherwise, the value 42816 indicates which bits of the result are guaranteed to be 1 when the 42817 comparison is true. This value is interpreted in the mode of the 42818 comparison operation, which is given by the mode of the first 42819 operand in the 'cstoreMODE4' pattern. Either the low bit or the 42820 sign bit of 'STORE_FLAG_VALUE' be on. Presently, only those bits 42821 are used by the compiler. 42822 42823 If 'STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 42824 generate code that depends only on the specified bits. It can also 42825 replace comparison operators with equivalent operations if they 42826 cause the required bits to be set, even if the remaining bits are 42827 undefined. For example, on a machine whose comparison operators 42828 return an 'SImode' value and where 'STORE_FLAG_VALUE' is defined as 42829 '0x80000000', saying that just the sign bit is relevant, the 42830 expression 42831 42832 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 42833 42834 can be converted to 42835 42836 (ashift:SI X (const_int N)) 42837 42838 where N is the appropriate shift count to move the bit being tested 42839 into the sign bit. 42840 42841 There is no way to describe a machine that always sets the 42842 low-order bit for a true value, but does not guarantee the value of 42843 any other bits, but we do not know of any machine that has such an 42844 instruction. If you are trying to port GCC to such a machine, 42845 include an instruction to perform a logical-and of the result with 42846 1 in the pattern for the comparison operators and let us know at 42847 <gcc@gcc.gnu.org>. 42848 42849 Often, a machine will have multiple instructions that obtain a 42850 value from a comparison (or the condition codes). Here are rules 42851 to guide the choice of value for 'STORE_FLAG_VALUE', and hence the 42852 instructions to be used: 42853 42854 * Use the shortest sequence that yields a valid definition for 42855 'STORE_FLAG_VALUE'. It is more efficient for the compiler to 42856 "normalize" the value (convert it to, e.g., 1 or 0) than for 42857 the comparison operators to do so because there may be 42858 opportunities to combine the normalization with other 42859 operations. 42860 42861 * For equal-length sequences, use a value of 1 or -1, with -1 42862 being slightly preferred on machines with expensive jumps and 42863 1 preferred on other machines. 42864 42865 * As a second choice, choose a value of '0x80000001' if 42866 instructions exist that set both the sign and low-order bits 42867 but do not define the others. 42868 42869 * Otherwise, use a value of '0x80000000'. 42870 42871 Many machines can produce both the value chosen for 42872 'STORE_FLAG_VALUE' and its negation in the same number of 42873 instructions. On those machines, you should also define a pattern 42874 for those cases, e.g., one matching 42875 42876 (set A (neg:M (ne:M B C))) 42877 42878 Some machines can also perform 'and' or 'plus' operations on 42879 condition code values with less instructions than the corresponding 42880 'cstoreMODE4' insn followed by 'and' or 'plus'. On those machines, 42881 define the appropriate patterns. Use the names 'incscc' and 42882 'decscc', respectively, for the patterns which perform 'plus' or 42883 'minus' operations on condition code values. See 'rs6000.md' for 42884 some examples. The GNU Superoptimizer can be used to find such 42885 instruction sequences on other machines. 42886 42887 If this macro is not defined, the default value, 1, is used. You 42888 need not define 'STORE_FLAG_VALUE' if the machine has no store-flag 42889 instructions, or if the value generated by these instructions is 1. 42890 42891 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 42892 A C expression that gives a nonzero 'REAL_VALUE_TYPE' value that is 42893 returned when comparison operators with floating-point results are 42894 true. Define this macro on machines that have comparison 42895 operations that return floating-point values. If there are no such 42896 operations, do not define this macro. 42897 42898 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 42899 A C expression that gives an rtx representing the nonzero true 42900 element for vector comparisons. The returned rtx should be valid 42901 for the inner mode of MODE which is guaranteed to be a vector mode. 42902 Define this macro on machines that have vector comparison 42903 operations that return a vector result. If there are no such 42904 operations, do not define this macro. Typically, this macro is 42905 defined as 'const1_rtx' or 'constm1_rtx'. This macro may return 42906 'NULL_RTX' to prevent the compiler optimizing such vector 42907 comparison operations for the given mode. 42908 42909 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 42910 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 42911 A C expression that indicates whether the architecture defines a 42912 value for 'clz' or 'ctz' with a zero operand. A result of '0' 42913 indicates the value is undefined. If the value is defined for only 42914 the RTL expression, the macro should evaluate to '1'; if the value 42915 applies also to the corresponding optab entry (which is normally 42916 the case if it expands directly into the corresponding RTL), then 42917 the macro should evaluate to '2'. In the cases where the value is 42918 defined, VALUE should be set to this value. 42919 42920 If this macro is not defined, the value of 'clz' or 'ctz' at zero 42921 is assumed to be undefined. 42922 42923 This macro must be defined if the target's expansion for 'ffs' 42924 relies on a particular value to get correct results. Otherwise it 42925 is not necessary, though it may be used to optimize some corner 42926 cases, and to provide a default expansion for the 'ffs' optab. 42927 42928 Note that regardless of this macro the "definedness" of 'clz' and 42929 'ctz' at zero do _not_ extend to the builtin functions visible to 42930 the user. Thus one may be free to adjust the value at will to 42931 match the target expansion of these operations without fear of 42932 breaking the API. 42933 42934 -- Macro: Pmode 42935 An alias for the machine mode for pointers. On most machines, 42936 define this to be the integer mode corresponding to the width of a 42937 hardware pointer; 'SImode' on 32-bit machine or 'DImode' on 64-bit 42938 machines. On some machines you must define this to be one of the 42939 partial integer modes, such as 'PSImode'. 42940 42941 The width of 'Pmode' must be at least as large as the value of 42942 'POINTER_SIZE'. If it is not equal, you must define the macro 42943 'POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 42944 'Pmode'. 42945 42946 -- Macro: FUNCTION_MODE 42947 An alias for the machine mode used for memory references to 42948 functions being called, in 'call' RTL expressions. On most CISC 42949 machines, where an instruction can begin at any byte address, this 42950 should be 'QImode'. On most RISC machines, where all instructions 42951 have fixed size and alignment, this should be a mode with the same 42952 size and alignment as the machine instruction words - typically 42953 'SImode' or 'HImode'. 42954 42955 -- Macro: STDC_0_IN_SYSTEM_HEADERS 42956 In normal operation, the preprocessor expands '__STDC__' to the 42957 constant 1, to signify that GCC conforms to ISO Standard C. On 42958 some hosts, like Solaris, the system compiler uses a different 42959 convention, where '__STDC__' is normally 0, but is 1 if the user 42960 specifies strict conformance to the C Standard. 42961 42962 Defining 'STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 42963 convention when processing system header files, but when processing 42964 user files '__STDC__' will always expand to 1. 42965 42966 -- C Target Hook: const char * TARGET_C_PREINCLUDE (void) 42967 Define this hook to return the name of a header file to be included 42968 at the start of all compilations, as if it had been included with 42969 '#include <FILE>'. If this hook returns 'NULL', or is not defined, 42970 or the header is not found, or if the user specifies 42971 '-ffreestanding' or '-nostdinc', no header is included. 42972 42973 This hook can be used together with a header provided by the system 42974 C library to implement ISO C requirements for certain macros to be 42975 predefined that describe properties of the whole implementation 42976 rather than just the compiler. 42977 42978 -- C Target Hook: bool TARGET_CXX_IMPLICIT_EXTERN_C (const char*) 42979 Define this hook to add target-specific C++ implicit extern C 42980 functions. If this function returns true for the name of a 42981 file-scope function, that function implicitly gets extern "C" 42982 linkage rather than whatever language linkage the declaration would 42983 normally have. An example of such function is WinMain on Win32 42984 targets. 42985 42986 -- Macro: SYSTEM_IMPLICIT_EXTERN_C 42987 Define this macro if the system header files do not support C++. 42988 This macro handles system header files by pretending that system 42989 header files are enclosed in 'extern "C" {...}'. 42990 42991 -- Macro: REGISTER_TARGET_PRAGMAS () 42992 Define this macro if you want to implement any target-specific 42993 pragmas. If defined, it is a C expression which makes a series of 42994 calls to 'c_register_pragma' or 'c_register_pragma_with_expansion' 42995 for each pragma. The macro may also do any setup required for the 42996 pragmas. 42997 42998 The primary reason to define this macro is to provide compatibility 42999 with other compilers for the same target. In general, we 43000 discourage definition of target-specific pragmas for GCC. 43001 43002 If the pragma can be implemented by attributes then you should 43003 consider defining the target hook 'TARGET_INSERT_ATTRIBUTES' as 43004 well. 43005 43006 Preprocessor macros that appear on pragma lines are not expanded. 43007 All '#pragma' directives that do not match any registered pragma 43008 are silently ignored, unless the user specifies 43009 '-Wunknown-pragmas'. 43010 43011 -- Function: void c_register_pragma (const char *SPACE, const char 43012 *NAME, void (*CALLBACK) (struct cpp_reader *)) 43013 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 43014 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 43015 43016 Each call to 'c_register_pragma' or 43017 'c_register_pragma_with_expansion' establishes one pragma. The 43018 CALLBACK routine will be called when the preprocessor encounters a 43019 pragma of the form 43020 43021 #pragma [SPACE] NAME ... 43022 43023 SPACE is the case-sensitive namespace of the pragma, or 'NULL' to 43024 put the pragma in the global namespace. The callback routine 43025 receives PFILE as its first argument, which can be passed on to 43026 cpplib's functions if necessary. You can lex tokens after the NAME 43027 by calling 'pragma_lex'. Tokens that are not read by the callback 43028 will be silently ignored. The end of the line is indicated by a 43029 token of type 'CPP_EOF'. Macro expansion occurs on the arguments 43030 of pragmas registered with 'c_register_pragma_with_expansion' but 43031 not on the arguments of pragmas registered with 43032 'c_register_pragma'. 43033 43034 Note that the use of 'pragma_lex' is specific to the C and C++ 43035 compilers. It will not work in the Java or Fortran compilers, or 43036 any other language compilers for that matter. Thus if 'pragma_lex' 43037 is going to be called from target-specific code, it must only be 43038 done so when building the C and C++ compilers. This can be done by 43039 defining the variables 'c_target_objs' and 'cxx_target_objs' in the 43040 target entry in the 'config.gcc' file. These variables should name 43041 the target-specific, language-specific object file which contains 43042 the code that uses 'pragma_lex'. Note it will also be necessary to 43043 add a rule to the makefile fragment pointed to by 'tmake_file' that 43044 shows how to build this object file. 43045 43046 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 43047 Define this macro if macros should be expanded in the arguments of 43048 '#pragma pack'. 43049 43050 -- Macro: TARGET_DEFAULT_PACK_STRUCT 43051 If your target requires a structure packing default other than 0 43052 (meaning the machine default), define this macro to the necessary 43053 value (in bytes). This must be a value that would also be valid to 43054 use with '#pragma pack()' (that is, a small power of two). 43055 43056 -- Macro: DOLLARS_IN_IDENTIFIERS 43057 Define this macro to control use of the character '$' in identifier 43058 names for the C family of languages. 0 means '$' is not allowed by 43059 default; 1 means it is allowed. 1 is the default; there is no need 43060 to define this macro in that case. 43061 43062 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 43063 Define this macro as a C expression that is nonzero if it is safe 43064 for the delay slot scheduler to place instructions in the delay 43065 slot of INSN, even if they appear to use a resource set or 43066 clobbered in INSN. INSN is always a 'jump_insn' or an 'insn'; GCC 43067 knows that every 'call_insn' has this behavior. On machines where 43068 some 'insn' or 'jump_insn' is really a function call and hence has 43069 this behavior, you should define this macro. 43070 43071 You need not define this macro if it would always return zero. 43072 43073 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 43074 Define this macro as a C expression that is nonzero if it is safe 43075 for the delay slot scheduler to place instructions in the delay 43076 slot of INSN, even if they appear to set or clobber a resource 43077 referenced in INSN. INSN is always a 'jump_insn' or an 'insn'. On 43078 machines where some 'insn' or 'jump_insn' is really a function call 43079 and its operands are registers whose use is actually in the 43080 subroutine it calls, you should define this macro. Doing so allows 43081 the delay slot scheduler to move instructions which copy arguments 43082 into the argument registers into the delay slot of INSN. 43083 43084 You need not define this macro if it would always return zero. 43085 43086 -- Macro: MULTIPLE_SYMBOL_SPACES 43087 Define this macro as a C expression that is nonzero if, in some 43088 cases, global symbols from one translation unit may not be bound to 43089 undefined symbols in another translation unit without user 43090 intervention. For instance, under Microsoft Windows symbols must 43091 be explicitly imported from shared libraries (DLLs). 43092 43093 You need not define this macro if it would always evaluate to zero. 43094 43095 -- Target Hook: rtx_insn * TARGET_MD_ASM_ADJUST (vec<rtx>& OUTPUTS, 43096 vec<rtx>& INPUTS, vec<machine_mode>& INPUT_MODES, vec<const 43097 char *>& CONSTRAINTS, vec<rtx>& CLOBBERS, HARD_REG_SET& 43098 CLOBBERED_REGS) 43099 This target hook may add "clobbers" to CLOBBERS and CLOBBERED_REGS 43100 for any hard regs the port wishes to automatically clobber for an 43101 asm. The OUTPUTS and INPUTS may be inspected to avoid clobbering a 43102 register that is already used by the asm. 43103 43104 It may modify the OUTPUTS, INPUTS, INPUT_MODES, and CONSTRAINTS as 43105 necessary for other pre-processing. In this case the return value 43106 is a sequence of insns to emit after the asm. Note that changes to 43107 INPUTS must be accompanied by the corresponding changes to 43108 INPUT_MODES. 43109 43110 -- Macro: MATH_LIBRARY 43111 Define this macro as a C string constant for the linker argument to 43112 link in the system math library, minus the initial '"-l"', or '""' 43113 if the target does not have a separate math library. 43114 43115 You need only define this macro if the default of '"m"' is wrong. 43116 43117 -- Macro: LIBRARY_PATH_ENV 43118 Define this macro as a C string constant for the environment 43119 variable that specifies where the linker should look for libraries. 43120 43121 You need only define this macro if the default of '"LIBRARY_PATH"' 43122 is wrong. 43123 43124 -- Macro: TARGET_POSIX_IO 43125 Define this macro if the target supports the following POSIX file 43126 functions, access, mkdir and file locking with fcntl / F_SETLKW. 43127 Defining 'TARGET_POSIX_IO' will enable the test coverage code to 43128 use file locking when exiting a program, which avoids race 43129 conditions if the program has forked. It will also create 43130 directories at run-time for cross-profiling. 43131 43132 -- Macro: MAX_CONDITIONAL_EXECUTE 43133 43134 A C expression for the maximum number of instructions to execute 43135 via conditional execution instructions instead of a branch. A 43136 value of 'BRANCH_COST'+1 is the default if the machine does not use 43137 cc0, and 1 if it does use cc0. 43138 43139 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 43140 Used if the target needs to perform machine-dependent modifications 43141 on the conditionals used for turning basic blocks into 43142 conditionally executed code. CE_INFO points to a data structure, 43143 'struct ce_if_block', which contains information about the 43144 currently processed blocks. TRUE_EXPR and FALSE_EXPR are the tests 43145 that are used for converting the then-block and the else-block, 43146 respectively. Set either TRUE_EXPR or FALSE_EXPR to a null pointer 43147 if the tests cannot be converted. 43148 43149 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 43150 FALSE_EXPR) 43151 Like 'IFCVT_MODIFY_TESTS', but used when converting more 43152 complicated if-statements into conditions combined by 'and' and 43153 'or' operations. BB contains the basic block that contains the 43154 test that is currently being processed and about to be turned into 43155 a condition. 43156 43157 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 43158 A C expression to modify the PATTERN of an INSN that is to be 43159 converted to conditional execution format. CE_INFO points to a 43160 data structure, 'struct ce_if_block', which contains information 43161 about the currently processed blocks. 43162 43163 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 43164 A C expression to perform any final machine dependent modifications 43165 in converting code to conditional execution. The involved basic 43166 blocks can be found in the 'struct ce_if_block' structure that is 43167 pointed to by CE_INFO. 43168 43169 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 43170 A C expression to cancel any machine dependent modifications in 43171 converting code to conditional execution. The involved basic 43172 blocks can be found in the 'struct ce_if_block' structure that is 43173 pointed to by CE_INFO. 43174 43175 -- Macro: IFCVT_MACHDEP_INIT (CE_INFO) 43176 A C expression to initialize any machine specific data for 43177 if-conversion of the if-block in the 'struct ce_if_block' structure 43178 that is pointed to by CE_INFO. 43179 43180 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void) 43181 If non-null, this hook performs a target-specific pass over the 43182 instruction stream. The compiler will run it at all optimization 43183 levels, just before the point at which it normally does 43184 delayed-branch scheduling. 43185 43186 The exact purpose of the hook varies from target to target. Some 43187 use it to do transformations that are necessary for correctness, 43188 such as laying out in-function constant pools or avoiding hardware 43189 hazards. Others use it as an opportunity to do some 43190 machine-dependent optimizations. 43191 43192 You need not implement the hook if it has nothing to do. The 43193 default definition is null. 43194 43195 -- Target Hook: void TARGET_INIT_BUILTINS (void) 43196 Define this hook if you have any machine-specific built-in 43197 functions that need to be defined. It should be a function that 43198 performs the necessary setup. 43199 43200 Machine specific built-in functions can be useful to expand special 43201 machine instructions that would otherwise not normally be generated 43202 because they have no equivalent in the source language (for 43203 example, SIMD vector instructions or prefetch instructions). 43204 43205 To create a built-in function, call the function 43206 'lang_hooks.builtin_function' which is defined by the language 43207 front end. You can use any type nodes set up by 43208 'build_common_tree_nodes'; only language front ends that use those 43209 two functions will call 'TARGET_INIT_BUILTINS'. 43210 43211 -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool 43212 INITIALIZE_P) 43213 Define this hook if you have any machine-specific built-in 43214 functions that need to be defined. It should be a function that 43215 returns the builtin function declaration for the builtin function 43216 code CODE. If there is no such builtin and it cannot be 43217 initialized at this time if INITIALIZE_P is true the function 43218 should return 'NULL_TREE'. If CODE is out of range the function 43219 should return 'error_mark_node'. 43220 43221 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 43222 SUBTARGET, machine_mode MODE, int IGNORE) 43223 43224 Expand a call to a machine specific built-in function that was set 43225 up by 'TARGET_INIT_BUILTINS'. EXP is the expression for the 43226 function call; the result should go to TARGET if that is 43227 convenient, and have mode MODE if that is convenient. SUBTARGET 43228 may be used as the target for computing one of EXP's operands. 43229 IGNORE is nonzero if the value is to be ignored. This function 43230 should return the result of the call to the built-in function. 43231 43232 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int 43233 LOC, tree FNDECL, void *ARGLIST) 43234 Select a replacement for a machine specific built-in function that 43235 was set up by 'TARGET_INIT_BUILTINS'. This is done _before_ 43236 regular type checking, and so allows the target to implement a 43237 crude form of function overloading. FNDECL is the declaration of 43238 the built-in function. ARGLIST is the list of arguments passed to 43239 the built-in function. The result is a complete expression that 43240 implements the operation, usually another 'CALL_EXPR'. ARGLIST 43241 really has type 'VEC(tree,gc)*' 43242 43243 -- Target Hook: bool TARGET_CHECK_BUILTIN_CALL (location_t LOC, 43244 vec<location_t> ARG_LOC, tree FNDECL, tree ORIG_FNDECL, 43245 unsigned int NARGS, tree *ARGS) 43246 Perform semantic checking on a call to a machine-specific built-in 43247 function after its arguments have been constrained to the function 43248 signature. Return true if the call is valid, otherwise report an 43249 error and return false. 43250 43251 This hook is called after 'TARGET_RESOLVE_OVERLOADED_BUILTIN'. The 43252 call was originally to built-in function ORIG_FNDECL, but after the 43253 optional 'TARGET_RESOLVE_OVERLOADED_BUILTIN' step is now to 43254 built-in function FNDECL. LOC is the location of the call and ARGS 43255 is an array of function arguments, of which there are NARGS. 43256 ARG_LOC specifies the location of each argument. 43257 43258 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, tree 43259 *ARGP, bool IGNORE) 43260 Fold a call to a machine specific built-in function that was set up 43261 by 'TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 43262 built-in function. N_ARGS is the number of arguments passed to the 43263 function; the arguments themselves are pointed to by ARGP. The 43264 result is another tree, valid for both GIMPLE and GENERIC, 43265 containing a simplified expression for the call's result. If 43266 IGNORE is true the value will be ignored. 43267 43268 -- Target Hook: bool TARGET_GIMPLE_FOLD_BUILTIN (gimple_stmt_iterator 43269 *GSI) 43270 Fold a call to a machine specific built-in function that was set up 43271 by 'TARGET_INIT_BUILTINS'. GSI points to the gimple statement 43272 holding the function call. Returns true if any change was made to 43273 the GIMPLE stream. 43274 43275 -- Target Hook: int TARGET_COMPARE_VERSION_PRIORITY (tree DECL1, tree 43276 DECL2) 43277 This hook is used to compare the target attributes in two functions 43278 to determine which function's features get higher priority. This 43279 is used during function multi-versioning to figure out the order in 43280 which two versions must be dispatched. A function version with a 43281 higher priority is checked for dispatching earlier. DECL1 and 43282 DECL2 are the two function decls that will be compared. 43283 43284 -- Target Hook: tree TARGET_GET_FUNCTION_VERSIONS_DISPATCHER (void 43285 *DECL) 43286 This hook is used to get the dispatcher function for a set of 43287 function versions. The dispatcher function is called to invoke the 43288 right function version at run-time. DECL is one version from a set 43289 of semantically identical versions. 43290 43291 -- Target Hook: tree TARGET_GENERATE_VERSION_DISPATCHER_BODY (void 43292 *ARG) 43293 This hook is used to generate the dispatcher logic to invoke the 43294 right function version at run-time for a given set of function 43295 versions. ARG points to the callgraph node of the dispatcher 43296 function whose body must be generated. 43297 43298 -- Target Hook: bool TARGET_PREDICT_DOLOOP_P (class loop *LOOP) 43299 Return true if we can predict it is possible to use a low-overhead 43300 loop for a particular loop. The parameter LOOP is a pointer to the 43301 loop. This target hook is required only when the target supports 43302 low-overhead loops, and will help ivopts to make some decisions. 43303 The default version of this hook returns false. 43304 43305 -- Target Hook: bool TARGET_HAVE_COUNT_REG_DECR_P 43306 Return true if the target supports hardware count register for 43307 decrement and branch. The default value is false. 43308 43309 -- Target Hook: int64_t TARGET_DOLOOP_COST_FOR_GENERIC 43310 One IV candidate dedicated for doloop is introduced in IVOPTs, we 43311 can calculate the computation cost of adopting it to any generic IV 43312 use by function get_computation_cost as before. But for targets 43313 which have hardware count register support for decrement and 43314 branch, it may have to move IV value from hardware count register 43315 to general purpose register while doloop IV candidate is used for 43316 generic IV uses. It probably takes expensive penalty. This hook 43317 allows target owners to define the cost for this especially for 43318 generic IV uses. The default value is zero. 43319 43320 -- Target Hook: int64_t TARGET_DOLOOP_COST_FOR_ADDRESS 43321 One IV candidate dedicated for doloop is introduced in IVOPTs, we 43322 can calculate the computation cost of adopting it to any address IV 43323 use by function get_computation_cost as before. But for targets 43324 which have hardware count register support for decrement and 43325 branch, it may have to move IV value from hardware count register 43326 to general purpose register while doloop IV candidate is used for 43327 address IV uses. It probably takes expensive penalty. This hook 43328 allows target owners to define the cost for this escpecially for 43329 address IV uses. The default value is zero. 43330 43331 -- Target Hook: bool TARGET_CAN_USE_DOLOOP_P (const widest_int 43332 &ITERATIONS, const widest_int &ITERATIONS_MAX, unsigned int 43333 LOOP_DEPTH, bool ENTERED_AT_TOP) 43334 Return true if it is possible to use low-overhead loops 43335 ('doloop_end' and 'doloop_begin') for a particular loop. 43336 ITERATIONS gives the exact number of iterations, or 0 if not known. 43337 ITERATIONS_MAX gives the maximum number of iterations, or 0 if not 43338 known. LOOP_DEPTH is the nesting depth of the loop, with 1 for 43339 innermost loops, 2 for loops that contain innermost loops, and so 43340 on. ENTERED_AT_TOP is true if the loop is only entered from the 43341 top. 43342 43343 This hook is only used if 'doloop_end' is available. The default 43344 implementation returns true. You can use 43345 'can_use_doloop_if_innermost' if the loop must be the innermost, 43346 and if there are no other restrictions. 43347 43348 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const 43349 rtx_insn *INSN) 43350 43351 Take an instruction in INSN and return NULL if it is valid within a 43352 low-overhead loop, otherwise return a string explaining why doloop 43353 could not be applied. 43354 43355 Many targets use special registers for low-overhead looping. For 43356 any instruction that clobbers these this function should return a 43357 string indicating the reason why the doloop could not be applied. 43358 By default, the RTL loop optimizer does not use a present doloop 43359 pattern for loops containing function calls or branch on table 43360 instructions. 43361 43362 -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx_insn *INSN) 43363 Take an instruction in INSN and return 'false' if the instruction 43364 is not appropriate as a combination of two or more instructions. 43365 The default is to accept all instructions. 43366 43367 -- Target Hook: bool TARGET_CAN_FOLLOW_JUMP (const rtx_insn *FOLLOWER, 43368 const rtx_insn *FOLLOWEE) 43369 FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if 43370 FOLLOWER may be modified to follow FOLLOWEE; false, if it can't. 43371 For example, on some targets, certain kinds of branches can't be 43372 made to follow through a hot/cold partitioning. 43373 43374 -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE) 43375 This target hook returns 'true' if X is considered to be 43376 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 43377 PA doesn't consider PLUS to be commutative inside a MEM. 43378 OUTER_CODE is the rtx code of the enclosing rtl, if known, 43379 otherwise it is UNKNOWN. 43380 43381 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 43382 43383 When the initial value of a hard register has been copied in a 43384 pseudo register, it is often not necessary to actually allocate 43385 another register to this pseudo register, because the original hard 43386 register or a stack slot it has been saved into can be used. 43387 'TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 43388 allocation once for each hard register that had its initial value 43389 copied by using 'get_func_hard_reg_initial_val' or 43390 'get_hard_reg_initial_val'. Possible values are 'NULL_RTX', if you 43391 don't want to do any special allocation, a 'REG' rtx--that would 43392 typically be the hard register itself, if it is known not to be 43393 clobbered--or a 'MEM'. If you are returning a 'MEM', this is only 43394 a hint for the allocator; it might decide to use another register 43395 anyways. You may use 'current_function_is_leaf' or 'REG_N_SETS' in 43396 the hook to determine if the hard register in question will not be 43397 clobbered. The default value of this hook is 'NULL', which 43398 disables any special allocation. 43399 43400 -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned 43401 FLAGS) 43402 This target hook returns nonzero if X, an 'unspec' or 43403 'unspec_volatile' operation, might cause a trap. Targets can use 43404 this hook to enhance precision of analysis for 'unspec' and 43405 'unspec_volatile' operations. You may call 'may_trap_p_1' to 43406 analyze inner elements of X in which case FLAGS should be passed 43407 along. 43408 43409 -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) 43410 The compiler invokes this hook whenever it changes its current 43411 function context ('cfun'). You can define this function if the 43412 back end needs to perform any initialization or reset actions on a 43413 per-function basis. For example, it may be used to implement 43414 function attributes that affect register usage or code generation 43415 patterns. The argument DECL is the declaration for the new 43416 function context, and may be null to indicate that the compiler has 43417 left a function context and is returning to processing at the top 43418 level. The default hook function does nothing. 43419 43420 GCC sets 'cfun' to a dummy function context during initialization 43421 of some parts of the back end. The hook function is not invoked in 43422 this situation; you need not worry about the hook being invoked 43423 recursively, or when the back end is in a partially-initialized 43424 state. 'cfun' might be 'NULL' to indicate processing at top level, 43425 outside of any function scope. 43426 43427 -- Macro: TARGET_OBJECT_SUFFIX 43428 Define this macro to be a C string representing the suffix for 43429 object files on your target machine. If you do not define this 43430 macro, GCC will use '.o' as the suffix for object files. 43431 43432 -- Macro: TARGET_EXECUTABLE_SUFFIX 43433 Define this macro to be a C string representing the suffix to be 43434 automatically added to executable files on your target machine. If 43435 you do not define this macro, GCC will use the null string as the 43436 suffix for executable files. 43437 43438 -- Macro: COLLECT_EXPORT_LIST 43439 If defined, 'collect2' will scan the individual object files 43440 specified on its command line and create an export list for the 43441 linker. Define this macro for systems like AIX, where the linker 43442 discards object files that are not referenced from 'main' and uses 43443 export lists. 43444 43445 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 43446 This target hook returns 'true' past the point in which new jump 43447 instructions could be created. On machines that require a register 43448 for every jump such as the SHmedia ISA of SH5, this point would 43449 typically be reload, so this target hook should be defined to a 43450 function such as: 43451 43452 static bool 43453 cannot_modify_jumps_past_reload_p () 43454 { 43455 return (reload_completed || reload_in_progress); 43456 } 43457 43458 -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void) 43459 This target hook returns true if the target supports conditional 43460 execution. This target hook is required only when the target has 43461 several different modes and they have different conditional 43462 execution capability, such as ARM. 43463 43464 -- Target Hook: rtx TARGET_GEN_CCMP_FIRST (rtx_insn **PREP_SEQ, 43465 rtx_insn **GEN_SEQ, int CODE, tree OP0, tree OP1) 43466 This function prepares to emit a comparison insn for the first 43467 compare in a sequence of conditional comparisions. It returns an 43468 appropriate comparison with 'CC' for passing to 'gen_ccmp_next' or 43469 'cbranch_optab'. The insns to prepare the compare are saved in 43470 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will be 43471 emitted when all the compares in the conditional comparision are 43472 generated without error. CODE is the 'rtx_code' of the compare for 43473 OP0 and OP1. 43474 43475 -- Target Hook: rtx TARGET_GEN_CCMP_NEXT (rtx_insn **PREP_SEQ, rtx_insn 43476 **GEN_SEQ, rtx PREV, int CMP_CODE, tree OP0, tree OP1, int 43477 BIT_CODE) 43478 This function prepares to emit a conditional comparison within a 43479 sequence of conditional comparisons. It returns an appropriate 43480 comparison with 'CC' for passing to 'gen_ccmp_next' or 43481 'cbranch_optab'. The insns to prepare the compare are saved in 43482 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will be 43483 emitted when all the compares in the conditional comparision are 43484 generated without error. The PREV expression is the result of a 43485 prior call to 'gen_ccmp_first' or 'gen_ccmp_next'. It may return 43486 'NULL' if the combination of PREV and this comparison is not 43487 supported, otherwise the result must be appropriate for passing to 43488 'gen_ccmp_next' or 'cbranch_optab'. CODE is the 'rtx_code' of the 43489 compare for OP0 and OP1. BIT_CODE is 'AND' or 'IOR', which is the 43490 op on the compares. 43491 43492 -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL, 43493 class loop *LOOP) 43494 This target hook returns a new value for the number of times LOOP 43495 should be unrolled. The parameter NUNROLL is the number of times 43496 the loop is to be unrolled. The parameter LOOP is a pointer to the 43497 loop, which is going to be checked for unrolling. This target hook 43498 is required only when the target has special constraints like 43499 maximum number of memory accesses. 43500 43501 -- Macro: POWI_MAX_MULTS 43502 If defined, this macro is interpreted as a signed integer C 43503 expression that specifies the maximum number of floating point 43504 multiplications that should be emitted when expanding 43505 exponentiation by an integer constant inline. When this value is 43506 defined, exponentiation requiring more than this number of 43507 multiplications is implemented by calling the system library's 43508 'pow', 'powf' or 'powl' routines. The default value places no 43509 upper bound on the multiplication count. 43510 43511 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 43512 *IPREFIX, int STDINC) 43513 This target hook should register any extra include files for the 43514 target. The parameter STDINC indicates if normal include files are 43515 present. The parameter SYSROOT is the system root directory. The 43516 parameter IPREFIX is the prefix for the gcc directory. 43517 43518 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 43519 char *IPREFIX, int STDINC) 43520 This target hook should register any extra include files for the 43521 target before any standard headers. The parameter STDINC indicates 43522 if normal include files are present. The parameter SYSROOT is the 43523 system root directory. The parameter IPREFIX is the prefix for the 43524 gcc directory. 43525 43526 -- Macro: void TARGET_OPTF (char *PATH) 43527 This target hook should register special include paths for the 43528 target. The parameter PATH is the include to register. On Darwin 43529 systems, this is used for Framework includes, which have semantics 43530 that are different from '-I'. 43531 43532 -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 43533 This target macro returns 'true' if it is safe to use a local alias 43534 for a virtual function FNDECL when constructing thunks, 'false' 43535 otherwise. By default, the macro returns 'true' for all functions, 43536 if a target supports aliases (i.e. defines 'ASM_OUTPUT_DEF'), 43537 'false' otherwise, 43538 43539 -- Macro: TARGET_FORMAT_TYPES 43540 If defined, this macro is the name of a global variable containing 43541 target-specific format checking information for the '-Wformat' 43542 option. The default is to have no target-specific format checks. 43543 43544 -- Macro: TARGET_N_FORMAT_TYPES 43545 If defined, this macro is the number of entries in 43546 'TARGET_FORMAT_TYPES'. 43547 43548 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES 43549 If defined, this macro is the name of a global variable containing 43550 target-specific format overrides for the '-Wformat' option. The 43551 default is to have no target-specific format overrides. If 43552 defined, 'TARGET_FORMAT_TYPES' must be defined, too. 43553 43554 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT 43555 If defined, this macro specifies the number of entries in 43556 'TARGET_OVERRIDES_FORMAT_ATTRIBUTES'. 43557 43558 -- Macro: TARGET_OVERRIDES_FORMAT_INIT 43559 If defined, this macro specifies the optional initialization 43560 routine for target specific customizations of the system printf and 43561 scanf formatter settings. 43562 43563 -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 43564 (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL) 43565 If defined, this macro returns the diagnostic message when it is 43566 illegal to pass argument VAL to function FUNCDECL with prototype 43567 TYPELIST. 43568 43569 -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree 43570 FROMTYPE, const_tree TOTYPE) 43571 If defined, this macro returns the diagnostic message when it is 43572 invalid to convert from FROMTYPE to TOTYPE, or 'NULL' if validity 43573 should be determined by the front end. 43574 43575 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, 43576 const_tree TYPE) 43577 If defined, this macro returns the diagnostic message when it is 43578 invalid to apply operation OP (where unary plus is denoted by 43579 'CONVERT_EXPR') to an operand of type TYPE, or 'NULL' if validity 43580 should be determined by the front end. 43581 43582 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, 43583 const_tree TYPE1, const_tree TYPE2) 43584 If defined, this macro returns the diagnostic message when it is 43585 invalid to apply operation OP to operands of types TYPE1 and TYPE2, 43586 or 'NULL' if validity should be determined by the front end. 43587 43588 -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE) 43589 If defined, this target hook returns the type to which values of 43590 TYPE should be promoted when they appear in expressions, analogous 43591 to the integer promotions, or 'NULL_TREE' to use the front end's 43592 normal promotion rules. This hook is useful when there are 43593 target-specific types with special promotion rules. This is 43594 currently used only by the C and C++ front ends. 43595 43596 -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR) 43597 If defined, this hook returns the result of converting EXPR to 43598 TYPE. It should return the converted expression, or 'NULL_TREE' to 43599 apply the front end's normal conversion rules. This hook is useful 43600 when there are target-specific types with special conversion rules. 43601 This is currently used only by the C and C++ front ends. 43602 43603 -- Target Hook: bool TARGET_VERIFY_TYPE_CONTEXT (location_t LOC, 43604 type_context_kind CONTEXT, const_tree TYPE, bool SILENT_P) 43605 If defined, this hook returns false if there is a target-specific 43606 reason why type TYPE cannot be used in the source language context 43607 described by CONTEXT. When SILENT_P is false, the hook also 43608 reports an error against LOC for invalid uses of TYPE. 43609 43610 Calls to this hook should be made through the global function 43611 'verify_type_context', which makes the SILENT_P parameter default 43612 to false and also handles 'error_mark_node'. 43613 43614 The default implementation always returns true. 43615 43616 -- Macro: OBJC_JBLEN 43617 This macro determines the size of the objective C jump buffer for 43618 the NeXT runtime. By default, OBJC_JBLEN is defined to an 43619 innocuous value. 43620 43621 -- Macro: LIBGCC2_UNWIND_ATTRIBUTE 43622 Define this macro if any target-specific attributes need to be 43623 attached to the functions in 'libgcc' that provide low-level 43624 support for call stack unwinding. It is used in declarations in 43625 'unwind-generic.h' and the associated definitions of those 43626 functions. 43627 43628 -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void) 43629 Define this macro to update the current function stack boundary if 43630 necessary. 43631 43632 -- Target Hook: rtx TARGET_GET_DRAP_RTX (void) 43633 This hook should return an rtx for Dynamic Realign Argument Pointer 43634 (DRAP) if a different argument pointer register is needed to access 43635 the function's argument list due to stack realignment. Return 43636 'NULL' if no DRAP is needed. 43637 43638 -- Target Hook: HARD_REG_SET TARGET_ZERO_CALL_USED_REGS (HARD_REG_SET 43639 SELECTED_REGS) 43640 This target hook emits instructions to zero the subset of 43641 SELECTED_REGS that could conceivably contain values that are useful 43642 to an attacker. Return the set of registers that were actually 43643 cleared. 43644 43645 The default implementation uses normal move instructions to zero 43646 all the registers in SELECTED_REGS. Define this hook if the target 43647 has more efficient ways of zeroing certain registers, or if you 43648 believe that certain registers would never contain values that are 43649 useful to an attacker. 43650 43651 -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void) 43652 When optimization is disabled, this hook indicates whether or not 43653 arguments should be allocated to stack slots. Normally, GCC 43654 allocates stacks slots for arguments when not optimizing in order 43655 to make debugging easier. However, when a function is declared 43656 with '__attribute__((naked))', there is no stack frame, and the 43657 compiler cannot safely move arguments from the registers in which 43658 they are passed to the stack. Therefore, this hook should return 43659 true in general, but false for naked functions. The default 43660 implementation always returns true. 43661 43662 -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR 43663 On some architectures it can take multiple instructions to 43664 synthesize a constant. If there is another constant already in a 43665 register that is close enough in value then it is preferable that 43666 the new constant is computed from this register using immediate 43667 addition or subtraction. We accomplish this through CSE. Besides 43668 the value of the constant we also add a lower and an upper constant 43669 anchor to the available expressions. These are then queried when 43670 encountering new constants. The anchors are computed by rounding 43671 the constant up and down to a multiple of the value of 43672 'TARGET_CONST_ANCHOR'. 'TARGET_CONST_ANCHOR' should be the maximum 43673 positive value accepted by immediate-add plus one. We currently 43674 assume that the value of 'TARGET_CONST_ANCHOR' is a power of 2. 43675 For example, on MIPS, where add-immediate takes a 16-bit signed 43676 value, 'TARGET_CONST_ANCHOR' is set to '0x8000'. The default value 43677 is zero, which disables this optimization. 43678 43679 -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void) 43680 Return the offset bitwise ored into shifted address to get 43681 corresponding Address Sanitizer shadow memory address. NULL if 43682 Address Sanitizer is not supported by the target. May return 0 if 43683 Address Sanitizer is not supported by a subtarget. 43684 43685 -- Target Hook: unsigned HOST_WIDE_INT TARGET_MEMMODEL_CHECK (unsigned 43686 HOST_WIDE_INT VAL) 43687 Validate target specific memory model mask bits. When NULL no 43688 target specific memory model bits are allowed. 43689 43690 -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 43691 This value should be set if the result written by 43692 'atomic_test_and_set' is not exactly 1, i.e. the 'bool' 'true'. 43693 43694 -- Target Hook: bool TARGET_HAS_IFUNC_P (void) 43695 It returns true if the target supports GNU indirect functions. The 43696 support includes the assembler, linker and dynamic linker. The 43697 default value of this hook is based on target's libc. 43698 43699 -- Target Hook: unsigned int TARGET_ATOMIC_ALIGN_FOR_MODE (machine_mode 43700 MODE) 43701 If defined, this function returns an appropriate alignment in bits 43702 for an atomic object of machine_mode MODE. If 0 is returned then 43703 the default alignment for the specified mode is used. 43704 43705 -- Target Hook: void TARGET_ATOMIC_ASSIGN_EXPAND_FENV (tree *HOLD, tree 43706 *CLEAR, tree *UPDATE) 43707 ISO C11 requires atomic compound assignments that may raise 43708 floating-point exceptions to raise exceptions corresponding to the 43709 arithmetic operation whose result was successfully stored in a 43710 compare-and-exchange sequence. This requires code equivalent to 43711 calls to 'feholdexcept', 'feclearexcept' and 'feupdateenv' to be 43712 generated at appropriate points in the compare-and-exchange 43713 sequence. This hook should set '*HOLD' to an expression equivalent 43714 to the call to 'feholdexcept', '*CLEAR' to an expression equivalent 43715 to the call to 'feclearexcept' and '*UPDATE' to an expression 43716 equivalent to the call to 'feupdateenv'. The three expressions are 43717 'NULL_TREE' on entry to the hook and may be left as 'NULL_TREE' if 43718 no code is required in a particular place. The default 43719 implementation leaves all three expressions as 'NULL_TREE'. The 43720 '__atomic_feraiseexcept' function from 'libatomic' may be of use as 43721 part of the code generated in '*UPDATE'. 43722 43723 -- Target Hook: void TARGET_RECORD_OFFLOAD_SYMBOL (tree) 43724 Used when offloaded functions are seen in the compilation unit and 43725 no named sections are available. It is called once for each symbol 43726 that must be recorded in the offload function and variable table. 43727 43728 -- Target Hook: char * TARGET_OFFLOAD_OPTIONS (void) 43729 Used when writing out the list of options into an LTO file. It 43730 should translate any relevant target-specific options (such as the 43731 ABI in use) into one of the '-foffload' options that exist as a 43732 common interface to express such options. It should return a 43733 string containing these options, separated by spaces, which the 43734 caller will free. 43735 43736 -- Macro: TARGET_SUPPORTS_WIDE_INT 43737 43738 On older ports, large integers are stored in 'CONST_DOUBLE' rtl 43739 objects. Newer ports define 'TARGET_SUPPORTS_WIDE_INT' to be 43740 nonzero to indicate that large integers are stored in 43741 'CONST_WIDE_INT' rtl objects. The 'CONST_WIDE_INT' allows very 43742 large integer constants to be represented. 'CONST_DOUBLE' is 43743 limited to twice the size of the host's 'HOST_WIDE_INT' 43744 representation. 43745 43746 Converting a port mostly requires looking for the places where 43747 'CONST_DOUBLE's are used with 'VOIDmode' and replacing that code 43748 with code that accesses 'CONST_WIDE_INT's. '"grep -i 43749 const_double"' at the port level gets you to 95% of the changes 43750 that need to be made. There are a few places that require a deeper 43751 look. 43752 43753 * There is no equivalent to 'hval' and 'lval' for 43754 'CONST_WIDE_INT's. This would be difficult to express in the 43755 md language since there are a variable number of elements. 43756 43757 Most ports only check that 'hval' is either 0 or -1 to see if 43758 the value is small. As mentioned above, this will no longer 43759 be necessary since small constants are always 'CONST_INT'. Of 43760 course there are still a few exceptions, the alpha's 43761 constraint used by the zap instruction certainly requires 43762 careful examination by C code. However, all the current code 43763 does is pass the hval and lval to C code, so evolving the c 43764 code to look at the 'CONST_WIDE_INT' is not really a large 43765 change. 43766 43767 * Because there is no standard template that ports use to 43768 materialize constants, there is likely to be some futzing that 43769 is unique to each port in this code. 43770 43771 * The rtx costs may have to be adjusted to properly account for 43772 larger constants that are represented as 'CONST_WIDE_INT'. 43773 43774 All and all it does not take long to convert ports that the 43775 maintainer is familiar with. 43776 43777 -- Target Hook: bool TARGET_HAVE_SPECULATION_SAFE_VALUE (bool ACTIVE) 43778 This hook is used to determine the level of target support for 43779 '__builtin_speculation_safe_value'. If called with an argument of 43780 false, it returns true if the target has been modified to support 43781 this builtin. If called with an argument of true, it returns true 43782 if the target requires active mitigation execution might be 43783 speculative. 43784 43785 The default implementation returns false if the target does not 43786 define a pattern named 'speculation_barrier'. Else it returns true 43787 for the first case and whether the pattern is enabled for the 43788 current compilation for the second case. 43789 43790 For targets that have no processors that can execute instructions 43791 speculatively an alternative implemenation of this hook is 43792 available: simply redefine this hook to 43793 'speculation_safe_value_not_needed' along with your other target 43794 hooks. 43795 43796 -- Target Hook: rtx TARGET_SPECULATION_SAFE_VALUE (machine_mode MODE, 43797 rtx RESULT, rtx VAL, rtx FAILVAL) 43798 This target hook can be used to generate a target-specific code 43799 sequence that implements the '__builtin_speculation_safe_value' 43800 built-in function. The function must always return VAL in RESULT 43801 in mode MODE when the cpu is not executing speculatively, but must 43802 never return that when speculating until it is known that the 43803 speculation will not be unwound. The hook supports two primary 43804 mechanisms for implementing the requirements. The first is to emit 43805 a speculation barrier which forces the processor to wait until all 43806 prior speculative operations have been resolved; the second is to 43807 use a target-specific mechanism that can track the speculation 43808 state and to return FAILVAL if it can determine that speculation 43809 must be unwound at a later time. 43810 43811 The default implementation simply copies VAL to RESULT and emits a 43812 'speculation_barrier' instruction if that is defined. 43813 43814 -- Target Hook: void TARGET_RUN_TARGET_SELFTESTS (void) 43815 If selftests are enabled, run any selftests for this target. 43816 43817 -- Target Hook: bool TARGET_MEMTAG_CAN_TAG_ADDRESSES () 43818 True if the backend architecture naturally supports ignoring some 43819 region of pointers. This feature means that '-fsanitize=hwaddress' 43820 can work. 43821 43822 At preset, this feature does not support address spaces. It also 43823 requires 'Pmode' to be the same as 'ptr_mode'. 43824 43825 -- Target Hook: uint8_t TARGET_MEMTAG_TAG_SIZE () 43826 Return the size of a tag (in bits) for this platform. 43827 43828 The default returns 8. 43829 43830 -- Target Hook: uint8_t TARGET_MEMTAG_GRANULE_SIZE () 43831 Return the size in real memory that each byte in shadow memory 43832 refers to. I.e. if a variable is X bytes long in memory, then 43833 this hook should return the value Y such that the tag in shadow 43834 memory spans X/Y bytes. 43835 43836 Most variables will need to be aligned to this amount since two 43837 variables that are neighbors in memory and share a tag granule 43838 would need to share the same tag. 43839 43840 The default returns 16. 43841 43842 -- Target Hook: rtx TARGET_MEMTAG_INSERT_RANDOM_TAG (rtx UNTAGGED, rtx 43843 TARGET) 43844 Return an RTX representing the value of UNTAGGED but with a 43845 (possibly) random tag in it. Put that value into TARGET if it is 43846 convenient to do so. This function is used to generate a tagged 43847 base for the current stack frame. 43848 43849 -- Target Hook: rtx TARGET_MEMTAG_ADD_TAG (rtx BASE, poly_int64 43850 ADDR_OFFSET, uint8_t TAG_OFFSET) 43851 Return an RTX that represents the result of adding ADDR_OFFSET to 43852 the address in pointer BASE and TAG_OFFSET to the tag in pointer 43853 BASE. The resulting RTX must either be a valid memory address or 43854 be able to get put into an operand with 'force_operand'. 43855 43856 Unlike other memtag hooks, this must return an expression and not 43857 emit any RTL. 43858 43859 -- Target Hook: rtx TARGET_MEMTAG_SET_TAG (rtx UNTAGGED_BASE, rtx TAG, 43860 rtx TARGET) 43861 Return an RTX representing UNTAGGED_BASE but with the tag TAG. Try 43862 and store this in TARGET if convenient. UNTAGGED_BASE is required 43863 to have a zero tag when this hook is called. The default of this 43864 hook is to set the top byte of UNTAGGED_BASE to TAG. 43865 43866 -- Target Hook: rtx TARGET_MEMTAG_EXTRACT_TAG (rtx TAGGED_POINTER, rtx 43867 TARGET) 43868 Return an RTX representing the tag stored in TAGGED_POINTER. Store 43869 the result in TARGET if it is convenient. The default represents 43870 the top byte of the original pointer. 43871 43872 -- Target Hook: rtx TARGET_MEMTAG_UNTAGGED_POINTER (rtx TAGGED_POINTER, 43873 rtx TARGET) 43874 Return an RTX representing TAGGED_POINTER with its tag set to zero. 43875 Store the result in TARGET if convenient. The default clears the 43876 top byte of the original pointer. 43877 43878 43879File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 43880 4388119 Host Configuration 43882********************* 43883 43884Most details about the machine and system on which the compiler is 43885actually running are detected by the 'configure' script. Some things 43886are impossible for 'configure' to detect; these are described in two 43887ways, either by macros defined in a file named 'xm-MACHINE.h' or by hook 43888functions in the file specified by the OUT_HOST_HOOK_OBJ variable in 43889'config.gcc'. (The intention is that very few hosts will need a header 43890file but nearly every fully supported host will need to override some 43891hooks.) 43892 43893 If you need to define only a few macros, and they have simple 43894definitions, consider using the 'xm_defines' variable in your 43895'config.gcc' entry instead of creating a host configuration header. 43896*Note System Config::. 43897 43898* Menu: 43899 43900* Host Common:: Things every host probably needs implemented. 43901* Filesystem:: Your host cannot have the letter 'a' in filenames? 43902* Host Misc:: Rare configuration options for hosts. 43903 43904 43905File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 43906 4390719.1 Host Common 43908================ 43909 43910Some things are just not portable, even between similar operating 43911systems, and are too difficult for autoconf to detect. They get 43912implemented using hook functions in the file specified by the 43913HOST_HOOK_OBJ variable in 'config.gcc'. 43914 43915 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 43916 This host hook is used to set up handling for extra signals. The 43917 most common thing to do in this hook is to detect stack overflow. 43918 43919 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 43920 FD) 43921 This host hook returns the address of some space that is likely to 43922 be free in some subsequent invocation of the compiler. We intend 43923 to load the PCH data at this address such that the data need not be 43924 relocated. The area should be able to hold SIZE bytes. If the 43925 host uses 'mmap', FD is an open file descriptor that can be used 43926 for probing. 43927 43928 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, size_t 43929 SIZE, int FD, size_t OFFSET) 43930 This host hook is called when a PCH file is about to be loaded. We 43931 want to load SIZE bytes from FD at OFFSET into memory at ADDRESS. 43932 The given address will be the result of a previous invocation of 43933 'HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we couldn't allocate 43934 SIZE bytes at ADDRESS. Return 0 if the memory is allocated but the 43935 data is not loaded. Return 1 if the hook has performed everything. 43936 43937 If the implementation uses reserved address space, free any 43938 reserved space beyond SIZE, regardless of the return value. If no 43939 PCH will be loaded, this hook may be called with SIZE zero, in 43940 which case all reserved address space should be freed. 43941 43942 Do not try to handle values of ADDRESS that could not have been 43943 returned by this executable; just return -1. Such values usually 43944 indicate an out-of-date PCH file (built by some other GCC 43945 executable), and such a PCH file won't work. 43946 43947 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 43948 This host hook returns the alignment required for allocating 43949 virtual memory. Usually this is the same as getpagesize, but on 43950 some hosts the alignment for reserving memory differs from the 43951 pagesize for committing memory. 43952 43953 43954File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 43955 4395619.2 Host Filesystem 43957==================== 43958 43959GCC needs to know a number of things about the semantics of the host 43960machine's filesystem. Filesystems with Unix and MS-DOS semantics are 43961automatically detected. For other systems, you can define the following 43962macros in 'xm-MACHINE.h'. 43963 43964'HAVE_DOS_BASED_FILE_SYSTEM' 43965 This macro is automatically defined by 'system.h' if the host file 43966 system obeys the semantics defined by MS-DOS instead of Unix. DOS 43967 file systems are case insensitive, file specifications may begin 43968 with a drive letter, and both forward slash and backslash ('/' and 43969 '\') are directory separators. 43970 43971'DIR_SEPARATOR' 43972'DIR_SEPARATOR_2' 43973 If defined, these macros expand to character constants specifying 43974 separators for directory names within a file specification. 43975 'system.h' will automatically give them appropriate values on Unix 43976 and MS-DOS file systems. If your file system is neither of these, 43977 define one or both appropriately in 'xm-MACHINE.h'. 43978 43979 However, operating systems like VMS, where constructing a pathname 43980 is more complicated than just stringing together directory names 43981 separated by a special character, should not define either of these 43982 macros. 43983 43984'PATH_SEPARATOR' 43985 If defined, this macro should expand to a character constant 43986 specifying the separator for elements of search paths. The default 43987 value is a colon (':'). DOS-based systems usually, but not always, 43988 use semicolon (';'). 43989 43990'VMS' 43991 Define this macro if the host system is VMS. 43992 43993'HOST_OBJECT_SUFFIX' 43994 Define this macro to be a C string representing the suffix for 43995 object files on your host machine. If you do not define this 43996 macro, GCC will use '.o' as the suffix for object files. 43997 43998'HOST_EXECUTABLE_SUFFIX' 43999 Define this macro to be a C string representing the suffix for 44000 executable files on your host machine. If you do not define this 44001 macro, GCC will use the null string as the suffix for executable 44002 files. 44003 44004'HOST_BIT_BUCKET' 44005 A pathname defined by the host operating system, which can be 44006 opened as a file and written to, but all the information written is 44007 discarded. This is commonly known as a "bit bucket" or "null 44008 device". If you do not define this macro, GCC will use '/dev/null' 44009 as the bit bucket. If the host does not support a bit bucket, 44010 define this macro to an invalid filename. 44011 44012'UPDATE_PATH_HOST_CANONICALIZE (PATH)' 44013 If defined, a C statement (sans semicolon) that performs 44014 host-dependent canonicalization when a path used in a compilation 44015 driver or preprocessor is canonicalized. PATH is a malloc-ed path 44016 to be canonicalized. If the C statement does canonicalize PATH 44017 into a different buffer, the old path should be freed and the new 44018 buffer should have been allocated with malloc. 44019 44020'DUMPFILE_FORMAT' 44021 Define this macro to be a C string representing the format to use 44022 for constructing the index part of debugging dump file names. The 44023 resultant string must fit in fifteen bytes. The full filename will 44024 be the concatenation of: the prefix of the assembler file name, the 44025 string resulting from applying this format to an index number, and 44026 a string unique to each dump file kind, e.g. 'rtl'. 44027 44028 If you do not define this macro, GCC will use '.%02d.'. You should 44029 define this macro if using the default will create an invalid file 44030 name. 44031 44032'DELETE_IF_ORDINARY' 44033 Define this macro to be a C statement (sans semicolon) that 44034 performs host-dependent removal of ordinary temp files in the 44035 compilation driver. 44036 44037 If you do not define this macro, GCC will use the default version. 44038 You should define this macro if the default version does not 44039 reliably remove the temp file as, for example, on VMS which allows 44040 multiple versions of a file. 44041 44042'HOST_LACKS_INODE_NUMBERS' 44043 Define this macro if the host filesystem does not report meaningful 44044 inode numbers in struct stat. 44045 44046 44047File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 44048 4404919.3 Host Misc 44050============== 44051 44052'FATAL_EXIT_CODE' 44053 A C expression for the status code to be returned when the compiler 44054 exits after serious errors. The default is the system-provided 44055 macro 'EXIT_FAILURE', or '1' if the system doesn't define that 44056 macro. Define this macro only if these defaults are incorrect. 44057 44058'SUCCESS_EXIT_CODE' 44059 A C expression for the status code to be returned when the compiler 44060 exits without serious errors. (Warnings are not serious errors.) 44061 The default is the system-provided macro 'EXIT_SUCCESS', or '0' if 44062 the system doesn't define that macro. Define this macro only if 44063 these defaults are incorrect. 44064 44065'USE_C_ALLOCA' 44066 Define this macro if GCC should use the C implementation of 44067 'alloca' provided by 'libiberty.a'. This only affects how some 44068 parts of the compiler itself allocate memory. It does not change 44069 code generation. 44070 44071 When GCC is built with a compiler other than itself, the C 'alloca' 44072 is always used. This is because most other implementations have 44073 serious bugs. You should define this macro only on a system where 44074 no stack-based 'alloca' can possibly work. For instance, if a 44075 system has a small limit on the size of the stack, GCC's builtin 44076 'alloca' will not work reliably. 44077 44078'COLLECT2_HOST_INITIALIZATION' 44079 If defined, a C statement (sans semicolon) that performs 44080 host-dependent initialization when 'collect2' is being initialized. 44081 44082'GCC_DRIVER_HOST_INITIALIZATION' 44083 If defined, a C statement (sans semicolon) that performs 44084 host-dependent initialization when a compilation driver is being 44085 initialized. 44086 44087'HOST_LONG_LONG_FORMAT' 44088 If defined, the string used to indicate an argument of type 'long 44089 long' to functions like 'printf'. The default value is '"ll"'. 44090 44091'HOST_LONG_FORMAT' 44092 If defined, the string used to indicate an argument of type 'long' 44093 to functions like 'printf'. The default value is '"l"'. 44094 44095'HOST_PTR_PRINTF' 44096 If defined, the string used to indicate an argument of type 'void 44097 *' to functions like 'printf'. The default value is '"%p"'. 44098 44099 In addition, if 'configure' generates an incorrect definition of any of 44100the macros in 'auto-host.h', you can override that definition in a host 44101configuration header. If you need to do this, first see if it is 44102possible to fix 'configure'. 44103 44104 44105File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 44106 4410720 Makefile Fragments 44108********************* 44109 44110When you configure GCC using the 'configure' script, it will construct 44111the file 'Makefile' from the template file 'Makefile.in'. When it does 44112this, it can incorporate makefile fragments from the 'config' directory. 44113These are used to set Makefile parameters that are not amenable to being 44114calculated by autoconf. The list of fragments to incorporate is set by 44115'config.gcc' (and occasionally 'config.build' and 'config.host'); *Note 44116System Config::. 44117 44118 Fragments are named either 't-TARGET' or 'x-HOST', depending on whether 44119they are relevant to configuring GCC to produce code for a particular 44120target, or to configuring GCC to run on a particular host. Here TARGET 44121and HOST are mnemonics which usually have some relationship to the 44122canonical system name, but no formal connection. 44123 44124 If these files do not exist, it means nothing needs to be added for a 44125given target or host. Most targets need a few 't-TARGET' fragments, but 44126needing 'x-HOST' fragments is rare. 44127 44128* Menu: 44129 44130* Target Fragment:: Writing 't-TARGET' files. 44131* Host Fragment:: Writing 'x-HOST' files. 44132 44133 44134File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 44135 4413620.1 Target Makefile Fragments 44137============================== 44138 44139Target makefile fragments can set these Makefile variables. 44140 44141'LIBGCC2_CFLAGS' 44142 Compiler flags to use when compiling 'libgcc2.c'. 44143 44144'LIB2FUNCS_EXTRA' 44145 A list of source file names to be compiled or assembled and 44146 inserted into 'libgcc.a'. 44147 44148'CRTSTUFF_T_CFLAGS' 44149 Special flags used when compiling 'crtstuff.c'. *Note 44150 Initialization::. 44151 44152'CRTSTUFF_T_CFLAGS_S' 44153 Special flags used when compiling 'crtstuff.c' for shared linking. 44154 Used if you use 'crtbeginS.o' and 'crtendS.o' in 'EXTRA-PARTS'. 44155 *Note Initialization::. 44156 44157'MULTILIB_OPTIONS' 44158 For some targets, invoking GCC in different ways produces objects 44159 that cannot be linked together. For example, for some targets GCC 44160 produces both big and little endian code. For these targets, you 44161 must arrange for multiple versions of 'libgcc.a' to be compiled, 44162 one for each set of incompatible options. When GCC invokes the 44163 linker, it arranges to link in the right version of 'libgcc.a', 44164 based on the command line options used. 44165 44166 The 'MULTILIB_OPTIONS' macro lists the set of options for which 44167 special versions of 'libgcc.a' must be built. Write options that 44168 are mutually incompatible side by side, separated by a slash. 44169 Write options that may be used together separated by a space. The 44170 build procedure will build all combinations of compatible options. 44171 44172 For example, if you set 'MULTILIB_OPTIONS' to 'm68000/m68020 44173 msoft-float', 'Makefile' will build special versions of 'libgcc.a' 44174 using the following sets of options: '-m68000', '-m68020', 44175 '-msoft-float', '-m68000 -msoft-float', and '-m68020 -msoft-float'. 44176 44177'MULTILIB_DIRNAMES' 44178 If 'MULTILIB_OPTIONS' is used, this variable specifies the 44179 directory names that should be used to hold the various libraries. 44180 Write one element in 'MULTILIB_DIRNAMES' for each element in 44181 'MULTILIB_OPTIONS'. If 'MULTILIB_DIRNAMES' is not used, the 44182 default value will be 'MULTILIB_OPTIONS', with all slashes treated 44183 as spaces. 44184 44185 'MULTILIB_DIRNAMES' describes the multilib directories using GCC 44186 conventions and is applied to directories that are part of the GCC 44187 installation. When multilib-enabled, the compiler will add a 44188 subdirectory of the form PREFIX/MULTILIB before each directory in 44189 the search path for libraries and crt files. 44190 44191 For example, if 'MULTILIB_OPTIONS' is set to 'm68000/m68020 44192 msoft-float', then the default value of 'MULTILIB_DIRNAMES' is 44193 'm68000 m68020 msoft-float'. You may specify a different value if 44194 you desire a different set of directory names. 44195 44196'MULTILIB_MATCHES' 44197 Sometimes the same option may be written in two different ways. If 44198 an option is listed in 'MULTILIB_OPTIONS', GCC needs to know about 44199 any synonyms. In that case, set 'MULTILIB_MATCHES' to a list of 44200 items of the form 'option=option' to describe all relevant 44201 synonyms. For example, 'm68000=mc68000 m68020=mc68020'. 44202 44203'MULTILIB_EXCEPTIONS' 44204 Sometimes when there are multiple sets of 'MULTILIB_OPTIONS' being 44205 specified, there are combinations that should not be built. In 44206 that case, set 'MULTILIB_EXCEPTIONS' to be all of the switch 44207 exceptions in shell case syntax that should not be built. 44208 44209 For example the ARM processor cannot execute both hardware floating 44210 point instructions and the reduced size THUMB instructions at the 44211 same time, so there is no need to build libraries with both of 44212 these options enabled. Therefore 'MULTILIB_EXCEPTIONS' is set to: 44213 *mthumb/*mhard-float* 44214 44215'MULTILIB_REQUIRED' 44216 Sometimes when there are only a few combinations are required, it 44217 would be a big effort to come up with a 'MULTILIB_EXCEPTIONS' list 44218 to cover all undesired ones. In such a case, just listing all the 44219 required combinations in 'MULTILIB_REQUIRED' would be more 44220 straightforward. 44221 44222 The way to specify the entries in 'MULTILIB_REQUIRED' is same with 44223 the way used for 'MULTILIB_EXCEPTIONS', only this time what are 44224 required will be specified. Suppose there are multiple sets of 44225 'MULTILIB_OPTIONS' and only two combinations are required, one for 44226 ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU, 44227 the 'MULTILIB_REQUIRED' can be set to: 44228 MULTILIB_REQUIRED = mthumb/march=armv7-m 44229 MULTILIB_REQUIRED += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16 44230 44231 The 'MULTILIB_REQUIRED' can be used together with 44232 'MULTILIB_EXCEPTIONS'. The option combinations generated from 44233 'MULTILIB_OPTIONS' will be filtered by 'MULTILIB_EXCEPTIONS' and 44234 then by 'MULTILIB_REQUIRED'. 44235 44236'MULTILIB_REUSE' 44237 Sometimes it is desirable to reuse one existing multilib for 44238 different sets of options. Such kind of reuse can minimize the 44239 number of multilib variants. And for some targets it is better to 44240 reuse an existing multilib than to fall back to default multilib 44241 when there is no corresponding multilib. This can be done by 44242 adding reuse rules to 'MULTILIB_REUSE'. 44243 44244 A reuse rule is comprised of two parts connected by equality sign. 44245 The left part is the option set used to build multilib and the 44246 right part is the option set that will reuse this multilib. Both 44247 parts should only use options specified in 'MULTILIB_OPTIONS' and 44248 the equality signs found in options name should be replaced with 44249 periods. An explicit period in the rule can be escaped by 44250 preceding it with a backslash. The order of options in the left 44251 part matters and should be same with those specified in 44252 'MULTILIB_REQUIRED' or aligned with the order in 44253 'MULTILIB_OPTIONS'. There is no such limitation for options in the 44254 right part as we don't build multilib from them. 44255 44256 'MULTILIB_REUSE' is different from 'MULTILIB_MATCHES' in that it 44257 sets up relations between two option sets rather than two options. 44258 Here is an example to demo how we reuse libraries built in Thumb 44259 mode for applications built in ARM mode: 44260 MULTILIB_REUSE = mthumb/march.armv7-r=marm/march.armv7-r 44261 44262 Before the advent of 'MULTILIB_REUSE', GCC select multilib by 44263 comparing command line options with options used to build multilib. 44264 The 'MULTILIB_REUSE' is complementary to that way. Only when the 44265 original comparison matches nothing it will work to see if it is OK 44266 to reuse some existing multilib. 44267 44268'MULTILIB_EXTRA_OPTS' 44269 Sometimes it is desirable that when building multiple versions of 44270 'libgcc.a' certain options should always be passed on to the 44271 compiler. In that case, set 'MULTILIB_EXTRA_OPTS' to be the list 44272 of options to be used for all builds. If you set this, you should 44273 probably set 'CRTSTUFF_T_CFLAGS' to a dash followed by it. 44274 44275'MULTILIB_OSDIRNAMES' 44276 If 'MULTILIB_OPTIONS' is used, this variable specifies a list of 44277 subdirectory names, that are used to modify the search path 44278 depending on the chosen multilib. Unlike 'MULTILIB_DIRNAMES', 44279 'MULTILIB_OSDIRNAMES' describes the multilib directories using 44280 operating systems conventions, and is applied to the directories 44281 such as 'lib' or those in the 'LIBRARY_PATH' environment variable. 44282 The format is either the same as of 'MULTILIB_DIRNAMES', or a set 44283 of mappings. When it is the same as 'MULTILIB_DIRNAMES', it 44284 describes the multilib directories using operating system 44285 conventions, rather than GCC conventions. When it is a set of 44286 mappings of the form GCCDIR=OSDIR, the left side gives the GCC 44287 convention and the right gives the equivalent OS defined location. 44288 If the OSDIR part begins with a '!', GCC will not search in the 44289 non-multilib directory and use exclusively the multilib directory. 44290 Otherwise, the compiler will examine the search path for libraries 44291 and crt files twice; the first time it will add MULTILIB to each 44292 directory in the search path, the second it will not. 44293 44294 For configurations that support both multilib and multiarch, 44295 'MULTILIB_OSDIRNAMES' also encodes the multiarch name, thus 44296 subsuming 'MULTIARCH_DIRNAME'. The multiarch name is appended to 44297 each directory name, separated by a colon (e.g. 44298 '../lib32:i386-linux-gnu'). 44299 44300 Each multiarch subdirectory will be searched before the 44301 corresponding OS multilib directory, for example 44302 '/lib/i386-linux-gnu' before '/lib/../lib32'. The multiarch name 44303 will also be used to modify the system header search path, as 44304 explained for 'MULTIARCH_DIRNAME'. 44305 44306'MULTIARCH_DIRNAME' 44307 This variable specifies the multiarch name for configurations that 44308 are multiarch-enabled but not multilibbed configurations. 44309 44310 The multiarch name is used to augment the search path for 44311 libraries, crt files and system header files with additional 44312 locations. The compiler will add a multiarch subdirectory of the 44313 form PREFIX/MULTIARCH before each directory in the library and crt 44314 search path. It will also add two directories 44315 'LOCAL_INCLUDE_DIR'/MULTIARCH and 44316 'NATIVE_SYSTEM_HEADER_DIR'/MULTIARCH) to the system header search 44317 path, respectively before 'LOCAL_INCLUDE_DIR' and 44318 'NATIVE_SYSTEM_HEADER_DIR'. 44319 44320 'MULTIARCH_DIRNAME' is not used for configurations that support 44321 both multilib and multiarch. In that case, multiarch names are 44322 encoded in 'MULTILIB_OSDIRNAMES' instead. 44323 44324 More documentation about multiarch can be found at 44325 <https://wiki.debian.org/Multiarch>. 44326 44327'SPECS' 44328 Unfortunately, setting 'MULTILIB_EXTRA_OPTS' is not enough, since 44329 it does not affect the build of target libraries, at least not the 44330 build of the default multilib. One possible work-around is to use 44331 'DRIVER_SELF_SPECS' to bring options from the 'specs' file as if 44332 they had been passed in the compiler driver command line. However, 44333 you don't want to be adding these options after the toolchain is 44334 installed, so you can instead tweak the 'specs' file that will be 44335 used during the toolchain build, while you still install the 44336 original, built-in 'specs'. The trick is to set 'SPECS' to some 44337 other filename (say 'specs.install'), that will then be created out 44338 of the built-in specs, and introduce a 'Makefile' rule to generate 44339 the 'specs' file that's going to be used at build time out of your 44340 'specs.install'. 44341 44342'T_CFLAGS' 44343 These are extra flags to pass to the C compiler. They are used 44344 both when building GCC, and when compiling things with the 44345 just-built GCC. This variable is deprecated and should not be 44346 used. 44347 44348 44349File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 44350 4435120.2 Host Makefile Fragments 44352============================ 44353 44354The use of 'x-HOST' fragments is discouraged. You should only use it 44355for makefile dependencies. 44356 44357 44358File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 44359 4436021 'collect2' 44361************* 44362 44363GCC uses a utility called 'collect2' on nearly all systems to arrange to 44364call various initialization functions at start time. 44365 44366 The program 'collect2' works by linking the program once and looking 44367through the linker output file for symbols with particular names 44368indicating they are constructor functions. If it finds any, it creates 44369a new temporary '.c' file containing a table of them, compiles it, and 44370links the program a second time including that file. 44371 44372 The actual calls to the constructors are carried out by a subroutine 44373called '__main', which is called (automatically) at the beginning of the 44374body of 'main' (provided 'main' was compiled with GNU CC). Calling 44375'__main' is necessary, even when compiling C code, to allow linking C 44376and C++ object code together. (If you use '-nostdlib', you get an 44377unresolved reference to '__main', since it's defined in the standard GCC 44378library. Include '-lgcc' at the end of your compiler command line to 44379resolve this reference.) 44380 44381 The program 'collect2' is installed as 'ld' in the directory where the 44382passes of the compiler are installed. When 'collect2' needs to find the 44383_real_ 'ld', it tries the following file names: 44384 44385 * a hard coded linker file name, if GCC was configured with the 44386 '--with-ld' option. 44387 44388 * 'real-ld' in the directories listed in the compiler's search 44389 directories. 44390 44391 * 'real-ld' in the directories listed in the environment variable 44392 'PATH'. 44393 44394 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 44395 if specified. 44396 44397 * 'ld' in the compiler's search directories, except that 'collect2' 44398 will not execute itself recursively. 44399 44400 * 'ld' in 'PATH'. 44401 44402 "The compiler's search directories" means all the directories where 44403'gcc' searches for passes of the compiler. This includes directories 44404that you specify with '-B'. 44405 44406 Cross-compilers search a little differently: 44407 44408 * 'real-ld' in the compiler's search directories. 44409 44410 * 'TARGET-real-ld' in 'PATH'. 44411 44412 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 44413 if specified. 44414 44415 * 'ld' in the compiler's search directories. 44416 44417 * 'TARGET-ld' in 'PATH'. 44418 44419 'collect2' explicitly avoids running 'ld' using the file name under 44420which 'collect2' itself was invoked. In fact, it remembers up a list of 44421such names--in case one copy of 'collect2' finds another copy (or 44422version) of 'collect2' installed as 'ld' in a second place in the search 44423path. 44424 44425 'collect2' searches for the utilities 'nm' and 'strip' using the same 44426algorithm as above for 'ld'. 44427 44428 44429File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 44430 4443122 Standard Header File Directories 44432*********************************** 44433 44434'GCC_INCLUDE_DIR' means the same thing for native and cross. It is 44435where GCC stores its private include files, and also where GCC stores 44436the fixed include files. A cross compiled GCC runs 'fixincludes' on the 44437header files in '$(tooldir)/include'. (If the cross compilation header 44438files need to be fixed, they must be installed before GCC is built. If 44439the cross compilation header files are already suitable for GCC, nothing 44440special need be done). 44441 44442 'GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 44443is where 'g++' looks first for header files. The C++ library installs 44444only target independent header files in that directory. 44445 44446 'LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 44447install anything there. It is normally '/usr/local/include'. This is 44448where local additions to a packaged system should place header files. 44449 44450 'CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 44451install anything there. 44452 44453 'TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 44454the place for other packages to install header files that GCC will use. 44455For a cross-compiler, this is the equivalent of '/usr/include'. When 44456you build a cross-compiler, 'fixincludes' processes any header files in 44457this directory. 44458 44459 44460File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top 44461 4446223 Memory Management and Type Information 44463***************************************** 44464 44465GCC uses some fairly sophisticated memory management techniques, which 44466involve determining information about GCC's data structures from GCC's 44467source code and using this information to perform garbage collection and 44468implement precompiled headers. 44469 44470 A full C++ parser would be too complicated for this task, so a limited 44471subset of C++ is interpreted and special markers are used to determine 44472what parts of the source to look at. All 'struct', 'union' and 44473'template' structure declarations that define data structures that are 44474allocated under control of the garbage collector must be marked. All 44475global variables that hold pointers to garbage-collected memory must 44476also be marked. Finally, all global variables that need to be saved and 44477restored by a precompiled header must be marked. (The precompiled 44478header mechanism can only save static variables if they're scalar. 44479Complex data structures must be allocated in garbage-collected memory to 44480be saved in a precompiled header.) 44481 44482 The full format of a marker is 44483 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 44484but in most cases no options are needed. The outer double parentheses 44485are still necessary, though: 'GTY(())'. Markers can appear: 44486 44487 * In a structure definition, before the open brace; 44488 * In a global variable declaration, after the keyword 'static' or 44489 'extern'; and 44490 * In a structure field definition, before the name of the field. 44491 44492 Here are some examples of marking simple data structures and globals. 44493 44494 struct GTY(()) TAG 44495 { 44496 FIELDS... 44497 }; 44498 44499 typedef struct GTY(()) TAG 44500 { 44501 FIELDS... 44502 } *TYPENAME; 44503 44504 static GTY(()) struct TAG *LIST; /* points to GC memory */ 44505 static GTY(()) int COUNTER; /* save counter in a PCH */ 44506 44507 The parser understands simple typedefs such as 'typedef struct TAG 44508*NAME;' and 'typedef int NAME;'. These don't need to be marked. 44509 44510 Since 'gengtype''s understanding of C++ is limited, there are several 44511constructs and declarations that are not supported inside 44512classes/structures marked for automatic GC code generation. The 44513following C++ constructs produce a 'gengtype' error on 44514structures/classes marked for automatic GC code generation: 44515 44516 * Type definitions inside classes/structures are not supported. 44517 * Enumerations inside classes/structures are not supported. 44518 44519 If you have a class or structure using any of the above constructs, you 44520need to mark that class as 'GTY ((user))' and provide your own marking 44521routines (see section *note User GC:: for details). 44522 44523 It is always valid to include function definitions inside classes. 44524Those are always ignored by 'gengtype', as it only cares about data 44525members. 44526 44527* Menu: 44528 44529* GTY Options:: What goes inside a 'GTY(())'. 44530* Inheritance and GTY:: Adding GTY to a class hierarchy. 44531* User GC:: Adding user-provided GC marking routines. 44532* GGC Roots:: Making global variables GGC roots. 44533* Files:: How the generated files work. 44534* Invoking the garbage collector:: How to invoke the garbage collector. 44535* Troubleshooting:: When something does not work as expected. 44536 44537 44538File: gccint.info, Node: GTY Options, Next: Inheritance and GTY, Up: Type Information 44539 4454023.1 The Inside of a 'GTY(())' 44541============================== 44542 44543Sometimes the C code is not enough to fully describe the type structure. 44544Extra information can be provided with 'GTY' options and additional 44545markers. Some options take a parameter, which may be either a string or 44546a type name, depending on the parameter. If an option takes no 44547parameter, it is acceptable either to omit the parameter entirely, or to 44548provide an empty string as a parameter. For example, 'GTY ((skip))' and 44549'GTY ((skip ("")))' are equivalent. 44550 44551 When the parameter is a string, often it is a fragment of C code. Four 44552special escapes may be used in these strings, to refer to pieces of the 44553data structure being marked: 44554 44555'%h' 44556 The current structure. 44557'%1' 44558 The structure that immediately contains the current structure. 44559'%0' 44560 The outermost structure that contains the current structure. 44561'%a' 44562 A partial expression of the form '[i1][i2]...' that indexes the 44563 array item currently being marked. 44564 44565 For instance, suppose that you have a structure of the form 44566 struct A { 44567 ... 44568 }; 44569 struct B { 44570 struct A foo[12]; 44571 }; 44572and 'b' is a variable of type 'struct B'. When marking 'b.foo[11]', 44573'%h' would expand to 'b.foo[11]', '%0' and '%1' would both expand to 44574'b', and '%a' would expand to '[11]'. 44575 44576 As in ordinary C, adjacent strings will be concatenated; this is 44577helpful when you have a complicated expression. 44578 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 44579 " ? TYPE_NEXT_VARIANT (&%h.generic)" 44580 " : TREE_CHAIN (&%h.generic)"))) 44581 44582 The available options are: 44583 44584'length ("EXPRESSION")' 44585 44586 There are two places the type machinery will need to be explicitly 44587 told the length of an array of non-atomic objects. The first case 44588 is when a structure ends in a variable-length array, like this: 44589 struct GTY(()) rtvec_def { 44590 int num_elem; /* number of elements */ 44591 rtx GTY ((length ("%h.num_elem"))) elem[1]; 44592 }; 44593 44594 In this case, the 'length' option is used to override the specified 44595 array length (which should usually be '1'). The parameter of the 44596 option is a fragment of C code that calculates the length. 44597 44598 The second case is when a structure or a global variable contains a 44599 pointer to an array, like this: 44600 struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter; 44601 In this case, 'iter' has been allocated by writing something like 44602 x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse); 44603 and the 'collapse' provides the length of the field. 44604 44605 This second use of 'length' also works on global variables, like: 44606 static GTY((length("reg_known_value_size"))) rtx *reg_known_value; 44607 44608 Note that the 'length' option is only meant for use with arrays of 44609 non-atomic objects, that is, objects that contain pointers pointing 44610 to other GTY-managed objects. For other GC-allocated arrays and 44611 strings you should use 'atomic'. 44612 44613'skip' 44614 44615 If 'skip' is applied to a field, the type machinery will ignore it. 44616 This is somewhat dangerous; the only safe use is in a union when 44617 one field really isn't ever used. 44618 44619'for_user' 44620 44621 Use this to mark types that need to be marked by user gc routines, 44622 but are not refered to in a template argument. So if you have some 44623 user gc type T1 and a non user gc type T2 you can give T2 the 44624 for_user option so that the marking functions for T1 can call non 44625 mangled functions to mark T2. 44626 44627'desc ("EXPRESSION")' 44628'tag ("CONSTANT")' 44629'default' 44630 44631 The type machinery needs to be told which field of a 'union' is 44632 currently active. This is done by giving each field a constant 44633 'tag' value, and then specifying a discriminator using 'desc'. The 44634 value of the expression given by 'desc' is compared against each 44635 'tag' value, each of which should be different. If no 'tag' is 44636 matched, the field marked with 'default' is used if there is one, 44637 otherwise no field in the union will be marked. 44638 44639 In the 'desc' option, the "current structure" is the union that it 44640 discriminates. Use '%1' to mean the structure containing it. 44641 There are no escapes available to the 'tag' option, since it is a 44642 constant. 44643 44644 For example, 44645 struct GTY(()) tree_binding 44646 { 44647 struct tree_common common; 44648 union tree_binding_u { 44649 tree GTY ((tag ("0"))) scope; 44650 struct cp_binding_level * GTY ((tag ("1"))) level; 44651 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 44652 tree value; 44653 }; 44654 44655 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 44656 'struct tree_binding *' is presumed to be 0 or 1. If 1, the type 44657 mechanism will treat the field 'level' as being present and if 0, 44658 will treat the field 'scope' as being present. 44659 44660 The 'desc' and 'tag' options can also be used for inheritance to 44661 denote which subclass an instance is. See *note Inheritance and 44662 GTY:: for more information. 44663 44664'cache' 44665 44666 When the 'cache' option is applied to a global variable 44667 gt_cleare_cache is called on that variable between the mark and 44668 sweep phases of garbage collection. The gt_clear_cache function is 44669 free to mark blocks as used, or to clear pointers in the variable. 44670 44671'deletable' 44672 44673 'deletable', when applied to a global variable, indicates that when 44674 garbage collection runs, there's no need to mark anything pointed 44675 to by this variable, it can just be set to 'NULL' instead. This is 44676 used to keep a list of free structures around for re-use. 44677 44678'maybe_undef' 44679 44680 When applied to a field, 'maybe_undef' indicates that it's OK if 44681 the structure that this fields points to is never defined, so long 44682 as this field is always 'NULL'. This is used to avoid requiring 44683 backends to define certain optional structures. It doesn't work 44684 with language frontends. 44685 44686'nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 44687 44688 The type machinery expects all pointers to point to the start of an 44689 object. Sometimes for abstraction purposes it's convenient to have 44690 a pointer which points inside an object. So long as it's possible 44691 to convert the original object to and from the pointer, such 44692 pointers can still be used. TYPE is the type of the original 44693 object, the TO EXPRESSION returns the pointer given the original 44694 object, and the FROM EXPRESSION returns the original object given 44695 the pointer. The pointer will be available using the '%h' escape. 44696 44697'chain_next ("EXPRESSION")' 44698'chain_prev ("EXPRESSION")' 44699'chain_circular ("EXPRESSION")' 44700 44701 It's helpful for the type machinery to know if objects are often 44702 chained together in long lists; this lets it generate code that 44703 uses less stack space by iterating along the list instead of 44704 recursing down it. 'chain_next' is an expression for the next item 44705 in the list, 'chain_prev' is an expression for the previous item. 44706 For singly linked lists, use only 'chain_next'; for doubly linked 44707 lists, use both. The machinery requires that taking the next item 44708 of the previous item gives the original item. 'chain_circular' is 44709 similar to 'chain_next', but can be used for circular single linked 44710 lists. 44711 44712'reorder ("FUNCTION NAME")' 44713 44714 Some data structures depend on the relative ordering of pointers. 44715 If the precompiled header machinery needs to change that ordering, 44716 it will call the function referenced by the 'reorder' option, 44717 before changing the pointers in the object that's pointed to by the 44718 field the option applies to. The function must take four 44719 arguments, with the signature 44720 'void *, void *, gt_pointer_operator, void *'. The first parameter 44721 is a pointer to the structure that contains the object being 44722 updated, or the object itself if there is no containing structure. 44723 The second parameter is a cookie that should be ignored. The third 44724 parameter is a routine that, given a pointer, will update it to its 44725 correct new value. The fourth parameter is a cookie that must be 44726 passed to the second parameter. 44727 44728 PCH cannot handle data structures that depend on the absolute 44729 values of pointers. 'reorder' functions can be expensive. When 44730 possible, it is better to depend on properties of the data, like an 44731 ID number or the hash of a string instead. 44732 44733'atomic' 44734 44735 The 'atomic' option can only be used with pointers. It informs the 44736 GC machinery that the memory that the pointer points to does not 44737 contain any pointers, and hence it should be treated by the GC and 44738 PCH machinery as an "atomic" block of memory that does not need to 44739 be examined when scanning memory for pointers. In particular, the 44740 machinery will not scan that memory for pointers to mark them as 44741 reachable (when marking pointers for GC) or to relocate them (when 44742 writing a PCH file). 44743 44744 The 'atomic' option differs from the 'skip' option. 'atomic' keeps 44745 the memory under Garbage Collection, but makes the GC ignore the 44746 contents of the memory. 'skip' is more drastic in that it causes 44747 the pointer and the memory to be completely ignored by the Garbage 44748 Collector. So, memory marked as 'atomic' is automatically freed 44749 when no longer reachable, while memory marked as 'skip' is not. 44750 44751 The 'atomic' option must be used with great care, because all sorts 44752 of problem can occur if used incorrectly, that is, if the memory 44753 the pointer points to does actually contain a pointer. 44754 44755 Here is an example of how to use it: 44756 struct GTY(()) my_struct { 44757 int number_of_elements; 44758 unsigned int * GTY ((atomic)) elements; 44759 }; 44760 In this case, 'elements' is a pointer under GC, and the memory it 44761 points to needs to be allocated using the Garbage Collector, and 44762 will be freed automatically by the Garbage Collector when it is no 44763 longer referenced. But the memory that the pointer points to is an 44764 array of 'unsigned int' elements, and the GC must not try to scan 44765 it to find pointers to mark or relocate, which is why it is marked 44766 with the 'atomic' option. 44767 44768 Note that, currently, global variables cannot be marked with 44769 'atomic'; only fields of a struct can. This is a known limitation. 44770 It would be useful to be able to mark global pointers with 'atomic' 44771 to make the PCH machinery aware of them so that they are saved and 44772 restored correctly to PCH files. 44773 44774'special ("NAME")' 44775 44776 The 'special' option is used to mark types that have to be dealt 44777 with by special case machinery. The parameter is the name of the 44778 special case. See 'gengtype.c' for further details. Avoid adding 44779 new special cases unless there is no other alternative. 44780 44781'user' 44782 44783 The 'user' option indicates that the code to mark structure fields 44784 is completely handled by user-provided routines. See section *note 44785 User GC:: for details on what functions need to be provided. 44786 44787 44788File: gccint.info, Node: Inheritance and GTY, Next: User GC, Prev: GTY Options, Up: Type Information 44789 4479023.2 Support for inheritance 44791============================ 44792 44793gengtype has some support for simple class hierarchies. You can use 44794this to have gengtype autogenerate marking routines, provided: 44795 44796 * There must be a concrete base class, with a discriminator 44797 expression that can be used to identify which subclass an instance 44798 is. 44799 * Only single inheritance is used. 44800 * None of the classes within the hierarchy are templates. 44801 44802 If your class hierarchy does not fit in this pattern, you must use 44803*note User GC:: instead. 44804 44805 The base class and its discriminator must be identified using the 44806"desc" option. Each concrete subclass must use the "tag" option to 44807identify which value of the discriminator it corresponds to. 44808 44809 Every class in the hierarchy must have a 'GTY(())' marker, as gengtype 44810will only attempt to parse classes that have such a marker (1). 44811 44812 class GTY((desc("%h.kind"), tag("0"))) example_base 44813 { 44814 public: 44815 int kind; 44816 tree a; 44817 }; 44818 44819 class GTY((tag("1"))) some_subclass : public example_base 44820 { 44821 public: 44822 tree b; 44823 }; 44824 44825 class GTY((tag("2"))) some_other_subclass : public example_base 44826 { 44827 public: 44828 tree c; 44829 }; 44830 44831 The generated marking routines for the above will contain a "switch" on 44832"kind", visiting all appropriate fields. For example, if kind is 2, it 44833will cast to "some_other_subclass" and visit fields a, b, and c. 44834 44835 ---------- Footnotes ---------- 44836 44837 (1) Classes lacking such a marker will not be identified as being 44838part of the hierarchy, and so the marking routines will not handle them, 44839leading to a assertion failure within the marking routines due to an 44840unknown tag value (assuming that assertions are enabled). 44841 44842 44843File: gccint.info, Node: User GC, Next: GGC Roots, Prev: Inheritance and GTY, Up: Type Information 44844 4484523.3 Support for user-provided GC marking routines 44846================================================== 44847 44848The garbage collector supports types for which no automatic marking code 44849is generated. For these types, the user is required to provide three 44850functions: one to act as a marker for garbage collection, and two 44851functions to act as marker and pointer walker for pre-compiled headers. 44852 44853 Given a structure 'struct GTY((user)) my_struct', the following 44854functions should be defined to mark 'my_struct': 44855 44856 void gt_ggc_mx (my_struct *p) 44857 { 44858 /* This marks field 'fld'. */ 44859 gt_ggc_mx (p->fld); 44860 } 44861 44862 void gt_pch_nx (my_struct *p) 44863 { 44864 /* This marks field 'fld'. */ 44865 gt_pch_nx (tp->fld); 44866 } 44867 44868 void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie) 44869 { 44870 /* For every field 'fld', call the given pointer operator. */ 44871 op (&(tp->fld), cookie); 44872 } 44873 44874 In general, each marker 'M' should call 'M' for every pointer field in 44875the structure. Fields that are not allocated in GC or are not pointers 44876must be ignored. 44877 44878 For embedded lists (e.g., structures with a 'next' or 'prev' pointer), 44879the marker must follow the chain and mark every element in it. 44880 44881 Note that the rules for the pointer walker 'gt_pch_nx (my_struct *, 44882gt_pointer_operator, void *)' are slightly different. In this case, the 44883operation 'op' must be applied to the _address_ of every pointer field. 44884 4488523.3.1 User-provided marking routines for template types 44886-------------------------------------------------------- 44887 44888When a template type 'TP' is marked with 'GTY', all instances of that 44889type are considered user-provided types. This means that the individual 44890instances of 'TP' do not need to be marked with 'GTY'. The user needs 44891to provide template functions to mark all the fields of the type. 44892 44893 The following code snippets represent all the functions that need to be 44894provided. Note that type 'TP' may reference to more than one type. In 44895these snippets, there is only one type 'T', but there could be more. 44896 44897 template<typename T> 44898 void gt_ggc_mx (TP<T> *tp) 44899 { 44900 extern void gt_ggc_mx (T&); 44901 44902 /* This marks field 'fld' of type 'T'. */ 44903 gt_ggc_mx (tp->fld); 44904 } 44905 44906 template<typename T> 44907 void gt_pch_nx (TP<T> *tp) 44908 { 44909 extern void gt_pch_nx (T&); 44910 44911 /* This marks field 'fld' of type 'T'. */ 44912 gt_pch_nx (tp->fld); 44913 } 44914 44915 template<typename T> 44916 void gt_pch_nx (TP<T *> *tp, gt_pointer_operator op, void *cookie) 44917 { 44918 /* For every field 'fld' of 'tp' with type 'T *', call the given 44919 pointer operator. */ 44920 op (&(tp->fld), cookie); 44921 } 44922 44923 template<typename T> 44924 void gt_pch_nx (TP<T> *tp, gt_pointer_operator, void *cookie) 44925 { 44926 extern void gt_pch_nx (T *, gt_pointer_operator, void *); 44927 44928 /* For every field 'fld' of 'tp' with type 'T', call the pointer 44929 walker for all the fields of T. */ 44930 gt_pch_nx (&(tp->fld), op, cookie); 44931 } 44932 44933 Support for user-defined types is currently limited. The following 44934restrictions apply: 44935 44936 1. Type 'TP' and all the argument types 'T' must be marked with 'GTY'. 44937 44938 2. Type 'TP' can only have type names in its argument list. 44939 44940 3. The pointer walker functions are different for 'TP<T>' and 'TP<T 44941 *>'. In the case of 'TP<T>', references to 'T' must be handled by 44942 calling 'gt_pch_nx' (which will, in turn, walk all the pointers 44943 inside fields of 'T'). In the case of 'TP<T *>', references to 'T 44944 *' must be handled by calling the 'op' function on the address of 44945 the pointer (see the code snippets above). 44946 44947 44948File: gccint.info, Node: GGC Roots, Next: Files, Prev: User GC, Up: Type Information 44949 4495023.4 Marking Roots for the Garbage Collector 44951============================================ 44952 44953In addition to keeping track of types, the type machinery also locates 44954the global variables ("roots") that the garbage collector starts at. 44955Roots must be declared using one of the following syntaxes: 44956 44957 * 'extern GTY(([OPTIONS])) TYPE NAME;' 44958 * 'static GTY(([OPTIONS])) TYPE NAME;' 44959The syntax 44960 * 'GTY(([OPTIONS])) TYPE NAME;' 44961is _not_ accepted. There should be an 'extern' declaration of such a 44962variable in a header somewhere--mark that, not the definition. Or, if 44963the variable is only used in one file, make it 'static'. 44964 44965 44966File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information 44967 4496823.5 Source Files Containing Type Information 44969============================================= 44970 44971Whenever you add 'GTY' markers to a source file that previously had 44972none, or create a new source file containing 'GTY' markers, there are 44973three things you need to do: 44974 44975 1. You need to add the file to the list of source files the type 44976 machinery scans. There are four cases: 44977 44978 a. For a back-end file, this is usually done automatically; if 44979 not, you should add it to 'target_gtfiles' in the appropriate 44980 port's entries in 'config.gcc'. 44981 44982 b. For files shared by all front ends, add the filename to the 44983 'GTFILES' variable in 'Makefile.in'. 44984 44985 c. For files that are part of one front end, add the filename to 44986 the 'gtfiles' variable defined in the appropriate 44987 'config-lang.in'. Headers should appear before non-headers in 44988 this list. 44989 44990 d. For files that are part of some but not all front ends, add 44991 the filename to the 'gtfiles' variable of _all_ the front ends 44992 that use it. 44993 44994 2. If the file was a header file, you'll need to check that it's 44995 included in the right place to be visible to the generated files. 44996 For a back-end header file, this should be done automatically. For 44997 a front-end header file, it needs to be included by the same file 44998 that includes 'gtype-LANG.h'. For other header files, it needs to 44999 be included in 'gtype-desc.c', which is a generated file, so add it 45000 to 'ifiles' in 'open_base_file' in 'gengtype.c'. 45001 45002 For source files that aren't header files, the machinery will 45003 generate a header file that should be included in the source file 45004 you just changed. The file will be called 'gt-PATH.h' where PATH 45005 is the pathname relative to the 'gcc' directory with slashes 45006 replaced by -, so for example the header file to be included in 45007 'cp/parser.c' is called 'gt-cp-parser.c'. The generated header 45008 file should be included after everything else in the source file. 45009 Don't forget to mention this file as a dependency in the 45010 'Makefile'! 45011 45012 For language frontends, there is another file that needs to be included 45013somewhere. It will be called 'gtype-LANG.h', where LANG is the name of 45014the subdirectory the language is contained in. 45015 45016 Plugins can add additional root tables. Run the 'gengtype' utility in 45017plugin mode as 'gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C' 45018with your plugin files PLUGIN*.C using 'GTY' to generate the PLUGINOUT.H 45019file. The GCC build tree is needed to be present in that mode. 45020 45021 45022File: gccint.info, Node: Invoking the garbage collector, Next: Troubleshooting, Prev: Files, Up: Type Information 45023 4502423.6 How to invoke the garbage collector 45025======================================== 45026 45027The GCC garbage collector GGC is only invoked explicitly. In contrast 45028with many other garbage collectors, it is not implicitly invoked by 45029allocation routines when a lot of memory has been consumed. So the only 45030way to have GGC reclaim storage is to call the 'ggc_collect' function 45031explicitly. This call is an expensive operation, as it may have to scan 45032the entire heap. Beware that local variables (on the GCC call stack) 45033are not followed by such an invocation (as many other garbage collectors 45034do): you should reference all your data from static or external 'GTY'-ed 45035variables, and it is advised to call 'ggc_collect' with a shallow call 45036stack. The GGC is an exact mark and sweep garbage collector (so it does 45037not scan the call stack for pointers). In practice GCC passes don't 45038often call 'ggc_collect' themselves, because it is called by the pass 45039manager between passes. 45040 45041 At the time of the 'ggc_collect' call all pointers in the GC-marked 45042structures must be valid or 'NULL'. In practice this means that there 45043should not be uninitialized pointer fields in the structures even if 45044your code never reads or writes those fields at a particular instance. 45045One way to ensure this is to use cleared versions of allocators unless 45046all the fields are initialized manually immediately after allocation. 45047 45048 45049File: gccint.info, Node: Troubleshooting, Prev: Invoking the garbage collector, Up: Type Information 45050 4505123.7 Troubleshooting the garbage collector 45052========================================== 45053 45054With the current garbage collector implementation, most issues should 45055show up as GCC compilation errors. Some of the most commonly 45056encountered issues are described below. 45057 45058 * Gengtype does not produce allocators for a 'GTY'-marked type. 45059 Gengtype checks if there is at least one possible path from GC 45060 roots to at least one instance of each type before outputting 45061 allocators. If there is no such path, the 'GTY' markers will be 45062 ignored and no allocators will be output. Solve this by making 45063 sure that there exists at least one such path. If creating it is 45064 unfeasible or raises a "code smell", consider if you really must 45065 use GC for allocating such type. 45066 45067 * Link-time errors about undefined 'gt_ggc_r_foo_bar' and 45068 similarly-named symbols. Check if your 'foo_bar' source file has 45069 '#include "gt-foo_bar.h"' as its very last line. 45070 45071 45072File: gccint.info, Node: Plugins, Next: LTO, Prev: Type Information, Up: Top 45073 4507424 Plugins 45075********** 45076 45077GCC plugins are loadable modules that provide extra features to the 45078compiler. Like GCC itself they can be distributed in source and binary 45079forms. 45080 45081 GCC plugins provide developers with a rich subset of the GCC API to 45082allow them to extend GCC as they see fit. Whether it is writing an 45083additional optimization pass, transforming code, or analyzing 45084information, plugins can be quite useful. 45085 45086* Menu: 45087 45088* Plugins loading:: How can we load plugins. 45089* Plugin API:: The APIs for plugins. 45090* Plugins pass:: How a plugin interact with the pass manager. 45091* Plugins GC:: How a plugin Interact with GCC Garbage Collector. 45092* Plugins description:: Giving information about a plugin itself. 45093* Plugins attr:: Registering custom attributes or pragmas. 45094* Plugins recording:: Recording information about pass execution. 45095* Plugins gate:: Controlling which passes are being run. 45096* Plugins tracking:: Keeping track of available passes. 45097* Plugins building:: How can we build a plugin. 45098 45099 45100File: gccint.info, Node: Plugins loading, Next: Plugin API, Up: Plugins 45101 4510224.1 Loading Plugins 45103==================== 45104 45105Plugins are supported on platforms that support '-ldl -rdynamic' as well 45106as Windows/MinGW. They are loaded by the compiler using 'dlopen' or 45107equivalent and invoked at pre-determined locations in the compilation 45108process. 45109 45110 Plugins are loaded with 45111 45112 '-fplugin=/path/to/NAME.EXT' '-fplugin-arg-NAME-KEY1[=VALUE1]' 45113 45114 Where NAME is the plugin name and EXT is the platform-specific dynamic 45115library extension. It should be 'dll' on Windows/MinGW, 'dylib' on 45116Darwin/Mac OS X, and 'so' on all other platforms. The plugin arguments 45117are parsed by GCC and passed to respective plugins as key-value pairs. 45118Multiple plugins can be invoked by specifying multiple '-fplugin' 45119arguments. 45120 45121 A plugin can be simply given by its short name (no dots or slashes). 45122When simply passing '-fplugin=NAME', the plugin is loaded from the 45123'plugin' directory, so '-fplugin=NAME' is the same as '-fplugin=`gcc 45124-print-file-name=plugin`/NAME.EXT', using backquote shell syntax to 45125query the 'plugin' directory. 45126 45127 45128File: gccint.info, Node: Plugin API, Next: Plugins pass, Prev: Plugins loading, Up: Plugins 45129 4513024.2 Plugin API 45131=============== 45132 45133Plugins are activated by the compiler at specific events as defined in 45134'gcc-plugin.h'. For each event of interest, the plugin should call 45135'register_callback' specifying the name of the event and address of the 45136callback function that will handle that event. 45137 45138 The header 'gcc-plugin.h' must be the first gcc header to be included. 45139 4514024.2.1 Plugin license check 45141--------------------------- 45142 45143Every plugin should define the global symbol 'plugin_is_GPL_compatible' 45144to assert that it has been licensed under a GPL-compatible license. If 45145this symbol does not exist, the compiler will emit a fatal error and 45146exit with the error message: 45147 45148 fatal error: plugin NAME is not licensed under a GPL-compatible license 45149 NAME: undefined symbol: plugin_is_GPL_compatible 45150 compilation terminated 45151 45152 The declared type of the symbol should be int, to match a forward 45153declaration in 'gcc-plugin.h' that suppresses C++ mangling. It does not 45154need to be in any allocated section, though. The compiler merely 45155asserts that the symbol exists in the global scope. Something like this 45156is enough: 45157 45158 int plugin_is_GPL_compatible; 45159 4516024.2.2 Plugin initialization 45161---------------------------- 45162 45163Every plugin should export a function called 'plugin_init' that is 45164called right after the plugin is loaded. This function is responsible 45165for registering all the callbacks required by the plugin and do any 45166other required initialization. 45167 45168 This function is called from 'compile_file' right before invoking the 45169parser. The arguments to 'plugin_init' are: 45170 45171 * 'plugin_info': Plugin invocation information. 45172 * 'version': GCC version. 45173 45174 The 'plugin_info' struct is defined as follows: 45175 45176 struct plugin_name_args 45177 { 45178 char *base_name; /* Short name of the plugin 45179 (filename without .so suffix). */ 45180 const char *full_name; /* Path to the plugin as specified with 45181 -fplugin=. */ 45182 int argc; /* Number of arguments specified with 45183 -fplugin-arg-.... */ 45184 struct plugin_argument *argv; /* Array of ARGC key-value pairs. */ 45185 const char *version; /* Version string provided by plugin. */ 45186 const char *help; /* Help string provided by plugin. */ 45187 } 45188 45189 If initialization fails, 'plugin_init' must return a non-zero value. 45190Otherwise, it should return 0. 45191 45192 The version of the GCC compiler loading the plugin is described by the 45193following structure: 45194 45195 struct plugin_gcc_version 45196 { 45197 const char *basever; 45198 const char *datestamp; 45199 const char *devphase; 45200 const char *revision; 45201 const char *configuration_arguments; 45202 }; 45203 45204 The function 'plugin_default_version_check' takes two pointers to such 45205structure and compare them field by field. It can be used by the 45206plugin's 'plugin_init' function. 45207 45208 The version of GCC used to compile the plugin can be found in the 45209symbol 'gcc_version' defined in the header 'plugin-version.h'. The 45210recommended version check to perform looks like 45211 45212 #include "plugin-version.h" 45213 ... 45214 45215 int 45216 plugin_init (struct plugin_name_args *plugin_info, 45217 struct plugin_gcc_version *version) 45218 { 45219 if (!plugin_default_version_check (version, &gcc_version)) 45220 return 1; 45221 45222 } 45223 45224 but you can also check the individual fields if you want a less strict 45225check. 45226 4522724.2.3 Plugin callbacks 45228----------------------- 45229 45230Callback functions have the following prototype: 45231 45232 /* The prototype for a plugin callback function. 45233 gcc_data - event-specific data provided by GCC 45234 user_data - plugin-specific data provided by the plug-in. */ 45235 typedef void (*plugin_callback_func)(void *gcc_data, void *user_data); 45236 45237 Callbacks can be invoked at the following pre-determined events: 45238 45239 enum plugin_event 45240 { 45241 PLUGIN_START_PARSE_FUNCTION, /* Called before parsing the body of a function. */ 45242 PLUGIN_FINISH_PARSE_FUNCTION, /* After finishing parsing a function. */ 45243 PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */ 45244 PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */ 45245 PLUGIN_FINISH_DECL, /* After finishing parsing a declaration. */ 45246 PLUGIN_FINISH_UNIT, /* Useful for summary processing. */ 45247 PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */ 45248 PLUGIN_FINISH, /* Called before GCC exits. */ 45249 PLUGIN_INFO, /* Information about the plugin. */ 45250 PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */ 45251 PLUGIN_GGC_MARKING, /* Extend the GGC marking. */ 45252 PLUGIN_GGC_END, /* Called at end of GGC. */ 45253 PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */ 45254 PLUGIN_ATTRIBUTES, /* Called during attribute registration */ 45255 PLUGIN_START_UNIT, /* Called before processing a translation unit. */ 45256 PLUGIN_PRAGMAS, /* Called during pragma registration. */ 45257 /* Called before first pass from all_passes. */ 45258 PLUGIN_ALL_PASSES_START, 45259 /* Called after last pass from all_passes. */ 45260 PLUGIN_ALL_PASSES_END, 45261 /* Called before first ipa pass. */ 45262 PLUGIN_ALL_IPA_PASSES_START, 45263 /* Called after last ipa pass. */ 45264 PLUGIN_ALL_IPA_PASSES_END, 45265 /* Allows to override pass gate decision for current_pass. */ 45266 PLUGIN_OVERRIDE_GATE, 45267 /* Called before executing a pass. */ 45268 PLUGIN_PASS_EXECUTION, 45269 /* Called before executing subpasses of a GIMPLE_PASS in 45270 execute_ipa_pass_list. */ 45271 PLUGIN_EARLY_GIMPLE_PASSES_START, 45272 /* Called after executing subpasses of a GIMPLE_PASS in 45273 execute_ipa_pass_list. */ 45274 PLUGIN_EARLY_GIMPLE_PASSES_END, 45275 /* Called when a pass is first instantiated. */ 45276 PLUGIN_NEW_PASS, 45277 /* Called when a file is #include-d or given via the #line directive. 45278 This could happen many times. The event data is the included file path, 45279 as a const char* pointer. */ 45280 PLUGIN_INCLUDE_FILE, 45281 45282 /* Called when -fanalyzer starts. The event data is an 45283 ana::plugin_analyzer_init_iface *. */ 45284 PLUGIN_ANALYZER_INIT, 45285 45286 PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback 45287 array. */ 45288 }; 45289 45290 In addition, plugins can also look up the enumerator of a named event, 45291and / or generate new events dynamically, by calling the function 45292'get_named_event_id'. 45293 45294 To register a callback, the plugin calls 'register_callback' with the 45295arguments: 45296 45297 * 'char *name': Plugin name. 45298 * 'int event': The event code. 45299 * 'plugin_callback_func callback': The function that handles 'event'. 45300 * 'void *user_data': Pointer to plugin-specific data. 45301 45302 For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, and 45303PLUGIN_REGISTER_GGC_ROOTS pseudo-events the 'callback' should be null, 45304and the 'user_data' is specific. 45305 45306 When the PLUGIN_PRAGMAS event is triggered (with a null pointer as data 45307from GCC), plugins may register their own pragmas. Notice that pragmas 45308are not available from 'lto1', so plugins used with '-flto' option to 45309GCC during link-time optimization cannot use pragmas and do not even see 45310functions like 'c_register_pragma' or 'pragma_lex'. 45311 45312 The PLUGIN_INCLUDE_FILE event, with a 'const char*' file path as GCC 45313data, is triggered for processing of '#include' or '#line' directives. 45314 45315 The PLUGIN_FINISH event is the last time that plugins can call GCC 45316functions, notably emit diagnostics with 'warning', 'error' etc. 45317 45318 45319File: gccint.info, Node: Plugins pass, Next: Plugins GC, Prev: Plugin API, Up: Plugins 45320 4532124.3 Interacting with the pass manager 45322====================================== 45323 45324There needs to be a way to add/reorder/remove passes dynamically. This 45325is useful for both analysis plugins (plugging in after a certain pass 45326such as CFG or an IPA pass) and optimization plugins. 45327 45328 Basic support for inserting new passes or replacing existing passes is 45329provided. A plugin registers a new pass with GCC by calling 45330'register_callback' with the 'PLUGIN_PASS_MANAGER_SETUP' event and a 45331pointer to a 'struct register_pass_info' object defined as follows 45332 45333 enum pass_positioning_ops 45334 { 45335 PASS_POS_INSERT_AFTER, // Insert after the reference pass. 45336 PASS_POS_INSERT_BEFORE, // Insert before the reference pass. 45337 PASS_POS_REPLACE // Replace the reference pass. 45338 }; 45339 45340 struct register_pass_info 45341 { 45342 struct opt_pass *pass; /* New pass provided by the plugin. */ 45343 const char *reference_pass_name; /* Name of the reference pass for hooking 45344 up the new pass. */ 45345 int ref_pass_instance_number; /* Insert the pass at the specified 45346 instance number of the reference pass. */ 45347 /* Do it for every instance if it is 0. */ 45348 enum pass_positioning_ops pos_op; /* how to insert the new pass. */ 45349 }; 45350 45351 45352 /* Sample plugin code that registers a new pass. */ 45353 int 45354 plugin_init (struct plugin_name_args *plugin_info, 45355 struct plugin_gcc_version *version) 45356 { 45357 struct register_pass_info pass_info; 45358 45359 ... 45360 45361 /* Code to fill in the pass_info object with new pass information. */ 45362 45363 ... 45364 45365 /* Register the new pass. */ 45366 register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info); 45367 45368 ... 45369 } 45370 45371 45372File: gccint.info, Node: Plugins GC, Next: Plugins description, Prev: Plugins pass, Up: Plugins 45373 4537424.4 Interacting with the GCC Garbage Collector 45375=============================================== 45376 45377Some plugins may want to be informed when GGC (the GCC Garbage 45378Collector) is running. They can register callbacks for the 45379'PLUGIN_GGC_START' and 'PLUGIN_GGC_END' events (for which the callback 45380is called with a null 'gcc_data') to be notified of the start or end of 45381the GCC garbage collection. 45382 45383 Some plugins may need to have GGC mark additional data. This can be 45384done by registering a callback (called with a null 'gcc_data') for the 45385'PLUGIN_GGC_MARKING' event. Such callbacks can call the 'ggc_set_mark' 45386routine, preferably through the 'ggc_mark' macro (and conversely, these 45387routines should usually not be used in plugins outside of the 45388'PLUGIN_GGC_MARKING' event). Plugins that wish to hold weak references 45389to gc data may also use this event to drop weak references when the 45390object is about to be collected. The 'ggc_marked_p' function can be 45391used to tell if an object is marked, or is about to be collected. The 45392'gt_clear_cache' overloads which some types define may also be of use in 45393managing weak references. 45394 45395 Some plugins may need to add extra GGC root tables, e.g. to handle 45396their own 'GTY'-ed data. This can be done with the 45397'PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the 45398extra root table (of type 'struct ggc_root_tab*') as 'user_data'. 45399Running the 'gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility 45400generates these extra root tables. 45401 45402 You should understand the details of memory management inside GCC 45403before using 'PLUGIN_GGC_MARKING' or 'PLUGIN_REGISTER_GGC_ROOTS'. 45404 45405 45406File: gccint.info, Node: Plugins description, Next: Plugins attr, Prev: Plugins GC, Up: Plugins 45407 4540824.5 Giving information about a plugin 45409====================================== 45410 45411A plugin should give some information to the user about itself. This 45412uses the following structure: 45413 45414 struct plugin_info 45415 { 45416 const char *version; 45417 const char *help; 45418 }; 45419 45420 Such a structure is passed as the 'user_data' by the plugin's init 45421routine using 'register_callback' with the 'PLUGIN_INFO' pseudo-event 45422and a null callback. 45423 45424 45425File: gccint.info, Node: Plugins attr, Next: Plugins recording, Prev: Plugins description, Up: Plugins 45426 4542724.6 Registering custom attributes or pragmas 45428============================================= 45429 45430For analysis (or other) purposes it is useful to be able to add custom 45431attributes or pragmas. 45432 45433 The 'PLUGIN_ATTRIBUTES' callback is called during attribute 45434registration. Use the 'register_attribute' function to register custom 45435attributes. 45436 45437 /* Attribute handler callback */ 45438 static tree 45439 handle_user_attribute (tree *node, tree name, tree args, 45440 int flags, bool *no_add_attrs) 45441 { 45442 return NULL_TREE; 45443 } 45444 45445 /* Attribute definition */ 45446 static struct attribute_spec user_attr = 45447 { "user", 1, 1, false, false, false, false, handle_user_attribute, NULL }; 45448 45449 /* Plugin callback called during attribute registration. 45450 Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL) 45451 */ 45452 static void 45453 register_attributes (void *event_data, void *data) 45454 { 45455 warning (0, G_("Callback to register attributes")); 45456 register_attribute (&user_attr); 45457 } 45458 45459 45460 The PLUGIN_PRAGMAS callback is called once during pragmas registration. 45461Use the 'c_register_pragma', 'c_register_pragma_with_data', 45462'c_register_pragma_with_expansion', 45463'c_register_pragma_with_expansion_and_data' functions to register custom 45464pragmas and their handlers (which often want to call 'pragma_lex') from 45465'c-family/c-pragma.h'. 45466 45467 /* Plugin callback called during pragmas registration. Registered with 45468 register_callback (plugin_name, PLUGIN_PRAGMAS, 45469 register_my_pragma, NULL); 45470 */ 45471 static void 45472 register_my_pragma (void *event_data, void *data) 45473 { 45474 warning (0, G_("Callback to register pragmas")); 45475 c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello); 45476 } 45477 45478 It is suggested to pass '"GCCPLUGIN"' (or a short name identifying your 45479plugin) as the "space" argument of your pragma. 45480 45481 Pragmas registered with 'c_register_pragma_with_expansion' or 45482'c_register_pragma_with_expansion_and_data' support preprocessor 45483expansions. For example: 45484 45485 #define NUMBER 10 45486 #pragma GCCPLUGIN foothreshold (NUMBER) 45487 45488 45489File: gccint.info, Node: Plugins recording, Next: Plugins gate, Prev: Plugins attr, Up: Plugins 45490 4549124.7 Recording information about pass execution 45492=============================================== 45493 45494The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass 45495(the same as current_pass) as 'gcc_data' to the callback. You can also 45496inspect cfun to find out about which function this pass is executed for. 45497Note that this event will only be invoked if the gate check (if 45498applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use 45499other hooks, like 'PLUGIN_ALL_PASSES_START', 'PLUGIN_ALL_PASSES_END', 45500'PLUGIN_ALL_IPA_PASSES_START', 'PLUGIN_ALL_IPA_PASSES_END', 45501'PLUGIN_EARLY_GIMPLE_PASSES_START', and/or 45502'PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your 45503plugin(s) in order to get context for the pass execution. 45504 45505 45506File: gccint.info, Node: Plugins gate, Next: Plugins tracking, Prev: Plugins recording, Up: Plugins 45507 4550824.8 Controlling which passes are being run 45509=========================================== 45510 45511After the original gate function for a pass is called, its result - the 45512gate status - is stored as an integer. Then the event 45513'PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in 45514the 'gcc_data' parameter to the callback function. A nonzero value of 45515the gate status means that the pass is to be executed. You can both 45516read and write the gate status via the passed pointer. 45517 45518 45519File: gccint.info, Node: Plugins tracking, Next: Plugins building, Prev: Plugins gate, Up: Plugins 45520 4552124.9 Keeping track of available passes 45522====================================== 45523 45524When your plugin is loaded, you can inspect the various pass lists to 45525determine what passes are available. However, other plugins might add 45526new passes. Also, future changes to GCC might cause generic passes to 45527be added after plugin loading. When a pass is first added to one of the 45528pass lists, the event 'PLUGIN_NEW_PASS' is invoked, with the callback 45529parameter 'gcc_data' pointing to the new pass. 45530 45531 45532File: gccint.info, Node: Plugins building, Prev: Plugins tracking, Up: Plugins 45533 4553424.10 Building GCC plugins 45535========================== 45536 45537If plugins are enabled, GCC installs the headers needed to build a 45538plugin (somewhere in the installation tree, e.g. under '/usr/local'). 45539In particular a 'plugin/include' directory is installed, containing all 45540the header files needed to build plugins. 45541 45542 On most systems, you can query this 'plugin' directory by invoking 'gcc 45543-print-file-name=plugin' (replace if needed 'gcc' with the appropriate 45544program path). 45545 45546 Inside plugins, this 'plugin' directory name can be queried by calling 45547'default_plugin_dir_name ()'. 45548 45549 Plugins may know, when they are compiled, the GCC version for which 45550'plugin-version.h' is provided. The constant macros 45551'GCCPLUGIN_VERSION_MAJOR', 'GCCPLUGIN_VERSION_MINOR', 45552'GCCPLUGIN_VERSION_PATCHLEVEL', 'GCCPLUGIN_VERSION' are integer numbers, 45553so a plugin could ensure it is built for GCC 4.7 with 45554 #if GCCPLUGIN_VERSION != 4007 45555 #error this GCC plugin is for GCC 4.7 45556 #endif 45557 45558 The following GNU Makefile excerpt shows how to build a simple plugin: 45559 45560 HOST_GCC=g++ 45561 TARGET_GCC=gcc 45562 PLUGIN_SOURCE_FILES= plugin1.c plugin2.cc 45563 GCCPLUGINS_DIR:= $(shell $(TARGET_GCC) -print-file-name=plugin) 45564 CXXFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -fno-rtti -O2 45565 45566 plugin.so: $(PLUGIN_SOURCE_FILES) 45567 $(HOST_GCC) -shared $(CXXFLAGS) $^ -o $@ 45568 45569 A single source file plugin may be built with 'g++ -I`gcc 45570-print-file-name=plugin`/include -fPIC -shared -fno-rtti -O2 plugin.c -o 45571plugin.so', using backquote shell syntax to query the 'plugin' 45572directory. 45573 45574 Plugin support on Windows/MinGW has a number of limitations and 45575additional requirements. When building a plugin on Windows we have to 45576link an import library for the corresponding backend executable, for 45577example, 'cc1.exe', 'cc1plus.exe', etc., in order to gain access to the 45578symbols provided by GCC. This means that on Windows a plugin is 45579language-specific, for example, for C, C++, etc. If you wish to use 45580your plugin with multiple languages, then you will need to build 45581multiple plugin libraries and either instruct your users on how to load 45582the correct version or provide a compiler wrapper that does this 45583automatically. 45584 45585 Additionally, on Windows the plugin library has to export the 45586'plugin_is_GPL_compatible' and 'plugin_init' symbols. If you do not 45587wish to modify the source code of your plugin, then you can use the 45588'-Wl,--export-all-symbols' option or provide a suitable DEF file. 45589Alternatively, you can export just these two symbols by decorating them 45590with '__declspec(dllexport)', for example: 45591 45592 #ifdef _WIN32 45593 __declspec(dllexport) 45594 #endif 45595 int plugin_is_GPL_compatible; 45596 45597 #ifdef _WIN32 45598 __declspec(dllexport) 45599 #endif 45600 int plugin_init (plugin_name_args *, plugin_gcc_version *) 45601 45602 The import libraries are installed into the 'plugin' directory and 45603their names are derived by appending the '.a' extension to the backend 45604executable names, for example, 'cc1.exe.a', 'cc1plus.exe.a', etc. The 45605following command line shows how to build the single source file plugin 45606on Windows to be used with the C++ compiler: 45607 45608 g++ -I`gcc -print-file-name=plugin`/include -shared -Wl,--export-all-symbols \ 45609 -o plugin.dll plugin.c `gcc -print-file-name=plugin`/cc1plus.exe.a 45610 45611 When a plugin needs to use 'gengtype', be sure that both 'gengtype' and 45612'gtype.state' have the same version as the GCC for which the plugin is 45613built. 45614 45615 45616File: gccint.info, Node: LTO, Next: Match and Simplify, Prev: Plugins, Up: Top 45617 4561825 Link Time Optimization 45619************************* 45620 45621Link Time Optimization (LTO) gives GCC the capability of dumping its 45622internal representation (GIMPLE) to disk, so that all the different 45623compilation units that make up a single executable can be optimized as a 45624single module. This expands the scope of inter-procedural optimizations 45625to encompass the whole program (or, rather, everything that is visible 45626at link time). 45627 45628* Menu: 45629 45630* LTO Overview:: Overview of LTO. 45631* LTO object file layout:: LTO file sections in ELF. 45632* IPA:: Using summary information in IPA passes. 45633* WHOPR:: Whole program assumptions, 45634 linker plugin and symbol visibilities. 45635* Internal flags:: Internal flags controlling 'lto1'. 45636 45637 45638File: gccint.info, Node: LTO Overview, Next: LTO object file layout, Up: LTO 45639 4564025.1 Design Overview 45641==================== 45642 45643Link time optimization is implemented as a GCC front end for a bytecode 45644representation of GIMPLE that is emitted in special sections of '.o' 45645files. Currently, LTO support is enabled in most ELF-based systems, as 45646well as darwin, cygwin and mingw systems. 45647 45648 Since GIMPLE bytecode is saved alongside final object code, object 45649files generated with LTO support are larger than regular object files. 45650This "fat" object format makes it easy to integrate LTO into existing 45651build systems, as one can, for instance, produce archives of the files. 45652Additionally, one might be able to ship one set of fat objects which 45653could be used both for development and the production of optimized 45654builds. A, perhaps surprising, side effect of this feature is that any 45655mistake in the toolchain leads to LTO information not being used (e.g. 45656an older 'libtool' calling 'ld' directly). This is both an advantage, 45657as the system is more robust, and a disadvantage, as the user is not 45658informed that the optimization has been disabled. 45659 45660 The current implementation only produces "fat" objects, effectively 45661doubling compilation time and increasing file sizes up to 5x the 45662original size. This hides the problem that some tools, such as 'ar' and 45663'nm', need to understand symbol tables of LTO sections. These tools 45664were extended to use the plugin infrastructure, and with these problems 45665solved, GCC will also support "slim" objects consisting of the 45666intermediate code alone. 45667 45668 At the highest level, LTO splits the compiler in two. The first half 45669(the "writer") produces a streaming representation of all the internal 45670data structures needed to optimize and generate code. This includes 45671declarations, types, the callgraph and the GIMPLE representation of 45672function bodies. 45673 45674 When '-flto' is given during compilation of a source file, the pass 45675manager executes all the passes in 'all_lto_gen_passes'. Currently, 45676this phase is composed of two IPA passes: 45677 45678 * 'pass_ipa_lto_gimple_out' This pass executes the function 45679 'lto_output' in 'lto-streamer-out.c', which traverses the call 45680 graph encoding every reachable declaration, type and function. 45681 This generates a memory representation of all the file sections 45682 described below. 45683 45684 * 'pass_ipa_lto_finish_out' This pass executes the function 45685 'produce_asm_for_decls' in 'lto-streamer-out.c', which takes the 45686 memory image built in the previous pass and encodes it in the 45687 corresponding ELF file sections. 45688 45689 The second half of LTO support is the "reader". This is implemented as 45690the GCC front end 'lto1' in 'lto/lto.c'. When 'collect2' detects a link 45691set of '.o'/'.a' files with LTO information and the '-flto' is enabled, 45692it invokes 'lto1' which reads the set of files and aggregates them into 45693a single translation unit for optimization. The main entry point for 45694the reader is 'lto/lto.c':'lto_main'. 45695 4569625.1.1 LTO modes of operation 45697----------------------------- 45698 45699One of the main goals of the GCC link-time infrastructure was to allow 45700effective compilation of large programs. For this reason GCC implements 45701two link-time compilation modes. 45702 45703 1. _LTO mode_, in which the whole program is read into the compiler at 45704 link-time and optimized in a similar way as if it were a single 45705 source-level compilation unit. 45706 45707 2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs 45708 and/or a distributed compilation environment to quickly link large 45709 applications. WHOPR stands for WHOle Program optimizeR (not to be 45710 confused with the semantics of '-fwhole-program'). It partitions 45711 the aggregated callgraph from many different '.o' files and 45712 distributes the compilation of the sub-graphs to different CPUs. 45713 45714 Note that distributed compilation is not implemented yet, but since 45715 the parallelism is facilitated via generating a 'Makefile', it 45716 would be easy to implement. 45717 45718 WHOPR splits LTO into three main stages: 45719 1. Local generation (LGEN) This stage executes in parallel. Every 45720 file in the program is compiled into the intermediate language and 45721 packaged together with the local call-graph and summary 45722 information. This stage is the same for both the LTO and WHOPR 45723 compilation mode. 45724 45725 2. Whole Program Analysis (WPA) WPA is performed sequentially. The 45726 global call-graph is generated, and a global analysis procedure 45727 makes transformation decisions. The global call-graph is 45728 partitioned to facilitate parallel optimization during phase 3. 45729 The results of the WPA stage are stored into new object files which 45730 contain the partitions of program expressed in the intermediate 45731 language and the optimization decisions. 45732 45733 3. Local transformations (LTRANS) This stage executes in parallel. 45734 All the decisions made during phase 2 are implemented locally in 45735 each partitioned object file, and the final object code is 45736 generated. Optimizations which cannot be decided efficiently 45737 during the phase 2 may be performed on the local call-graph 45738 partitions. 45739 45740 WHOPR can be seen as an extension of the usual LTO mode of compilation. 45741In LTO, WPA and LTRANS are executed within a single execution of the 45742compiler, after the whole program has been read into memory. 45743 45744 When compiling in WHOPR mode, the callgraph is partitioned during the 45745WPA stage. The whole program is split into a given number of partitions 45746of roughly the same size. The compiler tries to minimize the number of 45747references which cross partition boundaries. The main advantage of 45748WHOPR is to allow the parallel execution of LTRANS stages, which are the 45749most time-consuming part of the compilation process. Additionally, it 45750avoids the need to load the whole program into memory. 45751 45752 45753File: gccint.info, Node: LTO object file layout, Next: IPA, Prev: LTO Overview, Up: LTO 45754 4575525.2 LTO file sections 45756====================== 45757 45758LTO information is stored in several ELF sections inside object files. 45759Data structures and enum codes for sections are defined in 45760'lto-streamer.h'. 45761 45762 These sections are emitted from 'lto-streamer-out.c' and mapped in all 45763at once from 'lto/lto.c':'lto_file_read'. The individual functions 45764dealing with the reading/writing of each section are described below. 45765 45766 * Command line options ('.gnu.lto_.opts') 45767 45768 This section contains the command line options used to generate the 45769 object files. This is used at link time to determine the 45770 optimization level and other settings when they are not explicitly 45771 specified at the linker command line. 45772 45773 Currently, GCC does not support combining LTO object files compiled 45774 with different set of the command line options into a single 45775 binary. At link time, the options given on the command line and 45776 the options saved on all the files in a link-time set are applied 45777 globally. No attempt is made at validating the combination of 45778 flags (other than the usual validation done by option processing). 45779 This is implemented in 'lto/lto.c':'lto_read_all_file_options'. 45780 45781 * Symbol table ('.gnu.lto_.symtab') 45782 45783 This table replaces the ELF symbol table for functions and 45784 variables represented in the LTO IL. Symbols used and exported by 45785 the optimized assembly code of "fat" objects might not match the 45786 ones used and exported by the intermediate code. This table is 45787 necessary because the intermediate code is less optimized and thus 45788 requires a separate symbol table. 45789 45790 Additionally, the binary code in the "fat" object will lack a call 45791 to a function, since the call was optimized out at compilation time 45792 after the intermediate language was streamed out. In some special 45793 cases, the same optimization may not happen during link-time 45794 optimization. This would lead to an undefined symbol if only one 45795 symbol table was used. 45796 45797 The symbol table is emitted in 45798 'lto-streamer-out.c':'produce_symtab'. 45799 45800 * Global declarations and types ('.gnu.lto_.decls') 45801 45802 This section contains an intermediate language dump of all 45803 declarations and types required to represent the callgraph, static 45804 variables and top-level debug info. 45805 45806 The contents of this section are emitted in 45807 'lto-streamer-out.c':'produce_asm_for_decls'. Types and symbols 45808 are emitted in a topological order that preserves the sharing of 45809 pointers when the file is read back in 45810 ('lto.c':'read_cgraph_and_symbols'). 45811 45812 * The callgraph ('.gnu.lto_.cgraph') 45813 45814 This section contains the basic data structure used by the GCC 45815 inter-procedural optimization infrastructure. This section stores 45816 an annotated multi-graph which represents the functions and call 45817 sites as well as the variables, aliases and top-level 'asm' 45818 statements. 45819 45820 This section is emitted in 'lto-streamer-out.c':'output_cgraph' and 45821 read in 'lto-cgraph.c':'input_cgraph'. 45822 45823 * IPA references ('.gnu.lto_.refs') 45824 45825 This section contains references between function and static 45826 variables. It is emitted by 'lto-cgraph.c':'output_refs' and read 45827 by 'lto-cgraph.c':'input_refs'. 45828 45829 * Function bodies ('.gnu.lto_.function_body.<name>') 45830 45831 This section contains function bodies in the intermediate language 45832 representation. Every function body is in a separate section to 45833 allow copying of the section independently to different object 45834 files or reading the function on demand. 45835 45836 Functions are emitted in 'lto-streamer-out.c':'output_function' and 45837 read in 'lto-streamer-in.c':'input_function'. 45838 45839 * Static variable initializers ('.gnu.lto_.vars') 45840 45841 This section contains all the symbols in the global variable pool. 45842 It is emitted by 'lto-cgraph.c':'output_varpool' and read in 45843 'lto-cgraph.c':'input_cgraph'. 45844 45845 * Summaries and optimization summaries used by IPA passes 45846 ('.gnu.lto_.<xxx>', where '<xxx>' is one of 'jmpfuncs', 'pureconst' 45847 or 'reference') 45848 45849 These sections are used by IPA passes that need to emit summary 45850 information during LTO generation to be read and aggregated at link 45851 time. Each pass is responsible for implementing two pass manager 45852 hooks: one for writing the summary and another for reading it in. 45853 The format of these sections is entirely up to each individual 45854 pass. The only requirement is that the writer and reader hooks 45855 agree on the format. 45856 45857 45858File: gccint.info, Node: IPA, Next: WHOPR, Prev: LTO object file layout, Up: LTO 45859 4586025.3 Using summary information in IPA passes 45861============================================ 45862 45863Programs are represented internally as a _callgraph_ (a multi-graph 45864where nodes are functions and edges are call sites) and a _varpool_ (a 45865list of static and external variables in the program). 45866 45867 The inter-procedural optimization is organized as a sequence of 45868individual passes, which operate on the callgraph and the varpool. To 45869make the implementation of WHOPR possible, every inter-procedural 45870optimization pass is split into several stages that are executed at 45871different times during WHOPR compilation: 45872 45873 * LGEN time 45874 1. _Generate summary_ ('generate_summary' in 'struct 45875 ipa_opt_pass_d'). This stage analyzes every function body and 45876 variable initializer is examined and stores relevant 45877 information into a pass-specific data structure. 45878 45879 2. _Write summary_ ('write_summary' in 'struct ipa_opt_pass_d'). 45880 This stage writes all the pass-specific information generated 45881 by 'generate_summary'. Summaries go into their own 45882 'LTO_section_*' sections that have to be declared in 45883 'lto-streamer.h':'enum lto_section_type'. A new section is 45884 created by calling 'create_output_block' and data can be 45885 written using the 'lto_output_*' routines. 45886 45887 * WPA time 45888 1. _Read summary_ ('read_summary' in 'struct ipa_opt_pass_d'). 45889 This stage reads all the pass-specific information in exactly 45890 the same order that it was written by 'write_summary'. 45891 45892 2. _Execute_ ('execute' in 'struct opt_pass'). This performs 45893 inter-procedural propagation. This must be done without 45894 actual access to the individual function bodies or variable 45895 initializers. Typically, this results in a transitive closure 45896 operation over the summary information of all the nodes in the 45897 callgraph. 45898 45899 3. _Write optimization summary_ ('write_optimization_summary' in 45900 'struct ipa_opt_pass_d'). This writes the result of the 45901 inter-procedural propagation into the object file. This can 45902 use the same data structures and helper routines used in 45903 'write_summary'. 45904 45905 * LTRANS time 45906 1. _Read optimization summary_ ('read_optimization_summary' in 45907 'struct ipa_opt_pass_d'). The counterpart to 45908 'write_optimization_summary'. This reads the interprocedural 45909 optimization decisions in exactly the same format emitted by 45910 'write_optimization_summary'. 45911 45912 2. _Transform_ ('function_transform' and 'variable_transform' in 45913 'struct ipa_opt_pass_d'). The actual function bodies and 45914 variable initializers are updated based on the information 45915 passed down from the _Execute_ stage. 45916 45917 The implementation of the inter-procedural passes are shared between 45918LTO, WHOPR and classic non-LTO compilation. 45919 45920 * During the traditional file-by-file mode every pass executes its 45921 own _Generate summary_, _Execute_, and _Transform_ stages within 45922 the single execution context of the compiler. 45923 45924 * In LTO compilation mode, every pass uses _Generate summary_ and 45925 _Write summary_ stages at compilation time, while the _Read 45926 summary_, _Execute_, and _Transform_ stages are executed at link 45927 time. 45928 45929 * In WHOPR mode all stages are used. 45930 45931 To simplify development, the GCC pass manager differentiates between 45932normal inter-procedural passes (*note Regular IPA passes::), small 45933inter-procedural passes (*note Small IPA passes::) and late 45934inter-procedural passes (*note Late IPA passes::). A small or late IPA 45935pass ('SIMPLE_IPA_PASS') does everything at once and thus cannot be 45936executed during WPA in WHOPR mode. It defines only the _Execute_ stage 45937and during this stage it accesses and modifies the function bodies. 45938Such passes are useful for optimization at LGEN or LTRANS time and are 45939used, for example, to implement early optimization before writing object 45940files. The simple inter-procedural passes can also be used for easier 45941prototyping and development of a new inter-procedural pass. 45942 4594325.3.1 Virtual clones 45944--------------------- 45945 45946One of the main challenges of introducing the WHOPR compilation mode was 45947addressing the interactions between optimization passes. In LTO 45948compilation mode, the passes are executed in a sequence, each of which 45949consists of analysis (or _Generate summary_), propagation (or _Execute_) 45950and _Transform_ stages. Once the work of one pass is finished, the next 45951pass sees the updated program representation and can execute. This 45952makes the individual passes dependent on each other. 45953 45954 In WHOPR mode all passes first execute their _Generate summary_ stage. 45955Then summary writing marks the end of the LGEN stage. At WPA time, the 45956summaries are read back into memory and all passes run the _Execute_ 45957stage. Optimization summaries are streamed and sent to LTRANS, where 45958all the passes execute the _Transform_ stage. 45959 45960 Most optimization passes split naturally into analysis, propagation and 45961transformation stages. But some do not. The main problem arises when 45962one pass performs changes and the following pass gets confused by seeing 45963different callgraphs between the _Transform_ stage and the _Generate 45964summary_ or _Execute_ stage. This means that the passes are required to 45965communicate their decisions with each other. 45966 45967 To facilitate this communication, the GCC callgraph infrastructure 45968implements _virtual clones_, a method of representing the changes 45969performed by the optimization passes in the callgraph without needing to 45970update function bodies. 45971 45972 A _virtual clone_ in the callgraph is a function that has no associated 45973body, just a description of how to create its body based on a different 45974function (which itself may be a virtual clone). 45975 45976 The description of function modifications includes adjustments to the 45977function's signature (which allows, for example, removing or adding 45978function arguments), substitutions to perform on the function body, and, 45979for inlined functions, a pointer to the function that it will be inlined 45980into. 45981 45982 It is also possible to redirect any edge of the callgraph from a 45983function to its virtual clone. This implies updating of the call site 45984to adjust for the new function signature. 45985 45986 Most of the transformations performed by inter-procedural optimizations 45987can be represented via virtual clones. For instance, a constant 45988propagation pass can produce a virtual clone of the function which 45989replaces one of its arguments by a constant. The inliner can represent 45990its decisions by producing a clone of a function whose body will be 45991later integrated into a given function. 45992 45993 Using _virtual clones_, the program can be easily updated during the 45994_Execute_ stage, solving most of pass interactions problems that would 45995otherwise occur during _Transform_. 45996 45997 Virtual clones are later materialized in the LTRANS stage and turned 45998into real functions. Passes executed after the virtual clone were 45999introduced also perform their _Transform_ stage on new functions, so for 46000a pass there is no significant difference between operating on a real 46001function or a virtual clone introduced before its _Execute_ stage. 46002 46003 Optimization passes then work on virtual clones introduced before their 46004_Execute_ stage as if they were real functions. The only difference is 46005that clones are not visible during the _Generate Summary_ stage. 46006 46007 To keep function summaries updated, the callgraph interface allows an 46008optimizer to register a callback that is called every time a new clone 46009is introduced as well as when the actual function or variable is 46010generated or when a function or variable is removed. These hooks are 46011registered in the _Generate summary_ stage and allow the pass to keep 46012its information intact until the _Execute_ stage. The same hooks can 46013also be registered during the _Execute_ stage to keep the optimization 46014summaries updated for the _Transform_ stage. 46015 4601625.3.2 IPA references 46017--------------------- 46018 46019GCC represents IPA references in the callgraph. For a function or 46020variable 'A', the _IPA reference_ is a list of all locations where the 46021address of 'A' is taken and, when 'A' is a variable, a list of all 46022direct stores and reads to/from 'A'. References represent an oriented 46023multi-graph on the union of nodes of the callgraph and the varpool. See 46024'ipa-reference.c':'ipa_reference_write_optimization_summary' and 46025'ipa-reference.c':'ipa_reference_read_optimization_summary' for details. 46026 4602725.3.3 Jump functions 46028--------------------- 46029 46030Suppose that an optimization pass sees a function 'A' and it knows the 46031values of (some of) its arguments. The _jump function_ describes the 46032value of a parameter of a given function call in function 'A' based on 46033this knowledge. 46034 46035 Jump functions are used by several optimizations, such as the 46036inter-procedural constant propagation pass and the devirtualization 46037pass. The inliner also uses jump functions to perform inlining of 46038callbacks. 46039 46040 46041File: gccint.info, Node: WHOPR, Next: Internal flags, Prev: IPA, Up: LTO 46042 4604325.4 Whole program assumptions, linker plugin and symbol visibilities 46044===================================================================== 46045 46046Link-time optimization gives relatively minor benefits when used alone. 46047The problem is that propagation of inter-procedural information does not 46048work well across functions and variables that are called or referenced 46049by other compilation units (such as from a dynamically linked library). 46050We say that such functions and variables are _externally visible_. 46051 46052 To make the situation even more difficult, many applications organize 46053themselves as a set of shared libraries, and the default ELF visibility 46054rules allow one to overwrite any externally visible symbol with a 46055different symbol at runtime. This basically disables any optimizations 46056across such functions and variables, because the compiler cannot be sure 46057that the function body it is seeing is the same function body that will 46058be used at runtime. Any function or variable not declared 'static' in 46059the sources degrades the quality of inter-procedural optimization. 46060 46061 To avoid this problem the compiler must assume that it sees the whole 46062program when doing link-time optimization. Strictly speaking, the whole 46063program is rarely visible even at link-time. Standard system libraries 46064are usually linked dynamically or not provided with the link-time 46065information. In GCC, the whole program option ('-fwhole-program') 46066asserts that every function and variable defined in the current 46067compilation unit is static, except for function 'main' (note: at link 46068time, the current unit is the union of all objects compiled with LTO). 46069Since some functions and variables need to be referenced externally, for 46070example by another DSO or from an assembler file, GCC also provides the 46071function and variable attribute 'externally_visible' which can be used 46072to disable the effect of '-fwhole-program' on a specific symbol. 46073 46074 The whole program mode assumptions are slightly more complex in C++, 46075where inline functions in headers are put into _COMDAT_ sections. 46076COMDAT function and variables can be defined by multiple object files 46077and their bodies are unified at link-time and dynamic link-time. COMDAT 46078functions are changed to local only when their address is not taken and 46079thus un-sharing them with a library is not harmful. COMDAT variables 46080always remain externally visible, however for readonly variables it is 46081assumed that their initializers cannot be overwritten by a different 46082value. 46083 46084 GCC provides the function and variable attribute 'visibility' that can 46085be used to specify the visibility of externally visible symbols (or 46086alternatively an '-fdefault-visibility' command line option). ELF 46087defines the 'default', 'protected', 'hidden' and 'internal' 46088visibilities. 46089 46090 The most commonly used is visibility is 'hidden'. It specifies that 46091the symbol cannot be referenced from outside of the current shared 46092library. Unfortunately, this information cannot be used directly by the 46093link-time optimization in the compiler since the whole shared library 46094also might contain non-LTO objects and those are not visible to the 46095compiler. 46096 46097 GCC solves this problem using linker plugins. A _linker plugin_ is an 46098interface to the linker that allows an external program to claim the 46099ownership of a given object file. The linker then performs the linking 46100procedure by querying the plugin about the symbol table of the claimed 46101objects and once the linking decisions are complete, the plugin is 46102allowed to provide the final object file before the actual linking is 46103made. The linker plugin obtains the symbol resolution information which 46104specifies which symbols provided by the claimed objects are bound from 46105the rest of a binary being linked. 46106 46107 GCC is designed to be independent of the rest of the toolchain and aims 46108to support linkers without plugin support. For this reason it does not 46109use the linker plugin by default. Instead, the object files are 46110examined by 'collect2' before being passed to the linker and objects 46111found to have LTO sections are passed to 'lto1' first. This mode does 46112not work for library archives. The decision on what object files from 46113the archive are needed depends on the actual linking and thus GCC would 46114have to implement the linker itself. The resolution information is 46115missing too and thus GCC needs to make an educated guess based on 46116'-fwhole-program'. Without the linker plugin GCC also assumes that 46117symbols are declared 'hidden' and not referred by non-LTO code by 46118default. 46119 46120 46121File: gccint.info, Node: Internal flags, Prev: WHOPR, Up: LTO 46122 4612325.5 Internal flags controlling 'lto1' 46124====================================== 46125 46126The following flags are passed into 'lto1' and are not meant to be used 46127directly from the command line. 46128 46129 * -fwpa This option runs the serial part of the link-time optimizer 46130 performing the inter-procedural propagation (WPA mode). The 46131 compiler reads in summary information from all inputs and performs 46132 an analysis based on summary information only. It generates object 46133 files for subsequent runs of the link-time optimizer where 46134 individual object files are optimized using both summary 46135 information from the WPA mode and the actual function bodies. It 46136 then drives the LTRANS phase. 46137 46138 * -fltrans This option runs the link-time optimizer in the 46139 local-transformation (LTRANS) mode, which reads in output from a 46140 previous run of the LTO in WPA mode. In the LTRANS mode, LTO 46141 optimizes an object and produces the final assembly. 46142 46143 * -fltrans-output-list=FILE This option specifies a file to which the 46144 names of LTRANS output files are written. This option is only 46145 meaningful in conjunction with '-fwpa'. 46146 46147 * -fresolution=FILE This option specifies the linker resolution file. 46148 This option is only meaningful in conjunction with '-fwpa' and as 46149 option to pass through to the LTO linker plugin. 46150 46151 46152File: gccint.info, Node: Match and Simplify, Next: Static Analyzer, Prev: LTO, Up: Top 46153 4615426 Match and Simplify 46155********************* 46156 46157The GIMPLE and GENERIC pattern matching project match-and-simplify tries 46158to address several issues. 46159 46160 1. unify expression simplifications currently spread and duplicated 46161 over separate files like fold-const.c, gimple-fold.c and builtins.c 46162 2. allow for a cheap way to implement building and simplifying 46163 non-trivial GIMPLE expressions, avoiding the need to go through 46164 building and simplifying GENERIC via fold_buildN and then 46165 gimplifying via force_gimple_operand 46166 46167 To address these the project introduces a simple domain specific 46168language to write expression simplifications from which code targeting 46169GIMPLE and GENERIC is auto-generated. The GENERIC variant follows the 46170fold_buildN API while for the GIMPLE variant and to address 2) new APIs 46171are introduced. 46172 46173* Menu: 46174 46175* GIMPLE API:: 46176* The Language:: 46177 46178 46179File: gccint.info, Node: GIMPLE API, Next: The Language, Up: Match and Simplify 46180 4618126.1 GIMPLE API 46182=============== 46183 46184 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 46185 gimple_seq *, tree (*)(tree)) 46186 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 46187 tree, gimple_seq *, tree (*)(tree)) 46188 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 46189 tree, tree, gimple_seq *, tree (*)(tree)) 46190 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 46191 tree, gimple_seq *, tree (*)(tree)) 46192 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 46193 tree, tree, gimple_seq *, tree (*)(tree)) 46194 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 46195 tree, tree, tree, gimple_seq *, tree (*)(tree)) 46196 The main GIMPLE API entry to the expression simplifications 46197 mimicing that of the GENERIC fold_{unary,binary,ternary} functions. 46198 46199 thus providing n-ary overloads for operation or function. The 46200additional arguments are a gimple_seq where built statements are 46201inserted on (if 'NULL' then simplifications requiring new statements are 46202not performed) and a valueization hook that can be used to tie 46203simplifications to a SSA lattice. 46204 46205 In addition to those APIs 'fold_stmt' is overloaded with a valueization 46206hook: 46207 46208 -- bool: fold_stmt (gimple_stmt_iterator *, tree (*)(tree)); 46209 46210 Ontop of these a 'fold_buildN'-like API for GIMPLE is introduced: 46211 46212 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 46213 tree_code, tree, tree, tree (*valueize) (tree) = NULL); 46214 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 46215 tree_code, tree, tree, tree, tree (*valueize) (tree) = NULL); 46216 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 46217 tree_code, tree, tree, tree, tree, tree (*valueize) (tree) = 46218 NULL); 46219 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 46220 built_in_function, tree, tree, tree (*valueize) (tree) = 46221 NULL); 46222 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 46223 built_in_function, tree, tree, tree, tree (*valueize) (tree) = 46224 NULL); 46225 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 46226 built_in_function, tree, tree, tree, tree, tree (*valueize) 46227 (tree) = NULL); 46228 -- GIMPLE function: tree gimple_convert (gimple_seq *, location_t, 46229 tree, tree); 46230 46231 which is supposed to replace 'force_gimple_operand (fold_buildN (...), 46232...)' and calls to 'fold_convert'. Overloads without the 'location_t' 46233argument exist. Built statements are inserted on the provided sequence 46234and simplification is performed using the optional valueization hook. 46235 46236 46237File: gccint.info, Node: The Language, Prev: GIMPLE API, Up: Match and Simplify 46238 4623926.2 The Language 46240================= 46241 46242The language to write expression simplifications in resembles other 46243domain-specific languages GCC uses. Thus it is lispy. Lets start with 46244an example from the match.pd file: 46245 46246 (simplify 46247 (bit_and @0 integer_all_onesp) 46248 @0) 46249 46250 This example contains all required parts of an expression 46251simplification. A simplification is wrapped inside a '(simplify ...)' 46252expression. That contains at least two operands - an expression that is 46253matched with the GIMPLE or GENERIC IL and a replacement expression that 46254is returned if the match was successful. 46255 46256 Expressions have an operator ID, 'bit_and' in this case. Expressions 46257can be lower-case tree codes with '_expr' stripped off or builtin 46258function code names in all-caps, like 'BUILT_IN_SQRT'. 46259 46260 '@n' denotes a so-called capture. It captures the operand and lets you 46261refer to it in other places of the match-and-simplify. In the above 46262example it is refered to in the replacement expression. Captures are 46263'@' followed by a number or an identifier. 46264 46265 (simplify 46266 (bit_xor @0 @0) 46267 { build_zero_cst (type); }) 46268 46269 In this example '@0' is mentioned twice which constrains the matched 46270expression to have two equal operands. Usually matches are constraint 46271to equal types. If operands may be constants and conversions are 46272involved matching by value might be preferred in which case use '@@0' to 46273denote a by value match and the specific operand you want to refer to in 46274the result part. This example also introduces operands written in C 46275code. These can be used in the expression replacements and are supposed 46276to evaluate to a tree node which has to be a valid GIMPLE operand (so 46277you cannot generate expressions in C code). 46278 46279 (simplify 46280 (trunc_mod integer_zerop@0 @1) 46281 (if (!integer_zerop (@1)) 46282 @0)) 46283 46284 Here '@0' captures the first operand of the trunc_mod expression which 46285is also predicated with 'integer_zerop'. Expression operands may be 46286either expressions, predicates or captures. Captures can be 46287unconstrained or capture expresions or predicates. 46288 46289 This example introduces an optional operand of simplify, the 46290if-expression. This condition is evaluated after the expression matched 46291in the IL and is required to evaluate to true to enable the replacement 46292expression in the second operand position. The expression operand of 46293the 'if' is a standard C expression which may contain references to 46294captures. The 'if' has an optional third operand which may contain the 46295replacement expression that is enabled when the condition evaluates to 46296false. 46297 46298 A 'if' expression can be used to specify a common condition for 46299multiple simplify patterns, avoiding the need to repeat that multiple 46300times: 46301 46302 (if (!TYPE_SATURATING (type) 46303 && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) 46304 (simplify 46305 (minus (plus @0 @1) @0) 46306 @1) 46307 (simplify 46308 (minus (minus @0 @1) @0) 46309 (negate @1))) 46310 46311 Note that 'if's in outer position do not have the optional else clause 46312but instead have multiple then clauses. 46313 46314 Ifs can be nested. 46315 46316 There exists a 'switch' expression which can be used to chain 46317conditions avoiding nesting 'if's too much: 46318 46319 (simplify 46320 (simple_comparison @0 REAL_CST@1) 46321 (switch 46322 /* a CMP (-0) -> a CMP 0 */ 46323 (if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1))) 46324 (cmp @0 { build_real (TREE_TYPE (@1), dconst0); })) 46325 /* x != NaN is always true, other ops are always false. */ 46326 (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1)) 46327 && ! HONOR_SNANS (@1)) 46328 { constant_boolean_node (cmp == NE_EXPR, type); }))) 46329 46330 Is equal to 46331 46332 (simplify 46333 (simple_comparison @0 REAL_CST@1) 46334 (switch 46335 /* a CMP (-0) -> a CMP 0 */ 46336 (if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1))) 46337 (cmp @0 { build_real (TREE_TYPE (@1), dconst0); }) 46338 /* x != NaN is always true, other ops are always false. */ 46339 (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1)) 46340 && ! HONOR_SNANS (@1)) 46341 { constant_boolean_node (cmp == NE_EXPR, type); })))) 46342 46343 which has the second 'if' in the else operand of the first. The 46344'switch' expression takes 'if' expressions as operands (which may not 46345have else clauses) and as a last operand a replacement expression which 46346should be enabled by default if no other condition evaluated to true. 46347 46348 Captures can also be used for capturing results of sub-expressions. 46349 46350 #if GIMPLE 46351 (simplify 46352 (pointer_plus (addr@2 @0) INTEGER_CST_P@1) 46353 (if (is_gimple_min_invariant (@2))) 46354 { 46355 poly_int64 off; 46356 tree base = get_addr_base_and_unit_offset (@0, &off); 46357 off += tree_to_uhwi (@1); 46358 /* Now with that we should be able to simply write 46359 (addr (mem_ref (addr @base) (plus @off @1))) */ 46360 build1 (ADDR_EXPR, type, 46361 build2 (MEM_REF, TREE_TYPE (TREE_TYPE (@2)), 46362 build_fold_addr_expr (base), 46363 build_int_cst (ptr_type_node, off))); 46364 }) 46365 #endif 46366 46367 In the above example, '@2' captures the result of the expression '(addr 46368@0)'. For outermost expression only its type can be captured, and the 46369keyword 'type' is reserved for this purpose. The above example also 46370gives a way to conditionalize patterns to only apply to 'GIMPLE' or 46371'GENERIC' by means of using the pre-defined preprocessor macros 'GIMPLE' 46372and 'GENERIC' and using preprocessor directives. 46373 46374 (simplify 46375 (bit_and:c integral_op_p@0 (bit_ior:c (bit_not @0) @1)) 46376 (bit_and @1 @0)) 46377 46378 Here we introduce flags on match expressions. The flag used above, 46379'c', denotes that the expression should be also matched commutated. 46380Thus the above match expression is really the following four match 46381expressions: 46382 46383 (bit_and integral_op_p@0 (bit_ior (bit_not @0) @1)) 46384 (bit_and (bit_ior (bit_not @0) @1) integral_op_p@0) 46385 (bit_and integral_op_p@0 (bit_ior @1 (bit_not @0))) 46386 (bit_and (bit_ior @1 (bit_not @0)) integral_op_p@0) 46387 46388 Usual canonicalizations you know from GENERIC expressions are applied 46389before matching, so for example constant operands always come second in 46390commutative expressions. 46391 46392 The second supported flag is 's' which tells the code generator to fail 46393the pattern if the expression marked with 's' does have more than one 46394use and the simplification results in an expression with more than one 46395operator. For example in 46396 46397 (simplify 46398 (pointer_plus (pointer_plus:s @0 @1) @3) 46399 (pointer_plus @0 (plus @1 @3))) 46400 46401 this avoids the association if '(pointer_plus @0 @1)' is used outside 46402of the matched expression and thus it would stay live and not trivially 46403removed by dead code elimination. Now consider '((x + 3) + -3)' with 46404the temporary holding '(x + 3)' used elsewhere. This simplifies down to 46405'x' which is desirable and thus flagging with 's' does not prevent the 46406transform. Now consider '((x + 3) + 1)' which simplifies to '(x + 4)'. 46407Despite being flagged with 's' the simplification will be performed. 46408The simplification of '((x + a) + 1)' to '(x + (a + 1))' will not 46409performed in this case though. 46410 46411 More features exist to avoid too much repetition. 46412 46413 (for op (plus pointer_plus minus bit_ior bit_xor) 46414 (simplify 46415 (op @0 integer_zerop) 46416 @0)) 46417 46418 A 'for' expression can be used to repeat a pattern for each operator 46419specified, substituting 'op'. 'for' can be nested and a 'for' can have 46420multiple operators to iterate. 46421 46422 (for opa (plus minus) 46423 opb (minus plus) 46424 (for opc (plus minus) 46425 (simplify... 46426 46427 In this example the pattern will be repeated four times with 'opa, opb, 46428opc' being 'plus, minus, plus'; 'plus, minus, minus'; 'minus, plus, 46429plus'; 'minus, plus, minus'. 46430 46431 To avoid repeating operator lists in 'for' you can name them via 46432 46433 (define_operator_list pmm plus minus mult) 46434 46435 and use them in 'for' operator lists where they get expanded. 46436 46437 (for opa (pmm trunc_div) 46438 (simplify... 46439 46440 So this example iterates over 'plus', 'minus', 'mult' and 'trunc_div'. 46441 46442 Using operator lists can also remove the need to explicitely write a 46443'for'. All operator list uses that appear in a 'simplify' or 'match' 46444pattern in operator positions will implicitely be added to a new 'for'. 46445For example 46446 46447 (define_operator_list SQRT BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 46448 (define_operator_list POW BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 46449 (simplify 46450 (SQRT (POW @0 @1)) 46451 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); }))) 46452 46453 is the same as 46454 46455 (for SQRT (BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 46456 POW (BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 46457 (simplify 46458 (SQRT (POW @0 @1)) 46459 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); })))) 46460 46461 'for's and operator lists can include the special identifier 'null' 46462that matches nothing and can never be generated. This can be used to 46463pad an operator list so that it has a standard form, even if there isn't 46464a suitable operator for every form. 46465 46466 Another building block are 'with' expressions in the result expression 46467which nest the generated code in a new C block followed by its argument: 46468 46469 (simplify 46470 (convert (mult @0 @1)) 46471 (with { tree utype = unsigned_type_for (type); } 46472 (convert (mult (convert:utype @0) (convert:utype @1))))) 46473 46474 This allows code nested in the 'with' to refer to the declared 46475variables. In the above case we use the feature to specify the type of 46476a generated expression with the ':type' syntax where 'type' needs to be 46477an identifier that refers to the desired type. Usually the types of the 46478generated result expressions are determined from the context, but 46479sometimes like in the above case it is required that you specify them 46480explicitely. 46481 46482 Another modifier for generated expressions is '!' which tells the 46483machinery to only consider the simplification in case the marked 46484expression simplified to a simple operand. Consider for example 46485 46486 (simplify 46487 (plus (vec_cond:s @0 @1 @2) @3) 46488 (vec_cond @0 (plus! @1 @3) (plus! @2 @3))) 46489 46490 which moves the outer 'plus' operation to the inner arms of the 46491'vec_cond' expression but only if the actual plus operations both 46492simplify. Note this is currently only supported for code generation 46493targeting 'GIMPLE'. 46494 46495 As intermediate conversions are often optional there is a way to avoid 46496the need to repeat patterns both with and without such conversions. 46497Namely you can mark a conversion as being optional with a '?': 46498 46499 (simplify 46500 (eq (convert@0 @1) (convert? @2)) 46501 (eq @1 (convert @2))) 46502 46503 which will match both '(eq (convert @1) (convert @2))' and '(eq 46504(convert @1) @2)'. The optional converts are supposed to be all either 46505present or not, thus '(eq (convert? @1) (convert? @2))' will result in 46506two patterns only. If you want to match all four combinations you have 46507access to two additional conditional converts as in '(eq (convert1? @1) 46508(convert2? @2))'. 46509 46510 The support for '?' marking extends to all unary operations including 46511predicates you declare yourself with 'match'. 46512 46513 Predicates available from the GCC middle-end need to be made available 46514explicitely via 'define_predicates': 46515 46516 (define_predicates 46517 integer_onep integer_zerop integer_all_onesp) 46518 46519 You can also define predicates using the pattern matching language and 46520the 'match' form: 46521 46522 (match negate_expr_p 46523 INTEGER_CST 46524 (if (TYPE_OVERFLOW_WRAPS (type) 46525 || may_negate_without_overflow_p (t)))) 46526 (match negate_expr_p 46527 (negate @0)) 46528 46529 This shows that for 'match' expressions there is 't' available which 46530captures the outermost expression (something not possible in the 46531'simplify' context). As you can see 'match' has an identifier as first 46532operand which is how you refer to the predicate in patterns. Multiple 46533'match' for the same identifier add additional cases where the predicate 46534matches. 46535 46536 Predicates can also match an expression in which case you need to 46537provide a template specifying the identifier and where to get its 46538operands from: 46539 46540 (match (logical_inverted_value @0) 46541 (eq @0 integer_zerop)) 46542 (match (logical_inverted_value @0) 46543 (bit_not truth_valued_p@0)) 46544 46545 You can use the above predicate like 46546 46547 (simplify 46548 (bit_and @0 (logical_inverted_value @0)) 46549 { build_zero_cst (type); }) 46550 46551 Which will match a bitwise and of an operand with its logical inverted 46552value. 46553 46554 46555File: gccint.info, Node: Static Analyzer, Next: User Experience Guidelines, Prev: Match and Simplify, Up: Top 46556 4655727 Static Analyzer 46558****************** 46559 46560* Menu: 46561 46562* Analyzer Internals:: Analyzer Internals 46563* Debugging the Analyzer:: Useful debugging tips 46564 46565 46566File: gccint.info, Node: Analyzer Internals, Next: Debugging the Analyzer, Up: Static Analyzer 46567 4656827.1 Analyzer Internals 46569======================= 46570 4657127.1.1 Overview 46572--------------- 46573 46574The analyzer implementation works on the gimple-SSA representation. (I 46575chose this in the hopes of making it easy to work with LTO to do 46576whole-program analysis). 46577 46578 The implementation is read-only: it doesn't attempt to change anything, 46579just emit warnings. 46580 46581 The gimple representation can be seen using '-fdump-ipa-analyzer'. 46582 Tip: If the analyzer ICEs before this is written out, one 46583 workaround is to use '--param=analyzer-bb-explosion-factor=0' to 46584 force the analyzer to bail out after analyzing the first basic 46585 block. 46586 46587 First, we build a 'supergraph' which combines the callgraph and all of 46588the CFGs into a single directed graph, with both interprocedural and 46589intraprocedural edges. The nodes and edges in the supergraph are called 46590"supernodes" and "superedges", and often referred to in code as 'snodes' 46591and 'sedges'. Basic blocks in the CFGs are split at interprocedural 46592calls, so there can be more than one supernode per basic block. Most 46593statements will be in just one supernode, but a call statement can 46594appear in two supernodes: at the end of one for the call, and again at 46595the start of another for the return. 46596 46597 The supergraph can be seen using '-fdump-analyzer-supergraph'. 46598 46599 We then build an 'analysis_plan' which walks the callgraph to determine 46600which calls might be suitable for being summarized (rather than fully 46601explored) and thus in what order to explore the functions. 46602 46603 Next is the heart of the analyzer: we use a worklist to explore state 46604within the supergraph, building an "exploded graph". Nodes in the 46605exploded graph correspond to <point, state> pairs, as in "Precise 46606Interprocedural Dataflow Analysis via Graph Reachability" (Thomas Reps, 46607Susan Horwitz and Mooly Sagiv). 46608 46609 We reuse nodes for <point, state> pairs we've already seen, and avoid 46610tracking state too closely, so that (hopefully) we rapidly converge on a 46611final exploded graph, and terminate the analysis. We also bail out if 46612the number of exploded <end-of-basic-block, state> nodes gets larger 46613than a particular multiple of the total number of basic blocks (to 46614ensure termination in the face of pathological state-explosion cases, or 46615bugs). We also stop exploring a point once we hit a limit of states for 46616that point. 46617 46618 We can identify problems directly when processing a <point, state> 46619instance. For example, if we're finding the successors of 46620 46621 <point: before-stmt: "free (ptr);", 46622 state: {"ptr": freed}> 46623 46624 then we can detect a double-free of "ptr". We can then emit a path to 46625reach the problem by finding the simplest route through the graph. 46626 46627 Program points in the analysis are much more fine-grained than in the 46628CFG and supergraph, with points (and thus potentially exploded nodes) 46629for various events, including before individual statements. By default 46630the exploded graph merges multiple consecutive statements in a supernode 46631into one exploded edge to minimize the size of the exploded graph. This 46632can be suppressed via '-fanalyzer-fine-grained'. The fine-grained 46633approach seems to make things simpler and more debuggable that other 46634approaches I tried, in that each point is responsible for one thing. 46635 46636 Program points in the analysis also have a "call string" identifying 46637the stack of callsites below them, so that paths in the exploded graph 46638correspond to interprocedurally valid paths: we always return to the 46639correct call site, propagating state information accordingly. We avoid 46640infinite recursion by stopping the analysis if a callsite appears more 46641than 'analyzer-max-recursion-depth' in a callstring (defaulting to 2). 46642 4664327.1.2 Graphs 46644------------- 46645 46646Nodes and edges in the exploded graph are called "exploded nodes" and 46647"exploded edges" and often referred to in the code as 'enodes' and 46648'eedges' (especially when distinguishing them from the 'snodes' and 46649'sedges' in the supergraph). 46650 46651 Each graph numbers its nodes, giving unique identifiers - supernodes 46652are referred to throughout dumps in the form 'SN': INDEX' and exploded 46653nodes in the form 'EN: INDEX' (e.g. 'SN: 2' and 'EN:29'). 46654 46655 The supergraph can be seen using '-fdump-analyzer-supergraph-graph'. 46656 46657 The exploded graph can be seen using '-fdump-analyzer-exploded-graph' 46658and other dump options. Exploded nodes are color-coded in the .dot 46659output based on state-machine states to make it easier to see state 46660changes at a glance. 46661 4666227.1.3 State Tracking 46663--------------------- 46664 46665There's a tension between: 46666 * precision of analysis in the straight-line case, vs 46667 * exponential blow-up in the face of control flow. 46668 46669 For example, in general, given this CFG: 46670 46671 A 46672 / \ 46673 B C 46674 \ / 46675 D 46676 / \ 46677 E F 46678 \ / 46679 G 46680 46681 we want to avoid differences in state-tracking in B and C from leading 46682to blow-up. If we don't prevent state blowup, we end up with 46683exponential growth of the exploded graph like this: 46684 46685 46686 1:A 46687 / \ 46688 / \ 46689 / \ 46690 2:B 3:C 46691 | | 46692 4:D 5:D (2 exploded nodes for D) 46693 / \ / \ 46694 6:E 7:F 8:E 9:F 46695 | | | | 46696 10:G 11:G 12:G 13:G (4 exploded nodes for G) 46697 46698 46699 Similar issues arise with loops. 46700 46701 To prevent this, we follow various approaches: 46702 46703 a. state pruning: which tries to discard state that won't be relevant 46704 later on withing the function. This can be disabled via 46705 '-fno-analyzer-state-purge'. 46706 46707 b. state merging. We can try to find the commonality between two 46708 program_state instances to make a third, simpler program_state. We 46709 have two strategies here: 46710 46711 1. the worklist keeps new nodes for the same program_point 46712 together, and tries to merge them before processing, and thus 46713 before they have successors. Hence, in the above, the two 46714 nodes for D (4 and 5) reach the front of the worklist 46715 together, and we create a node for D with the merger of the 46716 incoming states. 46717 46718 2. try merging with the state of existing enodes for the 46719 program_point (which may have already been explored). There 46720 will be duplication, but only one set of duplication; 46721 subsequent duplicates are more likely to hit the cache. In 46722 particular, (hopefully) all merger chains are finite, and so 46723 we guarantee termination. This is intended to help with 46724 loops: we ought to explore the first iteration, and then have 46725 a "subsequent iterations" exploration, which uses a state 46726 merged from that of the first, to be more abstract. 46727 46728 We avoid merging pairs of states that have state-machine 46729 differences, as these are the kinds of differences that are likely 46730 to be most interesting. So, for example, given: 46731 46732 if (condition) 46733 ptr = malloc (size); 46734 else 46735 ptr = local_buf; 46736 46737 .... do things with 'ptr' 46738 46739 if (condition) 46740 free (ptr); 46741 46742 ...etc 46743 46744 then we end up with an exploded graph that looks like this: 46745 46746 46747 if (condition) 46748 / T \ F 46749 --------- ---------- 46750 / \ 46751 ptr = malloc (size) ptr = local_buf 46752 | | 46753 copy of copy of 46754 "do things with 'ptr'" "do things with 'ptr'" 46755 with ptr: heap-allocated with ptr: stack-allocated 46756 | | 46757 if (condition) if (condition) 46758 | known to be T | known to be F 46759 free (ptr); | 46760 \ / 46761 ----------------------------- 46762 | ('ptr' is pruned, so states can be merged) 46763 etc 46764 46765 46766 where some duplication has occurred, but only for the places where 46767 the the different paths are worth exploringly separately. 46768 46769 Merging can be disabled via '-fno-analyzer-state-merge'. 46770 4677127.1.4 Region Model 46772------------------- 46773 46774Part of the state stored at a 'exploded_node' is a 'region_model'. This 46775is an implementation of the region-based ternary model described in "A 46776Memory Model for Static Analysis of C Programs" 46777(https://www.researchgate.net/publication/221430855_A_Memory_Model_for_Static_Analysis_of_C_Programs) 46778(Zhongxing Xu, Ted Kremenek, and Jian Zhang). 46779 46780 A 'region_model' encapsulates a representation of the state of memory, 46781with a 'store' recording a binding between 'region' instances, to 46782'svalue' instances. The bindings are organized into clusters, where 46783regions accessible via well-defined pointer arithmetic are in the same 46784cluster. The representation is graph-like because values can be 46785pointers to regions. It also stores a constraint_manager, capturing 46786relationships between the values. 46787 46788 Because each node in the 'exploded_graph' has a 'region_model', and 46789each of the latter is graph-like, the 'exploded_graph' is in some ways a 46790graph of graphs. 46791 46792 Here's an example of printing a 'program_state', showing the 46793'region_model' within it, along with state for the 'malloc' state 46794machine. 46795 46796 (gdb) call debug (*this) 46797 rmodel: 46798 stack depth: 1 46799 frame (index 0): frame: ‘test’@1 46800 clusters within frame: ‘test’@1 46801 cluster for: ptr_3: &HEAP_ALLOCATED_REGION(12) 46802 m_called_unknown_fn: FALSE 46803 constraint_manager: 46804 equiv classes: 46805 constraints: 46806 malloc: 46807 0x2e89590: &HEAP_ALLOCATED_REGION(12): unchecked ('ptr_3') 46808 46809 This is the state at the point of returning from 'calls_malloc' back to 46810'test' in the following: 46811 46812 void * 46813 calls_malloc (void) 46814 { 46815 void *result = malloc (1024); 46816 return result; 46817 } 46818 46819 void test (void) 46820 { 46821 void *ptr = calls_malloc (); 46822 /* etc. */ 46823 } 46824 46825 Within the store, there is the cluster for 'ptr_3' within the frame for 46826'test', where the whole cluster is bound to a pointer value, pointing at 46827'HEAP_ALLOCATED_REGION(12)'. Additionally, this pointer has the 46828'unchecked' state for the 'malloc' state machine indicating it hasn't 46829yet been checked against NULL since the allocation call. 46830 4683127.1.5 Analyzer Paths 46832--------------------- 46833 46834We need to explain to the user what the problem is, and to persuade them 46835that there really is a problem. Hence having a 'diagnostic_path' isn't 46836just an incidental detail of the analyzer; it's required. 46837 46838 Paths ought to be: 46839 * interprocedurally-valid 46840 * feasible 46841 46842 Without state-merging, all paths in the exploded graph are feasible (in 46843terms of constraints being satisfied). With state-merging, paths in the 46844exploded graph can be infeasible. 46845 46846 We collate warnings and only emit them for the simplest path e.g. for 46847a bug in a utility function, with lots of routes to calling it, we only 46848emit the simplest path (which could be intraprocedural, if it can be 46849reproduced without a caller). 46850 46851 We thus want to find the shortest feasible path through the exploded 46852graph from the origin to the exploded node at which the diagnostic was 46853saved. Unfortunately, if we simply find the shortest such path and 46854check if it's feasible we might falsely reject the diagnostic, as there 46855might be a longer path that is feasible. Examples include the cases 46856where the diagnostic requires us to go at least once around a loop for a 46857later condition to be satisfied, or where for a later condition to be 46858satisfied we need to enter a suite of code that the simpler path skips. 46859 46860 We attempt to find the shortest feasible path to each diagnostic by 46861first constructing a "trimmed graph" from the exploded graph, containing 46862only those nodes and edges from which there are paths to the target 46863node, and using Dijkstra's algorithm to order the trimmed nodes by 46864minimal distance to the target. 46865 46866 We then use a worklist to iteratively build a "feasible graph" 46867(actually a tree), capturing the pertinent state along each path, in 46868which every path to a "feasible node" is feasible by construction, 46869restricting ourselves to the trimmed graph to ensure we stay on target, 46870and ordering the worklist so that the first feasible path we find to the 46871target node is the shortest possible path. Hence we start by trying the 46872shortest possible path, but if that fails, we explore progressively 46873longer paths, eventually trying iterations through loops. The 46874exploration is captured in the feasible_graph, which can be dumped as a 46875.dot file via '-fdump-analyzer-feasibility' to visualize the 46876exploration. The indices of the feasible nodes show the order in which 46877they were created. We effectively explore the tree of feasible paths in 46878order of shortest path until we either find a feasible path to the 46879target node, or hit a limit and give up. 46880 46881 This is something of a brute-force approach, but the trimmed graph 46882hopefully keeps the complexity manageable. 46883 46884 This algorithm can be disabled (for debugging purposes) via 46885'-fno-analyzer-feasibility', which simply uses the shortest path, and 46886notes if it is infeasible. 46887 46888 The above gives us a shortest feasible 'exploded_path' through the 46889'exploded_graph' (a list of 'exploded_edge *'). We use this 46890'exploded_path' to build a 'diagnostic_path' (a list of *events* for the 46891diagnostic subsystem) - specifically a 'checker_path'. 46892 46893 Having built the 'checker_path', we prune it to try to eliminate events 46894that aren't relevant, to minimize how much the user has to read. 46895 46896 After pruning, we notify each event in the path of its ID and record 46897the IDs of interesting events, allowing for events to refer to other 46898events in their descriptions. The 'pending_diagnostic' class has 46899various vfuncs to support emitting more precise descriptions, so that 46900e.g. 46901 46902 * a deref-of-unchecked-malloc diagnostic might use: 46903 returning possibly-NULL pointer to 'make_obj' from 'allocator' 46904 for a 'return_event' to make it clearer how the unchecked value 46905 moves from callee back to caller 46906 * a double-free diagnostic might use: 46907 second 'free' here; first 'free' was at (3) 46908 and a use-after-free might use 46909 use after 'free' here; memory was freed at (2) 46910 46911 At this point we can emit the diagnostic. 46912 4691327.1.6 Limitations 46914------------------ 46915 46916 * Only for C so far 46917 * The implementation of call summaries is currently very simplistic. 46918 * Lack of function pointer analysis 46919 * The constraint-handling code assumes reflexivity in some places 46920 (that values are equal to themselves), which is not the case for 46921 NaN. As a simple workaround, constraints on floating-point values 46922 are currently ignored. 46923 * There are various other limitations in the region model (grep for 46924 TODO/xfail in the testsuite). 46925 * The constraint_manager's implementation of transitivity is 46926 currently too expensive to enable by default and so must be 46927 manually enabled via '-fanalyzer-transitivity'). 46928 * The checkers are currently hardcoded and don't allow for user 46929 extensibility (e.g. adding allocate/release pairs). 46930 * Although the analyzer's test suite has a proof-of-concept test case 46931 for LTO, LTO support hasn't had extensive testing. There are 46932 various lang-specific things in the analyzer that assume C rather 46933 than LTO. For example, SSA names are printed to the user in "raw" 46934 form, rather than printing the underlying variable name. 46935 46936 Some ideas for other checkers 46937 * File-descriptor-based APIs 46938 * Linux kernel internal APIs 46939 * Signal handling 46940 46941 46942File: gccint.info, Node: Debugging the Analyzer, Prev: Analyzer Internals, Up: Static Analyzer 46943 4694427.2 Debugging the Analyzer 46945=========================== 46946 4694727.2.1 Special Functions for Debugging the Analyzer 46948--------------------------------------------------- 46949 46950The analyzer recognizes various special functions by name, for use in 46951debugging the analyzer. Declarations can be seen in the testsuite in 46952'analyzer-decls.h'. None of these functions are actually implemented. 46953 46954 Add: 46955 __analyzer_break (); 46956 to the source being analyzed to trigger a breakpoint in the analyzer 46957when that source is reached. By putting a series of these in the 46958source, it's much easier to effectively step through the program state 46959as it's analyzed. 46960 46961 The analyzer handles: 46962 46963 __analyzer_describe (0, expr); 46964 46965 by emitting a warning describing the 2nd argument (which can be of any 46966type), at a verbosity level given by the 1st argument. This is for use 46967when debugging, and may be of use in DejaGnu tests. 46968 46969 __analyzer_dump (); 46970 46971 will dump the copious information about the analyzer's state each time 46972it reaches the call in its traversal of the source. 46973 46974 __analyzer_dump_path (); 46975 46976 will emit a placeholder "note" diagnostic with a path to that call 46977site, if the analyzer finds a feasible path to it. 46978 46979 The builtin '__analyzer_dump_exploded_nodes' will emit a warning after 46980analysis containing information on all of the exploded nodes at that 46981program point: 46982 46983 __analyzer_dump_exploded_nodes (0); 46984 46985 will output the number of "processed" nodes, and the IDs of both 46986"processed" and "merger" nodes, such as: 46987 46988 warning: 2 processed enodes: [EN: 56, EN: 58] merger(s): [EN: 54-55, EN: 57, EN: 59] 46989 46990 With a non-zero argument 46991 46992 __analyzer_dump_exploded_nodes (1); 46993 46994 it will also dump all of the states within the "processed" nodes. 46995 46996 __analyzer_dump_region_model (); 46997 will dump the region_model's state to stderr. 46998 46999 __analyzer_eval (expr); 47000 will emit a warning with text "TRUE", FALSE" or "UNKNOWN" based on the 47001truthfulness of the argument. This is useful for writing DejaGnu tests. 47002 4700327.2.2 Other Debugging Techniques 47004--------------------------------- 47005 47006The option '-fdump-analyzer-json' will dump both the supergraph and the 47007exploded graph in compressed JSON form. 47008 47009 One approach when tracking down where a particular bogus state is 47010introduced into the 'exploded_graph' is to add custom code to 47011'program_state::validate'. 47012 47013 47014File: gccint.info, Node: User Experience Guidelines, Next: Funding, Prev: Static Analyzer, Up: Top 47015 4701628 User Experience Guidelines 47017***************************** 47018 47019To borrow a slogan from Elm 47020(https://elm-lang.org/news/compilers-as-assistants), 47021 47022 *Compilers should be assistants, not adversaries.* A compiler 47023 should not just detect bugs, it should then help you understand why 47024 there is a bug. It should not berate you in a robot voice, it 47025 should give you specific hints that help you write better code. 47026 Ultimately, a compiler should make programming faster and more fun! 47027 -- _Evan Czaplicki_ 47028 47029 This chapter provides guidelines on how to implement diagnostics and 47030command-line options in ways that we hope achieve the above ideal. 47031 47032* Menu: 47033 47034* Guidelines for Diagnostics:: How to implement diagnostics. 47035* Guidelines for Options:: Guidelines for command-line options. 47036 47037 47038File: gccint.info, Node: Guidelines for Diagnostics, Next: Guidelines for Options, Up: User Experience Guidelines 47039 4704028.1 Guidelines for Diagnostics 47041=============================== 47042 4704328.1.1 Talk in terms of the user's code 47044--------------------------------------- 47045 47046Diagnostics should be worded in terms of the user's source code, and the 47047source language, rather than GCC's own implementation details. 47048 4704928.1.2 Diagnostics are actionable 47050--------------------------------- 47051 47052A good diagnostic is "actionable": it should assist the user in taking 47053action. 47054 47055 Consider what an end user will want to do when encountering a 47056diagnostic. 47057 47058 Given an error, an end user will think: "How do I fix this?" 47059 47060 Given a warning, an end user will think: 47061 47062 * "Is this a real problem?" 47063 * "Do I care?" 47064 * if they decide it's genuine: "How do I fix this?" 47065 47066 A good diagnostic provides pertinent information to allow the user to 47067easily answer the above questions. 47068 4706928.1.3 The user's attention is important 47070---------------------------------------- 47071 47072A perfect compiler would issue a warning on every aspect of the user's 47073source code that ought to be fixed, and issue no other warnings. 47074Naturally, this ideal is impossible to achieve. 47075 47076 Warnings should have a good "signal-to-noise ratio": we should have few 47077"false positives" (falsely issuing a warning when no warning is 47078warranted) and few "false negatives" (failing to issue a warning when 47079one _is_ justified). 47080 47081 Note that a false positive can mean, in practice, a warning that the 47082user doesn't agree with. Ideally a diagnostic should contain enough 47083information to allow the user to make an informed choice about whether 47084they should care (and how to fix it), but a balance must be drawn 47085against overloading the user with irrelevant data. 47086 4708728.1.4 Sometimes the user didn't write the code 47088----------------------------------------------- 47089 47090GCC is typically used in two different ways: 47091 47092 * Semi-interactive usage: GCC is used as a development tool when the 47093 user is writing code, as the "compile" part of the 47094 "edit-compile-debug" cycle. The user is actively hacking on the 47095 code themself (perhaps a project they wrote, or someone else's), 47096 where they just made a change to the code and want to see what 47097 happens, and to be warned about mistakes. 47098 47099 * Batch rebuilds: where the user is recompiling one or more existing 47100 packages, and GCC is a detail that's being invoked by various build 47101 scripts. Examples include a user trying to bring up an operating 47102 system consisting of hundreds of packages on a new CPU 47103 architecture, where the packages were written by many different 47104 people, or simply rebuilding packages after a dependency changed, 47105 where the user is hoping "nothing breaks", since they are 47106 unfamiliar with the code. 47107 47108 Keep both of these styles of usage in mind when implementing 47109diagnostics. 47110 4711128.1.5 Precision of Wording 47112--------------------------- 47113 47114Provide the user with details that allow them to identify what the 47115problem is. For example, the vaguely-worded message: 47116 47117 demo.c:1:1: warning: 'noinline' attribute ignored [-Wattributes] 47118 1 | int foo __attribute__((noinline)); 47119 | ^~~ 47120 47121doesn't tell the user why the attribute was ignored, or what kind of 47122entity the compiler thought the attribute was being applied to (the 47123source location for the diagnostic is also poor; *note discussion of 47124'input_location': input_location_example.). A better message would be: 47125 47126 demo.c:1:24: warning: attribute 'noinline' on variable 'foo' was 47127 ignored [-Wattributes] 47128 1 | int foo __attribute__((noinline)); 47129 | ~~~ ~~~~~~~~~~~~~~~^~~~~~~~~ 47130 demo.c:1:24: note: attribute 'noinline' is only applicable to functions 47131 47132which spells out the missing information (and fixes the location 47133information, as discussed below). 47134 47135 The above example uses a note to avoid a combinatorial explosion of 47136possible messages. 47137 4713828.1.6 Try the diagnostic on real-world code 47139-------------------------------------------- 47140 47141It's worth testing a new warning on many instances of real-world code, 47142written by different people, and seeing what it complains about, and 47143what it doesn't complain about. 47144 47145 This may suggest heuristics that silence common false positives. 47146 47147 It may also suggest ways to improve the precision of the message. 47148 4714928.1.7 Make mismatches clear 47150---------------------------- 47151 47152Many diagnostics relate to a mismatch between two different places in 47153the user's source code. Examples include: 47154 * a type mismatch, where the type at a usage site does not match the 47155 type at a declaration 47156 47157 * the argument count at a call site does not match the parameter 47158 count at the declaration 47159 47160 * something is erroneously duplicated (e.g. an error, due to breaking 47161 a uniqueness requirement, or a warning, if it's suggestive of a 47162 bug) 47163 47164 * an "opened" syntactic construct (such as an open-parenthesis) is 47165 not closed 47166 47167 In each case, the diagnostic should indicate *both* pertinent locations 47168(so that the user can easily see the problem and how to fix it). 47169 47170 The standard way to do this is with a note (via 'inform'). For 47171example: 47172 47173 auto_diagnostic_group d; 47174 if (warning_at (loc, OPT_Wduplicated_cond, 47175 "duplicated %<if%> condition")) 47176 inform (EXPR_LOCATION (t), "previously used here"); 47177 47178which leads to: 47179 47180 demo.c: In function 'test': 47181 demo.c:5:17: warning: duplicated 'if' condition [-Wduplicated-cond] 47182 5 | else if (flag > 3) 47183 | ~~~~~^~~ 47184 demo.c:3:12: note: previously used here 47185 3 | if (flag > 3) 47186 | ~~~~~^~~ 47187 47188The 'inform' call should be guarded by the return value from the 47189'warning_at' call so that the note isn't emitted when the warning is 47190suppressed. 47191 47192 For cases involving punctuation where the locations might be near each 47193other, they can be conditionally consolidated via 47194'gcc_rich_location::add_location_if_nearby': 47195 47196 auto_diagnostic_group d; 47197 gcc_rich_location richloc (primary_loc); 47198 bool added secondary = richloc.add_location_if_nearby (secondary_loc); 47199 error_at (&richloc, "main message"); 47200 if (!added secondary) 47201 inform (secondary_loc, "message for secondary"); 47202 47203This will emit either one diagnostic with two locations: 47204 demo.c:42:10: error: main message 47205 (foo) 47206 ~ ^ 47207 47208or two diagnostics: 47209 47210 demo.c:42:4: error: main message 47211 foo) 47212 ^ 47213 demo.c:40:2: note: message for secondary 47214 ( 47215 ^ 47216 4721728.1.8 Location Information 47218--------------------------- 47219 47220GCC's 'location_t' type can support both ordinary locations, and 47221locations relating to a macro expansion. 47222 47223 As of GCC 6, ordinary locations changed from supporting just a point in 47224the user's source code to supporting three points: the "caret" location, 47225plus a start and a finish: 47226 47227 a = foo && bar; 47228 ~~~~^~~~~~ 47229 | | | 47230 | | finish 47231 | caret 47232 start 47233 47234 Tokens coming out of libcpp have locations of the form 'caret == 47235start', such as for 'foo' here: 47236 47237 a = foo && bar; 47238 ^~~ 47239 | | 47240 | finish 47241 caret == start 47242 47243 Compound expressions should be reported using the location of the 47244expression as a whole, rather than just of one token within it. 47245 47246 For example, in '-Wformat', rather than underlining just the first 47247token of a bad argument: 47248 47249 printf("hello %i %s", (long)0, "world"); 47250 ~^ ~ 47251 %li 47252 47253the whole of the expression should be underlined, so that the user can 47254easily identify what is being referred to: 47255 47256 printf("hello %i %s", (long)0, "world"); 47257 ~^ ~~~~~~~ 47258 %li 47259 47260 Avoid using the 'input_location' global, and the diagnostic functions 47261that implicitly use it--use 'error_at' and 'warning_at' rather than 47262'error' and 'warning', and provide the most appropriate 'location_t' 47263value available at that phase of the compilation. It's possible to 47264supply secondary 'location_t' values via 'rich_location'. 47265 47266For example, in the example of imprecise wording above, generating the 47267diagnostic using 'warning': 47268 47269 // BAD: implicitly uses input_location 47270 warning (OPT_Wattributes, "%qE attribute ignored", name); 47271 47272leads to: 47273 47274 // BAD: uses input_location 47275 demo.c:1:1: warning: 'noinline' attribute ignored [-Wattributes] 47276 1 | int foo __attribute__((noinline)); 47277 | ^~~ 47278 47279which thus happened to use the location of the 'int' token, rather than 47280that of the attribute. Using 'warning_at' with the location of the 47281attribute, providing the location of the declaration in question as a 47282secondary location, and adding a note: 47283 47284 auto_diagnostic_group d; 47285 gcc_rich_location richloc (attrib_loc); 47286 richloc.add_range (decl_loc); 47287 if (warning_at (OPT_Wattributes, &richloc, 47288 "attribute %qE on variable %qE was ignored", name)) 47289 inform (attrib_loc, "attribute %qE is only applicable to functions"); 47290 47291would lead to: 47292 47293 // OK: use location of attribute, with a secondary location 47294 demo.c:1:24: warning: attribute 'noinline' on variable 'foo' was 47295 ignored [-Wattributes] 47296 1 | int foo __attribute__((noinline)); 47297 | ~~~ ~~~~~~~~~~~~~~~^~~~~~~~~ 47298 demo.c:1:24: note: attribute 'noinline' is only applicable to functions 47299 4730028.1.9 Coding Conventions 47301------------------------- 47302 47303See the diagnostics section 47304(https://gcc.gnu.org/codingconventions.html#Diagnostics) of the GCC 47305coding conventions. 47306 47307 In the C++ front end, when comparing two types in a message, use '%H' 47308and '%I' rather than '%T', as this allows the diagnostics subsystem to 47309highlight differences between template-based types. For example, rather 47310than using '%qT': 47311 47312 // BAD: a pair of %qT used in C++ front end for type comparison 47313 error_at (loc, "could not convert %qE from %qT to %qT", expr, 47314 TREE_TYPE (expr), type); 47315 47316which could lead to: 47317 47318 error: could not convert 'map<int, double>()' from 'map<int,double>' 47319 to 'map<int,int>' 47320 47321using '%H' and '%I' (via '%qH' and '%qI'): 47322 47323 // OK: compare types in C++ front end via %qH and %qI 47324 error_at (loc, "could not convert %qE from %qH to %qI", expr, 47325 TREE_TYPE (expr), type); 47326 47327allows the above output to be simplified to: 47328 47329 error: could not convert 'map<int, double>()' from 'map<[...],double>' 47330 to 'map<[...],int>' 47331 47332where the 'double' and 'int' are colorized to highlight them. 47333 4733428.1.10 Group logically-related diagnostics 47335------------------------------------------- 47336 47337Use 'auto_diagnostic_group' when issuing multiple related diagnostics 47338(seen in various examples on this page). This informs the diagnostic 47339subsystem that all diagnostics issued within the lifetime of the 47340'auto_diagnostic_group' are related. For example, 47341'-fdiagnostics-format=json' will treat the first diagnostic emitted 47342within the group as a top-level diagnostic, and all subsequent 47343diagnostics within the group as its children. 47344 4734528.1.11 Quoting 47346--------------- 47347 47348Text should be quoted by either using the 'q' modifier in a directive 47349such as '%qE', or by enclosing the quoted text in a pair of '%<' and 47350'%>' directives, and never by using explicit quote characters. The 47351directives handle the appropriate quote characters for each language and 47352apply the correct color or highlighting. 47353 47354 The following elements should be quoted in GCC diagnostics: 47355 47356 * Language keywords. 47357 * Tokens. 47358 * Boolean, numerical, character, and string constants that appear in 47359 the source code. 47360 * Identifiers, including function, macro, type, and variable names. 47361 47362 Other elements such as numbers that do not refer to numeric constants 47363that appear in the source code should not be quoted. For example, in 47364the message: 47365 47366 argument %d of %qE must be a pointer type 47367 47368since the argument number does not refer to a numerical constant in the 47369source code it should not be quoted. 47370 4737128.1.12 Spelling and Terminology 47372-------------------------------- 47373 47374See the terminology and markup 47375(https://gcc.gnu.org/codingconventions.html#Spelling Spelling) section 47376of the GCC coding conventions. 47377 4737828.1.13 Fix-it hints 47379-------------------- 47380 47381GCC's diagnostic subsystem can emit "fix-it hints": small suggested 47382edits to the user's source code. 47383 47384 They are printed by default underneath the code in question. They can 47385also be viewed via '-fdiagnostics-generate-patch' and 47386'-fdiagnostics-parseable-fixits'. With the latter, an IDE ought to be 47387able to offer to automatically apply the suggested fix. 47388 47389 Fix-it hints contain code fragments, and thus they should not be marked 47390for translation. 47391 47392 Fix-it hints can be added to a diagnostic by using a 'rich_location' 47393rather than a 'location_t' - the fix-it hints are added to the 47394'rich_location' using one of the various 'add_fixit' member functions of 47395'rich_location'. They are documented with 'rich_location' in 47396'libcpp/line-map.h'. It's easiest to use the 'gcc_rich_location' 47397subclass of 'rich_location' found in 'gcc-rich-location.h', as this 47398implicitly supplies the 'line_table' variable. 47399 47400 For example: 47401 47402 if (const char *suggestion = hint.suggestion ()) 47403 { 47404 gcc_rich_location richloc (location); 47405 richloc.add_fixit_replace (suggestion); 47406 error_at (&richloc, 47407 "%qE does not name a type; did you mean %qs?", 47408 id, suggestion); 47409 } 47410 47411which can lead to: 47412 47413 spellcheck-typenames.C:73:1: error: 'singed' does not name a type; did 47414 you mean 'signed'? 47415 73 | singed char ch; 47416 | ^~~~~~ 47417 | signed 47418 47419 Non-trivial edits can be built up by adding multiple fix-it hints to 47420one 'rich_location'. It's best to express the edits in terms of the 47421locations of individual tokens. Various handy functions for adding 47422fix-it hints for idiomatic C and C++ can be seen in 47423'gcc-rich-location.h'. 47424 4742528.1.13.1 Fix-it hints should work 47426.................................. 47427 47428When implementing a fix-it hint, please verify that the suggested edit 47429leads to fixed, compilable code. (Unfortunately, this currently must be 47430done by hand using '-fdiagnostics-generate-patch'. It would be good to 47431have an automated way of verifying that fix-it hints actually fix the 47432code). 47433 47434 For example, a "gotcha" here is to forget to add a space when adding a 47435missing reserved word. Consider a C++ fix-it hint that adds 'typename' 47436in front of a template declaration. A naive way to implement this might 47437be: 47438 47439 gcc_rich_location richloc (loc); 47440 // BAD: insertion is missing a trailing space 47441 richloc.add_fixit_insert_before ("typename"); 47442 error_at (&richloc, "need %<typename%> before %<%T::%E%> because " 47443 "%qT is a dependent scope", 47444 parser->scope, id, parser->scope); 47445 47446When applied to the code, this might lead to: 47447 47448 T::type x; 47449 47450being "corrected" to: 47451 47452 typenameT::type x; 47453 47454In this case, the correct thing to do is to add a trailing space after 47455'typename': 47456 47457 gcc_rich_location richloc (loc); 47458 // OK: note that here we have a trailing space 47459 richloc.add_fixit_insert_before ("typename "); 47460 error_at (&richloc, "need %<typename%> before %<%T::%E%> because " 47461 "%qT is a dependent scope", 47462 parser->scope, id, parser->scope); 47463 47464leading to this corrected code: 47465 47466 typename T::type x; 47467 4746828.1.13.2 Express deletion in terms of deletion, not replacement 47469................................................................ 47470 47471It's best to express deletion suggestions in terms of deletion fix-it 47472hints, rather than replacement fix-it hints. For example, consider 47473this: 47474 47475 auto_diagnostic_group d; 47476 gcc_rich_location richloc (location_of (retval)); 47477 tree name = DECL_NAME (arg); 47478 richloc.add_fixit_replace (IDENTIFIER_POINTER (name)); 47479 warning_at (&richloc, OPT_Wredundant_move, 47480 "redundant move in return statement"); 47481 47482which is intended to e.g. replace a 'std::move' with the underlying 47483value: 47484 47485 return std::move (retval); 47486 ~~~~~~~~~~^~~~~~~~ 47487 retval 47488 47489where the change has been expressed as replacement, replacing with the 47490name of the declaration. This works for simple cases, but consider this 47491case: 47492 47493 #ifdef SOME_CONFIG_FLAG 47494 # define CONFIGURY_GLOBAL global_a 47495 #else 47496 # define CONFIGURY_GLOBAL global_b 47497 #endif 47498 47499 int fn () 47500 { 47501 return std::move (CONFIGURY_GLOBAL /* some comment */); 47502 } 47503 47504The above implementation erroneously strips out the macro and the 47505comment in the fix-it hint: 47506 47507 return std::move (CONFIGURY_GLOBAL /* some comment */); 47508 ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 47509 global_a 47510 47511and thus this resulting code: 47512 47513 return global_a; 47514 47515It's better to do deletions in terms of deletions; deleting the 47516'std::move (' and the trailing close-paren, leading to this: 47517 47518 return std::move (CONFIGURY_GLOBAL /* some comment */); 47519 ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 47520 CONFIGURY_GLOBAL /* some comment */ 47521 47522and thus this result: 47523 47524 return CONFIGURY_GLOBAL /* some comment */; 47525 47526Unfortunately, the pertinent 'location_t' values are not always 47527available. 47528 4752928.1.13.3 Multiple suggestions 47530.............................. 47531 47532In the rare cases where you need to suggest more than one mutually 47533exclusive solution to a problem, this can be done by emitting multiple 47534notes and calling 'rich_location::fixits_cannot_be_auto_applied' on each 47535note's 'rich_location'. If this is called, then the fix-it hints in the 47536'rich_location' will be printed, but will not be added to generated 47537patches. 47538 47539 47540File: gccint.info, Node: Guidelines for Options, Prev: Guidelines for Diagnostics, Up: User Experience Guidelines 47541 4754228.2 Guidelines for Options 47543=========================== 47544 47545 47546File: gccint.info, Node: Funding, Next: GNU Project, Prev: User Experience Guidelines, Up: Top 47547 47548Funding Free Software 47549********************* 47550 47551If you want to have more free software a few years from now, it makes 47552sense for you to help encourage people to contribute funds for its 47553development. The most effective approach known is to encourage 47554commercial redistributors to donate. 47555 47556 Users of free software systems can boost the pace of development by 47557encouraging for-a-fee distributors to donate part of their selling price 47558to free software developers--the Free Software Foundation, and others. 47559 47560 The way to convince distributors to do this is to demand it and expect 47561it from them. So when you compare distributors, judge them partly by 47562how much they give to free software development. Show distributors they 47563must compete to be the one who gives the most. 47564 47565 To make this approach work, you must insist on numbers that you can 47566compare, such as, "We will donate ten dollars to the Frobnitz project 47567for each disk sold." Don't be satisfied with a vague promise, such as 47568"A portion of the profits are donated," since it doesn't give a basis 47569for comparison. 47570 47571 Even a precise fraction "of the profits from this disk" is not very 47572meaningful, since creative accounting and unrelated business decisions 47573can greatly alter what fraction of the sales price counts as profit. If 47574the price you pay is $50, ten percent of the profit is probably less 47575than a dollar; it might be a few cents, or nothing at all. 47576 47577 Some redistributors do development work themselves. This is useful 47578too; but to keep everyone honest, you need to inquire how much they do, 47579and what kind. Some kinds of development make much more long-term 47580difference than others. For example, maintaining a separate version of 47581a program contributes very little; maintaining the standard version of a 47582program for the whole community contributes much. Easy new ports 47583contribute little, since someone else would surely do them; difficult 47584ports such as adding a new CPU to the GNU Compiler Collection contribute 47585more; major new features or packages contribute the most. 47586 47587 By establishing the idea that supporting further development is "the 47588proper thing to do" when distributing free software for a fee, we can 47589assure a steady flow of resources into making more free software. 47590 47591 Copyright (C) 1994 Free Software Foundation, Inc. 47592 Verbatim copying and redistribution of this section is permitted 47593 without royalty; alteration is not permitted. 47594 47595 47596File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 47597 47598The GNU Project and GNU/Linux 47599***************************** 47600 47601The GNU Project was launched in 1984 to develop a complete Unix-like 47602operating system which is free software: the GNU system. (GNU is a 47603recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 47604Variants of the GNU operating system, which use the kernel Linux, are 47605now widely used; though these systems are often referred to as "Linux", 47606they are more accurately called GNU/Linux systems. 47607 47608 For more information, see: 47609 <http://www.gnu.org/> 47610 <http://www.gnu.org/gnu/linux-and-gnu.html> 47611 47612 47613File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 47614 47615GNU General Public License 47616************************** 47617 47618 Version 3, 29 June 2007 47619 47620 Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> 47621 47622 Everyone is permitted to copy and distribute verbatim copies of this 47623 license document, but changing it is not allowed. 47624 47625Preamble 47626======== 47627 47628The GNU General Public License is a free, copyleft license for software 47629and other kinds of works. 47630 47631 The licenses for most software and other practical works are designed 47632to take away your freedom to share and change the works. By contrast, 47633the GNU General Public License is intended to guarantee your freedom to 47634share and change all versions of a program-to make sure it remains free 47635software for all its users. We, the Free Software Foundation, use the 47636GNU General Public License for most of our software; it applies also to 47637any other work released this way by its authors. You can apply it to 47638your programs, too. 47639 47640 When we speak of free software, we are referring to freedom, not price. 47641Our General Public Licenses are designed to make sure that you have the 47642freedom to distribute copies of free software (and charge for them if 47643you wish), that you receive source code or can get it if you want it, 47644that you can change the software or use pieces of it in new free 47645programs, and that you know you can do these things. 47646 47647 To protect your rights, we need to prevent others from denying you 47648these rights or asking you to surrender the rights. Therefore, you have 47649certain responsibilities if you distribute copies of the software, or if 47650you modify it: responsibilities to respect the freedom of others. 47651 47652 For example, if you distribute copies of such a program, whether gratis 47653or for a fee, you must pass on to the recipients the same freedoms that 47654you received. You must make sure that they, too, receive or can get the 47655source code. And you must show them these terms so they know their 47656rights. 47657 47658 Developers that use the GNU GPL protect your rights with two steps: (1) 47659assert copyright on the software, and (2) offer you this License giving 47660you legal permission to copy, distribute and/or modify it. 47661 47662 For the developers' and authors' protection, the GPL clearly explains 47663that there is no warranty for this free software. For both users' and 47664authors' sake, the GPL requires that modified versions be marked as 47665changed, so that their problems will not be attributed erroneously to 47666authors of previous versions. 47667 47668 Some devices are designed to deny users access to install or run 47669modified versions of the software inside them, although the manufacturer 47670can do so. This is fundamentally incompatible with the aim of 47671protecting users' freedom to change the software. The systematic 47672pattern of such abuse occurs in the area of products for individuals to 47673use, which is precisely where it is most unacceptable. Therefore, we 47674have designed this version of the GPL to prohibit the practice for those 47675products. If such problems arise substantially in other domains, we 47676stand ready to extend this provision to those domains in future versions 47677of the GPL, as needed to protect the freedom of users. 47678 47679 Finally, every program is threatened constantly by software patents. 47680States should not allow patents to restrict development and use of 47681software on general-purpose computers, but in those that do, we wish to 47682avoid the special danger that patents applied to a free program could 47683make it effectively proprietary. To prevent this, the GPL assures that 47684patents cannot be used to render the program non-free. 47685 47686 The precise terms and conditions for copying, distribution and 47687modification follow. 47688 47689TERMS AND CONDITIONS 47690==================== 47691 47692 0. Definitions. 47693 47694 "This License" refers to version 3 of the GNU General Public 47695 License. 47696 47697 "Copyright" also means copyright-like laws that apply to other 47698 kinds of works, such as semiconductor masks. 47699 47700 "The Program" refers to any copyrightable work licensed under this 47701 License. Each licensee is addressed as "you". "Licensees" and 47702 "recipients" may be individuals or organizations. 47703 47704 To "modify" a work means to copy from or adapt all or part of the 47705 work in a fashion requiring copyright permission, other than the 47706 making of an exact copy. The resulting work is called a "modified 47707 version" of the earlier work or a work "based on" the earlier work. 47708 47709 A "covered work" means either the unmodified Program or a work 47710 based on the Program. 47711 47712 To "propagate" a work means to do anything with it that, without 47713 permission, would make you directly or secondarily liable for 47714 infringement under applicable copyright law, except executing it on 47715 a computer or modifying a private copy. Propagation includes 47716 copying, distribution (with or without modification), making 47717 available to the public, and in some countries other activities as 47718 well. 47719 47720 To "convey" a work means any kind of propagation that enables other 47721 parties to make or receive copies. Mere interaction with a user 47722 through a computer network, with no transfer of a copy, is not 47723 conveying. 47724 47725 An interactive user interface displays "Appropriate Legal Notices" 47726 to the extent that it includes a convenient and prominently visible 47727 feature that (1) displays an appropriate copyright notice, and (2) 47728 tells the user that there is no warranty for the work (except to 47729 the extent that warranties are provided), that licensees may convey 47730 the work under this License, and how to view a copy of this 47731 License. If the interface presents a list of user commands or 47732 options, such as a menu, a prominent item in the list meets this 47733 criterion. 47734 47735 1. Source Code. 47736 47737 The "source code" for a work means the preferred form of the work 47738 for making modifications to it. "Object code" means any non-source 47739 form of a work. 47740 47741 A "Standard Interface" means an interface that either is an 47742 official standard defined by a recognized standards body, or, in 47743 the case of interfaces specified for a particular programming 47744 language, one that is widely used among developers working in that 47745 language. 47746 47747 The "System Libraries" of an executable work include anything, 47748 other than the work as a whole, that (a) is included in the normal 47749 form of packaging a Major Component, but which is not part of that 47750 Major Component, and (b) serves only to enable use of the work with 47751 that Major Component, or to implement a Standard Interface for 47752 which an implementation is available to the public in source code 47753 form. A "Major Component", in this context, means a major 47754 essential component (kernel, window system, and so on) of the 47755 specific operating system (if any) on which the executable work 47756 runs, or a compiler used to produce the work, or an object code 47757 interpreter used to run it. 47758 47759 The "Corresponding Source" for a work in object code form means all 47760 the source code needed to generate, install, and (for an executable 47761 work) run the object code and to modify the work, including scripts 47762 to control those activities. However, it does not include the 47763 work's System Libraries, or general-purpose tools or generally 47764 available free programs which are used unmodified in performing 47765 those activities but which are not part of the work. For example, 47766 Corresponding Source includes interface definition files associated 47767 with source files for the work, and the source code for shared 47768 libraries and dynamically linked subprograms that the work is 47769 specifically designed to require, such as by intimate data 47770 communication or control flow between those subprograms and other 47771 parts of the work. 47772 47773 The Corresponding Source need not include anything that users can 47774 regenerate automatically from other parts of the Corresponding 47775 Source. 47776 47777 The Corresponding Source for a work in source code form is that 47778 same work. 47779 47780 2. Basic Permissions. 47781 47782 All rights granted under this License are granted for the term of 47783 copyright on the Program, and are irrevocable provided the stated 47784 conditions are met. This License explicitly affirms your unlimited 47785 permission to run the unmodified Program. The output from running 47786 a covered work is covered by this License only if the output, given 47787 its content, constitutes a covered work. This License acknowledges 47788 your rights of fair use or other equivalent, as provided by 47789 copyright law. 47790 47791 You may make, run and propagate covered works that you do not 47792 convey, without conditions so long as your license otherwise 47793 remains in force. You may convey covered works to others for the 47794 sole purpose of having them make modifications exclusively for you, 47795 or provide you with facilities for running those works, provided 47796 that you comply with the terms of this License in conveying all 47797 material for which you do not control copyright. Those thus making 47798 or running the covered works for you must do so exclusively on your 47799 behalf, under your direction and control, on terms that prohibit 47800 them from making any copies of your copyrighted material outside 47801 their relationship with you. 47802 47803 Conveying under any other circumstances is permitted solely under 47804 the conditions stated below. Sublicensing is not allowed; section 47805 10 makes it unnecessary. 47806 47807 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 47808 47809 No covered work shall be deemed part of an effective technological 47810 measure under any applicable law fulfilling obligations under 47811 article 11 of the WIPO copyright treaty adopted on 20 December 47812 1996, or similar laws prohibiting or restricting circumvention of 47813 such measures. 47814 47815 When you convey a covered work, you waive any legal power to forbid 47816 circumvention of technological measures to the extent such 47817 circumvention is effected by exercising rights under this License 47818 with respect to the covered work, and you disclaim any intention to 47819 limit operation or modification of the work as a means of 47820 enforcing, against the work's users, your or third parties' legal 47821 rights to forbid circumvention of technological measures. 47822 47823 4. Conveying Verbatim Copies. 47824 47825 You may convey verbatim copies of the Program's source code as you 47826 receive it, in any medium, provided that you conspicuously and 47827 appropriately publish on each copy an appropriate copyright notice; 47828 keep intact all notices stating that this License and any 47829 non-permissive terms added in accord with section 7 apply to the 47830 code; keep intact all notices of the absence of any warranty; and 47831 give all recipients a copy of this License along with the Program. 47832 47833 You may charge any price or no price for each copy that you convey, 47834 and you may offer support or warranty protection for a fee. 47835 47836 5. Conveying Modified Source Versions. 47837 47838 You may convey a work based on the Program, or the modifications to 47839 produce it from the Program, in the form of source code under the 47840 terms of section 4, provided that you also meet all of these 47841 conditions: 47842 47843 a. The work must carry prominent notices stating that you 47844 modified it, and giving a relevant date. 47845 47846 b. The work must carry prominent notices stating that it is 47847 released under this License and any conditions added under 47848 section 7. This requirement modifies the requirement in 47849 section 4 to "keep intact all notices". 47850 47851 c. You must license the entire work, as a whole, under this 47852 License to anyone who comes into possession of a copy. This 47853 License will therefore apply, along with any applicable 47854 section 7 additional terms, to the whole of the work, and all 47855 its parts, regardless of how they are packaged. This License 47856 gives no permission to license the work in any other way, but 47857 it does not invalidate such permission if you have separately 47858 received it. 47859 47860 d. If the work has interactive user interfaces, each must display 47861 Appropriate Legal Notices; however, if the Program has 47862 interactive interfaces that do not display Appropriate Legal 47863 Notices, your work need not make them do so. 47864 47865 A compilation of a covered work with other separate and independent 47866 works, which are not by their nature extensions of the covered 47867 work, and which are not combined with it such as to form a larger 47868 program, in or on a volume of a storage or distribution medium, is 47869 called an "aggregate" if the compilation and its resulting 47870 copyright are not used to limit the access or legal rights of the 47871 compilation's users beyond what the individual works permit. 47872 Inclusion of a covered work in an aggregate does not cause this 47873 License to apply to the other parts of the aggregate. 47874 47875 6. Conveying Non-Source Forms. 47876 47877 You may convey a covered work in object code form under the terms 47878 of sections 4 and 5, provided that you also convey the 47879 machine-readable Corresponding Source under the terms of this 47880 License, in one of these ways: 47881 47882 a. Convey the object code in, or embodied in, a physical product 47883 (including a physical distribution medium), accompanied by the 47884 Corresponding Source fixed on a durable physical medium 47885 customarily used for software interchange. 47886 47887 b. Convey the object code in, or embodied in, a physical product 47888 (including a physical distribution medium), accompanied by a 47889 written offer, valid for at least three years and valid for as 47890 long as you offer spare parts or customer support for that 47891 product model, to give anyone who possesses the object code 47892 either (1) a copy of the Corresponding Source for all the 47893 software in the product that is covered by this License, on a 47894 durable physical medium customarily used for software 47895 interchange, for a price no more than your reasonable cost of 47896 physically performing this conveying of source, or (2) access 47897 to copy the Corresponding Source from a network server at no 47898 charge. 47899 47900 c. Convey individual copies of the object code with a copy of the 47901 written offer to provide the Corresponding Source. This 47902 alternative is allowed only occasionally and noncommercially, 47903 and only if you received the object code with such an offer, 47904 in accord with subsection 6b. 47905 47906 d. Convey the object code by offering access from a designated 47907 place (gratis or for a charge), and offer equivalent access to 47908 the Corresponding Source in the same way through the same 47909 place at no further charge. You need not require recipients 47910 to copy the Corresponding Source along with the object code. 47911 If the place to copy the object code is a network server, the 47912 Corresponding Source may be on a different server (operated by 47913 you or a third party) that supports equivalent copying 47914 facilities, provided you maintain clear directions next to the 47915 object code saying where to find the Corresponding Source. 47916 Regardless of what server hosts the Corresponding Source, you 47917 remain obligated to ensure that it is available for as long as 47918 needed to satisfy these requirements. 47919 47920 e. Convey the object code using peer-to-peer transmission, 47921 provided you inform other peers where the object code and 47922 Corresponding Source of the work are being offered to the 47923 general public at no charge under subsection 6d. 47924 47925 A separable portion of the object code, whose source code is 47926 excluded from the Corresponding Source as a System Library, need 47927 not be included in conveying the object code work. 47928 47929 A "User Product" is either (1) a "consumer product", which means 47930 any tangible personal property which is normally used for personal, 47931 family, or household purposes, or (2) anything designed or sold for 47932 incorporation into a dwelling. In determining whether a product is 47933 a consumer product, doubtful cases shall be resolved in favor of 47934 coverage. For a particular product received by a particular user, 47935 "normally used" refers to a typical or common use of that class of 47936 product, regardless of the status of the particular user or of the 47937 way in which the particular user actually uses, or expects or is 47938 expected to use, the product. A product is a consumer product 47939 regardless of whether the product has substantial commercial, 47940 industrial or non-consumer uses, unless such uses represent the 47941 only significant mode of use of the product. 47942 47943 "Installation Information" for a User Product means any methods, 47944 procedures, authorization keys, or other information required to 47945 install and execute modified versions of a covered work in that 47946 User Product from a modified version of its Corresponding Source. 47947 The information must suffice to ensure that the continued 47948 functioning of the modified object code is in no case prevented or 47949 interfered with solely because modification has been made. 47950 47951 If you convey an object code work under this section in, or with, 47952 or specifically for use in, a User Product, and the conveying 47953 occurs as part of a transaction in which the right of possession 47954 and use of the User Product is transferred to the recipient in 47955 perpetuity or for a fixed term (regardless of how the transaction 47956 is characterized), the Corresponding Source conveyed under this 47957 section must be accompanied by the Installation Information. But 47958 this requirement does not apply if neither you nor any third party 47959 retains the ability to install modified object code on the User 47960 Product (for example, the work has been installed in ROM). 47961 47962 The requirement to provide Installation Information does not 47963 include a requirement to continue to provide support service, 47964 warranty, or updates for a work that has been modified or installed 47965 by the recipient, or for the User Product in which it has been 47966 modified or installed. Access to a network may be denied when the 47967 modification itself materially and adversely affects the operation 47968 of the network or violates the rules and protocols for 47969 communication across the network. 47970 47971 Corresponding Source conveyed, and Installation Information 47972 provided, in accord with this section must be in a format that is 47973 publicly documented (and with an implementation available to the 47974 public in source code form), and must require no special password 47975 or key for unpacking, reading or copying. 47976 47977 7. Additional Terms. 47978 47979 "Additional permissions" are terms that supplement the terms of 47980 this License by making exceptions from one or more of its 47981 conditions. Additional permissions that are applicable to the 47982 entire Program shall be treated as though they were included in 47983 this License, to the extent that they are valid under applicable 47984 law. If additional permissions apply only to part of the Program, 47985 that part may be used separately under those permissions, but the 47986 entire Program remains governed by this License without regard to 47987 the additional permissions. 47988 47989 When you convey a copy of a covered work, you may at your option 47990 remove any additional permissions from that copy, or from any part 47991 of it. (Additional permissions may be written to require their own 47992 removal in certain cases when you modify the work.) You may place 47993 additional permissions on material, added by you to a covered work, 47994 for which you have or can give appropriate copyright permission. 47995 47996 Notwithstanding any other provision of this License, for material 47997 you add to a covered work, you may (if authorized by the copyright 47998 holders of that material) supplement the terms of this License with 47999 terms: 48000 48001 a. Disclaiming warranty or limiting liability differently from 48002 the terms of sections 15 and 16 of this License; or 48003 48004 b. Requiring preservation of specified reasonable legal notices 48005 or author attributions in that material or in the Appropriate 48006 Legal Notices displayed by works containing it; or 48007 48008 c. Prohibiting misrepresentation of the origin of that material, 48009 or requiring that modified versions of such material be marked 48010 in reasonable ways as different from the original version; or 48011 48012 d. Limiting the use for publicity purposes of names of licensors 48013 or authors of the material; or 48014 48015 e. Declining to grant rights under trademark law for use of some 48016 trade names, trademarks, or service marks; or 48017 48018 f. Requiring indemnification of licensors and authors of that 48019 material by anyone who conveys the material (or modified 48020 versions of it) with contractual assumptions of liability to 48021 the recipient, for any liability that these contractual 48022 assumptions directly impose on those licensors and authors. 48023 48024 All other non-permissive additional terms are considered "further 48025 restrictions" within the meaning of section 10. If the Program as 48026 you received it, or any part of it, contains a notice stating that 48027 it is governed by this License along with a term that is a further 48028 restriction, you may remove that term. If a license document 48029 contains a further restriction but permits relicensing or conveying 48030 under this License, you may add to a covered work material governed 48031 by the terms of that license document, provided that the further 48032 restriction does not survive such relicensing or conveying. 48033 48034 If you add terms to a covered work in accord with this section, you 48035 must place, in the relevant source files, a statement of the 48036 additional terms that apply to those files, or a notice indicating 48037 where to find the applicable terms. 48038 48039 Additional terms, permissive or non-permissive, may be stated in 48040 the form of a separately written license, or stated as exceptions; 48041 the above requirements apply either way. 48042 48043 8. Termination. 48044 48045 You may not propagate or modify a covered work except as expressly 48046 provided under this License. Any attempt otherwise to propagate or 48047 modify it is void, and will automatically terminate your rights 48048 under this License (including any patent licenses granted under the 48049 third paragraph of section 11). 48050 48051 However, if you cease all violation of this License, then your 48052 license from a particular copyright holder is reinstated (a) 48053 provisionally, unless and until the copyright holder explicitly and 48054 finally terminates your license, and (b) permanently, if the 48055 copyright holder fails to notify you of the violation by some 48056 reasonable means prior to 60 days after the cessation. 48057 48058 Moreover, your license from a particular copyright holder is 48059 reinstated permanently if the copyright holder notifies you of the 48060 violation by some reasonable means, this is the first time you have 48061 received notice of violation of this License (for any work) from 48062 that copyright holder, and you cure the violation prior to 30 days 48063 after your receipt of the notice. 48064 48065 Termination of your rights under this section does not terminate 48066 the licenses of parties who have received copies or rights from you 48067 under this License. If your rights have been terminated and not 48068 permanently reinstated, you do not qualify to receive new licenses 48069 for the same material under section 10. 48070 48071 9. Acceptance Not Required for Having Copies. 48072 48073 You are not required to accept this License in order to receive or 48074 run a copy of the Program. Ancillary propagation of a covered work 48075 occurring solely as a consequence of using peer-to-peer 48076 transmission to receive a copy likewise does not require 48077 acceptance. However, nothing other than this License grants you 48078 permission to propagate or modify any covered work. These actions 48079 infringe copyright if you do not accept this License. Therefore, 48080 by modifying or propagating a covered work, you indicate your 48081 acceptance of this License to do so. 48082 48083 10. Automatic Licensing of Downstream Recipients. 48084 48085 Each time you convey a covered work, the recipient automatically 48086 receives a license from the original licensors, to run, modify and 48087 propagate that work, subject to this License. You are not 48088 responsible for enforcing compliance by third parties with this 48089 License. 48090 48091 An "entity transaction" is a transaction transferring control of an 48092 organization, or substantially all assets of one, or subdividing an 48093 organization, or merging organizations. If propagation of a 48094 covered work results from an entity transaction, each party to that 48095 transaction who receives a copy of the work also receives whatever 48096 licenses to the work the party's predecessor in interest had or 48097 could give under the previous paragraph, plus a right to possession 48098 of the Corresponding Source of the work from the predecessor in 48099 interest, if the predecessor has it or can get it with reasonable 48100 efforts. 48101 48102 You may not impose any further restrictions on the exercise of the 48103 rights granted or affirmed under this License. For example, you 48104 may not impose a license fee, royalty, or other charge for exercise 48105 of rights granted under this License, and you may not initiate 48106 litigation (including a cross-claim or counterclaim in a lawsuit) 48107 alleging that any patent claim is infringed by making, using, 48108 selling, offering for sale, or importing the Program or any portion 48109 of it. 48110 48111 11. Patents. 48112 48113 A "contributor" is a copyright holder who authorizes use under this 48114 License of the Program or a work on which the Program is based. 48115 The work thus licensed is called the contributor's "contributor 48116 version". 48117 48118 A contributor's "essential patent claims" are all patent claims 48119 owned or controlled by the contributor, whether already acquired or 48120 hereafter acquired, that would be infringed by some manner, 48121 permitted by this License, of making, using, or selling its 48122 contributor version, but do not include claims that would be 48123 infringed only as a consequence of further modification of the 48124 contributor version. For purposes of this definition, "control" 48125 includes the right to grant patent sublicenses in a manner 48126 consistent with the requirements of this License. 48127 48128 Each contributor grants you a non-exclusive, worldwide, 48129 royalty-free patent license under the contributor's essential 48130 patent claims, to make, use, sell, offer for sale, import and 48131 otherwise run, modify and propagate the contents of its contributor 48132 version. 48133 48134 In the following three paragraphs, a "patent license" is any 48135 express agreement or commitment, however denominated, not to 48136 enforce a patent (such as an express permission to practice a 48137 patent or covenant not to sue for patent infringement). To "grant" 48138 such a patent license to a party means to make such an agreement or 48139 commitment not to enforce a patent against the party. 48140 48141 If you convey a covered work, knowingly relying on a patent 48142 license, and the Corresponding Source of the work is not available 48143 for anyone to copy, free of charge and under the terms of this 48144 License, through a publicly available network server or other 48145 readily accessible means, then you must either (1) cause the 48146 Corresponding Source to be so available, or (2) arrange to deprive 48147 yourself of the benefit of the patent license for this particular 48148 work, or (3) arrange, in a manner consistent with the requirements 48149 of this License, to extend the patent license to downstream 48150 recipients. "Knowingly relying" means you have actual knowledge 48151 that, but for the patent license, your conveying the covered work 48152 in a country, or your recipient's use of the covered work in a 48153 country, would infringe one or more identifiable patents in that 48154 country that you have reason to believe are valid. 48155 48156 If, pursuant to or in connection with a single transaction or 48157 arrangement, you convey, or propagate by procuring conveyance of, a 48158 covered work, and grant a patent license to some of the parties 48159 receiving the covered work authorizing them to use, propagate, 48160 modify or convey a specific copy of the covered work, then the 48161 patent license you grant is automatically extended to all 48162 recipients of the covered work and works based on it. 48163 48164 A patent license is "discriminatory" if it does not include within 48165 the scope of its coverage, prohibits the exercise of, or is 48166 conditioned on the non-exercise of one or more of the rights that 48167 are specifically granted under this License. You may not convey a 48168 covered work if you are a party to an arrangement with a third 48169 party that is in the business of distributing software, under which 48170 you make payment to the third party based on the extent of your 48171 activity of conveying the work, and under which the third party 48172 grants, to any of the parties who would receive the covered work 48173 from you, a discriminatory patent license (a) in connection with 48174 copies of the covered work conveyed by you (or copies made from 48175 those copies), or (b) primarily for and in connection with specific 48176 products or compilations that contain the covered work, unless you 48177 entered into that arrangement, or that patent license was granted, 48178 prior to 28 March 2007. 48179 48180 Nothing in this License shall be construed as excluding or limiting 48181 any implied license or other defenses to infringement that may 48182 otherwise be available to you under applicable patent law. 48183 48184 12. No Surrender of Others' Freedom. 48185 48186 If conditions are imposed on you (whether by court order, agreement 48187 or otherwise) that contradict the conditions of this License, they 48188 do not excuse you from the conditions of this License. If you 48189 cannot convey a covered work so as to satisfy simultaneously your 48190 obligations under this License and any other pertinent obligations, 48191 then as a consequence you may not convey it at all. For example, 48192 if you agree to terms that obligate you to collect a royalty for 48193 further conveying from those to whom you convey the Program, the 48194 only way you could satisfy both those terms and this License would 48195 be to refrain entirely from conveying the Program. 48196 48197 13. Use with the GNU Affero General Public License. 48198 48199 Notwithstanding any other provision of this License, you have 48200 permission to link or combine any covered work with a work licensed 48201 under version 3 of the GNU Affero General Public License into a 48202 single combined work, and to convey the resulting work. The terms 48203 of this License will continue to apply to the part which is the 48204 covered work, but the special requirements of the GNU Affero 48205 General Public License, section 13, concerning interaction through 48206 a network will apply to the combination as such. 48207 48208 14. Revised Versions of this License. 48209 48210 The Free Software Foundation may publish revised and/or new 48211 versions of the GNU General Public License from time to time. Such 48212 new versions will be similar in spirit to the present version, but 48213 may differ in detail to address new problems or concerns. 48214 48215 Each version is given a distinguishing version number. If the 48216 Program specifies that a certain numbered version of the GNU 48217 General Public License "or any later version" applies to it, you 48218 have the option of following the terms and conditions either of 48219 that numbered version or of any later version published by the Free 48220 Software Foundation. If the Program does not specify a version 48221 number of the GNU General Public License, you may choose any 48222 version ever published by the Free Software Foundation. 48223 48224 If the Program specifies that a proxy can decide which future 48225 versions of the GNU General Public License can be used, that 48226 proxy's public statement of acceptance of a version permanently 48227 authorizes you to choose that version for the Program. 48228 48229 Later license versions may give you additional or different 48230 permissions. However, no additional obligations are imposed on any 48231 author or copyright holder as a result of your choosing to follow a 48232 later version. 48233 48234 15. Disclaimer of Warranty. 48235 48236 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 48237 APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE 48238 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" 48239 WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 48240 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 48241 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE 48242 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. 48243 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL 48244 NECESSARY SERVICING, REPAIR OR CORRECTION. 48245 48246 16. Limitation of Liability. 48247 48248 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 48249 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES 48250 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR 48251 DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 48252 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE 48253 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA 48254 BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 48255 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 48256 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF 48257 THE POSSIBILITY OF SUCH DAMAGES. 48258 48259 17. Interpretation of Sections 15 and 16. 48260 48261 If the disclaimer of warranty and limitation of liability provided 48262 above cannot be given local legal effect according to their terms, 48263 reviewing courts shall apply local law that most closely 48264 approximates an absolute waiver of all civil liability in 48265 connection with the Program, unless a warranty or assumption of 48266 liability accompanies a copy of the Program in return for a fee. 48267 48268END OF TERMS AND CONDITIONS 48269=========================== 48270 48271How to Apply These Terms to Your New Programs 48272============================================= 48273 48274If you develop a new program, and you want it to be of the greatest 48275possible use to the public, the best way to achieve this is to make it 48276free software which everyone can redistribute and change under these 48277terms. 48278 48279 To do so, attach the following notices to the program. It is safest to 48280attach them to the start of each source file to most effectively state 48281the exclusion of warranty; and each file should have at least the 48282"copyright" line and a pointer to where the full notice is found. 48283 48284 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 48285 Copyright (C) YEAR NAME OF AUTHOR 48286 48287 This program is free software: you can redistribute it and/or modify 48288 it under the terms of the GNU General Public License as published by 48289 the Free Software Foundation, either version 3 of the License, or (at 48290 your option) any later version. 48291 48292 This program is distributed in the hope that it will be useful, but 48293 WITHOUT ANY WARRANTY; without even the implied warranty of 48294 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 48295 General Public License for more details. 48296 48297 You should have received a copy of the GNU General Public License 48298 along with this program. If not, see <http://www.gnu.org/licenses/>. 48299 48300 Also add information on how to contact you by electronic and paper 48301mail. 48302 48303 If the program does terminal interaction, make it output a short notice 48304like this when it starts in an interactive mode: 48305 48306 PROGRAM Copyright (C) YEAR NAME OF AUTHOR 48307 This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'. 48308 This is free software, and you are welcome to redistribute it 48309 under certain conditions; type 'show c' for details. 48310 48311 The hypothetical commands 'show w' and 'show c' should show the 48312appropriate parts of the General Public License. Of course, your 48313program's commands might be different; for a GUI interface, you would 48314use an "about box". 48315 48316 You should also get your employer (if you work as a programmer) or 48317school, if any, to sign a "copyright disclaimer" for the program, if 48318necessary. For more information on this, and how to apply and follow 48319the GNU GPL, see <http://www.gnu.org/licenses/>. 48320 48321 The GNU General Public License does not permit incorporating your 48322program into proprietary programs. If your program is a subroutine 48323library, you may consider it more useful to permit linking proprietary 48324applications with the library. If this is what you want to do, use the 48325GNU Lesser General Public License instead of this License. But first, 48326please read <https://www.gnu.org/licenses/why-not-lgpl.html>. 48327 48328 48329File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 48330 48331GNU Free Documentation License 48332****************************** 48333 48334 Version 1.3, 3 November 2008 48335 48336 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. 48337 <http://fsf.org/> 48338 48339 Everyone is permitted to copy and distribute verbatim copies 48340 of this license document, but changing it is not allowed. 48341 48342 0. PREAMBLE 48343 48344 The purpose of this License is to make a manual, textbook, or other 48345 functional and useful document "free" in the sense of freedom: to 48346 assure everyone the effective freedom to copy and redistribute it, 48347 with or without modifying it, either commercially or 48348 noncommercially. Secondarily, this License preserves for the 48349 author and publisher a way to get credit for their work, while not 48350 being considered responsible for modifications made by others. 48351 48352 This License is a kind of "copyleft", which means that derivative 48353 works of the document must themselves be free in the same sense. 48354 It complements the GNU General Public License, which is a copyleft 48355 license designed for free software. 48356 48357 We have designed this License in order to use it for manuals for 48358 free software, because free software needs free documentation: a 48359 free program should come with manuals providing the same freedoms 48360 that the software does. But this License is not limited to 48361 software manuals; it can be used for any textual work, regardless 48362 of subject matter or whether it is published as a printed book. We 48363 recommend this License principally for works whose purpose is 48364 instruction or reference. 48365 48366 1. APPLICABILITY AND DEFINITIONS 48367 48368 This License applies to any manual or other work, in any medium, 48369 that contains a notice placed by the copyright holder saying it can 48370 be distributed under the terms of this License. Such a notice 48371 grants a world-wide, royalty-free license, unlimited in duration, 48372 to use that work under the conditions stated herein. The 48373 "Document", below, refers to any such manual or work. Any member 48374 of the public is a licensee, and is addressed as "you". You accept 48375 the license if you copy, modify or distribute the work in a way 48376 requiring permission under copyright law. 48377 48378 A "Modified Version" of the Document means any work containing the 48379 Document or a portion of it, either copied verbatim, or with 48380 modifications and/or translated into another language. 48381 48382 A "Secondary Section" is a named appendix or a front-matter section 48383 of the Document that deals exclusively with the relationship of the 48384 publishers or authors of the Document to the Document's overall 48385 subject (or to related matters) and contains nothing that could 48386 fall directly within that overall subject. (Thus, if the Document 48387 is in part a textbook of mathematics, a Secondary Section may not 48388 explain any mathematics.) The relationship could be a matter of 48389 historical connection with the subject or with related matters, or 48390 of legal, commercial, philosophical, ethical or political position 48391 regarding them. 48392 48393 The "Invariant Sections" are certain Secondary Sections whose 48394 titles are designated, as being those of Invariant Sections, in the 48395 notice that says that the Document is released under this License. 48396 If a section does not fit the above definition of Secondary then it 48397 is not allowed to be designated as Invariant. The Document may 48398 contain zero Invariant Sections. If the Document does not identify 48399 any Invariant Sections then there are none. 48400 48401 The "Cover Texts" are certain short passages of text that are 48402 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 48403 that says that the Document is released under this License. A 48404 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 48405 be at most 25 words. 48406 48407 A "Transparent" copy of the Document means a machine-readable copy, 48408 represented in a format whose specification is available to the 48409 general public, that is suitable for revising the document 48410 straightforwardly with generic text editors or (for images composed 48411 of pixels) generic paint programs or (for drawings) some widely 48412 available drawing editor, and that is suitable for input to text 48413 formatters or for automatic translation to a variety of formats 48414 suitable for input to text formatters. A copy made in an otherwise 48415 Transparent file format whose markup, or absence of markup, has 48416 been arranged to thwart or discourage subsequent modification by 48417 readers is not Transparent. An image format is not Transparent if 48418 used for any substantial amount of text. A copy that is not 48419 "Transparent" is called "Opaque". 48420 48421 Examples of suitable formats for Transparent copies include plain 48422 ASCII without markup, Texinfo input format, LaTeX input format, 48423 SGML or XML using a publicly available DTD, and standard-conforming 48424 simple HTML, PostScript or PDF designed for human modification. 48425 Examples of transparent image formats include PNG, XCF and JPG. 48426 Opaque formats include proprietary formats that can be read and 48427 edited only by proprietary word processors, SGML or XML for which 48428 the DTD and/or processing tools are not generally available, and 48429 the machine-generated HTML, PostScript or PDF produced by some word 48430 processors for output purposes only. 48431 48432 The "Title Page" means, for a printed book, the title page itself, 48433 plus such following pages as are needed to hold, legibly, the 48434 material this License requires to appear in the title page. For 48435 works in formats which do not have any title page as such, "Title 48436 Page" means the text near the most prominent appearance of the 48437 work's title, preceding the beginning of the body of the text. 48438 48439 The "publisher" means any person or entity that distributes copies 48440 of the Document to the public. 48441 48442 A section "Entitled XYZ" means a named subunit of the Document 48443 whose title either is precisely XYZ or contains XYZ in parentheses 48444 following text that translates XYZ in another language. (Here XYZ 48445 stands for a specific section name mentioned below, such as 48446 "Acknowledgements", "Dedications", "Endorsements", or "History".) 48447 To "Preserve the Title" of such a section when you modify the 48448 Document means that it remains a section "Entitled XYZ" according 48449 to this definition. 48450 48451 The Document may include Warranty Disclaimers next to the notice 48452 which states that this License applies to the Document. These 48453 Warranty Disclaimers are considered to be included by reference in 48454 this License, but only as regards disclaiming warranties: any other 48455 implication that these Warranty Disclaimers may have is void and 48456 has no effect on the meaning of this License. 48457 48458 2. VERBATIM COPYING 48459 48460 You may copy and distribute the Document in any medium, either 48461 commercially or noncommercially, provided that this License, the 48462 copyright notices, and the license notice saying this License 48463 applies to the Document are reproduced in all copies, and that you 48464 add no other conditions whatsoever to those of this License. You 48465 may not use technical measures to obstruct or control the reading 48466 or further copying of the copies you make or distribute. However, 48467 you may accept compensation in exchange for copies. If you 48468 distribute a large enough number of copies you must also follow the 48469 conditions in section 3. 48470 48471 You may also lend copies, under the same conditions stated above, 48472 and you may publicly display copies. 48473 48474 3. COPYING IN QUANTITY 48475 48476 If you publish printed copies (or copies in media that commonly 48477 have printed covers) of the Document, numbering more than 100, and 48478 the Document's license notice requires Cover Texts, you must 48479 enclose the copies in covers that carry, clearly and legibly, all 48480 these Cover Texts: Front-Cover Texts on the front cover, and 48481 Back-Cover Texts on the back cover. Both covers must also clearly 48482 and legibly identify you as the publisher of these copies. The 48483 front cover must present the full title with all words of the title 48484 equally prominent and visible. You may add other material on the 48485 covers in addition. Copying with changes limited to the covers, as 48486 long as they preserve the title of the Document and satisfy these 48487 conditions, can be treated as verbatim copying in other respects. 48488 48489 If the required texts for either cover are too voluminous to fit 48490 legibly, you should put the first ones listed (as many as fit 48491 reasonably) on the actual cover, and continue the rest onto 48492 adjacent pages. 48493 48494 If you publish or distribute Opaque copies of the Document 48495 numbering more than 100, you must either include a machine-readable 48496 Transparent copy along with each Opaque copy, or state in or with 48497 each Opaque copy a computer-network location from which the general 48498 network-using public has access to download using public-standard 48499 network protocols a complete Transparent copy of the Document, free 48500 of added material. If you use the latter option, you must take 48501 reasonably prudent steps, when you begin distribution of Opaque 48502 copies in quantity, to ensure that this Transparent copy will 48503 remain thus accessible at the stated location until at least one 48504 year after the last time you distribute an Opaque copy (directly or 48505 through your agents or retailers) of that edition to the public. 48506 48507 It is requested, but not required, that you contact the authors of 48508 the Document well before redistributing any large number of copies, 48509 to give them a chance to provide you with an updated version of the 48510 Document. 48511 48512 4. MODIFICATIONS 48513 48514 You may copy and distribute a Modified Version of the Document 48515 under the conditions of sections 2 and 3 above, provided that you 48516 release the Modified Version under precisely this License, with the 48517 Modified Version filling the role of the Document, thus licensing 48518 distribution and modification of the Modified Version to whoever 48519 possesses a copy of it. In addition, you must do these things in 48520 the Modified Version: 48521 48522 A. Use in the Title Page (and on the covers, if any) a title 48523 distinct from that of the Document, and from those of previous 48524 versions (which should, if there were any, be listed in the 48525 History section of the Document). You may use the same title 48526 as a previous version if the original publisher of that 48527 version gives permission. 48528 48529 B. List on the Title Page, as authors, one or more persons or 48530 entities responsible for authorship of the modifications in 48531 the Modified Version, together with at least five of the 48532 principal authors of the Document (all of its principal 48533 authors, if it has fewer than five), unless they release you 48534 from this requirement. 48535 48536 C. State on the Title page the name of the publisher of the 48537 Modified Version, as the publisher. 48538 48539 D. Preserve all the copyright notices of the Document. 48540 48541 E. Add an appropriate copyright notice for your modifications 48542 adjacent to the other copyright notices. 48543 48544 F. Include, immediately after the copyright notices, a license 48545 notice giving the public permission to use the Modified 48546 Version under the terms of this License, in the form shown in 48547 the Addendum below. 48548 48549 G. Preserve in that license notice the full lists of Invariant 48550 Sections and required Cover Texts given in the Document's 48551 license notice. 48552 48553 H. Include an unaltered copy of this License. 48554 48555 I. Preserve the section Entitled "History", Preserve its Title, 48556 and add to it an item stating at least the title, year, new 48557 authors, and publisher of the Modified Version as given on the 48558 Title Page. If there is no section Entitled "History" in the 48559 Document, create one stating the title, year, authors, and 48560 publisher of the Document as given on its Title Page, then add 48561 an item describing the Modified Version as stated in the 48562 previous sentence. 48563 48564 J. Preserve the network location, if any, given in the Document 48565 for public access to a Transparent copy of the Document, and 48566 likewise the network locations given in the Document for 48567 previous versions it was based on. These may be placed in the 48568 "History" section. You may omit a network location for a work 48569 that was published at least four years before the Document 48570 itself, or if the original publisher of the version it refers 48571 to gives permission. 48572 48573 K. For any section Entitled "Acknowledgements" or "Dedications", 48574 Preserve the Title of the section, and preserve in the section 48575 all the substance and tone of each of the contributor 48576 acknowledgements and/or dedications given therein. 48577 48578 L. Preserve all the Invariant Sections of the Document, unaltered 48579 in their text and in their titles. Section numbers or the 48580 equivalent are not considered part of the section titles. 48581 48582 M. Delete any section Entitled "Endorsements". Such a section 48583 may not be included in the Modified Version. 48584 48585 N. Do not retitle any existing section to be Entitled 48586 "Endorsements" or to conflict in title with any Invariant 48587 Section. 48588 48589 O. Preserve any Warranty Disclaimers. 48590 48591 If the Modified Version includes new front-matter sections or 48592 appendices that qualify as Secondary Sections and contain no 48593 material copied from the Document, you may at your option designate 48594 some or all of these sections as invariant. To do this, add their 48595 titles to the list of Invariant Sections in the Modified Version's 48596 license notice. These titles must be distinct from any other 48597 section titles. 48598 48599 You may add a section Entitled "Endorsements", provided it contains 48600 nothing but endorsements of your Modified Version by various 48601 parties--for example, statements of peer review or that the text 48602 has been approved by an organization as the authoritative 48603 definition of a standard. 48604 48605 You may add a passage of up to five words as a Front-Cover Text, 48606 and a passage of up to 25 words as a Back-Cover Text, to the end of 48607 the list of Cover Texts in the Modified Version. Only one passage 48608 of Front-Cover Text and one of Back-Cover Text may be added by (or 48609 through arrangements made by) any one entity. If the Document 48610 already includes a cover text for the same cover, previously added 48611 by you or by arrangement made by the same entity you are acting on 48612 behalf of, you may not add another; but you may replace the old 48613 one, on explicit permission from the previous publisher that added 48614 the old one. 48615 48616 The author(s) and publisher(s) of the Document do not by this 48617 License give permission to use their names for publicity for or to 48618 assert or imply endorsement of any Modified Version. 48619 48620 5. COMBINING DOCUMENTS 48621 48622 You may combine the Document with other documents released under 48623 this License, under the terms defined in section 4 above for 48624 modified versions, provided that you include in the combination all 48625 of the Invariant Sections of all of the original documents, 48626 unmodified, and list them all as Invariant Sections of your 48627 combined work in its license notice, and that you preserve all 48628 their Warranty Disclaimers. 48629 48630 The combined work need only contain one copy of this License, and 48631 multiple identical Invariant Sections may be replaced with a single 48632 copy. If there are multiple Invariant Sections with the same name 48633 but different contents, make the title of each such section unique 48634 by adding at the end of it, in parentheses, the name of the 48635 original author or publisher of that section if known, or else a 48636 unique number. Make the same adjustment to the section titles in 48637 the list of Invariant Sections in the license notice of the 48638 combined work. 48639 48640 In the combination, you must combine any sections Entitled 48641 "History" in the various original documents, forming one section 48642 Entitled "History"; likewise combine any sections Entitled 48643 "Acknowledgements", and any sections Entitled "Dedications". You 48644 must delete all sections Entitled "Endorsements." 48645 48646 6. COLLECTIONS OF DOCUMENTS 48647 48648 You may make a collection consisting of the Document and other 48649 documents released under this License, and replace the individual 48650 copies of this License in the various documents with a single copy 48651 that is included in the collection, provided that you follow the 48652 rules of this License for verbatim copying of each of the documents 48653 in all other respects. 48654 48655 You may extract a single document from such a collection, and 48656 distribute it individually under this License, provided you insert 48657 a copy of this License into the extracted document, and follow this 48658 License in all other respects regarding verbatim copying of that 48659 document. 48660 48661 7. AGGREGATION WITH INDEPENDENT WORKS 48662 48663 A compilation of the Document or its derivatives with other 48664 separate and independent documents or works, in or on a volume of a 48665 storage or distribution medium, is called an "aggregate" if the 48666 copyright resulting from the compilation is not used to limit the 48667 legal rights of the compilation's users beyond what the individual 48668 works permit. When the Document is included in an aggregate, this 48669 License does not apply to the other works in the aggregate which 48670 are not themselves derivative works of the Document. 48671 48672 If the Cover Text requirement of section 3 is applicable to these 48673 copies of the Document, then if the Document is less than one half 48674 of the entire aggregate, the Document's Cover Texts may be placed 48675 on covers that bracket the Document within the aggregate, or the 48676 electronic equivalent of covers if the Document is in electronic 48677 form. Otherwise they must appear on printed covers that bracket 48678 the whole aggregate. 48679 48680 8. TRANSLATION 48681 48682 Translation is considered a kind of modification, so you may 48683 distribute translations of the Document under the terms of section 48684 4. Replacing Invariant Sections with translations requires special 48685 permission from their copyright holders, but you may include 48686 translations of some or all Invariant Sections in addition to the 48687 original versions of these Invariant Sections. You may include a 48688 translation of this License, and all the license notices in the 48689 Document, and any Warranty Disclaimers, provided that you also 48690 include the original English version of this License and the 48691 original versions of those notices and disclaimers. In case of a 48692 disagreement between the translation and the original version of 48693 this License or a notice or disclaimer, the original version will 48694 prevail. 48695 48696 If a section in the Document is Entitled "Acknowledgements", 48697 "Dedications", or "History", the requirement (section 4) to 48698 Preserve its Title (section 1) will typically require changing the 48699 actual title. 48700 48701 9. TERMINATION 48702 48703 You may not copy, modify, sublicense, or distribute the Document 48704 except as expressly provided under this License. Any attempt 48705 otherwise to copy, modify, sublicense, or distribute it is void, 48706 and will automatically terminate your rights under this License. 48707 48708 However, if you cease all violation of this License, then your 48709 license from a particular copyright holder is reinstated (a) 48710 provisionally, unless and until the copyright holder explicitly and 48711 finally terminates your license, and (b) permanently, if the 48712 copyright holder fails to notify you of the violation by some 48713 reasonable means prior to 60 days after the cessation. 48714 48715 Moreover, your license from a particular copyright holder is 48716 reinstated permanently if the copyright holder notifies you of the 48717 violation by some reasonable means, this is the first time you have 48718 received notice of violation of this License (for any work) from 48719 that copyright holder, and you cure the violation prior to 30 days 48720 after your receipt of the notice. 48721 48722 Termination of your rights under this section does not terminate 48723 the licenses of parties who have received copies or rights from you 48724 under this License. If your rights have been terminated and not 48725 permanently reinstated, receipt of a copy of some or all of the 48726 same material does not give you any rights to use it. 48727 48728 10. FUTURE REVISIONS OF THIS LICENSE 48729 48730 The Free Software Foundation may publish new, revised versions of 48731 the GNU Free Documentation License from time to time. Such new 48732 versions will be similar in spirit to the present version, but may 48733 differ in detail to address new problems or concerns. See 48734 <http://www.gnu.org/copyleft/>. 48735 48736 Each version of the License is given a distinguishing version 48737 number. If the Document specifies that a particular numbered 48738 version of this License "or any later version" applies to it, you 48739 have the option of following the terms and conditions either of 48740 that specified version or of any later version that has been 48741 published (not as a draft) by the Free Software Foundation. If the 48742 Document does not specify a version number of this License, you may 48743 choose any version ever published (not as a draft) by the Free 48744 Software Foundation. If the Document specifies that a proxy can 48745 decide which future versions of this License can be used, that 48746 proxy's public statement of acceptance of a version permanently 48747 authorizes you to choose that version for the Document. 48748 48749 11. RELICENSING 48750 48751 "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 48752 World Wide Web server that publishes copyrightable works and also 48753 provides prominent facilities for anybody to edit those works. A 48754 public wiki that anybody can edit is an example of such a server. 48755 A "Massive Multiauthor Collaboration" (or "MMC") contained in the 48756 site means any set of copyrightable works thus published on the MMC 48757 site. 48758 48759 "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 48760 license published by Creative Commons Corporation, a not-for-profit 48761 corporation with a principal place of business in San Francisco, 48762 California, as well as future copyleft versions of that license 48763 published by that same organization. 48764 48765 "Incorporate" means to publish or republish a Document, in whole or 48766 in part, as part of another Document. 48767 48768 An MMC is "eligible for relicensing" if it is licensed under this 48769 License, and if all works that were first published under this 48770 License somewhere other than this MMC, and subsequently 48771 incorporated in whole or in part into the MMC, (1) had no cover 48772 texts or invariant sections, and (2) were thus incorporated prior 48773 to November 1, 2008. 48774 48775 The operator of an MMC Site may republish an MMC contained in the 48776 site under CC-BY-SA on the same site at any time before August 1, 48777 2009, provided the MMC is eligible for relicensing. 48778 48779ADDENDUM: How to use this License for your documents 48780==================================================== 48781 48782To use this License in a document you have written, include a copy of 48783the License in the document and put the following copyright and license 48784notices just after the title page: 48785 48786 Copyright (C) YEAR YOUR NAME. 48787 Permission is granted to copy, distribute and/or modify this document 48788 under the terms of the GNU Free Documentation License, Version 1.3 48789 or any later version published by the Free Software Foundation; 48790 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 48791 Texts. A copy of the license is included in the section entitled ``GNU 48792 Free Documentation License''. 48793 48794 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 48795replace the "with...Texts." line with this: 48796 48797 with the Invariant Sections being LIST THEIR TITLES, with 48798 the Front-Cover Texts being LIST, and with the Back-Cover Texts 48799 being LIST. 48800 48801 If you have Invariant Sections without Cover Texts, or some other 48802combination of the three, merge those two alternatives to suit the 48803situation. 48804 48805 If your document contains nontrivial examples of program code, we 48806recommend releasing these examples in parallel under your choice of free 48807software license, such as the GNU General Public License, to permit 48808their use in free software. 48809 48810 48811File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 48812 48813Contributors to GCC 48814******************* 48815 48816The GCC project would like to thank its many contributors. Without them 48817the project would not have been nearly as successful as it has been. 48818Any omissions in this list are accidental. Feel free to contact 48819<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or 48820some of your contributions are not listed. Please keep this list in 48821alphabetical order. 48822 48823 * Analog Devices helped implement the support for complex data types 48824 and iterators. 48825 48826 * John David Anglin for threading-related fixes and improvements to 48827 libstdc++-v3, and the HP-UX port. 48828 48829 * James van Artsdalen wrote the code that makes efficient use of the 48830 Intel 80387 register stack. 48831 48832 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 48833 Series port. 48834 48835 * Alasdair Baird for various bug fixes. 48836 48837 * Giovanni Bajo for analyzing lots of complicated C++ problem 48838 reports. 48839 48840 * Peter Barada for his work to improve code generation for new 48841 ColdFire cores. 48842 48843 * Gerald Baumgartner added the signature extension to the C++ front 48844 end. 48845 48846 * Godmar Back for his Java improvements and encouragement. 48847 48848 * Scott Bambrough for help porting the Java compiler. 48849 48850 * Wolfgang Bangerth for processing tons of bug reports. 48851 48852 * Jon Beniston for his Microsoft Windows port of Java and port to 48853 Lattice Mico32. 48854 48855 * Daniel Berlin for better DWARF 2 support, faster/better 48856 optimizations, improved alias analysis, plus migrating GCC to 48857 Bugzilla. 48858 48859 * Geoff Berry for his Java object serialization work and various 48860 patches. 48861 48862 * David Binderman tests weekly snapshots of GCC trunk against Fedora 48863 Rawhide for several architectures. 48864 48865 * Laurynas Biveinis for memory management work and DJGPP port fixes. 48866 48867 * Uros Bizjak for the implementation of x87 math built-in functions 48868 and for various middle end and i386 back end improvements and bug 48869 fixes. 48870 48871 * Eric Blake for helping to make GCJ and libgcj conform to the 48872 specifications. 48873 48874 * Janne Blomqvist for contributions to GNU Fortran. 48875 48876 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 48877 other Java work. 48878 48879 * Segher Boessenkool for helping maintain the PowerPC port and the 48880 instruction combiner plus various contributions to the middle end. 48881 48882 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 48883 miscellaneous clean-ups. 48884 48885 * Steven Bosscher for integrating the GNU Fortran front end into GCC 48886 and for contributing to the tree-ssa branch. 48887 48888 * Eric Botcazou for fixing middle- and backend bugs left and right. 48889 48890 * Per Bothner for his direction via the steering committee and 48891 various improvements to the infrastructure for supporting new 48892 languages. Chill front end implementation. Initial 48893 implementations of cpplib, fix-header, config.guess, libio, and 48894 past C++ library (libg++) maintainer. Dreaming up, designing and 48895 implementing much of GCJ. 48896 48897 * Devon Bowen helped port GCC to the Tahoe. 48898 48899 * Don Bowman for mips-vxworks contributions. 48900 48901 * James Bowman for the FT32 port. 48902 48903 * Dave Brolley for work on cpplib and Chill. 48904 48905 * Paul Brook for work on the ARM architecture and maintaining GNU 48906 Fortran. 48907 48908 * Robert Brown implemented the support for Encore 32000 systems. 48909 48910 * Christian Bruel for improvements to local store elimination. 48911 48912 * Herman A.J. ten Brugge for various fixes. 48913 48914 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 48915 FAQ. 48916 48917 * Joe Buck for his direction via the steering committee from its 48918 creation to 2013. 48919 48920 * Iain Buclaw for the D frontend. 48921 48922 * Craig Burley for leadership of the G77 Fortran effort. 48923 48924 * Tobias Burnus for contributions to GNU Fortran. 48925 48926 * Stephan Buys for contributing Doxygen notes for libstdc++. 48927 48928 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 48929 to the C++ strings, streambufs and formatted I/O, hard detective 48930 work on the frustrating localization issues, and keeping up with 48931 the problem reports. 48932 48933 * John Carr for his alias work, SPARC hacking, infrastructure 48934 improvements, previous contributions to the steering committee, 48935 loop optimizations, etc. 48936 48937 * Stephane Carrez for 68HC11 and 68HC12 ports. 48938 48939 * Steve Chamberlain for support for the Renesas SH and H8 processors 48940 and the PicoJava processor, and for GCJ config fixes. 48941 48942 * Glenn Chambers for help with the GCJ FAQ. 48943 48944 * John-Marc Chandonia for various libgcj patches. 48945 48946 * Denis Chertykov for contributing and maintaining the AVR port, the 48947 first GCC port for an 8-bit architecture. 48948 48949 * Kito Cheng for his work on the RISC-V port, including bringing up 48950 the test suite and maintenance. 48951 48952 * Scott Christley for his Objective-C contributions. 48953 48954 * Eric Christopher for his Java porting help and clean-ups. 48955 48956 * Branko Cibej for more warning contributions. 48957 48958 * The GNU Classpath project for all of their merged runtime code. 48959 48960 * Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work, 48961 '--help', and other random hacking. 48962 48963 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 48964 48965 * R. Kelley Cook for making GCC buildable from a read-only directory 48966 as well as other miscellaneous build process and documentation 48967 clean-ups. 48968 48969 * Ralf Corsepius for SH testing and minor bug fixing. 48970 48971 * Franc,ois-Xavier Coudert for contributions to GNU Fortran. 48972 48973 * Stan Cox for care and feeding of the x86 port and lots of behind 48974 the scenes hacking. 48975 48976 * Alex Crain provided changes for the 3b1. 48977 48978 * Ian Dall for major improvements to the NS32k port. 48979 48980 * Paul Dale for his work to add uClinux platform support to the m68k 48981 backend. 48982 48983 * Palmer Dabbelt for his work maintaining the RISC-V port. 48984 48985 * Dario Dariol contributed the four varieties of sample programs that 48986 print a copy of their source. 48987 48988 * Russell Davidson for fstream and stringstream fixes in libstdc++. 48989 48990 * Bud Davis for work on the G77 and GNU Fortran compilers. 48991 48992 * Mo DeJong for GCJ and libgcj bug fixes. 48993 48994 * Jerry DeLisle for contributions to GNU Fortran. 48995 48996 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 48997 various bug fixes, and the M32C, MeP, MSP430, and RL78 ports. 48998 48999 * Arnaud Desitter for helping to debug GNU Fortran. 49000 49001 * Gabriel Dos Reis for contributions to G++, contributions and 49002 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 49003 including 'valarray<>', 'complex<>', maintaining the numerics 49004 library (including that pesky '<limits>' :-) and keeping up-to-date 49005 anything to do with numbers. 49006 49007 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 49008 ISO C99 support, CFG dumping support, etc., plus support of the C++ 49009 runtime libraries including for all kinds of C interface issues, 49010 contributing and maintaining 'complex<>', sanity checking and 49011 disbursement, configuration architecture, libio maintenance, and 49012 early math work. 49013 49014 * Franc,ois Dumont for his work on libstdc++-v3, especially 49015 maintaining and improving 'debug-mode' and associative and 49016 unordered containers. 49017 49018 * Zdenek Dvorak for a new loop unroller and various fixes. 49019 49020 * Michael Eager for his work on the Xilinx MicroBlaze port. 49021 49022 * Richard Earnshaw for his ongoing work with the ARM. 49023 49024 * David Edelsohn for his direction via the steering committee, 49025 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 49026 loop changes, doing the entire AIX port of libstdc++ with his bare 49027 hands, and for ensuring GCC properly keeps working on AIX. 49028 49029 * Kevin Ediger for the floating point formatting of num_put::do_put 49030 in libstdc++. 49031 49032 * Phil Edwards for libstdc++ work including configuration hackery, 49033 documentation maintainer, chief breaker of the web pages, the 49034 occasional iostream bug fix, and work on shared library symbol 49035 versioning. 49036 49037 * Paul Eggert for random hacking all over GCC. 49038 49039 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 49040 configuration support for locales and fstream-related fixes. 49041 49042 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 49043 iostreams. 49044 49045 * Christian Ehrhardt for dealing with bug reports. 49046 49047 * Ben Elliston for his work to move the Objective-C runtime into its 49048 own subdirectory and for his work on autoconf. 49049 49050 * Revital Eres for work on the PowerPC 750CL port. 49051 49052 * Marc Espie for OpenBSD support. 49053 49054 * Doug Evans for much of the global optimization framework, arc, 49055 m32r, and SPARC work. 49056 49057 * Christopher Faylor for his work on the Cygwin port and for caring 49058 and feeding the gcc.gnu.org box and saving its users tons of spam. 49059 49060 * Fred Fish for BeOS support and Ada fixes. 49061 49062 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 49063 49064 * Peter Gerwinski for various bug fixes and the Pascal front end. 49065 49066 * Kaveh R. Ghazi for his direction via the steering committee, 49067 amazing work to make '-W -Wall -W* -Werror' useful, and testing GCC 49068 on a plethora of platforms. Kaveh extends his gratitude to the 49069 CAIP Center at Rutgers University for providing him with computing 49070 resources to work on Free Software from the late 1980s to 2010. 49071 49072 * John Gilmore for a donation to the FSF earmarked improving GNU 49073 Java. 49074 49075 * Judy Goldberg for c++ contributions. 49076 49077 * Torbjorn Granlund for various fixes and the c-torture testsuite, 49078 multiply- and divide-by-constant optimization, improved long long 49079 support, improved leaf function register allocation, and his 49080 direction via the steering committee. 49081 49082 * Jonny Grant for improvements to 'collect2's' '--help' 49083 documentation. 49084 49085 * Anthony Green for his '-Os' contributions, the moxie port, and Java 49086 front end work. 49087 49088 * Stu Grossman for gdb hacking, allowing GCJ developers to debug Java 49089 code. 49090 49091 * Michael K. Gschwind contributed the port to the PDP-11. 49092 49093 * Richard Biener for his ongoing middle-end contributions and bug 49094 fixes and for release management. 49095 49096 * Ron Guilmette implemented the 'protoize' and 'unprotoize' tools, 49097 the support for DWARF 1 symbolic debugging information, and much of 49098 the support for System V Release 4. He has also worked heavily on 49099 the Intel 386 and 860 support. 49100 49101 * Sumanth Gundapaneni for contributing the CR16 port. 49102 49103 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 49104 GCSE. 49105 49106 * Bruno Haible for improvements in the runtime overhead for EH, new 49107 warnings and assorted bug fixes. 49108 49109 * Andrew Haley for his amazing Java compiler and library efforts. 49110 49111 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 49112 series 300. 49113 49114 * Michael Hayes for various thankless work he's done trying to get 49115 the c30/c40 ports functional. Lots of loop and unroll improvements 49116 and fixes. 49117 49118 * Dara Hazeghi for wading through myriads of target-specific bug 49119 reports. 49120 49121 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 49122 49123 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 49124 work, loop opts, and generally fixing lots of old problems we've 49125 ignored for years, flow rewrite and lots of further stuff, 49126 including reviewing tons of patches. 49127 49128 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 49129 various fixes. 49130 49131 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 49132 contributed the support for the Sony NEWS machine. 49133 49134 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 49135 various fixes. 49136 49137 * Katherine Holcomb for work on GNU Fortran. 49138 49139 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 49140 of testing and bug fixing, particularly of GCC configury code. 49141 49142 * Steve Holmgren for MachTen patches. 49143 49144 * Mat Hostetter for work on the TILE-Gx and TILEPro ports. 49145 49146 * Jan Hubicka for his x86 port improvements. 49147 49148 * Falk Hueffner for working on C and optimization bug reports. 49149 49150 * Bernardo Innocenti for his m68k work, including merging of ColdFire 49151 improvements and uClinux support. 49152 49153 * Christian Iseli for various bug fixes. 49154 49155 * Kamil Iskra for general m68k hacking. 49156 49157 * Lee Iverson for random fixes and MIPS testing. 49158 49159 * Balaji V. Iyer for Cilk+ development and merging. 49160 49161 * Andreas Jaeger for testing and benchmarking of GCC and various bug 49162 fixes. 49163 49164 * Martin Jambor for his work on inter-procedural optimizations, the 49165 switch conversion pass, and scalar replacement of aggregates. 49166 49167 * Jakub Jelinek for his SPARC work and sibling call optimizations as 49168 well as lots of bug fixes and test cases, and for improving the 49169 Java build system. 49170 49171 * Janis Johnson for ia64 testing and fixes, her quality improvement 49172 sidetracks, and web page maintenance. 49173 49174 * Kean Johnston for SCO OpenServer support and various fixes. 49175 49176 * Tim Josling for the sample language treelang based originally on 49177 Richard Kenner's "toy" language. 49178 49179 * Nicolai Josuttis for additional libstdc++ documentation. 49180 49181 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 49182 target. 49183 49184 * Steven G. Kargl for work on GNU Fortran. 49185 49186 * David Kashtan of SRI adapted GCC to VMS. 49187 49188 * Ryszard Kabatek for many, many libstdc++ bug fixes and 49189 optimizations of strings, especially member functions, and for 49190 auto_ptr fixes. 49191 49192 * Geoffrey Keating for his ongoing work to make the PPC work for 49193 GNU/Linux and his automatic regression tester. 49194 49195 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 49196 work in just about every part of libstdc++. 49197 49198 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 49199 MIL-STD-1750A. 49200 49201 * Richard Kenner of the New York University Ultracomputer Research 49202 Laboratory wrote the machine descriptions for the AMD 29000, the 49203 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 49204 support for instruction attributes. He also made changes to better 49205 support RISC processors including changes to common subexpression 49206 elimination, strength reduction, function calling sequence 49207 handling, and condition code support, in addition to generalizing 49208 the code for frame pointer elimination and delay slot scheduling. 49209 Richard Kenner was also the head maintainer of GCC for several 49210 years. 49211 49212 * Mumit Khan for various contributions to the Cygwin and Mingw32 49213 ports and maintaining binary releases for Microsoft Windows hosts, 49214 and for massive libstdc++ porting work to Cygwin/Mingw32. 49215 49216 * Robin Kirkham for cpu32 support. 49217 49218 * Mark Klein for PA improvements. 49219 49220 * Thomas Koenig for various bug fixes. 49221 49222 * Bruce Korb for the new and improved fixincludes code. 49223 49224 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 49225 effort. 49226 49227 * Maxim Kuvyrkov for contributions to the instruction scheduler, the 49228 Android and m68k/Coldfire ports, and optimizations. 49229 49230 * Charles LaBrec contributed the support for the Integrated Solutions 49231 68020 system. 49232 49233 * Asher Langton and Mike Kumbera for contributing Cray pointer 49234 support to GNU Fortran, and for other GNU Fortran improvements. 49235 49236 * Jeff Law for his direction via the steering committee, coordinating 49237 the entire egcs project and GCC 2.95, rolling out snapshots and 49238 releases, handling merges from GCC2, reviewing tons of patches that 49239 might have fallen through the cracks else, and random but extensive 49240 hacking. 49241 49242 * Walter Lee for work on the TILE-Gx and TILEPro ports. 49243 49244 * Marc Lehmann for his direction via the steering committee and 49245 helping with analysis and improvements of x86 performance. 49246 49247 * Victor Leikehman for work on GNU Fortran. 49248 49249 * Ted Lemon wrote parts of the RTL reader and printer. 49250 49251 * Kriang Lerdsuwanakij for C++ improvements including template as 49252 template parameter support, and many C++ fixes. 49253 49254 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 49255 and random work on the Java front end. 49256 49257 * Alain Lichnewsky ported GCC to the MIPS CPU. 49258 49259 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 49260 and patches. 49261 49262 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 49263 49264 * Chen Liqin for various S+core related fixes/improvement, and for 49265 maintaining the S+core port. 49266 49267 * Martin Liska for his work on identical code folding, the 49268 sanitizers, HSA, general bug fixing and for running automated 49269 regression testing of GCC and reporting numerous bugs. 49270 49271 * Weiwen Liu for testing and various bug fixes. 49272 49273 * Manuel Lo'pez-Iba'n~ez for improving '-Wconversion' and many other 49274 diagnostics fixes and improvements. 49275 49276 * Dave Love for his ongoing work with the Fortran front end and 49277 runtime libraries. 49278 49279 * Martin von Lo"wis for internal consistency checking infrastructure, 49280 various C++ improvements including namespace support, and tons of 49281 assistance with libstdc++/compiler merges. 49282 49283 * H.J. Lu for his previous contributions to the steering committee, 49284 many x86 bug reports, prototype patches, and keeping the GNU/Linux 49285 ports working. 49286 49287 * Greg McGary for random fixes and (someday) bounded pointers. 49288 49289 * Andrew MacLeod for his ongoing work in building a real EH system, 49290 various code generation improvements, work on the global optimizer, 49291 etc. 49292 49293 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 49294 hacking improvements to compile-time performance, overall knowledge 49295 and direction in the area of instruction scheduling, design and 49296 implementation of the automaton based instruction scheduler and 49297 design and implementation of the integrated and local register 49298 allocators. 49299 49300 * David Malcolm for his work on improving GCC diagnostics, JIT, 49301 self-tests and unit testing. 49302 49303 * Bob Manson for his behind the scenes work on dejagnu. 49304 49305 * John Marino for contributing the DragonFly BSD port. 49306 49307 * Philip Martin for lots of libstdc++ string and vector iterator 49308 fixes and improvements, and string clean up and testsuites. 49309 49310 * Michael Matz for his work on dominance tree discovery, the x86-64 49311 port, link-time optimization framework and general optimization 49312 improvements. 49313 49314 * All of the Mauve project contributors for Java test code. 49315 49316 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 49317 49318 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 49319 49320 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 49321 powerpc, haifa, ECOFF debug support, and other assorted hacking. 49322 49323 * Jason Merrill for his direction via the steering committee and 49324 leading the G++ effort. 49325 49326 * Martin Michlmayr for testing GCC on several architectures using the 49327 entire Debian archive. 49328 49329 * David Miller for his direction via the steering committee, lots of 49330 SPARC work, improvements in jump.c and interfacing with the Linux 49331 kernel developers. 49332 49333 * Gary Miller ported GCC to Charles River Data Systems machines. 49334 49335 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 49336 the entire libstdc++ testsuite namespace-compatible. 49337 49338 * Mark Mitchell for his direction via the steering committee, 49339 mountains of C++ work, load/store hoisting out of loops, alias 49340 analysis improvements, ISO C 'restrict' support, and serving as 49341 release manager from 2000 to 2011. 49342 49343 * Alan Modra for various GNU/Linux bits and testing. 49344 49345 * Toon Moene for his direction via the steering committee, Fortran 49346 maintenance, and his ongoing work to make us make Fortran run fast. 49347 49348 * Jason Molenda for major help in the care and feeding of all the 49349 services on the gcc.gnu.org (formerly egcs.cygnus.com) 49350 machine--mail, web services, ftp services, etc etc. Doing all this 49351 work on scrap paper and the backs of envelopes would have been... 49352 difficult. 49353 49354 * Catherine Moore for fixing various ugly problems we have sent her 49355 way, including the haifa bug which was killing the Alpha & PowerPC 49356 Linux kernels. 49357 49358 * Mike Moreton for his various Java patches. 49359 49360 * David Mosberger-Tang for various Alpha improvements, and for the 49361 initial IA-64 port. 49362 49363 * Stephen Moshier contributed the floating point emulator that 49364 assists in cross-compilation and permits support for floating point 49365 numbers wider than 64 bits and for ISO C99 support. 49366 49367 * Bill Moyer for his behind the scenes work on various issues. 49368 49369 * Philippe De Muyter for his work on the m68k port. 49370 49371 * Joseph S. Myers for his work on the PDP-11 port, format checking 49372 and ISO C99 support, and continuous emphasis on (and contributions 49373 to) documentation. 49374 49375 * Nathan Myers for his work on libstdc++-v3: architecture and 49376 authorship through the first three snapshots, including 49377 implementation of locale infrastructure, string, shadow C headers, 49378 and the initial project documentation (DESIGN, CHECKLIST, and so 49379 forth). Later, more work on MT-safe string and shadow headers. 49380 49381 * Felix Natter for documentation on porting libstdc++. 49382 49383 * Nathanael Nerode for cleaning up the configuration/build process. 49384 49385 * NeXT, Inc. donated the front end that supports the Objective-C 49386 language. 49387 49388 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the 49389 search engine setup, various documentation fixes and other small 49390 fixes. 49391 49392 * Geoff Noer for his work on getting cygwin native builds working. 49393 49394 * Vegard Nossum for running automated regression testing of GCC and 49395 reporting numerous bugs. 49396 49397 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 49398 tracking web pages, GIMPLE tuples, and assorted fixes. 49399 49400 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 49401 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and related 49402 infrastructure improvements. 49403 49404 * Alexandre Oliva for various build infrastructure improvements, 49405 scripts and amazing testing work, including keeping libtool issues 49406 sane and happy. 49407 49408 * Stefan Olsson for work on mt_alloc. 49409 49410 * Melissa O'Neill for various NeXT fixes. 49411 49412 * Rainer Orth for random MIPS work, including improvements to GCC's 49413 o32 ABI support, improvements to dejagnu's MIPS support, Java 49414 configuration clean-ups and porting work, and maintaining the IRIX, 49415 Solaris 2, and Tru64 UNIX ports. 49416 49417 * Steven Pemberton for his contribution of 'enquire' which allowed 49418 GCC to determine various properties of the floating point unit and 49419 generate 'float.h' in older versions of GCC. 49420 49421 * Hartmut Penner for work on the s390 port. 49422 49423 * Paul Petersen wrote the machine description for the Alliant FX/8. 49424 49425 * Alexandre Petit-Bianco for implementing much of the Java compiler 49426 and continued Java maintainership. 49427 49428 * Matthias Pfaller for major improvements to the NS32k port. 49429 49430 * Gerald Pfeifer for his direction via the steering committee, 49431 pointing out lots of problems we need to solve, maintenance of the 49432 web pages, and taking care of documentation maintenance in general. 49433 49434 * Marek Polacek for his work on the C front end, the sanitizers and 49435 general bug fixing. 49436 49437 * Andrew Pinski for processing bug reports by the dozen. 49438 49439 * Ovidiu Predescu for his work on the Objective-C front end and 49440 runtime libraries. 49441 49442 * Jerry Quinn for major performance improvements in C++ formatted 49443 I/O. 49444 49445 * Ken Raeburn for various improvements to checker, MIPS ports and 49446 various cleanups in the compiler. 49447 49448 * Rolf W. Rasmussen for hacking on AWT. 49449 49450 * David Reese of Sun Microsystems contributed to the Solaris on 49451 PowerPC port. 49452 49453 * John Regehr for running automated regression testing of GCC and 49454 reporting numerous bugs. 49455 49456 * Volker Reichelt for running automated regression testing of GCC and 49457 reporting numerous bugs and for keeping up with the problem 49458 reports. 49459 49460 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 49461 hacking and developing and maintaining the Epiphany port. 49462 49463 * Loren J. Rittle for improvements to libstdc++-v3 including the 49464 FreeBSD port, threading fixes, thread-related configury changes, 49465 critical threading documentation, and solutions to really tricky 49466 I/O problems, as well as keeping GCC properly working on FreeBSD 49467 and continuous testing. 49468 49469 * Craig Rodrigues for processing tons of bug reports. 49470 49471 * Ola Ro"nnerup for work on mt_alloc. 49472 49473 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 49474 49475 * David Ronis inspired and encouraged Craig to rewrite the G77 49476 documentation in texinfo format by contributing a first pass at a 49477 translation of the old 'g77-0.5.16/f/DOC' file. 49478 49479 * Ken Rose for fixes to GCC's delay slot filling code. 49480 49481 * Ira Rosen for her contributions to the auto-vectorizer. 49482 49483 * Paul Rubin wrote most of the preprocessor. 49484 49485 * Pe'tur Runo'lfsson for major performance improvements in C++ 49486 formatted I/O and large file support in C++ filebuf. 49487 49488 * Chip Salzenberg for libstdc++ patches and improvements to locales, 49489 traits, Makefiles, libio, libtool hackery, and "long long" support. 49490 49491 * Juha Sarlin for improvements to the H8 code generator. 49492 49493 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 49494 300. 49495 49496 * Roger Sayle for improvements to constant folding and GCC's RTL 49497 optimizers as well as for fixing numerous bugs. 49498 49499 * Bradley Schatz for his work on the GCJ FAQ. 49500 49501 * Peter Schauer wrote the code to allow debugging to work on the 49502 Alpha. 49503 49504 * William Schelter did most of the work on the Intel 80386 support. 49505 49506 * Tobias Schlu"ter for work on GNU Fortran. 49507 49508 * Bernd Schmidt for various code generation improvements and major 49509 work in the reload pass, serving as release manager for GCC 2.95.3, 49510 and work on the Blackfin and C6X ports. 49511 49512 * Peter Schmid for constant testing of libstdc++--especially 49513 application testing, going above and beyond what was requested for 49514 the release criteria--and libstdc++ header file tweaks. 49515 49516 * Jason Schroeder for jcf-dump patches. 49517 49518 * Andreas Schwab for his work on the m68k port. 49519 49520 * Lars Segerlund for work on GNU Fortran. 49521 49522 * Dodji Seketeli for numerous C++ bug fixes and debug info 49523 improvements. 49524 49525 * Tim Shen for major work on '<regex>'. 49526 49527 * Joel Sherrill for his direction via the steering committee, RTEMS 49528 contributions and RTEMS testing. 49529 49530 * Nathan Sidwell for many C++ fixes/improvements. 49531 49532 * Jeffrey Siegal for helping RMS with the original design of GCC, 49533 some code which handles the parse tree and RTL data structures, 49534 constant folding and help with the original VAX & m68k ports. 49535 49536 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 49537 from the LWG (thereby keeping GCC in line with updates from the 49538 ISO). 49539 49540 * Franz Sirl for his ongoing work with making the PPC port stable for 49541 GNU/Linux. 49542 49543 * Andrey Slepuhin for assorted AIX hacking. 49544 49545 * Trevor Smigiel for contributing the SPU port. 49546 49547 * Christopher Smith did the port for Convex machines. 49548 49549 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 49550 Retired from GCC maintainership August 2010, having mentored two 49551 new maintainers into the role. 49552 49553 * Randy Smith finished the Sun FPA support. 49554 49555 * Ed Smith-Rowland for his continuous work on libstdc++-v3, special 49556 functions, '<random>', and various improvements to C++11 features. 49557 49558 * Scott Snyder for queue, iterator, istream, and string fixes and 49559 libstdc++ testsuite entries. Also for providing the patch to G77 49560 to add rudimentary support for 'INTEGER*1', 'INTEGER*2', and 49561 'LOGICAL*1'. 49562 49563 * Zdenek Sojka for running automated regression testing of GCC and 49564 reporting numerous bugs. 49565 49566 * Arseny Solokha for running automated regression testing of GCC and 49567 reporting numerous bugs. 49568 49569 * Jayant Sonar for contributing the CR16 port. 49570 49571 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 49572 49573 * Richard Stallman, for writing the original GCC and launching the 49574 GNU project. 49575 49576 * Jan Stein of the Chalmers Computer Society provided support for 49577 Genix, as well as part of the 32000 machine description. 49578 49579 * Gerhard Steinmetz for running automated regression testing of GCC 49580 and reporting numerous bugs. 49581 49582 * Nigel Stephens for various mips16 related fixes/improvements. 49583 49584 * Jonathan Stone wrote the machine description for the Pyramid 49585 computer. 49586 49587 * Graham Stott for various infrastructure improvements. 49588 49589 * John Stracke for his Java HTTP protocol fixes. 49590 49591 * Mike Stump for his Elxsi port, G++ contributions over the years and 49592 more recently his vxworks contributions 49593 49594 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 49595 49596 * Zhendong Su for running automated regression testing of GCC and 49597 reporting numerous bugs. 49598 49599 * Chengnian Sun for running automated regression testing of GCC and 49600 reporting numerous bugs. 49601 49602 * Shigeya Suzuki for this fixes for the bsdi platforms. 49603 49604 * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64 49605 support, general configury hacking, fixincludes, etc. 49606 49607 * Holger Teutsch provided the support for the Clipper CPU. 49608 49609 * Gary Thomas for his ongoing work to make the PPC work for 49610 GNU/Linux. 49611 49612 * Paul Thomas for contributions to GNU Fortran. 49613 49614 * Philipp Thomas for random bug fixes throughout the compiler 49615 49616 * Jason Thorpe for thread support in libstdc++ on NetBSD. 49617 49618 * Kresten Krab Thorup wrote the run time support for the Objective-C 49619 language and the fantastic Java bytecode interpreter. 49620 49621 * Michael Tiemann for random bug fixes, the first instruction 49622 scheduler, initial C++ support, function integration, NS32k, SPARC 49623 and M88k machine description work, delay slot scheduling. 49624 49625 * Andreas Tobler for his work porting libgcj to Darwin. 49626 49627 * Teemu Torma for thread safe exception handling support. 49628 49629 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 49630 definitions, and of the VAX machine description. 49631 49632 * Daniel Towner and Hariharan Sandanagobalane contributed and 49633 maintain the picoChip port. 49634 49635 * Tom Tromey for internationalization support and for his many Java 49636 contributions and libgcj maintainership. 49637 49638 * Lassi Tuura for improvements to config.guess to determine HP 49639 processor types. 49640 49641 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 49642 49643 * Andy Vaught for the design and initial implementation of the GNU 49644 Fortran front end. 49645 49646 * Brent Verner for work with the libstdc++ cshadow files and their 49647 associated configure steps. 49648 49649 * Todd Vierling for contributions for NetBSD ports. 49650 49651 * Andrew Waterman for contributing the RISC-V port, as well as 49652 maintaining it. 49653 49654 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 49655 guidance and maintaining libstdc++. 49656 49657 * Dean Wakerley for converting the install documentation from HTML to 49658 texinfo in time for GCC 3.0. 49659 49660 * Krister Walfridsson for random bug fixes. 49661 49662 * Feng Wang for contributions to GNU Fortran. 49663 49664 * Stephen M. Webb for time and effort on making libstdc++ shadow 49665 files work with the tricky Solaris 8+ headers, and for pushing the 49666 build-time header tree. Also, for starting and driving the 49667 '<regex>' effort. 49668 49669 * John Wehle for various improvements for the x86 code generator, 49670 related infrastructure improvements to help x86 code generation, 49671 value range propagation and other work, WE32k port. 49672 49673 * Ulrich Weigand for work on the s390 port. 49674 49675 * Janus Weil for contributions to GNU Fortran. 49676 49677 * Zack Weinberg for major work on cpplib and various other bug fixes. 49678 49679 * Matt Welsh for help with Linux Threads support in GCJ. 49680 49681 * Urban Widmark for help fixing java.io. 49682 49683 * Mark Wielaard for new Java library code and his work integrating 49684 with Classpath. 49685 49686 * Dale Wiles helped port GCC to the Tahoe. 49687 49688 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 49689 49690 * Jim Wilson for his direction via the steering committee, tackling 49691 hard problems in various places that nobody else wanted to work on, 49692 strength reduction and other loop optimizations. 49693 49694 * Paul Woegerer and Tal Agmon for the CRX port. 49695 49696 * Carlo Wood for various fixes. 49697 49698 * Tom Wood for work on the m88k port. 49699 49700 * Chung-Ju Wu for his work on the Andes NDS32 port. 49701 49702 * Canqun Yang for work on GNU Fortran. 49703 49704 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 49705 description for the Tron architecture (specifically, the Gmicro). 49706 49707 * Kevin Zachmann helped port GCC to the Tahoe. 49708 49709 * Ayal Zaks for Swing Modulo Scheduling (SMS). 49710 49711 * Qirun Zhang for running automated regression testing of GCC and 49712 reporting numerous bugs. 49713 49714 * Xiaoqiang Zhang for work on GNU Fortran. 49715 49716 * Gilles Zunino for help porting Java to Irix. 49717 49718 The following people are recognized for their contributions to GNAT, 49719the Ada front end of GCC: 49720 * Bernard Banner 49721 49722 * Romain Berrendonner 49723 49724 * Geert Bosch 49725 49726 * Emmanuel Briot 49727 49728 * Joel Brobecker 49729 49730 * Ben Brosgol 49731 49732 * Vincent Celier 49733 49734 * Arnaud Charlet 49735 49736 * Chien Chieng 49737 49738 * Cyrille Comar 49739 49740 * Cyrille Crozes 49741 49742 * Robert Dewar 49743 49744 * Gary Dismukes 49745 49746 * Robert Duff 49747 49748 * Ed Falis 49749 49750 * Ramon Fernandez 49751 49752 * Sam Figueroa 49753 49754 * Vasiliy Fofanov 49755 49756 * Michael Friess 49757 49758 * Franco Gasperoni 49759 49760 * Ted Giering 49761 49762 * Matthew Gingell 49763 49764 * Laurent Guerby 49765 49766 * Jerome Guitton 49767 49768 * Olivier Hainque 49769 49770 * Jerome Hugues 49771 49772 * Hristian Kirtchev 49773 49774 * Jerome Lambourg 49775 49776 * Bruno Leclerc 49777 49778 * Albert Lee 49779 49780 * Sean McNeil 49781 49782 * Javier Miranda 49783 49784 * Laurent Nana 49785 49786 * Pascal Obry 49787 49788 * Dong-Ik Oh 49789 49790 * Laurent Pautet 49791 49792 * Brett Porter 49793 49794 * Thomas Quinot 49795 49796 * Nicolas Roche 49797 49798 * Pat Rogers 49799 49800 * Jose Ruiz 49801 49802 * Douglas Rupp 49803 49804 * Sergey Rybin 49805 49806 * Gail Schenker 49807 49808 * Ed Schonberg 49809 49810 * Nicolas Setton 49811 49812 * Samuel Tardieu 49813 49814 The following people are recognized for their contributions of new 49815features, bug reports, testing and integration of classpath/libgcj for 49816GCC version 4.1: 49817 * Lillian Angel for 'JTree' implementation and lots Free Swing 49818 additions and bug fixes. 49819 49820 * Wolfgang Baer for 'GapContent' bug fixes. 49821 49822 * Anthony Balkissoon for 'JList', Free Swing 1.5 updates and mouse 49823 event fixes, lots of Free Swing work including 'JTable' editing. 49824 49825 * Stuart Ballard for RMI constant fixes. 49826 49827 * Goffredo Baroncelli for 'HTTPURLConnection' fixes. 49828 49829 * Gary Benson for 'MessageFormat' fixes. 49830 49831 * Daniel Bonniot for 'Serialization' fixes. 49832 49833 * Chris Burdess for lots of gnu.xml and http protocol fixes, 'StAX' 49834 and 'DOM xml:id' support. 49835 49836 * Ka-Hing Cheung for 'TreePath' and 'TreeSelection' fixes. 49837 49838 * Archie Cobbs for build fixes, VM interface updates, 49839 'URLClassLoader' updates. 49840 49841 * Kelley Cook for build fixes. 49842 49843 * Martin Cordova for Suggestions for better 'SocketTimeoutException'. 49844 49845 * David Daney for 'BitSet' bug fixes, 'HttpURLConnection' rewrite and 49846 improvements. 49847 49848 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 49849 2D support. Lots of imageio framework additions, lots of AWT and 49850 Free Swing bug fixes. 49851 49852 * Jeroen Frijters for 'ClassLoader' and nio cleanups, serialization 49853 fixes, better 'Proxy' support, bug fixes and IKVM integration. 49854 49855 * Santiago Gala for 'AccessControlContext' fixes. 49856 49857 * Nicolas Geoffray for 'VMClassLoader' and 'AccessController' 49858 improvements. 49859 49860 * David Gilbert for 'basic' and 'metal' icon and plaf support and 49861 lots of documenting, Lots of Free Swing and metal theme additions. 49862 'MetalIconFactory' implementation. 49863 49864 * Anthony Green for 'MIDI' framework, 'ALSA' and 'DSSI' providers. 49865 49866 * Andrew Haley for 'Serialization' and 'URLClassLoader' fixes, gcj 49867 build speedups. 49868 49869 * Kim Ho for 'JFileChooser' implementation. 49870 49871 * Andrew John Hughes for 'Locale' and net fixes, URI RFC2986 updates, 49872 'Serialization' fixes, 'Properties' XML support and generic branch 49873 work, VMIntegration guide update. 49874 49875 * Bastiaan Huisman for 'TimeZone' bug fixing. 49876 49877 * Andreas Jaeger for mprec updates. 49878 49879 * Paul Jenner for better '-Werror' support. 49880 49881 * Ito Kazumitsu for 'NetworkInterface' implementation and updates. 49882 49883 * Roman Kennke for 'BoxLayout', 'GrayFilter' and 'SplitPane', plus 49884 bug fixes all over. Lots of Free Swing work including styled text. 49885 49886 * Simon Kitching for 'String' cleanups and optimization suggestions. 49887 49888 * Michael Koch for configuration fixes, 'Locale' updates, bug and 49889 build fixes. 49890 49891 * Guilhem Lavaux for configuration, thread and channel fixes and 49892 Kaffe integration. JCL native 'Pointer' updates. Logger bug 49893 fixes. 49894 49895 * David Lichteblau for JCL support library global/local reference 49896 cleanups. 49897 49898 * Aaron Luchko for JDWP updates and documentation fixes. 49899 49900 * Ziga Mahkovec for 'Graphics2D' upgraded to Cairo 0.5 and new regex 49901 features. 49902 49903 * Sven de Marothy for BMP imageio support, CSS and 'TextLayout' 49904 fixes. 'GtkImage' rewrite, 2D, awt, free swing and date/time fixes 49905 and implementing the Qt4 peers. 49906 49907 * Casey Marshall for crypto algorithm fixes, 'FileChannel' lock, 49908 'SystemLogger' and 'FileHandler' rotate implementations, NIO 49909 'FileChannel.map' support, security and policy updates. 49910 49911 * Bryce McKinlay for RMI work. 49912 49913 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 49914 testing and documenting. 49915 49916 * Kalle Olavi Niemitalo for build fixes. 49917 49918 * Rainer Orth for build fixes. 49919 49920 * Andrew Overholt for 'File' locking fixes. 49921 49922 * Ingo Proetel for 'Image', 'Logger' and 'URLClassLoader' updates. 49923 49924 * Olga Rodimina for 'MenuSelectionManager' implementation. 49925 49926 * Jan Roehrich for 'BasicTreeUI' and 'JTree' fixes. 49927 49928 * Julian Scheid for documentation updates and gjdoc support. 49929 49930 * Christian Schlichtherle for zip fixes and cleanups. 49931 49932 * Robert Schuster for documentation updates and beans fixes, 49933 'TreeNode' enumerations and 'ActionCommand' and various fixes, XML 49934 and URL, AWT and Free Swing bug fixes. 49935 49936 * Keith Seitz for lots of JDWP work. 49937 49938 * Christian Thalinger for 64-bit cleanups, Configuration and VM 49939 interface fixes and 'CACAO' integration, 'fdlibm' updates. 49940 49941 * Gael Thomas for 'VMClassLoader' boot packages support suggestions. 49942 49943 * Andreas Tobler for Darwin and Solaris testing and fixing, 'Qt4' 49944 support for Darwin/OS X, 'Graphics2D' support, 'gtk+' updates. 49945 49946 * Dalibor Topic for better 'DEBUG' support, build cleanups and Kaffe 49947 integration. 'Qt4' build infrastructure, 'SHA1PRNG' and 49948 'GdkPixbugDecoder' updates. 49949 49950 * Tom Tromey for Eclipse integration, generics work, lots of bug 49951 fixes and gcj integration including coordinating The Big Merge. 49952 49953 * Mark Wielaard for bug fixes, packaging and release management, 49954 'Clipboard' implementation, system call interrupts and network 49955 timeouts and 'GdkPixpufDecoder' fixes. 49956 49957 In addition to the above, all of which also contributed time and energy 49958in testing GCC, we would like to thank the following for their 49959contributions to testing: 49960 49961 * Michael Abd-El-Malek 49962 49963 * Thomas Arend 49964 49965 * Bonzo Armstrong 49966 49967 * Steven Ashe 49968 49969 * Chris Baldwin 49970 49971 * David Billinghurst 49972 49973 * Jim Blandy 49974 49975 * Stephane Bortzmeyer 49976 49977 * Horst von Brand 49978 49979 * Frank Braun 49980 49981 * Rodney Brown 49982 49983 * Sidney Cadot 49984 49985 * Bradford Castalia 49986 49987 * Robert Clark 49988 49989 * Jonathan Corbet 49990 49991 * Ralph Doncaster 49992 49993 * Richard Emberson 49994 49995 * Levente Farkas 49996 49997 * Graham Fawcett 49998 49999 * Mark Fernyhough 50000 50001 * Robert A. French 50002 50003 * Jo"rgen Freyh 50004 50005 * Mark K. Gardner 50006 50007 * Charles-Antoine Gauthier 50008 50009 * Yung Shing Gene 50010 50011 * David Gilbert 50012 50013 * Simon Gornall 50014 50015 * Fred Gray 50016 50017 * John Griffin 50018 50019 * Patrik Hagglund 50020 50021 * Phil Hargett 50022 50023 * Amancio Hasty 50024 50025 * Takafumi Hayashi 50026 50027 * Bryan W. Headley 50028 50029 * Kevin B. Hendricks 50030 50031 * Joep Jansen 50032 50033 * Christian Joensson 50034 50035 * Michel Kern 50036 50037 * David Kidd 50038 50039 * Tobias Kuipers 50040 50041 * Anand Krishnaswamy 50042 50043 * A. O. V. Le Blanc 50044 50045 * llewelly 50046 50047 * Damon Love 50048 50049 * Brad Lucier 50050 50051 * Matthias Klose 50052 50053 * Martin Knoblauch 50054 50055 * Rick Lutowski 50056 50057 * Jesse Macnish 50058 50059 * Stefan Morrell 50060 50061 * Anon A. Mous 50062 50063 * Matthias Mueller 50064 50065 * Pekka Nikander 50066 50067 * Rick Niles 50068 50069 * Jon Olson 50070 50071 * Magnus Persson 50072 50073 * Chris Pollard 50074 50075 * Richard Polton 50076 50077 * Derk Reefman 50078 50079 * David Rees 50080 50081 * Paul Reilly 50082 50083 * Tom Reilly 50084 50085 * Torsten Rueger 50086 50087 * Danny Sadinoff 50088 50089 * Marc Schifer 50090 50091 * Erik Schnetter 50092 50093 * Wayne K. Schroll 50094 50095 * David Schuler 50096 50097 * Vin Shelton 50098 50099 * Tim Souder 50100 50101 * Adam Sulmicki 50102 50103 * Bill Thorson 50104 50105 * George Talbot 50106 50107 * Pedro A. M. Vazquez 50108 50109 * Gregory Warnes 50110 50111 * Ian Watson 50112 50113 * David E. Young 50114 50115 * And many others 50116 50117 And finally we'd like to thank everyone who uses the compiler, provides 50118feedback and generally reminds us why we're doing this work in the first 50119place. 50120 50121 50122File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 50123 50124Option Index 50125************ 50126 50127GCC's command line options are indexed here without any initial '-' or 50128'--'. Where an option has both positive and negative forms (such as 50129'-fOPTION' and '-fno-OPTION'), relevant entries in the manual are 50130indexed under the most appropriate form; it may sometimes be useful to 50131look up both forms. 50132 50133�[index�] 50134* Menu: 50135 50136* fltrans: Internal flags. (line 18) 50137* fltrans-output-list: Internal flags. (line 23) 50138* fresolution: Internal flags. (line 27) 50139* fwpa: Internal flags. (line 9) 50140* msoft-float: Soft float library routines. 50141 (line 6) 50142 50143 50144File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 50145 50146Concept Index 50147************* 50148 50149�[index�] 50150* Menu: 50151 50152* ! in constraint: Multi-Alternative. (line 48) 50153* "real" instructions, RTL SSA: RTL SSA Basic Blocks. 50154 (line 11) 50155* # in constraint: Modifiers. (line 78) 50156* # in template: Output Template. (line 66) 50157* #pragma: Misc. (line 422) 50158* $ in constraint: Multi-Alternative. (line 57) 50159* % in constraint: Modifiers. (line 52) 50160* % in GTY option: GTY Options. (line 18) 50161* % in template: Output Template. (line 6) 50162* & in constraint: Modifiers. (line 25) 50163* (gimple_stmt_iterator: GIMPLE API. (line 30) 50164* (nil): RTL Objects. (line 73) 50165* * in constraint: Modifiers. (line 83) 50166* * in template: Output Statement. (line 29) 50167* *gimple_build_asm_vec: GIMPLE_ASM. (line 6) 50168* *gimple_build_assign: GIMPLE_ASSIGN. (line 6) 50169* *gimple_build_assign <1>: GIMPLE_ASSIGN. (line 18) 50170* *gimple_build_assign <2>: GIMPLE_ASSIGN. (line 29) 50171* *gimple_build_assign <3>: GIMPLE_ASSIGN. (line 35) 50172* *gimple_build_bind: GIMPLE_BIND. (line 6) 50173* *gimple_build_call: GIMPLE_CALL. (line 6) 50174* *gimple_build_call_from_tree: GIMPLE_CALL. (line 15) 50175* *gimple_build_call_vec: GIMPLE_CALL. (line 25) 50176* *gimple_build_catch: GIMPLE_CATCH. (line 6) 50177* *gimple_build_cond: GIMPLE_COND. (line 6) 50178* *gimple_build_cond_from_tree: GIMPLE_COND. (line 14) 50179* *gimple_build_debug_bind: GIMPLE_DEBUG. (line 6) 50180* *gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 6) 50181* *gimple_build_goto: GIMPLE_GOTO. (line 6) 50182* *gimple_build_label: GIMPLE_LABEL. (line 6) 50183* *gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD. 50184 (line 6) 50185* *gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE. 50186 (line 6) 50187* *gimple_build_omp_continue: GIMPLE_OMP_CONTINUE. 50188 (line 6) 50189* *gimple_build_omp_critical: GIMPLE_OMP_CRITICAL. 50190 (line 6) 50191* *gimple_build_omp_for: GIMPLE_OMP_FOR. (line 6) 50192* *gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL. 50193 (line 6) 50194* *gimple_build_omp_sections: GIMPLE_OMP_SECTIONS. 50195 (line 6) 50196* *gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 6) 50197* *gimple_build_resx: GIMPLE_RESX. (line 6) 50198* *gimple_build_return: GIMPLE_RETURN. (line 6) 50199* *gimple_build_switch: GIMPLE_SWITCH. (line 6) 50200* *gimple_build_try: GIMPLE_TRY. (line 6) 50201* + in constraint: Modifiers. (line 12) 50202* -fsection-anchors: Special Accessors. (line 117) 50203* -fsection-anchors <1>: Anchored Addresses. (line 6) 50204* /c in RTL dump: Flags. (line 230) 50205* /f in RTL dump: Flags. (line 238) 50206* /i in RTL dump: Flags. (line 283) 50207* /j in RTL dump: Flags. (line 295) 50208* /s in RTL dump: Flags. (line 254) 50209* /u in RTL dump: Flags. (line 307) 50210* /v in RTL dump: Flags. (line 339) 50211* 0 in constraint: Simple Constraints. (line 128) 50212* < in constraint: Simple Constraints. (line 47) 50213* = in constraint: Modifiers. (line 8) 50214* > in constraint: Simple Constraints. (line 59) 50215* ? in constraint: Multi-Alternative. (line 42) 50216* @ in instruction pattern names: Parameterized Names. 50217 (line 6) 50218* \: Output Template. (line 46) 50219* ^ in constraint: Multi-Alternative. (line 53) 50220* __absvdi2: Integer library routines. 50221 (line 106) 50222* __absvsi2: Integer library routines. 50223 (line 105) 50224* __addda3: Fixed-point fractional library routines. 50225 (line 52) 50226* __adddf3: Soft float library routines. 50227 (line 22) 50228* __adddq3: Fixed-point fractional library routines. 50229 (line 39) 50230* __addha3: Fixed-point fractional library routines. 50231 (line 49) 50232* __addhq3: Fixed-point fractional library routines. 50233 (line 37) 50234* __addqq3: Fixed-point fractional library routines. 50235 (line 35) 50236* __addsa3: Fixed-point fractional library routines. 50237 (line 51) 50238* __addsf3: Soft float library routines. 50239 (line 21) 50240* __addsq3: Fixed-point fractional library routines. 50241 (line 38) 50242* __addta3: Fixed-point fractional library routines. 50243 (line 53) 50244* __addtf3: Soft float library routines. 50245 (line 23) 50246* __adduda3: Fixed-point fractional library routines. 50247 (line 59) 50248* __addudq3: Fixed-point fractional library routines. 50249 (line 47) 50250* __adduha3: Fixed-point fractional library routines. 50251 (line 55) 50252* __adduhq3: Fixed-point fractional library routines. 50253 (line 43) 50254* __adduqq3: Fixed-point fractional library routines. 50255 (line 41) 50256* __addusa3: Fixed-point fractional library routines. 50257 (line 57) 50258* __addusq3: Fixed-point fractional library routines. 50259 (line 45) 50260* __adduta3: Fixed-point fractional library routines. 50261 (line 61) 50262* __addvdi3: Integer library routines. 50263 (line 110) 50264* __addvsi3: Integer library routines. 50265 (line 109) 50266* __addxf3: Soft float library routines. 50267 (line 25) 50268* __ashlda3: Fixed-point fractional library routines. 50269 (line 358) 50270* __ashldi3: Integer library routines. 50271 (line 13) 50272* __ashldq3: Fixed-point fractional library routines. 50273 (line 346) 50274* __ashlha3: Fixed-point fractional library routines. 50275 (line 356) 50276* __ashlhq3: Fixed-point fractional library routines. 50277 (line 344) 50278* __ashlqq3: Fixed-point fractional library routines. 50279 (line 343) 50280* __ashlsa3: Fixed-point fractional library routines. 50281 (line 357) 50282* __ashlsi3: Integer library routines. 50283 (line 12) 50284* __ashlsq3: Fixed-point fractional library routines. 50285 (line 345) 50286* __ashlta3: Fixed-point fractional library routines. 50287 (line 359) 50288* __ashlti3: Integer library routines. 50289 (line 14) 50290* __ashluda3: Fixed-point fractional library routines. 50291 (line 365) 50292* __ashludq3: Fixed-point fractional library routines. 50293 (line 354) 50294* __ashluha3: Fixed-point fractional library routines. 50295 (line 361) 50296* __ashluhq3: Fixed-point fractional library routines. 50297 (line 350) 50298* __ashluqq3: Fixed-point fractional library routines. 50299 (line 348) 50300* __ashlusa3: Fixed-point fractional library routines. 50301 (line 363) 50302* __ashlusq3: Fixed-point fractional library routines. 50303 (line 352) 50304* __ashluta3: Fixed-point fractional library routines. 50305 (line 367) 50306* __ashrda3: Fixed-point fractional library routines. 50307 (line 378) 50308* __ashrdi3: Integer library routines. 50309 (line 18) 50310* __ashrdq3: Fixed-point fractional library routines. 50311 (line 374) 50312* __ashrha3: Fixed-point fractional library routines. 50313 (line 376) 50314* __ashrhq3: Fixed-point fractional library routines. 50315 (line 372) 50316* __ashrqq3: Fixed-point fractional library routines. 50317 (line 371) 50318* __ashrsa3: Fixed-point fractional library routines. 50319 (line 377) 50320* __ashrsi3: Integer library routines. 50321 (line 17) 50322* __ashrsq3: Fixed-point fractional library routines. 50323 (line 373) 50324* __ashrta3: Fixed-point fractional library routines. 50325 (line 379) 50326* __ashrti3: Integer library routines. 50327 (line 19) 50328* __bid_adddd3: Decimal float library routines. 50329 (line 23) 50330* __bid_addsd3: Decimal float library routines. 50331 (line 19) 50332* __bid_addtd3: Decimal float library routines. 50333 (line 27) 50334* __bid_divdd3: Decimal float library routines. 50335 (line 66) 50336* __bid_divsd3: Decimal float library routines. 50337 (line 62) 50338* __bid_divtd3: Decimal float library routines. 50339 (line 70) 50340* __bid_eqdd2: Decimal float library routines. 50341 (line 258) 50342* __bid_eqsd2: Decimal float library routines. 50343 (line 256) 50344* __bid_eqtd2: Decimal float library routines. 50345 (line 260) 50346* __bid_extendddtd2: Decimal float library routines. 50347 (line 91) 50348* __bid_extendddtf: Decimal float library routines. 50349 (line 139) 50350* __bid_extendddxf: Decimal float library routines. 50351 (line 133) 50352* __bid_extenddfdd: Decimal float library routines. 50353 (line 146) 50354* __bid_extenddftd: Decimal float library routines. 50355 (line 106) 50356* __bid_extendsddd2: Decimal float library routines. 50357 (line 87) 50358* __bid_extendsddf: Decimal float library routines. 50359 (line 127) 50360* __bid_extendsdtd2: Decimal float library routines. 50361 (line 89) 50362* __bid_extendsdtf: Decimal float library routines. 50363 (line 137) 50364* __bid_extendsdxf: Decimal float library routines. 50365 (line 131) 50366* __bid_extendsfdd: Decimal float library routines. 50367 (line 102) 50368* __bid_extendsfsd: Decimal float library routines. 50369 (line 144) 50370* __bid_extendsftd: Decimal float library routines. 50371 (line 104) 50372* __bid_extendtftd: Decimal float library routines. 50373 (line 148) 50374* __bid_extendxftd: Decimal float library routines. 50375 (line 108) 50376* __bid_fixdddi: Decimal float library routines. 50377 (line 169) 50378* __bid_fixddsi: Decimal float library routines. 50379 (line 161) 50380* __bid_fixsddi: Decimal float library routines. 50381 (line 167) 50382* __bid_fixsdsi: Decimal float library routines. 50383 (line 159) 50384* __bid_fixtddi: Decimal float library routines. 50385 (line 171) 50386* __bid_fixtdsi: Decimal float library routines. 50387 (line 163) 50388* __bid_fixunsdddi: Decimal float library routines. 50389 (line 186) 50390* __bid_fixunsddsi: Decimal float library routines. 50391 (line 177) 50392* __bid_fixunssddi: Decimal float library routines. 50393 (line 184) 50394* __bid_fixunssdsi: Decimal float library routines. 50395 (line 175) 50396* __bid_fixunstddi: Decimal float library routines. 50397 (line 188) 50398* __bid_fixunstdsi: Decimal float library routines. 50399 (line 179) 50400* __bid_floatdidd: Decimal float library routines. 50401 (line 204) 50402* __bid_floatdisd: Decimal float library routines. 50403 (line 202) 50404* __bid_floatditd: Decimal float library routines. 50405 (line 206) 50406* __bid_floatsidd: Decimal float library routines. 50407 (line 195) 50408* __bid_floatsisd: Decimal float library routines. 50409 (line 193) 50410* __bid_floatsitd: Decimal float library routines. 50411 (line 197) 50412* __bid_floatunsdidd: Decimal float library routines. 50413 (line 222) 50414* __bid_floatunsdisd: Decimal float library routines. 50415 (line 220) 50416* __bid_floatunsditd: Decimal float library routines. 50417 (line 224) 50418* __bid_floatunssidd: Decimal float library routines. 50419 (line 213) 50420* __bid_floatunssisd: Decimal float library routines. 50421 (line 211) 50422* __bid_floatunssitd: Decimal float library routines. 50423 (line 215) 50424* __bid_gedd2: Decimal float library routines. 50425 (line 276) 50426* __bid_gesd2: Decimal float library routines. 50427 (line 274) 50428* __bid_getd2: Decimal float library routines. 50429 (line 278) 50430* __bid_gtdd2: Decimal float library routines. 50431 (line 303) 50432* __bid_gtsd2: Decimal float library routines. 50433 (line 301) 50434* __bid_gttd2: Decimal float library routines. 50435 (line 305) 50436* __bid_ledd2: Decimal float library routines. 50437 (line 294) 50438* __bid_lesd2: Decimal float library routines. 50439 (line 292) 50440* __bid_letd2: Decimal float library routines. 50441 (line 296) 50442* __bid_ltdd2: Decimal float library routines. 50443 (line 285) 50444* __bid_ltsd2: Decimal float library routines. 50445 (line 283) 50446* __bid_lttd2: Decimal float library routines. 50447 (line 287) 50448* __bid_muldd3: Decimal float library routines. 50449 (line 52) 50450* __bid_mulsd3: Decimal float library routines. 50451 (line 48) 50452* __bid_multd3: Decimal float library routines. 50453 (line 56) 50454* __bid_nedd2: Decimal float library routines. 50455 (line 267) 50456* __bid_negdd2: Decimal float library routines. 50457 (line 77) 50458* __bid_negsd2: Decimal float library routines. 50459 (line 75) 50460* __bid_negtd2: Decimal float library routines. 50461 (line 79) 50462* __bid_nesd2: Decimal float library routines. 50463 (line 265) 50464* __bid_netd2: Decimal float library routines. 50465 (line 269) 50466* __bid_subdd3: Decimal float library routines. 50467 (line 37) 50468* __bid_subsd3: Decimal float library routines. 50469 (line 33) 50470* __bid_subtd3: Decimal float library routines. 50471 (line 41) 50472* __bid_truncdddf: Decimal float library routines. 50473 (line 152) 50474* __bid_truncddsd2: Decimal float library routines. 50475 (line 93) 50476* __bid_truncddsf: Decimal float library routines. 50477 (line 123) 50478* __bid_truncdfsd: Decimal float library routines. 50479 (line 110) 50480* __bid_truncsdsf: Decimal float library routines. 50481 (line 150) 50482* __bid_trunctddd2: Decimal float library routines. 50483 (line 97) 50484* __bid_trunctddf: Decimal float library routines. 50485 (line 129) 50486* __bid_trunctdsd2: Decimal float library routines. 50487 (line 95) 50488* __bid_trunctdsf: Decimal float library routines. 50489 (line 125) 50490* __bid_trunctdtf: Decimal float library routines. 50491 (line 154) 50492* __bid_trunctdxf: Decimal float library routines. 50493 (line 135) 50494* __bid_trunctfdd: Decimal float library routines. 50495 (line 118) 50496* __bid_trunctfsd: Decimal float library routines. 50497 (line 114) 50498* __bid_truncxfdd: Decimal float library routines. 50499 (line 116) 50500* __bid_truncxfsd: Decimal float library routines. 50501 (line 112) 50502* __bid_unorddd2: Decimal float library routines. 50503 (line 234) 50504* __bid_unordsd2: Decimal float library routines. 50505 (line 232) 50506* __bid_unordtd2: Decimal float library routines. 50507 (line 236) 50508* __bswapdi2: Integer library routines. 50509 (line 161) 50510* __bswapsi2: Integer library routines. 50511 (line 160) 50512* __builtin_classify_type: Varargs. (line 48) 50513* __builtin_next_arg: Varargs. (line 39) 50514* __builtin_saveregs: Varargs. (line 22) 50515* __clear_cache: Miscellaneous routines. 50516 (line 9) 50517* __clzdi2: Integer library routines. 50518 (line 130) 50519* __clzsi2: Integer library routines. 50520 (line 129) 50521* __clzti2: Integer library routines. 50522 (line 131) 50523* __cmpda2: Fixed-point fractional library routines. 50524 (line 458) 50525* __cmpdf2: Soft float library routines. 50526 (line 163) 50527* __cmpdi2: Integer library routines. 50528 (line 86) 50529* __cmpdq2: Fixed-point fractional library routines. 50530 (line 447) 50531* __cmpha2: Fixed-point fractional library routines. 50532 (line 456) 50533* __cmphq2: Fixed-point fractional library routines. 50534 (line 445) 50535* __cmpqq2: Fixed-point fractional library routines. 50536 (line 444) 50537* __cmpsa2: Fixed-point fractional library routines. 50538 (line 457) 50539* __cmpsf2: Soft float library routines. 50540 (line 162) 50541* __cmpsq2: Fixed-point fractional library routines. 50542 (line 446) 50543* __cmpta2: Fixed-point fractional library routines. 50544 (line 459) 50545* __cmptf2: Soft float library routines. 50546 (line 164) 50547* __cmpti2: Integer library routines. 50548 (line 87) 50549* __cmpuda2: Fixed-point fractional library routines. 50550 (line 464) 50551* __cmpudq2: Fixed-point fractional library routines. 50552 (line 454) 50553* __cmpuha2: Fixed-point fractional library routines. 50554 (line 461) 50555* __cmpuhq2: Fixed-point fractional library routines. 50556 (line 451) 50557* __cmpuqq2: Fixed-point fractional library routines. 50558 (line 449) 50559* __cmpusa2: Fixed-point fractional library routines. 50560 (line 463) 50561* __cmpusq2: Fixed-point fractional library routines. 50562 (line 452) 50563* __cmputa2: Fixed-point fractional library routines. 50564 (line 466) 50565* __CTOR_LIST__: Initialization. (line 25) 50566* __ctzdi2: Integer library routines. 50567 (line 137) 50568* __ctzsi2: Integer library routines. 50569 (line 136) 50570* __ctzti2: Integer library routines. 50571 (line 138) 50572* __divda3: Fixed-point fractional library routines. 50573 (line 234) 50574* __divdc3: Soft float library routines. 50575 (line 250) 50576* __divdf3: Soft float library routines. 50577 (line 47) 50578* __divdi3: Integer library routines. 50579 (line 24) 50580* __divdq3: Fixed-point fractional library routines. 50581 (line 229) 50582* __divha3: Fixed-point fractional library routines. 50583 (line 231) 50584* __divhq3: Fixed-point fractional library routines. 50585 (line 227) 50586* __divqq3: Fixed-point fractional library routines. 50587 (line 225) 50588* __divsa3: Fixed-point fractional library routines. 50589 (line 233) 50590* __divsc3: Soft float library routines. 50591 (line 248) 50592* __divsf3: Soft float library routines. 50593 (line 46) 50594* __divsi3: Integer library routines. 50595 (line 23) 50596* __divsq3: Fixed-point fractional library routines. 50597 (line 228) 50598* __divta3: Fixed-point fractional library routines. 50599 (line 235) 50600* __divtc3: Soft float library routines. 50601 (line 252) 50602* __divtf3: Soft float library routines. 50603 (line 48) 50604* __divti3: Integer library routines. 50605 (line 25) 50606* __divxc3: Soft float library routines. 50607 (line 254) 50608* __divxf3: Soft float library routines. 50609 (line 50) 50610* __dpd_adddd3: Decimal float library routines. 50611 (line 21) 50612* __dpd_addsd3: Decimal float library routines. 50613 (line 17) 50614* __dpd_addtd3: Decimal float library routines. 50615 (line 25) 50616* __dpd_divdd3: Decimal float library routines. 50617 (line 64) 50618* __dpd_divsd3: Decimal float library routines. 50619 (line 60) 50620* __dpd_divtd3: Decimal float library routines. 50621 (line 68) 50622* __dpd_eqdd2: Decimal float library routines. 50623 (line 257) 50624* __dpd_eqsd2: Decimal float library routines. 50625 (line 255) 50626* __dpd_eqtd2: Decimal float library routines. 50627 (line 259) 50628* __dpd_extendddtd2: Decimal float library routines. 50629 (line 90) 50630* __dpd_extendddtf: Decimal float library routines. 50631 (line 138) 50632* __dpd_extendddxf: Decimal float library routines. 50633 (line 132) 50634* __dpd_extenddfdd: Decimal float library routines. 50635 (line 145) 50636* __dpd_extenddftd: Decimal float library routines. 50637 (line 105) 50638* __dpd_extendsddd2: Decimal float library routines. 50639 (line 86) 50640* __dpd_extendsddf: Decimal float library routines. 50641 (line 126) 50642* __dpd_extendsdtd2: Decimal float library routines. 50643 (line 88) 50644* __dpd_extendsdtf: Decimal float library routines. 50645 (line 136) 50646* __dpd_extendsdxf: Decimal float library routines. 50647 (line 130) 50648* __dpd_extendsfdd: Decimal float library routines. 50649 (line 101) 50650* __dpd_extendsfsd: Decimal float library routines. 50651 (line 143) 50652* __dpd_extendsftd: Decimal float library routines. 50653 (line 103) 50654* __dpd_extendtftd: Decimal float library routines. 50655 (line 147) 50656* __dpd_extendxftd: Decimal float library routines. 50657 (line 107) 50658* __dpd_fixdddi: Decimal float library routines. 50659 (line 168) 50660* __dpd_fixddsi: Decimal float library routines. 50661 (line 160) 50662* __dpd_fixsddi: Decimal float library routines. 50663 (line 166) 50664* __dpd_fixsdsi: Decimal float library routines. 50665 (line 158) 50666* __dpd_fixtddi: Decimal float library routines. 50667 (line 170) 50668* __dpd_fixtdsi: Decimal float library routines. 50669 (line 162) 50670* __dpd_fixunsdddi: Decimal float library routines. 50671 (line 185) 50672* __dpd_fixunsddsi: Decimal float library routines. 50673 (line 176) 50674* __dpd_fixunssddi: Decimal float library routines. 50675 (line 183) 50676* __dpd_fixunssdsi: Decimal float library routines. 50677 (line 174) 50678* __dpd_fixunstddi: Decimal float library routines. 50679 (line 187) 50680* __dpd_fixunstdsi: Decimal float library routines. 50681 (line 178) 50682* __dpd_floatdidd: Decimal float library routines. 50683 (line 203) 50684* __dpd_floatdisd: Decimal float library routines. 50685 (line 201) 50686* __dpd_floatditd: Decimal float library routines. 50687 (line 205) 50688* __dpd_floatsidd: Decimal float library routines. 50689 (line 194) 50690* __dpd_floatsisd: Decimal float library routines. 50691 (line 192) 50692* __dpd_floatsitd: Decimal float library routines. 50693 (line 196) 50694* __dpd_floatunsdidd: Decimal float library routines. 50695 (line 221) 50696* __dpd_floatunsdisd: Decimal float library routines. 50697 (line 219) 50698* __dpd_floatunsditd: Decimal float library routines. 50699 (line 223) 50700* __dpd_floatunssidd: Decimal float library routines. 50701 (line 212) 50702* __dpd_floatunssisd: Decimal float library routines. 50703 (line 210) 50704* __dpd_floatunssitd: Decimal float library routines. 50705 (line 214) 50706* __dpd_gedd2: Decimal float library routines. 50707 (line 275) 50708* __dpd_gesd2: Decimal float library routines. 50709 (line 273) 50710* __dpd_getd2: Decimal float library routines. 50711 (line 277) 50712* __dpd_gtdd2: Decimal float library routines. 50713 (line 302) 50714* __dpd_gtsd2: Decimal float library routines. 50715 (line 300) 50716* __dpd_gttd2: Decimal float library routines. 50717 (line 304) 50718* __dpd_ledd2: Decimal float library routines. 50719 (line 293) 50720* __dpd_lesd2: Decimal float library routines. 50721 (line 291) 50722* __dpd_letd2: Decimal float library routines. 50723 (line 295) 50724* __dpd_ltdd2: Decimal float library routines. 50725 (line 284) 50726* __dpd_ltsd2: Decimal float library routines. 50727 (line 282) 50728* __dpd_lttd2: Decimal float library routines. 50729 (line 286) 50730* __dpd_muldd3: Decimal float library routines. 50731 (line 50) 50732* __dpd_mulsd3: Decimal float library routines. 50733 (line 46) 50734* __dpd_multd3: Decimal float library routines. 50735 (line 54) 50736* __dpd_nedd2: Decimal float library routines. 50737 (line 266) 50738* __dpd_negdd2: Decimal float library routines. 50739 (line 76) 50740* __dpd_negsd2: Decimal float library routines. 50741 (line 74) 50742* __dpd_negtd2: Decimal float library routines. 50743 (line 78) 50744* __dpd_nesd2: Decimal float library routines. 50745 (line 264) 50746* __dpd_netd2: Decimal float library routines. 50747 (line 268) 50748* __dpd_subdd3: Decimal float library routines. 50749 (line 35) 50750* __dpd_subsd3: Decimal float library routines. 50751 (line 31) 50752* __dpd_subtd3: Decimal float library routines. 50753 (line 39) 50754* __dpd_truncdddf: Decimal float library routines. 50755 (line 151) 50756* __dpd_truncddsd2: Decimal float library routines. 50757 (line 92) 50758* __dpd_truncddsf: Decimal float library routines. 50759 (line 122) 50760* __dpd_truncdfsd: Decimal float library routines. 50761 (line 109) 50762* __dpd_truncsdsf: Decimal float library routines. 50763 (line 149) 50764* __dpd_trunctddd2: Decimal float library routines. 50765 (line 96) 50766* __dpd_trunctddf: Decimal float library routines. 50767 (line 128) 50768* __dpd_trunctdsd2: Decimal float library routines. 50769 (line 94) 50770* __dpd_trunctdsf: Decimal float library routines. 50771 (line 124) 50772* __dpd_trunctdtf: Decimal float library routines. 50773 (line 153) 50774* __dpd_trunctdxf: Decimal float library routines. 50775 (line 134) 50776* __dpd_trunctfdd: Decimal float library routines. 50777 (line 117) 50778* __dpd_trunctfsd: Decimal float library routines. 50779 (line 113) 50780* __dpd_truncxfdd: Decimal float library routines. 50781 (line 115) 50782* __dpd_truncxfsd: Decimal float library routines. 50783 (line 111) 50784* __dpd_unorddd2: Decimal float library routines. 50785 (line 233) 50786* __dpd_unordsd2: Decimal float library routines. 50787 (line 231) 50788* __dpd_unordtd2: Decimal float library routines. 50789 (line 235) 50790* __DTOR_LIST__: Initialization. (line 25) 50791* __eqdf2: Soft float library routines. 50792 (line 193) 50793* __eqsf2: Soft float library routines. 50794 (line 192) 50795* __eqtf2: Soft float library routines. 50796 (line 194) 50797* __extenddftf2: Soft float library routines. 50798 (line 67) 50799* __extenddfxf2: Soft float library routines. 50800 (line 68) 50801* __extendsfdf2: Soft float library routines. 50802 (line 64) 50803* __extendsftf2: Soft float library routines. 50804 (line 65) 50805* __extendsfxf2: Soft float library routines. 50806 (line 66) 50807* __ffsdi2: Integer library routines. 50808 (line 143) 50809* __ffsti2: Integer library routines. 50810 (line 144) 50811* __fixdfdi: Soft float library routines. 50812 (line 87) 50813* __fixdfsi: Soft float library routines. 50814 (line 80) 50815* __fixdfti: Soft float library routines. 50816 (line 93) 50817* __fixsfdi: Soft float library routines. 50818 (line 86) 50819* __fixsfsi: Soft float library routines. 50820 (line 79) 50821* __fixsfti: Soft float library routines. 50822 (line 92) 50823* __fixtfdi: Soft float library routines. 50824 (line 88) 50825* __fixtfsi: Soft float library routines. 50826 (line 81) 50827* __fixtfti: Soft float library routines. 50828 (line 94) 50829* __fixunsdfdi: Soft float library routines. 50830 (line 107) 50831* __fixunsdfsi: Soft float library routines. 50832 (line 100) 50833* __fixunsdfti: Soft float library routines. 50834 (line 114) 50835* __fixunssfdi: Soft float library routines. 50836 (line 106) 50837* __fixunssfsi: Soft float library routines. 50838 (line 99) 50839* __fixunssfti: Soft float library routines. 50840 (line 113) 50841* __fixunstfdi: Soft float library routines. 50842 (line 108) 50843* __fixunstfsi: Soft float library routines. 50844 (line 101) 50845* __fixunstfti: Soft float library routines. 50846 (line 115) 50847* __fixunsxfdi: Soft float library routines. 50848 (line 109) 50849* __fixunsxfsi: Soft float library routines. 50850 (line 102) 50851* __fixunsxfti: Soft float library routines. 50852 (line 116) 50853* __fixxfdi: Soft float library routines. 50854 (line 89) 50855* __fixxfsi: Soft float library routines. 50856 (line 82) 50857* __fixxfti: Soft float library routines. 50858 (line 95) 50859* __floatdidf: Soft float library routines. 50860 (line 127) 50861* __floatdisf: Soft float library routines. 50862 (line 126) 50863* __floatditf: Soft float library routines. 50864 (line 128) 50865* __floatdixf: Soft float library routines. 50866 (line 129) 50867* __floatsidf: Soft float library routines. 50868 (line 121) 50869* __floatsisf: Soft float library routines. 50870 (line 120) 50871* __floatsitf: Soft float library routines. 50872 (line 122) 50873* __floatsixf: Soft float library routines. 50874 (line 123) 50875* __floattidf: Soft float library routines. 50876 (line 133) 50877* __floattisf: Soft float library routines. 50878 (line 132) 50879* __floattitf: Soft float library routines. 50880 (line 134) 50881* __floattixf: Soft float library routines. 50882 (line 135) 50883* __floatundidf: Soft float library routines. 50884 (line 145) 50885* __floatundisf: Soft float library routines. 50886 (line 144) 50887* __floatunditf: Soft float library routines. 50888 (line 146) 50889* __floatundixf: Soft float library routines. 50890 (line 147) 50891* __floatunsidf: Soft float library routines. 50892 (line 139) 50893* __floatunsisf: Soft float library routines. 50894 (line 138) 50895* __floatunsitf: Soft float library routines. 50896 (line 140) 50897* __floatunsixf: Soft float library routines. 50898 (line 141) 50899* __floatuntidf: Soft float library routines. 50900 (line 151) 50901* __floatuntisf: Soft float library routines. 50902 (line 150) 50903* __floatuntitf: Soft float library routines. 50904 (line 152) 50905* __floatuntixf: Soft float library routines. 50906 (line 153) 50907* __fractdadf: Fixed-point fractional library routines. 50908 (line 643) 50909* __fractdadi: Fixed-point fractional library routines. 50910 (line 640) 50911* __fractdadq: Fixed-point fractional library routines. 50912 (line 623) 50913* __fractdaha2: Fixed-point fractional library routines. 50914 (line 624) 50915* __fractdahi: Fixed-point fractional library routines. 50916 (line 638) 50917* __fractdahq: Fixed-point fractional library routines. 50918 (line 621) 50919* __fractdaqi: Fixed-point fractional library routines. 50920 (line 637) 50921* __fractdaqq: Fixed-point fractional library routines. 50922 (line 620) 50923* __fractdasa2: Fixed-point fractional library routines. 50924 (line 625) 50925* __fractdasf: Fixed-point fractional library routines. 50926 (line 642) 50927* __fractdasi: Fixed-point fractional library routines. 50928 (line 639) 50929* __fractdasq: Fixed-point fractional library routines. 50930 (line 622) 50931* __fractdata2: Fixed-point fractional library routines. 50932 (line 626) 50933* __fractdati: Fixed-point fractional library routines. 50934 (line 641) 50935* __fractdauda: Fixed-point fractional library routines. 50936 (line 634) 50937* __fractdaudq: Fixed-point fractional library routines. 50938 (line 630) 50939* __fractdauha: Fixed-point fractional library routines. 50940 (line 632) 50941* __fractdauhq: Fixed-point fractional library routines. 50942 (line 628) 50943* __fractdauqq: Fixed-point fractional library routines. 50944 (line 627) 50945* __fractdausa: Fixed-point fractional library routines. 50946 (line 633) 50947* __fractdausq: Fixed-point fractional library routines. 50948 (line 629) 50949* __fractdauta: Fixed-point fractional library routines. 50950 (line 635) 50951* __fractdfda: Fixed-point fractional library routines. 50952 (line 1032) 50953* __fractdfdq: Fixed-point fractional library routines. 50954 (line 1029) 50955* __fractdfha: Fixed-point fractional library routines. 50956 (line 1030) 50957* __fractdfhq: Fixed-point fractional library routines. 50958 (line 1027) 50959* __fractdfqq: Fixed-point fractional library routines. 50960 (line 1026) 50961* __fractdfsa: Fixed-point fractional library routines. 50962 (line 1031) 50963* __fractdfsq: Fixed-point fractional library routines. 50964 (line 1028) 50965* __fractdfta: Fixed-point fractional library routines. 50966 (line 1033) 50967* __fractdfuda: Fixed-point fractional library routines. 50968 (line 1040) 50969* __fractdfudq: Fixed-point fractional library routines. 50970 (line 1037) 50971* __fractdfuha: Fixed-point fractional library routines. 50972 (line 1038) 50973* __fractdfuhq: Fixed-point fractional library routines. 50974 (line 1035) 50975* __fractdfuqq: Fixed-point fractional library routines. 50976 (line 1034) 50977* __fractdfusa: Fixed-point fractional library routines. 50978 (line 1039) 50979* __fractdfusq: Fixed-point fractional library routines. 50980 (line 1036) 50981* __fractdfuta: Fixed-point fractional library routines. 50982 (line 1041) 50983* __fractdida: Fixed-point fractional library routines. 50984 (line 982) 50985* __fractdidq: Fixed-point fractional library routines. 50986 (line 979) 50987* __fractdiha: Fixed-point fractional library routines. 50988 (line 980) 50989* __fractdihq: Fixed-point fractional library routines. 50990 (line 977) 50991* __fractdiqq: Fixed-point fractional library routines. 50992 (line 976) 50993* __fractdisa: Fixed-point fractional library routines. 50994 (line 981) 50995* __fractdisq: Fixed-point fractional library routines. 50996 (line 978) 50997* __fractdita: Fixed-point fractional library routines. 50998 (line 983) 50999* __fractdiuda: Fixed-point fractional library routines. 51000 (line 990) 51001* __fractdiudq: Fixed-point fractional library routines. 51002 (line 987) 51003* __fractdiuha: Fixed-point fractional library routines. 51004 (line 988) 51005* __fractdiuhq: Fixed-point fractional library routines. 51006 (line 985) 51007* __fractdiuqq: Fixed-point fractional library routines. 51008 (line 984) 51009* __fractdiusa: Fixed-point fractional library routines. 51010 (line 989) 51011* __fractdiusq: Fixed-point fractional library routines. 51012 (line 986) 51013* __fractdiuta: Fixed-point fractional library routines. 51014 (line 991) 51015* __fractdqda: Fixed-point fractional library routines. 51016 (line 551) 51017* __fractdqdf: Fixed-point fractional library routines. 51018 (line 573) 51019* __fractdqdi: Fixed-point fractional library routines. 51020 (line 570) 51021* __fractdqha: Fixed-point fractional library routines. 51022 (line 549) 51023* __fractdqhi: Fixed-point fractional library routines. 51024 (line 568) 51025* __fractdqhq2: Fixed-point fractional library routines. 51026 (line 547) 51027* __fractdqqi: Fixed-point fractional library routines. 51028 (line 567) 51029* __fractdqqq2: Fixed-point fractional library routines. 51030 (line 546) 51031* __fractdqsa: Fixed-point fractional library routines. 51032 (line 550) 51033* __fractdqsf: Fixed-point fractional library routines. 51034 (line 572) 51035* __fractdqsi: Fixed-point fractional library routines. 51036 (line 569) 51037* __fractdqsq2: Fixed-point fractional library routines. 51038 (line 548) 51039* __fractdqta: Fixed-point fractional library routines. 51040 (line 552) 51041* __fractdqti: Fixed-point fractional library routines. 51042 (line 571) 51043* __fractdquda: Fixed-point fractional library routines. 51044 (line 563) 51045* __fractdqudq: Fixed-point fractional library routines. 51046 (line 558) 51047* __fractdquha: Fixed-point fractional library routines. 51048 (line 560) 51049* __fractdquhq: Fixed-point fractional library routines. 51050 (line 555) 51051* __fractdquqq: Fixed-point fractional library routines. 51052 (line 553) 51053* __fractdqusa: Fixed-point fractional library routines. 51054 (line 562) 51055* __fractdqusq: Fixed-point fractional library routines. 51056 (line 556) 51057* __fractdquta: Fixed-point fractional library routines. 51058 (line 565) 51059* __fracthada2: Fixed-point fractional library routines. 51060 (line 579) 51061* __fracthadf: Fixed-point fractional library routines. 51062 (line 597) 51063* __fracthadi: Fixed-point fractional library routines. 51064 (line 594) 51065* __fracthadq: Fixed-point fractional library routines. 51066 (line 577) 51067* __fracthahi: Fixed-point fractional library routines. 51068 (line 592) 51069* __fracthahq: Fixed-point fractional library routines. 51070 (line 575) 51071* __fracthaqi: Fixed-point fractional library routines. 51072 (line 591) 51073* __fracthaqq: Fixed-point fractional library routines. 51074 (line 574) 51075* __fracthasa2: Fixed-point fractional library routines. 51076 (line 578) 51077* __fracthasf: Fixed-point fractional library routines. 51078 (line 596) 51079* __fracthasi: Fixed-point fractional library routines. 51080 (line 593) 51081* __fracthasq: Fixed-point fractional library routines. 51082 (line 576) 51083* __fracthata2: Fixed-point fractional library routines. 51084 (line 580) 51085* __fracthati: Fixed-point fractional library routines. 51086 (line 595) 51087* __fracthauda: Fixed-point fractional library routines. 51088 (line 588) 51089* __fracthaudq: Fixed-point fractional library routines. 51090 (line 584) 51091* __fracthauha: Fixed-point fractional library routines. 51092 (line 586) 51093* __fracthauhq: Fixed-point fractional library routines. 51094 (line 582) 51095* __fracthauqq: Fixed-point fractional library routines. 51096 (line 581) 51097* __fracthausa: Fixed-point fractional library routines. 51098 (line 587) 51099* __fracthausq: Fixed-point fractional library routines. 51100 (line 583) 51101* __fracthauta: Fixed-point fractional library routines. 51102 (line 589) 51103* __fracthida: Fixed-point fractional library routines. 51104 (line 950) 51105* __fracthidq: Fixed-point fractional library routines. 51106 (line 947) 51107* __fracthiha: Fixed-point fractional library routines. 51108 (line 948) 51109* __fracthihq: Fixed-point fractional library routines. 51110 (line 945) 51111* __fracthiqq: Fixed-point fractional library routines. 51112 (line 944) 51113* __fracthisa: Fixed-point fractional library routines. 51114 (line 949) 51115* __fracthisq: Fixed-point fractional library routines. 51116 (line 946) 51117* __fracthita: Fixed-point fractional library routines. 51118 (line 951) 51119* __fracthiuda: Fixed-point fractional library routines. 51120 (line 958) 51121* __fracthiudq: Fixed-point fractional library routines. 51122 (line 955) 51123* __fracthiuha: Fixed-point fractional library routines. 51124 (line 956) 51125* __fracthiuhq: Fixed-point fractional library routines. 51126 (line 953) 51127* __fracthiuqq: Fixed-point fractional library routines. 51128 (line 952) 51129* __fracthiusa: Fixed-point fractional library routines. 51130 (line 957) 51131* __fracthiusq: Fixed-point fractional library routines. 51132 (line 954) 51133* __fracthiuta: Fixed-point fractional library routines. 51134 (line 959) 51135* __fracthqda: Fixed-point fractional library routines. 51136 (line 505) 51137* __fracthqdf: Fixed-point fractional library routines. 51138 (line 521) 51139* __fracthqdi: Fixed-point fractional library routines. 51140 (line 518) 51141* __fracthqdq2: Fixed-point fractional library routines. 51142 (line 502) 51143* __fracthqha: Fixed-point fractional library routines. 51144 (line 503) 51145* __fracthqhi: Fixed-point fractional library routines. 51146 (line 516) 51147* __fracthqqi: Fixed-point fractional library routines. 51148 (line 515) 51149* __fracthqqq2: Fixed-point fractional library routines. 51150 (line 500) 51151* __fracthqsa: Fixed-point fractional library routines. 51152 (line 504) 51153* __fracthqsf: Fixed-point fractional library routines. 51154 (line 520) 51155* __fracthqsi: Fixed-point fractional library routines. 51156 (line 517) 51157* __fracthqsq2: Fixed-point fractional library routines. 51158 (line 501) 51159* __fracthqta: Fixed-point fractional library routines. 51160 (line 506) 51161* __fracthqti: Fixed-point fractional library routines. 51162 (line 519) 51163* __fracthquda: Fixed-point fractional library routines. 51164 (line 513) 51165* __fracthqudq: Fixed-point fractional library routines. 51166 (line 510) 51167* __fracthquha: Fixed-point fractional library routines. 51168 (line 511) 51169* __fracthquhq: Fixed-point fractional library routines. 51170 (line 508) 51171* __fracthquqq: Fixed-point fractional library routines. 51172 (line 507) 51173* __fracthqusa: Fixed-point fractional library routines. 51174 (line 512) 51175* __fracthqusq: Fixed-point fractional library routines. 51176 (line 509) 51177* __fracthquta: Fixed-point fractional library routines. 51178 (line 514) 51179* __fractqida: Fixed-point fractional library routines. 51180 (line 932) 51181* __fractqidq: Fixed-point fractional library routines. 51182 (line 929) 51183* __fractqiha: Fixed-point fractional library routines. 51184 (line 930) 51185* __fractqihq: Fixed-point fractional library routines. 51186 (line 927) 51187* __fractqiqq: Fixed-point fractional library routines. 51188 (line 926) 51189* __fractqisa: Fixed-point fractional library routines. 51190 (line 931) 51191* __fractqisq: Fixed-point fractional library routines. 51192 (line 928) 51193* __fractqita: Fixed-point fractional library routines. 51194 (line 933) 51195* __fractqiuda: Fixed-point fractional library routines. 51196 (line 941) 51197* __fractqiudq: Fixed-point fractional library routines. 51198 (line 937) 51199* __fractqiuha: Fixed-point fractional library routines. 51200 (line 939) 51201* __fractqiuhq: Fixed-point fractional library routines. 51202 (line 935) 51203* __fractqiuqq: Fixed-point fractional library routines. 51204 (line 934) 51205* __fractqiusa: Fixed-point fractional library routines. 51206 (line 940) 51207* __fractqiusq: Fixed-point fractional library routines. 51208 (line 936) 51209* __fractqiuta: Fixed-point fractional library routines. 51210 (line 942) 51211* __fractqqda: Fixed-point fractional library routines. 51212 (line 481) 51213* __fractqqdf: Fixed-point fractional library routines. 51214 (line 499) 51215* __fractqqdi: Fixed-point fractional library routines. 51216 (line 496) 51217* __fractqqdq2: Fixed-point fractional library routines. 51218 (line 478) 51219* __fractqqha: Fixed-point fractional library routines. 51220 (line 479) 51221* __fractqqhi: Fixed-point fractional library routines. 51222 (line 494) 51223* __fractqqhq2: Fixed-point fractional library routines. 51224 (line 476) 51225* __fractqqqi: Fixed-point fractional library routines. 51226 (line 493) 51227* __fractqqsa: Fixed-point fractional library routines. 51228 (line 480) 51229* __fractqqsf: Fixed-point fractional library routines. 51230 (line 498) 51231* __fractqqsi: Fixed-point fractional library routines. 51232 (line 495) 51233* __fractqqsq2: Fixed-point fractional library routines. 51234 (line 477) 51235* __fractqqta: Fixed-point fractional library routines. 51236 (line 482) 51237* __fractqqti: Fixed-point fractional library routines. 51238 (line 497) 51239* __fractqquda: Fixed-point fractional library routines. 51240 (line 490) 51241* __fractqqudq: Fixed-point fractional library routines. 51242 (line 486) 51243* __fractqquha: Fixed-point fractional library routines. 51244 (line 488) 51245* __fractqquhq: Fixed-point fractional library routines. 51246 (line 484) 51247* __fractqquqq: Fixed-point fractional library routines. 51248 (line 483) 51249* __fractqqusa: Fixed-point fractional library routines. 51250 (line 489) 51251* __fractqqusq: Fixed-point fractional library routines. 51252 (line 485) 51253* __fractqquta: Fixed-point fractional library routines. 51254 (line 491) 51255* __fractsada2: Fixed-point fractional library routines. 51256 (line 603) 51257* __fractsadf: Fixed-point fractional library routines. 51258 (line 619) 51259* __fractsadi: Fixed-point fractional library routines. 51260 (line 616) 51261* __fractsadq: Fixed-point fractional library routines. 51262 (line 601) 51263* __fractsaha2: Fixed-point fractional library routines. 51264 (line 602) 51265* __fractsahi: Fixed-point fractional library routines. 51266 (line 614) 51267* __fractsahq: Fixed-point fractional library routines. 51268 (line 599) 51269* __fractsaqi: Fixed-point fractional library routines. 51270 (line 613) 51271* __fractsaqq: Fixed-point fractional library routines. 51272 (line 598) 51273* __fractsasf: Fixed-point fractional library routines. 51274 (line 618) 51275* __fractsasi: Fixed-point fractional library routines. 51276 (line 615) 51277* __fractsasq: Fixed-point fractional library routines. 51278 (line 600) 51279* __fractsata2: Fixed-point fractional library routines. 51280 (line 604) 51281* __fractsati: Fixed-point fractional library routines. 51282 (line 617) 51283* __fractsauda: Fixed-point fractional library routines. 51284 (line 611) 51285* __fractsaudq: Fixed-point fractional library routines. 51286 (line 608) 51287* __fractsauha: Fixed-point fractional library routines. 51288 (line 609) 51289* __fractsauhq: Fixed-point fractional library routines. 51290 (line 606) 51291* __fractsauqq: Fixed-point fractional library routines. 51292 (line 605) 51293* __fractsausa: Fixed-point fractional library routines. 51294 (line 610) 51295* __fractsausq: Fixed-point fractional library routines. 51296 (line 607) 51297* __fractsauta: Fixed-point fractional library routines. 51298 (line 612) 51299* __fractsfda: Fixed-point fractional library routines. 51300 (line 1016) 51301* __fractsfdq: Fixed-point fractional library routines. 51302 (line 1013) 51303* __fractsfha: Fixed-point fractional library routines. 51304 (line 1014) 51305* __fractsfhq: Fixed-point fractional library routines. 51306 (line 1011) 51307* __fractsfqq: Fixed-point fractional library routines. 51308 (line 1010) 51309* __fractsfsa: Fixed-point fractional library routines. 51310 (line 1015) 51311* __fractsfsq: Fixed-point fractional library routines. 51312 (line 1012) 51313* __fractsfta: Fixed-point fractional library routines. 51314 (line 1017) 51315* __fractsfuda: Fixed-point fractional library routines. 51316 (line 1024) 51317* __fractsfudq: Fixed-point fractional library routines. 51318 (line 1021) 51319* __fractsfuha: Fixed-point fractional library routines. 51320 (line 1022) 51321* __fractsfuhq: Fixed-point fractional library routines. 51322 (line 1019) 51323* __fractsfuqq: Fixed-point fractional library routines. 51324 (line 1018) 51325* __fractsfusa: Fixed-point fractional library routines. 51326 (line 1023) 51327* __fractsfusq: Fixed-point fractional library routines. 51328 (line 1020) 51329* __fractsfuta: Fixed-point fractional library routines. 51330 (line 1025) 51331* __fractsida: Fixed-point fractional library routines. 51332 (line 966) 51333* __fractsidq: Fixed-point fractional library routines. 51334 (line 963) 51335* __fractsiha: Fixed-point fractional library routines. 51336 (line 964) 51337* __fractsihq: Fixed-point fractional library routines. 51338 (line 961) 51339* __fractsiqq: Fixed-point fractional library routines. 51340 (line 960) 51341* __fractsisa: Fixed-point fractional library routines. 51342 (line 965) 51343* __fractsisq: Fixed-point fractional library routines. 51344 (line 962) 51345* __fractsita: Fixed-point fractional library routines. 51346 (line 967) 51347* __fractsiuda: Fixed-point fractional library routines. 51348 (line 974) 51349* __fractsiudq: Fixed-point fractional library routines. 51350 (line 971) 51351* __fractsiuha: Fixed-point fractional library routines. 51352 (line 972) 51353* __fractsiuhq: Fixed-point fractional library routines. 51354 (line 969) 51355* __fractsiuqq: Fixed-point fractional library routines. 51356 (line 968) 51357* __fractsiusa: Fixed-point fractional library routines. 51358 (line 973) 51359* __fractsiusq: Fixed-point fractional library routines. 51360 (line 970) 51361* __fractsiuta: Fixed-point fractional library routines. 51362 (line 975) 51363* __fractsqda: Fixed-point fractional library routines. 51364 (line 527) 51365* __fractsqdf: Fixed-point fractional library routines. 51366 (line 545) 51367* __fractsqdi: Fixed-point fractional library routines. 51368 (line 542) 51369* __fractsqdq2: Fixed-point fractional library routines. 51370 (line 524) 51371* __fractsqha: Fixed-point fractional library routines. 51372 (line 525) 51373* __fractsqhi: Fixed-point fractional library routines. 51374 (line 540) 51375* __fractsqhq2: Fixed-point fractional library routines. 51376 (line 523) 51377* __fractsqqi: Fixed-point fractional library routines. 51378 (line 539) 51379* __fractsqqq2: Fixed-point fractional library routines. 51380 (line 522) 51381* __fractsqsa: Fixed-point fractional library routines. 51382 (line 526) 51383* __fractsqsf: Fixed-point fractional library routines. 51384 (line 544) 51385* __fractsqsi: Fixed-point fractional library routines. 51386 (line 541) 51387* __fractsqta: Fixed-point fractional library routines. 51388 (line 528) 51389* __fractsqti: Fixed-point fractional library routines. 51390 (line 543) 51391* __fractsquda: Fixed-point fractional library routines. 51392 (line 536) 51393* __fractsqudq: Fixed-point fractional library routines. 51394 (line 532) 51395* __fractsquha: Fixed-point fractional library routines. 51396 (line 534) 51397* __fractsquhq: Fixed-point fractional library routines. 51398 (line 530) 51399* __fractsquqq: Fixed-point fractional library routines. 51400 (line 529) 51401* __fractsqusa: Fixed-point fractional library routines. 51402 (line 535) 51403* __fractsqusq: Fixed-point fractional library routines. 51404 (line 531) 51405* __fractsquta: Fixed-point fractional library routines. 51406 (line 537) 51407* __fracttada2: Fixed-point fractional library routines. 51408 (line 650) 51409* __fracttadf: Fixed-point fractional library routines. 51410 (line 671) 51411* __fracttadi: Fixed-point fractional library routines. 51412 (line 668) 51413* __fracttadq: Fixed-point fractional library routines. 51414 (line 647) 51415* __fracttaha2: Fixed-point fractional library routines. 51416 (line 648) 51417* __fracttahi: Fixed-point fractional library routines. 51418 (line 666) 51419* __fracttahq: Fixed-point fractional library routines. 51420 (line 645) 51421* __fracttaqi: Fixed-point fractional library routines. 51422 (line 665) 51423* __fracttaqq: Fixed-point fractional library routines. 51424 (line 644) 51425* __fracttasa2: Fixed-point fractional library routines. 51426 (line 649) 51427* __fracttasf: Fixed-point fractional library routines. 51428 (line 670) 51429* __fracttasi: Fixed-point fractional library routines. 51430 (line 667) 51431* __fracttasq: Fixed-point fractional library routines. 51432 (line 646) 51433* __fracttati: Fixed-point fractional library routines. 51434 (line 669) 51435* __fracttauda: Fixed-point fractional library routines. 51436 (line 661) 51437* __fracttaudq: Fixed-point fractional library routines. 51438 (line 656) 51439* __fracttauha: Fixed-point fractional library routines. 51440 (line 658) 51441* __fracttauhq: Fixed-point fractional library routines. 51442 (line 653) 51443* __fracttauqq: Fixed-point fractional library routines. 51444 (line 651) 51445* __fracttausa: Fixed-point fractional library routines. 51446 (line 660) 51447* __fracttausq: Fixed-point fractional library routines. 51448 (line 654) 51449* __fracttauta: Fixed-point fractional library routines. 51450 (line 663) 51451* __fracttida: Fixed-point fractional library routines. 51452 (line 998) 51453* __fracttidq: Fixed-point fractional library routines. 51454 (line 995) 51455* __fracttiha: Fixed-point fractional library routines. 51456 (line 996) 51457* __fracttihq: Fixed-point fractional library routines. 51458 (line 993) 51459* __fracttiqq: Fixed-point fractional library routines. 51460 (line 992) 51461* __fracttisa: Fixed-point fractional library routines. 51462 (line 997) 51463* __fracttisq: Fixed-point fractional library routines. 51464 (line 994) 51465* __fracttita: Fixed-point fractional library routines. 51466 (line 999) 51467* __fracttiuda: Fixed-point fractional library routines. 51468 (line 1007) 51469* __fracttiudq: Fixed-point fractional library routines. 51470 (line 1003) 51471* __fracttiuha: Fixed-point fractional library routines. 51472 (line 1005) 51473* __fracttiuhq: Fixed-point fractional library routines. 51474 (line 1001) 51475* __fracttiuqq: Fixed-point fractional library routines. 51476 (line 1000) 51477* __fracttiusa: Fixed-point fractional library routines. 51478 (line 1006) 51479* __fracttiusq: Fixed-point fractional library routines. 51480 (line 1002) 51481* __fracttiuta: Fixed-point fractional library routines. 51482 (line 1008) 51483* __fractudada: Fixed-point fractional library routines. 51484 (line 865) 51485* __fractudadf: Fixed-point fractional library routines. 51486 (line 888) 51487* __fractudadi: Fixed-point fractional library routines. 51488 (line 885) 51489* __fractudadq: Fixed-point fractional library routines. 51490 (line 861) 51491* __fractudaha: Fixed-point fractional library routines. 51492 (line 863) 51493* __fractudahi: Fixed-point fractional library routines. 51494 (line 883) 51495* __fractudahq: Fixed-point fractional library routines. 51496 (line 859) 51497* __fractudaqi: Fixed-point fractional library routines. 51498 (line 882) 51499* __fractudaqq: Fixed-point fractional library routines. 51500 (line 858) 51501* __fractudasa: Fixed-point fractional library routines. 51502 (line 864) 51503* __fractudasf: Fixed-point fractional library routines. 51504 (line 887) 51505* __fractudasi: Fixed-point fractional library routines. 51506 (line 884) 51507* __fractudasq: Fixed-point fractional library routines. 51508 (line 860) 51509* __fractudata: Fixed-point fractional library routines. 51510 (line 866) 51511* __fractudati: Fixed-point fractional library routines. 51512 (line 886) 51513* __fractudaudq: Fixed-point fractional library routines. 51514 (line 874) 51515* __fractudauha2: Fixed-point fractional library routines. 51516 (line 876) 51517* __fractudauhq: Fixed-point fractional library routines. 51518 (line 870) 51519* __fractudauqq: Fixed-point fractional library routines. 51520 (line 868) 51521* __fractudausa2: Fixed-point fractional library routines. 51522 (line 878) 51523* __fractudausq: Fixed-point fractional library routines. 51524 (line 872) 51525* __fractudauta2: Fixed-point fractional library routines. 51526 (line 880) 51527* __fractudqda: Fixed-point fractional library routines. 51528 (line 772) 51529* __fractudqdf: Fixed-point fractional library routines. 51530 (line 798) 51531* __fractudqdi: Fixed-point fractional library routines. 51532 (line 794) 51533* __fractudqdq: Fixed-point fractional library routines. 51534 (line 767) 51535* __fractudqha: Fixed-point fractional library routines. 51536 (line 769) 51537* __fractudqhi: Fixed-point fractional library routines. 51538 (line 792) 51539* __fractudqhq: Fixed-point fractional library routines. 51540 (line 764) 51541* __fractudqqi: Fixed-point fractional library routines. 51542 (line 790) 51543* __fractudqqq: Fixed-point fractional library routines. 51544 (line 762) 51545* __fractudqsa: Fixed-point fractional library routines. 51546 (line 771) 51547* __fractudqsf: Fixed-point fractional library routines. 51548 (line 797) 51549* __fractudqsi: Fixed-point fractional library routines. 51550 (line 793) 51551* __fractudqsq: Fixed-point fractional library routines. 51552 (line 765) 51553* __fractudqta: Fixed-point fractional library routines. 51554 (line 774) 51555* __fractudqti: Fixed-point fractional library routines. 51556 (line 795) 51557* __fractudquda: Fixed-point fractional library routines. 51558 (line 786) 51559* __fractudquha: Fixed-point fractional library routines. 51560 (line 782) 51561* __fractudquhq2: Fixed-point fractional library routines. 51562 (line 778) 51563* __fractudquqq2: Fixed-point fractional library routines. 51564 (line 776) 51565* __fractudqusa: Fixed-point fractional library routines. 51566 (line 784) 51567* __fractudqusq2: Fixed-point fractional library routines. 51568 (line 780) 51569* __fractudquta: Fixed-point fractional library routines. 51570 (line 788) 51571* __fractuhada: Fixed-point fractional library routines. 51572 (line 806) 51573* __fractuhadf: Fixed-point fractional library routines. 51574 (line 829) 51575* __fractuhadi: Fixed-point fractional library routines. 51576 (line 826) 51577* __fractuhadq: Fixed-point fractional library routines. 51578 (line 802) 51579* __fractuhaha: Fixed-point fractional library routines. 51580 (line 804) 51581* __fractuhahi: Fixed-point fractional library routines. 51582 (line 824) 51583* __fractuhahq: Fixed-point fractional library routines. 51584 (line 800) 51585* __fractuhaqi: Fixed-point fractional library routines. 51586 (line 823) 51587* __fractuhaqq: Fixed-point fractional library routines. 51588 (line 799) 51589* __fractuhasa: Fixed-point fractional library routines. 51590 (line 805) 51591* __fractuhasf: Fixed-point fractional library routines. 51592 (line 828) 51593* __fractuhasi: Fixed-point fractional library routines. 51594 (line 825) 51595* __fractuhasq: Fixed-point fractional library routines. 51596 (line 801) 51597* __fractuhata: Fixed-point fractional library routines. 51598 (line 807) 51599* __fractuhati: Fixed-point fractional library routines. 51600 (line 827) 51601* __fractuhauda2: Fixed-point fractional library routines. 51602 (line 819) 51603* __fractuhaudq: Fixed-point fractional library routines. 51604 (line 815) 51605* __fractuhauhq: Fixed-point fractional library routines. 51606 (line 811) 51607* __fractuhauqq: Fixed-point fractional library routines. 51608 (line 809) 51609* __fractuhausa2: Fixed-point fractional library routines. 51610 (line 817) 51611* __fractuhausq: Fixed-point fractional library routines. 51612 (line 813) 51613* __fractuhauta2: Fixed-point fractional library routines. 51614 (line 821) 51615* __fractuhqda: Fixed-point fractional library routines. 51616 (line 709) 51617* __fractuhqdf: Fixed-point fractional library routines. 51618 (line 730) 51619* __fractuhqdi: Fixed-point fractional library routines. 51620 (line 727) 51621* __fractuhqdq: Fixed-point fractional library routines. 51622 (line 706) 51623* __fractuhqha: Fixed-point fractional library routines. 51624 (line 707) 51625* __fractuhqhi: Fixed-point fractional library routines. 51626 (line 725) 51627* __fractuhqhq: Fixed-point fractional library routines. 51628 (line 704) 51629* __fractuhqqi: Fixed-point fractional library routines. 51630 (line 724) 51631* __fractuhqqq: Fixed-point fractional library routines. 51632 (line 703) 51633* __fractuhqsa: Fixed-point fractional library routines. 51634 (line 708) 51635* __fractuhqsf: Fixed-point fractional library routines. 51636 (line 729) 51637* __fractuhqsi: Fixed-point fractional library routines. 51638 (line 726) 51639* __fractuhqsq: Fixed-point fractional library routines. 51640 (line 705) 51641* __fractuhqta: Fixed-point fractional library routines. 51642 (line 710) 51643* __fractuhqti: Fixed-point fractional library routines. 51644 (line 728) 51645* __fractuhquda: Fixed-point fractional library routines. 51646 (line 720) 51647* __fractuhqudq2: Fixed-point fractional library routines. 51648 (line 715) 51649* __fractuhquha: Fixed-point fractional library routines. 51650 (line 717) 51651* __fractuhquqq2: Fixed-point fractional library routines. 51652 (line 711) 51653* __fractuhqusa: Fixed-point fractional library routines. 51654 (line 719) 51655* __fractuhqusq2: Fixed-point fractional library routines. 51656 (line 713) 51657* __fractuhquta: Fixed-point fractional library routines. 51658 (line 722) 51659* __fractunsdadi: Fixed-point fractional library routines. 51660 (line 1562) 51661* __fractunsdahi: Fixed-point fractional library routines. 51662 (line 1560) 51663* __fractunsdaqi: Fixed-point fractional library routines. 51664 (line 1559) 51665* __fractunsdasi: Fixed-point fractional library routines. 51666 (line 1561) 51667* __fractunsdati: Fixed-point fractional library routines. 51668 (line 1563) 51669* __fractunsdida: Fixed-point fractional library routines. 51670 (line 1714) 51671* __fractunsdidq: Fixed-point fractional library routines. 51672 (line 1711) 51673* __fractunsdiha: Fixed-point fractional library routines. 51674 (line 1712) 51675* __fractunsdihq: Fixed-point fractional library routines. 51676 (line 1709) 51677* __fractunsdiqq: Fixed-point fractional library routines. 51678 (line 1708) 51679* __fractunsdisa: Fixed-point fractional library routines. 51680 (line 1713) 51681* __fractunsdisq: Fixed-point fractional library routines. 51682 (line 1710) 51683* __fractunsdita: Fixed-point fractional library routines. 51684 (line 1715) 51685* __fractunsdiuda: Fixed-point fractional library routines. 51686 (line 1726) 51687* __fractunsdiudq: Fixed-point fractional library routines. 51688 (line 1721) 51689* __fractunsdiuha: Fixed-point fractional library routines. 51690 (line 1723) 51691* __fractunsdiuhq: Fixed-point fractional library routines. 51692 (line 1718) 51693* __fractunsdiuqq: Fixed-point fractional library routines. 51694 (line 1716) 51695* __fractunsdiusa: Fixed-point fractional library routines. 51696 (line 1725) 51697* __fractunsdiusq: Fixed-point fractional library routines. 51698 (line 1719) 51699* __fractunsdiuta: Fixed-point fractional library routines. 51700 (line 1728) 51701* __fractunsdqdi: Fixed-point fractional library routines. 51702 (line 1546) 51703* __fractunsdqhi: Fixed-point fractional library routines. 51704 (line 1544) 51705* __fractunsdqqi: Fixed-point fractional library routines. 51706 (line 1543) 51707* __fractunsdqsi: Fixed-point fractional library routines. 51708 (line 1545) 51709* __fractunsdqti: Fixed-point fractional library routines. 51710 (line 1547) 51711* __fractunshadi: Fixed-point fractional library routines. 51712 (line 1552) 51713* __fractunshahi: Fixed-point fractional library routines. 51714 (line 1550) 51715* __fractunshaqi: Fixed-point fractional library routines. 51716 (line 1549) 51717* __fractunshasi: Fixed-point fractional library routines. 51718 (line 1551) 51719* __fractunshati: Fixed-point fractional library routines. 51720 (line 1553) 51721* __fractunshida: Fixed-point fractional library routines. 51722 (line 1670) 51723* __fractunshidq: Fixed-point fractional library routines. 51724 (line 1667) 51725* __fractunshiha: Fixed-point fractional library routines. 51726 (line 1668) 51727* __fractunshihq: Fixed-point fractional library routines. 51728 (line 1665) 51729* __fractunshiqq: Fixed-point fractional library routines. 51730 (line 1664) 51731* __fractunshisa: Fixed-point fractional library routines. 51732 (line 1669) 51733* __fractunshisq: Fixed-point fractional library routines. 51734 (line 1666) 51735* __fractunshita: Fixed-point fractional library routines. 51736 (line 1671) 51737* __fractunshiuda: Fixed-point fractional library routines. 51738 (line 1682) 51739* __fractunshiudq: Fixed-point fractional library routines. 51740 (line 1677) 51741* __fractunshiuha: Fixed-point fractional library routines. 51742 (line 1679) 51743* __fractunshiuhq: Fixed-point fractional library routines. 51744 (line 1674) 51745* __fractunshiuqq: Fixed-point fractional library routines. 51746 (line 1672) 51747* __fractunshiusa: Fixed-point fractional library routines. 51748 (line 1681) 51749* __fractunshiusq: Fixed-point fractional library routines. 51750 (line 1675) 51751* __fractunshiuta: Fixed-point fractional library routines. 51752 (line 1684) 51753* __fractunshqdi: Fixed-point fractional library routines. 51754 (line 1536) 51755* __fractunshqhi: Fixed-point fractional library routines. 51756 (line 1534) 51757* __fractunshqqi: Fixed-point fractional library routines. 51758 (line 1533) 51759* __fractunshqsi: Fixed-point fractional library routines. 51760 (line 1535) 51761* __fractunshqti: Fixed-point fractional library routines. 51762 (line 1537) 51763* __fractunsqida: Fixed-point fractional library routines. 51764 (line 1648) 51765* __fractunsqidq: Fixed-point fractional library routines. 51766 (line 1645) 51767* __fractunsqiha: Fixed-point fractional library routines. 51768 (line 1646) 51769* __fractunsqihq: Fixed-point fractional library routines. 51770 (line 1643) 51771* __fractunsqiqq: Fixed-point fractional library routines. 51772 (line 1642) 51773* __fractunsqisa: Fixed-point fractional library routines. 51774 (line 1647) 51775* __fractunsqisq: Fixed-point fractional library routines. 51776 (line 1644) 51777* __fractunsqita: Fixed-point fractional library routines. 51778 (line 1649) 51779* __fractunsqiuda: Fixed-point fractional library routines. 51780 (line 1660) 51781* __fractunsqiudq: Fixed-point fractional library routines. 51782 (line 1655) 51783* __fractunsqiuha: Fixed-point fractional library routines. 51784 (line 1657) 51785* __fractunsqiuhq: Fixed-point fractional library routines. 51786 (line 1652) 51787* __fractunsqiuqq: Fixed-point fractional library routines. 51788 (line 1650) 51789* __fractunsqiusa: Fixed-point fractional library routines. 51790 (line 1659) 51791* __fractunsqiusq: Fixed-point fractional library routines. 51792 (line 1653) 51793* __fractunsqiuta: Fixed-point fractional library routines. 51794 (line 1662) 51795* __fractunsqqdi: Fixed-point fractional library routines. 51796 (line 1531) 51797* __fractunsqqhi: Fixed-point fractional library routines. 51798 (line 1529) 51799* __fractunsqqqi: Fixed-point fractional library routines. 51800 (line 1528) 51801* __fractunsqqsi: Fixed-point fractional library routines. 51802 (line 1530) 51803* __fractunsqqti: Fixed-point fractional library routines. 51804 (line 1532) 51805* __fractunssadi: Fixed-point fractional library routines. 51806 (line 1557) 51807* __fractunssahi: Fixed-point fractional library routines. 51808 (line 1555) 51809* __fractunssaqi: Fixed-point fractional library routines. 51810 (line 1554) 51811* __fractunssasi: Fixed-point fractional library routines. 51812 (line 1556) 51813* __fractunssati: Fixed-point fractional library routines. 51814 (line 1558) 51815* __fractunssida: Fixed-point fractional library routines. 51816 (line 1692) 51817* __fractunssidq: Fixed-point fractional library routines. 51818 (line 1689) 51819* __fractunssiha: Fixed-point fractional library routines. 51820 (line 1690) 51821* __fractunssihq: Fixed-point fractional library routines. 51822 (line 1687) 51823* __fractunssiqq: Fixed-point fractional library routines. 51824 (line 1686) 51825* __fractunssisa: Fixed-point fractional library routines. 51826 (line 1691) 51827* __fractunssisq: Fixed-point fractional library routines. 51828 (line 1688) 51829* __fractunssita: Fixed-point fractional library routines. 51830 (line 1693) 51831* __fractunssiuda: Fixed-point fractional library routines. 51832 (line 1704) 51833* __fractunssiudq: Fixed-point fractional library routines. 51834 (line 1699) 51835* __fractunssiuha: Fixed-point fractional library routines. 51836 (line 1701) 51837* __fractunssiuhq: Fixed-point fractional library routines. 51838 (line 1696) 51839* __fractunssiuqq: Fixed-point fractional library routines. 51840 (line 1694) 51841* __fractunssiusa: Fixed-point fractional library routines. 51842 (line 1703) 51843* __fractunssiusq: Fixed-point fractional library routines. 51844 (line 1697) 51845* __fractunssiuta: Fixed-point fractional library routines. 51846 (line 1706) 51847* __fractunssqdi: Fixed-point fractional library routines. 51848 (line 1541) 51849* __fractunssqhi: Fixed-point fractional library routines. 51850 (line 1539) 51851* __fractunssqqi: Fixed-point fractional library routines. 51852 (line 1538) 51853* __fractunssqsi: Fixed-point fractional library routines. 51854 (line 1540) 51855* __fractunssqti: Fixed-point fractional library routines. 51856 (line 1542) 51857* __fractunstadi: Fixed-point fractional library routines. 51858 (line 1567) 51859* __fractunstahi: Fixed-point fractional library routines. 51860 (line 1565) 51861* __fractunstaqi: Fixed-point fractional library routines. 51862 (line 1564) 51863* __fractunstasi: Fixed-point fractional library routines. 51864 (line 1566) 51865* __fractunstati: Fixed-point fractional library routines. 51866 (line 1568) 51867* __fractunstida: Fixed-point fractional library routines. 51868 (line 1737) 51869* __fractunstidq: Fixed-point fractional library routines. 51870 (line 1733) 51871* __fractunstiha: Fixed-point fractional library routines. 51872 (line 1735) 51873* __fractunstihq: Fixed-point fractional library routines. 51874 (line 1731) 51875* __fractunstiqq: Fixed-point fractional library routines. 51876 (line 1730) 51877* __fractunstisa: Fixed-point fractional library routines. 51878 (line 1736) 51879* __fractunstisq: Fixed-point fractional library routines. 51880 (line 1732) 51881* __fractunstita: Fixed-point fractional library routines. 51882 (line 1738) 51883* __fractunstiuda: Fixed-point fractional library routines. 51884 (line 1752) 51885* __fractunstiudq: Fixed-point fractional library routines. 51886 (line 1746) 51887* __fractunstiuha: Fixed-point fractional library routines. 51888 (line 1748) 51889* __fractunstiuhq: Fixed-point fractional library routines. 51890 (line 1742) 51891* __fractunstiuqq: Fixed-point fractional library routines. 51892 (line 1740) 51893* __fractunstiusa: Fixed-point fractional library routines. 51894 (line 1750) 51895* __fractunstiusq: Fixed-point fractional library routines. 51896 (line 1744) 51897* __fractunstiuta: Fixed-point fractional library routines. 51898 (line 1754) 51899* __fractunsudadi: Fixed-point fractional library routines. 51900 (line 1628) 51901* __fractunsudahi: Fixed-point fractional library routines. 51902 (line 1624) 51903* __fractunsudaqi: Fixed-point fractional library routines. 51904 (line 1622) 51905* __fractunsudasi: Fixed-point fractional library routines. 51906 (line 1626) 51907* __fractunsudati: Fixed-point fractional library routines. 51908 (line 1630) 51909* __fractunsudqdi: Fixed-point fractional library routines. 51910 (line 1602) 51911* __fractunsudqhi: Fixed-point fractional library routines. 51912 (line 1598) 51913* __fractunsudqqi: Fixed-point fractional library routines. 51914 (line 1596) 51915* __fractunsudqsi: Fixed-point fractional library routines. 51916 (line 1600) 51917* __fractunsudqti: Fixed-point fractional library routines. 51918 (line 1604) 51919* __fractunsuhadi: Fixed-point fractional library routines. 51920 (line 1612) 51921* __fractunsuhahi: Fixed-point fractional library routines. 51922 (line 1608) 51923* __fractunsuhaqi: Fixed-point fractional library routines. 51924 (line 1606) 51925* __fractunsuhasi: Fixed-point fractional library routines. 51926 (line 1610) 51927* __fractunsuhati: Fixed-point fractional library routines. 51928 (line 1614) 51929* __fractunsuhqdi: Fixed-point fractional library routines. 51930 (line 1583) 51931* __fractunsuhqhi: Fixed-point fractional library routines. 51932 (line 1581) 51933* __fractunsuhqqi: Fixed-point fractional library routines. 51934 (line 1580) 51935* __fractunsuhqsi: Fixed-point fractional library routines. 51936 (line 1582) 51937* __fractunsuhqti: Fixed-point fractional library routines. 51938 (line 1584) 51939* __fractunsuqqdi: Fixed-point fractional library routines. 51940 (line 1576) 51941* __fractunsuqqhi: Fixed-point fractional library routines. 51942 (line 1572) 51943* __fractunsuqqqi: Fixed-point fractional library routines. 51944 (line 1570) 51945* __fractunsuqqsi: Fixed-point fractional library routines. 51946 (line 1574) 51947* __fractunsuqqti: Fixed-point fractional library routines. 51948 (line 1578) 51949* __fractunsusadi: Fixed-point fractional library routines. 51950 (line 1619) 51951* __fractunsusahi: Fixed-point fractional library routines. 51952 (line 1617) 51953* __fractunsusaqi: Fixed-point fractional library routines. 51954 (line 1616) 51955* __fractunsusasi: Fixed-point fractional library routines. 51956 (line 1618) 51957* __fractunsusati: Fixed-point fractional library routines. 51958 (line 1620) 51959* __fractunsusqdi: Fixed-point fractional library routines. 51960 (line 1592) 51961* __fractunsusqhi: Fixed-point fractional library routines. 51962 (line 1588) 51963* __fractunsusqqi: Fixed-point fractional library routines. 51964 (line 1586) 51965* __fractunsusqsi: Fixed-point fractional library routines. 51966 (line 1590) 51967* __fractunsusqti: Fixed-point fractional library routines. 51968 (line 1594) 51969* __fractunsutadi: Fixed-point fractional library routines. 51970 (line 1638) 51971* __fractunsutahi: Fixed-point fractional library routines. 51972 (line 1634) 51973* __fractunsutaqi: Fixed-point fractional library routines. 51974 (line 1632) 51975* __fractunsutasi: Fixed-point fractional library routines. 51976 (line 1636) 51977* __fractunsutati: Fixed-point fractional library routines. 51978 (line 1640) 51979* __fractuqqda: Fixed-point fractional library routines. 51980 (line 679) 51981* __fractuqqdf: Fixed-point fractional library routines. 51982 (line 702) 51983* __fractuqqdi: Fixed-point fractional library routines. 51984 (line 699) 51985* __fractuqqdq: Fixed-point fractional library routines. 51986 (line 675) 51987* __fractuqqha: Fixed-point fractional library routines. 51988 (line 677) 51989* __fractuqqhi: Fixed-point fractional library routines. 51990 (line 697) 51991* __fractuqqhq: Fixed-point fractional library routines. 51992 (line 673) 51993* __fractuqqqi: Fixed-point fractional library routines. 51994 (line 696) 51995* __fractuqqqq: Fixed-point fractional library routines. 51996 (line 672) 51997* __fractuqqsa: Fixed-point fractional library routines. 51998 (line 678) 51999* __fractuqqsf: Fixed-point fractional library routines. 52000 (line 701) 52001* __fractuqqsi: Fixed-point fractional library routines. 52002 (line 698) 52003* __fractuqqsq: Fixed-point fractional library routines. 52004 (line 674) 52005* __fractuqqta: Fixed-point fractional library routines. 52006 (line 680) 52007* __fractuqqti: Fixed-point fractional library routines. 52008 (line 700) 52009* __fractuqquda: Fixed-point fractional library routines. 52010 (line 692) 52011* __fractuqqudq2: Fixed-point fractional library routines. 52012 (line 686) 52013* __fractuqquha: Fixed-point fractional library routines. 52014 (line 688) 52015* __fractuqquhq2: Fixed-point fractional library routines. 52016 (line 682) 52017* __fractuqqusa: Fixed-point fractional library routines. 52018 (line 690) 52019* __fractuqqusq2: Fixed-point fractional library routines. 52020 (line 684) 52021* __fractuqquta: Fixed-point fractional library routines. 52022 (line 694) 52023* __fractusada: Fixed-point fractional library routines. 52024 (line 836) 52025* __fractusadf: Fixed-point fractional library routines. 52026 (line 857) 52027* __fractusadi: Fixed-point fractional library routines. 52028 (line 854) 52029* __fractusadq: Fixed-point fractional library routines. 52030 (line 833) 52031* __fractusaha: Fixed-point fractional library routines. 52032 (line 834) 52033* __fractusahi: Fixed-point fractional library routines. 52034 (line 852) 52035* __fractusahq: Fixed-point fractional library routines. 52036 (line 831) 52037* __fractusaqi: Fixed-point fractional library routines. 52038 (line 851) 52039* __fractusaqq: Fixed-point fractional library routines. 52040 (line 830) 52041* __fractusasa: Fixed-point fractional library routines. 52042 (line 835) 52043* __fractusasf: Fixed-point fractional library routines. 52044 (line 856) 52045* __fractusasi: Fixed-point fractional library routines. 52046 (line 853) 52047* __fractusasq: Fixed-point fractional library routines. 52048 (line 832) 52049* __fractusata: Fixed-point fractional library routines. 52050 (line 837) 52051* __fractusati: Fixed-point fractional library routines. 52052 (line 855) 52053* __fractusauda2: Fixed-point fractional library routines. 52054 (line 847) 52055* __fractusaudq: Fixed-point fractional library routines. 52056 (line 843) 52057* __fractusauha2: Fixed-point fractional library routines. 52058 (line 845) 52059* __fractusauhq: Fixed-point fractional library routines. 52060 (line 840) 52061* __fractusauqq: Fixed-point fractional library routines. 52062 (line 838) 52063* __fractusausq: Fixed-point fractional library routines. 52064 (line 841) 52065* __fractusauta2: Fixed-point fractional library routines. 52066 (line 849) 52067* __fractusqda: Fixed-point fractional library routines. 52068 (line 738) 52069* __fractusqdf: Fixed-point fractional library routines. 52070 (line 761) 52071* __fractusqdi: Fixed-point fractional library routines. 52072 (line 758) 52073* __fractusqdq: Fixed-point fractional library routines. 52074 (line 734) 52075* __fractusqha: Fixed-point fractional library routines. 52076 (line 736) 52077* __fractusqhi: Fixed-point fractional library routines. 52078 (line 756) 52079* __fractusqhq: Fixed-point fractional library routines. 52080 (line 732) 52081* __fractusqqi: Fixed-point fractional library routines. 52082 (line 755) 52083* __fractusqqq: Fixed-point fractional library routines. 52084 (line 731) 52085* __fractusqsa: Fixed-point fractional library routines. 52086 (line 737) 52087* __fractusqsf: Fixed-point fractional library routines. 52088 (line 760) 52089* __fractusqsi: Fixed-point fractional library routines. 52090 (line 757) 52091* __fractusqsq: Fixed-point fractional library routines. 52092 (line 733) 52093* __fractusqta: Fixed-point fractional library routines. 52094 (line 739) 52095* __fractusqti: Fixed-point fractional library routines. 52096 (line 759) 52097* __fractusquda: Fixed-point fractional library routines. 52098 (line 751) 52099* __fractusqudq2: Fixed-point fractional library routines. 52100 (line 745) 52101* __fractusquha: Fixed-point fractional library routines. 52102 (line 747) 52103* __fractusquhq2: Fixed-point fractional library routines. 52104 (line 743) 52105* __fractusquqq2: Fixed-point fractional library routines. 52106 (line 741) 52107* __fractusqusa: Fixed-point fractional library routines. 52108 (line 749) 52109* __fractusquta: Fixed-point fractional library routines. 52110 (line 753) 52111* __fractutada: Fixed-point fractional library routines. 52112 (line 899) 52113* __fractutadf: Fixed-point fractional library routines. 52114 (line 925) 52115* __fractutadi: Fixed-point fractional library routines. 52116 (line 921) 52117* __fractutadq: Fixed-point fractional library routines. 52118 (line 894) 52119* __fractutaha: Fixed-point fractional library routines. 52120 (line 896) 52121* __fractutahi: Fixed-point fractional library routines. 52122 (line 919) 52123* __fractutahq: Fixed-point fractional library routines. 52124 (line 891) 52125* __fractutaqi: Fixed-point fractional library routines. 52126 (line 917) 52127* __fractutaqq: Fixed-point fractional library routines. 52128 (line 889) 52129* __fractutasa: Fixed-point fractional library routines. 52130 (line 898) 52131* __fractutasf: Fixed-point fractional library routines. 52132 (line 924) 52133* __fractutasi: Fixed-point fractional library routines. 52134 (line 920) 52135* __fractutasq: Fixed-point fractional library routines. 52136 (line 892) 52137* __fractutata: Fixed-point fractional library routines. 52138 (line 901) 52139* __fractutati: Fixed-point fractional library routines. 52140 (line 922) 52141* __fractutauda2: Fixed-point fractional library routines. 52142 (line 915) 52143* __fractutaudq: Fixed-point fractional library routines. 52144 (line 909) 52145* __fractutauha2: Fixed-point fractional library routines. 52146 (line 911) 52147* __fractutauhq: Fixed-point fractional library routines. 52148 (line 905) 52149* __fractutauqq: Fixed-point fractional library routines. 52150 (line 903) 52151* __fractutausa2: Fixed-point fractional library routines. 52152 (line 913) 52153* __fractutausq: Fixed-point fractional library routines. 52154 (line 907) 52155* __gedf2: Soft float library routines. 52156 (line 205) 52157* __gesf2: Soft float library routines. 52158 (line 204) 52159* __getf2: Soft float library routines. 52160 (line 206) 52161* __gtdf2: Soft float library routines. 52162 (line 223) 52163* __gtsf2: Soft float library routines. 52164 (line 222) 52165* __gttf2: Soft float library routines. 52166 (line 224) 52167* __ledf2: Soft float library routines. 52168 (line 217) 52169* __lesf2: Soft float library routines. 52170 (line 216) 52171* __letf2: Soft float library routines. 52172 (line 218) 52173* __lshrdi3: Integer library routines. 52174 (line 30) 52175* __lshrsi3: Integer library routines. 52176 (line 29) 52177* __lshrti3: Integer library routines. 52178 (line 31) 52179* __lshruda3: Fixed-point fractional library routines. 52180 (line 396) 52181* __lshrudq3: Fixed-point fractional library routines. 52182 (line 390) 52183* __lshruha3: Fixed-point fractional library routines. 52184 (line 392) 52185* __lshruhq3: Fixed-point fractional library routines. 52186 (line 386) 52187* __lshruqq3: Fixed-point fractional library routines. 52188 (line 384) 52189* __lshrusa3: Fixed-point fractional library routines. 52190 (line 394) 52191* __lshrusq3: Fixed-point fractional library routines. 52192 (line 388) 52193* __lshruta3: Fixed-point fractional library routines. 52194 (line 398) 52195* __ltdf2: Soft float library routines. 52196 (line 211) 52197* __ltsf2: Soft float library routines. 52198 (line 210) 52199* __lttf2: Soft float library routines. 52200 (line 212) 52201* __main: Collect2. (line 15) 52202* __moddi3: Integer library routines. 52203 (line 36) 52204* __modsi3: Integer library routines. 52205 (line 35) 52206* __modti3: Integer library routines. 52207 (line 37) 52208* __morestack_current_segment: Miscellaneous routines. 52209 (line 45) 52210* __morestack_initial_sp: Miscellaneous routines. 52211 (line 46) 52212* __morestack_segments: Miscellaneous routines. 52213 (line 44) 52214* __mulda3: Fixed-point fractional library routines. 52215 (line 178) 52216* __muldc3: Soft float library routines. 52217 (line 239) 52218* __muldf3: Soft float library routines. 52219 (line 39) 52220* __muldi3: Integer library routines. 52221 (line 42) 52222* __muldq3: Fixed-point fractional library routines. 52223 (line 165) 52224* __mulha3: Fixed-point fractional library routines. 52225 (line 175) 52226* __mulhq3: Fixed-point fractional library routines. 52227 (line 163) 52228* __mulqq3: Fixed-point fractional library routines. 52229 (line 161) 52230* __mulsa3: Fixed-point fractional library routines. 52231 (line 177) 52232* __mulsc3: Soft float library routines. 52233 (line 237) 52234* __mulsf3: Soft float library routines. 52235 (line 38) 52236* __mulsi3: Integer library routines. 52237 (line 41) 52238* __mulsq3: Fixed-point fractional library routines. 52239 (line 164) 52240* __multa3: Fixed-point fractional library routines. 52241 (line 179) 52242* __multc3: Soft float library routines. 52243 (line 241) 52244* __multf3: Soft float library routines. 52245 (line 40) 52246* __multi3: Integer library routines. 52247 (line 43) 52248* __muluda3: Fixed-point fractional library routines. 52249 (line 185) 52250* __muludq3: Fixed-point fractional library routines. 52251 (line 173) 52252* __muluha3: Fixed-point fractional library routines. 52253 (line 181) 52254* __muluhq3: Fixed-point fractional library routines. 52255 (line 169) 52256* __muluqq3: Fixed-point fractional library routines. 52257 (line 167) 52258* __mulusa3: Fixed-point fractional library routines. 52259 (line 183) 52260* __mulusq3: Fixed-point fractional library routines. 52261 (line 171) 52262* __muluta3: Fixed-point fractional library routines. 52263 (line 187) 52264* __mulvdi3: Integer library routines. 52265 (line 114) 52266* __mulvsi3: Integer library routines. 52267 (line 113) 52268* __mulxc3: Soft float library routines. 52269 (line 243) 52270* __mulxf3: Soft float library routines. 52271 (line 42) 52272* __nedf2: Soft float library routines. 52273 (line 199) 52274* __negda2: Fixed-point fractional library routines. 52275 (line 306) 52276* __negdf2: Soft float library routines. 52277 (line 55) 52278* __negdi2: Integer library routines. 52279 (line 46) 52280* __negdq2: Fixed-point fractional library routines. 52281 (line 296) 52282* __negha2: Fixed-point fractional library routines. 52283 (line 304) 52284* __neghq2: Fixed-point fractional library routines. 52285 (line 294) 52286* __negqq2: Fixed-point fractional library routines. 52287 (line 293) 52288* __negsa2: Fixed-point fractional library routines. 52289 (line 305) 52290* __negsf2: Soft float library routines. 52291 (line 54) 52292* __negsq2: Fixed-point fractional library routines. 52293 (line 295) 52294* __negta2: Fixed-point fractional library routines. 52295 (line 307) 52296* __negtf2: Soft float library routines. 52297 (line 56) 52298* __negti2: Integer library routines. 52299 (line 47) 52300* __neguda2: Fixed-point fractional library routines. 52301 (line 311) 52302* __negudq2: Fixed-point fractional library routines. 52303 (line 302) 52304* __neguha2: Fixed-point fractional library routines. 52305 (line 308) 52306* __neguhq2: Fixed-point fractional library routines. 52307 (line 299) 52308* __neguqq2: Fixed-point fractional library routines. 52309 (line 297) 52310* __negusa2: Fixed-point fractional library routines. 52311 (line 310) 52312* __negusq2: Fixed-point fractional library routines. 52313 (line 300) 52314* __neguta2: Fixed-point fractional library routines. 52315 (line 313) 52316* __negvdi2: Integer library routines. 52317 (line 118) 52318* __negvsi2: Integer library routines. 52319 (line 117) 52320* __negxf2: Soft float library routines. 52321 (line 57) 52322* __nesf2: Soft float library routines. 52323 (line 198) 52324* __netf2: Soft float library routines. 52325 (line 200) 52326* __paritydi2: Integer library routines. 52327 (line 150) 52328* __paritysi2: Integer library routines. 52329 (line 149) 52330* __parityti2: Integer library routines. 52331 (line 151) 52332* __popcountdi2: Integer library routines. 52333 (line 156) 52334* __popcountsi2: Integer library routines. 52335 (line 155) 52336* __popcountti2: Integer library routines. 52337 (line 157) 52338* __powidf2: Soft float library routines. 52339 (line 232) 52340* __powisf2: Soft float library routines. 52341 (line 231) 52342* __powitf2: Soft float library routines. 52343 (line 233) 52344* __powixf2: Soft float library routines. 52345 (line 234) 52346* __satfractdadq: Fixed-point fractional library routines. 52347 (line 1160) 52348* __satfractdaha2: Fixed-point fractional library routines. 52349 (line 1161) 52350* __satfractdahq: Fixed-point fractional library routines. 52351 (line 1158) 52352* __satfractdaqq: Fixed-point fractional library routines. 52353 (line 1157) 52354* __satfractdasa2: Fixed-point fractional library routines. 52355 (line 1162) 52356* __satfractdasq: Fixed-point fractional library routines. 52357 (line 1159) 52358* __satfractdata2: Fixed-point fractional library routines. 52359 (line 1163) 52360* __satfractdauda: Fixed-point fractional library routines. 52361 (line 1173) 52362* __satfractdaudq: Fixed-point fractional library routines. 52363 (line 1168) 52364* __satfractdauha: Fixed-point fractional library routines. 52365 (line 1170) 52366* __satfractdauhq: Fixed-point fractional library routines. 52367 (line 1166) 52368* __satfractdauqq: Fixed-point fractional library routines. 52369 (line 1164) 52370* __satfractdausa: Fixed-point fractional library routines. 52371 (line 1172) 52372* __satfractdausq: Fixed-point fractional library routines. 52373 (line 1167) 52374* __satfractdauta: Fixed-point fractional library routines. 52375 (line 1174) 52376* __satfractdfda: Fixed-point fractional library routines. 52377 (line 1513) 52378* __satfractdfdq: Fixed-point fractional library routines. 52379 (line 1510) 52380* __satfractdfha: Fixed-point fractional library routines. 52381 (line 1511) 52382* __satfractdfhq: Fixed-point fractional library routines. 52383 (line 1508) 52384* __satfractdfqq: Fixed-point fractional library routines. 52385 (line 1507) 52386* __satfractdfsa: Fixed-point fractional library routines. 52387 (line 1512) 52388* __satfractdfsq: Fixed-point fractional library routines. 52389 (line 1509) 52390* __satfractdfta: Fixed-point fractional library routines. 52391 (line 1514) 52392* __satfractdfuda: Fixed-point fractional library routines. 52393 (line 1522) 52394* __satfractdfudq: Fixed-point fractional library routines. 52395 (line 1518) 52396* __satfractdfuha: Fixed-point fractional library routines. 52397 (line 1520) 52398* __satfractdfuhq: Fixed-point fractional library routines. 52399 (line 1516) 52400* __satfractdfuqq: Fixed-point fractional library routines. 52401 (line 1515) 52402* __satfractdfusa: Fixed-point fractional library routines. 52403 (line 1521) 52404* __satfractdfusq: Fixed-point fractional library routines. 52405 (line 1517) 52406* __satfractdfuta: Fixed-point fractional library routines. 52407 (line 1523) 52408* __satfractdida: Fixed-point fractional library routines. 52409 (line 1463) 52410* __satfractdidq: Fixed-point fractional library routines. 52411 (line 1460) 52412* __satfractdiha: Fixed-point fractional library routines. 52413 (line 1461) 52414* __satfractdihq: Fixed-point fractional library routines. 52415 (line 1458) 52416* __satfractdiqq: Fixed-point fractional library routines. 52417 (line 1457) 52418* __satfractdisa: Fixed-point fractional library routines. 52419 (line 1462) 52420* __satfractdisq: Fixed-point fractional library routines. 52421 (line 1459) 52422* __satfractdita: Fixed-point fractional library routines. 52423 (line 1464) 52424* __satfractdiuda: Fixed-point fractional library routines. 52425 (line 1471) 52426* __satfractdiudq: Fixed-point fractional library routines. 52427 (line 1468) 52428* __satfractdiuha: Fixed-point fractional library routines. 52429 (line 1469) 52430* __satfractdiuhq: Fixed-point fractional library routines. 52431 (line 1466) 52432* __satfractdiuqq: Fixed-point fractional library routines. 52433 (line 1465) 52434* __satfractdiusa: Fixed-point fractional library routines. 52435 (line 1470) 52436* __satfractdiusq: Fixed-point fractional library routines. 52437 (line 1467) 52438* __satfractdiuta: Fixed-point fractional library routines. 52439 (line 1472) 52440* __satfractdqda: Fixed-point fractional library routines. 52441 (line 1105) 52442* __satfractdqha: Fixed-point fractional library routines. 52443 (line 1103) 52444* __satfractdqhq2: Fixed-point fractional library routines. 52445 (line 1101) 52446* __satfractdqqq2: Fixed-point fractional library routines. 52447 (line 1100) 52448* __satfractdqsa: Fixed-point fractional library routines. 52449 (line 1104) 52450* __satfractdqsq2: Fixed-point fractional library routines. 52451 (line 1102) 52452* __satfractdqta: Fixed-point fractional library routines. 52453 (line 1106) 52454* __satfractdquda: Fixed-point fractional library routines. 52455 (line 1117) 52456* __satfractdqudq: Fixed-point fractional library routines. 52457 (line 1112) 52458* __satfractdquha: Fixed-point fractional library routines. 52459 (line 1114) 52460* __satfractdquhq: Fixed-point fractional library routines. 52461 (line 1109) 52462* __satfractdquqq: Fixed-point fractional library routines. 52463 (line 1107) 52464* __satfractdqusa: Fixed-point fractional library routines. 52465 (line 1116) 52466* __satfractdqusq: Fixed-point fractional library routines. 52467 (line 1110) 52468* __satfractdquta: Fixed-point fractional library routines. 52469 (line 1119) 52470* __satfracthada2: Fixed-point fractional library routines. 52471 (line 1126) 52472* __satfracthadq: Fixed-point fractional library routines. 52473 (line 1124) 52474* __satfracthahq: Fixed-point fractional library routines. 52475 (line 1122) 52476* __satfracthaqq: Fixed-point fractional library routines. 52477 (line 1121) 52478* __satfracthasa2: Fixed-point fractional library routines. 52479 (line 1125) 52480* __satfracthasq: Fixed-point fractional library routines. 52481 (line 1123) 52482* __satfracthata2: Fixed-point fractional library routines. 52483 (line 1127) 52484* __satfracthauda: Fixed-point fractional library routines. 52485 (line 1138) 52486* __satfracthaudq: Fixed-point fractional library routines. 52487 (line 1133) 52488* __satfracthauha: Fixed-point fractional library routines. 52489 (line 1135) 52490* __satfracthauhq: Fixed-point fractional library routines. 52491 (line 1130) 52492* __satfracthauqq: Fixed-point fractional library routines. 52493 (line 1128) 52494* __satfracthausa: Fixed-point fractional library routines. 52495 (line 1137) 52496* __satfracthausq: Fixed-point fractional library routines. 52497 (line 1131) 52498* __satfracthauta: Fixed-point fractional library routines. 52499 (line 1140) 52500* __satfracthida: Fixed-point fractional library routines. 52501 (line 1431) 52502* __satfracthidq: Fixed-point fractional library routines. 52503 (line 1428) 52504* __satfracthiha: Fixed-point fractional library routines. 52505 (line 1429) 52506* __satfracthihq: Fixed-point fractional library routines. 52507 (line 1426) 52508* __satfracthiqq: Fixed-point fractional library routines. 52509 (line 1425) 52510* __satfracthisa: Fixed-point fractional library routines. 52511 (line 1430) 52512* __satfracthisq: Fixed-point fractional library routines. 52513 (line 1427) 52514* __satfracthita: Fixed-point fractional library routines. 52515 (line 1432) 52516* __satfracthiuda: Fixed-point fractional library routines. 52517 (line 1439) 52518* __satfracthiudq: Fixed-point fractional library routines. 52519 (line 1436) 52520* __satfracthiuha: Fixed-point fractional library routines. 52521 (line 1437) 52522* __satfracthiuhq: Fixed-point fractional library routines. 52523 (line 1434) 52524* __satfracthiuqq: Fixed-point fractional library routines. 52525 (line 1433) 52526* __satfracthiusa: Fixed-point fractional library routines. 52527 (line 1438) 52528* __satfracthiusq: Fixed-point fractional library routines. 52529 (line 1435) 52530* __satfracthiuta: Fixed-point fractional library routines. 52531 (line 1440) 52532* __satfracthqda: Fixed-point fractional library routines. 52533 (line 1071) 52534* __satfracthqdq2: Fixed-point fractional library routines. 52535 (line 1068) 52536* __satfracthqha: Fixed-point fractional library routines. 52537 (line 1069) 52538* __satfracthqqq2: Fixed-point fractional library routines. 52539 (line 1066) 52540* __satfracthqsa: Fixed-point fractional library routines. 52541 (line 1070) 52542* __satfracthqsq2: Fixed-point fractional library routines. 52543 (line 1067) 52544* __satfracthqta: Fixed-point fractional library routines. 52545 (line 1072) 52546* __satfracthquda: Fixed-point fractional library routines. 52547 (line 1079) 52548* __satfracthqudq: Fixed-point fractional library routines. 52549 (line 1076) 52550* __satfracthquha: Fixed-point fractional library routines. 52551 (line 1077) 52552* __satfracthquhq: Fixed-point fractional library routines. 52553 (line 1074) 52554* __satfracthquqq: Fixed-point fractional library routines. 52555 (line 1073) 52556* __satfracthqusa: Fixed-point fractional library routines. 52557 (line 1078) 52558* __satfracthqusq: Fixed-point fractional library routines. 52559 (line 1075) 52560* __satfracthquta: Fixed-point fractional library routines. 52561 (line 1080) 52562* __satfractqida: Fixed-point fractional library routines. 52563 (line 1409) 52564* __satfractqidq: Fixed-point fractional library routines. 52565 (line 1406) 52566* __satfractqiha: Fixed-point fractional library routines. 52567 (line 1407) 52568* __satfractqihq: Fixed-point fractional library routines. 52569 (line 1404) 52570* __satfractqiqq: Fixed-point fractional library routines. 52571 (line 1403) 52572* __satfractqisa: Fixed-point fractional library routines. 52573 (line 1408) 52574* __satfractqisq: Fixed-point fractional library routines. 52575 (line 1405) 52576* __satfractqita: Fixed-point fractional library routines. 52577 (line 1410) 52578* __satfractqiuda: Fixed-point fractional library routines. 52579 (line 1421) 52580* __satfractqiudq: Fixed-point fractional library routines. 52581 (line 1416) 52582* __satfractqiuha: Fixed-point fractional library routines. 52583 (line 1418) 52584* __satfractqiuhq: Fixed-point fractional library routines. 52585 (line 1413) 52586* __satfractqiuqq: Fixed-point fractional library routines. 52587 (line 1411) 52588* __satfractqiusa: Fixed-point fractional library routines. 52589 (line 1420) 52590* __satfractqiusq: Fixed-point fractional library routines. 52591 (line 1414) 52592* __satfractqiuta: Fixed-point fractional library routines. 52593 (line 1423) 52594* __satfractqqda: Fixed-point fractional library routines. 52595 (line 1050) 52596* __satfractqqdq2: Fixed-point fractional library routines. 52597 (line 1047) 52598* __satfractqqha: Fixed-point fractional library routines. 52599 (line 1048) 52600* __satfractqqhq2: Fixed-point fractional library routines. 52601 (line 1045) 52602* __satfractqqsa: Fixed-point fractional library routines. 52603 (line 1049) 52604* __satfractqqsq2: Fixed-point fractional library routines. 52605 (line 1046) 52606* __satfractqqta: Fixed-point fractional library routines. 52607 (line 1051) 52608* __satfractqquda: Fixed-point fractional library routines. 52609 (line 1062) 52610* __satfractqqudq: Fixed-point fractional library routines. 52611 (line 1057) 52612* __satfractqquha: Fixed-point fractional library routines. 52613 (line 1059) 52614* __satfractqquhq: Fixed-point fractional library routines. 52615 (line 1054) 52616* __satfractqquqq: Fixed-point fractional library routines. 52617 (line 1052) 52618* __satfractqqusa: Fixed-point fractional library routines. 52619 (line 1061) 52620* __satfractqqusq: Fixed-point fractional library routines. 52621 (line 1055) 52622* __satfractqquta: Fixed-point fractional library routines. 52623 (line 1064) 52624* __satfractsada2: Fixed-point fractional library routines. 52625 (line 1147) 52626* __satfractsadq: Fixed-point fractional library routines. 52627 (line 1145) 52628* __satfractsaha2: Fixed-point fractional library routines. 52629 (line 1146) 52630* __satfractsahq: Fixed-point fractional library routines. 52631 (line 1143) 52632* __satfractsaqq: Fixed-point fractional library routines. 52633 (line 1142) 52634* __satfractsasq: Fixed-point fractional library routines. 52635 (line 1144) 52636* __satfractsata2: Fixed-point fractional library routines. 52637 (line 1148) 52638* __satfractsauda: Fixed-point fractional library routines. 52639 (line 1155) 52640* __satfractsaudq: Fixed-point fractional library routines. 52641 (line 1152) 52642* __satfractsauha: Fixed-point fractional library routines. 52643 (line 1153) 52644* __satfractsauhq: Fixed-point fractional library routines. 52645 (line 1150) 52646* __satfractsauqq: Fixed-point fractional library routines. 52647 (line 1149) 52648* __satfractsausa: Fixed-point fractional library routines. 52649 (line 1154) 52650* __satfractsausq: Fixed-point fractional library routines. 52651 (line 1151) 52652* __satfractsauta: Fixed-point fractional library routines. 52653 (line 1156) 52654* __satfractsfda: Fixed-point fractional library routines. 52655 (line 1497) 52656* __satfractsfdq: Fixed-point fractional library routines. 52657 (line 1494) 52658* __satfractsfha: Fixed-point fractional library routines. 52659 (line 1495) 52660* __satfractsfhq: Fixed-point fractional library routines. 52661 (line 1492) 52662* __satfractsfqq: Fixed-point fractional library routines. 52663 (line 1491) 52664* __satfractsfsa: Fixed-point fractional library routines. 52665 (line 1496) 52666* __satfractsfsq: Fixed-point fractional library routines. 52667 (line 1493) 52668* __satfractsfta: Fixed-point fractional library routines. 52669 (line 1498) 52670* __satfractsfuda: Fixed-point fractional library routines. 52671 (line 1505) 52672* __satfractsfudq: Fixed-point fractional library routines. 52673 (line 1502) 52674* __satfractsfuha: Fixed-point fractional library routines. 52675 (line 1503) 52676* __satfractsfuhq: Fixed-point fractional library routines. 52677 (line 1500) 52678* __satfractsfuqq: Fixed-point fractional library routines. 52679 (line 1499) 52680* __satfractsfusa: Fixed-point fractional library routines. 52681 (line 1504) 52682* __satfractsfusq: Fixed-point fractional library routines. 52683 (line 1501) 52684* __satfractsfuta: Fixed-point fractional library routines. 52685 (line 1506) 52686* __satfractsida: Fixed-point fractional library routines. 52687 (line 1447) 52688* __satfractsidq: Fixed-point fractional library routines. 52689 (line 1444) 52690* __satfractsiha: Fixed-point fractional library routines. 52691 (line 1445) 52692* __satfractsihq: Fixed-point fractional library routines. 52693 (line 1442) 52694* __satfractsiqq: Fixed-point fractional library routines. 52695 (line 1441) 52696* __satfractsisa: Fixed-point fractional library routines. 52697 (line 1446) 52698* __satfractsisq: Fixed-point fractional library routines. 52699 (line 1443) 52700* __satfractsita: Fixed-point fractional library routines. 52701 (line 1448) 52702* __satfractsiuda: Fixed-point fractional library routines. 52703 (line 1455) 52704* __satfractsiudq: Fixed-point fractional library routines. 52705 (line 1452) 52706* __satfractsiuha: Fixed-point fractional library routines. 52707 (line 1453) 52708* __satfractsiuhq: Fixed-point fractional library routines. 52709 (line 1450) 52710* __satfractsiuqq: Fixed-point fractional library routines. 52711 (line 1449) 52712* __satfractsiusa: Fixed-point fractional library routines. 52713 (line 1454) 52714* __satfractsiusq: Fixed-point fractional library routines. 52715 (line 1451) 52716* __satfractsiuta: Fixed-point fractional library routines. 52717 (line 1456) 52718* __satfractsqda: Fixed-point fractional library routines. 52719 (line 1086) 52720* __satfractsqdq2: Fixed-point fractional library routines. 52721 (line 1083) 52722* __satfractsqha: Fixed-point fractional library routines. 52723 (line 1084) 52724* __satfractsqhq2: Fixed-point fractional library routines. 52725 (line 1082) 52726* __satfractsqqq2: Fixed-point fractional library routines. 52727 (line 1081) 52728* __satfractsqsa: Fixed-point fractional library routines. 52729 (line 1085) 52730* __satfractsqta: Fixed-point fractional library routines. 52731 (line 1087) 52732* __satfractsquda: Fixed-point fractional library routines. 52733 (line 1097) 52734* __satfractsqudq: Fixed-point fractional library routines. 52735 (line 1092) 52736* __satfractsquha: Fixed-point fractional library routines. 52737 (line 1094) 52738* __satfractsquhq: Fixed-point fractional library routines. 52739 (line 1090) 52740* __satfractsquqq: Fixed-point fractional library routines. 52741 (line 1088) 52742* __satfractsqusa: Fixed-point fractional library routines. 52743 (line 1096) 52744* __satfractsqusq: Fixed-point fractional library routines. 52745 (line 1091) 52746* __satfractsquta: Fixed-point fractional library routines. 52747 (line 1098) 52748* __satfracttada2: Fixed-point fractional library routines. 52749 (line 1182) 52750* __satfracttadq: Fixed-point fractional library routines. 52751 (line 1179) 52752* __satfracttaha2: Fixed-point fractional library routines. 52753 (line 1180) 52754* __satfracttahq: Fixed-point fractional library routines. 52755 (line 1177) 52756* __satfracttaqq: Fixed-point fractional library routines. 52757 (line 1176) 52758* __satfracttasa2: Fixed-point fractional library routines. 52759 (line 1181) 52760* __satfracttasq: Fixed-point fractional library routines. 52761 (line 1178) 52762* __satfracttauda: Fixed-point fractional library routines. 52763 (line 1193) 52764* __satfracttaudq: Fixed-point fractional library routines. 52765 (line 1188) 52766* __satfracttauha: Fixed-point fractional library routines. 52767 (line 1190) 52768* __satfracttauhq: Fixed-point fractional library routines. 52769 (line 1185) 52770* __satfracttauqq: Fixed-point fractional library routines. 52771 (line 1183) 52772* __satfracttausa: Fixed-point fractional library routines. 52773 (line 1192) 52774* __satfracttausq: Fixed-point fractional library routines. 52775 (line 1186) 52776* __satfracttauta: Fixed-point fractional library routines. 52777 (line 1195) 52778* __satfracttida: Fixed-point fractional library routines. 52779 (line 1479) 52780* __satfracttidq: Fixed-point fractional library routines. 52781 (line 1476) 52782* __satfracttiha: Fixed-point fractional library routines. 52783 (line 1477) 52784* __satfracttihq: Fixed-point fractional library routines. 52785 (line 1474) 52786* __satfracttiqq: Fixed-point fractional library routines. 52787 (line 1473) 52788* __satfracttisa: Fixed-point fractional library routines. 52789 (line 1478) 52790* __satfracttisq: Fixed-point fractional library routines. 52791 (line 1475) 52792* __satfracttita: Fixed-point fractional library routines. 52793 (line 1480) 52794* __satfracttiuda: Fixed-point fractional library routines. 52795 (line 1488) 52796* __satfracttiudq: Fixed-point fractional library routines. 52797 (line 1484) 52798* __satfracttiuha: Fixed-point fractional library routines. 52799 (line 1486) 52800* __satfracttiuhq: Fixed-point fractional library routines. 52801 (line 1482) 52802* __satfracttiuqq: Fixed-point fractional library routines. 52803 (line 1481) 52804* __satfracttiusa: Fixed-point fractional library routines. 52805 (line 1487) 52806* __satfracttiusq: Fixed-point fractional library routines. 52807 (line 1483) 52808* __satfracttiuta: Fixed-point fractional library routines. 52809 (line 1489) 52810* __satfractudada: Fixed-point fractional library routines. 52811 (line 1358) 52812* __satfractudadq: Fixed-point fractional library routines. 52813 (line 1353) 52814* __satfractudaha: Fixed-point fractional library routines. 52815 (line 1355) 52816* __satfractudahq: Fixed-point fractional library routines. 52817 (line 1351) 52818* __satfractudaqq: Fixed-point fractional library routines. 52819 (line 1349) 52820* __satfractudasa: Fixed-point fractional library routines. 52821 (line 1357) 52822* __satfractudasq: Fixed-point fractional library routines. 52823 (line 1352) 52824* __satfractudata: Fixed-point fractional library routines. 52825 (line 1359) 52826* __satfractudaudq: Fixed-point fractional library routines. 52827 (line 1367) 52828* __satfractudauha2: Fixed-point fractional library routines. 52829 (line 1369) 52830* __satfractudauhq: Fixed-point fractional library routines. 52831 (line 1363) 52832* __satfractudauqq: Fixed-point fractional library routines. 52833 (line 1361) 52834* __satfractudausa2: Fixed-point fractional library routines. 52835 (line 1371) 52836* __satfractudausq: Fixed-point fractional library routines. 52837 (line 1365) 52838* __satfractudauta2: Fixed-point fractional library routines. 52839 (line 1373) 52840* __satfractudqda: Fixed-point fractional library routines. 52841 (line 1282) 52842* __satfractudqdq: Fixed-point fractional library routines. 52843 (line 1277) 52844* __satfractudqha: Fixed-point fractional library routines. 52845 (line 1279) 52846* __satfractudqhq: Fixed-point fractional library routines. 52847 (line 1274) 52848* __satfractudqqq: Fixed-point fractional library routines. 52849 (line 1272) 52850* __satfractudqsa: Fixed-point fractional library routines. 52851 (line 1281) 52852* __satfractudqsq: Fixed-point fractional library routines. 52853 (line 1275) 52854* __satfractudqta: Fixed-point fractional library routines. 52855 (line 1284) 52856* __satfractudquda: Fixed-point fractional library routines. 52857 (line 1296) 52858* __satfractudquha: Fixed-point fractional library routines. 52859 (line 1292) 52860* __satfractudquhq2: Fixed-point fractional library routines. 52861 (line 1288) 52862* __satfractudquqq2: Fixed-point fractional library routines. 52863 (line 1286) 52864* __satfractudqusa: Fixed-point fractional library routines. 52865 (line 1294) 52866* __satfractudqusq2: Fixed-point fractional library routines. 52867 (line 1290) 52868* __satfractudquta: Fixed-point fractional library routines. 52869 (line 1298) 52870* __satfractuhada: Fixed-point fractional library routines. 52871 (line 1310) 52872* __satfractuhadq: Fixed-point fractional library routines. 52873 (line 1305) 52874* __satfractuhaha: Fixed-point fractional library routines. 52875 (line 1307) 52876* __satfractuhahq: Fixed-point fractional library routines. 52877 (line 1302) 52878* __satfractuhaqq: Fixed-point fractional library routines. 52879 (line 1300) 52880* __satfractuhasa: Fixed-point fractional library routines. 52881 (line 1309) 52882* __satfractuhasq: Fixed-point fractional library routines. 52883 (line 1303) 52884* __satfractuhata: Fixed-point fractional library routines. 52885 (line 1312) 52886* __satfractuhauda2: Fixed-point fractional library routines. 52887 (line 1324) 52888* __satfractuhaudq: Fixed-point fractional library routines. 52889 (line 1320) 52890* __satfractuhauhq: Fixed-point fractional library routines. 52891 (line 1316) 52892* __satfractuhauqq: Fixed-point fractional library routines. 52893 (line 1314) 52894* __satfractuhausa2: Fixed-point fractional library routines. 52895 (line 1322) 52896* __satfractuhausq: Fixed-point fractional library routines. 52897 (line 1318) 52898* __satfractuhauta2: Fixed-point fractional library routines. 52899 (line 1326) 52900* __satfractuhqda: Fixed-point fractional library routines. 52901 (line 1231) 52902* __satfractuhqdq: Fixed-point fractional library routines. 52903 (line 1228) 52904* __satfractuhqha: Fixed-point fractional library routines. 52905 (line 1229) 52906* __satfractuhqhq: Fixed-point fractional library routines. 52907 (line 1226) 52908* __satfractuhqqq: Fixed-point fractional library routines. 52909 (line 1225) 52910* __satfractuhqsa: Fixed-point fractional library routines. 52911 (line 1230) 52912* __satfractuhqsq: Fixed-point fractional library routines. 52913 (line 1227) 52914* __satfractuhqta: Fixed-point fractional library routines. 52915 (line 1232) 52916* __satfractuhquda: Fixed-point fractional library routines. 52917 (line 1242) 52918* __satfractuhqudq2: Fixed-point fractional library routines. 52919 (line 1237) 52920* __satfractuhquha: Fixed-point fractional library routines. 52921 (line 1239) 52922* __satfractuhquqq2: Fixed-point fractional library routines. 52923 (line 1233) 52924* __satfractuhqusa: Fixed-point fractional library routines. 52925 (line 1241) 52926* __satfractuhqusq2: Fixed-point fractional library routines. 52927 (line 1235) 52928* __satfractuhquta: Fixed-point fractional library routines. 52929 (line 1244) 52930* __satfractunsdida: Fixed-point fractional library routines. 52931 (line 1841) 52932* __satfractunsdidq: Fixed-point fractional library routines. 52933 (line 1837) 52934* __satfractunsdiha: Fixed-point fractional library routines. 52935 (line 1839) 52936* __satfractunsdihq: Fixed-point fractional library routines. 52937 (line 1835) 52938* __satfractunsdiqq: Fixed-point fractional library routines. 52939 (line 1834) 52940* __satfractunsdisa: Fixed-point fractional library routines. 52941 (line 1840) 52942* __satfractunsdisq: Fixed-point fractional library routines. 52943 (line 1836) 52944* __satfractunsdita: Fixed-point fractional library routines. 52945 (line 1842) 52946* __satfractunsdiuda: Fixed-point fractional library routines. 52947 (line 1856) 52948* __satfractunsdiudq: Fixed-point fractional library routines. 52949 (line 1850) 52950* __satfractunsdiuha: Fixed-point fractional library routines. 52951 (line 1852) 52952* __satfractunsdiuhq: Fixed-point fractional library routines. 52953 (line 1846) 52954* __satfractunsdiuqq: Fixed-point fractional library routines. 52955 (line 1844) 52956* __satfractunsdiusa: Fixed-point fractional library routines. 52957 (line 1854) 52958* __satfractunsdiusq: Fixed-point fractional library routines. 52959 (line 1848) 52960* __satfractunsdiuta: Fixed-point fractional library routines. 52961 (line 1858) 52962* __satfractunshida: Fixed-point fractional library routines. 52963 (line 1793) 52964* __satfractunshidq: Fixed-point fractional library routines. 52965 (line 1789) 52966* __satfractunshiha: Fixed-point fractional library routines. 52967 (line 1791) 52968* __satfractunshihq: Fixed-point fractional library routines. 52969 (line 1787) 52970* __satfractunshiqq: Fixed-point fractional library routines. 52971 (line 1786) 52972* __satfractunshisa: Fixed-point fractional library routines. 52973 (line 1792) 52974* __satfractunshisq: Fixed-point fractional library routines. 52975 (line 1788) 52976* __satfractunshita: Fixed-point fractional library routines. 52977 (line 1794) 52978* __satfractunshiuda: Fixed-point fractional library routines. 52979 (line 1808) 52980* __satfractunshiudq: Fixed-point fractional library routines. 52981 (line 1802) 52982* __satfractunshiuha: Fixed-point fractional library routines. 52983 (line 1804) 52984* __satfractunshiuhq: Fixed-point fractional library routines. 52985 (line 1798) 52986* __satfractunshiuqq: Fixed-point fractional library routines. 52987 (line 1796) 52988* __satfractunshiusa: Fixed-point fractional library routines. 52989 (line 1806) 52990* __satfractunshiusq: Fixed-point fractional library routines. 52991 (line 1800) 52992* __satfractunshiuta: Fixed-point fractional library routines. 52993 (line 1810) 52994* __satfractunsqida: Fixed-point fractional library routines. 52995 (line 1767) 52996* __satfractunsqidq: Fixed-point fractional library routines. 52997 (line 1763) 52998* __satfractunsqiha: Fixed-point fractional library routines. 52999 (line 1765) 53000* __satfractunsqihq: Fixed-point fractional library routines. 53001 (line 1761) 53002* __satfractunsqiqq: Fixed-point fractional library routines. 53003 (line 1760) 53004* __satfractunsqisa: Fixed-point fractional library routines. 53005 (line 1766) 53006* __satfractunsqisq: Fixed-point fractional library routines. 53007 (line 1762) 53008* __satfractunsqita: Fixed-point fractional library routines. 53009 (line 1768) 53010* __satfractunsqiuda: Fixed-point fractional library routines. 53011 (line 1782) 53012* __satfractunsqiudq: Fixed-point fractional library routines. 53013 (line 1776) 53014* __satfractunsqiuha: Fixed-point fractional library routines. 53015 (line 1778) 53016* __satfractunsqiuhq: Fixed-point fractional library routines. 53017 (line 1772) 53018* __satfractunsqiuqq: Fixed-point fractional library routines. 53019 (line 1770) 53020* __satfractunsqiusa: Fixed-point fractional library routines. 53021 (line 1780) 53022* __satfractunsqiusq: Fixed-point fractional library routines. 53023 (line 1774) 53024* __satfractunsqiuta: Fixed-point fractional library routines. 53025 (line 1784) 53026* __satfractunssida: Fixed-point fractional library routines. 53027 (line 1818) 53028* __satfractunssidq: Fixed-point fractional library routines. 53029 (line 1815) 53030* __satfractunssiha: Fixed-point fractional library routines. 53031 (line 1816) 53032* __satfractunssihq: Fixed-point fractional library routines. 53033 (line 1813) 53034* __satfractunssiqq: Fixed-point fractional library routines. 53035 (line 1812) 53036* __satfractunssisa: Fixed-point fractional library routines. 53037 (line 1817) 53038* __satfractunssisq: Fixed-point fractional library routines. 53039 (line 1814) 53040* __satfractunssita: Fixed-point fractional library routines. 53041 (line 1819) 53042* __satfractunssiuda: Fixed-point fractional library routines. 53043 (line 1830) 53044* __satfractunssiudq: Fixed-point fractional library routines. 53045 (line 1825) 53046* __satfractunssiuha: Fixed-point fractional library routines. 53047 (line 1827) 53048* __satfractunssiuhq: Fixed-point fractional library routines. 53049 (line 1822) 53050* __satfractunssiuqq: Fixed-point fractional library routines. 53051 (line 1820) 53052* __satfractunssiusa: Fixed-point fractional library routines. 53053 (line 1829) 53054* __satfractunssiusq: Fixed-point fractional library routines. 53055 (line 1823) 53056* __satfractunssiuta: Fixed-point fractional library routines. 53057 (line 1832) 53058* __satfractunstida: Fixed-point fractional library routines. 53059 (line 1870) 53060* __satfractunstidq: Fixed-point fractional library routines. 53061 (line 1865) 53062* __satfractunstiha: Fixed-point fractional library routines. 53063 (line 1867) 53064* __satfractunstihq: Fixed-point fractional library routines. 53065 (line 1862) 53066* __satfractunstiqq: Fixed-point fractional library routines. 53067 (line 1860) 53068* __satfractunstisa: Fixed-point fractional library routines. 53069 (line 1869) 53070* __satfractunstisq: Fixed-point fractional library routines. 53071 (line 1863) 53072* __satfractunstita: Fixed-point fractional library routines. 53073 (line 1872) 53074* __satfractunstiuda: Fixed-point fractional library routines. 53075 (line 1886) 53076* __satfractunstiudq: Fixed-point fractional library routines. 53077 (line 1880) 53078* __satfractunstiuha: Fixed-point fractional library routines. 53079 (line 1882) 53080* __satfractunstiuhq: Fixed-point fractional library routines. 53081 (line 1876) 53082* __satfractunstiuqq: Fixed-point fractional library routines. 53083 (line 1874) 53084* __satfractunstiusa: Fixed-point fractional library routines. 53085 (line 1884) 53086* __satfractunstiusq: Fixed-point fractional library routines. 53087 (line 1878) 53088* __satfractunstiuta: Fixed-point fractional library routines. 53089 (line 1888) 53090* __satfractuqqda: Fixed-point fractional library routines. 53091 (line 1207) 53092* __satfractuqqdq: Fixed-point fractional library routines. 53093 (line 1202) 53094* __satfractuqqha: Fixed-point fractional library routines. 53095 (line 1204) 53096* __satfractuqqhq: Fixed-point fractional library routines. 53097 (line 1199) 53098* __satfractuqqqq: Fixed-point fractional library routines. 53099 (line 1197) 53100* __satfractuqqsa: Fixed-point fractional library routines. 53101 (line 1206) 53102* __satfractuqqsq: Fixed-point fractional library routines. 53103 (line 1200) 53104* __satfractuqqta: Fixed-point fractional library routines. 53105 (line 1209) 53106* __satfractuqquda: Fixed-point fractional library routines. 53107 (line 1221) 53108* __satfractuqqudq2: Fixed-point fractional library routines. 53109 (line 1215) 53110* __satfractuqquha: Fixed-point fractional library routines. 53111 (line 1217) 53112* __satfractuqquhq2: Fixed-point fractional library routines. 53113 (line 1211) 53114* __satfractuqqusa: Fixed-point fractional library routines. 53115 (line 1219) 53116* __satfractuqqusq2: Fixed-point fractional library routines. 53117 (line 1213) 53118* __satfractuqquta: Fixed-point fractional library routines. 53119 (line 1223) 53120* __satfractusada: Fixed-point fractional library routines. 53121 (line 1334) 53122* __satfractusadq: Fixed-point fractional library routines. 53123 (line 1331) 53124* __satfractusaha: Fixed-point fractional library routines. 53125 (line 1332) 53126* __satfractusahq: Fixed-point fractional library routines. 53127 (line 1329) 53128* __satfractusaqq: Fixed-point fractional library routines. 53129 (line 1328) 53130* __satfractusasa: Fixed-point fractional library routines. 53131 (line 1333) 53132* __satfractusasq: Fixed-point fractional library routines. 53133 (line 1330) 53134* __satfractusata: Fixed-point fractional library routines. 53135 (line 1335) 53136* __satfractusauda2: Fixed-point fractional library routines. 53137 (line 1345) 53138* __satfractusaudq: Fixed-point fractional library routines. 53139 (line 1341) 53140* __satfractusauha2: Fixed-point fractional library routines. 53141 (line 1343) 53142* __satfractusauhq: Fixed-point fractional library routines. 53143 (line 1338) 53144* __satfractusauqq: Fixed-point fractional library routines. 53145 (line 1336) 53146* __satfractusausq: Fixed-point fractional library routines. 53147 (line 1339) 53148* __satfractusauta2: Fixed-point fractional library routines. 53149 (line 1347) 53150* __satfractusqda: Fixed-point fractional library routines. 53151 (line 1255) 53152* __satfractusqdq: Fixed-point fractional library routines. 53153 (line 1250) 53154* __satfractusqha: Fixed-point fractional library routines. 53155 (line 1252) 53156* __satfractusqhq: Fixed-point fractional library routines. 53157 (line 1248) 53158* __satfractusqqq: Fixed-point fractional library routines. 53159 (line 1246) 53160* __satfractusqsa: Fixed-point fractional library routines. 53161 (line 1254) 53162* __satfractusqsq: Fixed-point fractional library routines. 53163 (line 1249) 53164* __satfractusqta: Fixed-point fractional library routines. 53165 (line 1256) 53166* __satfractusquda: Fixed-point fractional library routines. 53167 (line 1268) 53168* __satfractusqudq2: Fixed-point fractional library routines. 53169 (line 1262) 53170* __satfractusquha: Fixed-point fractional library routines. 53171 (line 1264) 53172* __satfractusquhq2: Fixed-point fractional library routines. 53173 (line 1260) 53174* __satfractusquqq2: Fixed-point fractional library routines. 53175 (line 1258) 53176* __satfractusqusa: Fixed-point fractional library routines. 53177 (line 1266) 53178* __satfractusquta: Fixed-point fractional library routines. 53179 (line 1270) 53180* __satfractutada: Fixed-point fractional library routines. 53181 (line 1385) 53182* __satfractutadq: Fixed-point fractional library routines. 53183 (line 1380) 53184* __satfractutaha: Fixed-point fractional library routines. 53185 (line 1382) 53186* __satfractutahq: Fixed-point fractional library routines. 53187 (line 1377) 53188* __satfractutaqq: Fixed-point fractional library routines. 53189 (line 1375) 53190* __satfractutasa: Fixed-point fractional library routines. 53191 (line 1384) 53192* __satfractutasq: Fixed-point fractional library routines. 53193 (line 1378) 53194* __satfractutata: Fixed-point fractional library routines. 53195 (line 1387) 53196* __satfractutauda2: Fixed-point fractional library routines. 53197 (line 1401) 53198* __satfractutaudq: Fixed-point fractional library routines. 53199 (line 1395) 53200* __satfractutauha2: Fixed-point fractional library routines. 53201 (line 1397) 53202* __satfractutauhq: Fixed-point fractional library routines. 53203 (line 1391) 53204* __satfractutauqq: Fixed-point fractional library routines. 53205 (line 1389) 53206* __satfractutausa2: Fixed-point fractional library routines. 53207 (line 1399) 53208* __satfractutausq: Fixed-point fractional library routines. 53209 (line 1393) 53210* __splitstack_find: Miscellaneous routines. 53211 (line 15) 53212* __ssaddda3: Fixed-point fractional library routines. 53213 (line 74) 53214* __ssadddq3: Fixed-point fractional library routines. 53215 (line 69) 53216* __ssaddha3: Fixed-point fractional library routines. 53217 (line 71) 53218* __ssaddhq3: Fixed-point fractional library routines. 53219 (line 67) 53220* __ssaddqq3: Fixed-point fractional library routines. 53221 (line 65) 53222* __ssaddsa3: Fixed-point fractional library routines. 53223 (line 73) 53224* __ssaddsq3: Fixed-point fractional library routines. 53225 (line 68) 53226* __ssaddta3: Fixed-point fractional library routines. 53227 (line 75) 53228* __ssashlda3: Fixed-point fractional library routines. 53229 (line 409) 53230* __ssashldq3: Fixed-point fractional library routines. 53231 (line 405) 53232* __ssashlha3: Fixed-point fractional library routines. 53233 (line 407) 53234* __ssashlhq3: Fixed-point fractional library routines. 53235 (line 403) 53236* __ssashlsa3: Fixed-point fractional library routines. 53237 (line 408) 53238* __ssashlsq3: Fixed-point fractional library routines. 53239 (line 404) 53240* __ssashlta3: Fixed-point fractional library routines. 53241 (line 410) 53242* __ssdivda3: Fixed-point fractional library routines. 53243 (line 268) 53244* __ssdivdq3: Fixed-point fractional library routines. 53245 (line 263) 53246* __ssdivha3: Fixed-point fractional library routines. 53247 (line 265) 53248* __ssdivhq3: Fixed-point fractional library routines. 53249 (line 261) 53250* __ssdivqq3: Fixed-point fractional library routines. 53251 (line 259) 53252* __ssdivsa3: Fixed-point fractional library routines. 53253 (line 267) 53254* __ssdivsq3: Fixed-point fractional library routines. 53255 (line 262) 53256* __ssdivta3: Fixed-point fractional library routines. 53257 (line 269) 53258* __ssmulda3: Fixed-point fractional library routines. 53259 (line 200) 53260* __ssmuldq3: Fixed-point fractional library routines. 53261 (line 195) 53262* __ssmulha3: Fixed-point fractional library routines. 53263 (line 197) 53264* __ssmulhq3: Fixed-point fractional library routines. 53265 (line 193) 53266* __ssmulqq3: Fixed-point fractional library routines. 53267 (line 191) 53268* __ssmulsa3: Fixed-point fractional library routines. 53269 (line 199) 53270* __ssmulsq3: Fixed-point fractional library routines. 53271 (line 194) 53272* __ssmulta3: Fixed-point fractional library routines. 53273 (line 201) 53274* __ssnegda2: Fixed-point fractional library routines. 53275 (line 323) 53276* __ssnegdq2: Fixed-point fractional library routines. 53277 (line 320) 53278* __ssnegha2: Fixed-point fractional library routines. 53279 (line 321) 53280* __ssneghq2: Fixed-point fractional library routines. 53281 (line 318) 53282* __ssnegqq2: Fixed-point fractional library routines. 53283 (line 317) 53284* __ssnegsa2: Fixed-point fractional library routines. 53285 (line 322) 53286* __ssnegsq2: Fixed-point fractional library routines. 53287 (line 319) 53288* __ssnegta2: Fixed-point fractional library routines. 53289 (line 324) 53290* __sssubda3: Fixed-point fractional library routines. 53291 (line 136) 53292* __sssubdq3: Fixed-point fractional library routines. 53293 (line 131) 53294* __sssubha3: Fixed-point fractional library routines. 53295 (line 133) 53296* __sssubhq3: Fixed-point fractional library routines. 53297 (line 129) 53298* __sssubqq3: Fixed-point fractional library routines. 53299 (line 127) 53300* __sssubsa3: Fixed-point fractional library routines. 53301 (line 135) 53302* __sssubsq3: Fixed-point fractional library routines. 53303 (line 130) 53304* __sssubta3: Fixed-point fractional library routines. 53305 (line 137) 53306* __subda3: Fixed-point fractional library routines. 53307 (line 114) 53308* __subdf3: Soft float library routines. 53309 (line 30) 53310* __subdq3: Fixed-point fractional library routines. 53311 (line 101) 53312* __subha3: Fixed-point fractional library routines. 53313 (line 111) 53314* __subhq3: Fixed-point fractional library routines. 53315 (line 99) 53316* __subqq3: Fixed-point fractional library routines. 53317 (line 97) 53318* __subsa3: Fixed-point fractional library routines. 53319 (line 113) 53320* __subsf3: Soft float library routines. 53321 (line 29) 53322* __subsq3: Fixed-point fractional library routines. 53323 (line 100) 53324* __subta3: Fixed-point fractional library routines. 53325 (line 115) 53326* __subtf3: Soft float library routines. 53327 (line 31) 53328* __subuda3: Fixed-point fractional library routines. 53329 (line 121) 53330* __subudq3: Fixed-point fractional library routines. 53331 (line 109) 53332* __subuha3: Fixed-point fractional library routines. 53333 (line 117) 53334* __subuhq3: Fixed-point fractional library routines. 53335 (line 105) 53336* __subuqq3: Fixed-point fractional library routines. 53337 (line 103) 53338* __subusa3: Fixed-point fractional library routines. 53339 (line 119) 53340* __subusq3: Fixed-point fractional library routines. 53341 (line 107) 53342* __subuta3: Fixed-point fractional library routines. 53343 (line 123) 53344* __subvdi3: Integer library routines. 53345 (line 122) 53346* __subvsi3: Integer library routines. 53347 (line 121) 53348* __subxf3: Soft float library routines. 53349 (line 33) 53350* __truncdfsf2: Soft float library routines. 53351 (line 75) 53352* __trunctfdf2: Soft float library routines. 53353 (line 72) 53354* __trunctfsf2: Soft float library routines. 53355 (line 74) 53356* __truncxfdf2: Soft float library routines. 53357 (line 71) 53358* __truncxfsf2: Soft float library routines. 53359 (line 73) 53360* __ucmpdi2: Integer library routines. 53361 (line 92) 53362* __ucmpti2: Integer library routines. 53363 (line 93) 53364* __udivdi3: Integer library routines. 53365 (line 52) 53366* __udivmoddi4: Integer library routines. 53367 (line 59) 53368* __udivmodti4: Integer library routines. 53369 (line 61) 53370* __udivsi3: Integer library routines. 53371 (line 50) 53372* __udivti3: Integer library routines. 53373 (line 54) 53374* __udivuda3: Fixed-point fractional library routines. 53375 (line 252) 53376* __udivudq3: Fixed-point fractional library routines. 53377 (line 246) 53378* __udivuha3: Fixed-point fractional library routines. 53379 (line 248) 53380* __udivuhq3: Fixed-point fractional library routines. 53381 (line 242) 53382* __udivuqq3: Fixed-point fractional library routines. 53383 (line 240) 53384* __udivusa3: Fixed-point fractional library routines. 53385 (line 250) 53386* __udivusq3: Fixed-point fractional library routines. 53387 (line 244) 53388* __udivuta3: Fixed-point fractional library routines. 53389 (line 254) 53390* __umoddi3: Integer library routines. 53391 (line 69) 53392* __umodsi3: Integer library routines. 53393 (line 67) 53394* __umodti3: Integer library routines. 53395 (line 71) 53396* __unorddf2: Soft float library routines. 53397 (line 172) 53398* __unordsf2: Soft float library routines. 53399 (line 171) 53400* __unordtf2: Soft float library routines. 53401 (line 173) 53402* __usadduda3: Fixed-point fractional library routines. 53403 (line 91) 53404* __usaddudq3: Fixed-point fractional library routines. 53405 (line 85) 53406* __usadduha3: Fixed-point fractional library routines. 53407 (line 87) 53408* __usadduhq3: Fixed-point fractional library routines. 53409 (line 81) 53410* __usadduqq3: Fixed-point fractional library routines. 53411 (line 79) 53412* __usaddusa3: Fixed-point fractional library routines. 53413 (line 89) 53414* __usaddusq3: Fixed-point fractional library routines. 53415 (line 83) 53416* __usadduta3: Fixed-point fractional library routines. 53417 (line 93) 53418* __usashluda3: Fixed-point fractional library routines. 53419 (line 427) 53420* __usashludq3: Fixed-point fractional library routines. 53421 (line 421) 53422* __usashluha3: Fixed-point fractional library routines. 53423 (line 423) 53424* __usashluhq3: Fixed-point fractional library routines. 53425 (line 417) 53426* __usashluqq3: Fixed-point fractional library routines. 53427 (line 415) 53428* __usashlusa3: Fixed-point fractional library routines. 53429 (line 425) 53430* __usashlusq3: Fixed-point fractional library routines. 53431 (line 419) 53432* __usashluta3: Fixed-point fractional library routines. 53433 (line 429) 53434* __usdivuda3: Fixed-point fractional library routines. 53435 (line 286) 53436* __usdivudq3: Fixed-point fractional library routines. 53437 (line 280) 53438* __usdivuha3: Fixed-point fractional library routines. 53439 (line 282) 53440* __usdivuhq3: Fixed-point fractional library routines. 53441 (line 276) 53442* __usdivuqq3: Fixed-point fractional library routines. 53443 (line 274) 53444* __usdivusa3: Fixed-point fractional library routines. 53445 (line 284) 53446* __usdivusq3: Fixed-point fractional library routines. 53447 (line 278) 53448* __usdivuta3: Fixed-point fractional library routines. 53449 (line 288) 53450* __usmuluda3: Fixed-point fractional library routines. 53451 (line 218) 53452* __usmuludq3: Fixed-point fractional library routines. 53453 (line 212) 53454* __usmuluha3: Fixed-point fractional library routines. 53455 (line 214) 53456* __usmuluhq3: Fixed-point fractional library routines. 53457 (line 208) 53458* __usmuluqq3: Fixed-point fractional library routines. 53459 (line 206) 53460* __usmulusa3: Fixed-point fractional library routines. 53461 (line 216) 53462* __usmulusq3: Fixed-point fractional library routines. 53463 (line 210) 53464* __usmuluta3: Fixed-point fractional library routines. 53465 (line 220) 53466* __usneguda2: Fixed-point fractional library routines. 53467 (line 337) 53468* __usnegudq2: Fixed-point fractional library routines. 53469 (line 332) 53470* __usneguha2: Fixed-point fractional library routines. 53471 (line 334) 53472* __usneguhq2: Fixed-point fractional library routines. 53473 (line 329) 53474* __usneguqq2: Fixed-point fractional library routines. 53475 (line 327) 53476* __usnegusa2: Fixed-point fractional library routines. 53477 (line 336) 53478* __usnegusq2: Fixed-point fractional library routines. 53479 (line 330) 53480* __usneguta2: Fixed-point fractional library routines. 53481 (line 339) 53482* __ussubuda3: Fixed-point fractional library routines. 53483 (line 154) 53484* __ussubudq3: Fixed-point fractional library routines. 53485 (line 148) 53486* __ussubuha3: Fixed-point fractional library routines. 53487 (line 150) 53488* __ussubuhq3: Fixed-point fractional library routines. 53489 (line 144) 53490* __ussubuqq3: Fixed-point fractional library routines. 53491 (line 142) 53492* __ussubusa3: Fixed-point fractional library routines. 53493 (line 152) 53494* __ussubusq3: Fixed-point fractional library routines. 53495 (line 146) 53496* __ussubuta3: Fixed-point fractional library routines. 53497 (line 156) 53498* abort: Portability. (line 20) 53499* abs: Arithmetic. (line 200) 53500* abs and attributes: Expressions. (line 83) 53501* absence_set: Processor pipeline description. 53502 (line 223) 53503* absM2 instruction pattern: Standard Names. (line 917) 53504* absolute value: Arithmetic. (line 200) 53505* ABSU_EXPR: Unary and Binary Expressions. 53506 (line 6) 53507* ABS_EXPR: Unary and Binary Expressions. 53508 (line 6) 53509* access to operands: Accessors. (line 6) 53510* access to special operands: Special Accessors. (line 6) 53511* accessors: Accessors. (line 6) 53512* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 48) 53513* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 140) 53514* ACCUM_TYPE_SIZE: Type Layout. (line 87) 53515* acosM2 instruction pattern: Standard Names. (line 1004) 53516* ADA_LONG_TYPE_SIZE: Type Layout. (line 25) 53517* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code. 53518 (line 6) 53519* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 14) 53520* addM3 instruction pattern: Standard Names. (line 460) 53521* addMODEcc instruction pattern: Standard Names. (line 1788) 53522* addptrM3 instruction pattern: Standard Names. (line 493) 53523* address constraints: Simple Constraints. (line 162) 53524* addressing modes: Addressing Modes. (line 6) 53525* address_operand: Machine-Independent Predicates. 53526 (line 62) 53527* address_operand <1>: Simple Constraints. (line 166) 53528* addr_diff_vec: Side Effects. (line 314) 53529* addr_diff_vec, length of: Insn Lengths. (line 26) 53530* ADDR_EXPR: Storage References. (line 6) 53531* addr_vec: Side Effects. (line 309) 53532* addr_vec, length of: Insn Lengths. (line 26) 53533* addvM4 instruction pattern: Standard Names. (line 476) 53534* ADJUST_FIELD_ALIGN: Storage Layout. (line 212) 53535* ADJUST_INSN_LENGTH: Insn Lengths. (line 41) 53536* ADJUST_REG_ALLOC_ORDER: Allocation Order. (line 22) 53537* aggregates as return values: Aggregate Return. (line 6) 53538* alias: Alias analysis. (line 6) 53539* allocate_stack instruction pattern: Standard Names. (line 2155) 53540* ALL_REGS: Register Classes. (line 17) 53541* alternate entry points: Insns. (line 146) 53542* analyzer: Static Analyzer. (line 6) 53543* analyzer, debugging: Debugging the Analyzer. 53544 (line 6) 53545* analyzer, internals: Analyzer Internals. (line 6) 53546* anchored addresses: Anchored Addresses. (line 6) 53547* and: Arithmetic. (line 158) 53548* and and attributes: Expressions. (line 50) 53549* and, canonicalization of: Insn Canonicalizations. 53550 (line 67) 53551* andM3 instruction pattern: Standard Names. (line 466) 53552* ANNOTATE_EXPR: Unary and Binary Expressions. 53553 (line 6) 53554* annotations: Annotations. (line 6) 53555* APPLY_RESULT_SIZE: Scalar Return. (line 112) 53556* ARGS_GROW_DOWNWARD: Frame Layout. (line 30) 53557* argument passing: Interface. (line 36) 53558* arguments in registers: Register Arguments. (line 6) 53559* arguments on stack: Stack Arguments. (line 6) 53560* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 207) 53561* ARG_POINTER_REGNUM: Frame Registers. (line 40) 53562* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 53563* arg_pointer_rtx: Frame Registers. (line 104) 53564* arithmetic library: Soft float library routines. 53565 (line 6) 53566* arithmetic shift: Arithmetic. (line 173) 53567* arithmetic shift with signed saturation: Arithmetic. (line 173) 53568* arithmetic shift with unsigned saturation: Arithmetic. (line 173) 53569* arithmetic, in RTL: Arithmetic. (line 6) 53570* ARITHMETIC_TYPE_P: Types for C++. (line 59) 53571* array: Types. (line 6) 53572* ARRAY_RANGE_REF: Storage References. (line 6) 53573* ARRAY_REF: Storage References. (line 6) 53574* ARRAY_TYPE: Types. (line 6) 53575* ashift: Arithmetic. (line 173) 53576* ashift and attributes: Expressions. (line 83) 53577* ashiftrt: Arithmetic. (line 190) 53578* ashiftrt and attributes: Expressions. (line 83) 53579* ashlM3 instruction pattern: Standard Names. (line 866) 53580* ashrM3 instruction pattern: Standard Names. (line 878) 53581* asinM2 instruction pattern: Standard Names. (line 998) 53582* ASM_APP_OFF: File Framework. (line 76) 53583* ASM_APP_ON: File Framework. (line 69) 53584* ASM_COMMENT_START: File Framework. (line 64) 53585* ASM_DECLARE_COLD_FUNCTION_NAME: Label Output. (line 136) 53586* ASM_DECLARE_COLD_FUNCTION_SIZE: Label Output. (line 151) 53587* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 108) 53588* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 123) 53589* ASM_DECLARE_OBJECT_NAME: Label Output. (line 164) 53590* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 192) 53591* ASM_FINAL_SPEC: Driver. (line 81) 53592* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 200) 53593* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 426) 53594* asm_fprintf: Instruction Output. (line 150) 53595* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 160) 53596* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 410) 53597* asm_input: Side Effects. (line 296) 53598* asm_input and /v: Flags. (line 65) 53599* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 80) 53600* asm_noperands: Insns. (line 327) 53601* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 59) 53602* asm_operands and /v: Flags. (line 65) 53603* asm_operands, RTL sharing: Sharing. (line 48) 53604* asm_operands, usage: Assembler. (line 6) 53605* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 8) 53606* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 25) 53607* ASM_OUTPUT_ALIGN: Alignment Output. (line 66) 53608* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 45) 53609* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 29) 53610* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 36) 53611* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 89) 53612* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 82) 53613* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 71) 53614* ASM_OUTPUT_ASCII: Data Output. (line 60) 53615* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 50) 53616* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 37) 53617* ASM_OUTPUT_COMMON: Uninitialized Data. (line 9) 53618* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 398) 53619* ASM_OUTPUT_DEF: Label Output. (line 447) 53620* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 454) 53621* ASM_OUTPUT_DWARF_DATAREL: DWARF. (line 110) 53622* ASM_OUTPUT_DWARF_DELTA: DWARF. (line 89) 53623* ASM_OUTPUT_DWARF_OFFSET: DWARF. (line 98) 53624* ASM_OUTPUT_DWARF_PCREL: DWARF. (line 105) 53625* ASM_OUTPUT_DWARF_TABLE_REF: DWARF. (line 115) 53626* ASM_OUTPUT_DWARF_VMS_DELTA: DWARF. (line 93) 53627* ASM_OUTPUT_EXTERNAL: Label Output. (line 327) 53628* ASM_OUTPUT_FDESC: Data Output. (line 69) 53629* ASM_OUTPUT_FUNCTION_LABEL: Label Output. (line 16) 53630* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 27) 53631* ASM_OUTPUT_LABEL: Label Output. (line 8) 53632* ASM_OUTPUT_LABELREF: Label Output. (line 349) 53633* ASM_OUTPUT_LABEL_REF: Label Output. (line 371) 53634* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 69) 53635* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 75) 53636* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 51) 53637* ASM_OUTPUT_OPCODE: Instruction Output. (line 35) 53638* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 118) 53639* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 82) 53640* ASM_OUTPUT_REG_POP: Instruction Output. (line 206) 53641* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 201) 53642* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 45) 53643* ASM_OUTPUT_SKIP: Alignment Output. (line 53) 53644* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 83) 53645* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 93) 53646* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 364) 53647* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 98) 53648* ASM_OUTPUT_WEAKREF: Label Output. (line 259) 53649* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 473) 53650* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 66) 53651* ASM_SPEC: Driver. (line 73) 53652* ASM_STABD_OP: DBX Options. (line 34) 53653* ASM_STABN_OP: DBX Options. (line 41) 53654* ASM_STABS_OP: DBX Options. (line 28) 53655* ASM_WEAKEN_DECL: Label Output. (line 251) 53656* ASM_WEAKEN_LABEL: Label Output. (line 238) 53657* assembler format: File Framework. (line 6) 53658* assembler instructions in RTL: Assembler. (line 6) 53659* ASSEMBLER_DIALECT: Instruction Output. (line 172) 53660* assemble_name: Label Output. (line 8) 53661* assemble_name_raw: Label Output. (line 27) 53662* assigning attribute values to insns: Tagging Insns. (line 6) 53663* ASSUME_EXTENDED_UNWIND_CONTEXT: Frame Registers. (line 163) 53664* asterisk in template: Output Statement. (line 29) 53665* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 88) 53666* atan2M3 instruction pattern: Standard Names. (line 1099) 53667* atanM2 instruction pattern: Standard Names. (line 1010) 53668* atomic: GTY Options. (line 197) 53669* atomic_addMODE instruction pattern: Standard Names. (line 2579) 53670* atomic_add_fetchMODE instruction pattern: Standard Names. (line 2608) 53671* atomic_andMODE instruction pattern: Standard Names. (line 2579) 53672* atomic_and_fetchMODE instruction pattern: Standard Names. (line 2608) 53673* atomic_bit_test_and_complementMODE instruction pattern: Standard Names. 53674 (line 2636) 53675* atomic_bit_test_and_resetMODE instruction pattern: Standard Names. 53676 (line 2636) 53677* atomic_bit_test_and_setMODE instruction pattern: Standard Names. 53678 (line 2636) 53679* atomic_compare_and_swapMODE instruction pattern: Standard Names. 53680 (line 2515) 53681* atomic_exchangeMODE instruction pattern: Standard Names. (line 2567) 53682* atomic_fetch_addMODE instruction pattern: Standard Names. (line 2593) 53683* atomic_fetch_andMODE instruction pattern: Standard Names. (line 2593) 53684* atomic_fetch_nandMODE instruction pattern: Standard Names. (line 2593) 53685* atomic_fetch_orMODE instruction pattern: Standard Names. (line 2593) 53686* atomic_fetch_subMODE instruction pattern: Standard Names. (line 2593) 53687* atomic_fetch_xorMODE instruction pattern: Standard Names. (line 2593) 53688* atomic_loadMODE instruction pattern: Standard Names. (line 2546) 53689* atomic_nandMODE instruction pattern: Standard Names. (line 2579) 53690* atomic_nand_fetchMODE instruction pattern: Standard Names. (line 2608) 53691* atomic_orMODE instruction pattern: Standard Names. (line 2579) 53692* atomic_or_fetchMODE instruction pattern: Standard Names. (line 2608) 53693* atomic_storeMODE instruction pattern: Standard Names. (line 2556) 53694* atomic_subMODE instruction pattern: Standard Names. (line 2579) 53695* atomic_sub_fetchMODE instruction pattern: Standard Names. (line 2608) 53696* atomic_test_and_set instruction pattern: Standard Names. (line 2625) 53697* atomic_xorMODE instruction pattern: Standard Names. (line 2579) 53698* atomic_xor_fetchMODE instruction pattern: Standard Names. (line 2608) 53699* attr: Expressions. (line 163) 53700* attr <1>: Tagging Insns. (line 54) 53701* attribute expressions: Expressions. (line 6) 53702* attribute specifications: Attr Example. (line 6) 53703* attribute specifications example: Attr Example. (line 6) 53704* attributes: Attributes. (line 6) 53705* attributes, defining: Defining Attributes. 53706 (line 6) 53707* attributes, target-specific: Target Attributes. (line 6) 53708* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 194) 53709* attr_flag: Expressions. (line 138) 53710* autoincrement addressing, availability: Portability. (line 20) 53711* autoincrement/decrement addressing: Simple Constraints. (line 30) 53712* automata_option: Processor pipeline description. 53713 (line 304) 53714* automaton based pipeline description: Processor pipeline description. 53715 (line 6) 53716* automaton based pipeline description <1>: Processor pipeline description. 53717 (line 49) 53718* automaton based scheduler: Processor pipeline description. 53719 (line 6) 53720* avgM3_ceil instruction pattern: Standard Names. (line 898) 53721* avgM3_floor instruction pattern: Standard Names. (line 886) 53722* AVOID_CCMODE_COPIES: Values in Registers. 53723 (line 148) 53724* backslash: Output Template. (line 46) 53725* barrier: Insns. (line 176) 53726* barrier and /f: Flags. (line 135) 53727* barrier and /v: Flags. (line 33) 53728* BASE_REG_CLASS: Register Classes. (line 111) 53729* basic block: Basic Blocks. (line 6) 53730* basic blocks, RTL SSA: RTL SSA Basic Blocks. 53731 (line 6) 53732* Basic Statements: Basic Statements. (line 6) 53733* basic-block.h: Control Flow. (line 6) 53734* basic_block: RTL SSA Basic Blocks. 53735 (line 6) 53736* basic_block <1>: Basic Blocks. (line 6) 53737* BASIC_BLOCK: Basic Blocks. (line 14) 53738* BB_HEAD, BB_END: Maintaining the CFG. 53739 (line 76) 53740* bb_seq: GIMPLE sequences. (line 72) 53741* BIGGEST_ALIGNMENT: Storage Layout. (line 179) 53742* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 205) 53743* BImode: Machine Modes. (line 22) 53744* BIND_EXPR: Unary and Binary Expressions. 53745 (line 6) 53746* BINFO_TYPE: Classes. (line 6) 53747* bit-fields: Bit-Fields. (line 6) 53748* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 432) 53749* BITS_BIG_ENDIAN: Storage Layout. (line 11) 53750* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 53751* BITS_PER_UNIT: Machine Modes. (line 445) 53752* BITS_PER_WORD: Storage Layout. (line 50) 53753* bitwise complement: Arithmetic. (line 154) 53754* bitwise exclusive-or: Arithmetic. (line 168) 53755* bitwise inclusive-or: Arithmetic. (line 163) 53756* bitwise logical-and: Arithmetic. (line 158) 53757* BIT_AND_EXPR: Unary and Binary Expressions. 53758 (line 6) 53759* BIT_IOR_EXPR: Unary and Binary Expressions. 53760 (line 6) 53761* BIT_NOT_EXPR: Unary and Binary Expressions. 53762 (line 6) 53763* BIT_XOR_EXPR: Unary and Binary Expressions. 53764 (line 6) 53765* BLKmode: Machine Modes. (line 185) 53766* BLKmode, and function return values: Calls. (line 23) 53767* blockage instruction pattern: Standard Names. (line 2355) 53768* Blocks: Blocks. (line 6) 53769* BLOCK_FOR_INSN, gimple_bb: Maintaining the CFG. 53770 (line 28) 53771* BLOCK_REG_PADDING: Register Arguments. (line 238) 53772* BND32mode: Machine Modes. (line 210) 53773* BND64mode: Machine Modes. (line 210) 53774* bool: Misc. (line 963) 53775* BOOLEAN_TYPE: Types. (line 6) 53776* BOOL_TYPE_SIZE: Type Layout. (line 43) 53777* branch prediction: Profile information. 53778 (line 24) 53779* BRANCH_COST: Costs. (line 104) 53780* break_out_memory_refs: Addressing Modes. (line 134) 53781* BREAK_STMT: Statements for C and C++. 53782 (line 6) 53783* BSS_SECTION_ASM_OP: Sections. (line 67) 53784* bswap: Arithmetic. (line 246) 53785* bswapM2 instruction pattern: Standard Names. (line 906) 53786* btruncM2 instruction pattern: Standard Names. (line 1116) 53787* build0: Macros and Functions. 53788 (line 16) 53789* build1: Macros and Functions. 53790 (line 17) 53791* build2: Macros and Functions. 53792 (line 18) 53793* build3: Macros and Functions. 53794 (line 19) 53795* build4: Macros and Functions. 53796 (line 20) 53797* build5: Macros and Functions. 53798 (line 21) 53799* build6: Macros and Functions. 53800 (line 22) 53801* builtin_longjmp instruction pattern: Standard Names. (line 2253) 53802* builtin_setjmp_receiver instruction pattern: Standard Names. 53803 (line 2243) 53804* builtin_setjmp_setup instruction pattern: Standard Names. (line 2232) 53805* BYTES_BIG_ENDIAN: Storage Layout. (line 23) 53806* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 229) 53807* byte_mode: Machine Modes. (line 463) 53808* C statements for assembler output: Output Statement. (line 6) 53809* cache: GTY Options. (line 127) 53810* cadd270M3 instruction pattern: Standard Names. (line 1217) 53811* cadd90M3 instruction pattern: Standard Names. (line 1195) 53812* call: Flags. (line 230) 53813* call <1>: Side Effects. (line 92) 53814* call instruction pattern: Standard Names. (line 1908) 53815* call usage: Calls. (line 10) 53816* call, in call_insn: Flags. (line 129) 53817* call, in mem: Flags. (line 70) 53818* call-clobbered register: Register Basics. (line 35) 53819* call-clobbered register <1>: Register Basics. (line 50) 53820* call-clobbered register <2>: Register Basics. (line 58) 53821* call-clobbered register <3>: Register Basics. (line 76) 53822* call-saved register: Register Basics. (line 35) 53823* call-saved register <1>: Register Basics. (line 50) 53824* call-saved register <2>: Register Basics. (line 58) 53825* call-saved register <3>: Register Basics. (line 76) 53826* call-used register: Register Basics. (line 35) 53827* call-used register <1>: Register Basics. (line 50) 53828* call-used register <2>: Register Basics. (line 58) 53829* call-used register <3>: Register Basics. (line 76) 53830* calling conventions: Stack and Calling. (line 6) 53831* calling functions in RTL: Calls. (line 6) 53832* CALL_EXPR: Unary and Binary Expressions. 53833 (line 6) 53834* call_insn: Insns. (line 95) 53835* call_insn and /c: Flags. (line 129) 53836* call_insn and /f: Flags. (line 135) 53837* call_insn and /i: Flags. (line 120) 53838* call_insn and /j: Flags. (line 175) 53839* call_insn and /s: Flags. (line 38) 53840* call_insn and /s <1>: Flags. (line 162) 53841* call_insn and /u: Flags. (line 28) 53842* call_insn and /u <1>: Flags. (line 115) 53843* call_insn and /u or /i: Flags. (line 125) 53844* call_insn and /v: Flags. (line 33) 53845* CALL_INSN_FUNCTION_USAGE: Insns. (line 101) 53846* call_pop instruction pattern: Standard Names. (line 1936) 53847* CALL_POPS_ARGS: Stack Arguments. (line 138) 53848* CALL_REALLY_USED_REGISTERS: Register Basics. (line 49) 53849* CALL_USED_REGISTERS: Register Basics. (line 34) 53850* call_used_regs: Register Basics. (line 102) 53851* call_value instruction pattern: Standard Names. (line 1928) 53852* call_value_pop instruction pattern: Standard Names. (line 1936) 53853* canadian: Configure Terms. (line 6) 53854* canonicalization of instructions: Insn Canonicalizations. 53855 (line 6) 53856* canonicalize_funcptr_for_compare instruction pattern: Standard Names. 53857 (line 2087) 53858* can_create_pseudo_p: Standard Names. (line 75) 53859* can_fallthru: Basic Blocks. (line 67) 53860* caret: Multi-Alternative. (line 53) 53861* caret <1>: Guidelines for Diagnostics. 53862 (line 183) 53863* casesi instruction pattern: Standard Names. (line 2029) 53864* CASE_VECTOR_MODE: Misc. (line 26) 53865* CASE_VECTOR_PC_RELATIVE: Misc. (line 39) 53866* CASE_VECTOR_SHORTEN_MODE: Misc. (line 30) 53867* cbranchMODE4 instruction pattern: Standard Names. (line 1897) 53868* cc0: Regs and Memory. (line 334) 53869* cc0 <1>: CC0 Condition Codes. 53870 (line 6) 53871* cc0, RTL sharing: Sharing. (line 30) 53872* cc0_rtx: Regs and Memory. (line 360) 53873* CC1PLUS_SPEC: Driver. (line 63) 53874* CC1_SPEC: Driver. (line 55) 53875* CCmode: Machine Modes. (line 178) 53876* CCmode <1>: MODE_CC Condition Codes. 53877 (line 6) 53878* cc_status: CC0 Condition Codes. 53879 (line 6) 53880* CC_STATUS_MDEP: CC0 Condition Codes. 53881 (line 16) 53882* CC_STATUS_MDEP_INIT: CC0 Condition Codes. 53883 (line 22) 53884* CDImode: Machine Modes. (line 204) 53885* ceilM2 instruction pattern: Standard Names. (line 1135) 53886* CEIL_DIV_EXPR: Unary and Binary Expressions. 53887 (line 6) 53888* CEIL_MOD_EXPR: Unary and Binary Expressions. 53889 (line 6) 53890* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 239) 53891* CFG verification: Maintaining the CFG. 53892 (line 116) 53893* CFG, Control Flow Graph: Control Flow. (line 6) 53894* cfghooks.h: Maintaining the CFG. 53895 (line 6) 53896* cgraph_finalize_function: Parsing pass. (line 51) 53897* chain_circular: GTY Options. (line 160) 53898* chain_next: GTY Options. (line 160) 53899* chain_prev: GTY Options. (line 160) 53900* change_address: Standard Names. (line 47) 53901* CHAR_TYPE_SIZE: Type Layout. (line 38) 53902* check_raw_ptrsM instruction pattern: Standard Names. (line 330) 53903* check_stack instruction pattern: Standard Names. (line 2173) 53904* check_war_ptrsM instruction pattern: Standard Names. (line 349) 53905* CHImode: Machine Modes. (line 204) 53906* class definitions, register: Register Classes. (line 6) 53907* class preference constraints: Class Preferences. (line 6) 53908* class, scope: Classes. (line 6) 53909* classes of RTX codes: RTL Classes. (line 6) 53910* CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 53911* CLASSTYPE_HAS_MUTABLE: Classes. (line 82) 53912* CLASSTYPE_NON_POD_P: Classes. (line 87) 53913* CLASS_MAX_NREGS: Register Classes. (line 531) 53914* CLASS_TYPE_P: Types for C++. (line 63) 53915* Cleanups: Cleanups. (line 6) 53916* CLEANUP_DECL: Statements for C and C++. 53917 (line 6) 53918* CLEANUP_EXPR: Statements for C and C++. 53919 (line 6) 53920* CLEANUP_POINT_EXPR: Unary and Binary Expressions. 53921 (line 6) 53922* CLEANUP_STMT: Statements for C and C++. 53923 (line 6) 53924* clear_cache instruction pattern: Standard Names. (line 2742) 53925* CLEAR_INSN_CACHE: Trampolines. (line 164) 53926* CLEAR_RATIO: Costs. (line 225) 53927* clobber: Side Effects. (line 106) 53928* clrsb: Arithmetic. (line 215) 53929* clrsbM2 instruction pattern: Standard Names. (line 1369) 53930* clz: Arithmetic. (line 222) 53931* clzM2 instruction pattern: Standard Names. (line 1385) 53932* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 340) 53933* cmlaM4 instruction pattern: Standard Names. (line 1239) 53934* cmla_conjM4 instruction pattern: Standard Names. (line 1258) 53935* cmlsM4 instruction pattern: Standard Names. (line 1278) 53936* cmls_conjM4 instruction pattern: Standard Names. (line 1297) 53937* cmpmemM instruction pattern: Standard Names. (line 1588) 53938* cmpstrM instruction pattern: Standard Names. (line 1567) 53939* cmpstrnM instruction pattern: Standard Names. (line 1554) 53940* cmulM4 instruction pattern: Standard Names. (line 1317) 53941* cmul_conjM4 instruction pattern: Standard Names. (line 1336) 53942* code generation RTL sequences: Expander Definitions. 53943 (line 6) 53944* code iterators in .md files: Code Iterators. (line 6) 53945* codes, RTL expression: RTL Objects. (line 47) 53946* code_label: Insns. (line 125) 53947* CODE_LABEL: Basic Blocks. (line 50) 53948* code_label and /i: Flags. (line 48) 53949* code_label and /v: Flags. (line 33) 53950* CODE_LABEL_NUMBER: Insns. (line 125) 53951* COImode: Machine Modes. (line 204) 53952* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 53953* COLLECT_EXPORT_LIST: Misc. (line 869) 53954* COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 53955 (line 43) 53956* COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 53957 (line 32) 53958* command-line options, guidelines for: Guidelines for Options. 53959 (line 6) 53960* commit_edge_insertions: Maintaining the CFG. 53961 (line 104) 53962* compare: Arithmetic. (line 46) 53963* compare, canonicalization of: Insn Canonicalizations. 53964 (line 36) 53965* COMPARE_MAX_PIECES: Costs. (line 220) 53966* comparison_operator: Machine-Independent Predicates. 53967 (line 110) 53968* compiler passes and files: Passes. (line 6) 53969* complement, bitwise: Arithmetic. (line 154) 53970* COMPLEX_CST: Constant expressions. 53971 (line 6) 53972* COMPLEX_EXPR: Unary and Binary Expressions. 53973 (line 6) 53974* complex_mode: Machine Modes. (line 307) 53975* COMPLEX_TYPE: Types. (line 6) 53976* COMPONENT_REF: Storage References. (line 6) 53977* Compound Expressions: Compound Expressions. 53978 (line 6) 53979* Compound Lvalues: Compound Lvalues. (line 6) 53980* COMPOUND_EXPR: Unary and Binary Expressions. 53981 (line 6) 53982* COMPOUND_LITERAL_EXPR: Unary and Binary Expressions. 53983 (line 6) 53984* COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions. 53985 (line 392) 53986* COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions. 53987 (line 392) 53988* computed jump: Edges. (line 127) 53989* computing the length of an insn: Insn Lengths. (line 6) 53990* concat: Regs and Memory. (line 412) 53991* concatn: Regs and Memory. (line 418) 53992* cond: Comparisons. (line 90) 53993* cond and attributes: Expressions. (line 37) 53994* condition code register: Regs and Memory. (line 334) 53995* condition code status: Condition Code. (line 6) 53996* condition codes: Comparisons. (line 20) 53997* conditional execution: Conditional Execution. 53998 (line 6) 53999* Conditional Expressions: Conditional Expressions. 54000 (line 6) 54001* conditions, in patterns: Patterns. (line 55) 54002* cond_addMODE instruction pattern: Standard Names. (line 1795) 54003* cond_andMODE instruction pattern: Standard Names. (line 1795) 54004* cond_divMODE instruction pattern: Standard Names. (line 1795) 54005* cond_exec: Side Effects. (line 254) 54006* COND_EXPR: Unary and Binary Expressions. 54007 (line 6) 54008* cond_fmaMODE instruction pattern: Standard Names. (line 1833) 54009* cond_fmsMODE instruction pattern: Standard Names. (line 1833) 54010* cond_fnmaMODE instruction pattern: Standard Names. (line 1833) 54011* cond_fnmsMODE instruction pattern: Standard Names. (line 1833) 54012* cond_iorMODE instruction pattern: Standard Names. (line 1795) 54013* cond_modMODE instruction pattern: Standard Names. (line 1795) 54014* cond_mulMODE instruction pattern: Standard Names. (line 1795) 54015* cond_smaxMODE instruction pattern: Standard Names. (line 1795) 54016* cond_sminMODE instruction pattern: Standard Names. (line 1795) 54017* cond_subMODE instruction pattern: Standard Names. (line 1795) 54018* cond_udivMODE instruction pattern: Standard Names. (line 1795) 54019* cond_umaxMODE instruction pattern: Standard Names. (line 1795) 54020* cond_uminMODE instruction pattern: Standard Names. (line 1795) 54021* cond_umodMODE instruction pattern: Standard Names. (line 1795) 54022* cond_xorMODE instruction pattern: Standard Names. (line 1795) 54023* configuration file: Filesystem. (line 6) 54024* configuration file <1>: Host Misc. (line 6) 54025* configure terms: Configure Terms. (line 6) 54026* CONJ_EXPR: Unary and Binary Expressions. 54027 (line 6) 54028* const: Constants. (line 226) 54029* const0_rtx: Constants. (line 21) 54030* CONST0_RTX: Constants. (line 244) 54031* const1_rtx: Constants. (line 21) 54032* CONST1_RTX: Constants. (line 244) 54033* const2_rtx: Constants. (line 21) 54034* CONST2_RTX: Constants. (line 244) 54035* constant attributes: Constant Attributes. 54036 (line 6) 54037* constant definitions: Constant Definitions. 54038 (line 6) 54039* constants in constraints: Simple Constraints. (line 68) 54040* CONSTANT_ADDRESS_P: Addressing Modes. (line 28) 54041* CONSTANT_P: Addressing Modes. (line 35) 54042* CONSTANT_POOL_ADDRESS_P: Flags. (line 19) 54043* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 74) 54044* constm1_rtx: Constants. (line 21) 54045* constraint modifier characters: Modifiers. (line 6) 54046* constraint, matching: Simple Constraints. (line 140) 54047* constraints: Constraints. (line 6) 54048* constraints, defining: Define Constraints. (line 6) 54049* constraints, machine specific: Machine Constraints. 54050 (line 6) 54051* constraints, testing: C Constraint Interface. 54052 (line 6) 54053* constraint_num: C Constraint Interface. 54054 (line 30) 54055* constraint_satisfied_p: C Constraint Interface. 54056 (line 42) 54057* CONSTRUCTOR: Unary and Binary Expressions. 54058 (line 6) 54059* constructors, automatic calls: Collect2. (line 15) 54060* constructors, output of: Initialization. (line 6) 54061* CONST_DECL: Declarations. (line 6) 54062* const_double: Constants. (line 37) 54063* const_double, RTL sharing: Sharing. (line 32) 54064* CONST_DOUBLE_LOW: Constants. (line 54) 54065* const_double_operand: Machine-Independent Predicates. 54066 (line 20) 54067* const_double_zero: Constants. (line 67) 54068* const_fixed: Constants. (line 107) 54069* const_int: Constants. (line 8) 54070* const_int and attribute tests: Expressions. (line 47) 54071* const_int and attributes: Expressions. (line 10) 54072* const_int, RTL sharing: Sharing. (line 23) 54073* const_int_operand: Machine-Independent Predicates. 54074 (line 15) 54075* const_poly_int: Constants. (line 114) 54076* const_poly_int, RTL sharing: Sharing. (line 25) 54077* const_string: Constants. (line 198) 54078* const_string and attributes: Expressions. (line 20) 54079* const_true_rtx: Constants. (line 31) 54080* const_vector: Constants. (line 121) 54081* const_vector, RTL sharing: Sharing. (line 35) 54082* CONST_WIDE_INT: Constants. (line 81) 54083* CONST_WIDE_INT_ELT: Constants. (line 103) 54084* CONST_WIDE_INT_NUNITS: Constants. (line 98) 54085* CONST_WIDE_INT_VEC: Constants. (line 94) 54086* container: Containers. (line 6) 54087* CONTINUE_STMT: Statements for C and C++. 54088 (line 6) 54089* contributors: Contributors. (line 6) 54090* controlling register usage: Register Basics. (line 116) 54091* controlling the compilation driver: Driver. (line 6) 54092* conventions, run-time: Interface. (line 6) 54093* conversions: Conversions. (line 6) 54094* CONVERT_EXPR: Unary and Binary Expressions. 54095 (line 6) 54096* copysignM3 instruction pattern: Standard Names. (line 1180) 54097* copy_rtx: Addressing Modes. (line 189) 54098* copy_rtx_if_shared: Sharing. (line 67) 54099* cosM2 instruction pattern: Standard Names. (line 969) 54100* costs of instructions: Costs. (line 6) 54101* CPLUSPLUS_CPP_SPEC: Driver. (line 50) 54102* CPP_SPEC: Driver. (line 43) 54103* CPSImode: Machine Modes. (line 204) 54104* cpymemM instruction pattern: Standard Names. (line 1443) 54105* CP_INTEGRAL_TYPE: Types for C++. (line 55) 54106* cp_namespace_decls: Namespaces. (line 49) 54107* CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33) 54108* CP_TYPE_CONST_P: Types for C++. (line 24) 54109* cp_type_quals: Types for C++. (line 6) 54110* cp_type_quals <1>: Types for C++. (line 16) 54111* CP_TYPE_RESTRICT_P: Types for C++. (line 30) 54112* CP_TYPE_VOLATILE_P: Types for C++. (line 27) 54113* CQImode: Machine Modes. (line 204) 54114* cross compilation and floating point: Floating Point. (line 6) 54115* CROSSING_JUMP_P: Flags. (line 10) 54116* crtl->args.pops_args: Function Entry. (line 111) 54117* crtl->args.pretend_args_size: Function Entry. (line 117) 54118* crtl->outgoing_args_size: Stack Arguments. (line 48) 54119* CRTSTUFF_T_CFLAGS: Target Fragment. (line 15) 54120* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 19) 54121* CRT_CALL_STATIC_FUNCTION: Sections. (line 125) 54122* CSImode: Machine Modes. (line 204) 54123* cstoreMODE4 instruction pattern: Standard Names. (line 1858) 54124* CTImode: Machine Modes. (line 204) 54125* ctrapMM4 instruction pattern: Standard Names. (line 2324) 54126* ctz: Arithmetic. (line 230) 54127* ctzM2 instruction pattern: Standard Names. (line 1400) 54128* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 341) 54129* CUMULATIVE_ARGS: Register Arguments. (line 137) 54130* current_function_is_leaf: Leaf Functions. (line 50) 54131* current_function_uses_only_leaf_regs: Leaf Functions. (line 50) 54132* current_insn_predicate: Conditional Execution. 54133 (line 27) 54134* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 136) 54135* c_register_pragma: Misc. (line 442) 54136* c_register_pragma_with_expansion: Misc. (line 444) 54137* DAmode: Machine Modes. (line 154) 54138* data bypass: Processor pipeline description. 54139 (line 105) 54140* data bypass <1>: Processor pipeline description. 54141 (line 196) 54142* data dependence delays: Processor pipeline description. 54143 (line 6) 54144* Data Dependency Analysis: Dependency analysis. 54145 (line 6) 54146* data structures: Per-Function Data. (line 6) 54147* DATA_ABI_ALIGNMENT: Storage Layout. (line 267) 54148* DATA_ALIGNMENT: Storage Layout. (line 254) 54149* DATA_SECTION_ASM_OP: Sections. (line 52) 54150* DBR_OUTPUT_SEQEND: Instruction Output. (line 133) 54151* dbr_sequence_length: Instruction Output. (line 133) 54152* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 100) 54153* DBX_CONTIN_CHAR: DBX Options. (line 63) 54154* DBX_CONTIN_LENGTH: DBX Options. (line 53) 54155* DBX_DEBUGGING_INFO: DBX Options. (line 8) 54156* DBX_FUNCTION_FIRST: DBX Options. (line 94) 54157* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 106) 54158* DBX_NO_XREFS: DBX Options. (line 47) 54159* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 8) 54160* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 33) 54161* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 54162 (line 41) 54163* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 8) 54164* DBX_REGISTER_NUMBER: All Debuggers. (line 8) 54165* DBX_REGPARM_STABS_CODE: DBX Options. (line 84) 54166* DBX_REGPARM_STABS_LETTER: DBX Options. (line 89) 54167* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 79) 54168* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 70) 54169* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 75) 54170* DBX_USE_BINCL: DBX Options. (line 112) 54171* DCmode: Machine Modes. (line 199) 54172* DDmode: Machine Modes. (line 93) 54173* De Morgan's law: Insn Canonicalizations. 54174 (line 67) 54175* dead_or_set_p: define_peephole. (line 65) 54176* DEBUGGER_ARG_OFFSET: All Debuggers. (line 35) 54177* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 27) 54178* debug_expr: Debug Information. (line 22) 54179* DEBUG_EXPR_DECL: Declarations. (line 6) 54180* debug_implicit_ptr: Debug Information. (line 27) 54181* debug_insn: Insns. (line 247) 54182* debug_marker: Debug Information. (line 37) 54183* debug_parameter_ref: Debug Information. (line 34) 54184* DEBUG_SYMS_TEXT: DBX Options. (line 24) 54185* decimal float library: Decimal float library routines. 54186 (line 6) 54187* declaration: Declarations. (line 6) 54188* declarations, RTL: RTL Declarations. (line 6) 54189* DECLARE_LIBRARY_RENAMES: Library Calls. (line 8) 54190* DECL_ALIGN: Declarations. (line 6) 54191* DECL_ANTICIPATED: Functions for C++. (line 42) 54192* DECL_ARGUMENTS: Function Basics. (line 36) 54193* DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158) 54194* DECL_ARTIFICIAL: Working with declarations. 54195 (line 24) 54196* DECL_ARTIFICIAL <1>: Function Basics. (line 6) 54197* DECL_ARTIFICIAL <2>: Function Properties. 54198 (line 47) 54199* DECL_ASSEMBLER_NAME: Function Basics. (line 6) 54200* DECL_ASSEMBLER_NAME <1>: Function Basics. (line 19) 54201* DECL_ATTRIBUTES: Attributes. (line 21) 54202* DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88) 54203* DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84) 54204* DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98) 54205* DECL_CONSTRUCTOR_P: Functions for C++. (line 77) 54206* DECL_CONST_MEMFUNC_P: Functions for C++. (line 71) 54207* DECL_CONTEXT: Namespaces. (line 31) 54208* DECL_CONV_FN_P: Functions for C++. (line 105) 54209* DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92) 54210* DECL_DESTRUCTOR_P: Functions for C++. (line 95) 54211* DECL_EXTERNAL: Declarations. (line 6) 54212* DECL_EXTERNAL <1>: Function Properties. 54213 (line 25) 54214* DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46) 54215* DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61) 54216* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6) 54217* DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties. 54218 (line 61) 54219* DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6) 54220* DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Properties. 54221 (line 55) 54222* DECL_GLOBAL_CTOR_P: Functions for C++. (line 108) 54223* DECL_GLOBAL_DTOR_P: Functions for C++. (line 112) 54224* DECL_INITIAL: Declarations. (line 6) 54225* DECL_INITIAL <1>: Function Basics. (line 51) 54226* DECL_LINKONCE_P: Functions for C++. (line 50) 54227* DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38) 54228* DECL_MAIN_P: Functions for C++. (line 34) 54229* DECL_NAME: Working with declarations. 54230 (line 7) 54231* DECL_NAME <1>: Function Basics. (line 6) 54232* DECL_NAME <2>: Function Basics. (line 9) 54233* DECL_NAME <3>: Namespaces. (line 20) 54234* DECL_NAMESPACE_ALIAS: Namespaces. (line 35) 54235* DECL_NAMESPACE_STD_P: Namespaces. (line 45) 54236* DECL_NONCONVERTING_P: Functions for C++. (line 80) 54237* DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68) 54238* DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138) 54239* DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102) 54240* DECL_PURE_P: Function Properties. 54241 (line 40) 54242* DECL_RESULT: Function Basics. (line 41) 54243* DECL_SAVED_TREE: Function Basics. (line 44) 54244* DECL_SIZE: Declarations. (line 6) 54245* DECL_STATIC_FUNCTION_P: Functions for C++. (line 65) 54246* DECL_STMT: Statements for C and C++. 54247 (line 6) 54248* DECL_STMT_DECL: Statements for C and C++. 54249 (line 6) 54250* DECL_THUNK_P: Functions for C++. (line 116) 54251* DECL_VIRTUAL_P: Function Properties. 54252 (line 44) 54253* DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74) 54254* default: GTY Options. (line 90) 54255* default_file_start: File Framework. (line 8) 54256* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 17) 54257* DEFAULT_INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 199) 54258* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34) 54259* DEFAULT_SIGNED_CHAR: Type Layout. (line 117) 54260* define_address_constraint: Define Constraints. (line 137) 54261* define_asm_attributes: Tagging Insns. (line 73) 54262* define_attr: Defining Attributes. 54263 (line 6) 54264* define_automaton: Processor pipeline description. 54265 (line 53) 54266* define_bypass: Processor pipeline description. 54267 (line 196) 54268* define_code_attr: Code Iterators. (line 6) 54269* define_code_iterator: Code Iterators. (line 6) 54270* define_cond_exec: Conditional Execution. 54271 (line 13) 54272* define_constants: Constant Definitions. 54273 (line 6) 54274* define_constraint: Define Constraints. (line 45) 54275* define_cpu_unit: Processor pipeline description. 54276 (line 68) 54277* define_c_enum: Constant Definitions. 54278 (line 49) 54279* define_delay: Delay Slots. (line 25) 54280* define_enum: Constant Definitions. 54281 (line 118) 54282* define_enum_attr: Defining Attributes. 54283 (line 83) 54284* define_enum_attr <1>: Constant Definitions. 54285 (line 136) 54286* define_expand: Expander Definitions. 54287 (line 11) 54288* define_insn: Patterns. (line 6) 54289* define_insn example: Example. (line 6) 54290* define_insn_and_rewrite: Insn Splitting. (line 236) 54291* define_insn_and_split: Insn Splitting. (line 190) 54292* define_insn_reservation: Processor pipeline description. 54293 (line 105) 54294* define_int_attr: Int Iterators. (line 6) 54295* define_int_iterator: Int Iterators. (line 6) 54296* define_memory_constraint: Define Constraints. (line 80) 54297* define_mode_attr: Substitutions. (line 6) 54298* define_mode_iterator: Defining Mode Iterators. 54299 (line 6) 54300* define_peephole: define_peephole. (line 6) 54301* define_peephole2: define_peephole2. (line 6) 54302* define_predicate: Defining Predicates. 54303 (line 6) 54304* define_query_cpu_unit: Processor pipeline description. 54305 (line 90) 54306* define_register_constraint: Define Constraints. (line 26) 54307* define_relaxed_memory_constraint: Define Constraints. (line 113) 54308* define_reservation: Processor pipeline description. 54309 (line 185) 54310* define_special_memory_constraint: Define Constraints. (line 99) 54311* define_special_predicate: Defining Predicates. 54312 (line 6) 54313* define_split: Insn Splitting. (line 32) 54314* define_subst: Define Subst. (line 6) 54315* define_subst <1>: Define Subst Example. 54316 (line 6) 54317* define_subst <2>: Define Subst Pattern Matching. 54318 (line 6) 54319* define_subst <3>: Define Subst Output Template. 54320 (line 6) 54321* define_subst <4>: Define Subst. (line 14) 54322* define_subst <5>: Subst Iterators. (line 6) 54323* define_subst_attr: Subst Iterators. (line 6) 54324* define_subst_attr <1>: Subst Iterators. (line 26) 54325* defining attributes and their values: Defining Attributes. 54326 (line 6) 54327* defining constraints: Define Constraints. (line 6) 54328* defining jump instruction patterns: Jump Patterns. (line 6) 54329* defining looping instruction patterns: Looping Patterns. (line 6) 54330* defining peephole optimizers: Peephole Definitions. 54331 (line 6) 54332* defining predicates: Defining Predicates. 54333 (line 6) 54334* defining RTL sequences for code generation: Expander Definitions. 54335 (line 6) 54336* degenerate phi node, RTL SSA: RTL SSA Access Lists. 54337 (line 25) 54338* delay slots, defining: Delay Slots. (line 6) 54339* deletable: GTY Options. (line 134) 54340* DELETE_IF_ORDINARY: Filesystem. (line 79) 54341* Dependent Patterns: Dependent Patterns. (line 6) 54342* desc: GTY Options. (line 90) 54343* descriptors for nested functions: Trampolines. (line 6) 54344* destructors, output of: Initialization. (line 6) 54345* deterministic finite state automaton: Processor pipeline description. 54346 (line 6) 54347* deterministic finite state automaton <1>: Processor pipeline description. 54348 (line 304) 54349* DFmode: Machine Modes. (line 76) 54350* diagnostics guidelines, fix-it hints: Guidelines for Diagnostics. 54351 (line 344) 54352* diagnostics, actionable: Guidelines for Diagnostics. 54353 (line 15) 54354* diagnostics, false positive: Guidelines for Diagnostics. 54355 (line 39) 54356* diagnostics, guidelines for: Guidelines for Diagnostics. 54357 (line 5) 54358* diagnostics, locations: Guidelines for Diagnostics. 54359 (line 183) 54360* diagnostics, true positive: Guidelines for Diagnostics. 54361 (line 39) 54362* digits in constraint: Simple Constraints. (line 128) 54363* DImode: Machine Modes. (line 45) 54364* directory options .md: Including Patterns. (line 47) 54365* DIR_SEPARATOR: Filesystem. (line 18) 54366* DIR_SEPARATOR_2: Filesystem. (line 19) 54367* disabling certain registers: Register Basics. (line 116) 54368* dispatch table: Dispatch Tables. (line 8) 54369* div: Arithmetic. (line 116) 54370* div and attributes: Expressions. (line 83) 54371* division: Arithmetic. (line 116) 54372* division <1>: Arithmetic. (line 130) 54373* division <2>: Arithmetic. (line 136) 54374* divM3 instruction pattern: Standard Names. (line 466) 54375* divmodM4 instruction pattern: Standard Names. (line 846) 54376* dollar sign: Multi-Alternative. (line 57) 54377* DOLLARS_IN_IDENTIFIERS: Misc. (line 487) 54378* doloop_begin instruction pattern: Standard Names. (line 2078) 54379* doloop_end instruction pattern: Standard Names. (line 2066) 54380* DONE: Expander Definitions. 54381 (line 77) 54382* DONE <1>: Insn Splitting. (line 61) 54383* DONE <2>: define_peephole2. (line 76) 54384* DONT_USE_BUILTIN_SETJMP: Exception Region Output. 54385 (line 78) 54386* DOUBLE_TYPE_SIZE: Type Layout. (line 52) 54387* DO_BODY: Statements for C and C++. 54388 (line 6) 54389* DO_COND: Statements for C and C++. 54390 (line 6) 54391* DO_STMT: Statements for C and C++. 54392 (line 6) 54393* DQmode: Machine Modes. (line 118) 54394* driver: Driver. (line 6) 54395* DRIVER_SELF_SPECS: Driver. (line 8) 54396* dump examples: Dump examples. (line 6) 54397* dump setup: Dump setup. (line 6) 54398* dump types: Dump types. (line 6) 54399* dump verbosity: Dump output verbosity. 54400 (line 6) 54401* DUMPFILE_FORMAT: Filesystem. (line 67) 54402* dump_basic_block: Dump types. (line 29) 54403* dump_generic_expr: Dump types. (line 31) 54404* dump_gimple_stmt: Dump types. (line 33) 54405* dump_printf: Dump types. (line 6) 54406* DWARF2_ASM_LINE_DEBUG_INFO: DWARF. (line 45) 54407* DWARF2_ASM_VIEW_DEBUG_INFO: DWARF. (line 51) 54408* DWARF2_DEBUGGING_INFO: DWARF. (line 8) 54409* DWARF2_FRAME_INFO: DWARF. (line 25) 54410* DWARF2_FRAME_REG_OUT: Frame Registers. (line 149) 54411* DWARF2_UNWIND_INFO: Exception Region Output. 54412 (line 39) 54413* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 146) 54414* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 54415 (line 90) 54416* DWARF_FRAME_REGISTERS: Frame Registers. (line 109) 54417* DWARF_FRAME_REGNUM: Frame Registers. (line 141) 54418* DWARF_LAZY_REGISTER_VALUE: Frame Registers. (line 170) 54419* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 134) 54420* DWARF_ZERO_REG: Frame Layout. (line 157) 54421* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 84) 54422* E in constraint: Simple Constraints. (line 87) 54423* earlyclobber operand: Modifiers. (line 25) 54424* edge: Edges. (line 6) 54425* edge in the flow graph: Edges. (line 6) 54426* edge iterators: Edges. (line 15) 54427* edge splitting: Maintaining the CFG. 54428 (line 104) 54429* EDGE_ABNORMAL: Edges. (line 127) 54430* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171) 54431* EDGE_ABNORMAL, EDGE_EH: Edges. (line 95) 54432* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 121) 54433* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 85) 54434* EDOM, implicit usage: Library Calls. (line 59) 54435* EH_FRAME_SECTION_NAME: Exception Region Output. 54436 (line 9) 54437* EH_FRAME_THROUGH_COLLECT2: Exception Region Output. 54438 (line 19) 54439* eh_return instruction pattern: Standard Names. (line 2259) 54440* EH_RETURN_DATA_REGNO: Exception Handling. (line 6) 54441* EH_RETURN_HANDLER_RTX: Exception Handling. (line 38) 54442* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 21) 54443* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 54444 (line 29) 54445* EH_USES: Function Entry. (line 162) 54446* ei_edge: Edges. (line 43) 54447* ei_end_p: Edges. (line 27) 54448* ei_last: Edges. (line 23) 54449* ei_next: Edges. (line 35) 54450* ei_one_before_end_p: Edges. (line 31) 54451* ei_prev: Edges. (line 39) 54452* ei_safe_safe: Edges. (line 47) 54453* ei_start: Edges. (line 19) 54454* ELIMINABLE_REGS: Elimination. (line 34) 54455* ELSE_CLAUSE: Statements for C and C++. 54456 (line 6) 54457* Embedded C: Fixed-point fractional library routines. 54458 (line 6) 54459* Empty Statements: Empty Statements. (line 6) 54460* EMPTY_CLASS_EXPR: Statements for C and C++. 54461 (line 6) 54462* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 345) 54463* Emulated TLS: Emulated TLS. (line 6) 54464* enabled: Disable Insn Alternatives. 54465 (line 6) 54466* ENDFILE_SPEC: Driver. (line 155) 54467* endianness: Portability. (line 20) 54468* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 10) 54469* entry_value: Debug Information. (line 30) 54470* enum reg_class: Register Classes. (line 70) 54471* ENUMERAL_TYPE: Types. (line 6) 54472* enumerations: Constant Definitions. 54473 (line 49) 54474* epilogue: Function Entry. (line 6) 54475* epilogue instruction pattern: Standard Names. (line 2297) 54476* EPILOGUE_USES: Function Entry. (line 156) 54477* eq: Comparisons. (line 52) 54478* eq and attributes: Expressions. (line 83) 54479* equal: Comparisons. (line 52) 54480* eq_attr: Expressions. (line 104) 54481* EQ_EXPR: Unary and Binary Expressions. 54482 (line 6) 54483* errno, implicit usage: Library Calls. (line 71) 54484* EXACT_DIV_EXPR: Unary and Binary Expressions. 54485 (line 6) 54486* examining SSA_NAMEs: SSA. (line 182) 54487* exception handling: Edges. (line 95) 54488* exception handling <1>: Exception Handling. (line 6) 54489* exception_receiver instruction pattern: Standard Names. (line 2224) 54490* exclamation point: Multi-Alternative. (line 48) 54491* exclusion_set: Processor pipeline description. 54492 (line 223) 54493* exclusive-or, bitwise: Arithmetic. (line 168) 54494* EXIT_EXPR: Unary and Binary Expressions. 54495 (line 6) 54496* EXIT_IGNORE_STACK: Function Entry. (line 144) 54497* exp10M2 instruction pattern: Standard Names. (line 1033) 54498* exp2M2 instruction pattern: Standard Names. (line 1040) 54499* expander definitions: Expander Definitions. 54500 (line 6) 54501* expm1M2 instruction pattern: Standard Names. (line 1023) 54502* expM2 instruction pattern: Standard Names. (line 1016) 54503* expression: Expression trees. (line 6) 54504* expression codes: RTL Objects. (line 47) 54505* EXPR_FILENAME: Working with declarations. 54506 (line 14) 54507* EXPR_LINENO: Working with declarations. 54508 (line 20) 54509* expr_list: Insns. (line 568) 54510* EXPR_STMT: Statements for C and C++. 54511 (line 6) 54512* EXPR_STMT_EXPR: Statements for C and C++. 54513 (line 6) 54514* extended basic blocks, RTL SSA: RTL SSA Basic Blocks. 54515 (line 29) 54516* extendMN2 instruction pattern: Standard Names. (line 1646) 54517* extensible constraints: Simple Constraints. (line 171) 54518* extract_last_M instruction pattern: Standard Names. (line 567) 54519* EXTRA_SPECS: Driver. (line 182) 54520* extv instruction pattern: Standard Names. (line 1737) 54521* extvM instruction pattern: Standard Names. (line 1682) 54522* extvmisalignM instruction pattern: Standard Names. (line 1692) 54523* extzv instruction pattern: Standard Names. (line 1755) 54524* extzvM instruction pattern: Standard Names. (line 1706) 54525* extzvmisalignM instruction pattern: Standard Names. (line 1709) 54526* F in constraint: Simple Constraints. (line 92) 54527* FAIL: Expander Definitions. 54528 (line 83) 54529* FAIL <1>: Insn Splitting. (line 68) 54530* FAIL <2>: define_peephole2. (line 83) 54531* fall-thru: Edges. (line 68) 54532* false positive: Guidelines for Diagnostics. 54533 (line 39) 54534* FATAL_EXIT_CODE: Host Misc. (line 6) 54535* FDL, GNU Free Documentation License: GNU Free Documentation License. 54536 (line 6) 54537* features, optional, in system conventions: Run-time Target. 54538 (line 59) 54539* ffs: Arithmetic. (line 210) 54540* ffsM2 instruction pattern: Standard Names. (line 1356) 54541* FIELD_DECL: Declarations. (line 6) 54542* files and passes of the compiler: Passes. (line 6) 54543* files, generated: Files. (line 6) 54544* file_end_indicate_exec_stack: File Framework. (line 39) 54545* final_absence_set: Processor pipeline description. 54546 (line 223) 54547* FINAL_PRESCAN_INSN: Instruction Output. (line 60) 54548* final_presence_set: Processor pipeline description. 54549 (line 223) 54550* final_sequence: Instruction Output. (line 144) 54551* FIND_BASE_TERM: Addressing Modes. (line 117) 54552* finite state automaton minimization: Processor pipeline description. 54553 (line 304) 54554* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 113) 54555* FINI_SECTION_ASM_OP: Sections. (line 98) 54556* FIRST_PARM_OFFSET: Frame Layout. (line 59) 54557* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 54558* FIRST_PSEUDO_REGISTER: Register Basics. (line 8) 54559* FIRST_STACK_REG: Stack Registers. (line 26) 54560* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 54561* fix: Conversions. (line 66) 54562* fix-it hints: Guidelines for Diagnostics. 54563 (line 344) 54564* fixed register: Register Basics. (line 15) 54565* fixed-point fractional library: Fixed-point fractional library routines. 54566 (line 6) 54567* FIXED_CONVERT_EXPR: Unary and Binary Expressions. 54568 (line 6) 54569* FIXED_CST: Constant expressions. 54570 (line 6) 54571* FIXED_POINT_TYPE: Types. (line 6) 54572* FIXED_REGISTERS: Register Basics. (line 14) 54573* fixed_regs: Register Basics. (line 102) 54574* fixed_size_mode: Machine Modes. (line 310) 54575* fixMN2 instruction pattern: Standard Names. (line 1613) 54576* fixunsMN2 instruction pattern: Standard Names. (line 1622) 54577* fixuns_truncMN2 instruction pattern: Standard Names. (line 1637) 54578* fix_truncMN2 instruction pattern: Standard Names. (line 1633) 54579* FIX_TRUNC_EXPR: Unary and Binary Expressions. 54580 (line 6) 54581* flags in RTL expression: Flags. (line 6) 54582* float: Conversions. (line 58) 54583* floating point and cross compilation: Floating Point. (line 6) 54584* floatMN2 instruction pattern: Standard Names. (line 1605) 54585* floatunsMN2 instruction pattern: Standard Names. (line 1609) 54586* FLOAT_EXPR: Unary and Binary Expressions. 54587 (line 6) 54588* float_extend: Conversions. (line 33) 54589* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 32) 54590* FLOAT_STORE_FLAG_VALUE: Misc. (line 322) 54591* float_truncate: Conversions. (line 53) 54592* FLOAT_TYPE_SIZE: Type Layout. (line 48) 54593* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 41) 54594* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 54595 (line 234) 54596* floorM2 instruction pattern: Standard Names. (line 1107) 54597* FLOOR_DIV_EXPR: Unary and Binary Expressions. 54598 (line 6) 54599* FLOOR_MOD_EXPR: Unary and Binary Expressions. 54600 (line 6) 54601* flow-insensitive alias analysis: Alias analysis. (line 6) 54602* flow-sensitive alias analysis: Alias analysis. (line 6) 54603* fma: Arithmetic. (line 112) 54604* fmaM4 instruction pattern: Standard Names. (line 502) 54605* fmaxM3 instruction pattern: Standard Names. (line 533) 54606* fminM3 instruction pattern: Standard Names. (line 533) 54607* fmodM3 instruction pattern: Standard Names. (line 939) 54608* fmsM4 instruction pattern: Standard Names. (line 509) 54609* fnmaM4 instruction pattern: Standard Names. (line 515) 54610* fnmsM4 instruction pattern: Standard Names. (line 521) 54611* fold_extract_last_M instruction pattern: Standard Names. (line 574) 54612* fold_left_plus_M instruction pattern: Standard Names. (line 582) 54613* FORCE_CODE_SECTION_ALIGN: Sections. (line 149) 54614* force_reg: Standard Names. (line 36) 54615* FOR_BODY: Statements for C and C++. 54616 (line 6) 54617* FOR_COND: Statements for C and C++. 54618 (line 6) 54619* FOR_EXPR: Statements for C and C++. 54620 (line 6) 54621* FOR_INIT_STMT: Statements for C and C++. 54622 (line 6) 54623* FOR_STMT: Statements for C and C++. 54624 (line 6) 54625* for_user: GTY Options. (line 82) 54626* fractional types: Fixed-point fractional library routines. 54627 (line 6) 54628* fractMN2 instruction pattern: Standard Names. (line 1655) 54629* fractunsMN2 instruction pattern: Standard Names. (line 1670) 54630* fract_convert: Conversions. (line 82) 54631* FRACT_TYPE_SIZE: Type Layout. (line 67) 54632* frame layout: Frame Layout. (line 6) 54633* FRAME_ADDR_RTX: Frame Layout. (line 108) 54634* FRAME_GROWS_DOWNWARD: Frame Layout. (line 26) 54635* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 54636 (line 69) 54637* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 225) 54638* frame_pointer_needed: Function Entry. (line 42) 54639* FRAME_POINTER_REGNUM: Frame Registers. (line 13) 54640* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 54641 (line 74) 54642* frame_pointer_rtx: Frame Registers. (line 104) 54643* frame_related: Flags. (line 238) 54644* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 54645 (line 135) 54646* frame_related, in mem: Flags. (line 74) 54647* frame_related, in reg: Flags. (line 102) 54648* frame_related, in symbol_ref: Flags. (line 179) 54649* frequency, count, BB_FREQ_BASE: Profile information. 54650 (line 30) 54651* ftruncM2 instruction pattern: Standard Names. (line 1628) 54652* function: Functions. (line 6) 54653* function <1>: Functions for C++. (line 6) 54654* function call conventions: Interface. (line 6) 54655* function entry and exit: Function Entry. (line 6) 54656* function entry point, alternate function entry point: Edges. 54657 (line 180) 54658* function properties: Function Properties. 54659 (line 6) 54660* function-call insns: Calls. (line 6) 54661* functions, leaf: Leaf Functions. (line 6) 54662* FUNCTION_ARG_REGNO_P: Register Arguments. (line 261) 54663* FUNCTION_BOUNDARY: Storage Layout. (line 176) 54664* FUNCTION_DECL: Functions. (line 6) 54665* FUNCTION_DECL <1>: Functions for C++. (line 6) 54666* FUNCTION_MODE: Misc. (line 377) 54667* FUNCTION_PROFILER: Profiling. (line 8) 54668* FUNCTION_TYPE: Types. (line 6) 54669* FUNCTION_VALUE: Scalar Return. (line 52) 54670* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 78) 54671* fundamental type: Types. (line 6) 54672* G in constraint: Simple Constraints. (line 96) 54673* g in constraint: Simple Constraints. (line 118) 54674* garbage collector, invocation: Invoking the garbage collector. 54675 (line 6) 54676* garbage collector, troubleshooting: Troubleshooting. (line 6) 54677* gather_loadMN instruction pattern: Standard Names. (line 232) 54678* GCC and portability: Portability. (line 6) 54679* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 54680* gcov_type: Profile information. 54681 (line 41) 54682* ge: Comparisons. (line 72) 54683* ge and attributes: Expressions. (line 83) 54684* gencodes: RTL passes. (line 18) 54685* general_operand: Machine-Independent Predicates. 54686 (line 104) 54687* GENERAL_REGS: Register Classes. (line 22) 54688* generated files: Files. (line 6) 54689* generating assembler output: Output Statement. (line 6) 54690* generating insns: RTL Template. (line 6) 54691* GENERIC: Parsing pass. (line 6) 54692* GENERIC <1>: GENERIC. (line 6) 54693* generic predicates: Machine-Independent Predicates. 54694 (line 6) 54695* genflags: RTL passes. (line 18) 54696* GEN_ERRNO_RTX: Library Calls. (line 71) 54697* get_attr: Expressions. (line 99) 54698* get_attr_length: Insn Lengths. (line 52) 54699* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 435) 54700* GET_CODE: RTL Objects. (line 47) 54701* get_insns: Insns. (line 34) 54702* get_last_insn: Insns. (line 34) 54703* GET_MODE: Machine Modes. (line 382) 54704* GET_MODE_ALIGNMENT: Machine Modes. (line 422) 54705* GET_MODE_BITSIZE: Machine Modes. (line 406) 54706* GET_MODE_CLASS: Machine Modes. (line 396) 54707* GET_MODE_FBIT: Machine Modes. (line 413) 54708* GET_MODE_IBIT: Machine Modes. (line 409) 54709* GET_MODE_MASK: Machine Modes. (line 417) 54710* GET_MODE_NAME: Machine Modes. (line 393) 54711* GET_MODE_NUNITS: Machine Modes. (line 431) 54712* GET_MODE_SIZE: Machine Modes. (line 403) 54713* GET_MODE_UNIT_SIZE: Machine Modes. (line 425) 54714* GET_MODE_WIDER_MODE: Machine Modes. (line 399) 54715* GET_RTX_CLASS: RTL Classes. (line 6) 54716* GET_RTX_FORMAT: RTL Classes. (line 136) 54717* GET_RTX_LENGTH: RTL Classes. (line 133) 54718* get_thread_pointerMODE instruction pattern: Standard Names. 54719 (line 2676) 54720* geu: Comparisons. (line 72) 54721* geu and attributes: Expressions. (line 83) 54722* GE_EXPR: Unary and Binary Expressions. 54723 (line 6) 54724* GGC: Type Information. (line 6) 54725* ggc_collect: Invoking the garbage collector. 54726 (line 6) 54727* GIMPLE: Parsing pass. (line 13) 54728* GIMPLE <1>: Gimplification pass. 54729 (line 6) 54730* GIMPLE <2>: GIMPLE. (line 6) 54731* gimple: Tuple representation. 54732 (line 14) 54733* GIMPLE API: GIMPLE API. (line 6) 54734* GIMPLE class hierarchy: Class hierarchy of GIMPLE statements. 54735 (line 6) 54736* GIMPLE Exception Handling: GIMPLE Exception Handling. 54737 (line 6) 54738* GIMPLE instruction set: GIMPLE instruction set. 54739 (line 6) 54740* GIMPLE sequences: GIMPLE sequences. (line 6) 54741* GIMPLE statement iterators: Basic Blocks. (line 78) 54742* GIMPLE statement iterators <1>: Maintaining the CFG. 54743 (line 33) 54744* gimple_addresses_taken: Manipulating GIMPLE statements. 54745 (line 89) 54746* GIMPLE_ASM: GIMPLE_ASM. (line 6) 54747* gimple_asm_clobber_op: GIMPLE_ASM. (line 39) 54748* gimple_asm_input_op: GIMPLE_ASM. (line 23) 54749* gimple_asm_nclobbers: GIMPLE_ASM. (line 20) 54750* gimple_asm_ninputs: GIMPLE_ASM. (line 14) 54751* gimple_asm_noutputs: GIMPLE_ASM. (line 17) 54752* gimple_asm_output_op: GIMPLE_ASM. (line 31) 54753* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 43) 54754* gimple_asm_set_input_op: GIMPLE_ASM. (line 27) 54755* gimple_asm_set_output_op: GIMPLE_ASM. (line 35) 54756* gimple_asm_set_volatile: GIMPLE_ASM. (line 54) 54757* gimple_asm_string: GIMPLE_ASM. (line 47) 54758* gimple_asm_volatile_p: GIMPLE_ASM. (line 51) 54759* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6) 54760* gimple_assign_cast_p: Logical Operators. (line 158) 54761* gimple_assign_cast_p <1>: GIMPLE_ASSIGN. (line 104) 54762* gimple_assign_lhs: GIMPLE_ASSIGN. (line 62) 54763* gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 65) 54764* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 68) 54765* gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 71) 54766* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 75) 54767* gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 78) 54768* gimple_assign_rhs3: GIMPLE_ASSIGN. (line 82) 54769* gimple_assign_rhs3_ptr: GIMPLE_ASSIGN. (line 85) 54770* gimple_assign_rhs_class: GIMPLE_ASSIGN. (line 56) 54771* gimple_assign_rhs_code: GIMPLE_ASSIGN. (line 52) 54772* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 89) 54773* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 92) 54774* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 96) 54775* gimple_assign_set_rhs3: GIMPLE_ASSIGN. (line 100) 54776* gimple_bb: Manipulating GIMPLE statements. 54777 (line 17) 54778* GIMPLE_BIND: GIMPLE_BIND. (line 6) 54779* gimple_bind_add_seq: GIMPLE_BIND. (line 34) 54780* gimple_bind_add_stmt: GIMPLE_BIND. (line 31) 54781* gimple_bind_append_vars: GIMPLE_BIND. (line 18) 54782* gimple_bind_block: GIMPLE_BIND. (line 39) 54783* gimple_bind_body: GIMPLE_BIND. (line 22) 54784* gimple_bind_set_block: GIMPLE_BIND. (line 44) 54785* gimple_bind_set_body: GIMPLE_BIND. (line 26) 54786* gimple_bind_set_vars: GIMPLE_BIND. (line 14) 54787* gimple_bind_vars: GIMPLE_BIND. (line 11) 54788* gimple_block: Manipulating GIMPLE statements. 54789 (line 20) 54790* gimple_build: GIMPLE API. (line 34) 54791* gimple_build <1>: GIMPLE API. (line 36) 54792* gimple_build <2>: GIMPLE API. (line 38) 54793* gimple_build <3>: GIMPLE API. (line 41) 54794* gimple_build <4>: GIMPLE API. (line 44) 54795* gimple_build <5>: GIMPLE API. (line 47) 54796* gimple_build_debug_begin_stmt: GIMPLE_DEBUG. (line 72) 54797* gimple_build_debug_inline_entry: GIMPLE_DEBUG. (line 82) 54798* gimple_build_nop: GIMPLE_NOP. (line 6) 54799* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 6) 54800* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 6) 54801* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 6) 54802* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 6) 54803* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS. 54804 (line 13) 54805* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR. 54806 (line 6) 54807* GIMPLE_CALL: GIMPLE_CALL. (line 6) 54808* gimple_call_arg: GIMPLE_CALL. (line 67) 54809* gimple_call_arg_ptr: GIMPLE_CALL. (line 71) 54810* gimple_call_chain: GIMPLE_CALL. (line 58) 54811* gimple_call_copy_skip_args: GIMPLE_CALL. (line 92) 54812* gimple_call_fn: GIMPLE_CALL. (line 39) 54813* gimple_call_fndecl: GIMPLE_CALL. (line 47) 54814* gimple_call_lhs: GIMPLE_CALL. (line 30) 54815* gimple_call_lhs_ptr: GIMPLE_CALL. (line 33) 54816* gimple_call_noreturn_p: GIMPLE_CALL. (line 89) 54817* gimple_call_num_args: GIMPLE_CALL. (line 64) 54818* gimple_call_return_type: GIMPLE_CALL. (line 55) 54819* gimple_call_set_arg: GIMPLE_CALL. (line 76) 54820* gimple_call_set_chain: GIMPLE_CALL. (line 61) 54821* gimple_call_set_fn: GIMPLE_CALL. (line 43) 54822* gimple_call_set_fndecl: GIMPLE_CALL. (line 52) 54823* gimple_call_set_lhs: GIMPLE_CALL. (line 36) 54824* gimple_call_set_tail: GIMPLE_CALL. (line 81) 54825* gimple_call_tail_p: GIMPLE_CALL. (line 86) 54826* GIMPLE_CATCH: GIMPLE_CATCH. (line 6) 54827* gimple_catch_handler: GIMPLE_CATCH. (line 19) 54828* gimple_catch_set_handler: GIMPLE_CATCH. (line 26) 54829* gimple_catch_set_types: GIMPLE_CATCH. (line 23) 54830* gimple_catch_types: GIMPLE_CATCH. (line 12) 54831* gimple_catch_types_ptr: GIMPLE_CATCH. (line 15) 54832* gimple_code: Manipulating GIMPLE statements. 54833 (line 14) 54834* GIMPLE_COND: GIMPLE_COND. (line 6) 54835* gimple_cond_code: GIMPLE_COND. (line 20) 54836* gimple_cond_false_label: GIMPLE_COND. (line 59) 54837* gimple_cond_lhs: GIMPLE_COND. (line 29) 54838* gimple_cond_make_false: GIMPLE_COND. (line 63) 54839* gimple_cond_make_true: GIMPLE_COND. (line 66) 54840* gimple_cond_rhs: GIMPLE_COND. (line 37) 54841* gimple_cond_set_code: GIMPLE_COND. (line 24) 54842* gimple_cond_set_false_label: GIMPLE_COND. (line 54) 54843* gimple_cond_set_lhs: GIMPLE_COND. (line 33) 54844* gimple_cond_set_rhs: GIMPLE_COND. (line 41) 54845* gimple_cond_set_true_label: GIMPLE_COND. (line 49) 54846* gimple_cond_true_label: GIMPLE_COND. (line 45) 54847* gimple_convert: GIMPLE API. (line 50) 54848* gimple_copy: Manipulating GIMPLE statements. 54849 (line 146) 54850* GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6) 54851* GIMPLE_DEBUG_BEGIN_STMT: GIMPLE_DEBUG. (line 6) 54852* gimple_debug_begin_stmt_p: Logical Operators. (line 169) 54853* GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6) 54854* gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 46) 54855* gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 50) 54856* gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 43) 54857* gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 68) 54858* gimple_debug_bind_p: Logical Operators. (line 162) 54859* gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 64) 54860* gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 59) 54861* gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 55) 54862* GIMPLE_DEBUG_INLINE_ENTRY: GIMPLE_DEBUG. (line 6) 54863* gimple_debug_inline_entry_p: Logical Operators. (line 173) 54864* gimple_debug_nonbind_marker_p: Logical Operators. (line 177) 54865* gimple_def_ops: Manipulating GIMPLE statements. 54866 (line 93) 54867* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6) 54868* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 18) 54869* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 27) 54870* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 22) 54871* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 11) 54872* gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 14) 54873* gimple_eh_must_not_throw_fndecl: GIMPLE_EH_FILTER. (line 32) 54874* gimple_eh_must_not_throw_set_fndecl: GIMPLE_EH_FILTER. (line 36) 54875* gimple_expr_code: Manipulating GIMPLE statements. 54876 (line 30) 54877* gimple_expr_type: Manipulating GIMPLE statements. 54878 (line 23) 54879* GIMPLE_GOTO: GIMPLE_GOTO. (line 6) 54880* gimple_goto_dest: GIMPLE_GOTO. (line 9) 54881* gimple_goto_set_dest: GIMPLE_GOTO. (line 12) 54882* gimple_has_mem_ops: Manipulating GIMPLE statements. 54883 (line 71) 54884* gimple_has_ops: Manipulating GIMPLE statements. 54885 (line 68) 54886* gimple_has_volatile_ops: Manipulating GIMPLE statements. 54887 (line 133) 54888* GIMPLE_LABEL: GIMPLE_LABEL. (line 6) 54889* gimple_label_label: GIMPLE_LABEL. (line 10) 54890* gimple_label_set_label: GIMPLE_LABEL. (line 13) 54891* gimple_loaded_syms: Manipulating GIMPLE statements. 54892 (line 121) 54893* gimple_locus: Manipulating GIMPLE statements. 54894 (line 41) 54895* gimple_locus_empty_p: Manipulating GIMPLE statements. 54896 (line 47) 54897* gimple_modified_p: Manipulating GIMPLE statements. 54898 (line 129) 54899* GIMPLE_NOP: GIMPLE_NOP. (line 6) 54900* gimple_nop_p: GIMPLE_NOP. (line 9) 54901* gimple_no_warning_p: Manipulating GIMPLE statements. 54902 (line 50) 54903* gimple_num_ops: Logical Operators. (line 76) 54904* gimple_num_ops <1>: Manipulating GIMPLE statements. 54905 (line 74) 54906* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD. 54907 (line 6) 54908* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD. 54909 (line 16) 54910* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD. 54911 (line 24) 54912* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD. 54913 (line 12) 54914* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD. 54915 (line 20) 54916* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE. 54917 (line 6) 54918* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE. 54919 (line 11) 54920* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE. 54921 (line 15) 54922* gimple_omp_body: GIMPLE_OMP_PARALLEL. 54923 (line 23) 54924* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE. 54925 (line 6) 54926* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE. 54927 (line 12) 54928* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE. 54929 (line 17) 54930* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE. 54931 (line 26) 54932* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE. 54933 (line 31) 54934* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE. 54935 (line 21) 54936* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE. 54937 (line 35) 54938* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL. 54939 (line 6) 54940* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL. 54941 (line 12) 54942* gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL. 54943 (line 16) 54944* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL. 54945 (line 21) 54946* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6) 54947* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 17) 54948* gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 20) 54949* gimple_omp_for_cond: GIMPLE_OMP_FOR. (line 80) 54950* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 48) 54951* gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 51) 54952* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 58) 54953* gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 61) 54954* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 28) 54955* gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 31) 54956* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 38) 54957* gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 41) 54958* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 67) 54959* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 23) 54960* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 76) 54961* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 54) 54962* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 64) 54963* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 34) 54964* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 44) 54965* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 71) 54966* GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6) 54967* GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6) 54968* GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL. 54969 (line 6) 54970* gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL. 54971 (line 42) 54972* gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL. 54973 (line 47) 54974* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL. 54975 (line 30) 54976* gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL. 54977 (line 33) 54978* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL. 54979 (line 15) 54980* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL. 54981 (line 56) 54982* gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL. 54983 (line 61) 54984* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL. 54985 (line 52) 54986* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL. 54987 (line 37) 54988* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL. 54989 (line 19) 54990* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL. 54991 (line 65) 54992* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6) 54993* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 13) 54994* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 10) 54995* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6) 54996* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS. 54997 (line 6) 54998* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS. 54999 (line 29) 55000* gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS. 55001 (line 32) 55002* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS. 55003 (line 16) 55004* gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS. 55005 (line 20) 55006* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS. 55007 (line 35) 55008* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS. 55009 (line 24) 55010* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 11) 55011* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 15) 55012* gimple_omp_set_body: GIMPLE_OMP_PARALLEL. 55013 (line 26) 55014* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6) 55015* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 13) 55016* gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 16) 55017* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 19) 55018* gimple_op: Logical Operators. (line 79) 55019* gimple_op <1>: Manipulating GIMPLE statements. 55020 (line 80) 55021* gimple_ops: Logical Operators. (line 82) 55022* gimple_ops <1>: Manipulating GIMPLE statements. 55023 (line 77) 55024* gimple_op_ptr: Manipulating GIMPLE statements. 55025 (line 83) 55026* GIMPLE_PHI: GIMPLE_PHI. (line 6) 55027* gimple_phi_arg: GIMPLE_PHI. (line 24) 55028* gimple_phi_arg <1>: SSA. (line 62) 55029* gimple_phi_arg_def: SSA. (line 68) 55030* gimple_phi_arg_edge: SSA. (line 65) 55031* gimple_phi_capacity: GIMPLE_PHI. (line 6) 55032* gimple_phi_num_args: GIMPLE_PHI. (line 10) 55033* gimple_phi_num_args <1>: SSA. (line 58) 55034* gimple_phi_result: GIMPLE_PHI. (line 15) 55035* gimple_phi_result <1>: SSA. (line 55) 55036* gimple_phi_result_ptr: GIMPLE_PHI. (line 18) 55037* gimple_phi_set_arg: GIMPLE_PHI. (line 28) 55038* gimple_phi_set_result: GIMPLE_PHI. (line 21) 55039* gimple_plf: Manipulating GIMPLE statements. 55040 (line 64) 55041* GIMPLE_RESX: GIMPLE_RESX. (line 6) 55042* gimple_resx_region: GIMPLE_RESX. (line 12) 55043* gimple_resx_set_region: GIMPLE_RESX. (line 15) 55044* GIMPLE_RETURN: GIMPLE_RETURN. (line 6) 55045* gimple_return_retval: GIMPLE_RETURN. (line 9) 55046* gimple_return_set_retval: GIMPLE_RETURN. (line 12) 55047* gimple_seq_add_seq: GIMPLE sequences. (line 30) 55048* gimple_seq_add_stmt: GIMPLE sequences. (line 24) 55049* gimple_seq_alloc: GIMPLE sequences. (line 61) 55050* gimple_seq_copy: GIMPLE sequences. (line 65) 55051* gimple_seq_deep_copy: GIMPLE sequences. (line 36) 55052* gimple_seq_empty_p: GIMPLE sequences. (line 69) 55053* gimple_seq_first: GIMPLE sequences. (line 43) 55054* gimple_seq_init: GIMPLE sequences. (line 58) 55055* gimple_seq_last: GIMPLE sequences. (line 46) 55056* gimple_seq_reverse: GIMPLE sequences. (line 39) 55057* gimple_seq_set_first: GIMPLE sequences. (line 53) 55058* gimple_seq_set_last: GIMPLE sequences. (line 49) 55059* gimple_seq_singleton_p: GIMPLE sequences. (line 78) 55060* gimple_set_block: Manipulating GIMPLE statements. 55061 (line 38) 55062* gimple_set_def_ops: Manipulating GIMPLE statements. 55063 (line 96) 55064* gimple_set_has_volatile_ops: Manipulating GIMPLE statements. 55065 (line 136) 55066* gimple_set_locus: Manipulating GIMPLE statements. 55067 (line 44) 55068* gimple_set_op: Manipulating GIMPLE statements. 55069 (line 86) 55070* gimple_set_plf: Manipulating GIMPLE statements. 55071 (line 60) 55072* gimple_set_use_ops: Manipulating GIMPLE statements. 55073 (line 103) 55074* gimple_set_vdef_ops: Manipulating GIMPLE statements. 55075 (line 117) 55076* gimple_set_visited: Manipulating GIMPLE statements. 55077 (line 53) 55078* gimple_set_vuse_ops: Manipulating GIMPLE statements. 55079 (line 110) 55080* gimple_simplify: GIMPLE API. (line 6) 55081* gimple_simplify <1>: GIMPLE API. (line 8) 55082* gimple_simplify <2>: GIMPLE API. (line 10) 55083* gimple_simplify <3>: GIMPLE API. (line 12) 55084* gimple_simplify <4>: GIMPLE API. (line 14) 55085* gimple_simplify <5>: GIMPLE API. (line 16) 55086* gimple_statement_with_ops: Tuple representation. 55087 (line 96) 55088* gimple_stored_syms: Manipulating GIMPLE statements. 55089 (line 125) 55090* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6) 55091* gimple_switch_default_label: GIMPLE_SWITCH. (line 41) 55092* gimple_switch_index: GIMPLE_SWITCH. (line 24) 55093* gimple_switch_label: GIMPLE_SWITCH. (line 31) 55094* gimple_switch_num_labels: GIMPLE_SWITCH. (line 14) 55095* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 45) 55096* gimple_switch_set_index: GIMPLE_SWITCH. (line 27) 55097* gimple_switch_set_label: GIMPLE_SWITCH. (line 36) 55098* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 19) 55099* GIMPLE_TRY: GIMPLE_TRY. (line 6) 55100* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 19) 55101* gimple_try_cleanup: GIMPLE_TRY. (line 26) 55102* gimple_try_eval: GIMPLE_TRY. (line 22) 55103* gimple_try_kind: GIMPLE_TRY. (line 15) 55104* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 30) 55105* gimple_try_set_cleanup: GIMPLE_TRY. (line 38) 55106* gimple_try_set_eval: GIMPLE_TRY. (line 34) 55107* gimple_use_ops: Manipulating GIMPLE statements. 55108 (line 100) 55109* gimple_vdef_ops: Manipulating GIMPLE statements. 55110 (line 114) 55111* gimple_visited_p: Manipulating GIMPLE statements. 55112 (line 57) 55113* gimple_vuse_ops: Manipulating GIMPLE statements. 55114 (line 107) 55115* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 55116 (line 10) 55117* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 55118 (line 17) 55119* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 55120 (line 13) 55121* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 55122 (line 20) 55123* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR. 55124 (line 6) 55125* gimplification: Parsing pass. (line 13) 55126* gimplification <1>: Gimplification pass. 55127 (line 6) 55128* gimplifier: Parsing pass. (line 13) 55129* gimplify_assign: GIMPLE_ASSIGN. (line 41) 55130* gimplify_expr: Gimplification pass. 55131 (line 18) 55132* gimplify_function_tree: Gimplification pass. 55133 (line 18) 55134* GLOBAL_INIT_PRIORITY: Functions for C++. (line 141) 55135* global_regs: Register Basics. (line 102) 55136* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 90) 55137* greater than: Comparisons. (line 60) 55138* greater than <1>: Comparisons. (line 64) 55139* greater than <2>: Comparisons. (line 72) 55140* gsi_after_labels: Sequence iterators. (line 74) 55141* gsi_bb: Sequence iterators. (line 82) 55142* gsi_commit_edge_inserts: Sequence iterators. (line 193) 55143* gsi_commit_edge_inserts <1>: Maintaining the CFG. 55144 (line 104) 55145* gsi_commit_one_edge_insert: Sequence iterators. (line 188) 55146* gsi_end_p: Sequence iterators. (line 59) 55147* gsi_end_p <1>: Maintaining the CFG. 55148 (line 48) 55149* gsi_for_stmt: Sequence iterators. (line 156) 55150* gsi_insert_after: Sequence iterators. (line 145) 55151* gsi_insert_after <1>: Maintaining the CFG. 55152 (line 60) 55153* gsi_insert_before: Sequence iterators. (line 134) 55154* gsi_insert_before <1>: Maintaining the CFG. 55155 (line 66) 55156* gsi_insert_on_edge: Sequence iterators. (line 173) 55157* gsi_insert_on_edge <1>: Maintaining the CFG. 55158 (line 104) 55159* gsi_insert_on_edge_immediate: Sequence iterators. (line 183) 55160* gsi_insert_seq_after: Sequence iterators. (line 152) 55161* gsi_insert_seq_before: Sequence iterators. (line 141) 55162* gsi_insert_seq_on_edge: Sequence iterators. (line 177) 55163* gsi_last: Sequence iterators. (line 49) 55164* gsi_last <1>: Maintaining the CFG. 55165 (line 44) 55166* gsi_last_bb: Sequence iterators. (line 55) 55167* gsi_link_after: Sequence iterators. (line 113) 55168* gsi_link_before: Sequence iterators. (line 103) 55169* gsi_link_seq_after: Sequence iterators. (line 108) 55170* gsi_link_seq_before: Sequence iterators. (line 97) 55171* gsi_move_after: Sequence iterators. (line 159) 55172* gsi_move_before: Sequence iterators. (line 164) 55173* gsi_move_to_bb_end: Sequence iterators. (line 169) 55174* gsi_next: Sequence iterators. (line 65) 55175* gsi_next <1>: Maintaining the CFG. 55176 (line 52) 55177* gsi_one_before_end_p: Sequence iterators. (line 62) 55178* gsi_prev: Sequence iterators. (line 68) 55179* gsi_prev <1>: Maintaining the CFG. 55180 (line 56) 55181* gsi_remove: Sequence iterators. (line 88) 55182* gsi_remove <1>: Maintaining the CFG. 55183 (line 72) 55184* gsi_replace: Sequence iterators. (line 128) 55185* gsi_seq: Sequence iterators. (line 85) 55186* gsi_split_seq_after: Sequence iterators. (line 118) 55187* gsi_split_seq_before: Sequence iterators. (line 123) 55188* gsi_start: Sequence iterators. (line 39) 55189* gsi_start <1>: Maintaining the CFG. 55190 (line 40) 55191* gsi_start_bb: Sequence iterators. (line 45) 55192* gsi_stmt: Sequence iterators. (line 71) 55193* gsi_stmt_ptr: Sequence iterators. (line 79) 55194* gt: Comparisons. (line 60) 55195* gt and attributes: Expressions. (line 83) 55196* gtu: Comparisons. (line 64) 55197* gtu and attributes: Expressions. (line 83) 55198* GTY: Type Information. (line 6) 55199* GT_EXPR: Unary and Binary Expressions. 55200 (line 6) 55201* guidelines for diagnostics: Guidelines for Diagnostics. 55202 (line 6) 55203* guidelines for options: Guidelines for Options. 55204 (line 6) 55205* guidelines, user experience: User Experience Guidelines. 55206 (line 6) 55207* H in constraint: Simple Constraints. (line 96) 55208* HAmode: Machine Modes. (line 146) 55209* HANDLER: Statements for C and C++. 55210 (line 6) 55211* HANDLER_BODY: Statements for C and C++. 55212 (line 6) 55213* HANDLER_PARMS: Statements for C and C++. 55214 (line 6) 55215* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 477) 55216* hard registers: Regs and Memory. (line 9) 55217* HARD_FRAME_POINTER_IS_ARG_POINTER: Frame Registers. (line 57) 55218* HARD_FRAME_POINTER_IS_FRAME_POINTER: Frame Registers. (line 50) 55219* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 19) 55220* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 10) 55221* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 55222 (line 21) 55223* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 55224 (line 39) 55225* HARD_REGNO_RENAME_OK: Values in Registers. 55226 (line 113) 55227* HAS_INIT_SECTION: Macros for Initialization. 55228 (line 18) 55229* HAS_LONG_COND_BRANCH: Misc. (line 8) 55230* HAS_LONG_UNCOND_BRANCH: Misc. (line 17) 55231* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 55232* HAVE_POST_DECREMENT: Addressing Modes. (line 11) 55233* HAVE_POST_INCREMENT: Addressing Modes. (line 10) 55234* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 17) 55235* HAVE_POST_MODIFY_REG: Addressing Modes. (line 23) 55236* HAVE_PRE_DECREMENT: Addressing Modes. (line 9) 55237* HAVE_PRE_INCREMENT: Addressing Modes. (line 8) 55238* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 16) 55239* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 22) 55240* HCmode: Machine Modes. (line 199) 55241* HFmode: Machine Modes. (line 61) 55242* high: Constants. (line 234) 55243* HImode: Machine Modes. (line 29) 55244* HImode, in insn: Insns. (line 291) 55245* HONOR_REG_ALLOC_ORDER: Allocation Order. (line 36) 55246* host configuration: Host Config. (line 6) 55247* host functions: Host Common. (line 6) 55248* host hooks: Host Common. (line 6) 55249* host makefile fragment: Host Fragment. (line 6) 55250* HOST_BIT_BUCKET: Filesystem. (line 51) 55251* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 55252* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 11) 55253* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 43) 55254* HOST_HOOKS_GT_PCH_GET_ADDRESS: Host Common. (line 15) 55255* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 24) 55256* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 55257* HOST_LONG_FORMAT: Host Misc. (line 45) 55258* HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 55259* HOST_OBJECT_SUFFIX: Filesystem. (line 40) 55260* HOST_PTR_PRINTF: Host Misc. (line 49) 55261* HOT_TEXT_SECTION_NAME: Sections. (line 42) 55262* HQmode: Machine Modes. (line 110) 55263* i in constraint: Simple Constraints. (line 68) 55264* I in constraint: Simple Constraints. (line 79) 55265* identifier: Identifiers. (line 6) 55266* IDENTIFIER_LENGTH: Identifiers. (line 22) 55267* IDENTIFIER_NODE: Identifiers. (line 6) 55268* IDENTIFIER_OPNAME_P: Identifiers. (line 27) 55269* IDENTIFIER_POINTER: Identifiers. (line 17) 55270* IDENTIFIER_TYPENAME_P: Identifiers. (line 33) 55271* IEEE 754-2008: Decimal float library routines. 55272 (line 6) 55273* IFCVT_MACHDEP_INIT: Misc. (line 606) 55274* IFCVT_MODIFY_CANCEL: Misc. (line 600) 55275* IFCVT_MODIFY_FINAL: Misc. (line 594) 55276* IFCVT_MODIFY_INSN: Misc. (line 588) 55277* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 580) 55278* IFCVT_MODIFY_TESTS: Misc. (line 570) 55279* IF_COND: Statements for C and C++. 55280 (line 6) 55281* IF_STMT: Statements for C and C++. 55282 (line 6) 55283* if_then_else: Comparisons. (line 80) 55284* if_then_else and attributes: Expressions. (line 32) 55285* if_then_else usage: Side Effects. (line 56) 55286* IMAGPART_EXPR: Unary and Binary Expressions. 55287 (line 6) 55288* Immediate Uses: SSA Operands. (line 258) 55289* immediate_operand: Machine-Independent Predicates. 55290 (line 10) 55291* IMMEDIATE_PREFIX: Instruction Output. (line 153) 55292* include: Including Patterns. (line 6) 55293* INCLUDE_DEFAULTS: Driver. (line 331) 55294* inclusive-or, bitwise: Arithmetic. (line 163) 55295* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 188) 55296* INCOMING_REGNO: Register Basics. (line 129) 55297* INCOMING_REG_PARM_STACK_SPACE: Stack Arguments. (line 73) 55298* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 133) 55299* INCOMING_STACK_BOUNDARY: Storage Layout. (line 171) 55300* INDEX_REG_CLASS: Register Classes. (line 140) 55301* indirect_jump instruction pattern: Standard Names. (line 2025) 55302* indirect_operand: Machine-Independent Predicates. 55303 (line 70) 55304* INDIRECT_REF: Storage References. (line 6) 55305* initialization routines: Initialization. (line 6) 55306* INITIAL_ELIMINATION_OFFSET: Elimination. (line 68) 55307* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 75) 55308* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 106) 55309* INIT_CUMULATIVE_ARGS: Register Arguments. (line 158) 55310* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 186) 55311* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 180) 55312* INIT_ENVIRONMENT: Driver. (line 309) 55313* INIT_EXPANDERS: Per-Function Data. (line 36) 55314* INIT_EXPR: Unary and Binary Expressions. 55315 (line 6) 55316* init_machine_status: Per-Function Data. (line 42) 55317* init_one_libfunc: Library Calls. (line 15) 55318* INIT_SECTION_ASM_OP: Sections. (line 90) 55319* INIT_SECTION_ASM_OP <1>: Macros for Initialization. 55320 (line 9) 55321* inlining: Target Attributes. (line 103) 55322* insert_insn_on_edge: Maintaining the CFG. 55323 (line 104) 55324* insn: Insns. (line 63) 55325* insn and /f: Flags. (line 135) 55326* insn and /j: Flags. (line 171) 55327* insn and /s: Flags. (line 38) 55328* insn and /s <1>: Flags. (line 162) 55329* insn and /u: Flags. (line 28) 55330* insn and /v: Flags. (line 33) 55331* insn attributes: Insn Attributes. (line 6) 55332* insn canonicalization: Insn Canonicalizations. 55333 (line 6) 55334* insn includes: Including Patterns. (line 6) 55335* insn lengths, computing: Insn Lengths. (line 6) 55336* insn notes, notes: Basic Blocks. (line 52) 55337* insn splitting: Insn Splitting. (line 6) 55338* insn-attr.h: Defining Attributes. 55339 (line 34) 55340* insns: Insns. (line 6) 55341* insns, generating: RTL Template. (line 6) 55342* insns, recognizing: RTL Template. (line 6) 55343* INSN_ANNULLED_BRANCH_P: Flags. (line 28) 55344* INSN_CODE: Insns. (line 318) 55345* INSN_DELETED_P: Flags. (line 33) 55346* INSN_FROM_TARGET_P: Flags. (line 38) 55347* insn_list: Insns. (line 568) 55348* INSN_REFERENCES_ARE_DELAYED: Misc. (line 504) 55349* INSN_SETS_ARE_DELAYED: Misc. (line 493) 55350* INSN_UID: Insns. (line 23) 55351* INSN_VAR_LOCATION: Insns. (line 247) 55352* instruction attributes: Insn Attributes. (line 6) 55353* instruction latency time: Processor pipeline description. 55354 (line 6) 55355* instruction latency time <1>: Processor pipeline description. 55356 (line 105) 55357* instruction latency time <2>: Processor pipeline description. 55358 (line 196) 55359* instruction patterns: Patterns. (line 6) 55360* instruction splitting: Insn Splitting. (line 6) 55361* instructions, RTL SSA: RTL SSA Instructions. 55362 (line 6) 55363* insv instruction pattern: Standard Names. (line 1761) 55364* insvM instruction pattern: Standard Names. (line 1713) 55365* insvmisalignM instruction pattern: Standard Names. (line 1723) 55366* int iterators in .md files: Int Iterators. (line 6) 55367* INT16_TYPE: Type Layout. (line 210) 55368* INT32_TYPE: Type Layout. (line 211) 55369* INT64_TYPE: Type Layout. (line 212) 55370* INT8_TYPE: Type Layout. (line 209) 55371* INTEGER_CST: Constant expressions. 55372 (line 6) 55373* INTEGER_TYPE: Types. (line 6) 55374* inter-procedural optimization passes: IPA passes. (line 6) 55375* Interdependence of Patterns: Dependent Patterns. (line 6) 55376* interfacing to GCC output: Interface. (line 6) 55377* interlock delays: Processor pipeline description. 55378 (line 6) 55379* intermediate representation lowering: Parsing pass. (line 13) 55380* INTMAX_TYPE: Type Layout. (line 186) 55381* INTPTR_TYPE: Type Layout. (line 233) 55382* introduction: Top. (line 6) 55383* INT_FAST16_TYPE: Type Layout. (line 226) 55384* INT_FAST32_TYPE: Type Layout. (line 227) 55385* INT_FAST64_TYPE: Type Layout. (line 228) 55386* INT_FAST8_TYPE: Type Layout. (line 225) 55387* INT_LEAST16_TYPE: Type Layout. (line 218) 55388* INT_LEAST32_TYPE: Type Layout. (line 219) 55389* INT_LEAST64_TYPE: Type Layout. (line 220) 55390* INT_LEAST8_TYPE: Type Layout. (line 217) 55391* INT_TYPE_SIZE: Type Layout. (line 11) 55392* INVOKE__main: Macros for Initialization. 55393 (line 50) 55394* in_struct: Flags. (line 254) 55395* in_struct, in code_label and note: Flags. (line 48) 55396* in_struct, in insn and jump_insn and call_insn: Flags. (line 38) 55397* in_struct, in insn, call_insn, jump_insn and jump_table_data: Flags. 55398 (line 162) 55399* in_struct, in subreg: Flags. (line 201) 55400* ior: Arithmetic. (line 163) 55401* ior and attributes: Expressions. (line 50) 55402* ior, canonicalization of: Insn Canonicalizations. 55403 (line 67) 55404* iorM3 instruction pattern: Standard Names. (line 466) 55405* IPA passes: IPA passes. (line 6) 55406* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 44) 55407* is_a: Machine Modes. (line 352) 55408* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 129) 55409* is_gimple_addressable: Logical Operators. (line 113) 55410* is_gimple_asm_val: Logical Operators. (line 117) 55411* is_gimple_assign: Logical Operators. (line 149) 55412* is_gimple_call: Logical Operators. (line 152) 55413* is_gimple_call_addr: Logical Operators. (line 120) 55414* is_gimple_constant: Logical Operators. (line 128) 55415* is_gimple_debug: Logical Operators. (line 155) 55416* is_gimple_ip_invariant: Logical Operators. (line 137) 55417* is_gimple_ip_invariant_address: Logical Operators. (line 142) 55418* is_gimple_mem_ref_addr: Logical Operators. (line 124) 55419* is_gimple_min_invariant: Logical Operators. (line 131) 55420* is_gimple_omp: Logical Operators. (line 166) 55421* is_gimple_val: Logical Operators. (line 107) 55422* iterators in .md files: Iterators. (line 6) 55423* IV analysis on GIMPLE: Scalar evolutions. (line 6) 55424* IV analysis on RTL: loop-iv. (line 6) 55425* JMP_BUF_SIZE: Exception Region Output. 55426 (line 83) 55427* jump: Flags. (line 295) 55428* jump instruction pattern: Standard Names. (line 1903) 55429* jump instruction patterns: Jump Patterns. (line 6) 55430* jump instructions and set: Side Effects. (line 56) 55431* jump, in call_insn: Flags. (line 175) 55432* jump, in insn: Flags. (line 171) 55433* jump, in mem: Flags. (line 59) 55434* Jumps: Jumps. (line 6) 55435* JUMP_ALIGN: Alignment Output. (line 8) 55436* jump_insn: Insns. (line 73) 55437* jump_insn and /f: Flags. (line 135) 55438* jump_insn and /j: Flags. (line 10) 55439* jump_insn and /s: Flags. (line 38) 55440* jump_insn and /s <1>: Flags. (line 162) 55441* jump_insn and /u: Flags. (line 28) 55442* jump_insn and /v: Flags. (line 33) 55443* JUMP_LABEL: Insns. (line 80) 55444* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 155) 55445* jump_table_data: Insns. (line 166) 55446* jump_table_data and /s: Flags. (line 162) 55447* jump_table_data and /v: Flags. (line 33) 55448* LABEL_ALIGN: Alignment Output. (line 42) 55449* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 21) 55450* LABEL_ALTERNATE_NAME: Edges. (line 180) 55451* LABEL_ALT_ENTRY_P: Insns. (line 146) 55452* LABEL_DECL: Declarations. (line 6) 55453* LABEL_KIND: Insns. (line 146) 55454* LABEL_NUSES: Insns. (line 142) 55455* LABEL_PRESERVE_P: Flags. (line 48) 55456* label_ref: Constants. (line 213) 55457* label_ref and /v: Flags. (line 54) 55458* label_ref, RTL sharing: Sharing. (line 38) 55459* LABEL_REF_NONLOCAL_P: Flags. (line 54) 55460* language-dependent trees: Language-dependent trees. 55461 (line 6) 55462* language-independent intermediate representation: Parsing pass. 55463 (line 13) 55464* lang_hooks.gimplify_expr: Gimplification pass. 55465 (line 18) 55466* lang_hooks.parse_file: Parsing pass. (line 6) 55467* large return values: Aggregate Return. (line 6) 55468* LAST_STACK_REG: Stack Registers. (line 30) 55469* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 55470* late IPA passes: Late IPA passes. (line 6) 55471* lceilMN2: Standard Names. (line 1175) 55472* LCSSA: LCSSA. (line 6) 55473* LDD_SUFFIX: Macros for Initialization. 55474 (line 121) 55475* ldexpM3 instruction pattern: Standard Names. (line 960) 55476* LD_FINI_SWITCH: Macros for Initialization. 55477 (line 28) 55478* LD_INIT_SWITCH: Macros for Initialization. 55479 (line 24) 55480* le: Comparisons. (line 76) 55481* le and attributes: Expressions. (line 83) 55482* leaf functions: Leaf Functions. (line 6) 55483* leaf_function_p: Standard Names. (line 1987) 55484* LEAF_REGISTERS: Leaf Functions. (line 23) 55485* LEAF_REG_REMAP: Leaf Functions. (line 37) 55486* left rotate: Arithmetic. (line 195) 55487* left shift: Arithmetic. (line 173) 55488* LEGITIMATE_PIC_OPERAND_P: PIC. (line 31) 55489* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 150) 55490* length: GTY Options. (line 47) 55491* len_load_M instruction pattern: Standard Names. (line 410) 55492* len_store_M instruction pattern: Standard Names. (line 422) 55493* less than: Comparisons. (line 68) 55494* less than or equal: Comparisons. (line 76) 55495* leu: Comparisons. (line 76) 55496* leu and attributes: Expressions. (line 83) 55497* LE_EXPR: Unary and Binary Expressions. 55498 (line 6) 55499* lfloorMN2: Standard Names. (line 1170) 55500* LIB2FUNCS_EXTRA: Target Fragment. (line 11) 55501* LIBCALL_VALUE: Scalar Return. (line 56) 55502* libgcc.a: Library Calls. (line 6) 55503* LIBGCC2_CFLAGS: Target Fragment. (line 8) 55504* LIBGCC2_GNU_PREFIX: Type Layout. (line 102) 55505* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 1052) 55506* LIBGCC_SPEC: Driver. (line 115) 55507* library subroutine names: Library Calls. (line 6) 55508* LIBRARY_PATH_ENV: Misc. (line 548) 55509* LIB_SPEC: Driver. (line 107) 55510* LIMIT_RELOAD_CLASS: Register Classes. (line 296) 55511* LINK_COMMAND_SPEC: Driver. (line 240) 55512* LINK_EH_SPEC: Driver. (line 142) 55513* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 232) 55514* LINK_LIBGCC_SPECIAL_1: Driver. (line 227) 55515* LINK_SPEC: Driver. (line 100) 55516* list: Containers. (line 6) 55517* Liveness representation: Liveness information. 55518 (line 6) 55519* load address instruction: Simple Constraints. (line 162) 55520* LOAD_EXTEND_OP: Misc. (line 80) 55521* load_multiple instruction pattern: Standard Names. (line 136) 55522* Local Register Allocator (LRA): RTL passes. (line 187) 55523* LOCAL_ALIGNMENT: Storage Layout. (line 288) 55524* LOCAL_CLASS_P: Classes. (line 70) 55525* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 325) 55526* LOCAL_INCLUDE_DIR: Driver. (line 316) 55527* LOCAL_LABEL_PREFIX: Instruction Output. (line 151) 55528* LOCAL_REGNO: Register Basics. (line 143) 55529* location information: Guidelines for Diagnostics. 55530 (line 183) 55531* log10M2 instruction pattern: Standard Names. (line 1064) 55532* log1pM2 instruction pattern: Standard Names. (line 1054) 55533* log2M2 instruction pattern: Standard Names. (line 1071) 55534* logbM2 instruction pattern: Standard Names. (line 1078) 55535* Logical Operators: Logical Operators. (line 6) 55536* logical-and, bitwise: Arithmetic. (line 158) 55537* LOGICAL_OP_NON_SHORT_CIRCUIT: Costs. (line 294) 55538* logM2 instruction pattern: Standard Names. (line 1047) 55539* LOG_LINKS: Insns. (line 337) 55540* longjmp and automatic variables: Interface. (line 52) 55541* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 92) 55542* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 57) 55543* LONG_FRACT_TYPE_SIZE: Type Layout. (line 72) 55544* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 97) 55545* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 77) 55546* LONG_LONG_TYPE_SIZE: Type Layout. (line 32) 55547* LONG_TYPE_SIZE: Type Layout. (line 21) 55548* Loop analysis: Loop representation. 55549 (line 6) 55550* Loop manipulation: Loop manipulation. (line 6) 55551* Loop querying: Loop querying. (line 6) 55552* Loop representation: Loop representation. 55553 (line 6) 55554* Loop-closed SSA form: LCSSA. (line 6) 55555* looping instruction patterns: Looping Patterns. (line 6) 55556* LOOP_ALIGN: Alignment Output. (line 29) 55557* LOOP_EXPR: Unary and Binary Expressions. 55558 (line 6) 55559* lowering, language-dependent intermediate representation: Parsing pass. 55560 (line 13) 55561* lo_sum: Arithmetic. (line 25) 55562* lrintMN2: Standard Names. (line 1160) 55563* lroundMN2: Standard Names. (line 1165) 55564* lshiftrt: Arithmetic. (line 190) 55565* lshiftrt and attributes: Expressions. (line 83) 55566* LSHIFT_EXPR: Unary and Binary Expressions. 55567 (line 6) 55568* lshrM3 instruction pattern: Standard Names. (line 878) 55569* lt: Comparisons. (line 68) 55570* lt and attributes: Expressions. (line 83) 55571* LTGT_EXPR: Unary and Binary Expressions. 55572 (line 6) 55573* lto: LTO. (line 6) 55574* ltrans: LTO. (line 6) 55575* ltu: Comparisons. (line 68) 55576* LT_EXPR: Unary and Binary Expressions. 55577 (line 6) 55578* m in constraint: Simple Constraints. (line 17) 55579* machine attributes: Target Attributes. (line 6) 55580* machine description macros: Target Macros. (line 6) 55581* machine descriptions: Machine Desc. (line 6) 55582* machine mode conversions: Conversions. (line 6) 55583* machine mode wrapper classes: Machine Modes. (line 291) 55584* machine modes: Machine Modes. (line 6) 55585* machine specific constraints: Machine Constraints. 55586 (line 6) 55587* machine-independent predicates: Machine-Independent Predicates. 55588 (line 6) 55589* machine_mode: Machine Modes. (line 6) 55590* MACH_DEP_SECTION_ASM_FLAG: Sections. (line 120) 55591* macros, target description: Target Macros. (line 6) 55592* maddMN4 instruction pattern: Standard Names. (line 799) 55593* makefile fragment: Fragments. (line 6) 55594* makefile targets: Makefile. (line 6) 55595* MAKE_DECL_ONE_ONLY: Label Output. (line 281) 55596* make_safe_from: Expander Definitions. 55597 (line 151) 55598* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 190) 55599* Manipulating GIMPLE statements: Manipulating GIMPLE statements. 55600 (line 6) 55601* marking roots: GGC Roots. (line 6) 55602* maskloadMN instruction pattern: Standard Names. (line 396) 55603* maskstoreMN instruction pattern: Standard Names. (line 403) 55604* mask_fold_left_plus_M instruction pattern: Standard Names. (line 588) 55605* mask_gather_loadMN instruction pattern: Standard Names. (line 249) 55606* MASK_RETURN_ADDR: Exception Region Output. 55607 (line 35) 55608* mask_scatter_storeMN instruction pattern: Standard Names. (line 272) 55609* Match and Simplify: Match and Simplify. (line 6) 55610* matching constraint: Simple Constraints. (line 140) 55611* matching operands: Output Template. (line 49) 55612* match_dup: RTL Template. (line 73) 55613* match_dup <1>: define_peephole2. (line 28) 55614* match_dup and attributes: Insn Lengths. (line 16) 55615* match_operand: RTL Template. (line 16) 55616* match_operand and attributes: Expressions. (line 55) 55617* match_operator: RTL Template. (line 95) 55618* match_op_dup: RTL Template. (line 163) 55619* match_parallel: RTL Template. (line 172) 55620* match_par_dup: RTL Template. (line 219) 55621* match_scratch: RTL Template. (line 58) 55622* match_scratch <1>: define_peephole2. (line 28) 55623* match_test and attributes: Expressions. (line 64) 55624* math library: Soft float library routines. 55625 (line 6) 55626* math, in RTL: Arithmetic. (line 6) 55627* matherr: Library Calls. (line 59) 55628* MATH_LIBRARY: Misc. (line 541) 55629* maxM3 instruction pattern: Standard Names. (line 527) 55630* MAX_BITSIZE_MODE_ANY_INT: Machine Modes. (line 449) 55631* MAX_BITSIZE_MODE_ANY_MODE: Machine Modes. (line 455) 55632* MAX_BITS_PER_WORD: Storage Layout. (line 54) 55633* MAX_CONDITIONAL_EXECUTE: Misc. (line 563) 55634* MAX_FIXED_MODE_SIZE: Storage Layout. (line 470) 55635* MAX_MOVE_MAX: Misc. (line 127) 55636* MAX_OFILE_ALIGNMENT: Storage Layout. (line 228) 55637* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42) 55638* MAX_STACK_ALIGNMENT: Storage Layout. (line 222) 55639* maybe_undef: GTY Options. (line 141) 55640* may_trap_p, tree_could_trap_p: Edges. (line 114) 55641* mcount: Profiling. (line 12) 55642* MD_EXEC_PREFIX: Driver. (line 271) 55643* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 93) 55644* MD_HANDLE_UNWABI: Exception Handling. (line 112) 55645* MD_STARTFILE_PREFIX: Driver. (line 299) 55646* MD_STARTFILE_PREFIX_1: Driver. (line 304) 55647* mem: Regs and Memory. (line 401) 55648* mem and /c: Flags. (line 70) 55649* mem and /f: Flags. (line 74) 55650* mem and /j: Flags. (line 59) 55651* mem and /u: Flags. (line 78) 55652* mem and /v: Flags. (line 65) 55653* mem, RTL sharing: Sharing. (line 43) 55654* memory model: Memory model. (line 6) 55655* memory reference, nonoffsettable: Simple Constraints. (line 254) 55656* memory references in constraints: Simple Constraints. (line 17) 55657* memory_barrier instruction pattern: Standard Names. (line 2371) 55658* memory_blockage instruction pattern: Standard Names. (line 2362) 55659* MEMORY_MOVE_COST: Costs. (line 53) 55660* memory_operand: Machine-Independent Predicates. 55661 (line 57) 55662* MEM_ADDR_SPACE: Special Accessors. (line 48) 55663* MEM_ALIAS_SET: Special Accessors. (line 9) 55664* MEM_ALIGN: Special Accessors. (line 45) 55665* MEM_EXPR: Special Accessors. (line 19) 55666* MEM_KEEP_ALIAS_SET_P: Flags. (line 59) 55667* MEM_NOTRAP_P: Flags. (line 70) 55668* MEM_OFFSET: Special Accessors. (line 31) 55669* MEM_OFFSET_KNOWN_P: Special Accessors. (line 27) 55670* MEM_POINTER: Flags. (line 74) 55671* MEM_READONLY_P: Flags. (line 78) 55672* MEM_REF: Storage References. (line 6) 55673* MEM_SIZE: Special Accessors. (line 39) 55674* MEM_SIZE_KNOWN_P: Special Accessors. (line 35) 55675* mem_thread_fence instruction pattern: Standard Names. (line 2661) 55676* MEM_VOLATILE_P: Flags. (line 65) 55677* METHOD_TYPE: Types. (line 6) 55678* MINIMUM_ALIGNMENT: Storage Layout. (line 338) 55679* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 198) 55680* minM3 instruction pattern: Standard Names. (line 527) 55681* minus: Arithmetic. (line 38) 55682* minus and attributes: Expressions. (line 83) 55683* minus, canonicalization of: Insn Canonicalizations. 55684 (line 27) 55685* MINUS_EXPR: Unary and Binary Expressions. 55686 (line 6) 55687* MIN_UNITS_PER_WORD: Storage Layout. (line 64) 55688* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 55689* miscellaneous register hooks: Miscellaneous Register Hooks. 55690 (line 6) 55691* mnemonic attribute: Mnemonic Attribute. (line 6) 55692* mod: Arithmetic. (line 136) 55693* mod and attributes: Expressions. (line 83) 55694* mode classes: Machine Modes. (line 226) 55695* mode iterators in .md files: Mode Iterators. (line 6) 55696* mode switching: Mode Switching. (line 6) 55697* MODE_ACCUM: Machine Modes. (line 256) 55698* MODE_BASE_REG_CLASS: Register Classes. (line 116) 55699* MODE_BASE_REG_REG_CLASS: Register Classes. (line 122) 55700* MODE_CC: Machine Modes. (line 271) 55701* MODE_CC <1>: MODE_CC Condition Codes. 55702 (line 6) 55703* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 129) 55704* MODE_COMPLEX_FLOAT: Machine Modes. (line 267) 55705* MODE_COMPLEX_INT: Machine Modes. (line 264) 55706* MODE_DECIMAL_FLOAT: Machine Modes. (line 244) 55707* MODE_FLOAT: Machine Modes. (line 240) 55708* MODE_FRACT: Machine Modes. (line 248) 55709* MODE_INT: Machine Modes. (line 232) 55710* MODE_OPAQUE: Machine Modes. (line 281) 55711* MODE_PARTIAL_INT: Machine Modes. (line 236) 55712* MODE_POINTER_BOUNDS: Machine Modes. (line 276) 55713* MODE_RANDOM: Machine Modes. (line 286) 55714* MODE_UACCUM: Machine Modes. (line 260) 55715* MODE_UFRACT: Machine Modes. (line 252) 55716* modifiers in constraints: Modifiers. (line 6) 55717* MODIFY_EXPR: Unary and Binary Expressions. 55718 (line 6) 55719* modM3 instruction pattern: Standard Names. (line 466) 55720* modulo scheduling: RTL passes. (line 123) 55721* MOVE_MAX: Misc. (line 122) 55722* MOVE_MAX_PIECES: Costs. (line 210) 55723* MOVE_RATIO: Costs. (line 149) 55724* movM instruction pattern: Standard Names. (line 11) 55725* movmemM instruction pattern: Standard Names. (line 1480) 55726* movmisalignM instruction pattern: Standard Names. (line 125) 55727* movMODEcc instruction pattern: Standard Names. (line 1775) 55728* movstr instruction pattern: Standard Names. (line 1516) 55729* movstrictM instruction pattern: Standard Names. (line 119) 55730* msubMN4 instruction pattern: Standard Names. (line 822) 55731* mulhisi3 instruction pattern: Standard Names. (line 775) 55732* mulM3 instruction pattern: Standard Names. (line 466) 55733* mulqihi3 instruction pattern: Standard Names. (line 779) 55734* mulsidi3 instruction pattern: Standard Names. (line 779) 55735* mult: Arithmetic. (line 93) 55736* mult and attributes: Expressions. (line 83) 55737* mult, canonicalization of: Insn Canonicalizations. 55738 (line 27) 55739* mult, canonicalization of <1>: Insn Canonicalizations. 55740 (line 107) 55741* MULTIARCH_DIRNAME: Target Fragment. (line 173) 55742* MULTILIB_DEFAULTS: Driver. (line 256) 55743* MULTILIB_DIRNAMES: Target Fragment. (line 44) 55744* MULTILIB_EXCEPTIONS: Target Fragment. (line 70) 55745* MULTILIB_EXTRA_OPTS: Target Fragment. (line 135) 55746* MULTILIB_MATCHES: Target Fragment. (line 63) 55747* MULTILIB_OPTIONS: Target Fragment. (line 24) 55748* MULTILIB_OSDIRNAMES: Target Fragment. (line 142) 55749* MULTILIB_REQUIRED: Target Fragment. (line 82) 55750* MULTILIB_REUSE: Target Fragment. (line 103) 55751* multiple alternative constraints: Multi-Alternative. (line 6) 55752* MULTIPLE_SYMBOL_SPACES: Misc. (line 517) 55753* multiplication: Arithmetic. (line 93) 55754* multiplication with signed saturation: Arithmetic. (line 93) 55755* multiplication with unsigned saturation: Arithmetic. (line 93) 55756* MULT_EXPR: Unary and Binary Expressions. 55757 (line 6) 55758* MULT_HIGHPART_EXPR: Unary and Binary Expressions. 55759 (line 6) 55760* mulvM4 instruction pattern: Standard Names. (line 482) 55761* n in constraint: Simple Constraints. (line 73) 55762* name: Identifiers. (line 6) 55763* named address spaces: Named Address Spaces. 55764 (line 6) 55765* named patterns and conditions: Patterns. (line 61) 55766* names, pattern: Standard Names. (line 6) 55767* namespace, scope: Namespaces. (line 6) 55768* NAMESPACE_DECL: Declarations. (line 6) 55769* NAMESPACE_DECL <1>: Namespaces. (line 6) 55770* NATIVE_SYSTEM_HEADER_COMPONENT: Driver. (line 326) 55771* ne: Comparisons. (line 56) 55772* ne and attributes: Expressions. (line 83) 55773* nearbyintM2 instruction pattern: Standard Names. (line 1144) 55774* neg: Arithmetic. (line 82) 55775* neg and attributes: Expressions. (line 83) 55776* neg, canonicalization of: Insn Canonicalizations. 55777 (line 27) 55778* NEGATE_EXPR: Unary and Binary Expressions. 55779 (line 6) 55780* negation: Arithmetic. (line 82) 55781* negation with signed saturation: Arithmetic. (line 82) 55782* negation with unsigned saturation: Arithmetic. (line 82) 55783* negM2 instruction pattern: Standard Names. (line 910) 55784* negMODEcc instruction pattern: Standard Names. (line 1844) 55785* negvM3 instruction pattern: Standard Names. (line 913) 55786* nested functions, support for: Trampolines. (line 6) 55787* nested_ptr: GTY Options. (line 149) 55788* next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks. (line 25) 55789* NEXT_INSN: Insns. (line 30) 55790* NEXT_OBJC_RUNTIME: Library Calls. (line 89) 55791* NE_EXPR: Unary and Binary Expressions. 55792 (line 6) 55793* nil: RTL Objects. (line 73) 55794* NM_FLAGS: Macros for Initialization. 55795 (line 110) 55796* nondeterministic finite state automaton: Processor pipeline description. 55797 (line 304) 55798* nonimmediate_operand: Machine-Independent Predicates. 55799 (line 100) 55800* nonlocal goto handler: Edges. (line 171) 55801* nonlocal_goto instruction pattern: Standard Names. (line 2197) 55802* nonlocal_goto_receiver instruction pattern: Standard Names. 55803 (line 2214) 55804* nonmemory_operand: Machine-Independent Predicates. 55805 (line 96) 55806* nonoffsettable memory reference: Simple Constraints. (line 254) 55807* NON_LVALUE_EXPR: Unary and Binary Expressions. 55808 (line 6) 55809* nop instruction pattern: Standard Names. (line 2020) 55810* NOP_EXPR: Unary and Binary Expressions. 55811 (line 6) 55812* normal predicates: Predicates. (line 31) 55813* not: Arithmetic. (line 154) 55814* not and attributes: Expressions. (line 50) 55815* not equal: Comparisons. (line 56) 55816* not, canonicalization of: Insn Canonicalizations. 55817 (line 27) 55818* note: Insns. (line 183) 55819* note and /i: Flags. (line 48) 55820* note and /v: Flags. (line 33) 55821* NOTE_INSN_BASIC_BLOCK: Basic Blocks. (line 50) 55822* NOTE_INSN_BASIC_BLOCK <1>: Basic Blocks. (line 52) 55823* NOTE_INSN_BEGIN_STMT: Insns. (line 233) 55824* NOTE_INSN_BLOCK_BEG: Insns. (line 208) 55825* NOTE_INSN_BLOCK_END: Insns. (line 208) 55826* NOTE_INSN_DELETED: Insns. (line 198) 55827* NOTE_INSN_DELETED_LABEL: Insns. (line 203) 55828* NOTE_INSN_EH_REGION_BEG: Insns. (line 214) 55829* NOTE_INSN_EH_REGION_END: Insns. (line 214) 55830* NOTE_INSN_FUNCTION_BEG: Insns. (line 221) 55831* NOTE_INSN_INLINE_ENTRY: Insns. (line 238) 55832* NOTE_INSN_VAR_LOCATION: Insns. (line 225) 55833* NOTE_LINE_NUMBER: Insns. (line 183) 55834* NOTE_SOURCE_FILE: Insns. (line 183) 55835* NOTE_VAR_LOCATION: Insns. (line 225) 55836* NOTICE_UPDATE_CC: CC0 Condition Codes. 55837 (line 30) 55838* notMODEcc instruction pattern: Standard Names. (line 1851) 55839* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 25) 55840* NO_DBX_FUNCTION_END: DBX Hooks. (line 19) 55841* NO_DBX_GCC_MARKER: File Names and DBX. (line 27) 55842* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 22) 55843* NO_DOLLAR_IN_LABEL: Label Output. (line 64) 55844* NO_DOT_IN_LABEL: Label Output. (line 70) 55845* NO_FUNCTION_CSE: Costs. (line 289) 55846* NO_PROFILE_COUNTERS: Profiling. (line 27) 55847* NO_REGS: Register Classes. (line 17) 55848* Number of iterations analysis: Number of iterations. 55849 (line 6) 55850* NUM_MACHINE_MODES: Machine Modes. (line 388) 55851* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 55852* NUM_POLY_INT_COEFFS: Overview of poly_int. 55853 (line 24) 55854* N_REG_CLASSES: Register Classes. (line 81) 55855* o in constraint: Simple Constraints. (line 23) 55856* OACC_CACHE: OpenACC. (line 6) 55857* OACC_DATA: OpenACC. (line 6) 55858* OACC_DECLARE: OpenACC. (line 6) 55859* OACC_ENTER_DATA: OpenACC. (line 6) 55860* OACC_EXIT_DATA: OpenACC. (line 6) 55861* OACC_HOST_DATA: OpenACC. (line 6) 55862* OACC_KERNELS: OpenACC. (line 6) 55863* OACC_LOOP: OpenACC. (line 6) 55864* OACC_PARALLEL: OpenACC. (line 6) 55865* OACC_SERIAL: OpenACC. (line 6) 55866* OACC_UPDATE: OpenACC. (line 6) 55867* OBJC_GEN_METHOD_LABEL: Label Output. (line 482) 55868* OBJC_JBLEN: Misc. (line 1047) 55869* OBJECT_FORMAT_COFF: Macros for Initialization. 55870 (line 96) 55871* offsettable address: Simple Constraints. (line 23) 55872* OFFSET_TYPE: Types. (line 6) 55873* OImode: Machine Modes. (line 51) 55874* OMP_ATOMIC: OpenMP. (line 6) 55875* OMP_CLAUSE: OpenMP. (line 6) 55876* OMP_CONTINUE: OpenMP. (line 6) 55877* OMP_CRITICAL: OpenMP. (line 6) 55878* OMP_FOR: OpenMP. (line 6) 55879* OMP_MASTER: OpenMP. (line 6) 55880* OMP_ORDERED: OpenMP. (line 6) 55881* OMP_PARALLEL: OpenMP. (line 6) 55882* OMP_RETURN: OpenMP. (line 6) 55883* OMP_SECTION: OpenMP. (line 6) 55884* OMP_SECTIONS: OpenMP. (line 6) 55885* OMP_SINGLE: OpenMP. (line 6) 55886* one_cmplM2 instruction pattern: Standard Names. (line 1440) 55887* OPAQUE_TYPE: Types. (line 6) 55888* operand access: Accessors. (line 6) 55889* Operand Access Routines: SSA Operands. (line 116) 55890* operand constraints: Constraints. (line 6) 55891* Operand Iterators: SSA Operands. (line 116) 55892* operand predicates: Predicates. (line 6) 55893* operand substitution: Output Template. (line 6) 55894* Operands: Operands. (line 6) 55895* operands: SSA Operands. (line 6) 55896* operands <1>: Patterns. (line 67) 55897* operator predicates: Predicates. (line 6) 55898* optc-gen.awk: Options. (line 6) 55899* OPTGROUP_ALL: Optimization groups. 55900 (line 28) 55901* OPTGROUP_INLINE: Optimization groups. 55902 (line 15) 55903* OPTGROUP_IPA: Optimization groups. 55904 (line 9) 55905* OPTGROUP_LOOP: Optimization groups. 55906 (line 12) 55907* OPTGROUP_OMP: Optimization groups. 55908 (line 18) 55909* OPTGROUP_OTHER: Optimization groups. 55910 (line 24) 55911* OPTGROUP_VEC: Optimization groups. 55912 (line 21) 55913* optimization dumps: Optimization info. (line 6) 55914* optimization groups: Optimization groups. 55915 (line 6) 55916* optimization info file names: Dump files and streams. 55917 (line 6) 55918* Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 55919* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 8) 55920* option specification files: Options. (line 6) 55921* optional hardware or system features: Run-time Target. (line 59) 55922* options, directory search: Including Patterns. (line 47) 55923* options, guidelines for: Guidelines for Options. 55924 (line 6) 55925* OPTION_DEFAULT_SPECS: Driver. (line 25) 55926* opt_mode: Machine Modes. (line 327) 55927* order of register allocation: Allocation Order. (line 6) 55928* ordered_comparison_operator: Machine-Independent Predicates. 55929 (line 115) 55930* ORDERED_EXPR: Unary and Binary Expressions. 55931 (line 6) 55932* Ordering of Patterns: Pattern Ordering. (line 6) 55933* ORIGINAL_REGNO: Special Accessors. (line 53) 55934* other register constraints: Simple Constraints. (line 171) 55935* outgoing_args_size: Stack Arguments. (line 48) 55936* OUTGOING_REGNO: Register Basics. (line 136) 55937* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 79) 55938* output of assembler code: File Framework. (line 6) 55939* output statements: Output Statement. (line 6) 55940* output templates: Output Template. (line 6) 55941* output_asm_insn: Output Statement. (line 52) 55942* OUTPUT_QUOTED_STRING: File Framework. (line 105) 55943* OVERLAPPING_REGISTER_NAMES: Instruction Output. (line 20) 55944* OVERLOAD: Functions for C++. (line 6) 55945* OVERRIDE_ABI_FORMAT: Register Arguments. (line 150) 55946* OVL_CURRENT: Functions for C++. (line 6) 55947* OVL_NEXT: Functions for C++. (line 6) 55948* p in constraint: Simple Constraints. (line 162) 55949* PAD_VARARGS_DOWN: Register Arguments. (line 230) 55950* parallel: Side Effects. (line 210) 55951* parameters, c++ abi: C++ ABI. (line 6) 55952* parameters, d abi: D Language and ABI. (line 6) 55953* parameters, miscellaneous: Misc. (line 6) 55954* parameters, precompiled headers: PCH Target. (line 6) 55955* parity: Arithmetic. (line 242) 55956* parityM2 instruction pattern: Standard Names. (line 1427) 55957* PARM_BOUNDARY: Storage Layout. (line 150) 55958* PARM_DECL: Declarations. (line 6) 55959* PARSE_LDD_OUTPUT: Macros for Initialization. 55960 (line 125) 55961* pass dumps: Passes. (line 6) 55962* passes and files of the compiler: Passes. (line 6) 55963* passing arguments: Interface. (line 36) 55964* pass_duplicate_computed_gotos: Edges. (line 161) 55965* PATH_SEPARATOR: Filesystem. (line 31) 55966* PATTERN: Insns. (line 307) 55967* pattern conditions: Patterns. (line 55) 55968* pattern names: Standard Names. (line 6) 55969* Pattern Ordering: Pattern Ordering. (line 6) 55970* patterns: Patterns. (line 6) 55971* pc: Regs and Memory. (line 388) 55972* pc and attributes: Insn Lengths. (line 20) 55973* pc, RTL sharing: Sharing. (line 28) 55974* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 364) 55975* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 64) 55976* PC_REGNUM: Register Basics. (line 150) 55977* pc_rtx: Regs and Memory. (line 393) 55978* PDImode: Machine Modes. (line 40) 55979* peephole optimization, RTL representation: Side Effects. (line 244) 55980* peephole optimizer definitions: Peephole Definitions. 55981 (line 6) 55982* per-function data: Per-Function Data. (line 6) 55983* percent sign: Output Template. (line 6) 55984* PHI nodes: SSA. (line 31) 55985* phi nodes, RTL SSA: RTL SSA Phi Nodes. (line 6) 55986* PIC: PIC. (line 6) 55987* PIC_OFFSET_TABLE_REGNUM: PIC. (line 15) 55988* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 25) 55989* pipeline hazard recognizer: Processor pipeline description. 55990 (line 6) 55991* pipeline hazard recognizer <1>: Processor pipeline description. 55992 (line 53) 55993* Plugins: Plugins. (line 6) 55994* plus: Arithmetic. (line 14) 55995* plus and attributes: Expressions. (line 83) 55996* plus, canonicalization of: Insn Canonicalizations. 55997 (line 27) 55998* PLUS_EXPR: Unary and Binary Expressions. 55999 (line 6) 56000* Pmode: Misc. (line 365) 56001* pmode_register_operand: Machine-Independent Predicates. 56002 (line 34) 56003* pointer: Types. (line 6) 56004* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 76) 56005* POINTER_DIFF_EXPR: Unary and Binary Expressions. 56006 (line 6) 56007* POINTER_PLUS_EXPR: Unary and Binary Expressions. 56008 (line 6) 56009* POINTER_SIZE: Storage Layout. (line 70) 56010* POINTER_TYPE: Types. (line 6) 56011* polynomial integers: poly_int. (line 6) 56012* poly_int: poly_int. (line 6) 56013* poly_int, invariant range: Overview of poly_int. 56014 (line 31) 56015* poly_int, main typedefs: Overview of poly_int. 56016 (line 46) 56017* poly_int, runtime value: Overview of poly_int. 56018 (line 6) 56019* poly_int, template parameters: Overview of poly_int. 56020 (line 24) 56021* poly_int, use in target-independent code: Consequences of using poly_int. 56022 (line 32) 56023* poly_int, use in target-specific code: Consequences of using poly_int. 56024 (line 40) 56025* POLY_INT_CST: Constant expressions. 56026 (line 6) 56027* popcount: Arithmetic. (line 238) 56028* popcountM2 instruction pattern: Standard Names. (line 1415) 56029* pops_args: Function Entry. (line 111) 56030* pop_operand: Machine-Independent Predicates. 56031 (line 87) 56032* portability: Portability. (line 6) 56033* position independent code: PIC. (line 6) 56034* POSTDECREMENT_EXPR: Unary and Binary Expressions. 56035 (line 6) 56036* POSTINCREMENT_EXPR: Unary and Binary Expressions. 56037 (line 6) 56038* post_dec: Incdec. (line 25) 56039* post_inc: Incdec. (line 30) 56040* POST_LINK_SPEC: Driver. (line 236) 56041* post_modify: Incdec. (line 33) 56042* post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks. 56043 (line 34) 56044* POWI_MAX_MULTS: Misc. (line 932) 56045* powM3 instruction pattern: Standard Names. (line 1092) 56046* pragma: Misc. (line 422) 56047* PREDECREMENT_EXPR: Unary and Binary Expressions. 56048 (line 6) 56049* predefined macros: Run-time Target. (line 6) 56050* predicates: Predicates. (line 6) 56051* predicates and machine modes: Predicates. (line 31) 56052* predication: Conditional Execution. 56053 (line 6) 56054* predict.def: Profile information. 56055 (line 24) 56056* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 40) 56057* PREFERRED_RELOAD_CLASS: Register Classes. (line 249) 56058* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 164) 56059* prefetch: Side Effects. (line 324) 56060* prefetch and /v: Flags. (line 92) 56061* prefetch instruction pattern: Standard Names. (line 2339) 56062* PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 92) 56063* PREINCREMENT_EXPR: Unary and Binary Expressions. 56064 (line 6) 56065* presence_set: Processor pipeline description. 56066 (line 223) 56067* preserving SSA form: SSA. (line 74) 56068* pretend_args_size: Function Entry. (line 117) 56069* prev_active_insn: define_peephole. (line 60) 56070* PREV_INSN: Insns. (line 26) 56071* pre_dec: Incdec. (line 8) 56072* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 126) 56073* pre_inc: Incdec. (line 22) 56074* pre_modify: Incdec. (line 52) 56075* PRINT_OPERAND: Instruction Output. (line 95) 56076* PRINT_OPERAND_ADDRESS: Instruction Output. (line 122) 56077* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 115) 56078* probe_stack instruction pattern: Standard Names. (line 2189) 56079* probe_stack_address instruction pattern: Standard Names. (line 2182) 56080* processor functional units: Processor pipeline description. 56081 (line 6) 56082* processor functional units <1>: Processor pipeline description. 56083 (line 68) 56084* processor pipeline description: Processor pipeline description. 56085 (line 6) 56086* product: Arithmetic. (line 93) 56087* profile feedback: Profile information. 56088 (line 14) 56089* profile representation: Profile information. 56090 (line 6) 56091* PROFILE_BEFORE_PROLOGUE: Profiling. (line 34) 56092* PROFILE_HOOK: Profiling. (line 22) 56093* profiling, code generation: Profiling. (line 6) 56094* program counter: Regs and Memory. (line 389) 56095* prologue: Function Entry. (line 6) 56096* prologue instruction pattern: Standard Names. (line 2278) 56097* PROMOTE_MODE: Storage Layout. (line 87) 56098* pseudo registers: Regs and Memory. (line 9) 56099* PSImode: Machine Modes. (line 32) 56100* PTRDIFF_TYPE: Type Layout. (line 157) 56101* purge_dead_edges: Edges. (line 103) 56102* purge_dead_edges <1>: Maintaining the CFG. 56103 (line 81) 56104* push address instruction: Simple Constraints. (line 162) 56105* pushM1 instruction pattern: Standard Names. (line 453) 56106* PUSH_ARGS: Stack Arguments. (line 17) 56107* PUSH_ARGS_REVERSED: Stack Arguments. (line 25) 56108* push_operand: Machine-Independent Predicates. 56109 (line 80) 56110* push_reload: Addressing Modes. (line 176) 56111* PUSH_ROUNDING: Stack Arguments. (line 31) 56112* PUT_CODE: RTL Objects. (line 47) 56113* PUT_MODE: Machine Modes. (line 385) 56114* PUT_REG_NOTE_KIND: Insns. (line 369) 56115* QCmode: Machine Modes. (line 199) 56116* QFmode: Machine Modes. (line 57) 56117* QImode: Machine Modes. (line 25) 56118* QImode, in insn: Insns. (line 291) 56119* QQmode: Machine Modes. (line 106) 56120* qualified type: Types. (line 6) 56121* qualified type <1>: Types for C++. (line 6) 56122* querying function unit reservations: Processor pipeline description. 56123 (line 90) 56124* question mark: Multi-Alternative. (line 42) 56125* quotient: Arithmetic. (line 116) 56126* r in constraint: Simple Constraints. (line 64) 56127* RDIV_EXPR: Unary and Binary Expressions. 56128 (line 6) 56129* READONLY_DATA_SECTION_ASM_OP: Sections. (line 62) 56130* real operands: SSA Operands. (line 6) 56131* REALPART_EXPR: Unary and Binary Expressions. 56132 (line 6) 56133* REAL_CST: Constant expressions. 56134 (line 6) 56135* REAL_LIBGCC_SPEC: Driver. (line 124) 56136* REAL_NM_FILE_NAME: Macros for Initialization. 56137 (line 105) 56138* REAL_TYPE: Types. (line 6) 56139* REAL_VALUE_ABS: Floating Point. (line 58) 56140* REAL_VALUE_ATOF: Floating Point. (line 39) 56141* REAL_VALUE_FIX: Floating Point. (line 31) 56142* REAL_VALUE_ISINF: Floating Point. (line 49) 56143* REAL_VALUE_ISNAN: Floating Point. (line 52) 56144* REAL_VALUE_NEGATE: Floating Point. (line 55) 56145* REAL_VALUE_NEGATIVE: Floating Point. (line 46) 56146* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 153) 56147* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 151) 56148* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 152) 56149* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 149) 56150* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 150) 56151* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 148) 56152* REAL_VALUE_TYPE: Floating Point. (line 25) 56153* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 34) 56154* recognizing insns: RTL Template. (line 6) 56155* recog_data.operand: Instruction Output. (line 54) 56156* RECORD_TYPE: Types. (line 6) 56157* RECORD_TYPE <1>: Classes. (line 6) 56158* redirect_edge_and_branch: Profile information. 56159 (line 71) 56160* redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 56161 (line 89) 56162* reduc_and_scal_M instruction pattern: Standard Names. (line 559) 56163* reduc_ior_scal_M instruction pattern: Standard Names. (line 560) 56164* reduc_plus_scal_M instruction pattern: Standard Names. (line 554) 56165* reduc_smax_scal_M instruction pattern: Standard Names. (line 544) 56166* reduc_smin_scal_M instruction pattern: Standard Names. (line 544) 56167* reduc_umax_scal_M instruction pattern: Standard Names. (line 549) 56168* reduc_umin_scal_M instruction pattern: Standard Names. (line 549) 56169* reduc_xor_scal_M instruction pattern: Standard Names. (line 561) 56170* reference: Types. (line 6) 56171* REFERENCE_TYPE: Types. (line 6) 56172* reg: Regs and Memory. (line 9) 56173* reg and /f: Flags. (line 102) 56174* reg and /i: Flags. (line 97) 56175* reg and /v: Flags. (line 106) 56176* reg, RTL sharing: Sharing. (line 17) 56177* register allocation order: Allocation Order. (line 6) 56178* register class definitions: Register Classes. (line 6) 56179* register class preference constraints: Class Preferences. (line 6) 56180* register pairs: Values in Registers. 56181 (line 65) 56182* Register Transfer Language (RTL): RTL. (line 6) 56183* register usage: Registers. (line 6) 56184* registers arguments: Register Arguments. (line 6) 56185* registers in constraints: Simple Constraints. (line 64) 56186* REGISTER_MOVE_COST: Costs. (line 9) 56187* REGISTER_NAMES: Instruction Output. (line 8) 56188* register_operand: Machine-Independent Predicates. 56189 (line 29) 56190* REGISTER_PREFIX: Instruction Output. (line 150) 56191* REGISTER_TARGET_PRAGMAS: Misc. (line 422) 56192* REGMODE_NATURAL_SIZE: Regs and Memory. (line 191) 56193* REGMODE_NATURAL_SIZE <1>: Regs and Memory. (line 273) 56194* REGMODE_NATURAL_SIZE <2>: Values in Registers. 56195 (line 46) 56196* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 172) 56197* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 150) 56198* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 160) 56199* REGNO_OK_FOR_BASE_P: Register Classes. (line 146) 56200* REGNO_OK_FOR_INDEX_P: Register Classes. (line 186) 56201* REGNO_REG_CLASS: Register Classes. (line 105) 56202* regs_ever_live: Function Entry. (line 29) 56203* regular expressions: Processor pipeline description. 56204 (line 6) 56205* regular expressions <1>: Processor pipeline description. 56206 (line 105) 56207* regular IPA passes: Regular IPA passes. (line 6) 56208* REG_ALLOC_ORDER: Allocation Order. (line 8) 56209* REG_BR_PRED: Insns. (line 541) 56210* REG_BR_PROB: Insns. (line 533) 56211* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 56212 (line 82) 56213* REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 56214 (line 52) 56215* REG_CALL_NOCF_CHECK: Insns. (line 557) 56216* REG_CC_SETTER: Insns. (line 505) 56217* REG_CC_USER: Insns. (line 505) 56218* reg_class_contents: Register Basics. (line 102) 56219* REG_CLASS_CONTENTS: Register Classes. (line 91) 56220* reg_class_for_constraint: C Constraint Interface. 56221 (line 48) 56222* REG_CLASS_NAMES: Register Classes. (line 86) 56223* REG_DEAD: Insns. (line 380) 56224* REG_DEAD, REG_UNUSED: Liveness information. 56225 (line 32) 56226* REG_DEP_ANTI: Insns. (line 527) 56227* REG_DEP_OUTPUT: Insns. (line 523) 56228* REG_DEP_TRUE: Insns. (line 520) 56229* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 109) 56230* REG_EQUAL: Insns. (line 434) 56231* REG_EQUIV: Insns. (line 434) 56232* REG_EXPR: Special Accessors. (line 58) 56233* REG_FRAME_RELATED_EXPR: Insns. (line 547) 56234* REG_FUNCTION_VALUE_P: Flags. (line 97) 56235* REG_INC: Insns. (line 396) 56236* reg_label and /v: Flags. (line 54) 56237* REG_LABEL_OPERAND: Insns. (line 410) 56238* REG_LABEL_TARGET: Insns. (line 419) 56239* reg_names: Register Basics. (line 102) 56240* reg_names <1>: Instruction Output. (line 107) 56241* REG_NONNEG: Insns. (line 402) 56242* REG_NOTES: Insns. (line 344) 56243* REG_NOTE_KIND: Insns. (line 369) 56244* REG_OFFSET: Special Accessors. (line 62) 56245* REG_OK_STRICT: Addressing Modes. (line 99) 56246* REG_PARM_STACK_SPACE: Stack Arguments. (line 58) 56247* REG_PARM_STACK_SPACE, and TARGET_FUNCTION_ARG: Register Arguments. 56248 (line 49) 56249* REG_POINTER: Flags. (line 102) 56250* REG_SETJMP: Insns. (line 428) 56251* REG_UNUSED: Insns. (line 389) 56252* REG_USERVAR_P: Flags. (line 106) 56253* REG_VALUE_IN_UNWIND_CONTEXT: Frame Registers. (line 156) 56254* REG_WORDS_BIG_ENDIAN: Storage Layout. (line 35) 56255* relative costs: Costs. (line 6) 56256* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 266) 56257* reloading: RTL passes. (line 170) 56258* reload_completed: Standard Names. (line 1987) 56259* reload_in instruction pattern: Standard Names. (line 98) 56260* reload_in_progress: Standard Names. (line 57) 56261* reload_out instruction pattern: Standard Names. (line 98) 56262* remainder: Arithmetic. (line 136) 56263* remainderM3 instruction pattern: Standard Names. (line 946) 56264* reorder: GTY Options. (line 175) 56265* representation of RTL: RTL. (line 6) 56266* reservation delays: Processor pipeline description. 56267 (line 6) 56268* restore_stack_block instruction pattern: Standard Names. (line 2103) 56269* restore_stack_function instruction pattern: Standard Names. 56270 (line 2103) 56271* restore_stack_nonlocal instruction pattern: Standard Names. 56272 (line 2103) 56273* rest_of_decl_compilation: Parsing pass. (line 51) 56274* rest_of_type_compilation: Parsing pass. (line 51) 56275* RESULT_DECL: Declarations. (line 6) 56276* return: Side Effects. (line 72) 56277* return instruction pattern: Standard Names. (line 1961) 56278* return values in registers: Scalar Return. (line 6) 56279* returning aggregate values: Aggregate Return. (line 6) 56280* returning structures and unions: Interface. (line 10) 56281* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 64) 56282* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 127) 56283* RETURN_ADDR_OFFSET: Exception Handling. (line 59) 56284* RETURN_ADDR_RTX: Frame Layout. (line 116) 56285* RETURN_EXPR: Statements for C and C++. 56286 (line 6) 56287* RETURN_STMT: Statements for C and C++. 56288 (line 6) 56289* return_val: Flags. (line 283) 56290* return_val, in call_insn: Flags. (line 120) 56291* return_val, in reg: Flags. (line 97) 56292* return_val, in symbol_ref: Flags. (line 216) 56293* reverse postorder: RTL SSA Instructions. 56294 (line 6) 56295* reverse probability: Profile information. 56296 (line 66) 56297* REVERSE_CONDITION: MODE_CC Condition Codes. 56298 (line 92) 56299* REVERSIBLE_CC_MODE: MODE_CC Condition Codes. 56300 (line 77) 56301* right rotate: Arithmetic. (line 195) 56302* right shift: Arithmetic. (line 190) 56303* rintM2 instruction pattern: Standard Names. (line 1152) 56304* RISC: Processor pipeline description. 56305 (line 6) 56306* RISC <1>: Processor pipeline description. 56307 (line 223) 56308* roots, marking: GGC Roots. (line 6) 56309* rotate: Arithmetic. (line 195) 56310* rotate <1>: Arithmetic. (line 195) 56311* rotatert: Arithmetic. (line 195) 56312* rotlM3 instruction pattern: Standard Names. (line 878) 56313* rotrM3 instruction pattern: Standard Names. (line 878) 56314* roundM2 instruction pattern: Standard Names. (line 1125) 56315* ROUND_DIV_EXPR: Unary and Binary Expressions. 56316 (line 6) 56317* ROUND_MOD_EXPR: Unary and Binary Expressions. 56318 (line 6) 56319* ROUND_TYPE_ALIGN: Storage Layout. (line 461) 56320* RPO: RTL SSA Instructions. 56321 (line 6) 56322* RSHIFT_EXPR: Unary and Binary Expressions. 56323 (line 6) 56324* rsqrtM2 instruction pattern: Standard Names. (line 926) 56325* RTL addition: Arithmetic. (line 14) 56326* RTL addition with signed saturation: Arithmetic. (line 14) 56327* RTL addition with unsigned saturation: Arithmetic. (line 14) 56328* RTL classes: RTL Classes. (line 6) 56329* RTL comparison: Arithmetic. (line 46) 56330* RTL comparison operations: Comparisons. (line 6) 56331* RTL constant expression types: Constants. (line 6) 56332* RTL constants: Constants. (line 6) 56333* RTL declarations: RTL Declarations. (line 6) 56334* RTL difference: Arithmetic. (line 38) 56335* RTL expression: RTL Objects. (line 6) 56336* RTL expressions for arithmetic: Arithmetic. (line 6) 56337* RTL format: RTL Classes. (line 73) 56338* RTL format characters: RTL Classes. (line 78) 56339* RTL function-call insns: Calls. (line 6) 56340* RTL insn template: RTL Template. (line 6) 56341* RTL integers: RTL Objects. (line 6) 56342* RTL memory expressions: Regs and Memory. (line 6) 56343* RTL object types: RTL Objects. (line 6) 56344* RTL postdecrement: Incdec. (line 6) 56345* RTL postincrement: Incdec. (line 6) 56346* RTL predecrement: Incdec. (line 6) 56347* RTL preincrement: Incdec. (line 6) 56348* RTL register expressions: Regs and Memory. (line 6) 56349* RTL representation: RTL. (line 6) 56350* RTL side effect expressions: Side Effects. (line 6) 56351* RTL SSA: RTL SSA. (line 6) 56352* RTL strings: RTL Objects. (line 6) 56353* RTL structure sharing assumptions: Sharing. (line 6) 56354* RTL subtraction: Arithmetic. (line 38) 56355* RTL subtraction with signed saturation: Arithmetic. (line 38) 56356* RTL subtraction with unsigned saturation: Arithmetic. (line 38) 56357* RTL sum: Arithmetic. (line 14) 56358* RTL vectors: RTL Objects. (line 6) 56359* RTL_CONST_CALL_P: Flags. (line 115) 56360* RTL_CONST_OR_PURE_CALL_P: Flags. (line 125) 56361* RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 129) 56362* RTL_PURE_CALL_P: Flags. (line 120) 56363* rtl_ssa::access_info: RTL SSA Accesses. (line 10) 56364* rtl_ssa::bb_info: RTL SSA Basic Blocks. 56365 (line 6) 56366* rtl_ssa::clobber_info: RTL SSA Accesses. (line 10) 56367* rtl_ssa::def_info: RTL SSA Accesses. (line 10) 56368* rtl_ssa::ebb_info: RTL SSA Basic Blocks. 56369 (line 29) 56370* rtl_ssa::insn_change: Changing RTL Instructions. 56371 (line 6) 56372* rtl_ssa::insn_info: RTL SSA Instructions. 56373 (line 6) 56374* rtl_ssa::phi_info: RTL SSA Accesses. (line 10) 56375* rtl_ssa::phi_info <1>: RTL SSA Phi Nodes. (line 6) 56376* rtl_ssa::set_info: RTL SSA Accesses. (line 10) 56377* rtl_ssa::use_info: RTL SSA Accesses. (line 10) 56378* RTX (See RTL): RTL Objects. (line 6) 56379* RTX codes, classes of: RTL Classes. (line 6) 56380* RTX_FRAME_RELATED_P: Flags. (line 135) 56381* run-time conventions: Interface. (line 6) 56382* run-time target specification: Run-time Target. (line 6) 56383* s in constraint: Simple Constraints. (line 100) 56384* SAD_EXPR: Vectors. (line 6) 56385* same_type_p: Types. (line 86) 56386* SAmode: Machine Modes. (line 150) 56387* satfractMN2 instruction pattern: Standard Names. (line 1663) 56388* satfractunsMN2 instruction pattern: Standard Names. (line 1676) 56389* satisfies_constraint_M: C Constraint Interface. 56390 (line 36) 56391* sat_fract: Conversions. (line 90) 56392* SAVE_EXPR: Unary and Binary Expressions. 56393 (line 6) 56394* save_stack_block instruction pattern: Standard Names. (line 2103) 56395* save_stack_function instruction pattern: Standard Names. (line 2103) 56396* save_stack_nonlocal instruction pattern: Standard Names. (line 2103) 56397* SBSS_SECTION_ASM_OP: Sections. (line 75) 56398* Scalar evolutions: Scalar evolutions. (line 6) 56399* scalars, returned as values: Scalar Return. (line 6) 56400* scalar_float_mode: Machine Modes. (line 298) 56401* scalar_int_mode: Machine Modes. (line 295) 56402* scalar_mode: Machine Modes. (line 301) 56403* scalbM3 instruction pattern: Standard Names. (line 953) 56404* scatter_storeMN instruction pattern: Standard Names. (line 255) 56405* SCHED_GROUP_P: Flags. (line 162) 56406* SCmode: Machine Modes. (line 199) 56407* scratch: Regs and Memory. (line 325) 56408* scratch operands: Regs and Memory. (line 325) 56409* scratch, RTL sharing: Sharing. (line 38) 56410* scratch_operand: Machine-Independent Predicates. 56411 (line 49) 56412* SDATA_SECTION_ASM_OP: Sections. (line 57) 56413* sdiv_pow2M3 instruction pattern: Standard Names. (line 638) 56414* sdiv_pow2M3 instruction pattern <1>: Standard Names. (line 639) 56415* SDmode: Machine Modes. (line 88) 56416* sdot_prodM instruction pattern: Standard Names. (line 593) 56417* search options: Including Patterns. (line 47) 56418* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 391) 56419* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 457) 56420* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 392) 56421* SECONDARY_RELOAD_CLASS: Register Classes. (line 390) 56422* SELECT_CC_MODE: MODE_CC Condition Codes. 56423 (line 6) 56424* sequence: Side Effects. (line 259) 56425* Sequence iterators: Sequence iterators. (line 6) 56426* set: Side Effects. (line 15) 56427* set and /f: Flags. (line 135) 56428* setmemM instruction pattern: Standard Names. (line 1527) 56429* SETUP_FRAME_ADDRESSES: Frame Layout. (line 94) 56430* SET_ASM_OP: Label Output. (line 451) 56431* SET_ASM_OP <1>: Label Output. (line 462) 56432* set_attr: Tagging Insns. (line 31) 56433* set_attr_alternative: Tagging Insns. (line 49) 56434* set_bb_seq: GIMPLE sequences. (line 75) 56435* SET_DEST: Side Effects. (line 69) 56436* SET_IS_RETURN_P: Flags. (line 171) 56437* SET_LABEL_KIND: Insns. (line 146) 56438* set_optab_libfunc: Library Calls. (line 15) 56439* SET_RATIO: Costs. (line 237) 56440* SET_SRC: Side Effects. (line 69) 56441* set_thread_pointerMODE instruction pattern: Standard Names. 56442 (line 2676) 56443* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6) 56444* SET_TYPE_STRUCTURAL_EQUALITY <1>: Types. (line 81) 56445* SFmode: Machine Modes. (line 69) 56446* sharing of RTL components: Sharing. (line 6) 56447* shift: Arithmetic. (line 173) 56448* SHIFT_COUNT_TRUNCATED: Misc. (line 134) 56449* SHLIB_SUFFIX: Macros for Initialization. 56450 (line 133) 56451* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 82) 56452* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 62) 56453* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 108) 56454* SHORT_TYPE_SIZE: Type Layout. (line 15) 56455* shrink-wrapping separate components: Shrink-wrapping separate components. 56456 (line 6) 56457* sibcall_epilogue instruction pattern: Standard Names. (line 2310) 56458* sibling call: Edges. (line 121) 56459* SIBLING_CALL_P: Flags. (line 175) 56460* signal-to-noise ratio (metaphorical usage for diagnostics): Guidelines for Diagnostics. 56461 (line 39) 56462* signed division: Arithmetic. (line 116) 56463* signed division with signed saturation: Arithmetic. (line 116) 56464* signed maximum: Arithmetic. (line 141) 56465* signed minimum: Arithmetic. (line 141) 56466* significandM2 instruction pattern: Standard Names. (line 1085) 56467* sign_extend: Conversions. (line 23) 56468* sign_extract: Bit-Fields. (line 8) 56469* sign_extract, canonicalization of: Insn Canonicalizations. 56470 (line 103) 56471* SIG_ATOMIC_TYPE: Type Layout. (line 208) 56472* SImode: Machine Modes. (line 37) 56473* simple constraints: Simple Constraints. (line 6) 56474* simple_return: Side Effects. (line 86) 56475* simple_return instruction pattern: Standard Names. (line 1976) 56476* sincosM3 instruction pattern: Standard Names. (line 981) 56477* sinM2 instruction pattern: Standard Names. (line 975) 56478* SIZETYPE: Type Layout. (line 147) 56479* SIZE_ASM_OP: Label Output. (line 33) 56480* SIZE_TYPE: Type Layout. (line 131) 56481* skip: GTY Options. (line 76) 56482* SLOW_BYTE_ACCESS: Costs. (line 117) 56483* small IPA passes: Small IPA passes. (line 6) 56484* smax: Arithmetic. (line 141) 56485* smin: Arithmetic. (line 141) 56486* sms, swing, software pipelining: RTL passes. (line 123) 56487* smulhrsM3 instruction pattern: Standard Names. (line 628) 56488* smulhsM3 instruction pattern: Standard Names. (line 618) 56489* smulM3_highpart instruction pattern: Standard Names. (line 791) 56490* soft float library: Soft float library routines. 56491 (line 6) 56492* source code, location information: Guidelines for Diagnostics. 56493 (line 183) 56494* special: GTY Options. (line 238) 56495* special predicates: Predicates. (line 31) 56496* SPECS: Target Fragment. (line 194) 56497* speculation_barrier instruction pattern: Standard Names. (line 2377) 56498* speed of instructions: Costs. (line 6) 56499* splitting instructions: Insn Splitting. (line 6) 56500* split_block: Maintaining the CFG. 56501 (line 96) 56502* SQmode: Machine Modes. (line 114) 56503* sqrt: Arithmetic. (line 206) 56504* sqrtM2 instruction pattern: Standard Names. (line 920) 56505* square root: Arithmetic. (line 206) 56506* SSA: SSA. (line 6) 56507* SSA, RTL form: RTL SSA. (line 6) 56508* ssaddM3 instruction pattern: Standard Names. (line 466) 56509* ssadM instruction pattern: Standard Names. (line 602) 56510* ssashlM3 instruction pattern: Standard Names. (line 866) 56511* SSA_NAME_DEF_STMT: SSA. (line 184) 56512* SSA_NAME_VERSION: SSA. (line 189) 56513* ssdivM3 instruction pattern: Standard Names. (line 466) 56514* ssmaddMN4 instruction pattern: Standard Names. (line 814) 56515* ssmsubMN4 instruction pattern: Standard Names. (line 838) 56516* ssmulM3 instruction pattern: Standard Names. (line 466) 56517* ssnegM2 instruction pattern: Standard Names. (line 910) 56518* sssubM3 instruction pattern: Standard Names. (line 466) 56519* ss_abs: Arithmetic. (line 200) 56520* ss_ashift: Arithmetic. (line 173) 56521* ss_div: Arithmetic. (line 116) 56522* ss_minus: Arithmetic. (line 38) 56523* ss_mult: Arithmetic. (line 93) 56524* ss_neg: Arithmetic. (line 82) 56525* ss_plus: Arithmetic. (line 14) 56526* ss_truncate: Conversions. (line 43) 56527* stack arguments: Stack Arguments. (line 6) 56528* stack frame layout: Frame Layout. (line 6) 56529* stack smashing protection: Stack Smashing Protection. 56530 (line 6) 56531* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 41) 56532* STACK_BOUNDARY: Storage Layout. (line 156) 56533* STACK_CHECK_BUILTIN: Stack Checking. (line 31) 56534* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 83) 56535* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 74) 56536* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 90) 56537* STACK_CHECK_MOVING_SP: Stack Checking. (line 53) 56538* STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 45) 56539* STACK_CHECK_PROTECT: Stack Checking. (line 62) 56540* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 38) 56541* STACK_DYNAMIC_OFFSET: Frame Layout. (line 67) 56542* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 56543 (line 83) 56544* STACK_GROWS_DOWNWARD: Frame Layout. (line 8) 56545* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 89) 56546* STACK_POINTER_OFFSET: Frame Layout. (line 51) 56547* STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 56548 (line 93) 56549* STACK_POINTER_REGNUM: Frame Registers. (line 8) 56550* STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 56551 (line 83) 56552* stack_pointer_rtx: Frame Registers. (line 104) 56553* stack_protect_combined_set instruction pattern: Standard Names. 56554 (line 2686) 56555* stack_protect_combined_test instruction pattern: Standard Names. 56556 (line 2716) 56557* stack_protect_set instruction pattern: Standard Names. (line 2702) 56558* stack_protect_test instruction pattern: Standard Names. (line 2733) 56559* STACK_PUSH_CODE: Frame Layout. (line 12) 56560* STACK_REGS: Stack Registers. (line 19) 56561* STACK_REG_COVER_CLASS: Stack Registers. (line 22) 56562* STACK_SAVEAREA_MODE: Storage Layout. (line 477) 56563* STACK_SIZE_MODE: Storage Layout. (line 488) 56564* STACK_SLOT_ALIGNMENT: Storage Layout. (line 309) 56565* standard pattern names: Standard Names. (line 6) 56566* STANDARD_STARTFILE_PREFIX: Driver. (line 278) 56567* STANDARD_STARTFILE_PREFIX_1: Driver. (line 285) 56568* STANDARD_STARTFILE_PREFIX_2: Driver. (line 292) 56569* STARTFILE_SPEC: Driver. (line 147) 56570* Statement and operand traversals: Statement and operand traversals. 56571 (line 6) 56572* Statement Sequences: Statement Sequences. 56573 (line 6) 56574* Statements: Statements. (line 6) 56575* statements: Function Properties. 56576 (line 6) 56577* statements <1>: Statements for C and C++. 56578 (line 6) 56579* static analysis: Static Analyzer. (line 6) 56580* static analyzer: Static Analyzer. (line 6) 56581* static analyzer, debugging: Debugging the Analyzer. 56582 (line 5) 56583* static analyzer, internals: Analyzer Internals. (line 5) 56584* Static profile estimation: Profile information. 56585 (line 24) 56586* static single assignment: SSA. (line 6) 56587* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 77) 56588* STATIC_CHAIN_REGNUM: Frame Registers. (line 76) 56589* stdarg.h and register arguments: Register Arguments. (line 44) 56590* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 386) 56591* STMT_EXPR: Unary and Binary Expressions. 56592 (line 6) 56593* STMT_IS_FULL_EXPR_P: Statements for C and C++. 56594 (line 18) 56595* storage layout: Storage Layout. (line 6) 56596* STORE_FLAG_VALUE: Misc. (line 237) 56597* STORE_MAX_PIECES: Costs. (line 215) 56598* store_multiple instruction pattern: Standard Names. (line 159) 56599* strcpy: Storage Layout. (line 262) 56600* STRICT_ALIGNMENT: Storage Layout. (line 359) 56601* strict_low_part: RTL Declarations. (line 9) 56602* strict_memory_address_p: Addressing Modes. (line 186) 56603* STRING_CST: Constant expressions. 56604 (line 6) 56605* STRING_POOL_ADDRESS_P: Flags. (line 179) 56606* strlenM instruction pattern: Standard Names. (line 1598) 56607* structure value address: Aggregate Return. (line 6) 56608* structures, returning: Interface. (line 10) 56609* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 351) 56610* subM3 instruction pattern: Standard Names. (line 466) 56611* SUBOBJECT: Statements for C and C++. 56612 (line 6) 56613* SUBOBJECT_CLEANUP: Statements for C and C++. 56614 (line 6) 56615* subreg: Regs and Memory. (line 97) 56616* subreg and /s: Flags. (line 201) 56617* subreg and /u: Flags. (line 194) 56618* subreg and /u and /v: Flags. (line 184) 56619* subreg, in strict_low_part: RTL Declarations. (line 9) 56620* SUBREG_BYTE: Regs and Memory. (line 316) 56621* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 184) 56622* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 194) 56623* SUBREG_PROMOTED_VAR_P: Flags. (line 201) 56624* SUBREG_REG: Regs and Memory. (line 316) 56625* subst iterators in .md files: Subst Iterators. (line 6) 56626* subvM4 instruction pattern: Standard Names. (line 482) 56627* SUCCESS_EXIT_CODE: Host Misc. (line 12) 56628* support for nested functions: Trampolines. (line 6) 56629* SUPPORTS_INIT_PRIORITY: Macros for Initialization. 56630 (line 57) 56631* SUPPORTS_ONE_ONLY: Label Output. (line 290) 56632* SUPPORTS_WEAK: Label Output. (line 264) 56633* SWITCHABLE_TARGET: Run-time Target. (line 160) 56634* SWITCH_BODY: Statements for C and C++. 56635 (line 6) 56636* SWITCH_COND: Statements for C and C++. 56637 (line 6) 56638* SWITCH_STMT: Statements for C and C++. 56639 (line 6) 56640* symbolic label: Sharing. (line 20) 56641* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 117) 56642* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 99) 56643* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 92) 56644* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 113) 56645* SYMBOL_FLAG_LOCAL: Special Accessors. (line 95) 56646* SYMBOL_FLAG_SMALL: Special Accessors. (line 104) 56647* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 108) 56648* symbol_ref: Constants. (line 203) 56649* symbol_ref and /f: Flags. (line 179) 56650* symbol_ref and /i: Flags. (line 216) 56651* symbol_ref and /u: Flags. (line 19) 56652* symbol_ref and /v: Flags. (line 220) 56653* symbol_ref, RTL sharing: Sharing. (line 20) 56654* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 117) 56655* SYMBOL_REF_BLOCK: Special Accessors. (line 130) 56656* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 135) 56657* SYMBOL_REF_CONSTANT: Special Accessors. (line 78) 56658* SYMBOL_REF_DATA: Special Accessors. (line 82) 56659* SYMBOL_REF_DECL: Special Accessors. (line 67) 56660* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 99) 56661* SYMBOL_REF_FLAG: Flags. (line 220) 56662* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 291) 56663* SYMBOL_REF_FLAGS: Special Accessors. (line 86) 56664* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 92) 56665* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 113) 56666* SYMBOL_REF_LOCAL_P: Special Accessors. (line 95) 56667* SYMBOL_REF_SMALL_P: Special Accessors. (line 104) 56668* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 108) 56669* SYMBOL_REF_USED: Flags. (line 211) 56670* SYMBOL_REF_WEAK: Flags. (line 216) 56671* sync_addMODE instruction pattern: Standard Names. (line 2431) 56672* sync_andMODE instruction pattern: Standard Names. (line 2431) 56673* sync_compare_and_swapMODE instruction pattern: Standard Names. 56674 (line 2391) 56675* sync_iorMODE instruction pattern: Standard Names. (line 2431) 56676* sync_lock_releaseMODE instruction pattern: Standard Names. (line 2496) 56677* sync_lock_test_and_setMODE instruction pattern: Standard Names. 56678 (line 2470) 56679* sync_nandMODE instruction pattern: Standard Names. (line 2431) 56680* sync_new_addMODE instruction pattern: Standard Names. (line 2463) 56681* sync_new_andMODE instruction pattern: Standard Names. (line 2463) 56682* sync_new_iorMODE instruction pattern: Standard Names. (line 2463) 56683* sync_new_nandMODE instruction pattern: Standard Names. (line 2463) 56684* sync_new_subMODE instruction pattern: Standard Names. (line 2463) 56685* sync_new_xorMODE instruction pattern: Standard Names. (line 2463) 56686* sync_old_addMODE instruction pattern: Standard Names. (line 2446) 56687* sync_old_andMODE instruction pattern: Standard Names. (line 2446) 56688* sync_old_iorMODE instruction pattern: Standard Names. (line 2446) 56689* sync_old_nandMODE instruction pattern: Standard Names. (line 2446) 56690* sync_old_subMODE instruction pattern: Standard Names. (line 2446) 56691* sync_old_xorMODE instruction pattern: Standard Names. (line 2446) 56692* sync_subMODE instruction pattern: Standard Names. (line 2431) 56693* sync_xorMODE instruction pattern: Standard Names. (line 2431) 56694* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 176) 56695* SYSROOT_SUFFIX_SPEC: Driver. (line 171) 56696* SYSTEM_IMPLICIT_EXTERN_C: Misc. (line 417) 56697* t-TARGET: Target Fragment. (line 6) 56698* table jump: Basic Blocks. (line 67) 56699* tablejump instruction pattern: Standard Names. (line 2049) 56700* tag: GTY Options. (line 90) 56701* tagging insns: Tagging Insns. (line 6) 56702* tail calls: Tail Calls. (line 6) 56703* TAmode: Machine Modes. (line 158) 56704* tanM2 instruction pattern: Standard Names. (line 992) 56705* target attributes: Target Attributes. (line 6) 56706* target description macros: Target Macros. (line 6) 56707* target functions: Target Structure. (line 6) 56708* target hooks: Target Structure. (line 6) 56709* target makefile fragment: Target Fragment. (line 6) 56710* target specifications: Run-time Target. (line 6) 56711* targetm: Target Structure. (line 6) 56712* targets, makefile: Makefile. (line 6) 56713* TARGET_ABSOLUTE_BIGGEST_ALIGNMENT: Storage Layout. (line 185) 56714* TARGET_ADDITIONAL_ALLOCNO_CLASS_P: Register Classes. (line 639) 56715* TARGET_ADDRESS_COST: Costs. (line 344) 56716* TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces. 56717 (line 42) 56718* TARGET_ADDR_SPACE_CONVERT: Named Address Spaces. 56719 (line 89) 56720* TARGET_ADDR_SPACE_DEBUG: Named Address Spaces. 56721 (line 99) 56722* TARGET_ADDR_SPACE_DIAGNOSE_USAGE: Named Address Spaces. 56723 (line 103) 56724* TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces. 56725 (line 59) 56726* TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces. 56727 (line 67) 56728* TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces. 56729 (line 36) 56730* TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces. 56731 (line 74) 56732* TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces. 56733 (line 48) 56734* TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID: Named Address Spaces. 56735 (line 83) 56736* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 436) 56737* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 812) 56738* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 1082) 56739* TARGET_ALWAYS_STRIP_DOTDOT: Driver. (line 250) 56740* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 92) 56741* TARGET_ARM_EABI_UNWINDER: Exception Region Output. 56742 (line 133) 56743* TARGET_ARRAY_MODE: Register Arguments. (line 373) 56744* TARGET_ARRAY_MODE_SUPPORTED_P: Register Arguments. (line 388) 56745* TARGET_ASAN_SHADOW_OFFSET: Misc. (line 1110) 56746* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 11) 56747* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 7) 56748* TARGET_ASM_ALIGNED_PDI_OP: Data Output. (line 10) 56749* TARGET_ASM_ALIGNED_PSI_OP: Data Output. (line 8) 56750* TARGET_ASM_ALIGNED_PTI_OP: Data Output. (line 12) 56751* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9) 56752* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 13) 56753* TARGET_ASM_ASSEMBLE_UNDEFINED_DECL: Label Output. (line 231) 56754* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 301) 56755* TARGET_ASM_BYTE_OP: Data Output. (line 6) 56756* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 209) 56757* TARGET_ASM_CLOSE_PAREN: Data Output. (line 139) 56758* TARGET_ASM_CODE_END: File Framework. (line 57) 56759* TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 56760 (line 68) 56761* TARGET_ASM_DECLARE_CONSTANT_NAME: Label Output. (line 177) 56762* TARGET_ASM_DECL_END: Data Output. (line 44) 56763* TARGET_ASM_DESTRUCTOR: Macros for Initialization. 56764 (line 82) 56765* TARGET_ASM_ELF_FLAGS_NUMERIC: File Framework. (line 120) 56766* TARGET_ASM_EMIT_EXCEPT_PERSONALITY: Dispatch Tables. (line 89) 56767* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 82) 56768* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 70) 56769* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 337) 56770* TARGET_ASM_FILE_END: File Framework. (line 35) 56771* TARGET_ASM_FILE_START: File Framework. (line 8) 56772* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 16) 56773* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 29) 56774* TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 82) 56775* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 67) 56776* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 61) 56777* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 73) 56778* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 18) 56779* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 225) 56780* TARGET_ASM_FUNCTION_SECTION: File Framework. (line 132) 56781* TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework. 56782 (line 142) 56783* TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC: Sections. (line 184) 56784* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 222) 56785* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 213) 56786* TARGET_ASM_INIT_SECTIONS: Sections. (line 164) 56787* TARGET_ASM_INTEGER: Data Output. (line 31) 56788* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 380) 56789* TARGET_ASM_LTO_END: File Framework. (line 52) 56790* TARGET_ASM_LTO_START: File Framework. (line 47) 56791* TARGET_ASM_MAKE_EH_SYMBOL_INDIRECT: Dispatch Tables. (line 102) 56792* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 343) 56793* TARGET_ASM_MERGEABLE_RODATA_PREFIX: Sections. (line 235) 56794* TARGET_ASM_NAMED_SECTION: File Framework. (line 112) 56795* TARGET_ASM_OPEN_PAREN: Data Output. (line 138) 56796* TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 48) 56797* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 42) 56798* TARGET_ASM_OUTPUT_DWARF_DTPREL: DWARF. (line 121) 56799* TARGET_ASM_OUTPUT_IDENT: File Framework. (line 99) 56800* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 167) 56801* TARGET_ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 91) 56802* TARGET_ASM_POST_CFI_STARTPROC: Dispatch Tables. (line 61) 56803* TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY: Function Entry. (line 9) 56804* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 173) 56805* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 184) 56806* TARGET_ASM_RELOC_RW_MASK: Sections. (line 173) 56807* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 244) 56808* TARGET_ASM_SELECT_SECTION: Sections. (line 191) 56809* TARGET_ASM_SHOULD_RESTORE_CFA_STATE: Dispatch Tables. (line 113) 56810* TARGET_ASM_TM_CLONE_TABLE_SECTION: Sections. (line 240) 56811* TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 81) 56812* TARGET_ASM_TTYPE: Exception Region Output. 56813 (line 127) 56814* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 18) 56815* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 14) 56816* TARGET_ASM_UNALIGNED_PDI_OP: Data Output. (line 17) 56817* TARGET_ASM_UNALIGNED_PSI_OP: Data Output. (line 15) 56818* TARGET_ASM_UNALIGNED_PTI_OP: Data Output. (line 19) 56819* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 16) 56820* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 20) 56821* TARGET_ASM_UNIQUE_SECTION: Sections. (line 213) 56822* TARGET_ASM_UNWIND_EMIT: Dispatch Tables. (line 96) 56823* TARGET_ASM_UNWIND_EMIT_BEFORE_INSN: Dispatch Tables. (line 108) 56824* TARGET_ATOMIC_ALIGN_FOR_MODE: Misc. (line 1130) 56825* TARGET_ATOMIC_ASSIGN_EXPAND_FENV: Misc. (line 1136) 56826* TARGET_ATOMIC_TEST_AND_SET_TRUEVAL: Misc. (line 1121) 56827* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 10) 56828* TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P: Target Attributes. (line 17) 56829* TARGET_BINDS_LOCAL_P: Sections. (line 322) 56830* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 281) 56831* TARGET_BUILTIN_DECL: Misc. (line 642) 56832* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 269) 56833* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 101) 56834* TARGET_CALLEE_COPIES: Register Arguments. (line 124) 56835* TARGET_CALL_ARGS: Varargs. (line 123) 56836* TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS: Miscellaneous Register Hooks. 56837 (line 6) 56838* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 242) 56839* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 876) 56840* TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P: Register Classes. (line 610) 56841* TARGET_CANONICALIZE_COMPARISON: MODE_CC Condition Codes. 56842 (line 55) 56843* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 302) 56844* TARGET_CAN_CHANGE_MODE_CLASS: Register Classes. (line 543) 56845* TARGET_CAN_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory. 56846 (line 299) 56847* TARGET_CAN_ELIMINATE: Elimination. (line 58) 56848* TARGET_CAN_FOLLOW_JUMP: Misc. (line 798) 56849* TARGET_CAN_INLINE_P: Target Attributes. (line 173) 56850* TARGET_CAN_USE_DOLOOP_P: Misc. (line 762) 56851* TARGET_CASE_VALUES_THRESHOLD: Misc. (line 46) 56852* TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes. 56853 (line 120) 56854* TARGET_CHECK_BUILTIN_CALL: Misc. (line 674) 56855* TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 26) 56856* TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target. (line 119) 56857* TARGET_CLASS_LIKELY_SPILLED_P: Register Classes. (line 499) 56858* TARGET_CLASS_MAX_NREGS: Register Classes. (line 515) 56859* TARGET_COMMUTATIVE_P: Misc. (line 805) 56860* TARGET_COMPARE_BY_PIECES_BRANCH_RATIO: Costs. (line 200) 56861* TARGET_COMPARE_VERSION_PRIORITY: Misc. (line 706) 56862* TARGET_COMPATIBLE_VECTOR_TYPES_P: Register Arguments. (line 350) 56863* TARGET_COMPUTE_FRAME_LAYOUT: Elimination. (line 74) 56864* TARGET_COMPUTE_PRESSURE_CLASSES: Register Classes. (line 655) 56865* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 25) 56866* TARGET_CONDITIONAL_REGISTER_USAGE: Register Basics. (line 102) 56867* TARGET_CONSTANT_ALIGNMENT: Storage Layout. (line 275) 56868* TARGET_CONST_ANCHOR: Misc. (line 1093) 56869* TARGET_CONST_NOT_OK_FOR_DEBUG_P: Addressing Modes. (line 238) 56870* TARGET_CONVERT_TO_TYPE: Misc. (line 1027) 56871* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 8) 56872* TARGET_CSTORE_MODE: Register Classes. (line 647) 56873* TARGET_CUSTOM_FUNCTION_DESCRIPTORS: Trampolines. (line 39) 56874* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 86) 56875* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 37) 56876* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 61) 56877* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 24) 56878* TARGET_CXX_DECL_MANGLING_CONTEXT: C++ ABI. (line 92) 56879* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 52) 56880* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 17) 56881* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 11) 56882* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 6) 56883* TARGET_CXX_IMPLICIT_EXTERN_C: Misc. (line 409) 56884* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 28) 56885* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 42) 56886* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 68) 56887* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 73) 56888* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 79) 56889* TARGET_C_EXCESS_PRECISION: Storage Layout. (line 109) 56890* TARGET_C_PREINCLUDE: Misc. (line 397) 56891* TARGET_DEBUG_UNWIND_INFO: DWARF. (line 32) 56892* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 541) 56893* TARGET_DECLSPEC: Target Attributes. (line 72) 56894* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 481) 56895* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 123) 56896* TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 55) 56897* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 465) 56898* TARGET_DELAY_SCHED2: DWARF. (line 77) 56899* TARGET_DELAY_VARTRACK: DWARF. (line 81) 56900* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 229) 56901* TARGET_DIFFERENT_ADDR_DISPLACEMENT_P: Register Classes. (line 603) 56902* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 55) 56903* TARGET_DOLOOP_COST_FOR_ADDRESS: Misc. (line 751) 56904* TARGET_DOLOOP_COST_FOR_GENERIC: Misc. (line 740) 56905* TARGET_DWARF_CALLING_CONVENTION: DWARF. (line 12) 56906* TARGET_DWARF_FRAME_REG_MODE: Exception Region Output. 56907 (line 113) 56908* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 165) 56909* TARGET_DWARF_POLY_INDETERMINATE_VALUE: Frame Layout. (line 177) 56910* TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 56911 (line 104) 56912* TARGET_D_CPU_VERSIONS: D Language and ABI. (line 6) 56913* TARGET_D_HAS_STDCALL_CONVENTION: D Language and ABI. (line 47) 56914* TARGET_D_MINFO_END_NAME: D Language and ABI. (line 42) 56915* TARGET_D_MINFO_SECTION: D Language and ABI. (line 29) 56916* TARGET_D_MINFO_START_NAME: D Language and ABI. (line 37) 56917* TARGET_D_OS_VERSIONS: D Language and ABI. (line 13) 56918* TARGET_D_REGISTER_CPU_TARGET_INFO: D Language and ABI. (line 17) 56919* TARGET_D_REGISTER_OS_TARGET_INFO: D Language and ABI. (line 25) 56920* TARGET_D_TEMPLATES_ALWAYS_COMDAT: D Language and ABI. (line 55) 56921* TARGET_EDOM: Library Calls. (line 59) 56922* TARGET_EMIT_CALL_BUILTIN___CLEAR_CACHE: Trampolines. (line 128) 56923* TARGET_EMPTY_RECORD_P: Aggregate Return. (line 86) 56924* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 67) 56925* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 18) 56926* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 23) 56927* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 44) 56928* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 35) 56929* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 62) 56930* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 48) 56931* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 55) 56932* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 40) 56933* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 30) 56934* TARGET_ENCODE_SECTION_INFO: Sections. (line 265) 56935* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 56936 (line 82) 56937* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 127) 56938* TARGET_END_CALL_ARGS: Varargs. (line 137) 56939* TARGET_ENUM_VA_LIST_P: Register Arguments. (line 285) 56940* TARGET_ESTIMATED_POLY_VALUE: Costs. (line 432) 56941* TARGET_EXCEPT_UNWIND_INFO: Exception Region Output. 56942 (line 46) 56943* TARGET_EXECUTABLE_SUFFIX: Misc. (line 863) 56944* TARGET_EXPAND_BUILTIN: Misc. (line 652) 56945* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 64) 56946* TARGET_EXPAND_DIVMOD_LIBFUNC: Scheduling. (line 461) 56947* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 547) 56948* TARGET_EXPR: Unary and Binary Expressions. 56949 (line 6) 56950* TARGET_EXTRA_INCLUDES: Misc. (line 942) 56951* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 20) 56952* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 949) 56953* TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes. 56954 (line 105) 56955* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 544) 56956* target_flags: Run-time Target. (line 51) 56957* TARGET_FLAGS_REGNUM: MODE_CC Condition Codes. 56958 (line 133) 56959* TARGET_FLOATN_BUILTIN_P: Register Arguments. (line 438) 56960* TARGET_FLOATN_MODE: Register Arguments. (line 420) 56961* TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P: Run-time Target. 56962 (line 179) 56963* TARGET_FNTYPE_ABI: Register Basics. (line 58) 56964* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 297) 56965* TARGET_FOLD_BUILTIN: Misc. (line 689) 56966* TARGET_FORMAT_TYPES: Misc. (line 970) 56967* TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 8) 56968* TARGET_FUNCTION_ARG: Register Arguments. (line 10) 56969* TARGET_FUNCTION_ARG_ADVANCE: Register Arguments. (line 195) 56970* TARGET_FUNCTION_ARG_BOUNDARY: Register Arguments. (line 248) 56971* TARGET_FUNCTION_ARG_OFFSET: Register Arguments. (line 206) 56972* TARGET_FUNCTION_ARG_PADDING: Register Arguments. (line 214) 56973* TARGET_FUNCTION_ARG_ROUND_BOUNDARY: Register Arguments. (line 254) 56974* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 101) 56975* TARGET_FUNCTION_INCOMING_ARG: Register Arguments. (line 64) 56976* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 6) 56977* TARGET_FUNCTION_VALUE: Scalar Return. (line 9) 56978* TARGET_FUNCTION_VALUE_REGNO_P: Scalar Return. (line 96) 56979* TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc. (line 722) 56980* TARGET_GEN_CCMP_FIRST: Misc. (line 895) 56981* TARGET_GEN_CCMP_NEXT: Misc. (line 906) 56982* TARGET_GET_DRAP_RTX: Misc. (line 1063) 56983* TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc. (line 715) 56984* TARGET_GET_MULTILIB_ABI_NAME: Register Basics. (line 99) 56985* TARGET_GET_PCH_VALIDITY: PCH Target. (line 6) 56986* TARGET_GET_RAW_ARG_MODE: Aggregate Return. (line 81) 56987* TARGET_GET_RAW_RESULT_MODE: Aggregate Return. (line 76) 56988* TARGET_GET_VALID_OPTION_VALUES: Stack Smashing Protection. 56989 (line 39) 56990* TARGET_GIMPLE_FOLD_BUILTIN: Misc. (line 699) 56991* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 307) 56992* TARGET_GOACC_DIM_LIMIT: Addressing Modes. (line 549) 56993* TARGET_GOACC_FORK_JOIN: Addressing Modes. (line 553) 56994* TARGET_GOACC_REDUCTION: Addressing Modes. (line 564) 56995* TARGET_GOACC_VALIDATE_DIMS: Addressing Modes. (line 536) 56996* TARGET_HANDLE_C_OPTION: Run-time Target. (line 73) 56997* TARGET_HANDLE_GENERIC_ATTRIBUTE: Target Attributes. (line 93) 56998* TARGET_HANDLE_OPTION: Run-time Target. (line 59) 56999* TARGET_HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 76) 57000* TARGET_HARD_REGNO_MODE_OK: Values in Registers. 57001 (line 54) 57002* TARGET_HARD_REGNO_NREGS: Values in Registers. 57003 (line 10) 57004* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers. 57005 (line 139) 57006* TARGET_HAS_IFUNC_P: Misc. (line 1125) 57007* TARGET_HAS_NO_HW_DIVIDE: Library Calls. (line 52) 57008* TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 889) 57009* TARGET_HAVE_COUNT_REG_DECR_P: Misc. (line 736) 57010* TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 57011 (line 63) 57012* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 150) 57013* TARGET_HAVE_SPECULATION_SAFE_VALUE: Misc. (line 1208) 57014* TARGET_HAVE_SRODATA_SECTION: Sections. (line 311) 57015* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 155) 57016* TARGET_HAVE_TLS: Sections. (line 331) 57017* TARGET_INIT_BUILTINS: Misc. (line 626) 57018* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output. 57019 (line 119) 57020* TARGET_INIT_LIBFUNCS: Library Calls. (line 15) 57021* TARGET_INIT_PIC_REG: Register Arguments. (line 88) 57022* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 80) 57023* TARGET_INSN_CALLEE_ABI: Register Basics. (line 65) 57024* TARGET_INSN_COST: Costs. (line 380) 57025* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 555) 57026* TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 994) 57027* TARGET_INVALID_BINARY_OP: Misc. (line 1013) 57028* TARGET_INVALID_CONVERSION: Misc. (line 1000) 57029* TARGET_INVALID_UNARY_OP: Misc. (line 1006) 57030* TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 779) 57031* TARGET_IN_SMALL_DATA_P: Sections. (line 307) 57032* TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS: Register Classes. (line 570) 57033* TARGET_KEEP_LEAF_WHEN_PROFILED: Profiling. (line 39) 57034* TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 48) 57035* TARGET_LEGITIMATE_COMBINED_INSN: Misc. (line 793) 57036* TARGET_LEGITIMATE_CONSTANT_P: Addressing Modes. (line 213) 57037* TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 129) 57038* TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: Register Classes. (line 618) 57039* TARGET_LIBCALL_VALUE: Scalar Return. (line 65) 57040* TARGET_LIBC_HAS_FAST_FUNCTION: Library Calls. (line 85) 57041* TARGET_LIBC_HAS_FUNCTION: Library Calls. (line 77) 57042* TARGET_LIBFUNC_GNU_PREFIX: Library Calls. (line 24) 57043* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 497) 57044* TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P: Register Arguments. 57045 (line 412) 57046* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 136) 57047* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 503) 57048* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 42) 57049* TARGET_LOAD_BOUNDS_FOR_ARG: Varargs. (line 153) 57050* TARGET_LOAD_RETURNED_BOUNDS: Varargs. (line 172) 57051* TARGET_LOOP_UNROLL_ADJUST: Misc. (line 923) 57052* TARGET_LOWER_LOCAL_DECL_ALIGNMENT: Storage Layout. (line 243) 57053* TARGET_LRA_P: Register Classes. (line 577) 57054* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 611) 57055* TARGET_MANGLE_ASSEMBLER_NAME: Label Output. (line 356) 57056* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 255) 57057* TARGET_MANGLE_TYPE: Storage Layout. (line 559) 57058* TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 38) 57059* TARGET_MAX_NOCE_IFCVT_SEQ_COST: Costs. (line 390) 57060* TARGET_MD_ASM_ADJUST: Misc. (line 526) 57061* TARGET_MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 449) 57062* TARGET_MEMMODEL_CHECK: Misc. (line 1116) 57063* TARGET_MEMORY_MOVE_COST: Costs. (line 79) 57064* TARGET_MEMTAG_ADD_TAG: Misc. (line 1280) 57065* TARGET_MEMTAG_CAN_TAG_ADDRESSES: Misc. (line 1248) 57066* TARGET_MEMTAG_EXTRACT_TAG: Misc. (line 1297) 57067* TARGET_MEMTAG_GRANULE_SIZE: Misc. (line 1261) 57068* TARGET_MEMTAG_INSERT_RANDOM_TAG: Misc. (line 1273) 57069* TARGET_MEMTAG_SET_TAG: Misc. (line 1290) 57070* TARGET_MEMTAG_TAG_SIZE: Misc. (line 1256) 57071* TARGET_MEMTAG_UNTAGGED_POINTER: Misc. (line 1303) 57072* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 107) 57073* TARGET_MEM_REF: Storage References. (line 6) 57074* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 45) 57075* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 37) 57076* TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 32) 57077* TARGET_MIN_ARITHMETIC_PRECISION: Misc. (line 63) 57078* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 112) 57079* TARGET_MODES_TIEABLE_P: Values in Registers. 57080 (line 123) 57081* TARGET_MODE_AFTER: Mode Switching. (line 57) 57082* TARGET_MODE_DEPENDENT_ADDRESS_P: Addressing Modes. (line 196) 57083* TARGET_MODE_EMIT: Mode Switching. (line 42) 57084* TARGET_MODE_ENTRY: Mode Switching. (line 64) 57085* TARGET_MODE_EXIT: Mode Switching. (line 71) 57086* TARGET_MODE_NEEDED: Mode Switching. (line 50) 57087* TARGET_MODE_PRIORITY: Mode Switching. (line 78) 57088* TARGET_MODE_REP_EXTENDED: Misc. (line 199) 57089* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 513) 57090* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 57) 57091* TARGET_MUST_PASS_IN_STACK, and TARGET_FUNCTION_ARG: Register Arguments. 57092 (line 49) 57093* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 442) 57094* TARGET_NEW_ADDRESS_PROFITABLE_P: Costs. (line 415) 57095* TARGET_NOCE_CONVERSION_PROFITABLE_P: Costs. (line 409) 57096* TARGET_NO_REGISTER_ALLOCATION: DWARF. (line 85) 57097* TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P: Costs. (line 422) 57098* TARGET_N_FORMAT_TYPES: Misc. (line 975) 57099* TARGET_OBJC_CONSTRUCT_STRING_OBJECT: Run-time Target. (line 88) 57100* TARGET_OBJC_DECLARE_CLASS_DEFINITION: Run-time Target. (line 109) 57101* TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target. 57102 (line 104) 57103* TARGET_OBJECT_SUFFIX: Misc. (line 858) 57104* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 45) 57105* TARGET_OFFLOAD_OPTIONS: Misc. (line 1159) 57106* TARGET_OMIT_STRUCT_RETURN_REG: Scalar Return. (line 117) 57107* TARGET_OMP_DEVICE_KIND_ARCH_ISA: Addressing Modes. (line 528) 57108* TARGET_OPTAB_SUPPORTED_P: Costs. (line 299) 57109* TARGET_OPTF: Misc. (line 957) 57110* TARGET_OPTION_FUNCTION_VERSIONS: Target Attributes. (line 165) 57111* TARGET_OPTION_INIT_STRUCT: Run-time Target. (line 156) 57112* TARGET_OPTION_OPTIMIZATION_TABLE: Run-time Target. (line 142) 57113* TARGET_OPTION_OVERRIDE: Target Attributes. (line 152) 57114* TARGET_OPTION_POST_STREAM_IN: Target Attributes. (line 133) 57115* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 145) 57116* TARGET_OPTION_PRINT: Target Attributes. (line 139) 57117* TARGET_OPTION_RESTORE: Target Attributes. (line 127) 57118* TARGET_OPTION_SAVE: Target Attributes. (line 120) 57119* TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 108) 57120* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 41) 57121* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 979) 57122* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 985) 57123* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 989) 57124* TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 126) 57125* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 112) 57126* TARGET_PCH_VALID_P: PCH Target. (line 11) 57127* TARGET_POSIX_IO: Misc. (line 555) 57128* TARGET_PRECOMPUTE_TLS_P: Addressing Modes. (line 221) 57129* TARGET_PREDICT_DOLOOP_P: Misc. (line 729) 57130* TARGET_PREFERRED_ELSE_VALUE: Addressing Modes. (line 572) 57131* TARGET_PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 284) 57132* TARGET_PREFERRED_RELOAD_CLASS: Register Classes. (line 213) 57133* TARGET_PREFERRED_RENAME_CLASS: Register Classes. (line 201) 57134* TARGET_PREPARE_PCH_SAVE: PCH Target. (line 34) 57135* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 144) 57136* TARGET_PROFILE_BEFORE_PROLOGUE: Sections. (line 315) 57137* TARGET_PROMOTED_TYPE: Misc. (line 1019) 57138* TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 126) 57139* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 10) 57140* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 250) 57141* TARGET_RECORD_OFFLOAD_SYMBOL: Misc. (line 1154) 57142* TARGET_REF_MAY_ALIAS_ERRNO: Register Arguments. (line 318) 57143* TARGET_REGISTER_MOVE_COST: Costs. (line 31) 57144* TARGET_REGISTER_PRIORITY: Register Classes. (line 582) 57145* TARGET_REGISTER_USAGE_LEVELING_P: Register Classes. (line 593) 57146* TARGET_RELAYOUT_FUNCTION: Target Attributes. (line 180) 57147* TARGET_RESET_LOCATION_VIEW: DWARF. (line 57) 57148* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 663) 57149* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 15) 57150* TARGET_RETURN_IN_MSB: Scalar Return. (line 124) 57151* TARGET_RETURN_POPS_ARGS: Stack Arguments. (line 98) 57152* TARGET_RTX_COSTS: Costs. (line 313) 57153* TARGET_RUN_TARGET_SELFTESTS: Misc. (line 1245) 57154* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 334) 57155* TARGET_SCHED_ADJUST_COST: Scheduling. (line 35) 57156* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 50) 57157* TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 294) 57158* TARGET_SCHED_CAN_SPECULATE_INSN: Scheduling. (line 354) 57159* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 309) 57160* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 101) 57161* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 255) 57162* TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 172) 57163* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 156) 57164* TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 165) 57165* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 144) 57166* TARGET_SCHED_DISPATCH: Scheduling. (line 370) 57167* TARGET_SCHED_DISPATCH_DO: Scheduling. (line 375) 57168* TARGET_SCHED_EXPOSED_PIPELINE: Scheduling. (line 379) 57169* TARGET_SCHED_FINISH: Scheduling. (line 122) 57170* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 137) 57171* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling. (line 235) 57172* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling. (line 223) 57173* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 57174 (line 179) 57175* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 57176 (line 207) 57177* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling. (line 240) 57178* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling. (line 250) 57179* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling. (line 245) 57180* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling. (line 229) 57181* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 313) 57182* TARGET_SCHED_FUSION_PRIORITY: Scheduling. (line 389) 57183* TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 335) 57184* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 289) 57185* TARGET_SCHED_INIT: Scheduling. (line 111) 57186* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 161) 57187* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 153) 57188* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 129) 57189* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 298) 57190* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 11) 57191* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 267) 57192* TARGET_SCHED_MACRO_FUSION_P: Scheduling. (line 87) 57193* TARGET_SCHED_MACRO_FUSION_PAIR_P: Scheduling. (line 91) 57194* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 328) 57195* TARGET_SCHED_REASSOCIATION_WIDTH: Scheduling. (line 384) 57196* TARGET_SCHED_REORDER: Scheduling. (line 58) 57197* TARGET_SCHED_REORDER2: Scheduling. (line 75) 57198* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 305) 57199* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 347) 57200* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 361) 57201* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 316) 57202* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 22) 57203* TARGET_SECONDARY_MEMORY_NEEDED: Register Classes. (line 447) 57204* TARGET_SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 466) 57205* TARGET_SECONDARY_RELOAD: Register Classes. (line 312) 57206* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 160) 57207* TARGET_SELECT_EARLY_REMAT_MODES: Register Classes. (line 488) 57208* TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P: Misc. (line 225) 57209* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 71) 57210* TARGET_SET_CURRENT_FUNCTION: Misc. (line 840) 57211* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 33) 57212* TARGET_SET_UP_BY_PROLOGUE: Tail Calls. (line 29) 57213* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 160) 57214* TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB: Shrink-wrapping separate components. 57215 (line 36) 57216* TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS: Shrink-wrapping separate components. 57217 (line 43) 57218* TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS: Shrink-wrapping separate components. 57219 (line 54) 57220* TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS: Shrink-wrapping separate components. 57221 (line 50) 57222* TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS: Shrink-wrapping separate components. 57223 (line 27) 57224* TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS: Shrink-wrapping separate components. 57225 (line 58) 57226* TARGET_SIMD_CLONE_ADJUST: Addressing Modes. (line 515) 57227* TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN: Addressing Modes. 57228 (line 507) 57229* TARGET_SIMD_CLONE_USABLE: Addressing Modes. (line 519) 57230* TARGET_SIMT_VF: Addressing Modes. (line 525) 57231* TARGET_SLOW_UNALIGNED_ACCESS: Costs. (line 132) 57232* TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments. 57233 (line 448) 57234* TARGET_SPECULATION_SAFE_VALUE: Misc. (line 1227) 57235* TARGET_SPILL_CLASS: Register Classes. (line 632) 57236* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 269) 57237* TARGET_STACK_CLASH_PROTECTION_ALLOCA_PROBE_RANGE: Stack Checking. 57238 (line 97) 57239* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 57240 (line 16) 57241* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 57242 (line 6) 57243* TARGET_STACK_PROTECT_RUNTIME_ENABLED_P: Stack Smashing Protection. 57244 (line 25) 57245* TARGET_STARTING_FRAME_OFFSET: Frame Layout. (line 34) 57246* TARGET_STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 57247 (line 74) 57248* TARGET_STATIC_CHAIN: Frame Registers. (line 90) 57249* TARGET_STATIC_RTX_ALIGNMENT: Storage Layout. (line 247) 57250* TARGET_STORE_BOUNDS_FOR_ARG: Varargs. (line 163) 57251* TARGET_STORE_RETURNED_BOUNDS: Varargs. (line 177) 57252* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 107) 57253* TARGET_STRING_OBJECT_REF_TYPE_P: Run-time Target. (line 114) 57254* TARGET_STRIP_NAME_ENCODING: Sections. (line 302) 57255* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44) 57256* TARGET_SUPPORTS_SPLIT_STACK: Stack Smashing Protection. 57257 (line 30) 57258* TARGET_SUPPORTS_WEAK: Label Output. (line 272) 57259* TARGET_SUPPORTS_WIDE_INT: Misc. (line 1167) 57260* TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output. 57261 (line 98) 57262* TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 140) 57263* TARGET_TRAMPOLINE_INIT: Trampolines. (line 107) 57264* TARGET_TRANSLATE_MODE_ATTRIBUTE: Register Arguments. (line 325) 57265* TARGET_TRULY_NOOP_TRUNCATION: Misc. (line 184) 57266* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 831) 57267* TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output. 57268 (line 73) 57269* TARGET_UNWIND_WORD_MODE: Storage Layout. (line 509) 57270* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 1059) 57271* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 123) 57272* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 53) 57273* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 256) 57274* TARGET_USE_BLOCKS_FOR_DECL_P: Addressing Modes. (line 263) 57275* TARGET_USE_BY_PIECES_INFRASTRUCTURE_P: Costs. (line 165) 57276* TARGET_USE_PSEUDO_PIC_REG: Register Arguments. (line 84) 57277* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 66) 57278* TARGET_VALID_POINTER_MODE: Register Arguments. (line 313) 57279* TARGET_VECTORIZE_ADD_STMT_COST: Addressing Modes. (line 469) 57280* TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES: Addressing Modes. 57281 (line 384) 57282* TARGET_VECTORIZE_BUILTIN_GATHER: Addressing Modes. (line 493) 57283* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 274) 57284* TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION: Addressing Modes. 57285 (line 352) 57286* TARGET_VECTORIZE_BUILTIN_SCATTER: Addressing Modes. (line 500) 57287* TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes. 57288 (line 300) 57289* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes. 57290 (line 344) 57291* TARGET_VECTORIZE_DESTROY_COST_DATA: Addressing Modes. (line 488) 57292* TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE: Addressing Modes. 57293 (line 453) 57294* TARGET_VECTORIZE_FINISH_COST: Addressing Modes. (line 481) 57295* TARGET_VECTORIZE_GET_MASK_MODE: Addressing Modes. (line 441) 57296* TARGET_VECTORIZE_INIT_COST: Addressing Modes. (line 460) 57297* TARGET_VECTORIZE_PREFERRED_SIMD_MODE: Addressing Modes. (line 369) 57298* TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT: Addressing Modes. 57299 (line 306) 57300* TARGET_VECTORIZE_RELATED_MODE: Addressing Modes. (line 415) 57301* TARGET_VECTORIZE_SPLIT_REDUCTION: Addressing Modes. (line 376) 57302* TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes. 57303 (line 359) 57304* TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes. 57305 (line 318) 57306* TARGET_VECTORIZE_VEC_PERM_CONST: Addressing Modes. (line 324) 57307* TARGET_VECTOR_ALIGNMENT: Storage Layout. (line 302) 57308* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 345) 57309* TARGET_VERIFY_TYPE_CONTEXT: Misc. (line 1034) 57310* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 303) 57311* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 297) 57312* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 286) 57313* TARGET_WANT_DEBUG_PUB_SECTIONS: DWARF. (line 72) 57314* TARGET_WARN_FUNC_RETURN: Tail Calls. (line 35) 57315* TARGET_WARN_PARAMETER_PASSING_ABI: Aggregate Return. (line 90) 57316* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 308) 57317* TARGET_ZERO_CALL_USED_REGS: Misc. (line 1069) 57318* TCmode: Machine Modes. (line 199) 57319* TDmode: Machine Modes. (line 97) 57320* TEMPLATE_DECL: Declarations. (line 6) 57321* Temporaries: Temporaries. (line 6) 57322* termination routines: Initialization. (line 6) 57323* testing constraints: C Constraint Interface. 57324 (line 6) 57325* TEXT_SECTION_ASM_OP: Sections. (line 37) 57326* TFmode: Machine Modes. (line 101) 57327* The Language: The Language. (line 6) 57328* THEN_CLAUSE: Statements for C and C++. 57329 (line 6) 57330* THREAD_MODEL_SPEC: Driver. (line 162) 57331* THROW_EXPR: Unary and Binary Expressions. 57332 (line 6) 57333* THUNK_DECL: Declarations. (line 6) 57334* THUNK_DELTA: Declarations. (line 6) 57335* TImode: Machine Modes. (line 48) 57336* TImode, in insn: Insns. (line 291) 57337* TLS_COMMON_ASM_OP: Sections. (line 80) 57338* TLS_SECTION_ASM_FLAG: Sections. (line 85) 57339* tm.h macros: Target Macros. (line 6) 57340* TQFmode: Machine Modes. (line 65) 57341* TQmode: Machine Modes. (line 122) 57342* trampolines for nested functions: Trampolines. (line 6) 57343* TRAMPOLINE_ALIGNMENT: Trampolines. (line 101) 57344* TRAMPOLINE_SECTION: Trampolines. (line 92) 57345* TRAMPOLINE_SIZE: Trampolines. (line 97) 57346* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 176) 57347* trap instruction pattern: Standard Names. (line 2320) 57348* tree: Tree overview. (line 6) 57349* tree <1>: Macros and Functions. 57350 (line 6) 57351* Tree SSA: Tree SSA. (line 6) 57352* TREE_CHAIN: Macros and Functions. 57353 (line 6) 57354* TREE_CODE: Tree overview. (line 6) 57355* tree_fits_shwi_p: Constant expressions. 57356 (line 6) 57357* tree_fits_uhwi_p: Constant expressions. 57358 (line 6) 57359* TREE_INT_CST_ELT: Constant expressions. 57360 (line 6) 57361* tree_int_cst_equal: Constant expressions. 57362 (line 6) 57363* TREE_INT_CST_LOW: Constant expressions. 57364 (line 6) 57365* tree_int_cst_lt: Constant expressions. 57366 (line 6) 57367* TREE_INT_CST_NUNITS: Constant expressions. 57368 (line 6) 57369* TREE_LIST: Containers. (line 6) 57370* TREE_OPERAND: Expression trees. (line 6) 57371* TREE_PUBLIC: Function Basics. (line 6) 57372* TREE_PUBLIC <1>: Function Properties. 57373 (line 28) 57374* TREE_PURPOSE: Containers. (line 6) 57375* TREE_READONLY: Function Properties. 57376 (line 37) 57377* tree_size: Macros and Functions. 57378 (line 13) 57379* TREE_STATIC: Function Properties. 57380 (line 31) 57381* TREE_STRING_LENGTH: Constant expressions. 57382 (line 6) 57383* TREE_STRING_POINTER: Constant expressions. 57384 (line 6) 57385* TREE_THIS_VOLATILE: Function Properties. 57386 (line 34) 57387* tree_to_shwi: Constant expressions. 57388 (line 6) 57389* tree_to_uhwi: Constant expressions. 57390 (line 6) 57391* TREE_TYPE: Macros and Functions. 57392 (line 6) 57393* TREE_TYPE <1>: Types. (line 6) 57394* TREE_TYPE <2>: Working with declarations. 57395 (line 11) 57396* TREE_TYPE <3>: Expression trees. (line 6) 57397* TREE_TYPE <4>: Expression trees. (line 17) 57398* TREE_TYPE <5>: Function Basics. (line 47) 57399* TREE_TYPE <6>: Types for C++. (line 6) 57400* TREE_VALUE: Containers. (line 6) 57401* TREE_VEC: Containers. (line 6) 57402* TREE_VEC_ELT: Containers. (line 6) 57403* TREE_VEC_LENGTH: Containers. (line 6) 57404* true positive: Guidelines for Diagnostics. 57405 (line 39) 57406* truncate: Conversions. (line 38) 57407* truncMN2 instruction pattern: Standard Names. (line 1641) 57408* TRUNC_DIV_EXPR: Unary and Binary Expressions. 57409 (line 6) 57410* TRUNC_MOD_EXPR: Unary and Binary Expressions. 57411 (line 6) 57412* TRUTH_ANDIF_EXPR: Unary and Binary Expressions. 57413 (line 6) 57414* TRUTH_AND_EXPR: Unary and Binary Expressions. 57415 (line 6) 57416* TRUTH_NOT_EXPR: Unary and Binary Expressions. 57417 (line 6) 57418* TRUTH_ORIF_EXPR: Unary and Binary Expressions. 57419 (line 6) 57420* TRUTH_OR_EXPR: Unary and Binary Expressions. 57421 (line 6) 57422* TRUTH_XOR_EXPR: Unary and Binary Expressions. 57423 (line 6) 57424* TRY_BLOCK: Statements for C and C++. 57425 (line 6) 57426* TRY_HANDLERS: Statements for C and C++. 57427 (line 6) 57428* TRY_STMTS: Statements for C and C++. 57429 (line 6) 57430* Tuple specific accessors: Tuple specific accessors. 57431 (line 6) 57432* tuples: Tuple representation. 57433 (line 6) 57434* type: Types. (line 6) 57435* type declaration: Declarations. (line 6) 57436* TYPENAME_TYPE: Types for C++. (line 6) 57437* TYPENAME_TYPE_FULLNAME: Types. (line 6) 57438* TYPENAME_TYPE_FULLNAME <1>: Types for C++. (line 6) 57439* TYPEOF_TYPE: Types for C++. (line 6) 57440* TYPE_ALIGN: Types. (line 6) 57441* TYPE_ALIGN <1>: Types. (line 30) 57442* TYPE_ALIGN <2>: Types for C++. (line 6) 57443* TYPE_ALIGN <3>: Types for C++. (line 44) 57444* TYPE_ARG_TYPES: Types. (line 6) 57445* TYPE_ARG_TYPES <1>: Types for C++. (line 6) 57446* TYPE_ASM_OP: Label Output. (line 76) 57447* TYPE_ATTRIBUTES: Attributes. (line 24) 57448* TYPE_BINFO: Classes. (line 6) 57449* TYPE_BUILT_IN: Types for C++. (line 66) 57450* TYPE_CANONICAL: Types. (line 6) 57451* TYPE_CANONICAL <1>: Types. (line 41) 57452* TYPE_CONTEXT: Types. (line 6) 57453* TYPE_CONTEXT <1>: Types for C++. (line 6) 57454* TYPE_DECL: Declarations. (line 6) 57455* TYPE_FIELDS: Types. (line 6) 57456* TYPE_FIELDS <1>: Types for C++. (line 6) 57457* TYPE_FIELDS <2>: Classes. (line 6) 57458* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 93) 57459* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 78) 57460* TYPE_HAS_MUTABLE_P: Classes. (line 83) 57461* TYPE_HAS_NEW_OPERATOR: Classes. (line 90) 57462* TYPE_MAIN_VARIANT: Types. (line 6) 57463* TYPE_MAIN_VARIANT <1>: Types. (line 19) 57464* TYPE_MAIN_VARIANT <2>: Types for C++. (line 6) 57465* TYPE_MAX_VALUE: Types. (line 6) 57466* TYPE_METHOD_BASETYPE: Types. (line 6) 57467* TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6) 57468* TYPE_MIN_VALUE: Types. (line 6) 57469* TYPE_NAME: Types. (line 6) 57470* TYPE_NAME <1>: Types. (line 33) 57471* TYPE_NAME <2>: Types for C++. (line 6) 57472* TYPE_NAME <3>: Types for C++. (line 47) 57473* TYPE_NOTHROW_P: Functions for C++. (line 154) 57474* TYPE_OFFSET_BASETYPE: Types. (line 6) 57475* TYPE_OFFSET_BASETYPE <1>: Types for C++. (line 6) 57476* TYPE_OPERAND_FMT: Label Output. (line 87) 57477* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 101) 57478* TYPE_OVERLOADS_ARROW: Classes. (line 104) 57479* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 97) 57480* TYPE_POLYMORPHIC_P: Classes. (line 74) 57481* TYPE_PRECISION: Types. (line 6) 57482* TYPE_PRECISION <1>: Types for C++. (line 6) 57483* TYPE_PTRDATAMEM_P: Types for C++. (line 6) 57484* TYPE_PTRDATAMEM_P <1>: Types for C++. (line 69) 57485* TYPE_PTRFN_P: Types for C++. (line 76) 57486* TYPE_PTROBV_P: Types for C++. (line 6) 57487* TYPE_PTROB_P: Types for C++. (line 79) 57488* TYPE_PTR_P: Types for C++. (line 72) 57489* TYPE_QUAL_CONST: Types. (line 6) 57490* TYPE_QUAL_CONST <1>: Types for C++. (line 6) 57491* TYPE_QUAL_RESTRICT: Types. (line 6) 57492* TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6) 57493* TYPE_QUAL_VOLATILE: Types. (line 6) 57494* TYPE_QUAL_VOLATILE <1>: Types for C++. (line 6) 57495* TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149) 57496* TYPE_SIZE: Types. (line 6) 57497* TYPE_SIZE <1>: Types. (line 25) 57498* TYPE_SIZE <2>: Types for C++. (line 6) 57499* TYPE_SIZE <3>: Types for C++. (line 39) 57500* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6) 57501* TYPE_STRUCTURAL_EQUALITY_P <1>: Types. (line 77) 57502* TYPE_UNQUALIFIED: Types. (line 6) 57503* TYPE_UNQUALIFIED <1>: Types for C++. (line 6) 57504* TYPE_VFIELD: Classes. (line 6) 57505* uaddvM4 instruction pattern: Standard Names. (line 485) 57506* uavgM3_ceil instruction pattern: Standard Names. (line 898) 57507* uavgM3_floor instruction pattern: Standard Names. (line 886) 57508* UDAmode: Machine Modes. (line 170) 57509* udiv: Arithmetic. (line 130) 57510* udivM3 instruction pattern: Standard Names. (line 466) 57511* udivmodM4 instruction pattern: Standard Names. (line 863) 57512* udot_prodM instruction pattern: Standard Names. (line 594) 57513* UDQmode: Machine Modes. (line 138) 57514* UHAmode: Machine Modes. (line 162) 57515* UHQmode: Machine Modes. (line 130) 57516* UINT16_TYPE: Type Layout. (line 214) 57517* UINT32_TYPE: Type Layout. (line 215) 57518* UINT64_TYPE: Type Layout. (line 216) 57519* UINT8_TYPE: Type Layout. (line 213) 57520* UINTMAX_TYPE: Type Layout. (line 197) 57521* UINTPTR_TYPE: Type Layout. (line 234) 57522* UINT_FAST16_TYPE: Type Layout. (line 230) 57523* UINT_FAST32_TYPE: Type Layout. (line 231) 57524* UINT_FAST64_TYPE: Type Layout. (line 232) 57525* UINT_FAST8_TYPE: Type Layout. (line 229) 57526* UINT_LEAST16_TYPE: Type Layout. (line 222) 57527* UINT_LEAST32_TYPE: Type Layout. (line 223) 57528* UINT_LEAST64_TYPE: Type Layout. (line 224) 57529* UINT_LEAST8_TYPE: Type Layout. (line 221) 57530* umaddMN4 instruction pattern: Standard Names. (line 810) 57531* umax: Arithmetic. (line 149) 57532* umaxM3 instruction pattern: Standard Names. (line 466) 57533* umin: Arithmetic. (line 149) 57534* uminM3 instruction pattern: Standard Names. (line 466) 57535* umod: Arithmetic. (line 136) 57536* umodM3 instruction pattern: Standard Names. (line 466) 57537* umsubMN4 instruction pattern: Standard Names. (line 834) 57538* umulhisi3 instruction pattern: Standard Names. (line 782) 57539* umulhrsM3 instruction pattern: Standard Names. (line 629) 57540* umulhsM3 instruction pattern: Standard Names. (line 619) 57541* umulM3_highpart instruction pattern: Standard Names. (line 796) 57542* umulqihi3 instruction pattern: Standard Names. (line 782) 57543* umulsidi3 instruction pattern: Standard Names. (line 782) 57544* umulvM4 instruction pattern: Standard Names. (line 490) 57545* unchanging: Flags. (line 307) 57546* unchanging, in call_insn: Flags. (line 115) 57547* unchanging, in jump_insn, call_insn and insn: Flags. (line 28) 57548* unchanging, in mem: Flags. (line 78) 57549* unchanging, in subreg: Flags. (line 184) 57550* unchanging, in subreg <1>: Flags. (line 194) 57551* unchanging, in symbol_ref: Flags. (line 19) 57552* UNEQ_EXPR: Unary and Binary Expressions. 57553 (line 6) 57554* UNGE_EXPR: Unary and Binary Expressions. 57555 (line 6) 57556* UNGT_EXPR: Unary and Binary Expressions. 57557 (line 6) 57558* unions, returning: Interface. (line 10) 57559* UNION_TYPE: Types. (line 6) 57560* UNION_TYPE <1>: Classes. (line 6) 57561* UNITS_PER_WORD: Storage Layout. (line 60) 57562* UNKNOWN_TYPE: Types. (line 6) 57563* UNKNOWN_TYPE <1>: Types for C++. (line 6) 57564* UNLE_EXPR: Unary and Binary Expressions. 57565 (line 6) 57566* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 48) 57567* UNLT_EXPR: Unary and Binary Expressions. 57568 (line 6) 57569* UNORDERED_EXPR: Unary and Binary Expressions. 57570 (line 6) 57571* unshare_all_rtl: Sharing. (line 61) 57572* unsigned division: Arithmetic. (line 130) 57573* unsigned division with unsigned saturation: Arithmetic. (line 130) 57574* unsigned greater than: Comparisons. (line 64) 57575* unsigned greater than <1>: Comparisons. (line 72) 57576* unsigned less than: Comparisons. (line 68) 57577* unsigned less than <1>: Comparisons. (line 76) 57578* unsigned minimum and maximum: Arithmetic. (line 149) 57579* unsigned_fix: Conversions. (line 77) 57580* unsigned_float: Conversions. (line 62) 57581* unsigned_fract_convert: Conversions. (line 97) 57582* unsigned_sat_fract: Conversions. (line 103) 57583* unspec: Side Effects. (line 299) 57584* unspec <1>: Constant Definitions. 57585 (line 111) 57586* unspec_volatile: Side Effects. (line 299) 57587* unspec_volatile <1>: Constant Definitions. 57588 (line 99) 57589* untyped_call instruction pattern: Standard Names. (line 1946) 57590* untyped_return instruction pattern: Standard Names. (line 2009) 57591* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 57592* update_ssa: SSA. (line 74) 57593* update_stmt: Manipulating GIMPLE statements. 57594 (line 140) 57595* update_stmt <1>: SSA Operands. (line 6) 57596* update_stmt_if_modified: Manipulating GIMPLE statements. 57597 (line 143) 57598* UQQmode: Machine Modes. (line 126) 57599* usaddM3 instruction pattern: Standard Names. (line 466) 57600* usadM instruction pattern: Standard Names. (line 603) 57601* USAmode: Machine Modes. (line 166) 57602* usashlM3 instruction pattern: Standard Names. (line 866) 57603* usdivM3 instruction pattern: Standard Names. (line 466) 57604* use: Side Effects. (line 168) 57605* used: Flags. (line 325) 57606* used, in symbol_ref: Flags. (line 211) 57607* user: GTY Options. (line 245) 57608* user experience guidelines: User Experience Guidelines. 57609 (line 6) 57610* user gc: User GC. (line 6) 57611* USER_LABEL_PREFIX: Instruction Output. (line 152) 57612* USE_C_ALLOCA: Host Misc. (line 19) 57613* USE_LD_AS_NEEDED: Driver. (line 135) 57614* USE_LOAD_POST_DECREMENT: Costs. (line 254) 57615* USE_LOAD_POST_INCREMENT: Costs. (line 249) 57616* USE_LOAD_PRE_DECREMENT: Costs. (line 264) 57617* USE_LOAD_PRE_INCREMENT: Costs. (line 259) 57618* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 205) 57619* USE_STORE_POST_DECREMENT: Costs. (line 274) 57620* USE_STORE_POST_INCREMENT: Costs. (line 269) 57621* USE_STORE_PRE_DECREMENT: Costs. (line 284) 57622* USE_STORE_PRE_INCREMENT: Costs. (line 279) 57623* USING_STMT: Statements for C and C++. 57624 (line 6) 57625* usmaddMN4 instruction pattern: Standard Names. (line 818) 57626* usmsubMN4 instruction pattern: Standard Names. (line 842) 57627* usmulhisi3 instruction pattern: Standard Names. (line 786) 57628* usmulM3 instruction pattern: Standard Names. (line 466) 57629* usmulqihi3 instruction pattern: Standard Names. (line 786) 57630* usmulsidi3 instruction pattern: Standard Names. (line 786) 57631* usnegM2 instruction pattern: Standard Names. (line 910) 57632* USQmode: Machine Modes. (line 134) 57633* ussubM3 instruction pattern: Standard Names. (line 466) 57634* usubvM4 instruction pattern: Standard Names. (line 490) 57635* us_ashift: Arithmetic. (line 173) 57636* us_minus: Arithmetic. (line 38) 57637* us_mult: Arithmetic. (line 93) 57638* us_neg: Arithmetic. (line 82) 57639* us_plus: Arithmetic. (line 14) 57640* us_truncate: Conversions. (line 48) 57641* UTAmode: Machine Modes. (line 174) 57642* UTQmode: Machine Modes. (line 142) 57643* V in constraint: Simple Constraints. (line 43) 57644* values, returned by functions: Scalar Return. (line 6) 57645* varargs implementation: Varargs. (line 6) 57646* variable: Declarations. (line 6) 57647* Variable Location Debug Information in RTL: Debug Information. 57648 (line 6) 57649* VAR_DECL: Declarations. (line 6) 57650* var_location: Debug Information. (line 14) 57651* vashlM3 instruction pattern: Standard Names. (line 882) 57652* vashrM3 instruction pattern: Standard Names. (line 882) 57653* VA_ARG_EXPR: Unary and Binary Expressions. 57654 (line 6) 57655* vcondeqMN instruction pattern: Standard Names. (line 385) 57656* vcondMN instruction pattern: Standard Names. (line 372) 57657* vconduMN instruction pattern: Standard Names. (line 382) 57658* vcond_mask_MN instruction pattern: Standard Names. (line 392) 57659* vector: Containers. (line 6) 57660* vector operations: Vector Operations. (line 6) 57661* VECTOR_CST: Constant expressions. 57662 (line 6) 57663* VECTOR_STORE_FLAG_VALUE: Misc. (line 329) 57664* vec_cmpeqMN instruction pattern: Standard Names. (line 365) 57665* vec_cmpMN instruction pattern: Standard Names. (line 355) 57666* vec_cmpuMN instruction pattern: Standard Names. (line 362) 57667* vec_concat: Vector Operations. (line 29) 57668* VEC_COND_EXPR: Vectors. (line 6) 57669* vec_duplicate: Vector Operations. (line 34) 57670* vec_duplicateM instruction pattern: Standard Names. (line 298) 57671* VEC_DUPLICATE_EXPR: Vectors. (line 6) 57672* vec_extractMN instruction pattern: Standard Names. (line 282) 57673* vec_initMN instruction pattern: Standard Names. (line 291) 57674* vec_load_lanesMN instruction pattern: Standard Names. (line 165) 57675* VEC_LSHIFT_EXPR: Vectors. (line 6) 57676* vec_mask_load_lanesMN instruction pattern: Standard Names. (line 189) 57677* vec_mask_store_lanesMN instruction pattern: Standard Names. 57678 (line 219) 57679* vec_merge: Vector Operations. (line 11) 57680* vec_packs_float_M instruction pattern: Standard Names. (line 694) 57681* vec_packu_float_M instruction pattern: Standard Names. (line 694) 57682* VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6) 57683* VEC_PACK_FLOAT_EXPR: Vectors. (line 6) 57684* VEC_PACK_SAT_EXPR: Vectors. (line 6) 57685* vec_pack_sbool_trunc_M instruction pattern: Standard Names. 57686 (line 671) 57687* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 687) 57688* vec_pack_ssat_M instruction pattern: Standard Names. (line 680) 57689* VEC_PACK_TRUNC_EXPR: Vectors. (line 6) 57690* vec_pack_trunc_M instruction pattern: Standard Names. (line 664) 57691* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 687) 57692* vec_pack_usat_M instruction pattern: Standard Names. (line 680) 57693* vec_permM instruction pattern: Standard Names. (line 434) 57694* vec_permM instruction pattern <1>: Addressing Modes. (line 338) 57695* VEC_RSHIFT_EXPR: Vectors. (line 6) 57696* vec_select: Vector Operations. (line 19) 57697* vec_series: Vector Operations. (line 41) 57698* vec_seriesM instruction pattern: Standard Names. (line 308) 57699* VEC_SERIES_EXPR: Vectors. (line 6) 57700* vec_setM instruction pattern: Standard Names. (line 277) 57701* vec_shl_insert_M instruction pattern: Standard Names. (line 645) 57702* vec_shl_M instruction pattern: Standard Names. (line 652) 57703* vec_shr_M instruction pattern: Standard Names. (line 658) 57704* vec_store_lanesMN instruction pattern: Standard Names. (line 206) 57705* vec_unpacks_float_hi_M instruction pattern: Standard Names. 57706 (line 724) 57707* vec_unpacks_float_lo_M instruction pattern: Standard Names. 57708 (line 724) 57709* vec_unpacks_hi_M instruction pattern: Standard Names. (line 701) 57710* vec_unpacks_lo_M instruction pattern: Standard Names. (line 701) 57711* vec_unpacks_sbool_hi_M instruction pattern: Standard Names. 57712 (line 715) 57713* vec_unpacks_sbool_lo_M instruction pattern: Standard Names. 57714 (line 715) 57715* vec_unpacku_float_hi_M instruction pattern: Standard Names. 57716 (line 724) 57717* vec_unpacku_float_lo_M instruction pattern: Standard Names. 57718 (line 724) 57719* vec_unpacku_hi_M instruction pattern: Standard Names. (line 708) 57720* vec_unpacku_lo_M instruction pattern: Standard Names. (line 708) 57721* VEC_UNPACK_FIX_TRUNC_HI_EXPR: Vectors. (line 6) 57722* VEC_UNPACK_FIX_TRUNC_LO_EXPR: Vectors. (line 6) 57723* VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6) 57724* VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6) 57725* VEC_UNPACK_HI_EXPR: Vectors. (line 6) 57726* VEC_UNPACK_LO_EXPR: Vectors. (line 6) 57727* vec_unpack_sfix_trunc_hi_M instruction pattern: Standard Names. 57728 (line 733) 57729* vec_unpack_sfix_trunc_lo_M instruction pattern: Standard Names. 57730 (line 733) 57731* vec_unpack_ufix_trunc_hi_M instruction pattern: Standard Names. 57732 (line 733) 57733* vec_unpack_ufix_trunc_lo_M instruction pattern: Standard Names. 57734 (line 733) 57735* VEC_WIDEN_MINUS_HI_EXPR: Vectors. (line 6) 57736* VEC_WIDEN_MINUS_LO_EXPR: Vectors. (line 6) 57737* VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6) 57738* VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6) 57739* VEC_WIDEN_PLUS_HI_EXPR: Vectors. (line 6) 57740* VEC_WIDEN_PLUS_LO_EXPR: Vectors. (line 6) 57741* vec_widen_saddl_hi_M instruction pattern: Standard Names. (line 761) 57742* vec_widen_saddl_lo_M instruction pattern: Standard Names. (line 761) 57743* vec_widen_smult_even_M instruction pattern: Standard Names. 57744 (line 743) 57745* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 743) 57746* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 743) 57747* vec_widen_smult_odd_M instruction pattern: Standard Names. (line 743) 57748* vec_widen_sshiftl_hi_M instruction pattern: Standard Names. 57749 (line 754) 57750* vec_widen_sshiftl_lo_M instruction pattern: Standard Names. 57751 (line 754) 57752* vec_widen_ssubl_hi_M instruction pattern: Standard Names. (line 768) 57753* vec_widen_ssubl_lo_M instruction pattern: Standard Names. (line 768) 57754* vec_widen_uaddl_hi_M instruction pattern: Standard Names. (line 761) 57755* vec_widen_uaddl_lo_M instruction pattern: Standard Names. (line 761) 57756* vec_widen_umult_even_M instruction pattern: Standard Names. 57757 (line 743) 57758* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 743) 57759* vec_widen_umult_lo_M instruction pattern: Standard Names. (line 743) 57760* vec_widen_umult_odd_M instruction pattern: Standard Names. (line 743) 57761* vec_widen_ushiftl_hi_M instruction pattern: Standard Names. 57762 (line 754) 57763* vec_widen_ushiftl_lo_M instruction pattern: Standard Names. 57764 (line 754) 57765* vec_widen_usubl_hi_M instruction pattern: Standard Names. (line 768) 57766* vec_widen_usubl_lo_M instruction pattern: Standard Names. (line 768) 57767* verify_flow_info: Maintaining the CFG. 57768 (line 116) 57769* virtual operands: SSA Operands. (line 6) 57770* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 57771* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 57772* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 57773* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 57774* VLIW: Processor pipeline description. 57775 (line 6) 57776* VLIW <1>: Processor pipeline description. 57777 (line 223) 57778* vlshrM3 instruction pattern: Standard Names. (line 882) 57779* VMS: Filesystem. (line 37) 57780* VMS_DEBUGGING_INFO: VMS Debug. (line 8) 57781* VOIDmode: Machine Modes. (line 192) 57782* VOID_TYPE: Types. (line 6) 57783* volatil: Flags. (line 339) 57784* volatil, in insn, call_insn, jump_insn, code_label, jump_table_data, barrier, and note: Flags. 57785 (line 33) 57786* volatil, in label_ref and reg_label: Flags. (line 54) 57787* volatil, in mem, asm_operands, and asm_input: Flags. (line 65) 57788* volatil, in reg: Flags. (line 106) 57789* volatil, in subreg: Flags. (line 184) 57790* volatil, in subreg <1>: Flags. (line 194) 57791* volatil, in symbol_ref: Flags. (line 220) 57792* volatile memory references: Flags. (line 340) 57793* volatile, in prefetch: Flags. (line 92) 57794* voting between constraint alternatives: Class Preferences. (line 6) 57795* vrotlM3 instruction pattern: Standard Names. (line 882) 57796* vrotrM3 instruction pattern: Standard Names. (line 882) 57797* walk_dominator_tree: SSA. (line 195) 57798* walk_gimple_op: Statement and operand traversals. 57799 (line 30) 57800* walk_gimple_seq: Statement and operand traversals. 57801 (line 47) 57802* walk_gimple_stmt: Statement and operand traversals. 57803 (line 10) 57804* WCHAR_TYPE: Type Layout. (line 165) 57805* WCHAR_TYPE_SIZE: Type Layout. (line 173) 57806* which_alternative: Output Statement. (line 58) 57807* WHILE_BODY: Statements for C and C++. 57808 (line 6) 57809* WHILE_COND: Statements for C and C++. 57810 (line 6) 57811* WHILE_STMT: Statements for C and C++. 57812 (line 6) 57813* while_ultMN instruction pattern: Standard Names. (line 320) 57814* whopr: LTO. (line 6) 57815* widen_ssumM3 instruction pattern: Standard Names. (line 611) 57816* widen_usumM3 instruction pattern: Standard Names. (line 612) 57817* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 110) 57818* window_save instruction pattern: Standard Names. (line 2291) 57819* WINT_TYPE: Type Layout. (line 178) 57820* WORDS_BIG_ENDIAN: Storage Layout. (line 28) 57821* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 225) 57822* word_mode: Machine Modes. (line 463) 57823* WORD_REGISTER_OPERATIONS: Misc. (line 53) 57824* wpa: LTO. (line 6) 57825* X in constraint: Simple Constraints. (line 122) 57826* x-HOST: Host Fragment. (line 6) 57827* XCmode: Machine Modes. (line 199) 57828* XCOFF_DEBUGGING_INFO: DBX Options. (line 12) 57829* XEXP: Accessors. (line 6) 57830* XFmode: Machine Modes. (line 82) 57831* XImode: Machine Modes. (line 54) 57832* XINT: Accessors. (line 6) 57833* xm-MACHINE.h: Filesystem. (line 6) 57834* xm-MACHINE.h <1>: Host Misc. (line 6) 57835* xor: Arithmetic. (line 168) 57836* xor, canonicalization of: Insn Canonicalizations. 57837 (line 94) 57838* xorM3 instruction pattern: Standard Names. (line 466) 57839* xorsignM3 instruction pattern: Standard Names. (line 1187) 57840* XSTR: Accessors. (line 6) 57841* XVEC: Accessors. (line 38) 57842* XVECEXP: Accessors. (line 45) 57843* XVECLEN: Accessors. (line 41) 57844* XWINT: Accessors. (line 6) 57845* zero_extend: Conversions. (line 28) 57846* zero_extendMN2 instruction pattern: Standard Names. (line 1651) 57847* zero_extract: Bit-Fields. (line 30) 57848* zero_extract, canonicalization of: Insn Canonicalizations. 57849 (line 103) 57850 57851 57852 57853Tag Table: 57854Node: Top1789 57855Node: Contributing5163 57856Node: Portability5893 57857Node: Interface7681 57858Node: Libgcc10722 57859Node: Integer library routines12549 57860Node: Soft float library routines19517 57861Node: Decimal float library routines31455 57862Node: Fixed-point fractional library routines47213 57863Node: Exception handling routines147609 57864Node: Miscellaneous routines148716 57865Node: Languages150836 57866Node: Source Tree152383 57867Node: Configure Terms152965 57868Node: Top Level155921 57869Node: gcc Directory159506 57870Node: Subdirectories160458 57871Node: Configuration162626 57872Node: Config Fragments163346 57873Node: System Config164571 57874Node: Configuration Files165507 57875Node: Build168123 57876Node: Makefile168535 57877Ref: Makefile-Footnote-1175310 57878Ref: Makefile-Footnote-2175457 57879Node: Library Files175531 57880Node: Headers176093 57881Node: Documentation178176 57882Node: Texinfo Manuals179035 57883Node: Man Page Generation181364 57884Node: Miscellaneous Docs183277 57885Node: Front End184664 57886Node: Front End Directory188343 57887Node: Front End Config189659 57888Node: Front End Makefile192495 57889Node: Back End196263 57890Node: Testsuites201149 57891Node: Test Idioms202138 57892Node: Test Directives205536 57893Node: Directives206063 57894Node: Selectors217838 57895Node: Effective-Target Keywords219194 57896Ref: arm_fp_ok232067 57897Ref: arm_fp_dp_ok232234 57898Ref: arm_neon_ok233267 57899Ref: arm_neon_ok_no_float_abi233436 57900Ref: arm_neonv2_ok233603 57901Ref: arm_fp16_ok233770 57902Ref: arm_neon_fp16_ok234112 57903Ref: arm_vfp3_ok235044 57904Ref: arm_arch_v8a_hard_ok235187 57905Ref: arm_v8_1a_neon_ok235937 57906Ref: arm_v8_2a_fp16_scalar_ok236365 57907Ref: arm_v8_2a_fp16_neon_ok236816 57908Ref: arm_v8_2a_dotprod_neon_ok237291 57909Ref: arm_fp16fml_neon_ok237711 57910Ref: arm_coproc1_ok240211 57911Ref: arm_coproc2_ok240337 57912Ref: arm_coproc3_ok240565 57913Ref: arm_simd32_ok240932 57914Ref: arm_qbit_ok241110 57915Ref: arm_dsp_ok241299 57916Ref: arm_softfp_ok241476 57917Ref: arm_hard_ok241549 57918Ref: arm_v8_1_lob_ok241624 57919Ref: stack_size_et255920 57920Node: Add Options258409 57921Ref: arm_fp16_ieee259647 57922Ref: arm_fp16_alternative259902 57923Ref: stack_size_ao262466 57924Node: Require Support262828 57925Node: Final Actions265730 57926Node: Ada Tests275699 57927Node: C Tests276862 57928Node: LTO Testing281234 57929Node: gcov Testing282877 57930Node: profopt Testing285847 57931Node: compat Testing287562 57932Node: Torture Tests291802 57933Node: GIMPLE Tests293436 57934Node: RTL Tests294678 57935Node: Options295984 57936Node: Option file format296425 57937Node: Option properties303414 57938Node: Passes319500 57939Node: Parsing pass320373 57940Node: Gimplification pass323901 57941Node: Pass manager325734 57942Node: IPA passes327575 57943Node: Small IPA passes328468 57944Node: Regular IPA passes331905 57945Node: Late IPA passes336683 57946Node: Tree SSA passes337642 57947Node: RTL passes359249 57948Node: Optimization info371513 57949Node: Dump setup372332 57950Node: Optimization groups373461 57951Node: Dump files and streams374440 57952Node: Dump output verbosity375638 57953Node: Dump types376694 57954Node: Dump examples379036 57955Node: poly_int380517 57956Node: Overview of poly_int381997 57957Node: Consequences of using poly_int384601 57958Node: Comparisons involving poly_int386236 57959Node: Comparison functions for poly_int387874 57960Node: Properties of the poly_int comparisons389081 57961Node: Comparing potentially-unordered poly_ints391523 57962Node: Comparing ordered poly_ints392434 57963Node: Checking for a poly_int marker value394458 57964Node: Range checks on poly_ints395307 57965Node: Sorting poly_ints397961 57966Node: Arithmetic on poly_ints398734 57967Node: Using poly_int with C++ arithmetic operators399535 57968Node: wi arithmetic on poly_ints401066 57969Node: Division of poly_ints401918 57970Node: Other poly_int arithmetic403425 57971Node: Alignment of poly_ints404831 57972Node: Computing bounds on poly_ints408108 57973Node: Converting poly_ints409497 57974Node: Miscellaneous poly_int routines413044 57975Node: Guidelines for using poly_int413684 57976Node: GENERIC418616 57977Node: Deficiencies420438 57978Node: Tree overview420679 57979Node: Macros and Functions424803 57980Node: Identifiers425628 57981Node: Containers427237 57982Node: Types428394 57983Node: Declarations440805 57984Node: Working with declarations441300 57985Node: Internal structure446904 57986Node: Current structure hierarchy447288 57987Node: Adding new DECL node types449381 57988Node: Attributes453665 57989Node: Expression trees454909 57990Node: Constant expressions456663 57991Node: Storage References462755 57992Node: Unary and Binary Expressions466274 57993Node: Vectors487176 57994Node: Statements495666 57995Node: Basic Statements496198 57996Node: Blocks500973 57997Node: Statement Sequences502674 57998Node: Empty Statements503007 57999Node: Jumps503581 58000Node: Cleanups504234 58001Node: OpenMP506275 58002Node: OpenACC512120 58003Node: Functions513237 58004Node: Function Basics513708 58005Node: Function Properties517392 58006Node: Language-dependent trees520173 58007Node: C and C++ Trees521060 58008Node: Types for C++523945 58009Node: Namespaces528915 58010Node: Classes532021 58011Node: Functions for C++536929 58012Node: Statements for C and C++543186 58013Node: C++ Expressions551693 58014Node: GIMPLE553204 58015Node: Tuple representation556869 58016Node: Class hierarchy of GIMPLE statements563829 58017Node: GIMPLE instruction set568817 58018Node: GIMPLE Exception Handling570449 58019Node: Temporaries572361 58020Ref: Temporaries-Footnote-1573679 58021Node: Operands573744 58022Node: Compound Expressions574505 58023Node: Compound Lvalues574739 58024Node: Conditional Expressions575501 58025Node: Logical Operators576160 58026Node: Manipulating GIMPLE statements583522 58027Node: Tuple specific accessors589458 58028Node: GIMPLE_ASM590237 58029Node: GIMPLE_ASSIGN592620 58030Node: GIMPLE_BIND597324 58031Node: GIMPLE_CALL599138 58032Node: GIMPLE_CATCH603281 58033Node: GIMPLE_COND604431 58034Node: GIMPLE_DEBUG607226 58035Node: GIMPLE_EH_FILTER611824 58036Node: GIMPLE_LABEL613387 58037Node: GIMPLE_GOTO614000 58038Node: GIMPLE_NOP614523 58039Node: GIMPLE_OMP_ATOMIC_LOAD614885 58040Node: GIMPLE_OMP_ATOMIC_STORE615881 58041Node: GIMPLE_OMP_CONTINUE616580 58042Node: GIMPLE_OMP_CRITICAL618059 58043Node: GIMPLE_OMP_FOR619053 58044Node: GIMPLE_OMP_MASTER622469 58045Node: GIMPLE_OMP_ORDERED622847 58046Node: GIMPLE_OMP_PARALLEL623241 58047Node: GIMPLE_OMP_RETURN626010 58048Node: GIMPLE_OMP_SECTION626655 58049Node: GIMPLE_OMP_SECTIONS627315 58050Node: GIMPLE_OMP_SINGLE628925 58051Node: GIMPLE_PHI629871 58052Node: GIMPLE_RESX631150 58053Node: GIMPLE_RETURN631869 58054Node: GIMPLE_SWITCH632443 58055Node: GIMPLE_TRY634318 58056Node: GIMPLE_WITH_CLEANUP_EXPR636090 58057Node: GIMPLE sequences636969 58058Node: Sequence iterators640175 58059Node: Adding a new GIMPLE statement code648632 58060Node: Statement and operand traversals649977 58061Node: Tree SSA652569 58062Node: Annotations654357 58063Node: SSA Operands654762 58064Node: SSA668565 58065Node: Alias analysis678271 58066Node: Memory model682045 58067Node: RTL683404 58068Node: RTL Objects685646 58069Node: RTL Classes689530 58070Node: Accessors694829 58071Node: Special Accessors697002 58072Node: Flags702789 58073Node: Machine Modes718052 58074Node: Constants735676 58075Node: Regs and Memory747475 58076Node: Arithmetic766873 58077Node: Comparisons777048 58078Node: Bit-Fields781340 58079Node: Vector Operations782891 58080Node: Conversions784995 58081Node: RTL Declarations789493 58082Node: Side Effects790337 58083Node: Incdec807346 58084Node: Assembler810682 58085Node: Debug Information812227 58086Node: Insns814154 58087Node: Calls842010 58088Node: RTL SSA844603 58089Node: Using RTL SSA845994 58090Node: RTL SSA Instructions847911 58091Ref: RTL SSA Instructions-Footnote-1849297 58092Node: RTL SSA Basic Blocks849431 58093Ref: real RTL SSA insns849899 58094Ref: RTL SSA Basic Blocks-Footnote-1852121 58095Node: RTL SSA Resources852255 58096Node: RTL SSA Accesses853372 58097Ref: RTL SSA Accesses-Footnote-1855073 58098Node: RTL SSA Phi Nodes855216 58099Node: RTL SSA Access Lists857220 58100Node: Changing RTL Instructions861501 58101Node: Changing One RTL SSA Instruction862110 58102Node: Changing Multiple RTL SSA Instructions867045 58103Node: Sharing871288 58104Node: Reading RTL874485 58105Node: Control Flow875476 58106Node: Basic Blocks877244 58107Node: Edges882698 58108Node: Profile information891317 58109Node: Maintaining the CFG896001 58110Node: Liveness information901769 58111Node: Loop Analysis and Representation903895 58112Node: Loop representation904931 58113Node: Loop querying912297 58114Node: Loop manipulation915118 58115Node: LCSSA917454 58116Node: Scalar evolutions919523 58117Node: loop-iv922767 58118Node: Number of iterations924689 58119Node: Dependency analysis928770 58120Node: Machine Desc935121 58121Node: Overview937684 58122Node: Patterns939724 58123Node: Example944691 58124Node: RTL Template946152 58125Node: Output Template956808 58126Node: Output Statement960989 58127Node: Predicates965328 58128Node: Machine-Independent Predicates968246 58129Node: Defining Predicates973190 58130Node: Constraints979153 58131Node: Simple Constraints980622 58132Node: Multi-Alternative993462 58133Node: Class Preferences996671 58134Node: Modifiers997563 58135Node: Machine Constraints1002297 58136Node: Disable Insn Alternatives1064401 58137Node: Define Constraints1067893 58138Node: C Constraint Interface1076482 58139Node: Standard Names1079609 58140Ref: shift patterns1117829 58141Ref: prologue instruction pattern1177737 58142Ref: window_save instruction pattern1178230 58143Ref: epilogue instruction pattern1178507 58144Node: Pattern Ordering1200483 58145Node: Dependent Patterns1201719 58146Node: Jump Patterns1203339 58147Ref: Jump Patterns-Footnote-11205484 58148Node: Looping Patterns1205532 58149Node: Insn Canonicalizations1211171 58150Node: Expander Definitions1216378 58151Node: Insn Splitting1224592 58152Node: Including Patterns1239622 58153Node: Peephole Definitions1241406 58154Node: define_peephole1242659 58155Node: define_peephole21248989 58156Node: Insn Attributes1253078 58157Node: Defining Attributes1254260 58158Ref: define_enum_attr1257752 58159Node: Expressions1258788 58160Node: Tagging Insns1265538 58161Node: Attr Example1269891 58162Node: Insn Lengths1272264 58163Node: Constant Attributes1275672 58164Node: Mnemonic Attribute1276848 58165Node: Delay Slots1278367 58166Node: Processor pipeline description1281590 58167Ref: Processor pipeline description-Footnote-11300402 58168Node: Conditional Execution1300726 58169Node: Define Subst1304209 58170Node: Define Subst Example1306244 58171Node: Define Subst Pattern Matching1309239 58172Node: Define Subst Output Template1310465 58173Node: Constant Definitions1312788 58174Ref: define_enum1316570 58175Node: Iterators1317058 58176Node: Mode Iterators1317703 58177Node: Defining Mode Iterators1318681 58178Node: Substitutions1320175 58179Node: Examples1322417 58180Node: Code Iterators1323865 58181Node: Int Iterators1326995 58182Node: Subst Iterators1329459 58183Node: Parameterized Names1331179 58184Node: Target Macros1335197 58185Node: Target Structure1338260 58186Node: Driver1340752 58187Node: Run-time Target1359722 58188Node: Per-Function Data1369255 58189Node: Storage Layout1372019 58190Node: Type Layout1399673 58191Node: Registers1413014 58192Node: Register Basics1413988 58193Node: Allocation Order1421550 58194Node: Values in Registers1424034 58195Node: Leaf Functions1431510 58196Node: Stack Registers1434369 58197Node: Register Classes1435641 58198Node: Stack and Calling1470423 58199Node: Frame Layout1471029 58200Node: Exception Handling1482864 58201Node: Stack Checking1489074 58202Node: Frame Registers1494699 58203Node: Elimination1503250 58204Node: Stack Arguments1507106 58205Node: Register Arguments1514302 58206Node: Scalar Return1539163 58207Node: Aggregate Return1545619 58208Node: Caller Saves1550173 58209Node: Function Entry1550915 58210Node: Profiling1562467 58211Node: Tail Calls1564577 58212Node: Shrink-wrapping separate components1566487 58213Node: Stack Smashing Protection1569528 58214Node: Miscellaneous Register Hooks1572017 58215Node: Varargs1572882 58216Node: Trampolines1582282 58217Node: Library Calls1591779 58218Node: Addressing Modes1596865 58219Node: Anchored Addresses1626258 58220Node: Condition Code1628901 58221Node: CC0 Condition Codes1631228 58222Node: MODE_CC Condition Codes1634474 58223Node: Costs1641300 58224Node: Scheduling1663262 58225Node: Sections1687184 58226Node: PIC1703549 58227Node: Assembler Format1705608 58228Node: File Framework1706746 58229Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1714345 58230Node: Data Output1716020 58231Node: Uninitialized Data1724308 58232Node: Label Output1729322 58233Node: Initialization1753933 58234Node: Macros for Initialization1759894 58235Node: Instruction Output1766613 58236Node: Dispatch Tables1777242 58237Node: Exception Region Output1782993 58238Node: Alignment Output1790075 58239Node: Debugging Info1793762 58240Node: All Debuggers1794416 58241Node: DBX Options1797188 58242Node: DBX Hooks1802626 58243Node: File Names and DBX1803935 58244Node: DWARF1806039 58245Node: VMS Debug1811854 58246Node: Floating Point1812433 58247Node: Mode Switching1815188 58248Node: Target Attributes1819625 58249Node: Emulated TLS1829101 58250Node: MIPS Coprocessors1832491 58251Node: PCH Target1833650 58252Node: C++ ABI1835492 58253Node: D Language and ABI1840284 58254Node: Named Address Spaces1843227 58255Node: Misc1849154 58256Ref: TARGET_SHIFT_TRUNCATION_MASK1857025 58257Node: Host Config1916111 58258Node: Host Common1917180 58259Node: Filesystem1919554 58260Node: Host Misc1923669 58261Node: Fragments1926118 58262Node: Target Fragment1927313 58263Node: Host Fragment1938125 58264Node: Collect21938365 58265Node: Header Dirs1941001 58266Node: Type Information1942424 58267Node: GTY Options1945700 58268Node: Inheritance and GTY1956959 58269Ref: Inheritance and GTY-Footnote-11958524 58270Node: User GC1958794 58271Node: GGC Roots1962533 58272Node: Files1963246 58273Node: Invoking the garbage collector1965953 58274Node: Troubleshooting1967458 58275Node: Plugins1968533 58276Node: Plugins loading1969662 58277Node: Plugin API1970761 58278Node: Plugins pass1978628 58279Node: Plugins GC1980599 58280Node: Plugins description1982316 58281Node: Plugins attr1982852 58282Node: Plugins recording1985132 58283Node: Plugins gate1985982 58284Node: Plugins tracking1986573 58285Node: Plugins building1987161 58286Node: LTO1990662 58287Node: LTO Overview1991534 58288Node: LTO object file layout1997361 58289Node: IPA2001991 58290Node: WHOPR2011041 58291Node: Internal flags2015601 58292Node: Match and Simplify2017012 58293Node: GIMPLE API2017974 58294Node: The Language2020769 58295Node: Static Analyzer2033268 58296Node: Analyzer Internals2033533 58297Node: Debugging the Analyzer2049420 58298Node: User Experience Guidelines2051857 58299Node: Guidelines for Diagnostics2052793 58300Ref: input_location_example2060968 58301Node: Guidelines for Options2070653 58302Node: Funding2070830 58303Node: GNU Project2073337 58304Node: Copying2073986 58305Node: GNU Free Documentation License2111497 58306Node: Contributors2136618 58307Node: Option Index2177594 58308Node: Concept Index2178471 58309 58310End Tag Table 58311