1This is gccint.info, produced by makeinfo version 6.1 from gccint.texi. 2 3Copyright (C) 1988-2015 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-2015 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, Up: (DIR) 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 5.5.0. The use of the GNU compilers is documented in a separate 59manual. *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* GENERIC:: Language-independent representation generated by Front Ends 86* GIMPLE:: Tuple representation used by Tree SSA optimizers 87* Tree SSA:: Analysis and optimization of GIMPLE 88* RTL:: Machine-dependent low-level intermediate representation. 89* Control Flow:: Maintaining and manipulating the control flow graph. 90* Loop Analysis and Representation:: Analysis and representation of loops 91* Machine Desc:: How to write machine description instruction patterns. 92* Target Macros:: How to write the machine description C macros and functions. 93* Host Config:: Writing the 'xm-MACHINE.h' file. 94* Fragments:: Writing the 't-TARGET' and 'x-HOST' files. 95* Collect2:: How 'collect2' works; how it finds 'ld'. 96* Header Dirs:: Understanding the standard header file directories. 97* Type Information:: GCC's memory management; generating type information. 98* Plugins:: Extending the compiler with plugins. 99* LTO:: Using Link-Time Optimization. 100 101* Match and Simplify:: How to write expression simplification patterns for GIMPLE and GENERIC 102* Funding:: How to help assure funding for free software. 103* GNU Project:: The GNU Project and GNU/Linux. 104 105* Copying:: GNU General Public License says 106 how you can copy and share GCC. 107* GNU Free Documentation License:: How you can copy and share this manual. 108* Contributors:: People who have contributed to GCC. 109 110* Option Index:: Index to command line options. 111* Concept Index:: Index of concepts and symbol names. 112 113 114File: gccint.info, Node: Contributing, Next: Portability, Up: Top 115 1161 Contributing to GCC Development 117********************************* 118 119If you would like to help pretest GCC releases to assure they work well, 120current development sources are available by SVN (see 121<http://gcc.gnu.org/svn.html>). Source and binary snapshots are also 122available for FTP; see <http://gcc.gnu.org/snapshots.html>. 123 124 If you would like to work on improvements to GCC, please read the 125advice at these URLs: 126 127 <http://gcc.gnu.org/contribute.html> 128 <http://gcc.gnu.org/contributewhy.html> 129 130for information on how to make useful contributions and avoid 131duplication of effort. Suggested projects are listed at 132<http://gcc.gnu.org/projects/>. 133 134 135File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top 136 1372 GCC and Portability 138********************* 139 140GCC itself aims to be portable to any machine where 'int' is at least a 14132-bit type. It aims to target machines with a flat (non-segmented) 142byte addressed data address space (the code address space can be 143separate). Target ABIs may have 8, 16, 32 or 64-bit 'int' type. 'char' 144can be wider than 8 bits. 145 146 GCC gets most of the information about the target machine from a 147machine description which gives an algebraic formula for each of the 148machine's instructions. This is a very clean way to describe the 149target. But when the compiler needs information that is difficult to 150express in this fashion, ad-hoc parameters have been defined for machine 151descriptions. The purpose of portability is to reduce the total work 152needed on the compiler; it was not of interest for its own sake. 153 154 GCC does not contain machine dependent code, but it does contain code 155that depends on machine parameters such as endianness (whether the most 156significant byte has the highest or lowest address of the bytes in a 157word) and the availability of autoincrement addressing. In the 158RTL-generation pass, it is often necessary to have multiple strategies 159for generating code for a particular kind of syntax tree, strategies 160that are usable for different combinations of parameters. Often, not 161all possible cases have been addressed, but only the common ones or only 162the ones that have been encountered. As a result, a new target may 163require additional strategies. You will know if this happens because 164the compiler will call 'abort'. Fortunately, the new strategies can be 165added in a machine-independent fashion, and will affect only the target 166machines that need them. 167 168 169File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top 170 1713 Interfacing to GCC Output 172*************************** 173 174GCC is normally configured to use the same function calling convention 175normally in use on the target system. This is done with the 176machine-description macros described (*note Target Macros::). 177 178 However, returning of structure and union values is done differently on 179some target machines. As a result, functions compiled with PCC 180returning such types cannot be called from code compiled with GCC, and 181vice versa. This does not cause trouble often because few Unix library 182routines return structures or unions. 183 184 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes long 185in the same registers used for 'int' or 'double' return values. (GCC 186typically allocates variables of such types in registers also.) 187Structures and unions of other sizes are returned by storing them into 188an address passed by the caller (usually in a register). The target 189hook 'TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address. 190 191 By contrast, PCC on most target machines returns structures and unions 192of any size by copying the data into an area of static storage, and then 193returning the address of that storage as if it were a pointer value. 194The caller must copy the data from that memory area to the place where 195the value is wanted. This is slower than the method used by GCC, and 196fails to be reentrant. 197 198 On some target machines, such as RISC machines and the 80386, the 199standard system convention is to pass to the subroutine the address of 200where to return the value. On these machines, GCC has been configured 201to be compatible with the standard compiler, when this method is used. 202It may not be compatible for structures of 1, 2, 4 or 8 bytes. 203 204 GCC uses the system's standard convention for passing arguments. On 205some machines, the first few arguments are passed in registers; in 206others, all are passed on the stack. It would be possible to use 207registers for argument passing on any machine, and this would probably 208result in a significant speedup. But the result would be complete 209incompatibility with code that follows the standard convention. So this 210change is practical only if you are switching to GCC as the sole C 211compiler for the system. We may implement register argument passing on 212certain machines once we have a complete GNU system so that we can 213compile the libraries with GCC. 214 215 On some machines (particularly the SPARC), certain types of arguments 216are passed "by invisible reference". This means that the value is 217stored in memory, and the address of the memory location is passed to 218the subroutine. 219 220 If you use 'longjmp', beware of automatic variables. ISO C says that 221automatic variables that are not declared 'volatile' have undefined 222values after a 'longjmp'. And this is all GCC promises to do, because 223it is very difficult to restore register variables correctly, and one of 224GCC's features is that it can put variables in registers without your 225asking it to. 226 227 228File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top 229 2304 The GCC low-level runtime library 231*********************************** 232 233GCC provides a low-level runtime library, 'libgcc.a' or 'libgcc_s.so.1' 234on some platforms. GCC generates calls to routines in this library 235automatically, whenever it needs to perform some operation that is too 236complicated to emit inline code for. 237 238 Most of the routines in 'libgcc' handle arithmetic operations that the 239target processor cannot perform directly. This includes integer 240multiply and divide on some machines, and all floating-point and 241fixed-point operations on other machines. 'libgcc' also includes 242routines for exception handling, and a handful of miscellaneous 243operations. 244 245 Some of these routines can be defined in mostly machine-independent C. 246Others must be hand-written in assembly language for each processor that 247needs them. 248 249 GCC will also generate calls to C library routines, such as 'memcpy' 250and 'memset', in some cases. The set of routines that GCC may possibly 251use is documented in *note (gcc)Other Builtins::. 252 253 These routines take arguments and return values of a specific machine 254mode, not a specific C type. *Note Machine Modes::, for an explanation 255of this concept. For illustrative purposes, in this chapter the 256floating point type 'float' is assumed to correspond to 'SFmode'; 257'double' to 'DFmode'; and 'long double' to both 'TFmode' and 'XFmode'. 258Similarly, the integer types 'int' and 'unsigned int' correspond to 259'SImode'; 'long' and 'unsigned long' to 'DImode'; and 'long long' and 260'unsigned long long' to 'TImode'. 261 262* Menu: 263 264* Integer library routines:: 265* Soft float library routines:: 266* Decimal float library routines:: 267* Fixed-point fractional library routines:: 268* Exception handling routines:: 269* Miscellaneous routines:: 270 271 272File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc 273 2744.1 Routines for integer arithmetic 275=================================== 276 277The integer arithmetic routines are used on platforms that don't provide 278hardware support for arithmetic operations on some modes. 279 2804.1.1 Arithmetic functions 281-------------------------- 282 283 -- Runtime Function: int __ashlsi3 (int A, int B) 284 -- Runtime Function: long __ashldi3 (long A, int B) 285 -- Runtime Function: long long __ashlti3 (long long A, int B) 286 These functions return the result of shifting A left by B bits. 287 288 -- Runtime Function: int __ashrsi3 (int A, int B) 289 -- Runtime Function: long __ashrdi3 (long A, int B) 290 -- Runtime Function: long long __ashrti3 (long long A, int B) 291 These functions return the result of arithmetically shifting A 292 right by B bits. 293 294 -- Runtime Function: int __divsi3 (int A, int B) 295 -- Runtime Function: long __divdi3 (long A, long B) 296 -- Runtime Function: long long __divti3 (long long A, long long B) 297 These functions return the quotient of the signed division of A and 298 B. 299 300 -- Runtime Function: int __lshrsi3 (int A, int B) 301 -- Runtime Function: long __lshrdi3 (long A, int B) 302 -- Runtime Function: long long __lshrti3 (long long A, int B) 303 These functions return the result of logically shifting A right by 304 B bits. 305 306 -- Runtime Function: int __modsi3 (int A, int B) 307 -- Runtime Function: long __moddi3 (long A, long B) 308 -- Runtime Function: long long __modti3 (long long A, long long B) 309 These functions return the remainder of the signed division of A 310 and B. 311 312 -- Runtime Function: int __mulsi3 (int A, int B) 313 -- Runtime Function: long __muldi3 (long A, long B) 314 -- Runtime Function: long long __multi3 (long long A, long long B) 315 These functions return the product of A and B. 316 317 -- Runtime Function: long __negdi2 (long A) 318 -- Runtime Function: long long __negti2 (long long A) 319 These functions return the negation of A. 320 321 -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned 322 int B) 323 -- Runtime Function: unsigned long __udivdi3 (unsigned long A, unsigned 324 long B) 325 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 326 A, unsigned long long B) 327 These functions return the quotient of the unsigned division of A 328 and B. 329 330 -- Runtime Function: unsigned long __udivmoddi4 (unsigned long A, 331 unsigned long B, unsigned long *C) 332 -- Runtime Function: unsigned long long __udivmodti4 (unsigned long 333 long A, unsigned long long B, unsigned long long *C) 334 These functions calculate both the quotient and remainder of the 335 unsigned division of A and B. The return value is the quotient, 336 and the remainder is placed in variable pointed to by C. 337 338 -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned 339 int B) 340 -- Runtime Function: unsigned long __umoddi3 (unsigned long A, unsigned 341 long B) 342 -- Runtime Function: unsigned long long __umodti3 (unsigned long long 343 A, unsigned long long B) 344 These functions return the remainder of the unsigned division of A 345 and B. 346 3474.1.2 Comparison functions 348-------------------------- 349 350The following functions implement integral comparisons. These functions 351implement a low-level compare, upon which the higher level comparison 352operators (such as less than and greater than or equal to) can be 353constructed. The returned values lie in the range zero to two, to allow 354the high-level operators to be implemented by testing the returned 355result using either signed or unsigned comparison. 356 357 -- Runtime Function: int __cmpdi2 (long A, long B) 358 -- Runtime Function: int __cmpti2 (long long A, long long B) 359 These functions perform a signed comparison of A and B. If A is 360 less than B, they return 0; if A is greater than B, they return 2; 361 and if A and B are equal they return 1. 362 363 -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B) 364 -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned long 365 long B) 366 These functions perform an unsigned comparison of A and B. If A is 367 less than B, they return 0; if A is greater than B, they return 2; 368 and if A and B are equal they return 1. 369 3704.1.3 Trapping arithmetic functions 371----------------------------------- 372 373The following functions implement trapping arithmetic. These functions 374call the libc function 'abort' upon signed arithmetic overflow. 375 376 -- Runtime Function: int __absvsi2 (int A) 377 -- Runtime Function: long __absvdi2 (long A) 378 These functions return the absolute value of A. 379 380 -- Runtime Function: int __addvsi3 (int A, int B) 381 -- Runtime Function: long __addvdi3 (long A, long B) 382 These functions return the sum of A and B; that is 'A + B'. 383 384 -- Runtime Function: int __mulvsi3 (int A, int B) 385 -- Runtime Function: long __mulvdi3 (long A, long B) 386 The functions return the product of A and B; that is 'A * B'. 387 388 -- Runtime Function: int __negvsi2 (int A) 389 -- Runtime Function: long __negvdi2 (long A) 390 These functions return the negation of A; that is '-A'. 391 392 -- Runtime Function: int __subvsi3 (int A, int B) 393 -- Runtime Function: long __subvdi3 (long A, long B) 394 These functions return the difference between B and A; that is 'A - 395 B'. 396 3974.1.4 Bit operations 398-------------------- 399 400 -- Runtime Function: int __clzsi2 (unsigned int A) 401 -- Runtime Function: int __clzdi2 (unsigned long A) 402 -- Runtime Function: int __clzti2 (unsigned long long A) 403 These functions return the number of leading 0-bits in A, starting 404 at the most significant bit position. If A is zero, the result is 405 undefined. 406 407 -- Runtime Function: int __ctzsi2 (unsigned int A) 408 -- Runtime Function: int __ctzdi2 (unsigned long A) 409 -- Runtime Function: int __ctzti2 (unsigned long long A) 410 These functions return the number of trailing 0-bits in A, starting 411 at the least significant bit position. If A is zero, the result is 412 undefined. 413 414 -- Runtime Function: int __ffsdi2 (unsigned long A) 415 -- Runtime Function: int __ffsti2 (unsigned long long A) 416 These functions return the index of the least significant 1-bit in 417 A, or the value zero if A is zero. The least significant bit is 418 index one. 419 420 -- Runtime Function: int __paritysi2 (unsigned int A) 421 -- Runtime Function: int __paritydi2 (unsigned long A) 422 -- Runtime Function: int __parityti2 (unsigned long long A) 423 These functions return the value zero if the number of bits set in 424 A is even, and the value one otherwise. 425 426 -- Runtime Function: int __popcountsi2 (unsigned int A) 427 -- Runtime Function: int __popcountdi2 (unsigned long A) 428 -- Runtime Function: int __popcountti2 (unsigned long long A) 429 These functions return the number of bits set in A. 430 431 -- Runtime Function: int32_t __bswapsi2 (int32_t A) 432 -- Runtime Function: int64_t __bswapdi2 (int64_t A) 433 These functions return the A byteswapped. 434 435 436File: gccint.info, Node: Soft float library routines, Next: Decimal float library routines, Prev: Integer library routines, Up: Libgcc 437 4384.2 Routines for floating point emulation 439========================================= 440 441The software floating point library is used on machines which do not 442have hardware support for floating point. It is also used whenever 443'-msoft-float' is used to disable generation of floating point 444instructions. (Not all targets support this switch.) 445 446 For compatibility with other compilers, the floating point emulation 447routines can be renamed with the 'DECLARE_LIBRARY_RENAMES' macro (*note 448Library Calls::). In this section, the default names are used. 449 450 Presently the library does not support 'XFmode', which is used for 451'long double' on some architectures. 452 4534.2.1 Arithmetic functions 454-------------------------- 455 456 -- Runtime Function: float __addsf3 (float A, float B) 457 -- Runtime Function: double __adddf3 (double A, double B) 458 -- Runtime Function: long double __addtf3 (long double A, long double 459 B) 460 -- Runtime Function: long double __addxf3 (long double A, long double 461 B) 462 These functions return the sum of A and B. 463 464 -- Runtime Function: float __subsf3 (float A, float B) 465 -- Runtime Function: double __subdf3 (double A, double B) 466 -- Runtime Function: long double __subtf3 (long double A, long double 467 B) 468 -- Runtime Function: long double __subxf3 (long double A, long double 469 B) 470 These functions return the difference between B and A; that is, 471 A - B. 472 473 -- Runtime Function: float __mulsf3 (float A, float B) 474 -- Runtime Function: double __muldf3 (double A, double B) 475 -- Runtime Function: long double __multf3 (long double A, long double 476 B) 477 -- Runtime Function: long double __mulxf3 (long double A, long double 478 B) 479 These functions return the product of A and B. 480 481 -- Runtime Function: float __divsf3 (float A, float B) 482 -- Runtime Function: double __divdf3 (double A, double B) 483 -- Runtime Function: long double __divtf3 (long double A, long double 484 B) 485 -- Runtime Function: long double __divxf3 (long double A, long double 486 B) 487 These functions return the quotient of A and B; that is, A / B. 488 489 -- Runtime Function: float __negsf2 (float A) 490 -- Runtime Function: double __negdf2 (double A) 491 -- Runtime Function: long double __negtf2 (long double A) 492 -- Runtime Function: long double __negxf2 (long double A) 493 These functions return the negation of A. They simply flip the 494 sign bit, so they can produce negative zero and negative NaN. 495 4964.2.2 Conversion functions 497-------------------------- 498 499 -- Runtime Function: double __extendsfdf2 (float A) 500 -- Runtime Function: long double __extendsftf2 (float A) 501 -- Runtime Function: long double __extendsfxf2 (float A) 502 -- Runtime Function: long double __extenddftf2 (double A) 503 -- Runtime Function: long double __extenddfxf2 (double A) 504 These functions extend A to the wider mode of their return type. 505 506 -- Runtime Function: double __truncxfdf2 (long double A) 507 -- Runtime Function: double __trunctfdf2 (long double A) 508 -- Runtime Function: float __truncxfsf2 (long double A) 509 -- Runtime Function: float __trunctfsf2 (long double A) 510 -- Runtime Function: float __truncdfsf2 (double A) 511 These functions truncate A to the narrower mode of their return 512 type, rounding toward zero. 513 514 -- Runtime Function: int __fixsfsi (float A) 515 -- Runtime Function: int __fixdfsi (double A) 516 -- Runtime Function: int __fixtfsi (long double A) 517 -- Runtime Function: int __fixxfsi (long double A) 518 These functions convert A to a signed integer, rounding toward 519 zero. 520 521 -- Runtime Function: long __fixsfdi (float A) 522 -- Runtime Function: long __fixdfdi (double A) 523 -- Runtime Function: long __fixtfdi (long double A) 524 -- Runtime Function: long __fixxfdi (long double A) 525 These functions convert A to a signed long, rounding toward zero. 526 527 -- Runtime Function: long long __fixsfti (float A) 528 -- Runtime Function: long long __fixdfti (double A) 529 -- Runtime Function: long long __fixtfti (long double A) 530 -- Runtime Function: long long __fixxfti (long double A) 531 These functions convert A to a signed long long, rounding toward 532 zero. 533 534 -- Runtime Function: unsigned int __fixunssfsi (float A) 535 -- Runtime Function: unsigned int __fixunsdfsi (double A) 536 -- Runtime Function: unsigned int __fixunstfsi (long double A) 537 -- Runtime Function: unsigned int __fixunsxfsi (long double A) 538 These functions convert A to an unsigned integer, rounding toward 539 zero. Negative values all become zero. 540 541 -- Runtime Function: unsigned long __fixunssfdi (float A) 542 -- Runtime Function: unsigned long __fixunsdfdi (double A) 543 -- Runtime Function: unsigned long __fixunstfdi (long double A) 544 -- Runtime Function: unsigned long __fixunsxfdi (long double A) 545 These functions convert A to an unsigned long, rounding toward 546 zero. Negative values all become zero. 547 548 -- Runtime Function: unsigned long long __fixunssfti (float A) 549 -- Runtime Function: unsigned long long __fixunsdfti (double A) 550 -- Runtime Function: unsigned long long __fixunstfti (long double A) 551 -- Runtime Function: unsigned long long __fixunsxfti (long double A) 552 These functions convert A to an unsigned long long, rounding toward 553 zero. Negative values all become zero. 554 555 -- Runtime Function: float __floatsisf (int I) 556 -- Runtime Function: double __floatsidf (int I) 557 -- Runtime Function: long double __floatsitf (int I) 558 -- Runtime Function: long double __floatsixf (int I) 559 These functions convert I, a signed integer, to floating point. 560 561 -- Runtime Function: float __floatdisf (long I) 562 -- Runtime Function: double __floatdidf (long I) 563 -- Runtime Function: long double __floatditf (long I) 564 -- Runtime Function: long double __floatdixf (long I) 565 These functions convert I, a signed long, to floating point. 566 567 -- Runtime Function: float __floattisf (long long I) 568 -- Runtime Function: double __floattidf (long long I) 569 -- Runtime Function: long double __floattitf (long long I) 570 -- Runtime Function: long double __floattixf (long long I) 571 These functions convert I, a signed long long, to floating point. 572 573 -- Runtime Function: float __floatunsisf (unsigned int I) 574 -- Runtime Function: double __floatunsidf (unsigned int I) 575 -- Runtime Function: long double __floatunsitf (unsigned int I) 576 -- Runtime Function: long double __floatunsixf (unsigned int I) 577 These functions convert I, an unsigned integer, to floating point. 578 579 -- Runtime Function: float __floatundisf (unsigned long I) 580 -- Runtime Function: double __floatundidf (unsigned long I) 581 -- Runtime Function: long double __floatunditf (unsigned long I) 582 -- Runtime Function: long double __floatundixf (unsigned long I) 583 These functions convert I, an unsigned long, to floating point. 584 585 -- Runtime Function: float __floatuntisf (unsigned long long I) 586 -- Runtime Function: double __floatuntidf (unsigned long long I) 587 -- Runtime Function: long double __floatuntitf (unsigned long long I) 588 -- Runtime Function: long double __floatuntixf (unsigned long long I) 589 These functions convert I, an unsigned long long, to floating 590 point. 591 5924.2.3 Comparison functions 593-------------------------- 594 595There are two sets of basic comparison functions. 596 597 -- Runtime Function: int __cmpsf2 (float A, float B) 598 -- Runtime Function: int __cmpdf2 (double A, double B) 599 -- Runtime Function: int __cmptf2 (long double A, long double B) 600 These functions calculate a <=> b. That is, if A is less than B, 601 they return -1; if A is greater than B, they return 1; and if A and 602 B are equal they return 0. If either argument is NaN they return 603 1, but you should not rely on this; if NaN is a possibility, use 604 one of the higher-level comparison functions. 605 606 -- Runtime Function: int __unordsf2 (float A, float B) 607 -- Runtime Function: int __unorddf2 (double A, double B) 608 -- Runtime Function: int __unordtf2 (long double A, long double B) 609 These functions return a nonzero value if either argument is NaN, 610 otherwise 0. 611 612 There is also a complete group of higher level functions which 613correspond directly to comparison operators. They implement the ISO C 614semantics for floating-point comparisons, taking NaN into account. Pay 615careful attention to the return values defined for each set. Under the 616hood, all of these routines are implemented as 617 618 if (__unordXf2 (a, b)) 619 return E; 620 return __cmpXf2 (a, b); 621 622where E is a constant chosen to give the proper behavior for NaN. Thus, 623the meaning of the return value is different for each set. Do not rely 624on this implementation; only the semantics documented below are 625guaranteed. 626 627 -- Runtime Function: int __eqsf2 (float A, float B) 628 -- Runtime Function: int __eqdf2 (double A, double B) 629 -- Runtime Function: int __eqtf2 (long double A, long double B) 630 These functions return zero if neither argument is NaN, and A and B 631 are equal. 632 633 -- Runtime Function: int __nesf2 (float A, float B) 634 -- Runtime Function: int __nedf2 (double A, double B) 635 -- Runtime Function: int __netf2 (long double A, long double B) 636 These functions return a nonzero value if either argument is NaN, 637 or if A and B are unequal. 638 639 -- Runtime Function: int __gesf2 (float A, float B) 640 -- Runtime Function: int __gedf2 (double A, double B) 641 -- Runtime Function: int __getf2 (long double A, long double B) 642 These functions return a value greater than or equal to zero if 643 neither argument is NaN, and A is greater than or equal to B. 644 645 -- Runtime Function: int __ltsf2 (float A, float B) 646 -- Runtime Function: int __ltdf2 (double A, double B) 647 -- Runtime Function: int __lttf2 (long double A, long double B) 648 These functions return a value less than zero if neither argument 649 is NaN, and A is strictly less than B. 650 651 -- Runtime Function: int __lesf2 (float A, float B) 652 -- Runtime Function: int __ledf2 (double A, double B) 653 -- Runtime Function: int __letf2 (long double A, long double B) 654 These functions return a value less than or equal to zero if 655 neither argument is NaN, and A is less than or equal to B. 656 657 -- Runtime Function: int __gtsf2 (float A, float B) 658 -- Runtime Function: int __gtdf2 (double A, double B) 659 -- Runtime Function: int __gttf2 (long double A, long double B) 660 These functions return a value greater than zero if neither 661 argument is NaN, and A is strictly greater than B. 662 6634.2.4 Other floating-point functions 664------------------------------------ 665 666 -- Runtime Function: float __powisf2 (float A, int B) 667 -- Runtime Function: double __powidf2 (double A, int B) 668 -- Runtime Function: long double __powitf2 (long double A, int B) 669 -- Runtime Function: long double __powixf2 (long double A, int B) 670 These functions convert raise A to the power B. 671 672 -- Runtime Function: complex float __mulsc3 (float A, float B, float C, 673 float D) 674 -- Runtime Function: complex double __muldc3 (double A, double B, 675 double C, double D) 676 -- Runtime Function: complex long double __multc3 (long double A, long 677 double B, long double C, long double D) 678 -- Runtime Function: complex long double __mulxc3 (long double A, long 679 double B, long double C, long double D) 680 These functions return the product of A + iB and C + iD, following 681 the rules of C99 Annex G. 682 683 -- Runtime Function: complex float __divsc3 (float A, float B, float C, 684 float D) 685 -- Runtime Function: complex double __divdc3 (double A, double B, 686 double C, double D) 687 -- Runtime Function: complex long double __divtc3 (long double A, long 688 double B, long double C, long double D) 689 -- Runtime Function: complex long double __divxc3 (long double A, long 690 double B, long double C, long double D) 691 These functions return the quotient of A + iB and C + iD (i.e., (A 692 + iB) / (C + iD)), following the rules of C99 Annex G. 693 694 695File: gccint.info, Node: Decimal float library routines, Next: Fixed-point fractional library routines, Prev: Soft float library routines, Up: Libgcc 696 6974.3 Routines for decimal floating point emulation 698================================================= 699 700The software decimal floating point library implements IEEE 754-2008 701decimal floating point arithmetic and is only activated on selected 702targets. 703 704 The software decimal floating point library supports either DPD 705(Densely Packed Decimal) or BID (Binary Integer Decimal) encoding as 706selected at configure time. 707 7084.3.1 Arithmetic functions 709-------------------------- 710 711 -- Runtime Function: _Decimal32 __dpd_addsd3 (_Decimal32 A, _Decimal32 712 B) 713 -- Runtime Function: _Decimal32 __bid_addsd3 (_Decimal32 A, _Decimal32 714 B) 715 -- Runtime Function: _Decimal64 __dpd_adddd3 (_Decimal64 A, _Decimal64 716 B) 717 -- Runtime Function: _Decimal64 __bid_adddd3 (_Decimal64 A, _Decimal64 718 B) 719 -- Runtime Function: _Decimal128 __dpd_addtd3 (_Decimal128 A, 720 _Decimal128 B) 721 -- Runtime Function: _Decimal128 __bid_addtd3 (_Decimal128 A, 722 _Decimal128 B) 723 These functions return the sum of A and B. 724 725 -- Runtime Function: _Decimal32 __dpd_subsd3 (_Decimal32 A, _Decimal32 726 B) 727 -- Runtime Function: _Decimal32 __bid_subsd3 (_Decimal32 A, _Decimal32 728 B) 729 -- Runtime Function: _Decimal64 __dpd_subdd3 (_Decimal64 A, _Decimal64 730 B) 731 -- Runtime Function: _Decimal64 __bid_subdd3 (_Decimal64 A, _Decimal64 732 B) 733 -- Runtime Function: _Decimal128 __dpd_subtd3 (_Decimal128 A, 734 _Decimal128 B) 735 -- Runtime Function: _Decimal128 __bid_subtd3 (_Decimal128 A, 736 _Decimal128 B) 737 These functions return the difference between B and A; that is, 738 A - B. 739 740 -- Runtime Function: _Decimal32 __dpd_mulsd3 (_Decimal32 A, _Decimal32 741 B) 742 -- Runtime Function: _Decimal32 __bid_mulsd3 (_Decimal32 A, _Decimal32 743 B) 744 -- Runtime Function: _Decimal64 __dpd_muldd3 (_Decimal64 A, _Decimal64 745 B) 746 -- Runtime Function: _Decimal64 __bid_muldd3 (_Decimal64 A, _Decimal64 747 B) 748 -- Runtime Function: _Decimal128 __dpd_multd3 (_Decimal128 A, 749 _Decimal128 B) 750 -- Runtime Function: _Decimal128 __bid_multd3 (_Decimal128 A, 751 _Decimal128 B) 752 These functions return the product of A and B. 753 754 -- Runtime Function: _Decimal32 __dpd_divsd3 (_Decimal32 A, _Decimal32 755 B) 756 -- Runtime Function: _Decimal32 __bid_divsd3 (_Decimal32 A, _Decimal32 757 B) 758 -- Runtime Function: _Decimal64 __dpd_divdd3 (_Decimal64 A, _Decimal64 759 B) 760 -- Runtime Function: _Decimal64 __bid_divdd3 (_Decimal64 A, _Decimal64 761 B) 762 -- Runtime Function: _Decimal128 __dpd_divtd3 (_Decimal128 A, 763 _Decimal128 B) 764 -- Runtime Function: _Decimal128 __bid_divtd3 (_Decimal128 A, 765 _Decimal128 B) 766 These functions return the quotient of A and B; that is, A / B. 767 768 -- Runtime Function: _Decimal32 __dpd_negsd2 (_Decimal32 A) 769 -- Runtime Function: _Decimal32 __bid_negsd2 (_Decimal32 A) 770 -- Runtime Function: _Decimal64 __dpd_negdd2 (_Decimal64 A) 771 -- Runtime Function: _Decimal64 __bid_negdd2 (_Decimal64 A) 772 -- Runtime Function: _Decimal128 __dpd_negtd2 (_Decimal128 A) 773 -- Runtime Function: _Decimal128 __bid_negtd2 (_Decimal128 A) 774 These functions return the negation of A. They simply flip the 775 sign bit, so they can produce negative zero and negative NaN. 776 7774.3.2 Conversion functions 778-------------------------- 779 780 -- Runtime Function: _Decimal64 __dpd_extendsddd2 (_Decimal32 A) 781 -- Runtime Function: _Decimal64 __bid_extendsddd2 (_Decimal32 A) 782 -- Runtime Function: _Decimal128 __dpd_extendsdtd2 (_Decimal32 A) 783 -- Runtime Function: _Decimal128 __bid_extendsdtd2 (_Decimal32 A) 784 -- Runtime Function: _Decimal128 __dpd_extendddtd2 (_Decimal64 A) 785 -- Runtime Function: _Decimal128 __bid_extendddtd2 (_Decimal64 A) 786 -- Runtime Function: _Decimal32 __dpd_truncddsd2 (_Decimal64 A) 787 -- Runtime Function: _Decimal32 __bid_truncddsd2 (_Decimal64 A) 788 -- Runtime Function: _Decimal32 __dpd_trunctdsd2 (_Decimal128 A) 789 -- Runtime Function: _Decimal32 __bid_trunctdsd2 (_Decimal128 A) 790 -- Runtime Function: _Decimal64 __dpd_trunctddd2 (_Decimal128 A) 791 -- Runtime Function: _Decimal64 __bid_trunctddd2 (_Decimal128 A) 792 These functions convert the value A from one decimal floating type 793 to another. 794 795 -- Runtime Function: _Decimal64 __dpd_extendsfdd (float A) 796 -- Runtime Function: _Decimal64 __bid_extendsfdd (float A) 797 -- Runtime Function: _Decimal128 __dpd_extendsftd (float A) 798 -- Runtime Function: _Decimal128 __bid_extendsftd (float A) 799 -- Runtime Function: _Decimal128 __dpd_extenddftd (double A) 800 -- Runtime Function: _Decimal128 __bid_extenddftd (double A) 801 -- Runtime Function: _Decimal128 __dpd_extendxftd (long double A) 802 -- Runtime Function: _Decimal128 __bid_extendxftd (long double A) 803 -- Runtime Function: _Decimal32 __dpd_truncdfsd (double A) 804 -- Runtime Function: _Decimal32 __bid_truncdfsd (double A) 805 -- Runtime Function: _Decimal32 __dpd_truncxfsd (long double A) 806 -- Runtime Function: _Decimal32 __bid_truncxfsd (long double A) 807 -- Runtime Function: _Decimal32 __dpd_trunctfsd (long double A) 808 -- Runtime Function: _Decimal32 __bid_trunctfsd (long double A) 809 -- Runtime Function: _Decimal64 __dpd_truncxfdd (long double A) 810 -- Runtime Function: _Decimal64 __bid_truncxfdd (long double A) 811 -- Runtime Function: _Decimal64 __dpd_trunctfdd (long double A) 812 -- Runtime Function: _Decimal64 __bid_trunctfdd (long double A) 813 These functions convert the value of A from a binary floating type 814 to a decimal floating type of a different size. 815 816 -- Runtime Function: float __dpd_truncddsf (_Decimal64 A) 817 -- Runtime Function: float __bid_truncddsf (_Decimal64 A) 818 -- Runtime Function: float __dpd_trunctdsf (_Decimal128 A) 819 -- Runtime Function: float __bid_trunctdsf (_Decimal128 A) 820 -- Runtime Function: double __dpd_extendsddf (_Decimal32 A) 821 -- Runtime Function: double __bid_extendsddf (_Decimal32 A) 822 -- Runtime Function: double __dpd_trunctddf (_Decimal128 A) 823 -- Runtime Function: double __bid_trunctddf (_Decimal128 A) 824 -- Runtime Function: long double __dpd_extendsdxf (_Decimal32 A) 825 -- Runtime Function: long double __bid_extendsdxf (_Decimal32 A) 826 -- Runtime Function: long double __dpd_extendddxf (_Decimal64 A) 827 -- Runtime Function: long double __bid_extendddxf (_Decimal64 A) 828 -- Runtime Function: long double __dpd_trunctdxf (_Decimal128 A) 829 -- Runtime Function: long double __bid_trunctdxf (_Decimal128 A) 830 -- Runtime Function: long double __dpd_extendsdtf (_Decimal32 A) 831 -- Runtime Function: long double __bid_extendsdtf (_Decimal32 A) 832 -- Runtime Function: long double __dpd_extendddtf (_Decimal64 A) 833 -- Runtime Function: long double __bid_extendddtf (_Decimal64 A) 834 These functions convert the value of A from a decimal floating type 835 to a binary floating type of a different size. 836 837 -- Runtime Function: _Decimal32 __dpd_extendsfsd (float A) 838 -- Runtime Function: _Decimal32 __bid_extendsfsd (float A) 839 -- Runtime Function: _Decimal64 __dpd_extenddfdd (double A) 840 -- Runtime Function: _Decimal64 __bid_extenddfdd (double A) 841 -- Runtime Function: _Decimal128 __dpd_extendtftd (long double A) 842 -- Runtime Function: _Decimal128 __bid_extendtftd (long double A) 843 -- Runtime Function: float __dpd_truncsdsf (_Decimal32 A) 844 -- Runtime Function: float __bid_truncsdsf (_Decimal32 A) 845 -- Runtime Function: double __dpd_truncdddf (_Decimal64 A) 846 -- Runtime Function: double __bid_truncdddf (_Decimal64 A) 847 -- Runtime Function: long double __dpd_trunctdtf (_Decimal128 A) 848 -- Runtime Function: long double __bid_trunctdtf (_Decimal128 A) 849 These functions convert the value of A between decimal and binary 850 floating types of the same size. 851 852 -- Runtime Function: int __dpd_fixsdsi (_Decimal32 A) 853 -- Runtime Function: int __bid_fixsdsi (_Decimal32 A) 854 -- Runtime Function: int __dpd_fixddsi (_Decimal64 A) 855 -- Runtime Function: int __bid_fixddsi (_Decimal64 A) 856 -- Runtime Function: int __dpd_fixtdsi (_Decimal128 A) 857 -- Runtime Function: int __bid_fixtdsi (_Decimal128 A) 858 These functions convert A to a signed integer. 859 860 -- Runtime Function: long __dpd_fixsddi (_Decimal32 A) 861 -- Runtime Function: long __bid_fixsddi (_Decimal32 A) 862 -- Runtime Function: long __dpd_fixdddi (_Decimal64 A) 863 -- Runtime Function: long __bid_fixdddi (_Decimal64 A) 864 -- Runtime Function: long __dpd_fixtddi (_Decimal128 A) 865 -- Runtime Function: long __bid_fixtddi (_Decimal128 A) 866 These functions convert A to a signed long. 867 868 -- Runtime Function: unsigned int __dpd_fixunssdsi (_Decimal32 A) 869 -- Runtime Function: unsigned int __bid_fixunssdsi (_Decimal32 A) 870 -- Runtime Function: unsigned int __dpd_fixunsddsi (_Decimal64 A) 871 -- Runtime Function: unsigned int __bid_fixunsddsi (_Decimal64 A) 872 -- Runtime Function: unsigned int __dpd_fixunstdsi (_Decimal128 A) 873 -- Runtime Function: unsigned int __bid_fixunstdsi (_Decimal128 A) 874 These functions convert A to an unsigned integer. Negative values 875 all become zero. 876 877 -- Runtime Function: unsigned long __dpd_fixunssddi (_Decimal32 A) 878 -- Runtime Function: unsigned long __bid_fixunssddi (_Decimal32 A) 879 -- Runtime Function: unsigned long __dpd_fixunsdddi (_Decimal64 A) 880 -- Runtime Function: unsigned long __bid_fixunsdddi (_Decimal64 A) 881 -- Runtime Function: unsigned long __dpd_fixunstddi (_Decimal128 A) 882 -- Runtime Function: unsigned long __bid_fixunstddi (_Decimal128 A) 883 These functions convert A to an unsigned long. Negative values all 884 become zero. 885 886 -- Runtime Function: _Decimal32 __dpd_floatsisd (int I) 887 -- Runtime Function: _Decimal32 __bid_floatsisd (int I) 888 -- Runtime Function: _Decimal64 __dpd_floatsidd (int I) 889 -- Runtime Function: _Decimal64 __bid_floatsidd (int I) 890 -- Runtime Function: _Decimal128 __dpd_floatsitd (int I) 891 -- Runtime Function: _Decimal128 __bid_floatsitd (int I) 892 These functions convert I, a signed integer, to decimal floating 893 point. 894 895 -- Runtime Function: _Decimal32 __dpd_floatdisd (long I) 896 -- Runtime Function: _Decimal32 __bid_floatdisd (long I) 897 -- Runtime Function: _Decimal64 __dpd_floatdidd (long I) 898 -- Runtime Function: _Decimal64 __bid_floatdidd (long I) 899 -- Runtime Function: _Decimal128 __dpd_floatditd (long I) 900 -- Runtime Function: _Decimal128 __bid_floatditd (long I) 901 These functions convert I, a signed long, to decimal floating 902 point. 903 904 -- Runtime Function: _Decimal32 __dpd_floatunssisd (unsigned int I) 905 -- Runtime Function: _Decimal32 __bid_floatunssisd (unsigned int I) 906 -- Runtime Function: _Decimal64 __dpd_floatunssidd (unsigned int I) 907 -- Runtime Function: _Decimal64 __bid_floatunssidd (unsigned int I) 908 -- Runtime Function: _Decimal128 __dpd_floatunssitd (unsigned int I) 909 -- Runtime Function: _Decimal128 __bid_floatunssitd (unsigned int I) 910 These functions convert I, an unsigned integer, to decimal floating 911 point. 912 913 -- Runtime Function: _Decimal32 __dpd_floatunsdisd (unsigned long I) 914 -- Runtime Function: _Decimal32 __bid_floatunsdisd (unsigned long I) 915 -- Runtime Function: _Decimal64 __dpd_floatunsdidd (unsigned long I) 916 -- Runtime Function: _Decimal64 __bid_floatunsdidd (unsigned long I) 917 -- Runtime Function: _Decimal128 __dpd_floatunsditd (unsigned long I) 918 -- Runtime Function: _Decimal128 __bid_floatunsditd (unsigned long I) 919 These functions convert I, an unsigned long, to decimal floating 920 point. 921 9224.3.3 Comparison functions 923-------------------------- 924 925 -- Runtime Function: int __dpd_unordsd2 (_Decimal32 A, _Decimal32 B) 926 -- Runtime Function: int __bid_unordsd2 (_Decimal32 A, _Decimal32 B) 927 -- Runtime Function: int __dpd_unorddd2 (_Decimal64 A, _Decimal64 B) 928 -- Runtime Function: int __bid_unorddd2 (_Decimal64 A, _Decimal64 B) 929 -- Runtime Function: int __dpd_unordtd2 (_Decimal128 A, _Decimal128 B) 930 -- Runtime Function: int __bid_unordtd2 (_Decimal128 A, _Decimal128 B) 931 These functions return a nonzero value if either argument is NaN, 932 otherwise 0. 933 934 There is also a complete group of higher level functions which 935correspond directly to comparison operators. They implement the ISO C 936semantics for floating-point comparisons, taking NaN into account. Pay 937careful attention to the return values defined for each set. Under the 938hood, all of these routines are implemented as 939 940 if (__bid_unordXd2 (a, b)) 941 return E; 942 return __bid_cmpXd2 (a, b); 943 944where E is a constant chosen to give the proper behavior for NaN. Thus, 945the meaning of the return value is different for each set. Do not rely 946on this implementation; only the semantics documented below are 947guaranteed. 948 949 -- Runtime Function: int __dpd_eqsd2 (_Decimal32 A, _Decimal32 B) 950 -- Runtime Function: int __bid_eqsd2 (_Decimal32 A, _Decimal32 B) 951 -- Runtime Function: int __dpd_eqdd2 (_Decimal64 A, _Decimal64 B) 952 -- Runtime Function: int __bid_eqdd2 (_Decimal64 A, _Decimal64 B) 953 -- Runtime Function: int __dpd_eqtd2 (_Decimal128 A, _Decimal128 B) 954 -- Runtime Function: int __bid_eqtd2 (_Decimal128 A, _Decimal128 B) 955 These functions return zero if neither argument is NaN, and A and B 956 are equal. 957 958 -- Runtime Function: int __dpd_nesd2 (_Decimal32 A, _Decimal32 B) 959 -- Runtime Function: int __bid_nesd2 (_Decimal32 A, _Decimal32 B) 960 -- Runtime Function: int __dpd_nedd2 (_Decimal64 A, _Decimal64 B) 961 -- Runtime Function: int __bid_nedd2 (_Decimal64 A, _Decimal64 B) 962 -- Runtime Function: int __dpd_netd2 (_Decimal128 A, _Decimal128 B) 963 -- Runtime Function: int __bid_netd2 (_Decimal128 A, _Decimal128 B) 964 These functions return a nonzero value if either argument is NaN, 965 or if A and B are unequal. 966 967 -- Runtime Function: int __dpd_gesd2 (_Decimal32 A, _Decimal32 B) 968 -- Runtime Function: int __bid_gesd2 (_Decimal32 A, _Decimal32 B) 969 -- Runtime Function: int __dpd_gedd2 (_Decimal64 A, _Decimal64 B) 970 -- Runtime Function: int __bid_gedd2 (_Decimal64 A, _Decimal64 B) 971 -- Runtime Function: int __dpd_getd2 (_Decimal128 A, _Decimal128 B) 972 -- Runtime Function: int __bid_getd2 (_Decimal128 A, _Decimal128 B) 973 These functions return a value greater than or equal to zero if 974 neither argument is NaN, and A is greater than or equal to B. 975 976 -- Runtime Function: int __dpd_ltsd2 (_Decimal32 A, _Decimal32 B) 977 -- Runtime Function: int __bid_ltsd2 (_Decimal32 A, _Decimal32 B) 978 -- Runtime Function: int __dpd_ltdd2 (_Decimal64 A, _Decimal64 B) 979 -- Runtime Function: int __bid_ltdd2 (_Decimal64 A, _Decimal64 B) 980 -- Runtime Function: int __dpd_lttd2 (_Decimal128 A, _Decimal128 B) 981 -- Runtime Function: int __bid_lttd2 (_Decimal128 A, _Decimal128 B) 982 These functions return a value less than zero if neither argument 983 is NaN, and A is strictly less than B. 984 985 -- Runtime Function: int __dpd_lesd2 (_Decimal32 A, _Decimal32 B) 986 -- Runtime Function: int __bid_lesd2 (_Decimal32 A, _Decimal32 B) 987 -- Runtime Function: int __dpd_ledd2 (_Decimal64 A, _Decimal64 B) 988 -- Runtime Function: int __bid_ledd2 (_Decimal64 A, _Decimal64 B) 989 -- Runtime Function: int __dpd_letd2 (_Decimal128 A, _Decimal128 B) 990 -- Runtime Function: int __bid_letd2 (_Decimal128 A, _Decimal128 B) 991 These functions return a value less than or equal to zero if 992 neither argument is NaN, and A is less than or equal to B. 993 994 -- Runtime Function: int __dpd_gtsd2 (_Decimal32 A, _Decimal32 B) 995 -- Runtime Function: int __bid_gtsd2 (_Decimal32 A, _Decimal32 B) 996 -- Runtime Function: int __dpd_gtdd2 (_Decimal64 A, _Decimal64 B) 997 -- Runtime Function: int __bid_gtdd2 (_Decimal64 A, _Decimal64 B) 998 -- Runtime Function: int __dpd_gttd2 (_Decimal128 A, _Decimal128 B) 999 -- Runtime Function: int __bid_gttd2 (_Decimal128 A, _Decimal128 B) 1000 These functions return a value greater than zero if neither 1001 argument is NaN, and A is strictly greater than B. 1002 1003 1004File: gccint.info, Node: Fixed-point fractional library routines, Next: Exception handling routines, Prev: Decimal float library routines, Up: Libgcc 1005 10064.4 Routines for fixed-point fractional emulation 1007================================================= 1008 1009The software fixed-point library implements fixed-point fractional 1010arithmetic, and is only activated on selected targets. 1011 1012 For ease of comprehension 'fract' is an alias for the '_Fract' type, 1013'accum' an alias for '_Accum', and 'sat' an alias for '_Sat'. 1014 1015 For illustrative purposes, in this section the fixed-point fractional 1016type 'short fract' is assumed to correspond to machine mode 'QQmode'; 1017'unsigned short fract' to 'UQQmode'; 'fract' to 'HQmode'; 1018'unsigned fract' to 'UHQmode'; 'long fract' to 'SQmode'; 1019'unsigned long fract' to 'USQmode'; 'long long fract' to 'DQmode'; and 1020'unsigned long long fract' to 'UDQmode'. Similarly the fixed-point 1021accumulator type 'short accum' corresponds to 'HAmode'; 1022'unsigned short accum' to 'UHAmode'; 'accum' to 'SAmode'; 1023'unsigned accum' to 'USAmode'; 'long accum' to 'DAmode'; 1024'unsigned long accum' to 'UDAmode'; 'long long accum' to 'TAmode'; and 1025'unsigned long long accum' to 'UTAmode'. 1026 10274.4.1 Arithmetic functions 1028-------------------------- 1029 1030 -- Runtime Function: short fract __addqq3 (short fract A, short fract 1031 B) 1032 -- Runtime Function: fract __addhq3 (fract A, fract B) 1033 -- Runtime Function: long fract __addsq3 (long fract A, long fract B) 1034 -- Runtime Function: long long fract __adddq3 (long long fract A, long 1035 long fract B) 1036 -- Runtime Function: unsigned short fract __adduqq3 (unsigned short 1037 fract A, unsigned short fract B) 1038 -- Runtime Function: unsigned fract __adduhq3 (unsigned fract A, 1039 unsigned fract B) 1040 -- Runtime Function: unsigned long fract __addusq3 (unsigned long fract 1041 A, unsigned long fract B) 1042 -- Runtime Function: unsigned long long fract __addudq3 (unsigned long 1043 long fract A, unsigned long long fract B) 1044 -- Runtime Function: short accum __addha3 (short accum A, short accum 1045 B) 1046 -- Runtime Function: accum __addsa3 (accum A, accum B) 1047 -- Runtime Function: long accum __addda3 (long accum A, long accum B) 1048 -- Runtime Function: long long accum __addta3 (long long accum A, long 1049 long accum B) 1050 -- Runtime Function: unsigned short accum __adduha3 (unsigned short 1051 accum A, unsigned short accum B) 1052 -- Runtime Function: unsigned accum __addusa3 (unsigned accum A, 1053 unsigned accum B) 1054 -- Runtime Function: unsigned long accum __adduda3 (unsigned long accum 1055 A, unsigned long accum B) 1056 -- Runtime Function: unsigned long long accum __adduta3 (unsigned long 1057 long accum A, unsigned long long accum B) 1058 These functions return the sum of A and B. 1059 1060 -- Runtime Function: short fract __ssaddqq3 (short fract A, short fract 1061 B) 1062 -- Runtime Function: fract __ssaddhq3 (fract A, fract B) 1063 -- Runtime Function: long fract __ssaddsq3 (long fract A, long fract B) 1064 -- Runtime Function: long long fract __ssadddq3 (long long fract A, 1065 long long fract B) 1066 -- Runtime Function: short accum __ssaddha3 (short accum A, short accum 1067 B) 1068 -- Runtime Function: accum __ssaddsa3 (accum A, accum B) 1069 -- Runtime Function: long accum __ssaddda3 (long accum A, long accum B) 1070 -- Runtime Function: long long accum __ssaddta3 (long long accum A, 1071 long long accum B) 1072 These functions return the sum of A and B with signed saturation. 1073 1074 -- Runtime Function: unsigned short fract __usadduqq3 (unsigned short 1075 fract A, unsigned short fract B) 1076 -- Runtime Function: unsigned fract __usadduhq3 (unsigned fract A, 1077 unsigned fract B) 1078 -- Runtime Function: unsigned long fract __usaddusq3 (unsigned long 1079 fract A, unsigned long fract B) 1080 -- Runtime Function: unsigned long long fract __usaddudq3 (unsigned 1081 long long fract A, unsigned long long fract B) 1082 -- Runtime Function: unsigned short accum __usadduha3 (unsigned short 1083 accum A, unsigned short accum B) 1084 -- Runtime Function: unsigned accum __usaddusa3 (unsigned accum A, 1085 unsigned accum B) 1086 -- Runtime Function: unsigned long accum __usadduda3 (unsigned long 1087 accum A, unsigned long accum B) 1088 -- Runtime Function: unsigned long long accum __usadduta3 (unsigned 1089 long long accum A, unsigned long long accum B) 1090 These functions return the sum of A and B with unsigned saturation. 1091 1092 -- Runtime Function: short fract __subqq3 (short fract A, short fract 1093 B) 1094 -- Runtime Function: fract __subhq3 (fract A, fract B) 1095 -- Runtime Function: long fract __subsq3 (long fract A, long fract B) 1096 -- Runtime Function: long long fract __subdq3 (long long fract A, long 1097 long fract B) 1098 -- Runtime Function: unsigned short fract __subuqq3 (unsigned short 1099 fract A, unsigned short fract B) 1100 -- Runtime Function: unsigned fract __subuhq3 (unsigned fract A, 1101 unsigned fract B) 1102 -- Runtime Function: unsigned long fract __subusq3 (unsigned long fract 1103 A, unsigned long fract B) 1104 -- Runtime Function: unsigned long long fract __subudq3 (unsigned long 1105 long fract A, unsigned long long fract B) 1106 -- Runtime Function: short accum __subha3 (short accum A, short accum 1107 B) 1108 -- Runtime Function: accum __subsa3 (accum A, accum B) 1109 -- Runtime Function: long accum __subda3 (long accum A, long accum B) 1110 -- Runtime Function: long long accum __subta3 (long long accum A, long 1111 long accum B) 1112 -- Runtime Function: unsigned short accum __subuha3 (unsigned short 1113 accum A, unsigned short accum B) 1114 -- Runtime Function: unsigned accum __subusa3 (unsigned accum A, 1115 unsigned accum B) 1116 -- Runtime Function: unsigned long accum __subuda3 (unsigned long accum 1117 A, unsigned long accum B) 1118 -- Runtime Function: unsigned long long accum __subuta3 (unsigned long 1119 long accum A, unsigned long long accum B) 1120 These functions return the difference of A and B; that is, 'A - B'. 1121 1122 -- Runtime Function: short fract __sssubqq3 (short fract A, short fract 1123 B) 1124 -- Runtime Function: fract __sssubhq3 (fract A, fract B) 1125 -- Runtime Function: long fract __sssubsq3 (long fract A, long fract B) 1126 -- Runtime Function: long long fract __sssubdq3 (long long fract A, 1127 long long fract B) 1128 -- Runtime Function: short accum __sssubha3 (short accum A, short accum 1129 B) 1130 -- Runtime Function: accum __sssubsa3 (accum A, accum B) 1131 -- Runtime Function: long accum __sssubda3 (long accum A, long accum B) 1132 -- Runtime Function: long long accum __sssubta3 (long long accum A, 1133 long long accum B) 1134 These functions return the difference of A and B with signed 1135 saturation; that is, 'A - B'. 1136 1137 -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short 1138 fract A, unsigned short fract B) 1139 -- Runtime Function: unsigned fract __ussubuhq3 (unsigned fract A, 1140 unsigned fract B) 1141 -- Runtime Function: unsigned long fract __ussubusq3 (unsigned long 1142 fract A, unsigned long fract B) 1143 -- Runtime Function: unsigned long long fract __ussubudq3 (unsigned 1144 long long fract A, unsigned long long fract B) 1145 -- Runtime Function: unsigned short accum __ussubuha3 (unsigned short 1146 accum A, unsigned short accum B) 1147 -- Runtime Function: unsigned accum __ussubusa3 (unsigned accum A, 1148 unsigned accum B) 1149 -- Runtime Function: unsigned long accum __ussubuda3 (unsigned long 1150 accum A, unsigned long accum B) 1151 -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned 1152 long long accum A, unsigned long long accum B) 1153 These functions return the difference of A and B with unsigned 1154 saturation; that is, 'A - B'. 1155 1156 -- Runtime Function: short fract __mulqq3 (short fract A, short fract 1157 B) 1158 -- Runtime Function: fract __mulhq3 (fract A, fract B) 1159 -- Runtime Function: long fract __mulsq3 (long fract A, long fract B) 1160 -- Runtime Function: long long fract __muldq3 (long long fract A, long 1161 long fract B) 1162 -- Runtime Function: unsigned short fract __muluqq3 (unsigned short 1163 fract A, unsigned short fract B) 1164 -- Runtime Function: unsigned fract __muluhq3 (unsigned fract A, 1165 unsigned fract B) 1166 -- Runtime Function: unsigned long fract __mulusq3 (unsigned long fract 1167 A, unsigned long fract B) 1168 -- Runtime Function: unsigned long long fract __muludq3 (unsigned long 1169 long fract A, unsigned long long fract B) 1170 -- Runtime Function: short accum __mulha3 (short accum A, short accum 1171 B) 1172 -- Runtime Function: accum __mulsa3 (accum A, accum B) 1173 -- Runtime Function: long accum __mulda3 (long accum A, long accum B) 1174 -- Runtime Function: long long accum __multa3 (long long accum A, long 1175 long accum B) 1176 -- Runtime Function: unsigned short accum __muluha3 (unsigned short 1177 accum A, unsigned short accum B) 1178 -- Runtime Function: unsigned accum __mulusa3 (unsigned accum A, 1179 unsigned accum B) 1180 -- Runtime Function: unsigned long accum __muluda3 (unsigned long accum 1181 A, unsigned long accum B) 1182 -- Runtime Function: unsigned long long accum __muluta3 (unsigned long 1183 long accum A, unsigned long long accum B) 1184 These functions return the product of A and B. 1185 1186 -- Runtime Function: short fract __ssmulqq3 (short fract A, short fract 1187 B) 1188 -- Runtime Function: fract __ssmulhq3 (fract A, fract B) 1189 -- Runtime Function: long fract __ssmulsq3 (long fract A, long fract B) 1190 -- Runtime Function: long long fract __ssmuldq3 (long long fract A, 1191 long long fract B) 1192 -- Runtime Function: short accum __ssmulha3 (short accum A, short accum 1193 B) 1194 -- Runtime Function: accum __ssmulsa3 (accum A, accum B) 1195 -- Runtime Function: long accum __ssmulda3 (long accum A, long accum B) 1196 -- Runtime Function: long long accum __ssmulta3 (long long accum A, 1197 long long accum B) 1198 These functions return the product of A and B with signed 1199 saturation. 1200 1201 -- Runtime Function: unsigned short fract __usmuluqq3 (unsigned short 1202 fract A, unsigned short fract B) 1203 -- Runtime Function: unsigned fract __usmuluhq3 (unsigned fract A, 1204 unsigned fract B) 1205 -- Runtime Function: unsigned long fract __usmulusq3 (unsigned long 1206 fract A, unsigned long fract B) 1207 -- Runtime Function: unsigned long long fract __usmuludq3 (unsigned 1208 long long fract A, unsigned long long fract B) 1209 -- Runtime Function: unsigned short accum __usmuluha3 (unsigned short 1210 accum A, unsigned short accum B) 1211 -- Runtime Function: unsigned accum __usmulusa3 (unsigned accum A, 1212 unsigned accum B) 1213 -- Runtime Function: unsigned long accum __usmuluda3 (unsigned long 1214 accum A, unsigned long accum B) 1215 -- Runtime Function: unsigned long long accum __usmuluta3 (unsigned 1216 long long accum A, unsigned long long accum B) 1217 These functions return the product of A and B with unsigned 1218 saturation. 1219 1220 -- Runtime Function: short fract __divqq3 (short fract A, short fract 1221 B) 1222 -- Runtime Function: fract __divhq3 (fract A, fract B) 1223 -- Runtime Function: long fract __divsq3 (long fract A, long fract B) 1224 -- Runtime Function: long long fract __divdq3 (long long fract A, long 1225 long fract B) 1226 -- Runtime Function: short accum __divha3 (short accum A, short accum 1227 B) 1228 -- Runtime Function: accum __divsa3 (accum A, accum B) 1229 -- Runtime Function: long accum __divda3 (long accum A, long accum B) 1230 -- Runtime Function: long long accum __divta3 (long long accum A, long 1231 long accum B) 1232 These functions return the quotient of the signed division of A and 1233 B. 1234 1235 -- Runtime Function: unsigned short fract __udivuqq3 (unsigned short 1236 fract A, unsigned short fract B) 1237 -- Runtime Function: unsigned fract __udivuhq3 (unsigned fract A, 1238 unsigned fract B) 1239 -- Runtime Function: unsigned long fract __udivusq3 (unsigned long 1240 fract A, unsigned long fract B) 1241 -- Runtime Function: unsigned long long fract __udivudq3 (unsigned long 1242 long fract A, unsigned long long fract B) 1243 -- Runtime Function: unsigned short accum __udivuha3 (unsigned short 1244 accum A, unsigned short accum B) 1245 -- Runtime Function: unsigned accum __udivusa3 (unsigned accum A, 1246 unsigned accum B) 1247 -- Runtime Function: unsigned long accum __udivuda3 (unsigned long 1248 accum A, unsigned long accum B) 1249 -- Runtime Function: unsigned long long accum __udivuta3 (unsigned long 1250 long accum A, unsigned long long accum B) 1251 These functions return the quotient of the unsigned division of A 1252 and B. 1253 1254 -- Runtime Function: short fract __ssdivqq3 (short fract A, short fract 1255 B) 1256 -- Runtime Function: fract __ssdivhq3 (fract A, fract B) 1257 -- Runtime Function: long fract __ssdivsq3 (long fract A, long fract B) 1258 -- Runtime Function: long long fract __ssdivdq3 (long long fract A, 1259 long long fract B) 1260 -- Runtime Function: short accum __ssdivha3 (short accum A, short accum 1261 B) 1262 -- Runtime Function: accum __ssdivsa3 (accum A, accum B) 1263 -- Runtime Function: long accum __ssdivda3 (long accum A, long accum B) 1264 -- Runtime Function: long long accum __ssdivta3 (long long accum A, 1265 long long accum B) 1266 These functions return the quotient of the signed division of A and 1267 B with signed saturation. 1268 1269 -- Runtime Function: unsigned short fract __usdivuqq3 (unsigned short 1270 fract A, unsigned short fract B) 1271 -- Runtime Function: unsigned fract __usdivuhq3 (unsigned fract A, 1272 unsigned fract B) 1273 -- Runtime Function: unsigned long fract __usdivusq3 (unsigned long 1274 fract A, unsigned long fract B) 1275 -- Runtime Function: unsigned long long fract __usdivudq3 (unsigned 1276 long long fract A, unsigned long long fract B) 1277 -- Runtime Function: unsigned short accum __usdivuha3 (unsigned short 1278 accum A, unsigned short accum B) 1279 -- Runtime Function: unsigned accum __usdivusa3 (unsigned accum A, 1280 unsigned accum B) 1281 -- Runtime Function: unsigned long accum __usdivuda3 (unsigned long 1282 accum A, unsigned long accum B) 1283 -- Runtime Function: unsigned long long accum __usdivuta3 (unsigned 1284 long long accum A, unsigned long long accum B) 1285 These functions return the quotient of the unsigned division of A 1286 and B with unsigned saturation. 1287 1288 -- Runtime Function: short fract __negqq2 (short fract A) 1289 -- Runtime Function: fract __neghq2 (fract A) 1290 -- Runtime Function: long fract __negsq2 (long fract A) 1291 -- Runtime Function: long long fract __negdq2 (long long fract A) 1292 -- Runtime Function: unsigned short fract __neguqq2 (unsigned short 1293 fract A) 1294 -- Runtime Function: unsigned fract __neguhq2 (unsigned fract A) 1295 -- Runtime Function: unsigned long fract __negusq2 (unsigned long fract 1296 A) 1297 -- Runtime Function: unsigned long long fract __negudq2 (unsigned long 1298 long fract A) 1299 -- Runtime Function: short accum __negha2 (short accum A) 1300 -- Runtime Function: accum __negsa2 (accum A) 1301 -- Runtime Function: long accum __negda2 (long accum A) 1302 -- Runtime Function: long long accum __negta2 (long long accum A) 1303 -- Runtime Function: unsigned short accum __neguha2 (unsigned short 1304 accum A) 1305 -- Runtime Function: unsigned accum __negusa2 (unsigned accum A) 1306 -- Runtime Function: unsigned long accum __neguda2 (unsigned long accum 1307 A) 1308 -- Runtime Function: unsigned long long accum __neguta2 (unsigned long 1309 long accum A) 1310 These functions return the negation of A. 1311 1312 -- Runtime Function: short fract __ssnegqq2 (short fract A) 1313 -- Runtime Function: fract __ssneghq2 (fract A) 1314 -- Runtime Function: long fract __ssnegsq2 (long fract A) 1315 -- Runtime Function: long long fract __ssnegdq2 (long long fract A) 1316 -- Runtime Function: short accum __ssnegha2 (short accum A) 1317 -- Runtime Function: accum __ssnegsa2 (accum A) 1318 -- Runtime Function: long accum __ssnegda2 (long accum A) 1319 -- Runtime Function: long long accum __ssnegta2 (long long accum A) 1320 These functions return the negation of A with signed saturation. 1321 1322 -- Runtime Function: unsigned short fract __usneguqq2 (unsigned short 1323 fract A) 1324 -- Runtime Function: unsigned fract __usneguhq2 (unsigned fract A) 1325 -- Runtime Function: unsigned long fract __usnegusq2 (unsigned long 1326 fract A) 1327 -- Runtime Function: unsigned long long fract __usnegudq2 (unsigned 1328 long long fract A) 1329 -- Runtime Function: unsigned short accum __usneguha2 (unsigned short 1330 accum A) 1331 -- Runtime Function: unsigned accum __usnegusa2 (unsigned accum A) 1332 -- Runtime Function: unsigned long accum __usneguda2 (unsigned long 1333 accum A) 1334 -- Runtime Function: unsigned long long accum __usneguta2 (unsigned 1335 long long accum A) 1336 These functions return the negation of A with unsigned saturation. 1337 1338 -- Runtime Function: short fract __ashlqq3 (short fract A, int B) 1339 -- Runtime Function: fract __ashlhq3 (fract A, int B) 1340 -- Runtime Function: long fract __ashlsq3 (long fract A, int B) 1341 -- Runtime Function: long long fract __ashldq3 (long long fract A, int 1342 B) 1343 -- Runtime Function: unsigned short fract __ashluqq3 (unsigned short 1344 fract A, int B) 1345 -- Runtime Function: unsigned fract __ashluhq3 (unsigned fract A, int 1346 B) 1347 -- Runtime Function: unsigned long fract __ashlusq3 (unsigned long 1348 fract A, int B) 1349 -- Runtime Function: unsigned long long fract __ashludq3 (unsigned long 1350 long fract A, int B) 1351 -- Runtime Function: short accum __ashlha3 (short accum A, int B) 1352 -- Runtime Function: accum __ashlsa3 (accum A, int B) 1353 -- Runtime Function: long accum __ashlda3 (long accum A, int B) 1354 -- Runtime Function: long long accum __ashlta3 (long long accum A, int 1355 B) 1356 -- Runtime Function: unsigned short accum __ashluha3 (unsigned short 1357 accum A, int B) 1358 -- Runtime Function: unsigned accum __ashlusa3 (unsigned accum A, int 1359 B) 1360 -- Runtime Function: unsigned long accum __ashluda3 (unsigned long 1361 accum A, int B) 1362 -- Runtime Function: unsigned long long accum __ashluta3 (unsigned long 1363 long accum A, int B) 1364 These functions return the result of shifting A left by B bits. 1365 1366 -- Runtime Function: short fract __ashrqq3 (short fract A, int B) 1367 -- Runtime Function: fract __ashrhq3 (fract A, int B) 1368 -- Runtime Function: long fract __ashrsq3 (long fract A, int B) 1369 -- Runtime Function: long long fract __ashrdq3 (long long fract A, int 1370 B) 1371 -- Runtime Function: short accum __ashrha3 (short accum A, int B) 1372 -- Runtime Function: accum __ashrsa3 (accum A, int B) 1373 -- Runtime Function: long accum __ashrda3 (long accum A, int B) 1374 -- Runtime Function: long long accum __ashrta3 (long long accum A, int 1375 B) 1376 These functions return the result of arithmetically shifting A 1377 right by B bits. 1378 1379 -- Runtime Function: unsigned short fract __lshruqq3 (unsigned short 1380 fract A, int B) 1381 -- Runtime Function: unsigned fract __lshruhq3 (unsigned fract A, int 1382 B) 1383 -- Runtime Function: unsigned long fract __lshrusq3 (unsigned long 1384 fract A, int B) 1385 -- Runtime Function: unsigned long long fract __lshrudq3 (unsigned long 1386 long fract A, int B) 1387 -- Runtime Function: unsigned short accum __lshruha3 (unsigned short 1388 accum A, int B) 1389 -- Runtime Function: unsigned accum __lshrusa3 (unsigned accum A, int 1390 B) 1391 -- Runtime Function: unsigned long accum __lshruda3 (unsigned long 1392 accum A, int B) 1393 -- Runtime Function: unsigned long long accum __lshruta3 (unsigned long 1394 long accum A, int B) 1395 These functions return the result of logically shifting A right by 1396 B bits. 1397 1398 -- Runtime Function: fract __ssashlhq3 (fract A, int B) 1399 -- Runtime Function: long fract __ssashlsq3 (long fract A, int B) 1400 -- Runtime Function: long long fract __ssashldq3 (long long fract A, 1401 int B) 1402 -- Runtime Function: short accum __ssashlha3 (short accum A, int B) 1403 -- Runtime Function: accum __ssashlsa3 (accum A, int B) 1404 -- Runtime Function: long accum __ssashlda3 (long accum A, int B) 1405 -- Runtime Function: long long accum __ssashlta3 (long long accum A, 1406 int B) 1407 These functions return the result of shifting A left by B bits with 1408 signed saturation. 1409 1410 -- Runtime Function: unsigned short fract __usashluqq3 (unsigned short 1411 fract A, int B) 1412 -- Runtime Function: unsigned fract __usashluhq3 (unsigned fract A, int 1413 B) 1414 -- Runtime Function: unsigned long fract __usashlusq3 (unsigned long 1415 fract A, int B) 1416 -- Runtime Function: unsigned long long fract __usashludq3 (unsigned 1417 long long fract A, int B) 1418 -- Runtime Function: unsigned short accum __usashluha3 (unsigned short 1419 accum A, int B) 1420 -- Runtime Function: unsigned accum __usashlusa3 (unsigned accum A, int 1421 B) 1422 -- Runtime Function: unsigned long accum __usashluda3 (unsigned long 1423 accum A, int B) 1424 -- Runtime Function: unsigned long long accum __usashluta3 (unsigned 1425 long long accum A, int B) 1426 These functions return the result of shifting A left by B bits with 1427 unsigned saturation. 1428 14294.4.2 Comparison functions 1430-------------------------- 1431 1432The following functions implement fixed-point comparisons. These 1433functions implement a low-level compare, upon which the higher level 1434comparison operators (such as less than and greater than or equal to) 1435can be constructed. The returned values lie in the range zero to two, 1436to allow the high-level operators to be implemented by testing the 1437returned result using either signed or unsigned comparison. 1438 1439 -- Runtime Function: int __cmpqq2 (short fract A, short fract B) 1440 -- Runtime Function: int __cmphq2 (fract A, fract B) 1441 -- Runtime Function: int __cmpsq2 (long fract A, long fract B) 1442 -- Runtime Function: int __cmpdq2 (long long fract A, long long fract 1443 B) 1444 -- Runtime Function: int __cmpuqq2 (unsigned short fract A, unsigned 1445 short fract B) 1446 -- Runtime Function: int __cmpuhq2 (unsigned fract A, unsigned fract B) 1447 -- Runtime Function: int __cmpusq2 (unsigned long fract A, unsigned 1448 long fract B) 1449 -- Runtime Function: int __cmpudq2 (unsigned long long fract A, 1450 unsigned long long fract B) 1451 -- Runtime Function: int __cmpha2 (short accum A, short accum B) 1452 -- Runtime Function: int __cmpsa2 (accum A, accum B) 1453 -- Runtime Function: int __cmpda2 (long accum A, long accum B) 1454 -- Runtime Function: int __cmpta2 (long long accum A, long long accum 1455 B) 1456 -- Runtime Function: int __cmpuha2 (unsigned short accum A, unsigned 1457 short accum B) 1458 -- Runtime Function: int __cmpusa2 (unsigned accum A, unsigned accum B) 1459 -- Runtime Function: int __cmpuda2 (unsigned long accum A, unsigned 1460 long accum B) 1461 -- Runtime Function: int __cmputa2 (unsigned long long accum A, 1462 unsigned long long accum B) 1463 These functions perform a signed or unsigned comparison of A and B 1464 (depending on the selected machine mode). If A is less than B, 1465 they return 0; if A is greater than B, they return 2; and if A and 1466 B are equal they return 1. 1467 14684.4.3 Conversion functions 1469-------------------------- 1470 1471 -- Runtime Function: fract __fractqqhq2 (short fract A) 1472 -- Runtime Function: long fract __fractqqsq2 (short fract A) 1473 -- Runtime Function: long long fract __fractqqdq2 (short fract A) 1474 -- Runtime Function: short accum __fractqqha (short fract A) 1475 -- Runtime Function: accum __fractqqsa (short fract A) 1476 -- Runtime Function: long accum __fractqqda (short fract A) 1477 -- Runtime Function: long long accum __fractqqta (short fract A) 1478 -- Runtime Function: unsigned short fract __fractqquqq (short fract A) 1479 -- Runtime Function: unsigned fract __fractqquhq (short fract A) 1480 -- Runtime Function: unsigned long fract __fractqqusq (short fract A) 1481 -- Runtime Function: unsigned long long fract __fractqqudq (short fract 1482 A) 1483 -- Runtime Function: unsigned short accum __fractqquha (short fract A) 1484 -- Runtime Function: unsigned accum __fractqqusa (short fract A) 1485 -- Runtime Function: unsigned long accum __fractqquda (short fract A) 1486 -- Runtime Function: unsigned long long accum __fractqquta (short fract 1487 A) 1488 -- Runtime Function: signed char __fractqqqi (short fract A) 1489 -- Runtime Function: short __fractqqhi (short fract A) 1490 -- Runtime Function: int __fractqqsi (short fract A) 1491 -- Runtime Function: long __fractqqdi (short fract A) 1492 -- Runtime Function: long long __fractqqti (short fract A) 1493 -- Runtime Function: float __fractqqsf (short fract A) 1494 -- Runtime Function: double __fractqqdf (short fract A) 1495 -- Runtime Function: short fract __fracthqqq2 (fract A) 1496 -- Runtime Function: long fract __fracthqsq2 (fract A) 1497 -- Runtime Function: long long fract __fracthqdq2 (fract A) 1498 -- Runtime Function: short accum __fracthqha (fract A) 1499 -- Runtime Function: accum __fracthqsa (fract A) 1500 -- Runtime Function: long accum __fracthqda (fract A) 1501 -- Runtime Function: long long accum __fracthqta (fract A) 1502 -- Runtime Function: unsigned short fract __fracthquqq (fract A) 1503 -- Runtime Function: unsigned fract __fracthquhq (fract A) 1504 -- Runtime Function: unsigned long fract __fracthqusq (fract A) 1505 -- Runtime Function: unsigned long long fract __fracthqudq (fract A) 1506 -- Runtime Function: unsigned short accum __fracthquha (fract A) 1507 -- Runtime Function: unsigned accum __fracthqusa (fract A) 1508 -- Runtime Function: unsigned long accum __fracthquda (fract A) 1509 -- Runtime Function: unsigned long long accum __fracthquta (fract A) 1510 -- Runtime Function: signed char __fracthqqi (fract A) 1511 -- Runtime Function: short __fracthqhi (fract A) 1512 -- Runtime Function: int __fracthqsi (fract A) 1513 -- Runtime Function: long __fracthqdi (fract A) 1514 -- Runtime Function: long long __fracthqti (fract A) 1515 -- Runtime Function: float __fracthqsf (fract A) 1516 -- Runtime Function: double __fracthqdf (fract A) 1517 -- Runtime Function: short fract __fractsqqq2 (long fract A) 1518 -- Runtime Function: fract __fractsqhq2 (long fract A) 1519 -- Runtime Function: long long fract __fractsqdq2 (long fract A) 1520 -- Runtime Function: short accum __fractsqha (long fract A) 1521 -- Runtime Function: accum __fractsqsa (long fract A) 1522 -- Runtime Function: long accum __fractsqda (long fract A) 1523 -- Runtime Function: long long accum __fractsqta (long fract A) 1524 -- Runtime Function: unsigned short fract __fractsquqq (long fract A) 1525 -- Runtime Function: unsigned fract __fractsquhq (long fract A) 1526 -- Runtime Function: unsigned long fract __fractsqusq (long fract A) 1527 -- Runtime Function: unsigned long long fract __fractsqudq (long fract 1528 A) 1529 -- Runtime Function: unsigned short accum __fractsquha (long fract A) 1530 -- Runtime Function: unsigned accum __fractsqusa (long fract A) 1531 -- Runtime Function: unsigned long accum __fractsquda (long fract A) 1532 -- Runtime Function: unsigned long long accum __fractsquta (long fract 1533 A) 1534 -- Runtime Function: signed char __fractsqqi (long fract A) 1535 -- Runtime Function: short __fractsqhi (long fract A) 1536 -- Runtime Function: int __fractsqsi (long fract A) 1537 -- Runtime Function: long __fractsqdi (long fract A) 1538 -- Runtime Function: long long __fractsqti (long fract A) 1539 -- Runtime Function: float __fractsqsf (long fract A) 1540 -- Runtime Function: double __fractsqdf (long fract A) 1541 -- Runtime Function: short fract __fractdqqq2 (long long fract A) 1542 -- Runtime Function: fract __fractdqhq2 (long long fract A) 1543 -- Runtime Function: long fract __fractdqsq2 (long long fract A) 1544 -- Runtime Function: short accum __fractdqha (long long fract A) 1545 -- Runtime Function: accum __fractdqsa (long long fract A) 1546 -- Runtime Function: long accum __fractdqda (long long fract A) 1547 -- Runtime Function: long long accum __fractdqta (long long fract A) 1548 -- Runtime Function: unsigned short fract __fractdquqq (long long fract 1549 A) 1550 -- Runtime Function: unsigned fract __fractdquhq (long long fract A) 1551 -- Runtime Function: unsigned long fract __fractdqusq (long long fract 1552 A) 1553 -- Runtime Function: unsigned long long fract __fractdqudq (long long 1554 fract A) 1555 -- Runtime Function: unsigned short accum __fractdquha (long long fract 1556 A) 1557 -- Runtime Function: unsigned accum __fractdqusa (long long fract A) 1558 -- Runtime Function: unsigned long accum __fractdquda (long long fract 1559 A) 1560 -- Runtime Function: unsigned long long accum __fractdquta (long long 1561 fract A) 1562 -- Runtime Function: signed char __fractdqqi (long long fract A) 1563 -- Runtime Function: short __fractdqhi (long long fract A) 1564 -- Runtime Function: int __fractdqsi (long long fract A) 1565 -- Runtime Function: long __fractdqdi (long long fract A) 1566 -- Runtime Function: long long __fractdqti (long long fract A) 1567 -- Runtime Function: float __fractdqsf (long long fract A) 1568 -- Runtime Function: double __fractdqdf (long long fract A) 1569 -- Runtime Function: short fract __fracthaqq (short accum A) 1570 -- Runtime Function: fract __fracthahq (short accum A) 1571 -- Runtime Function: long fract __fracthasq (short accum A) 1572 -- Runtime Function: long long fract __fracthadq (short accum A) 1573 -- Runtime Function: accum __fracthasa2 (short accum A) 1574 -- Runtime Function: long accum __fracthada2 (short accum A) 1575 -- Runtime Function: long long accum __fracthata2 (short accum A) 1576 -- Runtime Function: unsigned short fract __fracthauqq (short accum A) 1577 -- Runtime Function: unsigned fract __fracthauhq (short accum A) 1578 -- Runtime Function: unsigned long fract __fracthausq (short accum A) 1579 -- Runtime Function: unsigned long long fract __fracthaudq (short accum 1580 A) 1581 -- Runtime Function: unsigned short accum __fracthauha (short accum A) 1582 -- Runtime Function: unsigned accum __fracthausa (short accum A) 1583 -- Runtime Function: unsigned long accum __fracthauda (short accum A) 1584 -- Runtime Function: unsigned long long accum __fracthauta (short accum 1585 A) 1586 -- Runtime Function: signed char __fracthaqi (short accum A) 1587 -- Runtime Function: short __fracthahi (short accum A) 1588 -- Runtime Function: int __fracthasi (short accum A) 1589 -- Runtime Function: long __fracthadi (short accum A) 1590 -- Runtime Function: long long __fracthati (short accum A) 1591 -- Runtime Function: float __fracthasf (short accum A) 1592 -- Runtime Function: double __fracthadf (short accum A) 1593 -- Runtime Function: short fract __fractsaqq (accum A) 1594 -- Runtime Function: fract __fractsahq (accum A) 1595 -- Runtime Function: long fract __fractsasq (accum A) 1596 -- Runtime Function: long long fract __fractsadq (accum A) 1597 -- Runtime Function: short accum __fractsaha2 (accum A) 1598 -- Runtime Function: long accum __fractsada2 (accum A) 1599 -- Runtime Function: long long accum __fractsata2 (accum A) 1600 -- Runtime Function: unsigned short fract __fractsauqq (accum A) 1601 -- Runtime Function: unsigned fract __fractsauhq (accum A) 1602 -- Runtime Function: unsigned long fract __fractsausq (accum A) 1603 -- Runtime Function: unsigned long long fract __fractsaudq (accum A) 1604 -- Runtime Function: unsigned short accum __fractsauha (accum A) 1605 -- Runtime Function: unsigned accum __fractsausa (accum A) 1606 -- Runtime Function: unsigned long accum __fractsauda (accum A) 1607 -- Runtime Function: unsigned long long accum __fractsauta (accum A) 1608 -- Runtime Function: signed char __fractsaqi (accum A) 1609 -- Runtime Function: short __fractsahi (accum A) 1610 -- Runtime Function: int __fractsasi (accum A) 1611 -- Runtime Function: long __fractsadi (accum A) 1612 -- Runtime Function: long long __fractsati (accum A) 1613 -- Runtime Function: float __fractsasf (accum A) 1614 -- Runtime Function: double __fractsadf (accum A) 1615 -- Runtime Function: short fract __fractdaqq (long accum A) 1616 -- Runtime Function: fract __fractdahq (long accum A) 1617 -- Runtime Function: long fract __fractdasq (long accum A) 1618 -- Runtime Function: long long fract __fractdadq (long accum A) 1619 -- Runtime Function: short accum __fractdaha2 (long accum A) 1620 -- Runtime Function: accum __fractdasa2 (long accum A) 1621 -- Runtime Function: long long accum __fractdata2 (long accum A) 1622 -- Runtime Function: unsigned short fract __fractdauqq (long accum A) 1623 -- Runtime Function: unsigned fract __fractdauhq (long accum A) 1624 -- Runtime Function: unsigned long fract __fractdausq (long accum A) 1625 -- Runtime Function: unsigned long long fract __fractdaudq (long accum 1626 A) 1627 -- Runtime Function: unsigned short accum __fractdauha (long accum A) 1628 -- Runtime Function: unsigned accum __fractdausa (long accum A) 1629 -- Runtime Function: unsigned long accum __fractdauda (long accum A) 1630 -- Runtime Function: unsigned long long accum __fractdauta (long accum 1631 A) 1632 -- Runtime Function: signed char __fractdaqi (long accum A) 1633 -- Runtime Function: short __fractdahi (long accum A) 1634 -- Runtime Function: int __fractdasi (long accum A) 1635 -- Runtime Function: long __fractdadi (long accum A) 1636 -- Runtime Function: long long __fractdati (long accum A) 1637 -- Runtime Function: float __fractdasf (long accum A) 1638 -- Runtime Function: double __fractdadf (long accum A) 1639 -- Runtime Function: short fract __fracttaqq (long long accum A) 1640 -- Runtime Function: fract __fracttahq (long long accum A) 1641 -- Runtime Function: long fract __fracttasq (long long accum A) 1642 -- Runtime Function: long long fract __fracttadq (long long accum A) 1643 -- Runtime Function: short accum __fracttaha2 (long long accum A) 1644 -- Runtime Function: accum __fracttasa2 (long long accum A) 1645 -- Runtime Function: long accum __fracttada2 (long long accum A) 1646 -- Runtime Function: unsigned short fract __fracttauqq (long long accum 1647 A) 1648 -- Runtime Function: unsigned fract __fracttauhq (long long accum A) 1649 -- Runtime Function: unsigned long fract __fracttausq (long long accum 1650 A) 1651 -- Runtime Function: unsigned long long fract __fracttaudq (long long 1652 accum A) 1653 -- Runtime Function: unsigned short accum __fracttauha (long long accum 1654 A) 1655 -- Runtime Function: unsigned accum __fracttausa (long long accum A) 1656 -- Runtime Function: unsigned long accum __fracttauda (long long accum 1657 A) 1658 -- Runtime Function: unsigned long long accum __fracttauta (long long 1659 accum A) 1660 -- Runtime Function: signed char __fracttaqi (long long accum A) 1661 -- Runtime Function: short __fracttahi (long long accum A) 1662 -- Runtime Function: int __fracttasi (long long accum A) 1663 -- Runtime Function: long __fracttadi (long long accum A) 1664 -- Runtime Function: long long __fracttati (long long accum A) 1665 -- Runtime Function: float __fracttasf (long long accum A) 1666 -- Runtime Function: double __fracttadf (long long accum A) 1667 -- Runtime Function: short fract __fractuqqqq (unsigned short fract A) 1668 -- Runtime Function: fract __fractuqqhq (unsigned short fract A) 1669 -- Runtime Function: long fract __fractuqqsq (unsigned short fract A) 1670 -- Runtime Function: long long fract __fractuqqdq (unsigned short fract 1671 A) 1672 -- Runtime Function: short accum __fractuqqha (unsigned short fract A) 1673 -- Runtime Function: accum __fractuqqsa (unsigned short fract A) 1674 -- Runtime Function: long accum __fractuqqda (unsigned short fract A) 1675 -- Runtime Function: long long accum __fractuqqta (unsigned short fract 1676 A) 1677 -- Runtime Function: unsigned fract __fractuqquhq2 (unsigned short 1678 fract A) 1679 -- Runtime Function: unsigned long fract __fractuqqusq2 (unsigned short 1680 fract A) 1681 -- Runtime Function: unsigned long long fract __fractuqqudq2 (unsigned 1682 short fract A) 1683 -- Runtime Function: unsigned short accum __fractuqquha (unsigned short 1684 fract A) 1685 -- Runtime Function: unsigned accum __fractuqqusa (unsigned short fract 1686 A) 1687 -- Runtime Function: unsigned long accum __fractuqquda (unsigned short 1688 fract A) 1689 -- Runtime Function: unsigned long long accum __fractuqquta (unsigned 1690 short fract A) 1691 -- Runtime Function: signed char __fractuqqqi (unsigned short fract A) 1692 -- Runtime Function: short __fractuqqhi (unsigned short fract A) 1693 -- Runtime Function: int __fractuqqsi (unsigned short fract A) 1694 -- Runtime Function: long __fractuqqdi (unsigned short fract A) 1695 -- Runtime Function: long long __fractuqqti (unsigned short fract A) 1696 -- Runtime Function: float __fractuqqsf (unsigned short fract A) 1697 -- Runtime Function: double __fractuqqdf (unsigned short fract A) 1698 -- Runtime Function: short fract __fractuhqqq (unsigned fract A) 1699 -- Runtime Function: fract __fractuhqhq (unsigned fract A) 1700 -- Runtime Function: long fract __fractuhqsq (unsigned fract A) 1701 -- Runtime Function: long long fract __fractuhqdq (unsigned fract A) 1702 -- Runtime Function: short accum __fractuhqha (unsigned fract A) 1703 -- Runtime Function: accum __fractuhqsa (unsigned fract A) 1704 -- Runtime Function: long accum __fractuhqda (unsigned fract A) 1705 -- Runtime Function: long long accum __fractuhqta (unsigned fract A) 1706 -- Runtime Function: unsigned short fract __fractuhquqq2 (unsigned 1707 fract A) 1708 -- Runtime Function: unsigned long fract __fractuhqusq2 (unsigned fract 1709 A) 1710 -- Runtime Function: unsigned long long fract __fractuhqudq2 (unsigned 1711 fract A) 1712 -- Runtime Function: unsigned short accum __fractuhquha (unsigned fract 1713 A) 1714 -- Runtime Function: unsigned accum __fractuhqusa (unsigned fract A) 1715 -- Runtime Function: unsigned long accum __fractuhquda (unsigned fract 1716 A) 1717 -- Runtime Function: unsigned long long accum __fractuhquta (unsigned 1718 fract A) 1719 -- Runtime Function: signed char __fractuhqqi (unsigned fract A) 1720 -- Runtime Function: short __fractuhqhi (unsigned fract A) 1721 -- Runtime Function: int __fractuhqsi (unsigned fract A) 1722 -- Runtime Function: long __fractuhqdi (unsigned fract A) 1723 -- Runtime Function: long long __fractuhqti (unsigned fract A) 1724 -- Runtime Function: float __fractuhqsf (unsigned fract A) 1725 -- Runtime Function: double __fractuhqdf (unsigned fract A) 1726 -- Runtime Function: short fract __fractusqqq (unsigned long fract A) 1727 -- Runtime Function: fract __fractusqhq (unsigned long fract A) 1728 -- Runtime Function: long fract __fractusqsq (unsigned long fract A) 1729 -- Runtime Function: long long fract __fractusqdq (unsigned long fract 1730 A) 1731 -- Runtime Function: short accum __fractusqha (unsigned long fract A) 1732 -- Runtime Function: accum __fractusqsa (unsigned long fract A) 1733 -- Runtime Function: long accum __fractusqda (unsigned long fract A) 1734 -- Runtime Function: long long accum __fractusqta (unsigned long fract 1735 A) 1736 -- Runtime Function: unsigned short fract __fractusquqq2 (unsigned long 1737 fract A) 1738 -- Runtime Function: unsigned fract __fractusquhq2 (unsigned long fract 1739 A) 1740 -- Runtime Function: unsigned long long fract __fractusqudq2 (unsigned 1741 long fract A) 1742 -- Runtime Function: unsigned short accum __fractusquha (unsigned long 1743 fract A) 1744 -- Runtime Function: unsigned accum __fractusqusa (unsigned long fract 1745 A) 1746 -- Runtime Function: unsigned long accum __fractusquda (unsigned long 1747 fract A) 1748 -- Runtime Function: unsigned long long accum __fractusquta (unsigned 1749 long fract A) 1750 -- Runtime Function: signed char __fractusqqi (unsigned long fract A) 1751 -- Runtime Function: short __fractusqhi (unsigned long fract A) 1752 -- Runtime Function: int __fractusqsi (unsigned long fract A) 1753 -- Runtime Function: long __fractusqdi (unsigned long fract A) 1754 -- Runtime Function: long long __fractusqti (unsigned long fract A) 1755 -- Runtime Function: float __fractusqsf (unsigned long fract A) 1756 -- Runtime Function: double __fractusqdf (unsigned long fract A) 1757 -- Runtime Function: short fract __fractudqqq (unsigned long long fract 1758 A) 1759 -- Runtime Function: fract __fractudqhq (unsigned long long fract A) 1760 -- Runtime Function: long fract __fractudqsq (unsigned long long fract 1761 A) 1762 -- Runtime Function: long long fract __fractudqdq (unsigned long long 1763 fract A) 1764 -- Runtime Function: short accum __fractudqha (unsigned long long fract 1765 A) 1766 -- Runtime Function: accum __fractudqsa (unsigned long long fract A) 1767 -- Runtime Function: long accum __fractudqda (unsigned long long fract 1768 A) 1769 -- Runtime Function: long long accum __fractudqta (unsigned long long 1770 fract A) 1771 -- Runtime Function: unsigned short fract __fractudquqq2 (unsigned long 1772 long fract A) 1773 -- Runtime Function: unsigned fract __fractudquhq2 (unsigned long long 1774 fract A) 1775 -- Runtime Function: unsigned long fract __fractudqusq2 (unsigned long 1776 long fract A) 1777 -- Runtime Function: unsigned short accum __fractudquha (unsigned long 1778 long fract A) 1779 -- Runtime Function: unsigned accum __fractudqusa (unsigned long long 1780 fract A) 1781 -- Runtime Function: unsigned long accum __fractudquda (unsigned long 1782 long fract A) 1783 -- Runtime Function: unsigned long long accum __fractudquta (unsigned 1784 long long fract A) 1785 -- Runtime Function: signed char __fractudqqi (unsigned long long fract 1786 A) 1787 -- Runtime Function: short __fractudqhi (unsigned long long fract A) 1788 -- Runtime Function: int __fractudqsi (unsigned long long fract A) 1789 -- Runtime Function: long __fractudqdi (unsigned long long fract A) 1790 -- Runtime Function: long long __fractudqti (unsigned long long fract 1791 A) 1792 -- Runtime Function: float __fractudqsf (unsigned long long fract A) 1793 -- Runtime Function: double __fractudqdf (unsigned long long fract A) 1794 -- Runtime Function: short fract __fractuhaqq (unsigned short accum A) 1795 -- Runtime Function: fract __fractuhahq (unsigned short accum A) 1796 -- Runtime Function: long fract __fractuhasq (unsigned short accum A) 1797 -- Runtime Function: long long fract __fractuhadq (unsigned short accum 1798 A) 1799 -- Runtime Function: short accum __fractuhaha (unsigned short accum A) 1800 -- Runtime Function: accum __fractuhasa (unsigned short accum A) 1801 -- Runtime Function: long accum __fractuhada (unsigned short accum A) 1802 -- Runtime Function: long long accum __fractuhata (unsigned short accum 1803 A) 1804 -- Runtime Function: unsigned short fract __fractuhauqq (unsigned short 1805 accum A) 1806 -- Runtime Function: unsigned fract __fractuhauhq (unsigned short accum 1807 A) 1808 -- Runtime Function: unsigned long fract __fractuhausq (unsigned short 1809 accum A) 1810 -- Runtime Function: unsigned long long fract __fractuhaudq (unsigned 1811 short accum A) 1812 -- Runtime Function: unsigned accum __fractuhausa2 (unsigned short 1813 accum A) 1814 -- Runtime Function: unsigned long accum __fractuhauda2 (unsigned short 1815 accum A) 1816 -- Runtime Function: unsigned long long accum __fractuhauta2 (unsigned 1817 short accum A) 1818 -- Runtime Function: signed char __fractuhaqi (unsigned short accum A) 1819 -- Runtime Function: short __fractuhahi (unsigned short accum A) 1820 -- Runtime Function: int __fractuhasi (unsigned short accum A) 1821 -- Runtime Function: long __fractuhadi (unsigned short accum A) 1822 -- Runtime Function: long long __fractuhati (unsigned short accum A) 1823 -- Runtime Function: float __fractuhasf (unsigned short accum A) 1824 -- Runtime Function: double __fractuhadf (unsigned short accum A) 1825 -- Runtime Function: short fract __fractusaqq (unsigned accum A) 1826 -- Runtime Function: fract __fractusahq (unsigned accum A) 1827 -- Runtime Function: long fract __fractusasq (unsigned accum A) 1828 -- Runtime Function: long long fract __fractusadq (unsigned accum A) 1829 -- Runtime Function: short accum __fractusaha (unsigned accum A) 1830 -- Runtime Function: accum __fractusasa (unsigned accum A) 1831 -- Runtime Function: long accum __fractusada (unsigned accum A) 1832 -- Runtime Function: long long accum __fractusata (unsigned accum A) 1833 -- Runtime Function: unsigned short fract __fractusauqq (unsigned accum 1834 A) 1835 -- Runtime Function: unsigned fract __fractusauhq (unsigned accum A) 1836 -- Runtime Function: unsigned long fract __fractusausq (unsigned accum 1837 A) 1838 -- Runtime Function: unsigned long long fract __fractusaudq (unsigned 1839 accum A) 1840 -- Runtime Function: unsigned short accum __fractusauha2 (unsigned 1841 accum A) 1842 -- Runtime Function: unsigned long accum __fractusauda2 (unsigned accum 1843 A) 1844 -- Runtime Function: unsigned long long accum __fractusauta2 (unsigned 1845 accum A) 1846 -- Runtime Function: signed char __fractusaqi (unsigned accum A) 1847 -- Runtime Function: short __fractusahi (unsigned accum A) 1848 -- Runtime Function: int __fractusasi (unsigned accum A) 1849 -- Runtime Function: long __fractusadi (unsigned accum A) 1850 -- Runtime Function: long long __fractusati (unsigned accum A) 1851 -- Runtime Function: float __fractusasf (unsigned accum A) 1852 -- Runtime Function: double __fractusadf (unsigned accum A) 1853 -- Runtime Function: short fract __fractudaqq (unsigned long accum A) 1854 -- Runtime Function: fract __fractudahq (unsigned long accum A) 1855 -- Runtime Function: long fract __fractudasq (unsigned long accum A) 1856 -- Runtime Function: long long fract __fractudadq (unsigned long accum 1857 A) 1858 -- Runtime Function: short accum __fractudaha (unsigned long accum A) 1859 -- Runtime Function: accum __fractudasa (unsigned long accum A) 1860 -- Runtime Function: long accum __fractudada (unsigned long accum A) 1861 -- Runtime Function: long long accum __fractudata (unsigned long accum 1862 A) 1863 -- Runtime Function: unsigned short fract __fractudauqq (unsigned long 1864 accum A) 1865 -- Runtime Function: unsigned fract __fractudauhq (unsigned long accum 1866 A) 1867 -- Runtime Function: unsigned long fract __fractudausq (unsigned long 1868 accum A) 1869 -- Runtime Function: unsigned long long fract __fractudaudq (unsigned 1870 long accum A) 1871 -- Runtime Function: unsigned short accum __fractudauha2 (unsigned long 1872 accum A) 1873 -- Runtime Function: unsigned accum __fractudausa2 (unsigned long accum 1874 A) 1875 -- Runtime Function: unsigned long long accum __fractudauta2 (unsigned 1876 long accum A) 1877 -- Runtime Function: signed char __fractudaqi (unsigned long accum A) 1878 -- Runtime Function: short __fractudahi (unsigned long accum A) 1879 -- Runtime Function: int __fractudasi (unsigned long accum A) 1880 -- Runtime Function: long __fractudadi (unsigned long accum A) 1881 -- Runtime Function: long long __fractudati (unsigned long accum A) 1882 -- Runtime Function: float __fractudasf (unsigned long accum A) 1883 -- Runtime Function: double __fractudadf (unsigned long accum A) 1884 -- Runtime Function: short fract __fractutaqq (unsigned long long accum 1885 A) 1886 -- Runtime Function: fract __fractutahq (unsigned long long accum A) 1887 -- Runtime Function: long fract __fractutasq (unsigned long long accum 1888 A) 1889 -- Runtime Function: long long fract __fractutadq (unsigned long long 1890 accum A) 1891 -- Runtime Function: short accum __fractutaha (unsigned long long accum 1892 A) 1893 -- Runtime Function: accum __fractutasa (unsigned long long accum A) 1894 -- Runtime Function: long accum __fractutada (unsigned long long accum 1895 A) 1896 -- Runtime Function: long long accum __fractutata (unsigned long long 1897 accum A) 1898 -- Runtime Function: unsigned short fract __fractutauqq (unsigned long 1899 long accum A) 1900 -- Runtime Function: unsigned fract __fractutauhq (unsigned long long 1901 accum A) 1902 -- Runtime Function: unsigned long fract __fractutausq (unsigned long 1903 long accum A) 1904 -- Runtime Function: unsigned long long fract __fractutaudq (unsigned 1905 long long accum A) 1906 -- Runtime Function: unsigned short accum __fractutauha2 (unsigned long 1907 long accum A) 1908 -- Runtime Function: unsigned accum __fractutausa2 (unsigned long long 1909 accum A) 1910 -- Runtime Function: unsigned long accum __fractutauda2 (unsigned long 1911 long accum A) 1912 -- Runtime Function: signed char __fractutaqi (unsigned long long accum 1913 A) 1914 -- Runtime Function: short __fractutahi (unsigned long long accum A) 1915 -- Runtime Function: int __fractutasi (unsigned long long accum A) 1916 -- Runtime Function: long __fractutadi (unsigned long long accum A) 1917 -- Runtime Function: long long __fractutati (unsigned long long accum 1918 A) 1919 -- Runtime Function: float __fractutasf (unsigned long long accum A) 1920 -- Runtime Function: double __fractutadf (unsigned long long accum A) 1921 -- Runtime Function: short fract __fractqiqq (signed char A) 1922 -- Runtime Function: fract __fractqihq (signed char A) 1923 -- Runtime Function: long fract __fractqisq (signed char A) 1924 -- Runtime Function: long long fract __fractqidq (signed char A) 1925 -- Runtime Function: short accum __fractqiha (signed char A) 1926 -- Runtime Function: accum __fractqisa (signed char A) 1927 -- Runtime Function: long accum __fractqida (signed char A) 1928 -- Runtime Function: long long accum __fractqita (signed char A) 1929 -- Runtime Function: unsigned short fract __fractqiuqq (signed char A) 1930 -- Runtime Function: unsigned fract __fractqiuhq (signed char A) 1931 -- Runtime Function: unsigned long fract __fractqiusq (signed char A) 1932 -- Runtime Function: unsigned long long fract __fractqiudq (signed char 1933 A) 1934 -- Runtime Function: unsigned short accum __fractqiuha (signed char A) 1935 -- Runtime Function: unsigned accum __fractqiusa (signed char A) 1936 -- Runtime Function: unsigned long accum __fractqiuda (signed char A) 1937 -- Runtime Function: unsigned long long accum __fractqiuta (signed char 1938 A) 1939 -- Runtime Function: short fract __fracthiqq (short A) 1940 -- Runtime Function: fract __fracthihq (short A) 1941 -- Runtime Function: long fract __fracthisq (short A) 1942 -- Runtime Function: long long fract __fracthidq (short A) 1943 -- Runtime Function: short accum __fracthiha (short A) 1944 -- Runtime Function: accum __fracthisa (short A) 1945 -- Runtime Function: long accum __fracthida (short A) 1946 -- Runtime Function: long long accum __fracthita (short A) 1947 -- Runtime Function: unsigned short fract __fracthiuqq (short A) 1948 -- Runtime Function: unsigned fract __fracthiuhq (short A) 1949 -- Runtime Function: unsigned long fract __fracthiusq (short A) 1950 -- Runtime Function: unsigned long long fract __fracthiudq (short A) 1951 -- Runtime Function: unsigned short accum __fracthiuha (short A) 1952 -- Runtime Function: unsigned accum __fracthiusa (short A) 1953 -- Runtime Function: unsigned long accum __fracthiuda (short A) 1954 -- Runtime Function: unsigned long long accum __fracthiuta (short A) 1955 -- Runtime Function: short fract __fractsiqq (int A) 1956 -- Runtime Function: fract __fractsihq (int A) 1957 -- Runtime Function: long fract __fractsisq (int A) 1958 -- Runtime Function: long long fract __fractsidq (int A) 1959 -- Runtime Function: short accum __fractsiha (int A) 1960 -- Runtime Function: accum __fractsisa (int A) 1961 -- Runtime Function: long accum __fractsida (int A) 1962 -- Runtime Function: long long accum __fractsita (int A) 1963 -- Runtime Function: unsigned short fract __fractsiuqq (int A) 1964 -- Runtime Function: unsigned fract __fractsiuhq (int A) 1965 -- Runtime Function: unsigned long fract __fractsiusq (int A) 1966 -- Runtime Function: unsigned long long fract __fractsiudq (int A) 1967 -- Runtime Function: unsigned short accum __fractsiuha (int A) 1968 -- Runtime Function: unsigned accum __fractsiusa (int A) 1969 -- Runtime Function: unsigned long accum __fractsiuda (int A) 1970 -- Runtime Function: unsigned long long accum __fractsiuta (int A) 1971 -- Runtime Function: short fract __fractdiqq (long A) 1972 -- Runtime Function: fract __fractdihq (long A) 1973 -- Runtime Function: long fract __fractdisq (long A) 1974 -- Runtime Function: long long fract __fractdidq (long A) 1975 -- Runtime Function: short accum __fractdiha (long A) 1976 -- Runtime Function: accum __fractdisa (long A) 1977 -- Runtime Function: long accum __fractdida (long A) 1978 -- Runtime Function: long long accum __fractdita (long A) 1979 -- Runtime Function: unsigned short fract __fractdiuqq (long A) 1980 -- Runtime Function: unsigned fract __fractdiuhq (long A) 1981 -- Runtime Function: unsigned long fract __fractdiusq (long A) 1982 -- Runtime Function: unsigned long long fract __fractdiudq (long A) 1983 -- Runtime Function: unsigned short accum __fractdiuha (long A) 1984 -- Runtime Function: unsigned accum __fractdiusa (long A) 1985 -- Runtime Function: unsigned long accum __fractdiuda (long A) 1986 -- Runtime Function: unsigned long long accum __fractdiuta (long A) 1987 -- Runtime Function: short fract __fracttiqq (long long A) 1988 -- Runtime Function: fract __fracttihq (long long A) 1989 -- Runtime Function: long fract __fracttisq (long long A) 1990 -- Runtime Function: long long fract __fracttidq (long long A) 1991 -- Runtime Function: short accum __fracttiha (long long A) 1992 -- Runtime Function: accum __fracttisa (long long A) 1993 -- Runtime Function: long accum __fracttida (long long A) 1994 -- Runtime Function: long long accum __fracttita (long long A) 1995 -- Runtime Function: unsigned short fract __fracttiuqq (long long A) 1996 -- Runtime Function: unsigned fract __fracttiuhq (long long A) 1997 -- Runtime Function: unsigned long fract __fracttiusq (long long A) 1998 -- Runtime Function: unsigned long long fract __fracttiudq (long long 1999 A) 2000 -- Runtime Function: unsigned short accum __fracttiuha (long long A) 2001 -- Runtime Function: unsigned accum __fracttiusa (long long A) 2002 -- Runtime Function: unsigned long accum __fracttiuda (long long A) 2003 -- Runtime Function: unsigned long long accum __fracttiuta (long long 2004 A) 2005 -- Runtime Function: short fract __fractsfqq (float A) 2006 -- Runtime Function: fract __fractsfhq (float A) 2007 -- Runtime Function: long fract __fractsfsq (float A) 2008 -- Runtime Function: long long fract __fractsfdq (float A) 2009 -- Runtime Function: short accum __fractsfha (float A) 2010 -- Runtime Function: accum __fractsfsa (float A) 2011 -- Runtime Function: long accum __fractsfda (float A) 2012 -- Runtime Function: long long accum __fractsfta (float A) 2013 -- Runtime Function: unsigned short fract __fractsfuqq (float A) 2014 -- Runtime Function: unsigned fract __fractsfuhq (float A) 2015 -- Runtime Function: unsigned long fract __fractsfusq (float A) 2016 -- Runtime Function: unsigned long long fract __fractsfudq (float A) 2017 -- Runtime Function: unsigned short accum __fractsfuha (float A) 2018 -- Runtime Function: unsigned accum __fractsfusa (float A) 2019 -- Runtime Function: unsigned long accum __fractsfuda (float A) 2020 -- Runtime Function: unsigned long long accum __fractsfuta (float A) 2021 -- Runtime Function: short fract __fractdfqq (double A) 2022 -- Runtime Function: fract __fractdfhq (double A) 2023 -- Runtime Function: long fract __fractdfsq (double A) 2024 -- Runtime Function: long long fract __fractdfdq (double A) 2025 -- Runtime Function: short accum __fractdfha (double A) 2026 -- Runtime Function: accum __fractdfsa (double A) 2027 -- Runtime Function: long accum __fractdfda (double A) 2028 -- Runtime Function: long long accum __fractdfta (double A) 2029 -- Runtime Function: unsigned short fract __fractdfuqq (double A) 2030 -- Runtime Function: unsigned fract __fractdfuhq (double A) 2031 -- Runtime Function: unsigned long fract __fractdfusq (double A) 2032 -- Runtime Function: unsigned long long fract __fractdfudq (double A) 2033 -- Runtime Function: unsigned short accum __fractdfuha (double A) 2034 -- Runtime Function: unsigned accum __fractdfusa (double A) 2035 -- Runtime Function: unsigned long accum __fractdfuda (double A) 2036 -- Runtime Function: unsigned long long accum __fractdfuta (double A) 2037 These functions convert from fractional and signed non-fractionals 2038 to fractionals and signed non-fractionals, without saturation. 2039 2040 -- Runtime Function: fract __satfractqqhq2 (short fract A) 2041 -- Runtime Function: long fract __satfractqqsq2 (short fract A) 2042 -- Runtime Function: long long fract __satfractqqdq2 (short fract A) 2043 -- Runtime Function: short accum __satfractqqha (short fract A) 2044 -- Runtime Function: accum __satfractqqsa (short fract A) 2045 -- Runtime Function: long accum __satfractqqda (short fract A) 2046 -- Runtime Function: long long accum __satfractqqta (short fract A) 2047 -- Runtime Function: unsigned short fract __satfractqquqq (short fract 2048 A) 2049 -- Runtime Function: unsigned fract __satfractqquhq (short fract A) 2050 -- Runtime Function: unsigned long fract __satfractqqusq (short fract 2051 A) 2052 -- Runtime Function: unsigned long long fract __satfractqqudq (short 2053 fract A) 2054 -- Runtime Function: unsigned short accum __satfractqquha (short fract 2055 A) 2056 -- Runtime Function: unsigned accum __satfractqqusa (short fract A) 2057 -- Runtime Function: unsigned long accum __satfractqquda (short fract 2058 A) 2059 -- Runtime Function: unsigned long long accum __satfractqquta (short 2060 fract A) 2061 -- Runtime Function: short fract __satfracthqqq2 (fract A) 2062 -- Runtime Function: long fract __satfracthqsq2 (fract A) 2063 -- Runtime Function: long long fract __satfracthqdq2 (fract A) 2064 -- Runtime Function: short accum __satfracthqha (fract A) 2065 -- Runtime Function: accum __satfracthqsa (fract A) 2066 -- Runtime Function: long accum __satfracthqda (fract A) 2067 -- Runtime Function: long long accum __satfracthqta (fract A) 2068 -- Runtime Function: unsigned short fract __satfracthquqq (fract A) 2069 -- Runtime Function: unsigned fract __satfracthquhq (fract A) 2070 -- Runtime Function: unsigned long fract __satfracthqusq (fract A) 2071 -- Runtime Function: unsigned long long fract __satfracthqudq (fract A) 2072 -- Runtime Function: unsigned short accum __satfracthquha (fract A) 2073 -- Runtime Function: unsigned accum __satfracthqusa (fract A) 2074 -- Runtime Function: unsigned long accum __satfracthquda (fract A) 2075 -- Runtime Function: unsigned long long accum __satfracthquta (fract A) 2076 -- Runtime Function: short fract __satfractsqqq2 (long fract A) 2077 -- Runtime Function: fract __satfractsqhq2 (long fract A) 2078 -- Runtime Function: long long fract __satfractsqdq2 (long fract A) 2079 -- Runtime Function: short accum __satfractsqha (long fract A) 2080 -- Runtime Function: accum __satfractsqsa (long fract A) 2081 -- Runtime Function: long accum __satfractsqda (long fract A) 2082 -- Runtime Function: long long accum __satfractsqta (long fract A) 2083 -- Runtime Function: unsigned short fract __satfractsquqq (long fract 2084 A) 2085 -- Runtime Function: unsigned fract __satfractsquhq (long fract A) 2086 -- Runtime Function: unsigned long fract __satfractsqusq (long fract A) 2087 -- Runtime Function: unsigned long long fract __satfractsqudq (long 2088 fract A) 2089 -- Runtime Function: unsigned short accum __satfractsquha (long fract 2090 A) 2091 -- Runtime Function: unsigned accum __satfractsqusa (long fract A) 2092 -- Runtime Function: unsigned long accum __satfractsquda (long fract A) 2093 -- Runtime Function: unsigned long long accum __satfractsquta (long 2094 fract A) 2095 -- Runtime Function: short fract __satfractdqqq2 (long long fract A) 2096 -- Runtime Function: fract __satfractdqhq2 (long long fract A) 2097 -- Runtime Function: long fract __satfractdqsq2 (long long fract A) 2098 -- Runtime Function: short accum __satfractdqha (long long fract A) 2099 -- Runtime Function: accum __satfractdqsa (long long fract A) 2100 -- Runtime Function: long accum __satfractdqda (long long fract A) 2101 -- Runtime Function: long long accum __satfractdqta (long long fract A) 2102 -- Runtime Function: unsigned short fract __satfractdquqq (long long 2103 fract A) 2104 -- Runtime Function: unsigned fract __satfractdquhq (long long fract A) 2105 -- Runtime Function: unsigned long fract __satfractdqusq (long long 2106 fract A) 2107 -- Runtime Function: unsigned long long fract __satfractdqudq (long 2108 long fract A) 2109 -- Runtime Function: unsigned short accum __satfractdquha (long long 2110 fract A) 2111 -- Runtime Function: unsigned accum __satfractdqusa (long long fract A) 2112 -- Runtime Function: unsigned long accum __satfractdquda (long long 2113 fract A) 2114 -- Runtime Function: unsigned long long accum __satfractdquta (long 2115 long fract A) 2116 -- Runtime Function: short fract __satfracthaqq (short accum A) 2117 -- Runtime Function: fract __satfracthahq (short accum A) 2118 -- Runtime Function: long fract __satfracthasq (short accum A) 2119 -- Runtime Function: long long fract __satfracthadq (short accum A) 2120 -- Runtime Function: accum __satfracthasa2 (short accum A) 2121 -- Runtime Function: long accum __satfracthada2 (short accum A) 2122 -- Runtime Function: long long accum __satfracthata2 (short accum A) 2123 -- Runtime Function: unsigned short fract __satfracthauqq (short accum 2124 A) 2125 -- Runtime Function: unsigned fract __satfracthauhq (short accum A) 2126 -- Runtime Function: unsigned long fract __satfracthausq (short accum 2127 A) 2128 -- Runtime Function: unsigned long long fract __satfracthaudq (short 2129 accum A) 2130 -- Runtime Function: unsigned short accum __satfracthauha (short accum 2131 A) 2132 -- Runtime Function: unsigned accum __satfracthausa (short accum A) 2133 -- Runtime Function: unsigned long accum __satfracthauda (short accum 2134 A) 2135 -- Runtime Function: unsigned long long accum __satfracthauta (short 2136 accum A) 2137 -- Runtime Function: short fract __satfractsaqq (accum A) 2138 -- Runtime Function: fract __satfractsahq (accum A) 2139 -- Runtime Function: long fract __satfractsasq (accum A) 2140 -- Runtime Function: long long fract __satfractsadq (accum A) 2141 -- Runtime Function: short accum __satfractsaha2 (accum A) 2142 -- Runtime Function: long accum __satfractsada2 (accum A) 2143 -- Runtime Function: long long accum __satfractsata2 (accum A) 2144 -- Runtime Function: unsigned short fract __satfractsauqq (accum A) 2145 -- Runtime Function: unsigned fract __satfractsauhq (accum A) 2146 -- Runtime Function: unsigned long fract __satfractsausq (accum A) 2147 -- Runtime Function: unsigned long long fract __satfractsaudq (accum A) 2148 -- Runtime Function: unsigned short accum __satfractsauha (accum A) 2149 -- Runtime Function: unsigned accum __satfractsausa (accum A) 2150 -- Runtime Function: unsigned long accum __satfractsauda (accum A) 2151 -- Runtime Function: unsigned long long accum __satfractsauta (accum A) 2152 -- Runtime Function: short fract __satfractdaqq (long accum A) 2153 -- Runtime Function: fract __satfractdahq (long accum A) 2154 -- Runtime Function: long fract __satfractdasq (long accum A) 2155 -- Runtime Function: long long fract __satfractdadq (long accum A) 2156 -- Runtime Function: short accum __satfractdaha2 (long accum A) 2157 -- Runtime Function: accum __satfractdasa2 (long accum A) 2158 -- Runtime Function: long long accum __satfractdata2 (long accum A) 2159 -- Runtime Function: unsigned short fract __satfractdauqq (long accum 2160 A) 2161 -- Runtime Function: unsigned fract __satfractdauhq (long accum A) 2162 -- Runtime Function: unsigned long fract __satfractdausq (long accum A) 2163 -- Runtime Function: unsigned long long fract __satfractdaudq (long 2164 accum A) 2165 -- Runtime Function: unsigned short accum __satfractdauha (long accum 2166 A) 2167 -- Runtime Function: unsigned accum __satfractdausa (long accum A) 2168 -- Runtime Function: unsigned long accum __satfractdauda (long accum A) 2169 -- Runtime Function: unsigned long long accum __satfractdauta (long 2170 accum A) 2171 -- Runtime Function: short fract __satfracttaqq (long long accum A) 2172 -- Runtime Function: fract __satfracttahq (long long accum A) 2173 -- Runtime Function: long fract __satfracttasq (long long accum A) 2174 -- Runtime Function: long long fract __satfracttadq (long long accum A) 2175 -- Runtime Function: short accum __satfracttaha2 (long long accum A) 2176 -- Runtime Function: accum __satfracttasa2 (long long accum A) 2177 -- Runtime Function: long accum __satfracttada2 (long long accum A) 2178 -- Runtime Function: unsigned short fract __satfracttauqq (long long 2179 accum A) 2180 -- Runtime Function: unsigned fract __satfracttauhq (long long accum A) 2181 -- Runtime Function: unsigned long fract __satfracttausq (long long 2182 accum A) 2183 -- Runtime Function: unsigned long long fract __satfracttaudq (long 2184 long accum A) 2185 -- Runtime Function: unsigned short accum __satfracttauha (long long 2186 accum A) 2187 -- Runtime Function: unsigned accum __satfracttausa (long long accum A) 2188 -- Runtime Function: unsigned long accum __satfracttauda (long long 2189 accum A) 2190 -- Runtime Function: unsigned long long accum __satfracttauta (long 2191 long accum A) 2192 -- Runtime Function: short fract __satfractuqqqq (unsigned short fract 2193 A) 2194 -- Runtime Function: fract __satfractuqqhq (unsigned short fract A) 2195 -- Runtime Function: long fract __satfractuqqsq (unsigned short fract 2196 A) 2197 -- Runtime Function: long long fract __satfractuqqdq (unsigned short 2198 fract A) 2199 -- Runtime Function: short accum __satfractuqqha (unsigned short fract 2200 A) 2201 -- Runtime Function: accum __satfractuqqsa (unsigned short fract A) 2202 -- Runtime Function: long accum __satfractuqqda (unsigned short fract 2203 A) 2204 -- Runtime Function: long long accum __satfractuqqta (unsigned short 2205 fract A) 2206 -- Runtime Function: unsigned fract __satfractuqquhq2 (unsigned short 2207 fract A) 2208 -- Runtime Function: unsigned long fract __satfractuqqusq2 (unsigned 2209 short fract A) 2210 -- Runtime Function: unsigned long long fract __satfractuqqudq2 2211 (unsigned short fract A) 2212 -- Runtime Function: unsigned short accum __satfractuqquha (unsigned 2213 short fract A) 2214 -- Runtime Function: unsigned accum __satfractuqqusa (unsigned short 2215 fract A) 2216 -- Runtime Function: unsigned long accum __satfractuqquda (unsigned 2217 short fract A) 2218 -- Runtime Function: unsigned long long accum __satfractuqquta 2219 (unsigned short fract A) 2220 -- Runtime Function: short fract __satfractuhqqq (unsigned fract A) 2221 -- Runtime Function: fract __satfractuhqhq (unsigned fract A) 2222 -- Runtime Function: long fract __satfractuhqsq (unsigned fract A) 2223 -- Runtime Function: long long fract __satfractuhqdq (unsigned fract A) 2224 -- Runtime Function: short accum __satfractuhqha (unsigned fract A) 2225 -- Runtime Function: accum __satfractuhqsa (unsigned fract A) 2226 -- Runtime Function: long accum __satfractuhqda (unsigned fract A) 2227 -- Runtime Function: long long accum __satfractuhqta (unsigned fract A) 2228 -- Runtime Function: unsigned short fract __satfractuhquqq2 (unsigned 2229 fract A) 2230 -- Runtime Function: unsigned long fract __satfractuhqusq2 (unsigned 2231 fract A) 2232 -- Runtime Function: unsigned long long fract __satfractuhqudq2 2233 (unsigned fract A) 2234 -- Runtime Function: unsigned short accum __satfractuhquha (unsigned 2235 fract A) 2236 -- Runtime Function: unsigned accum __satfractuhqusa (unsigned fract A) 2237 -- Runtime Function: unsigned long accum __satfractuhquda (unsigned 2238 fract A) 2239 -- Runtime Function: unsigned long long accum __satfractuhquta 2240 (unsigned fract A) 2241 -- Runtime Function: short fract __satfractusqqq (unsigned long fract 2242 A) 2243 -- Runtime Function: fract __satfractusqhq (unsigned long fract A) 2244 -- Runtime Function: long fract __satfractusqsq (unsigned long fract A) 2245 -- Runtime Function: long long fract __satfractusqdq (unsigned long 2246 fract A) 2247 -- Runtime Function: short accum __satfractusqha (unsigned long fract 2248 A) 2249 -- Runtime Function: accum __satfractusqsa (unsigned long fract A) 2250 -- Runtime Function: long accum __satfractusqda (unsigned long fract A) 2251 -- Runtime Function: long long accum __satfractusqta (unsigned long 2252 fract A) 2253 -- Runtime Function: unsigned short fract __satfractusquqq2 (unsigned 2254 long fract A) 2255 -- Runtime Function: unsigned fract __satfractusquhq2 (unsigned long 2256 fract A) 2257 -- Runtime Function: unsigned long long fract __satfractusqudq2 2258 (unsigned long fract A) 2259 -- Runtime Function: unsigned short accum __satfractusquha (unsigned 2260 long fract A) 2261 -- Runtime Function: unsigned accum __satfractusqusa (unsigned long 2262 fract A) 2263 -- Runtime Function: unsigned long accum __satfractusquda (unsigned 2264 long fract A) 2265 -- Runtime Function: unsigned long long accum __satfractusquta 2266 (unsigned long fract A) 2267 -- Runtime Function: short fract __satfractudqqq (unsigned long long 2268 fract A) 2269 -- Runtime Function: fract __satfractudqhq (unsigned long long fract A) 2270 -- Runtime Function: long fract __satfractudqsq (unsigned long long 2271 fract A) 2272 -- Runtime Function: long long fract __satfractudqdq (unsigned long 2273 long fract A) 2274 -- Runtime Function: short accum __satfractudqha (unsigned long long 2275 fract A) 2276 -- Runtime Function: accum __satfractudqsa (unsigned long long fract A) 2277 -- Runtime Function: long accum __satfractudqda (unsigned long long 2278 fract A) 2279 -- Runtime Function: long long accum __satfractudqta (unsigned long 2280 long fract A) 2281 -- Runtime Function: unsigned short fract __satfractudquqq2 (unsigned 2282 long long fract A) 2283 -- Runtime Function: unsigned fract __satfractudquhq2 (unsigned long 2284 long fract A) 2285 -- Runtime Function: unsigned long fract __satfractudqusq2 (unsigned 2286 long long fract A) 2287 -- Runtime Function: unsigned short accum __satfractudquha (unsigned 2288 long long fract A) 2289 -- Runtime Function: unsigned accum __satfractudqusa (unsigned long 2290 long fract A) 2291 -- Runtime Function: unsigned long accum __satfractudquda (unsigned 2292 long long fract A) 2293 -- Runtime Function: unsigned long long accum __satfractudquta 2294 (unsigned long long fract A) 2295 -- Runtime Function: short fract __satfractuhaqq (unsigned short accum 2296 A) 2297 -- Runtime Function: fract __satfractuhahq (unsigned short accum A) 2298 -- Runtime Function: long fract __satfractuhasq (unsigned short accum 2299 A) 2300 -- Runtime Function: long long fract __satfractuhadq (unsigned short 2301 accum A) 2302 -- Runtime Function: short accum __satfractuhaha (unsigned short accum 2303 A) 2304 -- Runtime Function: accum __satfractuhasa (unsigned short accum A) 2305 -- Runtime Function: long accum __satfractuhada (unsigned short accum 2306 A) 2307 -- Runtime Function: long long accum __satfractuhata (unsigned short 2308 accum A) 2309 -- Runtime Function: unsigned short fract __satfractuhauqq (unsigned 2310 short accum A) 2311 -- Runtime Function: unsigned fract __satfractuhauhq (unsigned short 2312 accum A) 2313 -- Runtime Function: unsigned long fract __satfractuhausq (unsigned 2314 short accum A) 2315 -- Runtime Function: unsigned long long fract __satfractuhaudq 2316 (unsigned short accum A) 2317 -- Runtime Function: unsigned accum __satfractuhausa2 (unsigned short 2318 accum A) 2319 -- Runtime Function: unsigned long accum __satfractuhauda2 (unsigned 2320 short accum A) 2321 -- Runtime Function: unsigned long long accum __satfractuhauta2 2322 (unsigned short accum A) 2323 -- Runtime Function: short fract __satfractusaqq (unsigned accum A) 2324 -- Runtime Function: fract __satfractusahq (unsigned accum A) 2325 -- Runtime Function: long fract __satfractusasq (unsigned accum A) 2326 -- Runtime Function: long long fract __satfractusadq (unsigned accum A) 2327 -- Runtime Function: short accum __satfractusaha (unsigned accum A) 2328 -- Runtime Function: accum __satfractusasa (unsigned accum A) 2329 -- Runtime Function: long accum __satfractusada (unsigned accum A) 2330 -- Runtime Function: long long accum __satfractusata (unsigned accum A) 2331 -- Runtime Function: unsigned short fract __satfractusauqq (unsigned 2332 accum A) 2333 -- Runtime Function: unsigned fract __satfractusauhq (unsigned accum A) 2334 -- Runtime Function: unsigned long fract __satfractusausq (unsigned 2335 accum A) 2336 -- Runtime Function: unsigned long long fract __satfractusaudq 2337 (unsigned accum A) 2338 -- Runtime Function: unsigned short accum __satfractusauha2 (unsigned 2339 accum A) 2340 -- Runtime Function: unsigned long accum __satfractusauda2 (unsigned 2341 accum A) 2342 -- Runtime Function: unsigned long long accum __satfractusauta2 2343 (unsigned accum A) 2344 -- Runtime Function: short fract __satfractudaqq (unsigned long accum 2345 A) 2346 -- Runtime Function: fract __satfractudahq (unsigned long accum A) 2347 -- Runtime Function: long fract __satfractudasq (unsigned long accum A) 2348 -- Runtime Function: long long fract __satfractudadq (unsigned long 2349 accum A) 2350 -- Runtime Function: short accum __satfractudaha (unsigned long accum 2351 A) 2352 -- Runtime Function: accum __satfractudasa (unsigned long accum A) 2353 -- Runtime Function: long accum __satfractudada (unsigned long accum A) 2354 -- Runtime Function: long long accum __satfractudata (unsigned long 2355 accum A) 2356 -- Runtime Function: unsigned short fract __satfractudauqq (unsigned 2357 long accum A) 2358 -- Runtime Function: unsigned fract __satfractudauhq (unsigned long 2359 accum A) 2360 -- Runtime Function: unsigned long fract __satfractudausq (unsigned 2361 long accum A) 2362 -- Runtime Function: unsigned long long fract __satfractudaudq 2363 (unsigned long accum A) 2364 -- Runtime Function: unsigned short accum __satfractudauha2 (unsigned 2365 long accum A) 2366 -- Runtime Function: unsigned accum __satfractudausa2 (unsigned long 2367 accum A) 2368 -- Runtime Function: unsigned long long accum __satfractudauta2 2369 (unsigned long accum A) 2370 -- Runtime Function: short fract __satfractutaqq (unsigned long long 2371 accum A) 2372 -- Runtime Function: fract __satfractutahq (unsigned long long accum A) 2373 -- Runtime Function: long fract __satfractutasq (unsigned long long 2374 accum A) 2375 -- Runtime Function: long long fract __satfractutadq (unsigned long 2376 long accum A) 2377 -- Runtime Function: short accum __satfractutaha (unsigned long long 2378 accum A) 2379 -- Runtime Function: accum __satfractutasa (unsigned long long accum A) 2380 -- Runtime Function: long accum __satfractutada (unsigned long long 2381 accum A) 2382 -- Runtime Function: long long accum __satfractutata (unsigned long 2383 long accum A) 2384 -- Runtime Function: unsigned short fract __satfractutauqq (unsigned 2385 long long accum A) 2386 -- Runtime Function: unsigned fract __satfractutauhq (unsigned long 2387 long accum A) 2388 -- Runtime Function: unsigned long fract __satfractutausq (unsigned 2389 long long accum A) 2390 -- Runtime Function: unsigned long long fract __satfractutaudq 2391 (unsigned long long accum A) 2392 -- Runtime Function: unsigned short accum __satfractutauha2 (unsigned 2393 long long accum A) 2394 -- Runtime Function: unsigned accum __satfractutausa2 (unsigned long 2395 long accum A) 2396 -- Runtime Function: unsigned long accum __satfractutauda2 (unsigned 2397 long long accum A) 2398 -- Runtime Function: short fract __satfractqiqq (signed char A) 2399 -- Runtime Function: fract __satfractqihq (signed char A) 2400 -- Runtime Function: long fract __satfractqisq (signed char A) 2401 -- Runtime Function: long long fract __satfractqidq (signed char A) 2402 -- Runtime Function: short accum __satfractqiha (signed char A) 2403 -- Runtime Function: accum __satfractqisa (signed char A) 2404 -- Runtime Function: long accum __satfractqida (signed char A) 2405 -- Runtime Function: long long accum __satfractqita (signed char A) 2406 -- Runtime Function: unsigned short fract __satfractqiuqq (signed char 2407 A) 2408 -- Runtime Function: unsigned fract __satfractqiuhq (signed char A) 2409 -- Runtime Function: unsigned long fract __satfractqiusq (signed char 2410 A) 2411 -- Runtime Function: unsigned long long fract __satfractqiudq (signed 2412 char A) 2413 -- Runtime Function: unsigned short accum __satfractqiuha (signed char 2414 A) 2415 -- Runtime Function: unsigned accum __satfractqiusa (signed char A) 2416 -- Runtime Function: unsigned long accum __satfractqiuda (signed char 2417 A) 2418 -- Runtime Function: unsigned long long accum __satfractqiuta (signed 2419 char A) 2420 -- Runtime Function: short fract __satfracthiqq (short A) 2421 -- Runtime Function: fract __satfracthihq (short A) 2422 -- Runtime Function: long fract __satfracthisq (short A) 2423 -- Runtime Function: long long fract __satfracthidq (short A) 2424 -- Runtime Function: short accum __satfracthiha (short A) 2425 -- Runtime Function: accum __satfracthisa (short A) 2426 -- Runtime Function: long accum __satfracthida (short A) 2427 -- Runtime Function: long long accum __satfracthita (short A) 2428 -- Runtime Function: unsigned short fract __satfracthiuqq (short A) 2429 -- Runtime Function: unsigned fract __satfracthiuhq (short A) 2430 -- Runtime Function: unsigned long fract __satfracthiusq (short A) 2431 -- Runtime Function: unsigned long long fract __satfracthiudq (short A) 2432 -- Runtime Function: unsigned short accum __satfracthiuha (short A) 2433 -- Runtime Function: unsigned accum __satfracthiusa (short A) 2434 -- Runtime Function: unsigned long accum __satfracthiuda (short A) 2435 -- Runtime Function: unsigned long long accum __satfracthiuta (short A) 2436 -- Runtime Function: short fract __satfractsiqq (int A) 2437 -- Runtime Function: fract __satfractsihq (int A) 2438 -- Runtime Function: long fract __satfractsisq (int A) 2439 -- Runtime Function: long long fract __satfractsidq (int A) 2440 -- Runtime Function: short accum __satfractsiha (int A) 2441 -- Runtime Function: accum __satfractsisa (int A) 2442 -- Runtime Function: long accum __satfractsida (int A) 2443 -- Runtime Function: long long accum __satfractsita (int A) 2444 -- Runtime Function: unsigned short fract __satfractsiuqq (int A) 2445 -- Runtime Function: unsigned fract __satfractsiuhq (int A) 2446 -- Runtime Function: unsigned long fract __satfractsiusq (int A) 2447 -- Runtime Function: unsigned long long fract __satfractsiudq (int A) 2448 -- Runtime Function: unsigned short accum __satfractsiuha (int A) 2449 -- Runtime Function: unsigned accum __satfractsiusa (int A) 2450 -- Runtime Function: unsigned long accum __satfractsiuda (int A) 2451 -- Runtime Function: unsigned long long accum __satfractsiuta (int A) 2452 -- Runtime Function: short fract __satfractdiqq (long A) 2453 -- Runtime Function: fract __satfractdihq (long A) 2454 -- Runtime Function: long fract __satfractdisq (long A) 2455 -- Runtime Function: long long fract __satfractdidq (long A) 2456 -- Runtime Function: short accum __satfractdiha (long A) 2457 -- Runtime Function: accum __satfractdisa (long A) 2458 -- Runtime Function: long accum __satfractdida (long A) 2459 -- Runtime Function: long long accum __satfractdita (long A) 2460 -- Runtime Function: unsigned short fract __satfractdiuqq (long A) 2461 -- Runtime Function: unsigned fract __satfractdiuhq (long A) 2462 -- Runtime Function: unsigned long fract __satfractdiusq (long A) 2463 -- Runtime Function: unsigned long long fract __satfractdiudq (long A) 2464 -- Runtime Function: unsigned short accum __satfractdiuha (long A) 2465 -- Runtime Function: unsigned accum __satfractdiusa (long A) 2466 -- Runtime Function: unsigned long accum __satfractdiuda (long A) 2467 -- Runtime Function: unsigned long long accum __satfractdiuta (long A) 2468 -- Runtime Function: short fract __satfracttiqq (long long A) 2469 -- Runtime Function: fract __satfracttihq (long long A) 2470 -- Runtime Function: long fract __satfracttisq (long long A) 2471 -- Runtime Function: long long fract __satfracttidq (long long A) 2472 -- Runtime Function: short accum __satfracttiha (long long A) 2473 -- Runtime Function: accum __satfracttisa (long long A) 2474 -- Runtime Function: long accum __satfracttida (long long A) 2475 -- Runtime Function: long long accum __satfracttita (long long A) 2476 -- Runtime Function: unsigned short fract __satfracttiuqq (long long A) 2477 -- Runtime Function: unsigned fract __satfracttiuhq (long long A) 2478 -- Runtime Function: unsigned long fract __satfracttiusq (long long A) 2479 -- Runtime Function: unsigned long long fract __satfracttiudq (long 2480 long A) 2481 -- Runtime Function: unsigned short accum __satfracttiuha (long long A) 2482 -- Runtime Function: unsigned accum __satfracttiusa (long long A) 2483 -- Runtime Function: unsigned long accum __satfracttiuda (long long A) 2484 -- Runtime Function: unsigned long long accum __satfracttiuta (long 2485 long A) 2486 -- Runtime Function: short fract __satfractsfqq (float A) 2487 -- Runtime Function: fract __satfractsfhq (float A) 2488 -- Runtime Function: long fract __satfractsfsq (float A) 2489 -- Runtime Function: long long fract __satfractsfdq (float A) 2490 -- Runtime Function: short accum __satfractsfha (float A) 2491 -- Runtime Function: accum __satfractsfsa (float A) 2492 -- Runtime Function: long accum __satfractsfda (float A) 2493 -- Runtime Function: long long accum __satfractsfta (float A) 2494 -- Runtime Function: unsigned short fract __satfractsfuqq (float A) 2495 -- Runtime Function: unsigned fract __satfractsfuhq (float A) 2496 -- Runtime Function: unsigned long fract __satfractsfusq (float A) 2497 -- Runtime Function: unsigned long long fract __satfractsfudq (float A) 2498 -- Runtime Function: unsigned short accum __satfractsfuha (float A) 2499 -- Runtime Function: unsigned accum __satfractsfusa (float A) 2500 -- Runtime Function: unsigned long accum __satfractsfuda (float A) 2501 -- Runtime Function: unsigned long long accum __satfractsfuta (float A) 2502 -- Runtime Function: short fract __satfractdfqq (double A) 2503 -- Runtime Function: fract __satfractdfhq (double A) 2504 -- Runtime Function: long fract __satfractdfsq (double A) 2505 -- Runtime Function: long long fract __satfractdfdq (double A) 2506 -- Runtime Function: short accum __satfractdfha (double A) 2507 -- Runtime Function: accum __satfractdfsa (double A) 2508 -- Runtime Function: long accum __satfractdfda (double A) 2509 -- Runtime Function: long long accum __satfractdfta (double A) 2510 -- Runtime Function: unsigned short fract __satfractdfuqq (double A) 2511 -- Runtime Function: unsigned fract __satfractdfuhq (double A) 2512 -- Runtime Function: unsigned long fract __satfractdfusq (double A) 2513 -- Runtime Function: unsigned long long fract __satfractdfudq (double 2514 A) 2515 -- Runtime Function: unsigned short accum __satfractdfuha (double A) 2516 -- Runtime Function: unsigned accum __satfractdfusa (double A) 2517 -- Runtime Function: unsigned long accum __satfractdfuda (double A) 2518 -- Runtime Function: unsigned long long accum __satfractdfuta (double 2519 A) 2520 The functions convert from fractional and signed non-fractionals to 2521 fractionals, with saturation. 2522 2523 -- Runtime Function: unsigned char __fractunsqqqi (short fract A) 2524 -- Runtime Function: unsigned short __fractunsqqhi (short fract A) 2525 -- Runtime Function: unsigned int __fractunsqqsi (short fract A) 2526 -- Runtime Function: unsigned long __fractunsqqdi (short fract A) 2527 -- Runtime Function: unsigned long long __fractunsqqti (short fract A) 2528 -- Runtime Function: unsigned char __fractunshqqi (fract A) 2529 -- Runtime Function: unsigned short __fractunshqhi (fract A) 2530 -- Runtime Function: unsigned int __fractunshqsi (fract A) 2531 -- Runtime Function: unsigned long __fractunshqdi (fract A) 2532 -- Runtime Function: unsigned long long __fractunshqti (fract A) 2533 -- Runtime Function: unsigned char __fractunssqqi (long fract A) 2534 -- Runtime Function: unsigned short __fractunssqhi (long fract A) 2535 -- Runtime Function: unsigned int __fractunssqsi (long fract A) 2536 -- Runtime Function: unsigned long __fractunssqdi (long fract A) 2537 -- Runtime Function: unsigned long long __fractunssqti (long fract A) 2538 -- Runtime Function: unsigned char __fractunsdqqi (long long fract A) 2539 -- Runtime Function: unsigned short __fractunsdqhi (long long fract A) 2540 -- Runtime Function: unsigned int __fractunsdqsi (long long fract A) 2541 -- Runtime Function: unsigned long __fractunsdqdi (long long fract A) 2542 -- Runtime Function: unsigned long long __fractunsdqti (long long fract 2543 A) 2544 -- Runtime Function: unsigned char __fractunshaqi (short accum A) 2545 -- Runtime Function: unsigned short __fractunshahi (short accum A) 2546 -- Runtime Function: unsigned int __fractunshasi (short accum A) 2547 -- Runtime Function: unsigned long __fractunshadi (short accum A) 2548 -- Runtime Function: unsigned long long __fractunshati (short accum A) 2549 -- Runtime Function: unsigned char __fractunssaqi (accum A) 2550 -- Runtime Function: unsigned short __fractunssahi (accum A) 2551 -- Runtime Function: unsigned int __fractunssasi (accum A) 2552 -- Runtime Function: unsigned long __fractunssadi (accum A) 2553 -- Runtime Function: unsigned long long __fractunssati (accum A) 2554 -- Runtime Function: unsigned char __fractunsdaqi (long accum A) 2555 -- Runtime Function: unsigned short __fractunsdahi (long accum A) 2556 -- Runtime Function: unsigned int __fractunsdasi (long accum A) 2557 -- Runtime Function: unsigned long __fractunsdadi (long accum A) 2558 -- Runtime Function: unsigned long long __fractunsdati (long accum A) 2559 -- Runtime Function: unsigned char __fractunstaqi (long long accum A) 2560 -- Runtime Function: unsigned short __fractunstahi (long long accum A) 2561 -- Runtime Function: unsigned int __fractunstasi (long long accum A) 2562 -- Runtime Function: unsigned long __fractunstadi (long long accum A) 2563 -- Runtime Function: unsigned long long __fractunstati (long long accum 2564 A) 2565 -- Runtime Function: unsigned char __fractunsuqqqi (unsigned short 2566 fract A) 2567 -- Runtime Function: unsigned short __fractunsuqqhi (unsigned short 2568 fract A) 2569 -- Runtime Function: unsigned int __fractunsuqqsi (unsigned short fract 2570 A) 2571 -- Runtime Function: unsigned long __fractunsuqqdi (unsigned short 2572 fract A) 2573 -- Runtime Function: unsigned long long __fractunsuqqti (unsigned short 2574 fract A) 2575 -- Runtime Function: unsigned char __fractunsuhqqi (unsigned fract A) 2576 -- Runtime Function: unsigned short __fractunsuhqhi (unsigned fract A) 2577 -- Runtime Function: unsigned int __fractunsuhqsi (unsigned fract A) 2578 -- Runtime Function: unsigned long __fractunsuhqdi (unsigned fract A) 2579 -- Runtime Function: unsigned long long __fractunsuhqti (unsigned fract 2580 A) 2581 -- Runtime Function: unsigned char __fractunsusqqi (unsigned long fract 2582 A) 2583 -- Runtime Function: unsigned short __fractunsusqhi (unsigned long 2584 fract A) 2585 -- Runtime Function: unsigned int __fractunsusqsi (unsigned long fract 2586 A) 2587 -- Runtime Function: unsigned long __fractunsusqdi (unsigned long fract 2588 A) 2589 -- Runtime Function: unsigned long long __fractunsusqti (unsigned long 2590 fract A) 2591 -- Runtime Function: unsigned char __fractunsudqqi (unsigned long long 2592 fract A) 2593 -- Runtime Function: unsigned short __fractunsudqhi (unsigned long long 2594 fract A) 2595 -- Runtime Function: unsigned int __fractunsudqsi (unsigned long long 2596 fract A) 2597 -- Runtime Function: unsigned long __fractunsudqdi (unsigned long long 2598 fract A) 2599 -- Runtime Function: unsigned long long __fractunsudqti (unsigned long 2600 long fract A) 2601 -- Runtime Function: unsigned char __fractunsuhaqi (unsigned short 2602 accum A) 2603 -- Runtime Function: unsigned short __fractunsuhahi (unsigned short 2604 accum A) 2605 -- Runtime Function: unsigned int __fractunsuhasi (unsigned short accum 2606 A) 2607 -- Runtime Function: unsigned long __fractunsuhadi (unsigned short 2608 accum A) 2609 -- Runtime Function: unsigned long long __fractunsuhati (unsigned short 2610 accum A) 2611 -- Runtime Function: unsigned char __fractunsusaqi (unsigned accum A) 2612 -- Runtime Function: unsigned short __fractunsusahi (unsigned accum A) 2613 -- Runtime Function: unsigned int __fractunsusasi (unsigned accum A) 2614 -- Runtime Function: unsigned long __fractunsusadi (unsigned accum A) 2615 -- Runtime Function: unsigned long long __fractunsusati (unsigned accum 2616 A) 2617 -- Runtime Function: unsigned char __fractunsudaqi (unsigned long accum 2618 A) 2619 -- Runtime Function: unsigned short __fractunsudahi (unsigned long 2620 accum A) 2621 -- Runtime Function: unsigned int __fractunsudasi (unsigned long accum 2622 A) 2623 -- Runtime Function: unsigned long __fractunsudadi (unsigned long accum 2624 A) 2625 -- Runtime Function: unsigned long long __fractunsudati (unsigned long 2626 accum A) 2627 -- Runtime Function: unsigned char __fractunsutaqi (unsigned long long 2628 accum A) 2629 -- Runtime Function: unsigned short __fractunsutahi (unsigned long long 2630 accum A) 2631 -- Runtime Function: unsigned int __fractunsutasi (unsigned long long 2632 accum A) 2633 -- Runtime Function: unsigned long __fractunsutadi (unsigned long long 2634 accum A) 2635 -- Runtime Function: unsigned long long __fractunsutati (unsigned long 2636 long accum A) 2637 -- Runtime Function: short fract __fractunsqiqq (unsigned char A) 2638 -- Runtime Function: fract __fractunsqihq (unsigned char A) 2639 -- Runtime Function: long fract __fractunsqisq (unsigned char A) 2640 -- Runtime Function: long long fract __fractunsqidq (unsigned char A) 2641 -- Runtime Function: short accum __fractunsqiha (unsigned char A) 2642 -- Runtime Function: accum __fractunsqisa (unsigned char A) 2643 -- Runtime Function: long accum __fractunsqida (unsigned char A) 2644 -- Runtime Function: long long accum __fractunsqita (unsigned char A) 2645 -- Runtime Function: unsigned short fract __fractunsqiuqq (unsigned 2646 char A) 2647 -- Runtime Function: unsigned fract __fractunsqiuhq (unsigned char A) 2648 -- Runtime Function: unsigned long fract __fractunsqiusq (unsigned char 2649 A) 2650 -- Runtime Function: unsigned long long fract __fractunsqiudq (unsigned 2651 char A) 2652 -- Runtime Function: unsigned short accum __fractunsqiuha (unsigned 2653 char A) 2654 -- Runtime Function: unsigned accum __fractunsqiusa (unsigned char A) 2655 -- Runtime Function: unsigned long accum __fractunsqiuda (unsigned char 2656 A) 2657 -- Runtime Function: unsigned long long accum __fractunsqiuta (unsigned 2658 char A) 2659 -- Runtime Function: short fract __fractunshiqq (unsigned short A) 2660 -- Runtime Function: fract __fractunshihq (unsigned short A) 2661 -- Runtime Function: long fract __fractunshisq (unsigned short A) 2662 -- Runtime Function: long long fract __fractunshidq (unsigned short A) 2663 -- Runtime Function: short accum __fractunshiha (unsigned short A) 2664 -- Runtime Function: accum __fractunshisa (unsigned short A) 2665 -- Runtime Function: long accum __fractunshida (unsigned short A) 2666 -- Runtime Function: long long accum __fractunshita (unsigned short A) 2667 -- Runtime Function: unsigned short fract __fractunshiuqq (unsigned 2668 short A) 2669 -- Runtime Function: unsigned fract __fractunshiuhq (unsigned short A) 2670 -- Runtime Function: unsigned long fract __fractunshiusq (unsigned 2671 short A) 2672 -- Runtime Function: unsigned long long fract __fractunshiudq (unsigned 2673 short A) 2674 -- Runtime Function: unsigned short accum __fractunshiuha (unsigned 2675 short A) 2676 -- Runtime Function: unsigned accum __fractunshiusa (unsigned short A) 2677 -- Runtime Function: unsigned long accum __fractunshiuda (unsigned 2678 short A) 2679 -- Runtime Function: unsigned long long accum __fractunshiuta (unsigned 2680 short A) 2681 -- Runtime Function: short fract __fractunssiqq (unsigned int A) 2682 -- Runtime Function: fract __fractunssihq (unsigned int A) 2683 -- Runtime Function: long fract __fractunssisq (unsigned int A) 2684 -- Runtime Function: long long fract __fractunssidq (unsigned int A) 2685 -- Runtime Function: short accum __fractunssiha (unsigned int A) 2686 -- Runtime Function: accum __fractunssisa (unsigned int A) 2687 -- Runtime Function: long accum __fractunssida (unsigned int A) 2688 -- Runtime Function: long long accum __fractunssita (unsigned int A) 2689 -- Runtime Function: unsigned short fract __fractunssiuqq (unsigned int 2690 A) 2691 -- Runtime Function: unsigned fract __fractunssiuhq (unsigned int A) 2692 -- Runtime Function: unsigned long fract __fractunssiusq (unsigned int 2693 A) 2694 -- Runtime Function: unsigned long long fract __fractunssiudq (unsigned 2695 int A) 2696 -- Runtime Function: unsigned short accum __fractunssiuha (unsigned int 2697 A) 2698 -- Runtime Function: unsigned accum __fractunssiusa (unsigned int A) 2699 -- Runtime Function: unsigned long accum __fractunssiuda (unsigned int 2700 A) 2701 -- Runtime Function: unsigned long long accum __fractunssiuta (unsigned 2702 int A) 2703 -- Runtime Function: short fract __fractunsdiqq (unsigned long A) 2704 -- Runtime Function: fract __fractunsdihq (unsigned long A) 2705 -- Runtime Function: long fract __fractunsdisq (unsigned long A) 2706 -- Runtime Function: long long fract __fractunsdidq (unsigned long A) 2707 -- Runtime Function: short accum __fractunsdiha (unsigned long A) 2708 -- Runtime Function: accum __fractunsdisa (unsigned long A) 2709 -- Runtime Function: long accum __fractunsdida (unsigned long A) 2710 -- Runtime Function: long long accum __fractunsdita (unsigned long A) 2711 -- Runtime Function: unsigned short fract __fractunsdiuqq (unsigned 2712 long A) 2713 -- Runtime Function: unsigned fract __fractunsdiuhq (unsigned long A) 2714 -- Runtime Function: unsigned long fract __fractunsdiusq (unsigned long 2715 A) 2716 -- Runtime Function: unsigned long long fract __fractunsdiudq (unsigned 2717 long A) 2718 -- Runtime Function: unsigned short accum __fractunsdiuha (unsigned 2719 long A) 2720 -- Runtime Function: unsigned accum __fractunsdiusa (unsigned long A) 2721 -- Runtime Function: unsigned long accum __fractunsdiuda (unsigned long 2722 A) 2723 -- Runtime Function: unsigned long long accum __fractunsdiuta (unsigned 2724 long A) 2725 -- Runtime Function: short fract __fractunstiqq (unsigned long long A) 2726 -- Runtime Function: fract __fractunstihq (unsigned long long A) 2727 -- Runtime Function: long fract __fractunstisq (unsigned long long A) 2728 -- Runtime Function: long long fract __fractunstidq (unsigned long long 2729 A) 2730 -- Runtime Function: short accum __fractunstiha (unsigned long long A) 2731 -- Runtime Function: accum __fractunstisa (unsigned long long A) 2732 -- Runtime Function: long accum __fractunstida (unsigned long long A) 2733 -- Runtime Function: long long accum __fractunstita (unsigned long long 2734 A) 2735 -- Runtime Function: unsigned short fract __fractunstiuqq (unsigned 2736 long long A) 2737 -- Runtime Function: unsigned fract __fractunstiuhq (unsigned long long 2738 A) 2739 -- Runtime Function: unsigned long fract __fractunstiusq (unsigned long 2740 long A) 2741 -- Runtime Function: unsigned long long fract __fractunstiudq (unsigned 2742 long long A) 2743 -- Runtime Function: unsigned short accum __fractunstiuha (unsigned 2744 long long A) 2745 -- Runtime Function: unsigned accum __fractunstiusa (unsigned long long 2746 A) 2747 -- Runtime Function: unsigned long accum __fractunstiuda (unsigned long 2748 long A) 2749 -- Runtime Function: unsigned long long accum __fractunstiuta (unsigned 2750 long long A) 2751 These functions convert from fractionals to unsigned 2752 non-fractionals; and from unsigned non-fractionals to fractionals, 2753 without saturation. 2754 2755 -- Runtime Function: short fract __satfractunsqiqq (unsigned char A) 2756 -- Runtime Function: fract __satfractunsqihq (unsigned char A) 2757 -- Runtime Function: long fract __satfractunsqisq (unsigned char A) 2758 -- Runtime Function: long long fract __satfractunsqidq (unsigned char 2759 A) 2760 -- Runtime Function: short accum __satfractunsqiha (unsigned char A) 2761 -- Runtime Function: accum __satfractunsqisa (unsigned char A) 2762 -- Runtime Function: long accum __satfractunsqida (unsigned char A) 2763 -- Runtime Function: long long accum __satfractunsqita (unsigned char 2764 A) 2765 -- Runtime Function: unsigned short fract __satfractunsqiuqq (unsigned 2766 char A) 2767 -- Runtime Function: unsigned fract __satfractunsqiuhq (unsigned char 2768 A) 2769 -- Runtime Function: unsigned long fract __satfractunsqiusq (unsigned 2770 char A) 2771 -- Runtime Function: unsigned long long fract __satfractunsqiudq 2772 (unsigned char A) 2773 -- Runtime Function: unsigned short accum __satfractunsqiuha (unsigned 2774 char A) 2775 -- Runtime Function: unsigned accum __satfractunsqiusa (unsigned char 2776 A) 2777 -- Runtime Function: unsigned long accum __satfractunsqiuda (unsigned 2778 char A) 2779 -- Runtime Function: unsigned long long accum __satfractunsqiuta 2780 (unsigned char A) 2781 -- Runtime Function: short fract __satfractunshiqq (unsigned short A) 2782 -- Runtime Function: fract __satfractunshihq (unsigned short A) 2783 -- Runtime Function: long fract __satfractunshisq (unsigned short A) 2784 -- Runtime Function: long long fract __satfractunshidq (unsigned short 2785 A) 2786 -- Runtime Function: short accum __satfractunshiha (unsigned short A) 2787 -- Runtime Function: accum __satfractunshisa (unsigned short A) 2788 -- Runtime Function: long accum __satfractunshida (unsigned short A) 2789 -- Runtime Function: long long accum __satfractunshita (unsigned short 2790 A) 2791 -- Runtime Function: unsigned short fract __satfractunshiuqq (unsigned 2792 short A) 2793 -- Runtime Function: unsigned fract __satfractunshiuhq (unsigned short 2794 A) 2795 -- Runtime Function: unsigned long fract __satfractunshiusq (unsigned 2796 short A) 2797 -- Runtime Function: unsigned long long fract __satfractunshiudq 2798 (unsigned short A) 2799 -- Runtime Function: unsigned short accum __satfractunshiuha (unsigned 2800 short A) 2801 -- Runtime Function: unsigned accum __satfractunshiusa (unsigned short 2802 A) 2803 -- Runtime Function: unsigned long accum __satfractunshiuda (unsigned 2804 short A) 2805 -- Runtime Function: unsigned long long accum __satfractunshiuta 2806 (unsigned short A) 2807 -- Runtime Function: short fract __satfractunssiqq (unsigned int A) 2808 -- Runtime Function: fract __satfractunssihq (unsigned int A) 2809 -- Runtime Function: long fract __satfractunssisq (unsigned int A) 2810 -- Runtime Function: long long fract __satfractunssidq (unsigned int A) 2811 -- Runtime Function: short accum __satfractunssiha (unsigned int A) 2812 -- Runtime Function: accum __satfractunssisa (unsigned int A) 2813 -- Runtime Function: long accum __satfractunssida (unsigned int A) 2814 -- Runtime Function: long long accum __satfractunssita (unsigned int A) 2815 -- Runtime Function: unsigned short fract __satfractunssiuqq (unsigned 2816 int A) 2817 -- Runtime Function: unsigned fract __satfractunssiuhq (unsigned int A) 2818 -- Runtime Function: unsigned long fract __satfractunssiusq (unsigned 2819 int A) 2820 -- Runtime Function: unsigned long long fract __satfractunssiudq 2821 (unsigned int A) 2822 -- Runtime Function: unsigned short accum __satfractunssiuha (unsigned 2823 int A) 2824 -- Runtime Function: unsigned accum __satfractunssiusa (unsigned int A) 2825 -- Runtime Function: unsigned long accum __satfractunssiuda (unsigned 2826 int A) 2827 -- Runtime Function: unsigned long long accum __satfractunssiuta 2828 (unsigned int A) 2829 -- Runtime Function: short fract __satfractunsdiqq (unsigned long A) 2830 -- Runtime Function: fract __satfractunsdihq (unsigned long A) 2831 -- Runtime Function: long fract __satfractunsdisq (unsigned long A) 2832 -- Runtime Function: long long fract __satfractunsdidq (unsigned long 2833 A) 2834 -- Runtime Function: short accum __satfractunsdiha (unsigned long A) 2835 -- Runtime Function: accum __satfractunsdisa (unsigned long A) 2836 -- Runtime Function: long accum __satfractunsdida (unsigned long A) 2837 -- Runtime Function: long long accum __satfractunsdita (unsigned long 2838 A) 2839 -- Runtime Function: unsigned short fract __satfractunsdiuqq (unsigned 2840 long A) 2841 -- Runtime Function: unsigned fract __satfractunsdiuhq (unsigned long 2842 A) 2843 -- Runtime Function: unsigned long fract __satfractunsdiusq (unsigned 2844 long A) 2845 -- Runtime Function: unsigned long long fract __satfractunsdiudq 2846 (unsigned long A) 2847 -- Runtime Function: unsigned short accum __satfractunsdiuha (unsigned 2848 long A) 2849 -- Runtime Function: unsigned accum __satfractunsdiusa (unsigned long 2850 A) 2851 -- Runtime Function: unsigned long accum __satfractunsdiuda (unsigned 2852 long A) 2853 -- Runtime Function: unsigned long long accum __satfractunsdiuta 2854 (unsigned long A) 2855 -- Runtime Function: short fract __satfractunstiqq (unsigned long long 2856 A) 2857 -- Runtime Function: fract __satfractunstihq (unsigned long long A) 2858 -- Runtime Function: long fract __satfractunstisq (unsigned long long 2859 A) 2860 -- Runtime Function: long long fract __satfractunstidq (unsigned long 2861 long A) 2862 -- Runtime Function: short accum __satfractunstiha (unsigned long long 2863 A) 2864 -- Runtime Function: accum __satfractunstisa (unsigned long long A) 2865 -- Runtime Function: long accum __satfractunstida (unsigned long long 2866 A) 2867 -- Runtime Function: long long accum __satfractunstita (unsigned long 2868 long A) 2869 -- Runtime Function: unsigned short fract __satfractunstiuqq (unsigned 2870 long long A) 2871 -- Runtime Function: unsigned fract __satfractunstiuhq (unsigned long 2872 long A) 2873 -- Runtime Function: unsigned long fract __satfractunstiusq (unsigned 2874 long long A) 2875 -- Runtime Function: unsigned long long fract __satfractunstiudq 2876 (unsigned long long A) 2877 -- Runtime Function: unsigned short accum __satfractunstiuha (unsigned 2878 long long A) 2879 -- Runtime Function: unsigned accum __satfractunstiusa (unsigned long 2880 long A) 2881 -- Runtime Function: unsigned long accum __satfractunstiuda (unsigned 2882 long long A) 2883 -- Runtime Function: unsigned long long accum __satfractunstiuta 2884 (unsigned long long A) 2885 These functions convert from unsigned non-fractionals to 2886 fractionals, with saturation. 2887 2888 2889File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Fixed-point fractional library routines, Up: Libgcc 2890 28914.5 Language-independent routines for exception handling 2892======================================================== 2893 2894document me! 2895 2896 _Unwind_DeleteException 2897 _Unwind_Find_FDE 2898 _Unwind_ForcedUnwind 2899 _Unwind_GetGR 2900 _Unwind_GetIP 2901 _Unwind_GetLanguageSpecificData 2902 _Unwind_GetRegionStart 2903 _Unwind_GetTextRelBase 2904 _Unwind_GetDataRelBase 2905 _Unwind_RaiseException 2906 _Unwind_Resume 2907 _Unwind_SetGR 2908 _Unwind_SetIP 2909 _Unwind_FindEnclosingFunction 2910 _Unwind_SjLj_Register 2911 _Unwind_SjLj_Unregister 2912 _Unwind_SjLj_RaiseException 2913 _Unwind_SjLj_ForcedUnwind 2914 _Unwind_SjLj_Resume 2915 __deregister_frame 2916 __deregister_frame_info 2917 __deregister_frame_info_bases 2918 __register_frame 2919 __register_frame_info 2920 __register_frame_info_bases 2921 __register_frame_info_table 2922 __register_frame_info_table_bases 2923 __register_frame_table 2924 2925 2926File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc 2927 29284.6 Miscellaneous runtime library routines 2929========================================== 2930 29314.6.1 Cache control functions 2932----------------------------- 2933 2934 -- Runtime Function: void __clear_cache (char *BEG, char *END) 2935 This function clears the instruction cache between BEG and END. 2936 29374.6.2 Split stack functions and variables 2938----------------------------------------- 2939 2940 -- Runtime Function: void * __splitstack_find (void *SEGMENT_ARG, void 2941 *SP, size_t LEN, void **NEXT_SEGMENT, void **NEXT_SP, void 2942 **INITIAL_SP) 2943 When using '-fsplit-stack', this call may be used to iterate over 2944 the stack segments. It may be called like this: 2945 void *next_segment = NULL; 2946 void *next_sp = NULL; 2947 void *initial_sp = NULL; 2948 void *stack; 2949 size_t stack_size; 2950 while ((stack = __splitstack_find (next_segment, next_sp, 2951 &stack_size, &next_segment, 2952 &next_sp, &initial_sp)) 2953 != NULL) 2954 { 2955 /* Stack segment starts at stack and is 2956 stack_size bytes long. */ 2957 } 2958 2959 There is no way to iterate over the stack segments of a different 2960 thread. However, what is permitted is for one thread to call this 2961 with the SEGMENT_ARG and SP arguments NULL, to pass NEXT_SEGMENT, 2962 NEXT_SP, and INITIAL_SP to a different thread, and then to suspend 2963 one way or another. A different thread may run the subsequent 2964 '__splitstack_find' iterations. Of course, this will only work if 2965 the first thread is suspended while the second thread is calling 2966 '__splitstack_find'. If not, the second thread could be looking at 2967 the stack while it is changing, and anything could happen. 2968 2969 -- Variable: __morestack_segments 2970 -- Variable: __morestack_current_segment 2971 -- Variable: __morestack_initial_sp 2972 Internal variables used by the '-fsplit-stack' implementation. 2973 2974 2975File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top 2976 29775 Language Front Ends in GCC 2978**************************** 2979 2980The interface to front ends for languages in GCC, and in particular the 2981'tree' structure (*note GENERIC::), was initially designed for C, and 2982many aspects of it are still somewhat biased towards C and C-like 2983languages. It is, however, reasonably well suited to other procedural 2984languages, and front ends for many such languages have been written for 2985GCC. 2986 2987 Writing a compiler as a front end for GCC, rather than compiling 2988directly to assembler or generating C code which is then compiled by 2989GCC, has several advantages: 2990 2991 * GCC front ends benefit from the support for many different target 2992 machines already present in GCC. 2993 * GCC front ends benefit from all the optimizations in GCC. Some of 2994 these, such as alias analysis, may work better when GCC is 2995 compiling directly from source code then when it is compiling from 2996 generated C code. 2997 * Better debugging information is generated when compiling directly 2998 from source code than when going via intermediate generated C code. 2999 3000 Because of the advantages of writing a compiler as a GCC front end, GCC 3001front ends have also been created for languages very different from 3002those for which GCC was designed, such as the declarative 3003logic/functional language Mercury. For these reasons, it may also be 3004useful to implement compilers created for specialized purposes (for 3005example, as part of a research project) as GCC front ends. 3006 3007 3008File: gccint.info, Node: Source Tree, Next: Testsuites, Prev: Languages, Up: Top 3009 30106 Source Tree Structure and Build System 3011**************************************** 3012 3013This chapter describes the structure of the GCC source tree, and how GCC 3014is built. The user documentation for building and installing GCC is in 3015a separate manual (<http://gcc.gnu.org/install/>), with which it is 3016presumed that you are familiar. 3017 3018* Menu: 3019 3020* Configure Terms:: Configuration terminology and history. 3021* Top Level:: The top level source directory. 3022* gcc Directory:: The 'gcc' subdirectory. 3023 3024 3025File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree 3026 30276.1 Configure Terms and History 3028=============================== 3029 3030The configure and build process has a long and colorful history, and can 3031be confusing to anyone who doesn't know why things are the way they are. 3032While there are other documents which describe the configuration process 3033in detail, here are a few things that everyone working on GCC should 3034know. 3035 3036 There are three system names that the build knows about: the machine 3037you are building on ("build"), the machine that you are building for 3038("host"), and the machine that GCC will produce code for ("target"). 3039When you configure GCC, you specify these with '--build=', '--host=', 3040and '--target='. 3041 3042 Specifying the host without specifying the build should be avoided, as 3043'configure' may (and once did) assume that the host you specify is also 3044the build, which may not be true. 3045 3046 If build, host, and target are all the same, this is called a "native". 3047If build and host are the same but target is different, this is called a 3048"cross". If build, host, and target are all different this is called a 3049"canadian" (for obscure reasons dealing with Canada's political party 3050and the background of the person working on the build at that time). If 3051host and target are the same, but build is different, you are using a 3052cross-compiler to build a native for a different system. Some people 3053call this a "host-x-host", "crossed native", or "cross-built native". 3054If build and target are the same, but host is different, you are using a 3055cross compiler to build a cross compiler that produces code for the 3056machine you're building on. This is rare, so there is no common way of 3057describing it. There is a proposal to call this a "crossback". 3058 3059 If build and host are the same, the GCC you are building will also be 3060used to build the target libraries (like 'libstdc++'). If build and 3061host are different, you must have already built and installed a cross 3062compiler that will be used to build the target libraries (if you 3063configured with '--target=foo-bar', this compiler will be called 3064'foo-bar-gcc'). 3065 3066 In the case of target libraries, the machine you're building for is the 3067machine you specified with '--target'. So, build is the machine you're 3068building on (no change there), host is the machine you're building for 3069(the target libraries are built for the target, so host is the target 3070you specified), and target doesn't apply (because you're not building a 3071compiler, you're building libraries). The configure/make process will 3072adjust these variables as needed. It also sets '$with_cross_host' to 3073the original '--host' value in case you need it. 3074 3075 The 'libiberty' support library is built up to three times: once for 3076the host, once for the target (even if they are the same), and once for 3077the build if build and host are different. This allows it to be used by 3078all programs which are generated in the course of the build process. 3079 3080 3081File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree 3082 30836.2 Top Level Source Directory 3084============================== 3085 3086The top level source directory in a GCC distribution contains several 3087files and directories that are shared with other software distributions 3088such as that of GNU Binutils. It also contains several subdirectories 3089that contain parts of GCC and its runtime libraries: 3090 3091'boehm-gc' 3092 The Boehm conservative garbage collector, used as part of the Java 3093 runtime library. 3094 3095'config' 3096 Autoconf macros and Makefile fragments used throughout the tree. 3097 3098'contrib' 3099 Contributed scripts that may be found useful in conjunction with 3100 GCC. One of these, 'contrib/texi2pod.pl', is used to generate man 3101 pages from Texinfo manuals as part of the GCC build process. 3102 3103'fixincludes' 3104 The support for fixing system headers to work with GCC. See 3105 'fixincludes/README' for more information. The headers fixed by 3106 this mechanism are installed in 'LIBSUBDIR/include-fixed'. Along 3107 with those headers, 'README-fixinc' is also installed, as 3108 'LIBSUBDIR/include-fixed/README'. 3109 3110'gcc' 3111 The main sources of GCC itself (except for runtime libraries), 3112 including optimizers, support for different target architectures, 3113 language front ends, and testsuites. *Note The 'gcc' Subdirectory: 3114 gcc Directory, for details. 3115 3116'gnattools' 3117 Support tools for GNAT. 3118 3119'include' 3120 Headers for the 'libiberty' library. 3121 3122'intl' 3123 GNU 'libintl', from GNU 'gettext', for systems which do not include 3124 it in 'libc'. 3125 3126'libada' 3127 The Ada runtime library. 3128 3129'libatomic' 3130 The runtime support library for atomic operations (e.g. for 3131 '__sync' and '__atomic'). 3132 3133'libcpp' 3134 The C preprocessor library. 3135 3136'libdecnumber' 3137 The Decimal Float support library. 3138 3139'libffi' 3140 The 'libffi' library, used as part of the Java runtime library. 3141 3142'libgcc' 3143 The GCC runtime library. 3144 3145'libgfortran' 3146 The Fortran runtime library. 3147 3148'libgo' 3149 The Go runtime library. The bulk of this library is mirrored from 3150 the master Go repository (http://code.google.com/p/go/). 3151 3152'libgomp' 3153 The GNU Offloading and Multi Processing Runtime Library. 3154 3155'libiberty' 3156 The 'libiberty' library, used for portability and for some 3157 generally useful data structures and algorithms. *Note 3158 Introduction: (libiberty)Top, for more information about this 3159 library. 3160 3161'libitm' 3162 The runtime support library for transactional memory. 3163 3164'libjava' 3165 The Java runtime library. 3166 3167'libobjc' 3168 The Objective-C and Objective-C++ runtime library. 3169 3170'libquadmath' 3171 The runtime support library for quad-precision math operations. 3172 3173'libssp' 3174 The Stack protector runtime library. 3175 3176'libstdc++-v3' 3177 The C++ runtime library. 3178 3179'lto-plugin' 3180 Plugin used by the linker if link-time optimizations are enabled. 3181 3182'maintainer-scripts' 3183 Scripts used by the 'gccadmin' account on 'gcc.gnu.org'. 3184 3185'zlib' 3186 The 'zlib' compression library, used by the Java front end, as part 3187 of the Java runtime library, and for compressing and uncompressing 3188 GCC's intermediate language in LTO object files. 3189 3190 The build system in the top level directory, including how recursion 3191into subdirectories works and how building runtime libraries for 3192multilibs is handled, is documented in a separate manual, included with 3193GNU Binutils. *Note GNU configure and build system: (configure)Top, for 3194details. 3195 3196 3197File: gccint.info, Node: gcc Directory, Prev: Top Level, Up: Source Tree 3198 31996.3 The 'gcc' Subdirectory 3200========================== 3201 3202The 'gcc' directory contains many files that are part of the C sources 3203of GCC, other files used as part of the configuration and build process, 3204and subdirectories including documentation and a testsuite. The files 3205that are sources of GCC are documented in a separate chapter. *Note 3206Passes and Files of the Compiler: Passes. 3207 3208* Menu: 3209 3210* Subdirectories:: Subdirectories of 'gcc'. 3211* Configuration:: The configuration process, and the files it uses. 3212* Build:: The build system in the 'gcc' directory. 3213* Makefile:: Targets in 'gcc/Makefile'. 3214* Library Files:: Library source files and headers under 'gcc/'. 3215* Headers:: Headers installed by GCC. 3216* Documentation:: Building documentation in GCC. 3217* Front End:: Anatomy of a language front end. 3218* Back End:: Anatomy of a target back end. 3219 3220 3221File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory 3222 32236.3.1 Subdirectories of 'gcc' 3224----------------------------- 3225 3226The 'gcc' directory contains the following subdirectories: 3227 3228'LANGUAGE' 3229 Subdirectories for various languages. Directories containing a 3230 file 'config-lang.in' are language subdirectories. The contents of 3231 the subdirectories 'c' (for C), 'cp' (for C++), 'objc' (for 3232 Objective-C), 'objcp' (for Objective-C++), and 'lto' (for LTO) are 3233 documented in this manual (*note Passes and Files of the Compiler: 3234 Passes.); those for other languages are not. *Note Anatomy of a 3235 Language Front End: Front End, for details of the files in these 3236 directories. 3237 3238'common' 3239 Source files shared between the compiler drivers (such as 'gcc') 3240 and the compilers proper (such as 'cc1'). If an architecture 3241 defines target hooks shared between those places, it also has a 3242 subdirectory in 'common/config'. *Note Target Structure::. 3243 3244'config' 3245 Configuration files for supported architectures and operating 3246 systems. *Note Anatomy of a Target Back End: Back End, for details 3247 of the files in this directory. 3248 3249'doc' 3250 Texinfo documentation for GCC, together with automatically 3251 generated man pages and support for converting the installation 3252 manual to HTML. *Note Documentation::. 3253 3254'ginclude' 3255 System headers installed by GCC, mainly those required by the C 3256 standard of freestanding implementations. *Note Headers Installed 3257 by GCC: Headers, for details of when these and other headers are 3258 installed. 3259 3260'po' 3261 Message catalogs with translations of messages produced by GCC into 3262 various languages, 'LANGUAGE.po'. This directory also contains 3263 'gcc.pot', the template for these message catalogues, 'exgettext', 3264 a wrapper around 'gettext' to extract the messages from the GCC 3265 sources and create 'gcc.pot', which is run by 'make gcc.pot', and 3266 'EXCLUDES', a list of files from which messages should not be 3267 extracted. 3268 3269'testsuite' 3270 The GCC testsuites (except for those for runtime libraries). *Note 3271 Testsuites::. 3272 3273 3274File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory 3275 32766.3.2 Configuration in the 'gcc' Directory 3277------------------------------------------ 3278 3279The 'gcc' directory is configured with an Autoconf-generated script 3280'configure'. The 'configure' script is generated from 'configure.ac' 3281and 'aclocal.m4'. From the files 'configure.ac' and 'acconfig.h', 3282Autoheader generates the file 'config.in'. The file 'cstamp-h.in' is 3283used as a timestamp. 3284 3285* Menu: 3286 3287* Config Fragments:: Scripts used by 'configure'. 3288* System Config:: The 'config.build', 'config.host', and 3289 'config.gcc' files. 3290* Configuration Files:: Files created by running 'configure'. 3291 3292 3293File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration 3294 32956.3.2.1 Scripts Used by 'configure' 3296................................... 3297 3298'configure' uses some other scripts to help in its work: 3299 3300 * The standard GNU 'config.sub' and 'config.guess' files, kept in the 3301 top level directory, are used. 3302 3303 * The file 'config.gcc' is used to handle configuration specific to 3304 the particular target machine. The file 'config.build' is used to 3305 handle configuration specific to the particular build machine. The 3306 file 'config.host' is used to handle configuration specific to the 3307 particular host machine. (In general, these should only be used 3308 for features that cannot reasonably be tested in Autoconf feature 3309 tests.) *Note The 'config.build'; 'config.host'; and 'config.gcc' 3310 Files: System Config, for details of the contents of these files. 3311 3312 * Each language subdirectory has a file 'LANGUAGE/config-lang.in' 3313 that is used for front-end-specific configuration. *Note The Front 3314 End 'config-lang.in' File: Front End Config, for details of this 3315 file. 3316 3317 * A helper script 'configure.frag' is used as part of creating the 3318 output of 'configure'. 3319 3320 3321File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration 3322 33236.3.2.2 The 'config.build'; 'config.host'; and 'config.gcc' Files 3324................................................................. 3325 3326The 'config.build' file contains specific rules for particular systems 3327which GCC is built on. This should be used as rarely as possible, as 3328the behavior of the build system can always be detected by autoconf. 3329 3330 The 'config.host' file contains specific rules for particular systems 3331which GCC will run on. This is rarely needed. 3332 3333 The 'config.gcc' file contains specific rules for particular systems 3334which GCC will generate code for. This is usually needed. 3335 3336 Each file has a list of the shell variables it sets, with descriptions, 3337at the top of the file. 3338 3339 FIXME: document the contents of these files, and what variables should 3340be set to control build, host and target configuration. 3341 3342 3343File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration 3344 33456.3.2.3 Files Created by 'configure' 3346.................................... 3347 3348Here we spell out what files will be set up by 'configure' in the 'gcc' 3349directory. Some other files are created as temporary files in the 3350configuration process, and are not used in the subsequent build; these 3351are not documented. 3352 3353 * 'Makefile' is constructed from 'Makefile.in', together with the 3354 host and target fragments (*note Makefile Fragments: Fragments.) 3355 't-TARGET' and 'x-HOST' from 'config', if any, and language 3356 Makefile fragments 'LANGUAGE/Make-lang.in'. 3357 * 'auto-host.h' contains information about the host machine 3358 determined by 'configure'. If the host machine is different from 3359 the build machine, then 'auto-build.h' is also created, containing 3360 such information about the build machine. 3361 * 'config.status' is a script that may be run to recreate the current 3362 configuration. 3363 * 'configargs.h' is a header containing details of the arguments 3364 passed to 'configure' to configure GCC, and of the thread model 3365 used. 3366 * 'cstamp-h' is used as a timestamp. 3367 * If a language 'config-lang.in' file (*note The Front End 3368 'config-lang.in' File: Front End Config.) sets 'outputs', then the 3369 files listed in 'outputs' there are also generated. 3370 3371 The following configuration headers are created from the Makefile, 3372using 'mkconfig.sh', rather than directly by 'configure'. 'config.h', 3373'bconfig.h' and 'tconfig.h' all contain the 'xm-MACHINE.h' header, if 3374any, appropriate to the host, build and target machines respectively, 3375the configuration headers for the target, and some definitions; for the 3376host and build machines, these include the autoconfigured headers 3377generated by 'configure'. The other configuration headers are 3378determined by 'config.gcc'. They also contain the typedefs for 'rtx', 3379'rtvec' and 'tree'. 3380 3381 * 'config.h', for use in programs that run on the host machine. 3382 * 'bconfig.h', for use in programs that run on the build machine. 3383 * 'tconfig.h', for use in programs and libraries for the target 3384 machine. 3385 * 'tm_p.h', which includes the header 'MACHINE-protos.h' that 3386 contains prototypes for functions in the target 'MACHINE.c' file. 3387 The header 'MACHINE-protos.h' can include prototypes of functions 3388 that use rtl and tree data structures inside appropriate '#ifdef 3389 RTX_CODE' and '#ifdef TREE_CODE' conditional code segements. The 3390 'MACHINE-protos.h' is included after the 'rtl.h' and/or 'tree.h' 3391 would have been included. The 'tm_p.h' also includes the header 3392 'tm-preds.h' which is generated by 'genpreds' program during the 3393 build to define the declarations and inline functions for the 3394 predicate functions. 3395 3396 3397File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory 3398 33996.3.3 Build System in the 'gcc' Directory 3400----------------------------------------- 3401 3402FIXME: describe the build system, including what is built in what 3403stages. Also list the various source files that are used in the build 3404process but aren't source files of GCC itself and so aren't documented 3405below (*note Passes::). 3406 3407 3408File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory 3409 34106.3.4 Makefile Targets 3411---------------------- 3412 3413These targets are available from the 'gcc' directory: 3414 3415'all' 3416 This is the default target. Depending on what your 3417 build/host/target configuration is, it coordinates all the things 3418 that need to be built. 3419 3420'doc' 3421 Produce info-formatted documentation and man pages. Essentially it 3422 calls 'make man' and 'make info'. 3423 3424'dvi' 3425 Produce DVI-formatted documentation. 3426 3427'pdf' 3428 Produce PDF-formatted documentation. 3429 3430'html' 3431 Produce HTML-formatted documentation. 3432 3433'man' 3434 Generate man pages. 3435 3436'info' 3437 Generate info-formatted pages. 3438 3439'mostlyclean' 3440 Delete the files made while building the compiler. 3441 3442'clean' 3443 That, and all the other files built by 'make all'. 3444 3445'distclean' 3446 That, and all the files created by 'configure'. 3447 3448'maintainer-clean' 3449 Distclean plus any file that can be generated from other files. 3450 Note that additional tools may be required beyond what is normally 3451 needed to build GCC. 3452 3453'srcextra' 3454 Generates files in the source directory that are not 3455 version-controlled but should go into a release tarball. 3456 3457'srcinfo' 3458'srcman' 3459 Copies the info-formatted and manpage documentation into the source 3460 directory usually for the purpose of generating a release tarball. 3461 3462'install' 3463 Installs GCC. 3464 3465'uninstall' 3466 Deletes installed files, though this is not supported. 3467 3468'check' 3469 Run the testsuite. This creates a 'testsuite' subdirectory that 3470 has various '.sum' and '.log' files containing the results of the 3471 testing. You can run subsets with, for example, 'make check-gcc'. 3472 You can specify specific tests by setting 'RUNTESTFLAGS' to be the 3473 name of the '.exp' file, optionally followed by (for some tests) an 3474 equals and a file wildcard, like: 3475 3476 make check-gcc RUNTESTFLAGS="execute.exp=19980413-*" 3477 3478 Note that running the testsuite may require additional tools be 3479 installed, such as Tcl or DejaGnu. 3480 3481 The toplevel tree from which you start GCC compilation is not the GCC 3482directory, but rather a complex Makefile that coordinates the various 3483steps of the build, including bootstrapping the compiler and using the 3484new compiler to build target libraries. 3485 3486 When GCC is configured for a native configuration, the default action 3487for 'make' is to do a full three-stage bootstrap. This means that GCC 3488is built three times--once with the native compiler, once with the 3489native-built compiler it just built, and once with the compiler it built 3490the second time. In theory, the last two should produce the same 3491results, which 'make compare' can check. Each stage is configured 3492separately and compiled into a separate directory, to minimize problems 3493due to ABI incompatibilities between the native compiler and GCC. 3494 3495 If you do a change, rebuilding will also start from the first stage and 3496"bubble" up the change through the three stages. Each stage is taken 3497from its build directory (if it had been built previously), rebuilt, and 3498copied to its subdirectory. This will allow you to, for example, 3499continue a bootstrap after fixing a bug which causes the stage2 build to 3500crash. It does not provide as good coverage of the compiler as 3501bootstrapping from scratch, but it ensures that the new code is 3502syntactically correct (e.g., that you did not use GCC extensions by 3503mistake), and avoids spurious bootstrap comparison failures(1). 3504 3505 Other targets available from the top level include: 3506 3507'bootstrap-lean' 3508 Like 'bootstrap', except that the various stages are removed once 3509 they're no longer needed. This saves disk space. 3510 3511'bootstrap2' 3512'bootstrap2-lean' 3513 Performs only the first two stages of bootstrap. Unlike a 3514 three-stage bootstrap, this does not perform a comparison to test 3515 that the compiler is running properly. Note that the disk space 3516 required by a "lean" bootstrap is approximately independent of the 3517 number of stages. 3518 3519'stageN-bubble (N = 1...4, profile, feedback)' 3520 Rebuild all the stages up to N, with the appropriate flags, 3521 "bubbling" the changes as described above. 3522 3523'all-stageN (N = 1...4, profile, feedback)' 3524 Assuming that stage N has already been built, rebuild it with the 3525 appropriate flags. This is rarely needed. 3526 3527'cleanstrap' 3528 Remove everything ('make clean') and rebuilds ('make bootstrap'). 3529 3530'compare' 3531 Compares the results of stages 2 and 3. This ensures that the 3532 compiler is running properly, since it should produce the same 3533 object files regardless of how it itself was compiled. 3534 3535'profiledbootstrap' 3536 Builds a compiler with profiling feedback information. In this 3537 case, the second and third stages are named 'profile' and 3538 'feedback', respectively. For more information, see *note Building 3539 with profile feedback: (gccinstall)Building. 3540 3541'restrap' 3542 Restart a bootstrap, so that everything that was not built with the 3543 system compiler is rebuilt. 3544 3545'stageN-start (N = 1...4, profile, feedback)' 3546 For each package that is bootstrapped, rename directories so that, 3547 for example, 'gcc' points to the stageN GCC, compiled with the 3548 stageN-1 GCC(2). 3549 3550 You will invoke this target if you need to test or debug the stageN 3551 GCC. If you only need to execute GCC (but you need not run 'make' 3552 either to rebuild it or to run test suites), you should be able to 3553 work directly in the 'stageN-gcc' directory. This makes it easier 3554 to debug multiple stages in parallel. 3555 3556'stage' 3557 For each package that is bootstrapped, relocate its build directory 3558 to indicate its stage. For example, if the 'gcc' directory points 3559 to the stage2 GCC, after invoking this target it will be renamed to 3560 'stage2-gcc'. 3561 3562 If you wish to use non-default GCC flags when compiling the stage2 and 3563stage3 compilers, set 'BOOT_CFLAGS' on the command line when doing 3564'make'. 3565 3566 Usually, the first stage only builds the languages that the compiler is 3567written in: typically, C and maybe Ada. If you are debugging a 3568miscompilation of a different stage2 front-end (for example, of the 3569Fortran front-end), you may want to have front-ends for other languages 3570in the first stage as well. To do so, set 'STAGE1_LANGUAGES' on the 3571command line when doing 'make'. 3572 3573 For example, in the aforementioned scenario of debugging a Fortran 3574front-end miscompilation caused by the stage1 compiler, you may need a 3575command like 3576 3577 make stage2-bubble STAGE1_LANGUAGES=c,fortran 3578 3579 Alternatively, you can use per-language targets to build and test 3580languages that are not enabled by default in stage1. For example, 'make 3581f951' will build a Fortran compiler even in the stage1 build directory. 3582 3583 ---------- Footnotes ---------- 3584 3585 (1) Except if the compiler was buggy and miscompiled some of the 3586files that were not modified. In this case, it's best to use 'make 3587restrap'. 3588 3589 (2) Customarily, the system compiler is also termed the 'stage0' GCC. 3590 3591 3592File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory 3593 35946.3.5 Library Source Files and Headers under the 'gcc' Directory 3595---------------------------------------------------------------- 3596 3597FIXME: list here, with explanation, all the C source files and headers 3598under the 'gcc' directory that aren't built into the GCC executable but 3599rather are part of runtime libraries and object files, such as 3600'crtstuff.c' and 'unwind-dw2.c'. *Note Headers Installed by GCC: 3601Headers, for more information about the 'ginclude' directory. 3602 3603 3604File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory 3605 36066.3.6 Headers Installed by GCC 3607------------------------------ 3608 3609In general, GCC expects the system C library to provide most of the 3610headers to be used with it. However, GCC will fix those headers if 3611necessary to make them work with GCC, and will install some headers 3612required of freestanding implementations. These headers are installed 3613in 'LIBSUBDIR/include'. Headers for non-C runtime libraries are also 3614installed by GCC; these are not documented here. (FIXME: document them 3615somewhere.) 3616 3617 Several of the headers GCC installs are in the 'ginclude' directory. 3618These headers, 'iso646.h', 'stdarg.h', 'stdbool.h', and 'stddef.h', are 3619installed in 'LIBSUBDIR/include', unless the target Makefile fragment 3620(*note Target Fragment::) overrides this by setting 'USER_H'. 3621 3622 In addition to these headers and those generated by fixing system 3623headers to work with GCC, some other headers may also be installed in 3624'LIBSUBDIR/include'. 'config.gcc' may set 'extra_headers'; this 3625specifies additional headers under 'config' to be installed on some 3626systems. 3627 3628 GCC installs its own version of '<float.h>', from 'ginclude/float.h'. 3629This is done to cope with command-line options that change the 3630representation of floating point numbers. 3631 3632 GCC also installs its own version of '<limits.h>'; this is generated 3633from 'glimits.h', together with 'limitx.h' and 'limity.h' if the system 3634also has its own version of '<limits.h>'. (GCC provides its own header 3635because it is required of ISO C freestanding implementations, but needs 3636to include the system header from its own header as well because other 3637standards such as POSIX specify additional values to be defined in 3638'<limits.h>'.) The system's '<limits.h>' header is used via 3639'LIBSUBDIR/include/syslimits.h', which is copied from 'gsyslimits.h' if 3640it does not need fixing to work with GCC; if it needs fixing, 3641'syslimits.h' is the fixed copy. 3642 3643 GCC can also install '<tgmath.h>'. It will do this when 'config.gcc' 3644sets 'use_gcc_tgmath' to 'yes'. 3645 3646 3647File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory 3648 36496.3.7 Building Documentation 3650---------------------------- 3651 3652The main GCC documentation is in the form of manuals in Texinfo format. 3653These are installed in Info format; DVI versions may be generated by 3654'make dvi', PDF versions by 'make pdf', and HTML versions by 'make 3655html'. In addition, some man pages are generated from the Texinfo 3656manuals, there are some other text files with miscellaneous 3657documentation, and runtime libraries have their own documentation 3658outside the 'gcc' directory. FIXME: document the documentation for 3659runtime libraries somewhere. 3660 3661* Menu: 3662 3663* Texinfo Manuals:: GCC manuals in Texinfo format. 3664* Man Page Generation:: Generating man pages from Texinfo manuals. 3665* Miscellaneous Docs:: Miscellaneous text files with documentation. 3666 3667 3668File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation 3669 36706.3.7.1 Texinfo Manuals 3671....................... 3672 3673The manuals for GCC as a whole, and the C and C++ front ends, are in 3674files 'doc/*.texi'. Other front ends have their own manuals in files 3675'LANGUAGE/*.texi'. Common files 'doc/include/*.texi' are provided which 3676may be included in multiple manuals; the following files are in 3677'doc/include': 3678 3679'fdl.texi' 3680 The GNU Free Documentation License. 3681'funding.texi' 3682 The section "Funding Free Software". 3683'gcc-common.texi' 3684 Common definitions for manuals. 3685'gpl_v3.texi' 3686 The GNU General Public License. 3687'texinfo.tex' 3688 A copy of 'texinfo.tex' known to work with the GCC manuals. 3689 3690 DVI-formatted manuals are generated by 'make dvi', which uses 3691'texi2dvi' (via the Makefile macro '$(TEXI2DVI)'). PDF-formatted 3692manuals are generated by 'make pdf', which uses 'texi2pdf' (via the 3693Makefile macro '$(TEXI2PDF)'). HTML formatted manuals are generated by 3694'make html'. Info manuals are generated by 'make info' (which is run as 3695part of a bootstrap); this generates the manuals in the source 3696directory, using 'makeinfo' via the Makefile macro '$(MAKEINFO)', and 3697they are included in release distributions. 3698 3699 Manuals are also provided on the GCC web site, in both HTML and 3700PostScript forms. This is done via the script 3701'maintainer-scripts/update_web_docs_svn'. Each manual to be provided 3702online must be listed in the definition of 'MANUALS' in that file; a 3703file 'NAME.texi' must only appear once in the source tree, and the 3704output manual must have the same name as the source file. (However, 3705other Texinfo files, included in manuals but not themselves the root 3706files of manuals, may have names that appear more than once in the 3707source tree.) The manual file 'NAME.texi' should only include other 3708files in its own directory or in 'doc/include'. HTML manuals will be 3709generated by 'makeinfo --html', PostScript manuals by 'texi2dvi' and 3710'dvips', and PDF manuals by 'texi2pdf'. All Texinfo files that are 3711parts of manuals must be version-controlled, even if they are generated 3712files, for the generation of online manuals to work. 3713 3714 The installation manual, 'doc/install.texi', is also provided on the 3715GCC web site. The HTML version is generated by the script 3716'doc/install.texi2html'. 3717 3718 3719File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation 3720 37216.3.7.2 Man Page Generation 3722........................... 3723 3724Because of user demand, in addition to full Texinfo manuals, man pages 3725are provided which contain extracts from those manuals. These man pages 3726are generated from the Texinfo manuals using 'contrib/texi2pod.pl' and 3727'pod2man'. (The man page for 'g++', 'cp/g++.1', just contains a '.so' 3728reference to 'gcc.1', but all the other man pages are generated from 3729Texinfo manuals.) 3730 3731 Because many systems may not have the necessary tools installed to 3732generate the man pages, they are only generated if the 'configure' 3733script detects that recent enough tools are installed, and the Makefiles 3734allow generating man pages to fail without aborting the build. Man 3735pages are also included in release distributions. They are generated in 3736the source directory. 3737 3738 Magic comments in Texinfo files starting '@c man' control what parts of 3739a Texinfo file go into a man page. Only a subset of Texinfo is 3740supported by 'texi2pod.pl', and it may be necessary to add support for 3741more Texinfo features to this script when generating new man pages. To 3742improve the man page output, some special Texinfo macros are provided in 3743'doc/include/gcc-common.texi' which 'texi2pod.pl' understands: 3744 3745'@gcctabopt' 3746 Use in the form '@table @gcctabopt' for tables of options, where 3747 for printed output the effect of '@code' is better than that of 3748 '@option' but for man page output a different effect is wanted. 3749'@gccoptlist' 3750 Use for summary lists of options in manuals. 3751'@gol' 3752 Use at the end of each line inside '@gccoptlist'. This is 3753 necessary to avoid problems with differences in how the 3754 '@gccoptlist' macro is handled by different Texinfo formatters. 3755 3756 FIXME: describe the 'texi2pod.pl' input language and magic comments in 3757more detail. 3758 3759 3760File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation 3761 37626.3.7.3 Miscellaneous Documentation 3763................................... 3764 3765In addition to the formal documentation that is installed by GCC, there 3766are several other text files in the 'gcc' subdirectory with 3767miscellaneous documentation: 3768 3769'ABOUT-GCC-NLS' 3770 Notes on GCC's Native Language Support. FIXME: this should be part 3771 of this manual rather than a separate file. 3772'ABOUT-NLS' 3773 Notes on the Free Translation Project. 3774'COPYING' 3775'COPYING3' 3776 The GNU General Public License, Versions 2 and 3. 3777'COPYING.LIB' 3778'COPYING3.LIB' 3779 The GNU Lesser General Public License, Versions 2.1 and 3. 3780'*ChangeLog*' 3781'*/ChangeLog*' 3782 Change log files for various parts of GCC. 3783'LANGUAGES' 3784 Details of a few changes to the GCC front-end interface. FIXME: 3785 the information in this file should be part of general 3786 documentation of the front-end interface in this manual. 3787'ONEWS' 3788 Information about new features in old versions of GCC. (For recent 3789 versions, the information is on the GCC web site.) 3790'README.Portability' 3791 Information about portability issues when writing code in GCC. 3792 FIXME: why isn't this part of this manual or of the GCC Coding 3793 Conventions? 3794 3795 FIXME: document such files in subdirectories, at least 'config', 'c', 3796'cp', 'objc', 'testsuite'. 3797 3798 3799File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory 3800 38016.3.8 Anatomy of a Language Front End 3802------------------------------------- 3803 3804A front end for a language in GCC has the following parts: 3805 3806 * A directory 'LANGUAGE' under 'gcc' containing source files for that 3807 front end. *Note The Front End 'LANGUAGE' Directory: Front End 3808 Directory, for details. 3809 * A mention of the language in the list of supported languages in 3810 'gcc/doc/install.texi'. 3811 * A mention of the name under which the language's runtime library is 3812 recognized by '--enable-shared=PACKAGE' in the documentation of 3813 that option in 'gcc/doc/install.texi'. 3814 * A mention of any special prerequisites for building the front end 3815 in the documentation of prerequisites in 'gcc/doc/install.texi'. 3816 * Details of contributors to that front end in 3817 'gcc/doc/contrib.texi'. If the details are in that front end's own 3818 manual then there should be a link to that manual's list in 3819 'contrib.texi'. 3820 * Information about support for that language in 3821 'gcc/doc/frontends.texi'. 3822 * Information about standards for that language, and the front end's 3823 support for them, in 'gcc/doc/standards.texi'. This may be a link 3824 to such information in the front end's own manual. 3825 * Details of source file suffixes for that language and '-x LANG' 3826 options supported, in 'gcc/doc/invoke.texi'. 3827 * Entries in 'default_compilers' in 'gcc.c' for source file suffixes 3828 for that language. 3829 * Preferably testsuites, which may be under 'gcc/testsuite' or 3830 runtime library directories. FIXME: document somewhere how to 3831 write testsuite harnesses. 3832 * Probably a runtime library for the language, outside the 'gcc' 3833 directory. FIXME: document this further. 3834 * Details of the directories of any runtime libraries in 3835 'gcc/doc/sourcebuild.texi'. 3836 * Check targets in 'Makefile.def' for the top-level 'Makefile' to 3837 check just the compiler or the compiler and runtime library for the 3838 language. 3839 3840 If the front end is added to the official GCC source repository, the 3841following are also necessary: 3842 3843 * At least one Bugzilla component for bugs in that front end and 3844 runtime libraries. This category needs to be added to the Bugzilla 3845 database. 3846 * Normally, one or more maintainers of that front end listed in 3847 'MAINTAINERS'. 3848 * Mentions on the GCC web site in 'index.html' and 'frontends.html', 3849 with any relevant links on 'readings.html'. (Front ends that are 3850 not an official part of GCC may also be listed on 'frontends.html', 3851 with relevant links.) 3852 * A news item on 'index.html', and possibly an announcement on the 3853 <gcc-announce@gcc.gnu.org> mailing list. 3854 * The front end's manuals should be mentioned in 3855 'maintainer-scripts/update_web_docs_svn' (*note Texinfo Manuals::) 3856 and the online manuals should be linked to from 3857 'onlinedocs/index.html'. 3858 * Any old releases or CVS repositories of the front end, before its 3859 inclusion in GCC, should be made available on the GCC FTP site 3860 <ftp://gcc.gnu.org/pub/gcc/old-releases/>. 3861 * The release and snapshot script 'maintainer-scripts/gcc_release' 3862 should be updated to generate appropriate tarballs for this front 3863 end. 3864 * If this front end includes its own version files that include the 3865 current date, 'maintainer-scripts/update_version' should be updated 3866 accordingly. 3867 3868* Menu: 3869 3870* Front End Directory:: The front end 'LANGUAGE' directory. 3871* Front End Config:: The front end 'config-lang.in' file. 3872* Front End Makefile:: The front end 'Make-lang.in' file. 3873 3874 3875File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End 3876 38776.3.8.1 The Front End 'LANGUAGE' Directory 3878.......................................... 3879 3880A front end 'LANGUAGE' directory contains the source files of that front 3881end (but not of any runtime libraries, which should be outside the 'gcc' 3882directory). This includes documentation, and possibly some subsidiary 3883programs built alongside the front end. Certain files are special and 3884other parts of the compiler depend on their names: 3885 3886'config-lang.in' 3887 This file is required in all language subdirectories. *Note The 3888 Front End 'config-lang.in' File: Front End Config, for details of 3889 its contents 3890'Make-lang.in' 3891 This file is required in all language subdirectories. *Note The 3892 Front End 'Make-lang.in' File: Front End Makefile, for details of 3893 its contents. 3894'lang.opt' 3895 This file registers the set of switches that the front end accepts 3896 on the command line, and their '--help' text. *Note Options::. 3897'lang-specs.h' 3898 This file provides entries for 'default_compilers' in 'gcc.c' which 3899 override the default of giving an error that a compiler for that 3900 language is not installed. 3901'LANGUAGE-tree.def' 3902 This file, which need not exist, defines any language-specific tree 3903 codes. 3904 3905 3906File: gccint.info, Node: Front End Config, Next: Front End Makefile, Prev: Front End Directory, Up: Front End 3907 39086.3.8.2 The Front End 'config-lang.in' File 3909........................................... 3910 3911Each language subdirectory contains a 'config-lang.in' file. This file 3912is a shell script that may define some variables describing the 3913language: 3914 3915'language' 3916 This definition must be present, and gives the name of the language 3917 for some purposes such as arguments to '--enable-languages'. 3918'lang_requires' 3919 If defined, this variable lists (space-separated) language front 3920 ends other than C that this front end requires to be enabled (with 3921 the names given being their 'language' settings). For example, the 3922 Java front end depends on the C++ front end, so sets 3923 'lang_requires=c++'. 3924'subdir_requires' 3925 If defined, this variable lists (space-separated) front end 3926 directories other than C that this front end requires to be 3927 present. For example, the Objective-C++ front end uses source 3928 files from the C++ and Objective-C front ends, so sets 3929 'subdir_requires="cp objc"'. 3930'target_libs' 3931 If defined, this variable lists (space-separated) targets in the 3932 top level 'Makefile' to build the runtime libraries for this 3933 language, such as 'target-libobjc'. 3934'lang_dirs' 3935 If defined, this variable lists (space-separated) top level 3936 directories (parallel to 'gcc'), apart from the runtime libraries, 3937 that should not be configured if this front end is not built. 3938'build_by_default' 3939 If defined to 'no', this language front end is not built unless 3940 enabled in a '--enable-languages' argument. Otherwise, front ends 3941 are built by default, subject to any special logic in 3942 'configure.ac' (as is present to disable the Ada front end if the 3943 Ada compiler is not already installed). 3944'boot_language' 3945 If defined to 'yes', this front end is built in stage1 of the 3946 bootstrap. This is only relevant to front ends written in their 3947 own languages. 3948'compilers' 3949 If defined, a space-separated list of compiler executables that 3950 will be run by the driver. The names here will each end with 3951 '\$(exeext)'. 3952'outputs' 3953 If defined, a space-separated list of files that should be 3954 generated by 'configure' substituting values in them. This 3955 mechanism can be used to create a file 'LANGUAGE/Makefile' from 3956 'LANGUAGE/Makefile.in', but this is deprecated, building everything 3957 from the single 'gcc/Makefile' is preferred. 3958'gtfiles' 3959 If defined, a space-separated list of files that should be scanned 3960 by 'gengtype.c' to generate the garbage collection tables and 3961 routines for this language. This excludes the files that are 3962 common to all front ends. *Note Type Information::. 3963 3964 3965File: gccint.info, Node: Front End Makefile, Prev: Front End Config, Up: Front End 3966 39676.3.8.3 The Front End 'Make-lang.in' File 3968......................................... 3969 3970Each language subdirectory contains a 'Make-lang.in' file. It contains 3971targets 'LANG.HOOK' (where 'LANG' is the setting of 'language' in 3972'config-lang.in') for the following values of 'HOOK', and any other 3973Makefile rules required to build those targets (which may if necessary 3974use other Makefiles specified in 'outputs' in 'config-lang.in', although 3975this is deprecated). It also adds any testsuite targets that can use 3976the standard rule in 'gcc/Makefile.in' to the variable 'lang_checks'. 3977 3978'all.cross' 3979'start.encap' 3980'rest.encap' 3981 FIXME: exactly what goes in each of these targets? 3982'tags' 3983 Build an 'etags' 'TAGS' file in the language subdirectory in the 3984 source tree. 3985'info' 3986 Build info documentation for the front end, in the build directory. 3987 This target is only called by 'make bootstrap' if a suitable 3988 version of 'makeinfo' is available, so does not need to check for 3989 this, and should fail if an error occurs. 3990'dvi' 3991 Build DVI documentation for the front end, in the build directory. 3992 This should be done using '$(TEXI2DVI)', with appropriate '-I' 3993 arguments pointing to directories of included files. 3994'pdf' 3995 Build PDF documentation for the front end, in the build directory. 3996 This should be done using '$(TEXI2PDF)', with appropriate '-I' 3997 arguments pointing to directories of included files. 3998'html' 3999 Build HTML documentation for the front end, in the build directory. 4000'man' 4001 Build generated man pages for the front end from Texinfo manuals 4002 (*note Man Page Generation::), in the build directory. This target 4003 is only called if the necessary tools are available, but should 4004 ignore errors so as not to stop the build if errors occur; man 4005 pages are optional and the tools involved may be installed in a 4006 broken way. 4007'install-common' 4008 Install everything that is part of the front end, apart from the 4009 compiler executables listed in 'compilers' in 'config-lang.in'. 4010'install-info' 4011 Install info documentation for the front end, if it is present in 4012 the source directory. This target should have dependencies on info 4013 files that should be installed. 4014'install-man' 4015 Install man pages for the front end. This target should ignore 4016 errors. 4017'install-plugin' 4018 Install headers needed for plugins. 4019'srcextra' 4020 Copies its dependencies into the source directory. This generally 4021 should be used for generated files such as Bison output files which 4022 are not version-controlled, but should be included in any release 4023 tarballs. This target will be executed during a bootstrap if 4024 '--enable-generated-files-in-srcdir' was specified as a 'configure' 4025 option. 4026'srcinfo' 4027'srcman' 4028 Copies its dependencies into the source directory. These targets 4029 will be executed during a bootstrap if 4030 '--enable-generated-files-in-srcdir' was specified as a 'configure' 4031 option. 4032'uninstall' 4033 Uninstall files installed by installing the compiler. This is 4034 currently documented not to be supported, so the hook need not do 4035 anything. 4036'mostlyclean' 4037'clean' 4038'distclean' 4039'maintainer-clean' 4040 The language parts of the standard GNU '*clean' targets. *Note 4041 Standard Targets for Users: (standards)Standard Targets, for 4042 details of the standard targets. For GCC, 'maintainer-clean' 4043 should delete all generated files in the source directory that are 4044 not version-controlled, but should not delete anything that is. 4045 4046 'Make-lang.in' must also define a variable 'LANG_OBJS' to a list of 4047host object files that are used by that language. 4048 4049 4050File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory 4051 40526.3.9 Anatomy of a Target Back End 4053---------------------------------- 4054 4055A back end for a target architecture in GCC has the following parts: 4056 4057 * A directory 'MACHINE' under 'gcc/config', containing a machine 4058 description 'MACHINE.md' file (*note Machine Descriptions: Machine 4059 Desc.), header files 'MACHINE.h' and 'MACHINE-protos.h' and a 4060 source file 'MACHINE.c' (*note Target Description Macros and 4061 Functions: Target Macros.), possibly a target Makefile fragment 4062 't-MACHINE' (*note The Target Makefile Fragment: Target Fragment.), 4063 and maybe some other files. The names of these files may be 4064 changed from the defaults given by explicit specifications in 4065 'config.gcc'. 4066 * If necessary, a file 'MACHINE-modes.def' in the 'MACHINE' 4067 directory, containing additional machine modes to represent 4068 condition codes. *Note Condition Code::, for further details. 4069 * An optional 'MACHINE.opt' file in the 'MACHINE' directory, 4070 containing a list of target-specific options. You can also add 4071 other option files using the 'extra_options' variable in 4072 'config.gcc'. *Note Options::. 4073 * Entries in 'config.gcc' (*note The 'config.gcc' File: System 4074 Config.) for the systems with this target architecture. 4075 * Documentation in 'gcc/doc/invoke.texi' for any command-line options 4076 supported by this target (*note Run-time Target Specification: 4077 Run-time Target.). This means both entries in the summary table of 4078 options and details of the individual options. 4079 * Documentation in 'gcc/doc/extend.texi' for any target-specific 4080 attributes supported (*note Defining target-specific uses of 4081 '__attribute__': Target Attributes.), including where the same 4082 attribute is already supported on some targets, which are 4083 enumerated in the manual. 4084 * Documentation in 'gcc/doc/extend.texi' for any target-specific 4085 pragmas supported. 4086 * Documentation in 'gcc/doc/extend.texi' of any target-specific 4087 built-in functions supported. 4088 * Documentation in 'gcc/doc/extend.texi' of any target-specific 4089 format checking styles supported. 4090 * Documentation in 'gcc/doc/md.texi' of any target-specific 4091 constraint letters (*note Constraints for Particular Machines: 4092 Machine Constraints.). 4093 * A note in 'gcc/doc/contrib.texi' under the person or people who 4094 contributed the target support. 4095 * Entries in 'gcc/doc/install.texi' for all target triplets supported 4096 with this target architecture, giving details of any special notes 4097 about installation for this target, or saying that there are no 4098 special notes if there are none. 4099 * Possibly other support outside the 'gcc' directory for runtime 4100 libraries. FIXME: reference docs for this. The 'libstdc++' 4101 porting manual needs to be installed as info for this to work, or 4102 to be a chapter of this manual. 4103 4104 If the back end is added to the official GCC source repository, the 4105following are also necessary: 4106 4107 * An entry for the target architecture in 'readings.html' on the GCC 4108 web site, with any relevant links. 4109 * Details of the properties of the back end and target architecture 4110 in 'backends.html' on the GCC web site. 4111 * A news item about the contribution of support for that target 4112 architecture, in 'index.html' on the GCC web site. 4113 * Normally, one or more maintainers of that target listed in 4114 'MAINTAINERS'. Some existing architectures may be unmaintained, 4115 but it would be unusual to add support for a target that does not 4116 have a maintainer when support is added. 4117 * Target triplets covering all 'config.gcc' stanzas for the target, 4118 in the list in 'contrib/config-list.mk'. 4119 4120 4121File: gccint.info, Node: Testsuites, Next: Options, Prev: Source Tree, Up: Top 4122 41237 Testsuites 4124************ 4125 4126GCC contains several testsuites to help maintain compiler quality. Most 4127of the runtime libraries and language front ends in GCC have testsuites. 4128Currently only the C language testsuites are documented here; FIXME: 4129document the others. 4130 4131* Menu: 4132 4133* Test Idioms:: Idioms used in testsuite code. 4134* Test Directives:: Directives used within DejaGnu tests. 4135* Ada Tests:: The Ada language testsuites. 4136* C Tests:: The C language testsuites. 4137* libgcj Tests:: The Java library testsuites. 4138* LTO Testing:: Support for testing link-time optimizations. 4139* gcov Testing:: Support for testing gcov. 4140* profopt Testing:: Support for testing profile-directed optimizations. 4141* compat Testing:: Support for testing binary compatibility. 4142* Torture Tests:: Support for torture testing using multiple options. 4143 4144 4145File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites 4146 41477.1 Idioms Used in Testsuite Code 4148================================= 4149 4150In general, C testcases have a trailing '-N.c', starting with '-1.c', in 4151case other testcases with similar names are added later. If the test is 4152a test of some well-defined feature, it should have a name referring to 4153that feature such as 'FEATURE-1.c'. If it does not test a well-defined 4154feature but just happens to exercise a bug somewhere in the compiler, 4155and a bug report has been filed for this bug in the GCC bug database, 4156'prBUG-NUMBER-1.c' is the appropriate form of name. Otherwise (for 4157miscellaneous bugs not filed in the GCC bug database), and previously 4158more generally, test cases are named after the date on which they were 4159added. This allows people to tell at a glance whether a test failure is 4160because of a recently found bug that has not yet been fixed, or whether 4161it may be a regression, but does not give any other information about 4162the bug or where discussion of it may be found. Some other language 4163testsuites follow similar conventions. 4164 4165 In the 'gcc.dg' testsuite, it is often necessary to test that an error 4166is indeed a hard error and not just a warning--for example, where it is 4167a constraint violation in the C standard, which must become an error 4168with '-pedantic-errors'. The following idiom, where the first line 4169shown is line LINE of the file and the line that generates the error, is 4170used for this: 4171 4172 /* { dg-bogus "warning" "warning in place of error" } */ 4173 /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */ 4174 4175 It may be necessary to check that an expression is an integer constant 4176expression and has a certain value. To check that 'E' has value 'V', an 4177idiom similar to the following is used: 4178 4179 char x[((E) == (V) ? 1 : -1)]; 4180 4181 In 'gcc.dg' tests, '__typeof__' is sometimes used to make assertions 4182about the types of expressions. See, for example, 4183'gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact 4184rules for the types of conditional expressions in the C standard; see, 4185for example, 'gcc.dg/c99-intconst-1.c'. 4186 4187 It is useful to be able to test that optimizations are being made 4188properly. This cannot be done in all cases, but it can be done where 4189the optimization will lead to code being optimized away (for example, 4190where flow analysis or alias analysis should show that certain code 4191cannot be called) or to functions not being called because they have 4192been expanded as built-in functions. Such tests go in 4193'gcc.c-torture/execute'. Where code should be optimized away, a call to 4194a nonexistent function such as 'link_failure ()' may be inserted; a 4195definition 4196 4197 #ifndef __OPTIMIZE__ 4198 void 4199 link_failure (void) 4200 { 4201 abort (); 4202 } 4203 #endif 4204 4205will also be needed so that linking still succeeds when the test is run 4206without optimization. When all calls to a built-in function should have 4207been optimized and no calls to the non-built-in version of the function 4208should remain, that function may be defined as 'static' to call 'abort 4209()' (although redeclaring a function as static may not work on all 4210targets). 4211 4212 All testcases must be portable. Target-specific testcases must have 4213appropriate code to avoid causing failures on unsupported systems; 4214unfortunately, the mechanisms for this differ by directory. 4215 4216 FIXME: discuss non-C testsuites here. 4217 4218 4219File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites 4220 42217.2 Directives used within DejaGnu tests 4222======================================== 4223 4224* Menu: 4225 4226* Directives:: Syntax and descriptions of test directives. 4227* Selectors:: Selecting targets to which a test applies. 4228* Effective-Target Keywords:: Keywords describing target attributes. 4229* Add Options:: Features for 'dg-add-options' 4230* Require Support:: Variants of 'dg-require-SUPPORT' 4231* Final Actions:: Commands for use in 'dg-final' 4232 4233 4234File: gccint.info, Node: Directives, Next: Selectors, Up: Test Directives 4235 42367.2.1 Syntax and Descriptions of test directives 4237------------------------------------------------ 4238 4239Test directives appear within comments in a test source file and begin 4240with 'dg-'. Some of these are defined within DejaGnu and others are 4241local to the GCC testsuite. 4242 4243 The order in which test directives appear in a test can be important: 4244directives local to GCC sometimes override information used by the 4245DejaGnu directives, which know nothing about the GCC directives, so the 4246DejaGnu directives must precede GCC directives. 4247 4248 Several test directives include selectors (*note Selectors::) which are 4249usually preceded by the keyword 'target' or 'xfail'. 4250 42517.2.1.1 Specify how to build the test 4252..................................... 4253 4254'{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }' 4255 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 4256 is executed. It is one of: 4257 4258 'preprocess' 4259 Compile with '-E' to run only the preprocessor. 4260 'compile' 4261 Compile with '-S' to produce an assembly code file. 4262 'assemble' 4263 Compile with '-c' to produce a relocatable object file. 4264 'link' 4265 Compile, assemble, and link to produce an executable file. 4266 'run' 4267 Produce and run an executable file, which is expected to 4268 return an exit code of 0. 4269 4270 The default is 'compile'. That can be overridden for a set of 4271 tests by redefining 'dg-do-what-default' within the '.exp' file for 4272 those tests. 4273 4274 If the directive includes the optional '{ target SELECTOR }' then 4275 the test is skipped unless the target system matches the SELECTOR. 4276 4277 If DO-WHAT-KEYWORD is 'run' and the directive includes the optional 4278 '{ xfail SELECTOR }' and the selector is met then the test is 4279 expected to fail. The 'xfail' clause is ignored for other values 4280 of DO-WHAT-KEYWORD; those tests can use directive 'dg-xfail-if'. 4281 42827.2.1.2 Specify additional compiler options 4283........................................... 4284 4285'{ dg-options OPTIONS [{ target SELECTOR }] }' 4286 This DejaGnu directive provides a list of compiler options, to be 4287 used if the target system matches SELECTOR, that replace the 4288 default options used for this set of tests. 4289 4290'{ dg-add-options FEATURE ... }' 4291 Add any compiler options that are needed to access certain 4292 features. This directive does nothing on targets that enable the 4293 features by default, or that don't provide them at all. It must 4294 come after all 'dg-options' directives. For supported values of 4295 FEATURE see *note Add Options::. 4296 4297'{ dg-additional-options OPTIONS [{ target SELECTOR }] }' 4298 This directive provides a list of compiler options, to be used if 4299 the target system matches SELECTOR, that are added to the default 4300 options used for this set of tests. 4301 43027.2.1.3 Modify the test timeout value 4303..................................... 4304 4305The normal timeout limit, in seconds, is found by searching the 4306following in order: 4307 4308 * the value defined by an earlier 'dg-timeout' directive in the test 4309 4310 * variable TOOL_TIMEOUT defined by the set of tests 4311 4312 * GCC,TIMEOUT set in the target board 4313 4314 * 300 4315 4316'{ dg-timeout N [{target SELECTOR }] }' 4317 Set the time limit for the compilation and for the execution of the 4318 test to the specified number of seconds. 4319 4320'{ dg-timeout-factor X [{ target SELECTOR }] }' 4321 Multiply the normal time limit for compilation and execution of the 4322 test by the specified floating-point factor. 4323 43247.2.1.4 Skip a test for some targets 4325.................................... 4326 4327'{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4328 Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each 4329 element is a string of zero or more GCC options. Skip the test if 4330 all of the following conditions are met: 4331 * the test system is included in SELECTOR 4332 4333 * for at least one of the option strings in INCLUDE-OPTS, every 4334 option from that string is in the set of options with which 4335 the test would be compiled; use '"*"' for an INCLUDE-OPTS list 4336 that matches any options; that is the default if INCLUDE-OPTS 4337 is not specified 4338 4339 * for each of the option strings in EXCLUDE-OPTS, at least one 4340 option from that string is not in the set of options with 4341 which the test would be compiled; use '""' for an empty 4342 EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not 4343 specified 4344 4345 For example, to skip a test if option '-Os' is present: 4346 4347 /* { dg-skip-if "" { *-*-* } { "-Os" } { "" } } */ 4348 4349 To skip a test if both options '-O2' and '-g' are present: 4350 4351 /* { dg-skip-if "" { *-*-* } { "-O2 -g" } { "" } } */ 4352 4353 To skip a test if either '-O2' or '-O3' is present: 4354 4355 /* { dg-skip-if "" { *-*-* } { "-O2" "-O3" } { "" } } */ 4356 4357 To skip a test unless option '-Os' is present: 4358 4359 /* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */ 4360 4361 To skip a test if either '-O2' or '-O3' is used with '-g' but not 4362 if '-fpic' is also present: 4363 4364 /* { dg-skip-if "" { *-*-* } { "-O2 -g" "-O3 -g" } { "-fpic" } } */ 4365 4366'{ dg-require-effective-target KEYWORD [{ SELECTOR }] }' 4367 Skip the test if the test target, including current multilib flags, 4368 is not covered by the effective-target keyword. If the directive 4369 includes the optional '{ SELECTOR }' then the effective-target test 4370 is only performed if the target system matches the SELECTOR. This 4371 directive must appear after any 'dg-do' directive in the test and 4372 before any 'dg-additional-sources' directive. *Note 4373 Effective-Target Keywords::. 4374 4375'{ dg-require-SUPPORT args }' 4376 Skip the test if the target does not provide the required support. 4377 These directives must appear after any 'dg-do' directive in the 4378 test and before any 'dg-additional-sources' directive. They 4379 require at least one argument, which can be an empty string if the 4380 specific procedure does not examine the argument. *Note Require 4381 Support::, for a complete list of these directives. 4382 43837.2.1.5 Expect a test to fail for some targets 4384.............................................. 4385 4386'{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4387 Expect the test to fail if the conditions (which are the same as 4388 for 'dg-skip-if') are met. This does not affect the execute step. 4389 4390'{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4391 Expect the execute step of a test to fail if the conditions (which 4392 are the same as for 'dg-skip-if') are met. 4393 43947.2.1.6 Expect the test executable to fail 4395.......................................... 4396 4397'{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }' 4398 Expect the test executable to return a nonzero exit status if the 4399 conditions (which are the same as for 'dg-skip-if') are met. 4400 44017.2.1.7 Verify compiler messages 4402................................ 4403 4404'{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4405 This DejaGnu directive appears on a source line that is expected to 4406 get an error message, or else specifies the source line associated 4407 with the message. If there is no message for that line or if the 4408 text of that message is not matched by REGEXP then the check fails 4409 and COMMENT is included in the 'FAIL' message. The check does not 4410 look for the string 'error' unless it is part of REGEXP. 4411 4412'{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4413 This DejaGnu directive appears on a source line that is expected to 4414 get a warning message, or else specifies the source line associated 4415 with the message. If there is no message for that line or if the 4416 text of that message is not matched by REGEXP then the check fails 4417 and COMMENT is included in the 'FAIL' message. The check does not 4418 look for the string 'warning' unless it is part of REGEXP. 4419 4420'{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4421 The line is expected to get a message other than an error or 4422 warning. If there is no message for that line or if the text of 4423 that message is not matched by REGEXP then the check fails and 4424 COMMENT is included in the 'FAIL' message. 4425 4426'{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4427 This DejaGnu directive appears on a source line that should not get 4428 a message matching REGEXP, or else specifies the source line 4429 associated with the bogus message. It is usually used with 'xfail' 4430 to indicate that the message is a known problem for a particular 4431 set of targets. 4432 4433'{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }' 4434 This DejaGnu directive indicates that the test is expected to fail 4435 due to compiler messages that are not handled by 'dg-error', 4436 'dg-warning' or 'dg-bogus'. For this directive 'xfail' has the 4437 same effect as 'target'. 4438 4439'{ dg-prune-output REGEXP }' 4440 Prune messages matching REGEXP from the test output. 4441 44427.2.1.8 Verify output of the test executable 4443............................................ 4444 4445'{ dg-output REGEXP [{ target/xfail SELECTOR }] }' 4446 This DejaGnu directive compares REGEXP to the combined output that 4447 the test executable writes to 'stdout' and 'stderr'. 4448 44497.2.1.9 Specify additional files for a test 4450........................................... 4451 4452'{ dg-additional-files "FILELIST" }' 4453 Specify additional files, other than source files, that must be 4454 copied to the system where the compiler runs. 4455 4456'{ dg-additional-sources "FILELIST" }' 4457 Specify additional source files to appear in the compile line 4458 following the main test file. 4459 44607.2.1.10 Add checks at the end of a test 4461........................................ 4462 4463'{ dg-final { LOCAL-DIRECTIVE } }' 4464 This DejaGnu directive is placed within a comment anywhere in the 4465 source file and is processed after the test has been compiled and 4466 run. Multiple 'dg-final' commands are processed in the order in 4467 which they appear in the source file. *Note Final Actions::, for a 4468 list of directives that can be used within 'dg-final'. 4469 4470 4471File: gccint.info, Node: Selectors, Next: Effective-Target Keywords, Prev: Directives, Up: Test Directives 4472 44737.2.2 Selecting targets to which a test applies 4474----------------------------------------------- 4475 4476Several test directives include SELECTORs to limit the targets for which 4477a test is run or to declare that a test is expected to fail on 4478particular targets. 4479 4480 A selector is: 4481 * one or more target triplets, possibly including wildcard 4482 characters; use '*-*-*' to match any target 4483 * a single effective-target keyword (*note Effective-Target 4484 Keywords::) 4485 * a logical expression 4486 4487 Depending on the context, the selector specifies whether a test is 4488skipped and reported as unsupported or is expected to fail. A context 4489that allows either 'target' or 'xfail' also allows '{ target SELECTOR1 4490xfail SELECTOR2 }' to skip the test for targets that don't match 4491SELECTOR1 and the test to fail for targets that match SELECTOR2. 4492 4493 A selector expression appears within curly braces and uses a single 4494logical operator: one of '!', '&&', or '||'. An operand is another 4495selector expression, an effective-target keyword, a single target 4496triplet, or a list of target triplets within quotes or curly braces. 4497For example: 4498 4499 { target { ! "hppa*-*-* ia64*-*-*" } } 4500 { target { powerpc*-*-* && lp64 } } 4501 { xfail { lp64 || vect_no_align } } 4502 4503 4504File: gccint.info, Node: Effective-Target Keywords, Next: Add Options, Prev: Selectors, Up: Test Directives 4505 45067.2.3 Keywords describing target attributes 4507------------------------------------------- 4508 4509Effective-target keywords identify sets of targets that support 4510particular functionality. They are used to limit tests to be run only 4511for particular targets, or to specify that particular sets of targets 4512are expected to fail some tests. 4513 4514 Effective-target keywords are defined in 'lib/target-supports.exp' in 4515the GCC testsuite, with the exception of those that are documented as 4516being local to a particular test directory. 4517 4518 The 'effective target' takes into account all of the compiler options 4519with which the test will be compiled, including the multilib options. 4520By convention, keywords ending in '_nocache' can also include options 4521specified for the particular test in an earlier 'dg-options' or 4522'dg-add-options' directive. 4523 45247.2.3.1 Data type sizes 4525....................... 4526 4527'ilp32' 4528 Target has 32-bit 'int', 'long', and pointers. 4529 4530'lp64' 4531 Target has 32-bit 'int', 64-bit 'long' and pointers. 4532 4533'llp64' 4534 Target has 32-bit 'int' and 'long', 64-bit 'long long' and 4535 pointers. 4536 4537'double64' 4538 Target has 64-bit 'double'. 4539 4540'double64plus' 4541 Target has 'double' that is 64 bits or longer. 4542 4543'longdouble128' 4544 Target has 128-bit 'long double'. 4545 4546'int32plus' 4547 Target has 'int' that is at 32 bits or longer. 4548 4549'int16' 4550 Target has 'int' that is 16 bits or shorter. 4551 4552'long_neq_int' 4553 Target has 'int' and 'long' with different sizes. 4554 4555'large_double' 4556 Target supports 'double' that is longer than 'float'. 4557 4558'large_long_double' 4559 Target supports 'long double' that is longer than 'double'. 4560 4561'ptr32plus' 4562 Target has pointers that are 32 bits or longer. 4563 4564'size32plus' 4565 Target supports array and structure sizes that are 32 bits or 4566 longer. 4567 4568'4byte_wchar_t' 4569 Target has 'wchar_t' that is at least 4 bytes. 4570 45717.2.3.2 Fortran-specific attributes 4572................................... 4573 4574'fortran_integer_16' 4575 Target supports Fortran 'integer' that is 16 bytes or longer. 4576 4577'fortran_large_int' 4578 Target supports Fortran 'integer' kinds larger than 'integer(8)'. 4579 4580'fortran_large_real' 4581 Target supports Fortran 'real' kinds larger than 'real(8)'. 4582 45837.2.3.3 Vector-specific attributes 4584.................................. 4585 4586'vect_condition' 4587 Target supports vector conditional operations. 4588 4589'vect_double' 4590 Target supports hardware vectors of 'double'. 4591 4592'vect_float' 4593 Target supports hardware vectors of 'float'. 4594 4595'vect_int' 4596 Target supports hardware vectors of 'int'. 4597 4598'vect_long' 4599 Target supports hardware vectors of 'long'. 4600 4601'vect_long_long' 4602 Target supports hardware vectors of 'long long'. 4603 4604'vect_aligned_arrays' 4605 Target aligns arrays to vector alignment boundary. 4606 4607'vect_hw_misalign' 4608 Target supports a vector misalign access. 4609 4610'vect_no_align' 4611 Target does not support a vector alignment mechanism. 4612 4613'vect_no_int_max' 4614 Target does not support a vector max instruction on 'int'. 4615 4616'vect_no_int_add' 4617 Target does not support a vector add instruction on 'int'. 4618 4619'vect_no_bitwise' 4620 Target does not support vector bitwise instructions. 4621 4622'vect_char_mult' 4623 Target supports 'vector char' multiplication. 4624 4625'vect_short_mult' 4626 Target supports 'vector short' multiplication. 4627 4628'vect_int_mult' 4629 Target supports 'vector int' multiplication. 4630 4631'vect_extract_even_odd' 4632 Target supports vector even/odd element extraction. 4633 4634'vect_extract_even_odd_wide' 4635 Target supports vector even/odd element extraction of vectors with 4636 elements 'SImode' or larger. 4637 4638'vect_interleave' 4639 Target supports vector interleaving. 4640 4641'vect_strided' 4642 Target supports vector interleaving and extract even/odd. 4643 4644'vect_strided_wide' 4645 Target supports vector interleaving and extract even/odd for wide 4646 element types. 4647 4648'vect_perm' 4649 Target supports vector permutation. 4650 4651'vect_shift' 4652 Target supports a hardware vector shift operation. 4653 4654'vect_widen_sum_hi_to_si' 4655 Target supports a vector widening summation of 'short' operands 4656 into 'int' results, or can promote (unpack) from 'short' to 'int'. 4657 4658'vect_widen_sum_qi_to_hi' 4659 Target supports a vector widening summation of 'char' operands into 4660 'short' results, or can promote (unpack) from 'char' to 'short'. 4661 4662'vect_widen_sum_qi_to_si' 4663 Target supports a vector widening summation of 'char' operands into 4664 'int' results. 4665 4666'vect_widen_mult_qi_to_hi' 4667 Target supports a vector widening multiplication of 'char' operands 4668 into 'short' results, or can promote (unpack) from 'char' to 4669 'short' and perform non-widening multiplication of 'short'. 4670 4671'vect_widen_mult_hi_to_si' 4672 Target supports a vector widening multiplication of 'short' 4673 operands into 'int' results, or can promote (unpack) from 'short' 4674 to 'int' and perform non-widening multiplication of 'int'. 4675 4676'vect_widen_mult_si_to_di_pattern' 4677 Target supports a vector widening multiplication of 'int' operands 4678 into 'long' results. 4679 4680'vect_sdot_qi' 4681 Target supports a vector dot-product of 'signed char'. 4682 4683'vect_udot_qi' 4684 Target supports a vector dot-product of 'unsigned char'. 4685 4686'vect_sdot_hi' 4687 Target supports a vector dot-product of 'signed short'. 4688 4689'vect_udot_hi' 4690 Target supports a vector dot-product of 'unsigned short'. 4691 4692'vect_pack_trunc' 4693 Target supports a vector demotion (packing) of 'short' to 'char' 4694 and from 'int' to 'short' using modulo arithmetic. 4695 4696'vect_unpack' 4697 Target supports a vector promotion (unpacking) of 'char' to 'short' 4698 and from 'char' to 'int'. 4699 4700'vect_intfloat_cvt' 4701 Target supports conversion from 'signed int' to 'float'. 4702 4703'vect_uintfloat_cvt' 4704 Target supports conversion from 'unsigned int' to 'float'. 4705 4706'vect_floatint_cvt' 4707 Target supports conversion from 'float' to 'signed int'. 4708 4709'vect_floatuint_cvt' 4710 Target supports conversion from 'float' to 'unsigned int'. 4711 47127.2.3.4 Thread Local Storage attributes 4713....................................... 4714 4715'tls' 4716 Target supports thread-local storage. 4717 4718'tls_native' 4719 Target supports native (rather than emulated) thread-local storage. 4720 4721'tls_runtime' 4722 Test system supports executing TLS executables. 4723 47247.2.3.5 Decimal floating point attributes 4725......................................... 4726 4727'dfp' 4728 Targets supports compiling decimal floating point extension to C. 4729 4730'dfp_nocache' 4731 Including the options used to compile this particular test, the 4732 target supports compiling decimal floating point extension to C. 4733 4734'dfprt' 4735 Test system can execute decimal floating point tests. 4736 4737'dfprt_nocache' 4738 Including the options used to compile this particular test, the 4739 test system can execute decimal floating point tests. 4740 4741'hard_dfp' 4742 Target generates decimal floating point instructions with current 4743 options. 4744 47457.2.3.6 ARM-specific attributes 4746............................... 4747 4748'arm32' 4749 ARM target generates 32-bit code. 4750 4751'arm_eabi' 4752 ARM target adheres to the ABI for the ARM Architecture. 4753 4754'arm_hf_eabi' 4755 ARM target adheres to the VFP and Advanced SIMD Register Arguments 4756 variant of the ABI for the ARM Architecture (as selected with 4757 '-mfloat-abi=hard'). 4758 4759'arm_hard_vfp_ok' 4760 ARM target supports '-mfpu=vfp -mfloat-abi=hard'. Some multilibs 4761 may be incompatible with these options. 4762 4763'arm_iwmmxt_ok' 4764 ARM target supports '-mcpu=iwmmxt'. Some multilibs may be 4765 incompatible with this option. 4766 4767'arm_neon' 4768 ARM target supports generating NEON instructions. 4769 4770'arm_tune_string_ops_prefer_neon' 4771 Test CPU tune supports inlining string operations with NEON 4772 instructions. 4773 4774'arm_neon_hw' 4775 Test system supports executing NEON instructions. 4776 4777'arm_neonv2_hw' 4778 Test system supports executing NEON v2 instructions. 4779 4780'arm_neon_ok' 4781 ARM Target supports '-mfpu=neon -mfloat-abi=softfp' or compatible 4782 options. Some multilibs may be incompatible with these options. 4783 4784'arm_neonv2_ok' 4785 ARM Target supports '-mfpu=neon-vfpv4 -mfloat-abi=softfp' or 4786 compatible options. Some multilibs may be incompatible with these 4787 options. 4788 4789'arm_neon_fp16_ok' 4790 ARM Target supports '-mfpu=neon-fp16 -mfloat-abi=softfp' or 4791 compatible options. Some multilibs may be incompatible with these 4792 options. 4793 4794'arm_thumb1_ok' 4795 ARM target generates Thumb-1 code for '-mthumb'. 4796 4797'arm_thumb2_ok' 4798 ARM target generates Thumb-2 code for '-mthumb'. 4799 4800'arm_vfp_ok' 4801 ARM target supports '-mfpu=vfp -mfloat-abi=softfp'. Some multilibs 4802 may be incompatible with these options. 4803 4804'arm_vfp3_ok' 4805 ARM target supports '-mfpu=vfp3 -mfloat-abi=softfp'. Some 4806 multilibs may be incompatible with these options. 4807 4808'arm_v8_vfp_ok' 4809 ARM target supports '-mfpu=fp-armv8 -mfloat-abi=softfp'. Some 4810 multilibs may be incompatible with these options. 4811 4812'arm_v8_neon_ok' 4813 ARM target supports '-mfpu=neon-fp-armv8 -mfloat-abi=softfp'. Some 4814 multilibs may be incompatible with these options. 4815 4816'arm_prefer_ldrd_strd' 4817 ARM target prefers 'LDRD' and 'STRD' instructions over 'LDM' and 4818 'STM' instructions. 4819 48207.2.3.7 MIPS-specific attributes 4821................................ 4822 4823'mips64' 4824 MIPS target supports 64-bit instructions. 4825 4826'nomips16' 4827 MIPS target does not produce MIPS16 code. 4828 4829'mips16_attribute' 4830 MIPS target can generate MIPS16 code. 4831 4832'mips_loongson' 4833 MIPS target is a Loongson-2E or -2F target using an ABI that 4834 supports the Loongson vector modes. 4835 4836'mips_newabi_large_long_double' 4837 MIPS target supports 'long double' larger than 'double' when using 4838 the new ABI. 4839 4840'mpaired_single' 4841 MIPS target supports '-mpaired-single'. 4842 48437.2.3.8 PowerPC-specific attributes 4844................................... 4845 4846'dfp_hw' 4847 PowerPC target supports executing hardware DFP instructions. 4848 4849'p8vector_hw' 4850 PowerPC target supports executing VSX instructions (ISA 2.07). 4851 4852'powerpc64' 4853 Test system supports executing 64-bit instructions. 4854 4855'powerpc_altivec' 4856 PowerPC target supports AltiVec. 4857 4858'powerpc_altivec_ok' 4859 PowerPC target supports '-maltivec'. 4860 4861'powerpc_eabi_ok' 4862 PowerPC target supports '-meabi'. 4863 4864'powerpc_elfv2' 4865 PowerPC target supports '-mabi=elfv2'. 4866 4867'powerpc_fprs' 4868 PowerPC target supports floating-point registers. 4869 4870'powerpc_hard_double' 4871 PowerPC target supports hardware double-precision floating-point. 4872 4873'powerpc_htm_ok' 4874 PowerPC target supports '-mhtm' 4875 4876'powerpc_p8vector_ok' 4877 PowerPC target supports '-mpower8-vector' 4878 4879'powerpc_ppu_ok' 4880 PowerPC target supports '-mcpu=cell'. 4881 4882'powerpc_spe' 4883 PowerPC target supports PowerPC SPE. 4884 4885'powerpc_spe_nocache' 4886 Including the options used to compile this particular test, the 4887 PowerPC target supports PowerPC SPE. 4888 4889'powerpc_spu' 4890 PowerPC target supports PowerPC SPU. 4891 4892'powerpc_vsx_ok' 4893 PowerPC target supports '-mvsx'. 4894 4895'powerpc_405_nocache' 4896 Including the options used to compile this particular test, the 4897 PowerPC target supports PowerPC 405. 4898 4899'ppc_recip_hw' 4900 PowerPC target supports executing reciprocal estimate instructions. 4901 4902'spu_auto_overlay' 4903 SPU target has toolchain that supports automatic overlay 4904 generation. 4905 4906'vmx_hw' 4907 PowerPC target supports executing AltiVec instructions. 4908 4909'vsx_hw' 4910 PowerPC target supports executing VSX instructions (ISA 2.06). 4911 49127.2.3.9 Other hardware attributes 4913................................. 4914 4915'avx' 4916 Target supports compiling 'avx' instructions. 4917 4918'avx_runtime' 4919 Target supports the execution of 'avx' instructions. 4920 4921'cell_hw' 4922 Test system can execute AltiVec and Cell PPU instructions. 4923 4924'coldfire_fpu' 4925 Target uses a ColdFire FPU. 4926 4927'hard_float' 4928 Target supports FPU instructions. 4929 4930'non_strict_align' 4931 Target does not require strict alignment. 4932 4933'sse' 4934 Target supports compiling 'sse' instructions. 4935 4936'sse_runtime' 4937 Target supports the execution of 'sse' instructions. 4938 4939'sse2' 4940 Target supports compiling 'sse2' instructions. 4941 4942'sse2_runtime' 4943 Target supports the execution of 'sse2' instructions. 4944 4945'sync_char_short' 4946 Target supports atomic operations on 'char' and 'short'. 4947 4948'sync_int_long' 4949 Target supports atomic operations on 'int' and 'long'. 4950 4951'ultrasparc_hw' 4952 Test environment appears to run executables on a simulator that 4953 accepts only 'EM_SPARC' executables and chokes on 'EM_SPARC32PLUS' 4954 or 'EM_SPARCV9' executables. 4955 4956'vect_cmdline_needed' 4957 Target requires a command line argument to enable a SIMD 4958 instruction set. 4959 4960'pie_copyreloc' 4961 The x86-64 target linker supports PIE with copy reloc. 4962 49637.2.3.10 Environment attributes 4964............................... 4965 4966'c' 4967 The language for the compiler under test is C. 4968 4969'c++' 4970 The language for the compiler under test is C++. 4971 4972'c99_runtime' 4973 Target provides a full C99 runtime. 4974 4975'correct_iso_cpp_string_wchar_protos' 4976 Target 'string.h' and 'wchar.h' headers provide C++ required 4977 overloads for 'strchr' etc. functions. 4978 4979'dummy_wcsftime' 4980 Target uses a dummy 'wcsftime' function that always returns zero. 4981 4982'fd_truncate' 4983 Target can truncate a file from a file descriptor, as used by 4984 'libgfortran/io/unix.c:fd_truncate'; i.e. 'ftruncate' or 'chsize'. 4985 4986'freestanding' 4987 Target is 'freestanding' as defined in section 4 of the C99 4988 standard. Effectively, it is a target which supports no extra 4989 headers or libraries other than what is considered essential. 4990 4991'init_priority' 4992 Target supports constructors with initialization priority 4993 arguments. 4994 4995'inttypes_types' 4996 Target has the basic signed and unsigned types in 'inttypes.h'. 4997 This is for tests that GCC's notions of these types agree with 4998 those in the header, as some systems have only 'inttypes.h'. 4999 5000'lax_strtofp' 5001 Target might have errors of a few ULP in string to floating-point 5002 conversion functions and overflow is not always detected correctly 5003 by those functions. 5004 5005'mempcpy' 5006 Target provides 'mempcpy' function. 5007 5008'mmap' 5009 Target supports 'mmap'. 5010 5011'newlib' 5012 Target supports Newlib. 5013 5014'pow10' 5015 Target provides 'pow10' function. 5016 5017'pthread' 5018 Target can compile using 'pthread.h' with no errors or warnings. 5019 5020'pthread_h' 5021 Target has 'pthread.h'. 5022 5023'run_expensive_tests' 5024 Expensive testcases (usually those that consume excessive amounts 5025 of CPU time) should be run on this target. This can be enabled by 5026 setting the 'GCC_TEST_RUN_EXPENSIVE' environment variable to a 5027 non-empty string. 5028 5029'simulator' 5030 Test system runs executables on a simulator (i.e. slowly) rather 5031 than hardware (i.e. fast). 5032 5033'stabs' 5034 Target supports the stabs debugging format. 5035 5036'stdint_types' 5037 Target has the basic signed and unsigned C types in 'stdint.h'. 5038 This will be obsolete when GCC ensures a working 'stdint.h' for all 5039 targets. 5040 5041'stpcpy' 5042 Target provides 'stpcpy' function. 5043 5044'trampolines' 5045 Target supports trampolines. 5046 5047'uclibc' 5048 Target supports uClibc. 5049 5050'unwrapped' 5051 Target does not use a status wrapper. 5052 5053'vxworks_kernel' 5054 Target is a VxWorks kernel. 5055 5056'vxworks_rtp' 5057 Target is a VxWorks RTP. 5058 5059'wchar' 5060 Target supports wide characters. 5061 50627.2.3.11 Other attributes 5063......................... 5064 5065'automatic_stack_alignment' 5066 Target supports automatic stack alignment. 5067 5068'cxa_atexit' 5069 Target uses '__cxa_atexit'. 5070 5071'default_packed' 5072 Target has packed layout of structure members by default. 5073 5074'fgraphite' 5075 Target supports Graphite optimizations. 5076 5077'fixed_point' 5078 Target supports fixed-point extension to C. 5079 5080'fopenacc' 5081 Target supports OpenACC via '-fopenacc'. 5082 5083'fopenmp' 5084 Target supports OpenMP via '-fopenmp'. 5085 5086'fpic' 5087 Target supports '-fpic' and '-fPIC'. 5088 5089'freorder' 5090 Target supports '-freorder-blocks-and-partition'. 5091 5092'fstack_protector' 5093 Target supports '-fstack-protector'. 5094 5095'gas' 5096 Target uses GNU 'as'. 5097 5098'gc_sections' 5099 Target supports '--gc-sections'. 5100 5101'gld' 5102 Target uses GNU 'ld'. 5103 5104'keeps_null_pointer_checks' 5105 Target keeps null pointer checks, either due to the use of 5106 '-fno-delete-null-pointer-checks' or hardwired into the target. 5107 5108'lto' 5109 Compiler has been configured to support link-time optimization 5110 (LTO). 5111 5112'naked_functions' 5113 Target supports the 'naked' function attribute. 5114 5115'named_sections' 5116 Target supports named sections. 5117 5118'natural_alignment_32' 5119 Target uses natural alignment (aligned to type size) for types of 5120 32 bits or less. 5121 5122'target_natural_alignment_64' 5123 Target uses natural alignment (aligned to type size) for types of 5124 64 bits or less. 5125 5126'nonpic' 5127 Target does not generate PIC by default. 5128 5129'pie_enabled' 5130 Target generates PIE by default. 5131 5132'pcc_bitfield_type_matters' 5133 Target defines 'PCC_BITFIELD_TYPE_MATTERS'. 5134 5135'pe_aligned_commons' 5136 Target supports '-mpe-aligned-commons'. 5137 5138'pie' 5139 Target supports '-pie', '-fpie' and '-fPIE'. 5140 5141'section_anchors' 5142 Target supports section anchors. 5143 5144'short_enums' 5145 Target defaults to short enums. 5146 5147'static' 5148 Target supports '-static'. 5149 5150'static_libgfortran' 5151 Target supports statically linking 'libgfortran'. 5152 5153'string_merging' 5154 Target supports merging string constants at link time. 5155 5156'ucn' 5157 Target supports compiling and assembling UCN. 5158 5159'ucn_nocache' 5160 Including the options used to compile this particular test, the 5161 target supports compiling and assembling UCN. 5162 5163'unaligned_stack' 5164 Target does not guarantee that its 'STACK_BOUNDARY' is greater than 5165 or equal to the required vector alignment. 5166 5167'vector_alignment_reachable' 5168 Vector alignment is reachable for types of 32 bits or less. 5169 5170'vector_alignment_reachable_for_64bit' 5171 Vector alignment is reachable for types of 64 bits or less. 5172 5173'wchar_t_char16_t_compatible' 5174 Target supports 'wchar_t' that is compatible with 'char16_t'. 5175 5176'wchar_t_char32_t_compatible' 5177 Target supports 'wchar_t' that is compatible with 'char32_t'. 5178 5179'comdat_group' 5180 Target uses comdat groups. 5181 51827.2.3.12 Local to tests in 'gcc.target/i386' 5183............................................ 5184 5185'3dnow' 5186 Target supports compiling '3dnow' instructions. 5187 5188'aes' 5189 Target supports compiling 'aes' instructions. 5190 5191'fma4' 5192 Target supports compiling 'fma4' instructions. 5193 5194'ms_hook_prologue' 5195 Target supports attribute 'ms_hook_prologue'. 5196 5197'pclmul' 5198 Target supports compiling 'pclmul' instructions. 5199 5200'sse3' 5201 Target supports compiling 'sse3' instructions. 5202 5203'sse4' 5204 Target supports compiling 'sse4' instructions. 5205 5206'sse4a' 5207 Target supports compiling 'sse4a' instructions. 5208 5209'ssse3' 5210 Target supports compiling 'ssse3' instructions. 5211 5212'vaes' 5213 Target supports compiling 'vaes' instructions. 5214 5215'vpclmul' 5216 Target supports compiling 'vpclmul' instructions. 5217 5218'xop' 5219 Target supports compiling 'xop' instructions. 5220 52217.2.3.13 Local to tests in 'gcc.target/spu/ea' 5222.............................................. 5223 5224'ealib' 5225 Target '__ea' library functions are available. 5226 52277.2.3.14 Local to tests in 'gcc.test-framework' 5228............................................... 5229 5230'no' 5231 Always returns 0. 5232 5233'yes' 5234 Always returns 1. 5235 5236 5237File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives 5238 52397.2.4 Features for 'dg-add-options' 5240----------------------------------- 5241 5242The supported values of FEATURE for directive 'dg-add-options' are: 5243 5244'arm_neon' 5245 NEON support. Only ARM targets support this feature, and only then 5246 in certain modes; see the *note arm_neon_ok effective target 5247 keyword: arm_neon_ok. 5248 5249'arm_neon_fp16' 5250 NEON and half-precision floating point support. Only ARM targets 5251 support this feature, and only then in certain modes; see the *note 5252 arm_neon_fp16_ok effective target keyword: arm_neon_ok. 5253 5254'arm_vfp3' 5255 arm vfp3 floating point support; see the *note arm_vfp3_ok 5256 effective target keyword: arm_vfp3_ok. 5257 5258'bind_pic_locally' 5259 Add the target-specific flags needed to enable functions to bind 5260 locally when using pic/PIC passes in the testsuite. 5261 5262'c99_runtime' 5263 Add the target-specific flags needed to access the C99 runtime. 5264 5265'ieee' 5266 Add the target-specific flags needed to enable full IEEE compliance 5267 mode. 5268 5269'mips16_attribute' 5270 'mips16' function attributes. Only MIPS targets support this 5271 feature, and only then in certain modes. 5272 5273'tls' 5274 Add the target-specific flags needed to use thread-local storage. 5275 5276 5277File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives 5278 52797.2.5 Variants of 'dg-require-SUPPORT' 5280-------------------------------------- 5281 5282A few of the 'dg-require' directives take arguments. 5283 5284'dg-require-iconv CODESET' 5285 Skip the test if the target does not support iconv. CODESET is the 5286 codeset to convert to. 5287 5288'dg-require-profiling PROFOPT' 5289 Skip the test if the target does not support profiling with option 5290 PROFOPT. 5291 5292'dg-require-visibility VIS' 5293 Skip the test if the target does not support the 'visibility' 5294 attribute. If VIS is '""', support for 'visibility("hidden")' is 5295 checked, for 'visibility("VIS")' otherwise. 5296 5297 The original 'dg-require' directives were defined before there was 5298support for effective-target keywords. The directives that do not take 5299arguments could be replaced with effective-target keywords. 5300 5301'dg-require-alias ""' 5302 Skip the test if the target does not support the 'alias' attribute. 5303 5304'dg-require-ascii-locale ""' 5305 Skip the test if the host does not support an ASCII locale. 5306 5307'dg-require-compat-dfp ""' 5308 Skip this test unless both compilers in a 'compat' testsuite 5309 support decimal floating point. 5310 5311'dg-require-cxa-atexit ""' 5312 Skip the test if the target does not support '__cxa_atexit'. This 5313 is equivalent to 'dg-require-effective-target cxa_atexit'. 5314 5315'dg-require-dll ""' 5316 Skip the test if the target does not support DLL attributes. 5317 5318'dg-require-fork ""' 5319 Skip the test if the target does not support 'fork'. 5320 5321'dg-require-gc-sections ""' 5322 Skip the test if the target's linker does not support the 5323 '--gc-sections' flags. This is equivalent to 5324 'dg-require-effective-target gc-sections'. 5325 5326'dg-require-host-local ""' 5327 Skip the test if the host is remote, rather than the same as the 5328 build system. Some tests are incompatible with DejaGnu's handling 5329 of remote hosts, which involves copying the source file to the host 5330 and compiling it with a relative path and "'-o a.out'". 5331 5332'dg-require-mkfifo ""' 5333 Skip the test if the target does not support 'mkfifo'. 5334 5335'dg-require-named-sections ""' 5336 Skip the test is the target does not support named sections. This 5337 is equivalent to 'dg-require-effective-target named_sections'. 5338 5339'dg-require-weak ""' 5340 Skip the test if the target does not support weak symbols. 5341 5342'dg-require-weak-override ""' 5343 Skip the test if the target does not support overriding weak 5344 symbols. 5345 5346 5347File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives 5348 53497.2.6 Commands for use in 'dg-final' 5350------------------------------------ 5351 5352The GCC testsuite defines the following directives to be used within 5353'dg-final'. 5354 53557.2.6.1 Scan a particular file 5356.............................. 5357 5358'scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 5359 Passes if REGEXP matches text in FILENAME. 5360'scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 5361 Passes if REGEXP does not match text in FILENAME. 5362'scan-module MODULE REGEXP [{ target/xfail SELECTOR }]' 5363 Passes if REGEXP matches in Fortran module MODULE. 5364 53657.2.6.2 Scan the assembly output 5366................................ 5367 5368'scan-assembler REGEX [{ target/xfail SELECTOR }]' 5369 Passes if REGEX matches text in the test's assembler output. 5370 5371'scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 5372 Passes if REGEX does not match text in the test's assembler output. 5373 5374'scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 5375 Passes if REGEX is matched exactly NUM times in the test's 5376 assembler output. 5377 5378'scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 5379 Passes if REGEX matches text in the test's demangled assembler 5380 output. 5381 5382'scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 5383 Passes if REGEX does not match text in the test's demangled 5384 assembler output. 5385 5386'scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 5387 Passes if SYMBOL is defined as a hidden symbol in the test's 5388 assembly output. 5389 5390'scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 5391 Passes if SYMBOL is not defined as a hidden symbol in the test's 5392 assembly output. 5393 53947.2.6.3 Scan optimization dump files 5395.................................... 5396 5397These commands are available for KIND of 'tree', 'rtl', and 'ipa'. 5398 5399'scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 5400 Passes if REGEX matches text in the dump file with suffix SUFFIX. 5401 5402'scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5403 Passes if REGEX does not match text in the dump file with suffix 5404 SUFFIX. 5405 5406'scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 5407 Passes if REGEX is found exactly NUM times in the dump file with 5408 suffix SUFFIX. 5409 5410'scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 5411 Passes if REGEX matches demangled text in the dump file with suffix 5412 SUFFIX. 5413 5414'scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5415 Passes if REGEX does not match demangled text in the dump file with 5416 suffix SUFFIX. 5417 54187.2.6.4 Verify that an output files exists or not 5419................................................. 5420 5421'output-exists [{ target/xfail SELECTOR }]' 5422 Passes if compiler output file exists. 5423 5424'output-exists-not [{ target/xfail SELECTOR }]' 5425 Passes if compiler output file does not exist. 5426 54277.2.6.5 Check for LTO tests 5428........................... 5429 5430'scan-symbol REGEXP [{ target/xfail SELECTOR }]' 5431 Passes if the pattern is present in the final executable. 5432 54337.2.6.6 Checks for 'gcov' tests 5434............................... 5435 5436'run-gcov SOURCEFILE' 5437 Check line counts in 'gcov' tests. 5438 5439'run-gcov [branches] [calls] { OPTS SOURCEFILE }' 5440 Check branch and/or call counts, in addition to line counts, in 5441 'gcov' tests. 5442 54437.2.6.7 Clean up generated test files 5444..................................... 5445 5446'cleanup-coverage-files' 5447 Removes coverage data files generated for this test. 5448 5449'cleanup-ipa-dump SUFFIX' 5450 Removes IPA dump files generated for this test. 5451 5452'cleanup-modules "LIST-OF-EXTRA-MODULES"' 5453 Removes Fortran module files generated for this test, excluding the 5454 module names listed in keep-modules. Cleaning up module files is 5455 usually done automatically by the testsuite by looking at the 5456 source files and removing the modules after the test has been 5457 executed. 5458 module MoD1 5459 end module MoD1 5460 module Mod2 5461 end module Mod2 5462 module moD3 5463 end module moD3 5464 module mod4 5465 end module mod4 5466 ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant 5467 ! { dg-final { keep-modules "mod3 mod4" } } 5468 5469'keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"' 5470 Whitespace separated list of module names that should not be 5471 deleted by cleanup-modules. If the list of modules is empty, all 5472 modules defined in this file are kept. 5473 module maybe_unneeded 5474 end module maybe_unneeded 5475 module keep1 5476 end module keep1 5477 module keep2 5478 end module keep2 5479 ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two 5480 ! { dg-final { keep-modules "" } } ! keep all 5481 5482'cleanup-profile-file' 5483 Removes profiling files generated for this test. 5484 5485'cleanup-repo-files' 5486 Removes files generated for this test for '-frepo'. 5487 5488'cleanup-rtl-dump SUFFIX' 5489 Removes RTL dump files generated for this test. 5490 5491'cleanup-saved-temps' 5492 Removes files for the current test which were kept for 5493 '-save-temps'. 5494 5495'cleanup-tree-dump SUFFIX' 5496 Removes tree dump files matching SUFFIX which were generated for 5497 this test. 5498 5499 5500File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 5501 55027.3 Ada Language Testsuites 5503=========================== 5504 5505The Ada testsuite includes executable tests from the ACATS testsuite, 5506publicly available at <http://www.ada-auth.org/acats.html>. 5507 5508 These tests are integrated in the GCC testsuite in the 'ada/acats' 5509directory, and enabled automatically when running 'make check', assuming 5510the Ada language has been enabled when configuring GCC. 5511 5512 You can also run the Ada testsuite independently, using 'make 5513check-ada', or run a subset of the tests by specifying which chapter to 5514run, e.g.: 5515 5516 $ make check-ada CHAPTERS="c3 c9" 5517 5518 The tests are organized by directory, each directory corresponding to a 5519chapter of the Ada Reference Manual. So for example, 'c9' corresponds 5520to chapter 9, which deals with tasking features of the language. 5521 5522 There is also an extra chapter called 'gcc' containing a template for 5523creating new executable tests, although this is deprecated in favor of 5524the 'gnat.dg' testsuite. 5525 5526 The tests are run using two 'sh' scripts: 'run_acats' and 'run_all.sh'. 5527To run the tests using a simulator or a cross target, see the small 5528customization section at the top of 'run_all.sh'. 5529 5530 These tests are run using the build tree: they can be run without doing 5531a 'make install'. 5532 5533 5534File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites 5535 55367.4 C Language Testsuites 5537========================= 5538 5539GCC contains the following C language testsuites, in the 'gcc/testsuite' 5540directory: 5541 5542'gcc.dg' 5543 This contains tests of particular features of the C compiler, using 5544 the more modern 'dg' harness. Correctness tests for various 5545 compiler features should go here if possible. 5546 5547 Magic comments determine whether the file is preprocessed, 5548 compiled, linked or run. In these tests, error and warning message 5549 texts are compared against expected texts or regular expressions 5550 given in comments. These tests are run with the options '-ansi 5551 -pedantic' unless other options are given in the test. Except as 5552 noted below they are not run with multiple optimization options. 5553'gcc.dg/compat' 5554 This subdirectory contains tests for binary compatibility using 5555 'lib/compat.exp', which in turn uses the language-independent 5556 support (*note Support for testing binary compatibility: compat 5557 Testing.). 5558'gcc.dg/cpp' 5559 This subdirectory contains tests of the preprocessor. 5560'gcc.dg/debug' 5561 This subdirectory contains tests for debug formats. Tests in this 5562 subdirectory are run for each debug format that the compiler 5563 supports. 5564'gcc.dg/format' 5565 This subdirectory contains tests of the '-Wformat' format checking. 5566 Tests in this directory are run with and without '-DWIDE'. 5567'gcc.dg/noncompile' 5568 This subdirectory contains tests of code that should not compile 5569 and does not need any special compilation options. They are run 5570 with multiple optimization options, since sometimes invalid code 5571 crashes the compiler with optimization. 5572'gcc.dg/special' 5573 FIXME: describe this. 5574 5575'gcc.c-torture' 5576 This contains particular code fragments which have historically 5577 broken easily. These tests are run with multiple optimization 5578 options, so tests for features which only break at some 5579 optimization levels belong here. This also contains tests to check 5580 that certain optimizations occur. It might be worthwhile to 5581 separate the correctness tests cleanly from the code quality tests, 5582 but it hasn't been done yet. 5583 5584'gcc.c-torture/compat' 5585 FIXME: describe this. 5586 5587 This directory should probably not be used for new tests. 5588'gcc.c-torture/compile' 5589 This testsuite contains test cases that should compile, but do not 5590 need to link or run. These test cases are compiled with several 5591 different combinations of optimization options. All warnings are 5592 disabled for these test cases, so this directory is not suitable if 5593 you wish to test for the presence or absence of compiler warnings. 5594 While special options can be set, and tests disabled on specific 5595 platforms, by the use of '.x' files, mostly these test cases should 5596 not contain platform dependencies. FIXME: discuss how defines such 5597 as 'NO_LABEL_VALUES' and 'STACK_SIZE' are used. 5598'gcc.c-torture/execute' 5599 This testsuite contains test cases that should compile, link and 5600 run; otherwise the same comments as for 'gcc.c-torture/compile' 5601 apply. 5602'gcc.c-torture/execute/ieee' 5603 This contains tests which are specific to IEEE floating point. 5604'gcc.c-torture/unsorted' 5605 FIXME: describe this. 5606 5607 This directory should probably not be used for new tests. 5608'gcc.misc-tests' 5609 This directory contains C tests that require special handling. 5610 Some of these tests have individual expect files, and others share 5611 special-purpose expect files: 5612 5613 'bprob*.c' 5614 Test '-fbranch-probabilities' using 5615 'gcc.misc-tests/bprob.exp', which in turn uses the generic, 5616 language-independent framework (*note Support for testing 5617 profile-directed optimizations: profopt Testing.). 5618 5619 'gcov*.c' 5620 Test 'gcov' output using 'gcov.exp', which in turn uses the 5621 language-independent support (*note Support for testing gcov: 5622 gcov Testing.). 5623 5624 'i386-pf-*.c' 5625 Test i386-specific support for data prefetch using 5626 'i386-prefetch.exp'. 5627 5628'gcc.test-framework' 5629 'dg-*.c' 5630 Test the testsuite itself using 5631 'gcc.test-framework/test-framework.exp'. 5632 5633 FIXME: merge in 'testsuite/README.gcc' and discuss the format of test 5634cases and magic comments more. 5635 5636 5637File: gccint.info, Node: libgcj Tests, Next: LTO Testing, Prev: C Tests, Up: Testsuites 5638 56397.5 The Java library testsuites. 5640================================ 5641 5642Runtime tests are executed via 'make check' in the 5643'TARGET/libjava/testsuite' directory in the build tree. Additional 5644runtime tests can be checked into this testsuite. 5645 5646 Regression testing of the core packages in libgcj is also covered by 5647the Mauve testsuite. The Mauve Project develops tests for the Java 5648Class Libraries. These tests are run as part of libgcj testing by 5649placing the Mauve tree within the libjava testsuite sources at 5650'libjava/testsuite/libjava.mauve/mauve', or by specifying the location 5651of that tree when invoking 'make', as in 'make MAUVEDIR=~/mauve check'. 5652 5653 To detect regressions, a mechanism in 'mauve.exp' compares the failures 5654for a test run against the list of expected failures in 5655'libjava/testsuite/libjava.mauve/xfails' from the source hierarchy. 5656Update this file when adding new failing tests to Mauve, or when fixing 5657bugs in libgcj that had caused Mauve test failures. 5658 5659 We encourage developers to contribute test cases to Mauve. 5660 5661 5662File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: libgcj Tests, Up: Testsuites 5663 56647.6 Support for testing link-time optimizations 5665=============================================== 5666 5667Tests for link-time optimizations usually require multiple source files 5668that are compiled separately, perhaps with different sets of options. 5669There are several special-purpose test directives used for these tests. 5670 5671'{ dg-lto-do DO-WHAT-KEYWORD }' 5672 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 5673 is executed. It is one of: 5674 5675 'assemble' 5676 Compile with '-c' to produce a relocatable object file. 5677 'link' 5678 Compile, assemble, and link to produce an executable file. 5679 'run' 5680 Produce and run an executable file, which is expected to 5681 return an exit code of 0. 5682 5683 The default is 'assemble'. That can be overridden for a set of 5684 tests by redefining 'dg-do-what-default' within the '.exp' file for 5685 those tests. 5686 5687 Unlike 'dg-do', 'dg-lto-do' does not support an optional 'target' 5688 or 'xfail' list. Use 'dg-skip-if', 'dg-xfail-if', or 5689 'dg-xfail-run-if'. 5690 5691'{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}' 5692 This directive provides a list of one or more sets of compiler 5693 options to override LTO_OPTIONS. Each test will be compiled and 5694 run with each of these sets of options. 5695 5696'{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}' 5697 This directive adds OPTIONS to the linker options used. 5698 5699'{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}' 5700 This directive removes OPTIONS from the set of linker options used. 5701 5702 5703File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites 5704 57057.7 Support for testing 'gcov' 5706============================== 5707 5708Language-independent support for testing 'gcov', and for checking that 5709branch profiling produces expected values, is provided by the expect 5710file 'lib/gcov.exp'. 'gcov' tests also rely on procedures in 5711'lib/gcc-dg.exp' to compile and run the test program. A typical 'gcov' 5712test contains the following DejaGnu commands within comments: 5713 5714 { dg-options "-fprofile-arcs -ftest-coverage" } 5715 { dg-do run { target native } } 5716 { dg-final { run-gcov sourcefile } } 5717 5718 Checks of 'gcov' output can include line counts, branch percentages, 5719and call return percentages. All of these checks are requested via 5720commands that appear in comments in the test's source file. Commands to 5721check line counts are processed by default. Commands to check branch 5722percentages and call return percentages are processed if the 'run-gcov' 5723command has arguments 'branches' or 'calls', respectively. For example, 5724the following specifies checking both, as well as passing '-b' to 5725'gcov': 5726 5727 { dg-final { run-gcov branches calls { -b sourcefile } } } 5728 5729 A line count command appears within a comment on the source line that 5730is expected to get the specified count and has the form 'count(CNT)'. A 5731test should only check line counts for lines that will get the same 5732count for any architecture. 5733 5734 Commands to check branch percentages ('branch') and call return 5735percentages ('returns') are very similar to each other. A beginning 5736command appears on or before the first of a range of lines that will 5737report the percentage, and the ending command follows that range of 5738lines. The beginning command can include a list of percentages, all of 5739which are expected to be found within the range. A range is terminated 5740by the next command of the same kind. A command 'branch(end)' or 5741'returns(end)' marks the end of a range without starting a new one. For 5742example: 5743 5744 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 5745 /* branch(end) */ 5746 foo (i, j); 5747 5748 For a call return percentage, the value specified is the percentage of 5749calls reported to return. For a branch percentage, the value is either 5750the expected percentage or 100 minus that value, since the direction of 5751a branch can differ depending on the target or the optimization level. 5752 5753 Not all branches and calls need to be checked. A test should not check 5754for branches that might be optimized away or replaced with predicated 5755instructions. Don't check for calls inserted by the compiler or ones 5756that might be inlined or optimized away. 5757 5758 A single test can check for combinations of line counts, branch 5759percentages, and call return percentages. The command to check a line 5760count must appear on the line that will report that count, but commands 5761to check branch percentages and call return percentages can bracket the 5762lines that report them. 5763 5764 5765File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 5766 57677.8 Support for testing profile-directed optimizations 5768====================================================== 5769 5770The file 'profopt.exp' provides language-independent support for 5771checking correct execution of a test built with profile-directed 5772optimization. This testing requires that a test program be built and 5773executed twice. The first time it is compiled to generate profile data, 5774and the second time it is compiled to use the data that was generated 5775during the first execution. The second execution is to verify that the 5776test produces the expected results. 5777 5778 To check that the optimization actually generated better code, a test 5779can be built and run a third time with normal optimizations to verify 5780that the performance is better with the profile-directed optimizations. 5781'profopt.exp' has the beginnings of this kind of support. 5782 5783 'profopt.exp' provides generic support for profile-directed 5784optimizations. Each set of tests that uses it provides information 5785about a specific optimization: 5786 5787'tool' 5788 tool being tested, e.g., 'gcc' 5789 5790'profile_option' 5791 options used to generate profile data 5792 5793'feedback_option' 5794 options used to optimize using that profile data 5795 5796'prof_ext' 5797 suffix of profile data files 5798 5799'PROFOPT_OPTIONS' 5800 list of options with which to run each test, similar to the lists 5801 for torture tests 5802 5803'{ dg-final-generate { LOCAL-DIRECTIVE } }' 5804 This directive is similar to 'dg-final', but the LOCAL-DIRECTIVE is 5805 run after the generation of profile data. 5806 5807'{ dg-final-use { LOCAL-DIRECTIVE } }' 5808 The LOCAL-DIRECTIVE is run after the profile data have been used. 5809 5810 5811File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites 5812 58137.9 Support for testing binary compatibility 5814============================================ 5815 5816The file 'compat.exp' provides language-independent support for binary 5817compatibility testing. It supports testing interoperability of two 5818compilers that follow the same ABI, or of multiple sets of compiler 5819options that should not affect binary compatibility. It is intended to 5820be used for testsuites that complement ABI testsuites. 5821 5822 A test supported by this framework has three parts, each in a separate 5823source file: a main program and two pieces that interact with each other 5824to split up the functionality being tested. 5825 5826'TESTNAME_main.SUFFIX' 5827 Contains the main program, which calls a function in file 5828 'TESTNAME_x.SUFFIX'. 5829 5830'TESTNAME_x.SUFFIX' 5831 Contains at least one call to a function in 'TESTNAME_y.SUFFIX'. 5832 5833'TESTNAME_y.SUFFIX' 5834 Shares data with, or gets arguments from, 'TESTNAME_x.SUFFIX'. 5835 5836 Within each test, the main program and one functional piece are 5837compiled by the GCC under test. The other piece can be compiled by an 5838alternate compiler. If no alternate compiler is specified, then all 5839three source files are all compiled by the GCC under test. You can 5840specify pairs of sets of compiler options. The first element of such a 5841pair specifies options used with the GCC under test, and the second 5842element of the pair specifies options used with the alternate compiler. 5843Each test is compiled with each pair of options. 5844 5845 'compat.exp' defines default pairs of compiler options. These can be 5846overridden by defining the environment variable 'COMPAT_OPTIONS' as: 5847 5848 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 5849 ...[list {TSTN} {ALTN}]]" 5850 5851 where TSTI and ALTI are lists of options, with TSTI used by the 5852compiler under test and ALTI used by the alternate compiler. For 5853example, with '[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 5854the test is first built with '-g -O0' by the compiler under test and 5855with '-O3' by the alternate compiler. The test is built a second time 5856using '-fpic' by the compiler under test and '-fPIC -O2' by the 5857alternate compiler. 5858 5859 An alternate compiler is specified by defining an environment variable 5860to be the full pathname of an installed compiler; for C define 5861'ALT_CC_UNDER_TEST', and for C++ define 'ALT_CXX_UNDER_TEST'. These 5862will be written to the 'site.exp' file used by DejaGnu. The default is 5863to build each test with the compiler under test using the first of each 5864pair of compiler options from 'COMPAT_OPTIONS'. When 5865'ALT_CC_UNDER_TEST' or 'ALT_CXX_UNDER_TEST' is 'same', each test is 5866built using the compiler under test but with combinations of the options 5867from 'COMPAT_OPTIONS'. 5868 5869 To run only the C++ compatibility suite using the compiler under test 5870and another version of GCC using specific compiler options, do the 5871following from 'OBJDIR/gcc': 5872 5873 rm site.exp 5874 make -k \ 5875 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 5876 COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \ 5877 check-c++ \ 5878 RUNTESTFLAGS="compat.exp" 5879 5880 A test that fails when the source files are compiled with different 5881compilers, but passes when the files are compiled with the same 5882compiler, demonstrates incompatibility of the generated code or runtime 5883support. A test that fails for the alternate compiler but passes for 5884the compiler under test probably tests for a bug that was fixed in the 5885compiler under test but is present in the alternate compiler. 5886 5887 The binary compatibility tests support a small number of test framework 5888commands that appear within comments in a test file. 5889 5890'dg-require-*' 5891 These commands can be used in 'TESTNAME_main.SUFFIX' to skip the 5892 test if specific support is not available on the target. 5893 5894'dg-options' 5895 The specified options are used for compiling this particular source 5896 file, appended to the options from 'COMPAT_OPTIONS'. When this 5897 command appears in 'TESTNAME_main.SUFFIX' the options are also used 5898 to link the test program. 5899 5900'dg-xfail-if' 5901 This command can be used in a secondary source file to specify that 5902 compilation is expected to fail for particular options on 5903 particular targets. 5904 5905 5906File: gccint.info, Node: Torture Tests, Prev: compat Testing, Up: Testsuites 5907 59087.10 Support for torture testing using multiple options 5909======================================================= 5910 5911Throughout the compiler testsuite there are several directories whose 5912tests are run multiple times, each with a different set of options. 5913These are known as torture tests. 'lib/torture-options.exp' defines 5914procedures to set up these lists: 5915 5916'torture-init' 5917 Initialize use of torture lists. 5918'set-torture-options' 5919 Set lists of torture options to use for tests with and without 5920 loops. Optionally combine a set of torture options with a set of 5921 other options, as is done with Objective-C runtime options. 5922'torture-finish' 5923 Finalize use of torture lists. 5924 5925 The '.exp' file for a set of tests that use torture options must 5926include calls to these three procedures if: 5927 5928 * It calls 'gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS. 5929 5930 * It calls ${TOOL}'-torture' or ${TOOL}'-torture-execute', where TOOL 5931 is 'c', 'fortran', or 'objc'. 5932 5933 * It calls 'dg-pch'. 5934 5935 It is not necessary for a '.exp' file that calls 'gcc-dg-runtest' to 5936call the torture procedures if the tests should use the list in 5937DG_TORTURE_OPTIONS defined in 'gcc-dg.exp'. 5938 5939 Most uses of torture options can override the default lists by defining 5940TORTURE_OPTIONS or add to the default list by defining 5941ADDITIONAL_TORTURE_OPTIONS. Define these in a '.dejagnurc' file or add 5942them to the 'site.exp' file; for example 5943 5944 set ADDITIONAL_TORTURE_OPTIONS [list \ 5945 { -O2 -ftree-loop-linear } \ 5946 { -O2 -fpeel-loops } ] 5947 5948 5949File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top 5950 59518 Option specification files 5952**************************** 5953 5954Most GCC command-line options are described by special option definition 5955files, the names of which conventionally end in '.opt'. This chapter 5956describes the format of these files. 5957 5958* Menu: 5959 5960* Option file format:: The general layout of the files 5961* Option properties:: Supported option properties 5962 5963 5964File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 5965 59668.1 Option file format 5967====================== 5968 5969Option files are a simple list of records in which each field occupies 5970its own line and in which the records themselves are separated by blank 5971lines. Comments may appear on their own line anywhere within the file 5972and are preceded by semicolons. Whitespace is allowed before the 5973semicolon. 5974 5975 The files can contain the following types of record: 5976 5977 * A language definition record. These records have two fields: the 5978 string 'Language' and the name of the language. Once a language 5979 has been declared in this way, it can be used as an option 5980 property. *Note Option properties::. 5981 5982 * A target specific save record to save additional information. 5983 These records have two fields: the string 'TargetSave', and a 5984 declaration type to go in the 'cl_target_option' structure. 5985 5986 * A variable record to define a variable used to store option 5987 information. These records have two fields: the string 'Variable', 5988 and a declaration of the type and name of the variable, optionally 5989 with an initializer (but without any trailing ';'). These records 5990 may be used for variables used for many options where declaring the 5991 initializer in a single option definition record, or duplicating it 5992 in many records, would be inappropriate, or for variables set in 5993 option handlers rather than referenced by 'Var' properties. 5994 5995 * A variable record to define a variable used to store option 5996 information. These records have two fields: the string 5997 'TargetVariable', and a declaration of the type and name of the 5998 variable, optionally with an initializer (but without any trailing 5999 ';'). 'TargetVariable' is a combination of 'Variable' and 6000 'TargetSave' records in that the variable is defined in the 6001 'gcc_options' structure, but these variables are also stored in the 6002 'cl_target_option' structure. The variables are saved in the 6003 target save code and restored in the target restore code. 6004 6005 * A variable record to record any additional files that the 6006 'options.h' file should include. This is useful to provide 6007 enumeration or structure definitions needed for target variables. 6008 These records have two fields: the string 'HeaderInclude' and the 6009 name of the include file. 6010 6011 * A variable record to record any additional files that the 6012 'options.c' or 'options-save.c' file should include. This is 6013 useful to provide inline functions needed for target variables 6014 and/or '#ifdef' sequences to properly set up the initialization. 6015 These records have two fields: the string 'SourceInclude' and the 6016 name of the include file. 6017 6018 * An enumeration record to define a set of strings that may be used 6019 as arguments to an option or options. These records have three 6020 fields: the string 'Enum', a space-separated list of properties and 6021 help text used to describe the set of strings in '--help' output. 6022 Properties use the same format as option properties; the following 6023 are valid: 6024 'Name(NAME)' 6025 This property is required; NAME must be a name (suitable for 6026 use in C identifiers) used to identify the set of strings in 6027 'Enum' option properties. 6028 6029 'Type(TYPE)' 6030 This property is required; TYPE is the C type for variables 6031 set by options using this enumeration together with 'Var'. 6032 6033 'UnknownError(MESSAGE)' 6034 The message MESSAGE will be used as an error message if the 6035 argument is invalid; for enumerations without 'UnknownError', 6036 a generic error message is used. MESSAGE should contain a 6037 single '%qs' format, which will be used to format the invalid 6038 argument. 6039 6040 * An enumeration value record to define one of the strings in a set 6041 given in an 'Enum' record. These records have two fields: the 6042 string 'EnumValue' and a space-separated list of properties. 6043 Properties use the same format as option properties; the following 6044 are valid: 6045 'Enum(NAME)' 6046 This property is required; NAME says which 'Enum' record this 6047 'EnumValue' record corresponds to. 6048 6049 'String(STRING)' 6050 This property is required; STRING is the string option 6051 argument being described by this record. 6052 6053 'Value(VALUE)' 6054 This property is required; it says what value (representable 6055 as 'int') should be used for the given string. 6056 6057 'Canonical' 6058 This property is optional. If present, it says the present 6059 string is the canonical one among all those with the given 6060 value. Other strings yielding that value will be mapped to 6061 this one so specs do not need to handle them. 6062 6063 'DriverOnly' 6064 This property is optional. If present, the present string 6065 will only be accepted by the driver. This is used for cases 6066 such as '-march=native' that are processed by the driver so 6067 that 'gcc -v' shows how the options chosen depended on the 6068 system on which the compiler was run. 6069 6070 * An option definition record. These records have the following 6071 fields: 6072 1. the name of the option, with the leading "-" removed 6073 2. a space-separated list of option properties (*note Option 6074 properties::) 6075 3. the help text to use for '--help' (omitted if the second field 6076 contains the 'Undocumented' property). 6077 6078 By default, all options beginning with "f", "W" or "m" are 6079 implicitly assumed to take a "no-" form. This form should not be 6080 listed separately. If an option beginning with one of these 6081 letters does not have a "no-" form, you can use the 6082 'RejectNegative' property to reject it. 6083 6084 The help text is automatically line-wrapped before being displayed. 6085 Normally the name of the option is printed on the left-hand side of 6086 the output and the help text is printed on the right. However, if 6087 the help text contains a tab character, the text to the left of the 6088 tab is used instead of the option's name and the text to the right 6089 of the tab forms the help text. This allows you to elaborate on 6090 what type of argument the option takes. 6091 6092 * A target mask record. These records have one field of the form 6093 'Mask(X)'. The options-processing script will automatically 6094 allocate a bit in 'target_flags' (*note Run-time Target::) for each 6095 mask name X and set the macro 'MASK_X' to the appropriate bitmask. 6096 It will also declare a 'TARGET_X' macro that has the value 1 when 6097 bit 'MASK_X' is set and 0 otherwise. 6098 6099 They are primarily intended to declare target masks that are not 6100 associated with user options, either because these masks represent 6101 internal switches or because the options are not available on all 6102 configurations and yet the masks always need to be defined. 6103 6104 6105File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 6106 61078.2 Option properties 6108===================== 6109 6110The second field of an option record can specify any of the following 6111properties. When an option takes an argument, it is enclosed in 6112parentheses following the option property name. The parser that handles 6113option files is quite simplistic, and will be tricked by any nested 6114parentheses within the argument text itself; in this case, the entire 6115option argument can be wrapped in curly braces within the parentheses to 6116demarcate it, e.g.: 6117 6118 Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)}) 6119 6120'Common' 6121 The option is available for all languages and targets. 6122 6123'Target' 6124 The option is available for all languages but is target-specific. 6125 6126'Driver' 6127 The option is handled by the compiler driver using code not shared 6128 with the compilers proper ('cc1' etc.). 6129 6130'LANGUAGE' 6131 The option is available when compiling for the given language. 6132 6133 It is possible to specify several different languages for the same 6134 option. Each LANGUAGE must have been declared by an earlier 6135 'Language' record. *Note Option file format::. 6136 6137'RejectDriver' 6138 The option is only handled by the compilers proper ('cc1' etc.) and 6139 should not be accepted by the driver. 6140 6141'RejectNegative' 6142 The option does not have a "no-" form. All options beginning with 6143 "f", "W" or "m" are assumed to have a "no-" form unless this 6144 property is used. 6145 6146'Negative(OTHERNAME)' 6147 The option will turn off another option OTHERNAME, which is the 6148 option name with the leading "-" removed. This chain action will 6149 propagate through the 'Negative' property of the option to be 6150 turned off. 6151 6152 As a consequence, if you have a group of mutually-exclusive 6153 options, their 'Negative' properties should form a circular chain. 6154 For example, if options '-A', '-B' and '-C' are mutually exclusive, 6155 their respective 'Negative' properties should be 'Negative(B)', 6156 'Negative(C)' and 'Negative(A)'. 6157 6158'Joined' 6159'Separate' 6160 The option takes a mandatory argument. 'Joined' indicates that the 6161 option and argument can be included in the same 'argv' entry (as 6162 with '-mflush-func=NAME', for example). 'Separate' indicates that 6163 the option and argument can be separate 'argv' entries (as with 6164 '-o'). An option is allowed to have both of these properties. 6165 6166'JoinedOrMissing' 6167 The option takes an optional argument. If the argument is given, 6168 it will be part of the same 'argv' entry as the option itself. 6169 6170 This property cannot be used alongside 'Joined' or 'Separate'. 6171 6172'MissingArgError(MESSAGE)' 6173 For an option marked 'Joined' or 'Separate', the message MESSAGE 6174 will be used as an error message if the mandatory argument is 6175 missing; for options without 'MissingArgError', a generic error 6176 message is used. MESSAGE should contain a single '%qs' format, 6177 which will be used to format the name of the option passed. 6178 6179'Args(N)' 6180 For an option marked 'Separate', indicate that it takes N 6181 arguments. The default is 1. 6182 6183'UInteger' 6184 The option's argument is a non-negative integer. The option parser 6185 will check and convert the argument before passing it to the 6186 relevant option handler. 'UInteger' should also be used on options 6187 like '-falign-loops' where both '-falign-loops' and 6188 '-falign-loops'=N are supported to make sure the saved options are 6189 given a full integer. 6190 6191'ToLower' 6192 The option's argument should be converted to lowercase as part of 6193 putting it in canonical form, and before comparing with the strings 6194 indicated by any 'Enum' property. 6195 6196'NoDriverArg' 6197 For an option marked 'Separate', the option only takes an argument 6198 in the compiler proper, not in the driver. This is for 6199 compatibility with existing options that are used both directly and 6200 via '-Wp,'; new options should not have this property. 6201 6202'Var(VAR)' 6203 The state of this option should be stored in variable VAR (actually 6204 a macro for 'global_options.x_VAR'). The way that the state is 6205 stored depends on the type of option: 6206 6207 * If the option uses the 'Mask' or 'InverseMask' properties, VAR 6208 is the integer variable that contains the mask. 6209 6210 * If the option is a normal on/off switch, VAR is an integer 6211 variable that is nonzero when the option is enabled. The 6212 options parser will set the variable to 1 when the positive 6213 form of the option is used and 0 when the "no-" form is used. 6214 6215 * If the option takes an argument and has the 'UInteger' 6216 property, VAR is an integer variable that stores the value of 6217 the argument. 6218 6219 * If the option takes an argument and has the 'Enum' property, 6220 VAR is a variable (type given in the 'Type' property of the 6221 'Enum' record whose 'Name' property has the same argument as 6222 the 'Enum' property of this option) that stores the value of 6223 the argument. 6224 6225 * If the option has the 'Defer' property, VAR is a pointer to a 6226 'VEC(cl_deferred_option,heap)' that stores the option for 6227 later processing. (VAR is declared with type 'void *' and 6228 needs to be cast to 'VEC(cl_deferred_option,heap)' before 6229 use.) 6230 6231 * Otherwise, if the option takes an argument, VAR is a pointer 6232 to the argument string. The pointer will be null if the 6233 argument is optional and wasn't given. 6234 6235 The option-processing script will usually zero-initialize VAR. You 6236 can modify this behavior using 'Init'. 6237 6238'Var(VAR, SET)' 6239 The option controls an integer variable VAR and is active when VAR 6240 equals SET. The option parser will set VAR to SET when the 6241 positive form of the option is used and '!SET' when the "no-" form 6242 is used. 6243 6244 VAR is declared in the same way as for the single-argument form 6245 described above. 6246 6247'Init(VALUE)' 6248 The variable specified by the 'Var' property should be statically 6249 initialized to VALUE. If more than one option using the same 6250 variable specifies 'Init', all must specify the same initializer. 6251 6252'Mask(NAME)' 6253 The option is associated with a bit in the 'target_flags' variable 6254 (*note Run-time Target::) and is active when that bit is set. You 6255 may also specify 'Var' to select a variable other than 6256 'target_flags'. 6257 6258 The options-processing script will automatically allocate a unique 6259 bit for the option. If the option is attached to 'target_flags', 6260 the script will set the macro 'MASK_NAME' to the appropriate 6261 bitmask. It will also declare a 'TARGET_NAME' macro that has the 6262 value 1 when the option is active and 0 otherwise. If you use 6263 'Var' to attach the option to a different variable, the bitmask 6264 macro with be called 'OPTION_MASK_NAME'. 6265 6266'InverseMask(OTHERNAME)' 6267'InverseMask(OTHERNAME, THISNAME)' 6268 The option is the inverse of another option that has the 6269 'Mask(OTHERNAME)' property. If THISNAME is given, the 6270 options-processing script will declare a 'TARGET_THISNAME' macro 6271 that is 1 when the option is active and 0 otherwise. 6272 6273'Enum(NAME)' 6274 The option's argument is a string from the set of strings 6275 associated with the corresponding 'Enum' record. The string is 6276 checked and converted to the integer specified in the corresponding 6277 'EnumValue' record before being passed to option handlers. 6278 6279'Defer' 6280 The option should be stored in a vector, specified with 'Var', for 6281 later processing. 6282 6283'Alias(OPT)' 6284'Alias(OPT, ARG)' 6285'Alias(OPT, POSARG, NEGARG)' 6286 The option is an alias for '-OPT' (or the negative form of that 6287 option, depending on 'NegativeAlias'). In the first form, any 6288 argument passed to the alias is considered to be passed to '-OPT', 6289 and '-OPT' is considered to be negated if the alias is used in 6290 negated form. In the second form, the alias may not be negated or 6291 have an argument, and POSARG is considered to be passed as an 6292 argument to '-OPT'. In the third form, the alias may not have an 6293 argument, if the alias is used in the positive form then POSARG is 6294 considered to be passed to '-OPT', and if the alias is used in the 6295 negative form then NEGARG is considered to be passed to '-OPT'. 6296 6297 Aliases should not specify 'Var' or 'Mask' or 'UInteger'. Aliases 6298 should normally specify the same languages as the target of the 6299 alias; the flags on the target will be used to determine any 6300 diagnostic for use of an option for the wrong language, while those 6301 on the alias will be used to identify what command-line text is the 6302 option and what text is any argument to that option. 6303 6304 When an 'Alias' definition is used for an option, driver specs do 6305 not need to handle it and no 'OPT_' enumeration value is defined 6306 for it; only the canonical form of the option will be seen in those 6307 places. 6308 6309'NegativeAlias' 6310 For an option marked with 'Alias(OPT)', the option is considered to 6311 be an alias for the positive form of '-OPT' if negated and for the 6312 negative form of '-OPT' if not negated. 'NegativeAlias' may not be 6313 used with the forms of 'Alias' taking more than one argument. 6314 6315'Ignore' 6316 This option is ignored apart from printing any warning specified 6317 using 'Warn'. The option will not be seen by specs and no 'OPT_' 6318 enumeration value is defined for it. 6319 6320'SeparateAlias' 6321 For an option marked with 'Joined', 'Separate' and 'Alias', the 6322 option only acts as an alias when passed a separate argument; with 6323 a joined argument it acts as a normal option, with an 'OPT_' 6324 enumeration value. This is for compatibility with the Java '-d' 6325 option and should not be used for new options. 6326 6327'Warn(MESSAGE)' 6328 If this option is used, output the warning MESSAGE. MESSAGE is a 6329 format string, either taking a single operand with a '%qs' format 6330 which is the option name, or not taking any operands, which is 6331 passed to the 'warning' function. If an alias is marked 'Warn', 6332 the target of the alias must not also be marked 'Warn'. 6333 6334'Report' 6335 The state of the option should be printed by '-fverbose-asm'. 6336 6337'Warning' 6338 This is a warning option and should be shown as such in '--help' 6339 output. This flag does not currently affect anything other than 6340 '--help'. 6341 6342'Optimization' 6343 This is an optimization option. It should be shown as such in 6344 '--help' output, and any associated variable named using 'Var' 6345 should be saved and restored when the optimization level is changed 6346 with 'optimize' attributes. 6347 6348'Undocumented' 6349 The option is deliberately missing documentation and should not be 6350 included in the '--help' output. 6351 6352'Condition(COND)' 6353 The option should only be accepted if preprocessor condition COND 6354 is true. Note that any C declarations associated with the option 6355 will be present even if COND is false; COND simply controls whether 6356 the option is accepted and whether it is printed in the '--help' 6357 output. 6358 6359'Save' 6360 Build the 'cl_target_option' structure to hold a copy of the 6361 option, add the functions 'cl_target_option_save' and 6362 'cl_target_option_restore' to save and restore the options. 6363 6364'SetByCombined' 6365 The option may also be set by a combined option such as 6366 '-ffast-math'. This causes the 'gcc_options' struct to have a 6367 field 'frontend_set_NAME', where 'NAME' is the name of the field 6368 holding the value of this option (without the leading 'x_'). This 6369 gives the front end a way to indicate that the value has been set 6370 explicitly and should not be changed by the combined option. For 6371 example, some front ends use this to prevent '-ffast-math' and 6372 '-fno-fast-math' from changing the value of '-fmath-errno' for 6373 languages that do not use 'errno'. 6374 6375'EnabledBy(OPT)' 6376'EnabledBy(OPT || OPT2)' 6377'EnabledBy(OPT && OPT2)' 6378 If not explicitly set, the option is set to the value of '-OPT'; 6379 multiple options can be given, separated by '||'. The third form 6380 using '&&' specifies that the option is only set if both OPT and 6381 OPT2 are set. 6382 6383'LangEnabledBy(LANGUAGE, OPT)' 6384'LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)' 6385 When compiling for the given language, the option is set to the 6386 value of '-OPT', if not explicitly set. OPT can be also a list of 6387 '||' separated options. In the second form, if OPT is used in the 6388 positive form then POSARG is considered to be passed to the option, 6389 and if OPT is used in the negative form then NEGARG is considered 6390 to be passed to the option. It is possible to specify several 6391 different languages. Each LANGUAGE must have been declared by an 6392 earlier 'Language' record. *Note Option file format::. 6393 6394'NoDWARFRecord' 6395 The option is omitted from the producer string written by 6396 '-grecord-gcc-switches'. 6397 6398'PchIgnore' 6399 Even if this is a target option, this option will not be recorded / 6400 compared to determine if a precompiled header file matches. 6401 6402'CPP(VAR)' 6403 The state of this option should be kept in sync with the 6404 preprocessor option VAR. If this property is set, then properties 6405 'Var' and 'Init' must be set as well. 6406 6407'CppReason(CPP_W_ENUM)' 6408 This warning option corresponds to 'cpplib.h' warning reason code 6409 CPP_W_ENUM. This should only be used for warning options of the 6410 C-family front-ends. 6411 6412 6413File: gccint.info, Node: Passes, Next: GENERIC, Prev: Options, Up: Top 6414 64159 Passes and Files of the Compiler 6416********************************** 6417 6418This chapter is dedicated to giving an overview of the optimization and 6419code generation passes of the compiler. In the process, it describes 6420some of the language front end interface, though this description is no 6421where near complete. 6422 6423* Menu: 6424 6425* Parsing pass:: The language front end turns text into bits. 6426* Cilk Plus Transformation:: Transform Cilk Plus Code to equivalent C/C++. 6427* Gimplification pass:: The bits are turned into something we can optimize. 6428* Pass manager:: Sequencing the optimization passes. 6429* Tree SSA passes:: Optimizations on a high-level representation. 6430* RTL passes:: Optimizations on a low-level representation. 6431* Optimization info:: Dumping optimization information from passes. 6432 6433 6434File: gccint.info, Node: Parsing pass, Next: Cilk Plus Transformation, Up: Passes 6435 64369.1 Parsing pass 6437================ 6438 6439The language front end is invoked only once, via 6440'lang_hooks.parse_file', to parse the entire input. The language front 6441end may use any intermediate language representation deemed appropriate. 6442The C front end uses GENERIC trees (*note GENERIC::), plus a double 6443handful of language specific tree codes defined in 'c-common.def'. The 6444Fortran front end uses a completely different private representation. 6445 6446 At some point the front end must translate the representation used in 6447the front end to a representation understood by the language-independent 6448portions of the compiler. Current practice takes one of two forms. The 6449C front end manually invokes the gimplifier (*note GIMPLE::) on each 6450function, and uses the gimplifier callbacks to convert the 6451language-specific tree nodes directly to GIMPLE before passing the 6452function off to be compiled. The Fortran front end converts from a 6453private representation to GENERIC, which is later lowered to GIMPLE when 6454the function is compiled. Which route to choose probably depends on how 6455well GENERIC (plus extensions) can be made to match up with the source 6456language and necessary parsing data structures. 6457 6458 BUG: Gimplification must occur before nested function lowering, and 6459nested function lowering must be done by the front end before passing 6460the data off to cgraph. 6461 6462 TODO: Cgraph should control nested function lowering. It would only be 6463invoked when it is certain that the outer-most function is used. 6464 6465 TODO: Cgraph needs a gimplify_function callback. It should be invoked 6466when (1) it is certain that the function is used, (2) warning flags 6467specified by the user require some amount of compilation in order to 6468honor, (3) the language indicates that semantic analysis is not complete 6469until gimplification occurs. Hum... this sounds overly complicated. 6470Perhaps we should just have the front end gimplify always; in most cases 6471it's only one function call. 6472 6473 The front end needs to pass all function definitions and top level 6474declarations off to the middle-end so that they can be compiled and 6475emitted to the object file. For a simple procedural language, it is 6476usually most convenient to do this as each top level declaration or 6477definition is seen. There is also a distinction to be made between 6478generating functional code and generating complete debug information. 6479The only thing that is absolutely required for functional code is that 6480function and data _definitions_ be passed to the middle-end. For 6481complete debug information, function, data and type declarations should 6482all be passed as well. 6483 6484 In any case, the front end needs each complete top-level function or 6485data declaration, and each data definition should be passed to 6486'rest_of_decl_compilation'. Each complete type definition should be 6487passed to 'rest_of_type_compilation'. Each function definition should 6488be passed to 'cgraph_finalize_function'. 6489 6490 TODO: I know rest_of_compilation currently has all sorts of RTL 6491generation semantics. I plan to move all code generation bits (both 6492Tree and RTL) to compile_function. Should we hide cgraph from the front 6493ends and move back to rest_of_compilation as the official interface? 6494Possibly we should rename all three interfaces such that the names match 6495in some meaningful way and that is more descriptive than "rest_of". 6496 6497 The middle-end will, at its option, emit the function and data 6498definitions immediately or queue them for later processing. 6499 6500 6501File: gccint.info, Node: Cilk Plus Transformation, Next: Gimplification pass, Prev: Parsing pass, Up: Passes 6502 65039.2 Cilk Plus Transformation 6504============================ 6505 6506If Cilk Plus generation (flag '-fcilkplus') is enabled, all the Cilk 6507Plus code is transformed into equivalent C and C++ functions. Majority 6508of this transformation occurs toward the end of the parsing and right 6509before the gimplification pass. 6510 6511 These are the major components to the Cilk Plus language extension: 6512 * Array Notations: During parsing phase, all the array notation 6513 specific information is stored in 'ARRAY_NOTATION_REF' tree using 6514 the function 'c_parser_array_notation'. During the end of parsing, 6515 we check the entire function to see if there are any array notation 6516 specific code (using the function 'contains_array_notation_expr'). 6517 If this function returns true, then we expand them using either 6518 'expand_array_notation_exprs' or 'build_array_notation_expr'. For 6519 the cases where array notations are inside conditions, they are 6520 transformed using the function 'fix_conditional_array_notations'. 6521 The C language-specific routines are located in 6522 'c/c-array-notation.c' and the equivalent C++ routines are in the 6523 file 'cp/cp-array-notation.c'. Common routines such as functions 6524 to initialize built-in functions are stored in 6525 'array-notation-common.c'. 6526 6527 * Cilk keywords: 6528 * '_Cilk_spawn': The '_Cilk_spawn' keyword is parsed and the 6529 function it contains is marked as a spawning function. The 6530 spawning function is called the spawner. At the end of the 6531 parsing phase, appropriate built-in functions are added to the 6532 spawner that are defined in the Cilk runtime. The appropriate 6533 locations of these functions, and the internal structures are 6534 detailed in 'cilk_init_builtins' in the file 'cilk-common.c'. 6535 The pointers to Cilk functions and fields of internal 6536 structures are described in 'cilk.h'. The built-in functions 6537 are described in 'cilk-builtins.def'. 6538 6539 During gimplification, a new "spawn-helper" function is 6540 created. The spawned function is replaced with a spawn helper 6541 function in the spawner. The spawned function-call is moved 6542 into the spawn helper. The main function that does these 6543 transformations is 'gimplify_cilk_spawn' in 'c-family/cilk.c'. 6544 In the spawn-helper, the gimplification function 6545 'gimplify_call_expr', inserts a function call 6546 '__cilkrts_detach'. This function is expanded by 6547 'builtin_expand_cilk_detach' located in 'c-family/cilk.c'. 6548 6549 * '_Cilk_sync': '_Cilk_sync' is parsed like a keyword. During 6550 gimplification, the function 'gimplify_cilk_sync' in 6551 'c-family/cilk.c', will replace this keyword with a set of 6552 functions that are stored in the Cilk runtime. One of the 6553 internal functions inserted during gimplification, 6554 '__cilkrts_pop_frame' must be expanded by the compiler and is 6555 done by 'builtin_expand_cilk_pop_frame' in 'cilk-common.c'. 6556 6557 Documentation about Cilk Plus and language specification is provided 6558under the "Learn" section in <https://www.cilkplus.org>. It is worth 6559mentioning that the current implementation follows ABI 1.1. 6560 6561 6562File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Cilk Plus Transformation, Up: Passes 6563 65649.3 Gimplification pass 6565======================= 6566 6567"Gimplification" is a whimsical term for the process of converting the 6568intermediate representation of a function into the GIMPLE language 6569(*note GIMPLE::). The term stuck, and so words like "gimplification", 6570"gimplify", "gimplifier" and the like are sprinkled throughout this 6571section of code. 6572 6573 While a front end may certainly choose to generate GIMPLE directly if 6574it chooses, this can be a moderately complex process unless the 6575intermediate language used by the front end is already fairly simple. 6576Usually it is easier to generate GENERIC trees plus extensions and let 6577the language-independent gimplifier do most of the work. 6578 6579 The main entry point to this pass is 'gimplify_function_tree' located 6580in 'gimplify.c'. From here we process the entire function gimplifying 6581each statement in turn. The main workhorse for this pass is 6582'gimplify_expr'. Approximately everything passes through here at least 6583once, and it is from here that we invoke the 'lang_hooks.gimplify_expr' 6584callback. 6585 6586 The callback should examine the expression in question and return 6587'GS_UNHANDLED' if the expression is not a language specific construct 6588that requires attention. Otherwise it should alter the expression in 6589some way to such that forward progress is made toward producing valid 6590GIMPLE. If the callback is certain that the transformation is complete 6591and the expression is valid GIMPLE, it should return 'GS_ALL_DONE'. 6592Otherwise it should return 'GS_OK', which will cause the expression to 6593be processed again. If the callback encounters an error during the 6594transformation (because the front end is relying on the gimplification 6595process to finish semantic checks), it should return 'GS_ERROR'. 6596 6597 6598File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes 6599 66009.4 Pass manager 6601================ 6602 6603The pass manager is located in 'passes.c', 'tree-optimize.c' and 6604'tree-pass.h'. It processes passes as described in 'passes.def'. Its 6605job is to run all of the individual passes in the correct order, and 6606take care of standard bookkeeping that applies to every pass. 6607 6608 The theory of operation is that each pass defines a structure that 6609represents everything we need to know about that pass--when it should be 6610run, how it should be run, what intermediate language form or 6611on-the-side data structures it needs. We register the pass to be run in 6612some particular order, and the pass manager arranges for everything to 6613happen in the correct order. 6614 6615 The actuality doesn't completely live up to the theory at present. 6616Command-line switches and 'timevar_id_t' enumerations must still be 6617defined elsewhere. The pass manager validates constraints but does not 6618attempt to (re-)generate data structures or lower intermediate language 6619form based on the requirements of the next pass. Nevertheless, what is 6620present is useful, and a far sight better than nothing at all. 6621 6622 Each pass should have a unique name. Each pass may have its own dump 6623file (for GCC debugging purposes). Passes with a name starting with a 6624star do not dump anything. Sometimes passes are supposed to share a 6625dump file / option name. To still give these unique names, you can use 6626a prefix that is delimited by a space from the part that is used for the 6627dump file / option name. E.g. When the pass name is "ud dce", the name 6628used for dump file/options is "dce". 6629 6630 TODO: describe the global variables set up by the pass manager, and a 6631brief description of how a new pass should use it. I need to look at 6632what info RTL passes use first... 6633 6634 6635File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes 6636 66379.5 Tree SSA passes 6638=================== 6639 6640The following briefly describes the Tree optimization passes that are 6641run after gimplification and what source files they are located in. 6642 6643 * Remove useless statements 6644 6645 This pass is an extremely simple sweep across the gimple code in 6646 which we identify obviously dead code and remove it. Here we do 6647 things like simplify 'if' statements with constant conditions, 6648 remove exception handling constructs surrounding code that 6649 obviously cannot throw, remove lexical bindings that contain no 6650 variables, and other assorted simplistic cleanups. The idea is to 6651 get rid of the obvious stuff quickly rather than wait until later 6652 when it's more work to get rid of it. This pass is located in 6653 'tree-cfg.c' and described by 'pass_remove_useless_stmts'. 6654 6655 * OpenMP lowering 6656 6657 If OpenMP generation ('-fopenmp') is enabled, this pass lowers 6658 OpenMP constructs into GIMPLE. 6659 6660 Lowering of OpenMP constructs involves creating replacement 6661 expressions for local variables that have been mapped using data 6662 sharing clauses, exposing the control flow of most synchronization 6663 directives and adding region markers to facilitate the creation of 6664 the control flow graph. The pass is located in 'omp-low.c' and is 6665 described by 'pass_lower_omp'. 6666 6667 * OpenMP expansion 6668 6669 If OpenMP generation ('-fopenmp') is enabled, this pass expands 6670 parallel regions into their own functions to be invoked by the 6671 thread library. The pass is located in 'omp-low.c' and is 6672 described by 'pass_expand_omp'. 6673 6674 * Lower control flow 6675 6676 This pass flattens 'if' statements ('COND_EXPR') and moves lexical 6677 bindings ('BIND_EXPR') out of line. After this pass, all 'if' 6678 statements will have exactly two 'goto' statements in its 'then' 6679 and 'else' arms. Lexical binding information for each statement 6680 will be found in 'TREE_BLOCK' rather than being inferred from its 6681 position under a 'BIND_EXPR'. This pass is found in 'gimple-low.c' 6682 and is described by 'pass_lower_cf'. 6683 6684 * Lower exception handling control flow 6685 6686 This pass decomposes high-level exception handling constructs 6687 ('TRY_FINALLY_EXPR' and 'TRY_CATCH_EXPR') into a form that 6688 explicitly represents the control flow involved. After this pass, 6689 'lookup_stmt_eh_region' will return a non-negative number for any 6690 statement that may have EH control flow semantics; examine 6691 'tree_can_throw_internal' or 'tree_can_throw_external' for exact 6692 semantics. Exact control flow may be extracted from 6693 'foreach_reachable_handler'. The EH region nesting tree is defined 6694 in 'except.h' and built in 'except.c'. The lowering pass itself is 6695 in 'tree-eh.c' and is described by 'pass_lower_eh'. 6696 6697 * Build the control flow graph 6698 6699 This pass decomposes a function into basic blocks and creates all 6700 of the edges that connect them. It is located in 'tree-cfg.c' and 6701 is described by 'pass_build_cfg'. 6702 6703 * Find all referenced variables 6704 6705 This pass walks the entire function and collects an array of all 6706 variables referenced in the function, 'referenced_vars'. The index 6707 at which a variable is found in the array is used as a UID for the 6708 variable within this function. This data is needed by the SSA 6709 rewriting routines. The pass is located in 'tree-dfa.c' and is 6710 described by 'pass_referenced_vars'. 6711 6712 * Enter static single assignment form 6713 6714 This pass rewrites the function such that it is in SSA form. After 6715 this pass, all 'is_gimple_reg' variables will be referenced by 6716 'SSA_NAME', and all occurrences of other variables will be 6717 annotated with 'VDEFS' and 'VUSES'; PHI nodes will have been 6718 inserted as necessary for each basic block. This pass is located 6719 in 'tree-ssa.c' and is described by 'pass_build_ssa'. 6720 6721 * Warn for uninitialized variables 6722 6723 This pass scans the function for uses of 'SSA_NAME's that are fed 6724 by default definition. For non-parameter variables, such uses are 6725 uninitialized. The pass is run twice, before and after 6726 optimization (if turned on). In the first pass we only warn for 6727 uses that are positively uninitialized; in the second pass we warn 6728 for uses that are possibly uninitialized. The pass is located in 6729 'tree-ssa.c' and is defined by 'pass_early_warn_uninitialized' and 6730 'pass_late_warn_uninitialized'. 6731 6732 * Dead code elimination 6733 6734 This pass scans the function for statements without side effects 6735 whose result is unused. It does not do memory life analysis, so 6736 any value that is stored in memory is considered used. The pass is 6737 run multiple times throughout the optimization process. It is 6738 located in 'tree-ssa-dce.c' and is described by 'pass_dce'. 6739 6740 * Dominator optimizations 6741 6742 This pass performs trivial dominator-based copy and constant 6743 propagation, expression simplification, and jump threading. It is 6744 run multiple times throughout the optimization process. It is 6745 located in 'tree-ssa-dom.c' and is described by 'pass_dominator'. 6746 6747 * Forward propagation of single-use variables 6748 6749 This pass attempts to remove redundant computation by substituting 6750 variables that are used once into the expression that uses them and 6751 seeing if the result can be simplified. It is located in 6752 'tree-ssa-forwprop.c' and is described by 'pass_forwprop'. 6753 6754 * Copy Renaming 6755 6756 This pass attempts to change the name of compiler temporaries 6757 involved in copy operations such that SSA->normal can coalesce the 6758 copy away. When compiler temporaries are copies of user variables, 6759 it also renames the compiler temporary to the user variable 6760 resulting in better use of user symbols. It is located in 6761 'tree-ssa-copyrename.c' and is described by 'pass_copyrename'. 6762 6763 * PHI node optimizations 6764 6765 This pass recognizes forms of PHI inputs that can be represented as 6766 conditional expressions and rewrites them into straight line code. 6767 It is located in 'tree-ssa-phiopt.c' and is described by 6768 'pass_phiopt'. 6769 6770 * May-alias optimization 6771 6772 This pass performs a flow sensitive SSA-based points-to analysis. 6773 The resulting may-alias, must-alias, and escape analysis 6774 information is used to promote variables from in-memory addressable 6775 objects to non-aliased variables that can be renamed into SSA form. 6776 We also update the 'VDEF'/'VUSE' memory tags for non-renameable 6777 aggregates so that we get fewer false kills. The pass is located 6778 in 'tree-ssa-alias.c' and is described by 'pass_may_alias'. 6779 6780 Interprocedural points-to information is located in 6781 'tree-ssa-structalias.c' and described by 'pass_ipa_pta'. 6782 6783 * Profiling 6784 6785 This pass instruments the function in order to collect runtime 6786 block and value profiling data. Such data may be fed back into the 6787 compiler on a subsequent run so as to allow optimization based on 6788 expected execution frequencies. The pass is located in 6789 'tree-profile.c' and is described by 'pass_ipa_tree_profile'. 6790 6791 * Static profile estimation 6792 6793 This pass implements series of heuristics to guess propababilities 6794 of branches. The resulting predictions are turned into edge 6795 profile by propagating branches across the control flow graphs. 6796 The pass is located in 'tree-profile.c' and is described by 6797 'pass_profile'. 6798 6799 * Lower complex arithmetic 6800 6801 This pass rewrites complex arithmetic operations into their 6802 component scalar arithmetic operations. The pass is located in 6803 'tree-complex.c' and is described by 'pass_lower_complex'. 6804 6805 * Scalar replacement of aggregates 6806 6807 This pass rewrites suitable non-aliased local aggregate variables 6808 into a set of scalar variables. The resulting scalar variables are 6809 rewritten into SSA form, which allows subsequent optimization 6810 passes to do a significantly better job with them. The pass is 6811 located in 'tree-sra.c' and is described by 'pass_sra'. 6812 6813 * Dead store elimination 6814 6815 This pass eliminates stores to memory that are subsequently 6816 overwritten by another store, without any intervening loads. The 6817 pass is located in 'tree-ssa-dse.c' and is described by 'pass_dse'. 6818 6819 * Tail recursion elimination 6820 6821 This pass transforms tail recursion into a loop. It is located in 6822 'tree-tailcall.c' and is described by 'pass_tail_recursion'. 6823 6824 * Forward store motion 6825 6826 This pass sinks stores and assignments down the flowgraph closer to 6827 their use point. The pass is located in 'tree-ssa-sink.c' and is 6828 described by 'pass_sink_code'. 6829 6830 * Partial redundancy elimination 6831 6832 This pass eliminates partially redundant computations, as well as 6833 performing load motion. The pass is located in 'tree-ssa-pre.c' 6834 and is described by 'pass_pre'. 6835 6836 Just before partial redundancy elimination, if 6837 '-funsafe-math-optimizations' is on, GCC tries to convert divisions 6838 to multiplications by the reciprocal. The pass is located in 6839 'tree-ssa-math-opts.c' and is described by 'pass_cse_reciprocal'. 6840 6841 * Full redundancy elimination 6842 6843 This is a simpler form of PRE that only eliminates redundancies 6844 that occur on all paths. It is located in 'tree-ssa-pre.c' and 6845 described by 'pass_fre'. 6846 6847 * Loop optimization 6848 6849 The main driver of the pass is placed in 'tree-ssa-loop.c' and 6850 described by 'pass_loop'. 6851 6852 The optimizations performed by this pass are: 6853 6854 Loop invariant motion. This pass moves only invariants that would 6855 be hard to handle on RTL level (function calls, operations that 6856 expand to nontrivial sequences of insns). With '-funswitch-loops' 6857 it also moves operands of conditions that are invariant out of the 6858 loop, so that we can use just trivial invariantness analysis in 6859 loop unswitching. The pass also includes store motion. The pass 6860 is implemented in 'tree-ssa-loop-im.c'. 6861 6862 Canonical induction variable creation. This pass creates a simple 6863 counter for number of iterations of the loop and replaces the exit 6864 condition of the loop using it, in case when a complicated analysis 6865 is necessary to determine the number of iterations. Later 6866 optimizations then may determine the number easily. The pass is 6867 implemented in 'tree-ssa-loop-ivcanon.c'. 6868 6869 Induction variable optimizations. This pass performs standard 6870 induction variable optimizations, including strength reduction, 6871 induction variable merging and induction variable elimination. The 6872 pass is implemented in 'tree-ssa-loop-ivopts.c'. 6873 6874 Loop unswitching. This pass moves the conditional jumps that are 6875 invariant out of the loops. To achieve this, a duplicate of the 6876 loop is created for each possible outcome of conditional jump(s). 6877 The pass is implemented in 'tree-ssa-loop-unswitch.c'. 6878 6879 The optimizations also use various utility functions contained in 6880 'tree-ssa-loop-manip.c', 'cfgloop.c', 'cfgloopanal.c' and 6881 'cfgloopmanip.c'. 6882 6883 Vectorization. This pass transforms loops to operate on vector 6884 types instead of scalar types. Data parallelism across loop 6885 iterations is exploited to group data elements from consecutive 6886 iterations into a vector and operate on them in parallel. 6887 Depending on available target support the loop is conceptually 6888 unrolled by a factor 'VF' (vectorization factor), which is the 6889 number of elements operated upon in parallel in each iteration, and 6890 the 'VF' copies of each scalar operation are fused to form a vector 6891 operation. Additional loop transformations such as peeling and 6892 versioning may take place to align the number of iterations, and to 6893 align the memory accesses in the loop. The pass is implemented in 6894 'tree-vectorizer.c' (the main driver), 'tree-vect-loop.c' and 6895 'tree-vect-loop-manip.c' (loop specific parts and general loop 6896 utilities), 'tree-vect-slp' (loop-aware SLP functionality), 6897 'tree-vect-stmts.c' and 'tree-vect-data-refs.c'. Analysis of data 6898 references is in 'tree-data-ref.c'. 6899 6900 SLP Vectorization. This pass performs vectorization of 6901 straight-line code. The pass is implemented in 'tree-vectorizer.c' 6902 (the main driver), 'tree-vect-slp.c', 'tree-vect-stmts.c' and 6903 'tree-vect-data-refs.c'. 6904 6905 Autoparallelization. This pass splits the loop iteration space to 6906 run into several threads. The pass is implemented in 6907 'tree-parloops.c'. 6908 6909 Graphite is a loop transformation framework based on the polyhedral 6910 model. Graphite stands for Gimple Represented as Polyhedra. The 6911 internals of this infrastructure are documented in 6912 <http://gcc.gnu.org/wiki/Graphite>. The passes working on this 6913 representation are implemented in the various 'graphite-*' files. 6914 6915 * Tree level if-conversion for vectorizer 6916 6917 This pass applies if-conversion to simple loops to help vectorizer. 6918 We identify if convertible loops, if-convert statements and merge 6919 basic blocks in one big block. The idea is to present loop in such 6920 form so that vectorizer can have one to one mapping between 6921 statements and available vector operations. This pass is located 6922 in 'tree-if-conv.c' and is described by 'pass_if_conversion'. 6923 6924 * Conditional constant propagation 6925 6926 This pass relaxes a lattice of values in order to identify those 6927 that must be constant even in the presence of conditional branches. 6928 The pass is located in 'tree-ssa-ccp.c' and is described by 6929 'pass_ccp'. 6930 6931 A related pass that works on memory loads and stores, and not just 6932 register values, is located in 'tree-ssa-ccp.c' and described by 6933 'pass_store_ccp'. 6934 6935 * Conditional copy propagation 6936 6937 This is similar to constant propagation but the lattice of values 6938 is the "copy-of" relation. It eliminates redundant copies from the 6939 code. The pass is located in 'tree-ssa-copy.c' and described by 6940 'pass_copy_prop'. 6941 6942 A related pass that works on memory copies, and not just register 6943 copies, is located in 'tree-ssa-copy.c' and described by 6944 'pass_store_copy_prop'. 6945 6946 * Value range propagation 6947 6948 This transformation is similar to constant propagation but instead 6949 of propagating single constant values, it propagates known value 6950 ranges. The implementation is based on Patterson's range 6951 propagation algorithm (Accurate Static Branch Prediction by Value 6952 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 6953 Patterson's algorithm, this implementation does not propagate 6954 branch probabilities nor it uses more than a single range per SSA 6955 name. This means that the current implementation cannot be used 6956 for branch prediction (though adapting it would not be difficult). 6957 The pass is located in 'tree-vrp.c' and is described by 'pass_vrp'. 6958 6959 * Folding built-in functions 6960 6961 This pass simplifies built-in functions, as applicable, with 6962 constant arguments or with inferable string lengths. It is located 6963 in 'tree-ssa-ccp.c' and is described by 'pass_fold_builtins'. 6964 6965 * Split critical edges 6966 6967 This pass identifies critical edges and inserts empty basic blocks 6968 such that the edge is no longer critical. The pass is located in 6969 'tree-cfg.c' and is described by 'pass_split_crit_edges'. 6970 6971 * Control dependence dead code elimination 6972 6973 This pass is a stronger form of dead code elimination that can 6974 eliminate unnecessary control flow statements. It is located in 6975 'tree-ssa-dce.c' and is described by 'pass_cd_dce'. 6976 6977 * Tail call elimination 6978 6979 This pass identifies function calls that may be rewritten into 6980 jumps. No code transformation is actually applied here, but the 6981 data and control flow problem is solved. The code transformation 6982 requires target support, and so is delayed until RTL. In the 6983 meantime 'CALL_EXPR_TAILCALL' is set indicating the possibility. 6984 The pass is located in 'tree-tailcall.c' and is described by 6985 'pass_tail_calls'. The RTL transformation is handled by 6986 'fixup_tail_calls' in 'calls.c'. 6987 6988 * Warn for function return without value 6989 6990 For non-void functions, this pass locates return statements that do 6991 not specify a value and issues a warning. Such a statement may 6992 have been injected by falling off the end of the function. This 6993 pass is run last so that we have as much time as possible to prove 6994 that the statement is not reachable. It is located in 'tree-cfg.c' 6995 and is described by 'pass_warn_function_return'. 6996 6997 * Leave static single assignment form 6998 6999 This pass rewrites the function such that it is in normal form. At 7000 the same time, we eliminate as many single-use temporaries as 7001 possible, so the intermediate language is no longer GIMPLE, but 7002 GENERIC. The pass is located in 'tree-outof-ssa.c' and is 7003 described by 'pass_del_ssa'. 7004 7005 * Merge PHI nodes that feed into one another 7006 7007 This is part of the CFG cleanup passes. It attempts to join PHI 7008 nodes from a forwarder CFG block into another block with PHI nodes. 7009 The pass is located in 'tree-cfgcleanup.c' and is described by 7010 'pass_merge_phi'. 7011 7012 * Return value optimization 7013 7014 If a function always returns the same local variable, and that 7015 local variable is an aggregate type, then the variable is replaced 7016 with the return value for the function (i.e., the function's 7017 DECL_RESULT). This is equivalent to the C++ named return value 7018 optimization applied to GIMPLE. The pass is located in 7019 'tree-nrv.c' and is described by 'pass_nrv'. 7020 7021 * Return slot optimization 7022 7023 If a function returns a memory object and is called as 'var = 7024 foo()', this pass tries to change the call so that the address of 7025 'var' is sent to the caller to avoid an extra memory copy. This 7026 pass is located in 'tree-nrv.c' and is described by 7027 'pass_return_slot'. 7028 7029 * Optimize calls to '__builtin_object_size' 7030 7031 This is a propagation pass similar to CCP that tries to remove 7032 calls to '__builtin_object_size' when the size of the object can be 7033 computed at compile-time. This pass is located in 7034 'tree-object-size.c' and is described by 'pass_object_sizes'. 7035 7036 * Loop invariant motion 7037 7038 This pass removes expensive loop-invariant computations out of 7039 loops. The pass is located in 'tree-ssa-loop.c' and described by 7040 'pass_lim'. 7041 7042 * Loop nest optimizations 7043 7044 This is a family of loop transformations that works on loop nests. 7045 It includes loop interchange, scaling, skewing and reversal and 7046 they are all geared to the optimization of data locality in array 7047 traversals and the removal of dependencies that hamper 7048 optimizations such as loop parallelization and vectorization. The 7049 pass is located in 'tree-loop-linear.c' and described by 7050 'pass_linear_transform'. 7051 7052 * Removal of empty loops 7053 7054 This pass removes loops with no code in them. The pass is located 7055 in 'tree-ssa-loop-ivcanon.c' and described by 'pass_empty_loop'. 7056 7057 * Unrolling of small loops 7058 7059 This pass completely unrolls loops with few iterations. The pass 7060 is located in 'tree-ssa-loop-ivcanon.c' and described by 7061 'pass_complete_unroll'. 7062 7063 * Predictive commoning 7064 7065 This pass makes the code reuse the computations from the previous 7066 iterations of the loops, especially loads and stores to memory. It 7067 does so by storing the values of these computations to a bank of 7068 temporary variables that are rotated at the end of loop. To avoid 7069 the need for this rotation, the loop is then unrolled and the 7070 copies of the loop body are rewritten to use the appropriate 7071 version of the temporary variable. This pass is located in 7072 'tree-predcom.c' and described by 'pass_predcom'. 7073 7074 * Array prefetching 7075 7076 This pass issues prefetch instructions for array references inside 7077 loops. The pass is located in 'tree-ssa-loop-prefetch.c' and 7078 described by 'pass_loop_prefetch'. 7079 7080 * Reassociation 7081 7082 This pass rewrites arithmetic expressions to enable optimizations 7083 that operate on them, like redundancy elimination and 7084 vectorization. The pass is located in 'tree-ssa-reassoc.c' and 7085 described by 'pass_reassoc'. 7086 7087 * Optimization of 'stdarg' functions 7088 7089 This pass tries to avoid the saving of register arguments into the 7090 stack on entry to 'stdarg' functions. If the function doesn't use 7091 any 'va_start' macros, no registers need to be saved. If 7092 'va_start' macros are used, the 'va_list' variables don't escape 7093 the function, it is only necessary to save registers that will be 7094 used in 'va_arg' macros. For instance, if 'va_arg' is only used 7095 with integral types in the function, floating point registers don't 7096 need to be saved. This pass is located in 'tree-stdarg.c' and 7097 described by 'pass_stdarg'. 7098 7099 7100File: gccint.info, Node: RTL passes, Next: Optimization info, Prev: Tree SSA passes, Up: Passes 7101 71029.6 RTL passes 7103============== 7104 7105The following briefly describes the RTL generation and optimization 7106passes that are run after the Tree optimization passes. 7107 7108 * RTL generation 7109 7110 The source files for RTL generation include 'stmt.c', 'calls.c', 7111 'expr.c', 'explow.c', 'expmed.c', 'function.c', 'optabs.c' and 7112 'emit-rtl.c'. Also, the file 'insn-emit.c', generated from the 7113 machine description by the program 'genemit', is used in this pass. 7114 The header file 'expr.h' is used for communication within this 7115 pass. 7116 7117 The header files 'insn-flags.h' and 'insn-codes.h', generated from 7118 the machine description by the programs 'genflags' and 'gencodes', 7119 tell this pass which standard names are available for use and which 7120 patterns correspond to them. 7121 7122 * Generation of exception landing pads 7123 7124 This pass generates the glue that handles communication between the 7125 exception handling library routines and the exception handlers 7126 within the function. Entry points in the function that are invoked 7127 by the exception handling library are called "landing pads". The 7128 code for this pass is located in 'except.c'. 7129 7130 * Control flow graph cleanup 7131 7132 This pass removes unreachable code, simplifies jumps to next, jumps 7133 to jump, jumps across jumps, etc. The pass is run multiple times. 7134 For historical reasons, it is occasionally referred to as the "jump 7135 optimization pass". The bulk of the code for this pass is in 7136 'cfgcleanup.c', and there are support routines in 'cfgrtl.c' and 7137 'jump.c'. 7138 7139 * Forward propagation of single-def values 7140 7141 This pass attempts to remove redundant computation by substituting 7142 variables that come from a single definition, and seeing if the 7143 result can be simplified. It performs copy propagation and 7144 addressing mode selection. The pass is run twice, with values 7145 being propagated into loops only on the second run. The code is 7146 located in 'fwprop.c'. 7147 7148 * Common subexpression elimination 7149 7150 This pass removes redundant computation within basic blocks, and 7151 optimizes addressing modes based on cost. The pass is run twice. 7152 The code for this pass is located in 'cse.c'. 7153 7154 * Global common subexpression elimination 7155 7156 This pass performs two different types of GCSE depending on whether 7157 you are optimizing for size or not (LCM based GCSE tends to 7158 increase code size for a gain in speed, while Morel-Renvoise based 7159 GCSE does not). When optimizing for size, GCSE is done using 7160 Morel-Renvoise Partial Redundancy Elimination, with the exception 7161 that it does not try to move invariants out of loops--that is left 7162 to the loop optimization pass. If MR PRE GCSE is done, code 7163 hoisting (aka unification) is also done, as well as load motion. 7164 If you are optimizing for speed, LCM (lazy code motion) based GCSE 7165 is done. LCM is based on the work of Knoop, Ruthing, and Steffen. 7166 LCM based GCSE also does loop invariant code motion. We also 7167 perform load and store motion when optimizing for speed. 7168 Regardless of which type of GCSE is used, the GCSE pass also 7169 performs global constant and copy propagation. The source file for 7170 this pass is 'gcse.c', and the LCM routines are in 'lcm.c'. 7171 7172 * Loop optimization 7173 7174 This pass performs several loop related optimizations. The source 7175 files 'cfgloopanal.c' and 'cfgloopmanip.c' contain generic loop 7176 analysis and manipulation code. Initialization and finalization of 7177 loop structures is handled by 'loop-init.c'. A loop invariant 7178 motion pass is implemented in 'loop-invariant.c'. Basic block 7179 level optimizations--unrolling, and peeling loops-- are implemented 7180 in 'loop-unroll.c'. Replacing of the exit condition of loops by 7181 special machine-dependent instructions is handled by 7182 'loop-doloop.c'. 7183 7184 * Jump bypassing 7185 7186 This pass is an aggressive form of GCSE that transforms the control 7187 flow graph of a function by propagating constants into conditional 7188 branch instructions. The source file for this pass is 'gcse.c'. 7189 7190 * If conversion 7191 7192 This pass attempts to replace conditional branches and surrounding 7193 assignments with arithmetic, boolean value producing comparison 7194 instructions, and conditional move instructions. In the very last 7195 invocation after reload/LRA, it will generate predicated 7196 instructions when supported by the target. The code is located in 7197 'ifcvt.c'. 7198 7199 * Web construction 7200 7201 This pass splits independent uses of each pseudo-register. This 7202 can improve effect of the other transformation, such as CSE or 7203 register allocation. The code for this pass is located in 'web.c'. 7204 7205 * Instruction combination 7206 7207 This pass attempts to combine groups of two or three instructions 7208 that are related by data flow into single instructions. It 7209 combines the RTL expressions for the instructions by substitution, 7210 simplifies the result using algebra, and then attempts to match the 7211 result against the machine description. The code is located in 7212 'combine.c'. 7213 7214 * Mode switching optimization 7215 7216 This pass looks for instructions that require the processor to be 7217 in a specific "mode" and minimizes the number of mode changes 7218 required to satisfy all users. What these modes are, and what they 7219 apply to are completely target-specific. The code for this pass is 7220 located in 'mode-switching.c'. 7221 7222 * Modulo scheduling 7223 7224 This pass looks at innermost loops and reorders their instructions 7225 by overlapping different iterations. Modulo scheduling is 7226 performed immediately before instruction scheduling. The code for 7227 this pass is located in 'modulo-sched.c'. 7228 7229 * Instruction scheduling 7230 7231 This pass looks for instructions whose output will not be available 7232 by the time that it is used in subsequent instructions. Memory 7233 loads and floating point instructions often have this behavior on 7234 RISC machines. It re-orders instructions within a basic block to 7235 try to separate the definition and use of items that otherwise 7236 would cause pipeline stalls. This pass is performed twice, before 7237 and after register allocation. The code for this pass is located 7238 in 'haifa-sched.c', 'sched-deps.c', 'sched-ebb.c', 'sched-rgn.c' 7239 and 'sched-vis.c'. 7240 7241 * Register allocation 7242 7243 These passes make sure that all occurrences of pseudo registers are 7244 eliminated, either by allocating them to a hard register, replacing 7245 them by an equivalent expression (e.g. a constant) or by placing 7246 them on the stack. This is done in several subpasses: 7247 7248 * The integrated register allocator (IRA). It is called 7249 integrated because coalescing, register live range splitting, 7250 and hard register preferencing are done on-the-fly during 7251 coloring. It also has better integration with the reload/LRA 7252 pass. Pseudo-registers spilled by the allocator or the 7253 reload/LRA have still a chance to get hard-registers if the 7254 reload/LRA evicts some pseudo-registers from hard-registers. 7255 The allocator helps to choose better pseudos for spilling 7256 based on their live ranges and to coalesce stack slots 7257 allocated for the spilled pseudo-registers. IRA is a regional 7258 register allocator which is transformed into Chaitin-Briggs 7259 allocator if there is one region. By default, IRA chooses 7260 regions using register pressure but the user can force it to 7261 use one region or regions corresponding to all loops. 7262 7263 Source files of the allocator are 'ira.c', 'ira-build.c', 7264 'ira-costs.c', 'ira-conflicts.c', 'ira-color.c', 'ira-emit.c', 7265 'ira-lives', plus header files 'ira.h' and 'ira-int.h' used 7266 for the communication between the allocator and the rest of 7267 the compiler and between the IRA files. 7268 7269 * Reloading. This pass renumbers pseudo registers with the 7270 hardware registers numbers they were allocated. Pseudo 7271 registers that did not get hard registers are replaced with 7272 stack slots. Then it finds instructions that are invalid 7273 because a value has failed to end up in a register, or has 7274 ended up in a register of the wrong kind. It fixes up these 7275 instructions by reloading the problematical values temporarily 7276 into registers. Additional instructions are generated to do 7277 the copying. 7278 7279 The reload pass also optionally eliminates the frame pointer 7280 and inserts instructions to save and restore call-clobbered 7281 registers around calls. 7282 7283 Source files are 'reload.c' and 'reload1.c', plus the header 7284 'reload.h' used for communication between them. 7285 7286 * This pass is a modern replacement of the reload pass. Source 7287 files are 'lra.c', 'lra-assign.c', 'lra-coalesce.c', 7288 'lra-constraints.c', 'lra-eliminations.c', 'lra-lives.c', 7289 'lra-remat.c', 'lra-spills.c', the header 'lra-int.h' used for 7290 communication between them, and the header 'lra.h' used for 7291 communication between LRA and the rest of compiler. 7292 7293 Unlike the reload pass, intermediate LRA decisions are 7294 reflected in RTL as much as possible. This reduces the number 7295 of target-dependent macros and hooks, leaving instruction 7296 constraints as the primary source of control. 7297 7298 LRA is run on targets for which TARGET_LRA_P returns true. 7299 7300 * Basic block reordering 7301 7302 This pass implements profile guided code positioning. If profile 7303 information is not available, various types of static analysis are 7304 performed to make the predictions normally coming from the profile 7305 feedback (IE execution frequency, branch probability, etc). It is 7306 implemented in the file 'bb-reorder.c', and the various prediction 7307 routines are in 'predict.c'. 7308 7309 * Variable tracking 7310 7311 This pass computes where the variables are stored at each position 7312 in code and generates notes describing the variable locations to 7313 RTL code. The location lists are then generated according to these 7314 notes to debug information if the debugging information format 7315 supports location lists. The code is located in 'var-tracking.c'. 7316 7317 * Delayed branch scheduling 7318 7319 This optional pass attempts to find instructions that can go into 7320 the delay slots of other instructions, usually jumps and calls. 7321 The code for this pass is located in 'reorg.c'. 7322 7323 * Branch shortening 7324 7325 On many RISC machines, branch instructions have a limited range. 7326 Thus, longer sequences of instructions must be used for long 7327 branches. In this pass, the compiler figures out what how far each 7328 instruction will be from each other instruction, and therefore 7329 whether the usual instructions, or the longer sequences, must be 7330 used for each branch. The code for this pass is located in 7331 'final.c'. 7332 7333 * Register-to-stack conversion 7334 7335 Conversion from usage of some hard registers to usage of a register 7336 stack may be done at this point. Currently, this is supported only 7337 for the floating-point registers of the Intel 80387 coprocessor. 7338 The code for this pass is located in 'reg-stack.c'. 7339 7340 * Final 7341 7342 This pass outputs the assembler code for the function. The source 7343 files are 'final.c' plus 'insn-output.c'; the latter is generated 7344 automatically from the machine description by the tool 'genoutput'. 7345 The header file 'conditions.h' is used for communication between 7346 these files. 7347 7348 * Debugging information output 7349 7350 This is run after final because it must output the stack slot 7351 offsets for pseudo registers that did not get hard registers. 7352 Source files are 'dbxout.c' for DBX symbol table format, 'sdbout.c' 7353 for SDB symbol table format, 'dwarfout.c' for DWARF symbol table 7354 format, files 'dwarf2out.c' and 'dwarf2asm.c' for DWARF2 symbol 7355 table format, and 'vmsdbgout.c' for VMS debug symbol table format. 7356 7357 7358File: gccint.info, Node: Optimization info, Prev: RTL passes, Up: Passes 7359 73609.7 Optimization info 7361===================== 7362 7363This section is describes dump infrastructure which is common to both 7364pass dumps as well as optimization dumps. The goal for this 7365infrastructure is to provide both gcc developers and users detailed 7366information about various compiler transformations and optimizations. 7367 7368* Menu: 7369 7370* Dump setup:: Setup of optimization dumps. 7371* Optimization groups:: Groups made up of optimization passes. 7372* Dump files and streams:: Dump output file names and streams. 7373* Dump output verbosity:: How much information to dump. 7374* Dump types:: Various types of dump functions. 7375* Dump examples:: Sample usage. 7376 7377 7378File: gccint.info, Node: Dump setup, Next: Optimization groups, Up: Optimization info 7379 73809.7.1 Dump setup 7381---------------- 7382 7383A dump_manager class is defined in 'dumpfile.h'. Various passes 7384register dumping pass-specific information via 'dump_register' in 7385'passes.c'. During the registration, an optimization pass can select 7386its optimization group (*note Optimization groups::). After that 7387optimization information corresponding to the entire group (presumably 7388from multiple passes) can be output via command-line switches. Note 7389that if a pass does not fit into any of the pre-defined groups, it can 7390select 'OPTGROUP_NONE'. 7391 7392 Note that in general, a pass need not know its dump output file name, 7393whether certain flags are enabled, etc. However, for legacy reasons, 7394passes could also call 'dump_begin' which returns a stream in case the 7395particular pass has optimization dumps enabled. A pass could call 7396'dump_end' when the dump has ended. These methods should go away once 7397all the passes are converted to use the new dump infrastructure. 7398 7399 The recommended way to setup the dump output is via 'dump_start' and 7400'dump_end'. 7401 7402 7403File: gccint.info, Node: Optimization groups, Next: Dump files and streams, Prev: Dump setup, Up: Optimization info 7404 74059.7.2 Optimization groups 7406------------------------- 7407 7408The optimization passes are grouped into several categories. Currently 7409defined categories in 'dumpfile.h' are 7410 7411'OPTGROUP_IPA' 7412 IPA optimization passes. Enabled by '-ipa' 7413 7414'OPTGROUP_LOOP' 7415 Loop optimization passes. Enabled by '-loop'. 7416 7417'OPTGROUP_INLINE' 7418 Inlining passes. Enabled by '-inline'. 7419 7420'OPTGROUP_VEC' 7421 Vectorization passes. Enabled by '-vec'. 7422 7423'OPTGROUP_OTHER' 7424 All other optimization passes which do not fall into one of the 7425 above. 7426 7427'OPTGROUP_ALL' 7428 All optimization passes. Enabled by '-all'. 7429 7430 By using groups a user could selectively enable optimization 7431information only for a group of passes. By default, the optimization 7432information for all the passes is dumped. 7433 7434 7435File: gccint.info, Node: Dump files and streams, Next: Dump output verbosity, Prev: Optimization groups, Up: Optimization info 7436 74379.7.3 Dump files and streams 7438---------------------------- 7439 7440There are two separate output streams available for outputting 7441optimization information from passes. Note that both these streams 7442accept 'stderr' and 'stdout' as valid streams and thus it is possible to 7443dump output to standard output or error. This is specially handy for 7444outputting all available information in a single file by redirecting 7445'stderr'. 7446 7447'pstream' 7448 This stream is for pass-specific dump output. For example, 7449 '-fdump-tree-vect=foo.v' dumps tree vectorization pass output into 7450 the given file name 'foo.v'. If the file name is not provided, the 7451 default file name is based on the source file and pass number. 7452 Note that one could also use special file names 'stdout' and 7453 'stderr' for dumping to standard output and standard error 7454 respectively. 7455 7456'alt_stream' 7457 This steam is used for printing optimization specific output in 7458 response to the '-fopt-info'. Again a file name can be given. If 7459 the file name is not given, it defaults to 'stderr'. 7460 7461 7462File: gccint.info, Node: Dump output verbosity, Next: Dump types, Prev: Dump files and streams, Up: Optimization info 7463 74649.7.4 Dump output verbosity 7465--------------------------- 7466 7467The dump verbosity has the following options 7468 7469'optimized' 7470 Print information when an optimization is successfully applied. It 7471 is up to a pass to decide which information is relevant. For 7472 example, the vectorizer passes print the source location of loops 7473 which got successfully vectorized. 7474 7475'missed' 7476 Print information about missed optimizations. Individual passes 7477 control which information to include in the output. For example, 7478 7479 gcc -O2 -ftree-vectorize -fopt-info-vec-missed 7480 7481 will print information about missed optimization opportunities from 7482 vectorization passes on stderr. 7483 7484'note' 7485 Print verbose information about optimizations, such as certain 7486 transformations, more detailed messages about decisions etc. 7487 7488'all' 7489 Print detailed optimization information. This includes OPTIMIZED, 7490 MISSED, and NOTE. 7491 7492 7493File: gccint.info, Node: Dump types, Next: Dump examples, Prev: Dump output verbosity, Up: Optimization info 7494 74959.7.5 Dump types 7496---------------- 7497 7498'dump_printf' 7499 7500 This is a generic method for doing formatted output. It takes an 7501 additional argument 'dump_kind' which signifies the type of dump. 7502 This method outputs information only when the dumps are enabled for 7503 this particular 'dump_kind'. Note that the caller doesn't need to 7504 know if the particular dump is enabled or not, or even the file 7505 name. The caller only needs to decide which dump output 7506 information is relevant, and under what conditions. This 7507 determines the associated flags. 7508 7509 Consider the following example from 'loop-unroll.c' where an 7510 informative message about a loop (along with its location) is 7511 printed when any of the following flags is enabled 7512 7513 - optimization messages 7514 - RTL dumps 7515 - detailed dumps 7516 7517 int report_flags = MSG_OPTIMIZED_LOCATIONS | TDF_RTL | TDF_DETAILS; 7518 dump_printf_loc (report_flags, locus, 7519 "loop turned into non-loop; it never loops.\n"); 7520 7521'dump_basic_block' 7522 Output basic block. 7523'dump_generic_expr' 7524 Output generic expression. 7525'dump_gimple_stmt' 7526 Output gimple statement. 7527 7528 Note that the above methods also have variants prefixed with 7529 '_loc', such as 'dump_printf_loc', which are similar except they 7530 also output the source location information. 7531 7532 7533File: gccint.info, Node: Dump examples, Prev: Dump types, Up: Optimization info 7534 75359.7.6 Dump examples 7536------------------- 7537 7538 gcc -O3 -fopt-info-missed=missed.all 7539 7540 outputs missed optimization report from all the passes into 7541'missed.all'. 7542 7543 As another example, 7544 gcc -O3 -fopt-info-inline-optimized-missed=inline.txt 7545 7546 will output information about missed optimizations as well as optimized 7547locations from all the inlining passes into 'inline.txt'. 7548 7549 If the FILENAME is provided, then the dumps from all the applicable 7550optimizations are concatenated into the 'filename'. Otherwise the dump 7551is output onto 'stderr'. If OPTIONS is omitted, it defaults to 7552'all-all', which means dump all available optimization info from all the 7553passes. In the following example, all optimization info is output on to 7554'stderr'. 7555 7556 gcc -O3 -fopt-info 7557 7558 Note that '-fopt-info-vec-missed' behaves the same as 7559'-fopt-info-missed-vec'. 7560 7561 As another example, consider 7562 7563 gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt 7564 7565 Here the two output file names 'vec.miss' and 'loop.opt' are in 7566conflict since only one output file is allowed. In this case, only the 7567first option takes effect and the subsequent options are ignored. Thus 7568only the 'vec.miss' is produced which containts dumps from the 7569vectorizer about missed opportunities. 7570 7571 7572File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: Passes, Up: Top 7573 757410 GENERIC 7575********** 7576 7577The purpose of GENERIC is simply to provide a language-independent way 7578of representing an entire function in trees. To this end, it was 7579necessary to add a few new tree codes to the back end, but almost 7580everything was already there. If you can express it with the codes in 7581'gcc/tree.def', it's GENERIC. 7582 7583 Early on, there was a great deal of debate about how to think about 7584statements in a tree IL. In GENERIC, a statement is defined as any 7585expression whose value, if any, is ignored. A statement will always 7586have 'TREE_SIDE_EFFECTS' set (or it will be discarded), but a 7587non-statement expression may also have side effects. A 'CALL_EXPR', for 7588instance. 7589 7590 It would be possible for some local optimizations to work on the 7591GENERIC form of a function; indeed, the adapted tree inliner works fine 7592on GENERIC, but the current compiler performs inlining after lowering to 7593GIMPLE (a restricted form described in the next section). Indeed, 7594currently the frontends perform this lowering before handing off to 7595'tree_rest_of_compilation', but this seems inelegant. 7596 7597* Menu: 7598 7599* Deficiencies:: Topics net yet covered in this document. 7600* Tree overview:: All about 'tree's. 7601* Types:: Fundamental and aggregate types. 7602* Declarations:: Type declarations and variables. 7603* Attributes:: Declaration and type attributes. 7604* Expressions: Expression trees. Operating on data. 7605* Statements:: Control flow and related trees. 7606* Functions:: Function bodies, linkage, and other aspects. 7607* Language-dependent trees:: Topics and trees specific to language front ends. 7608* C and C++ Trees:: Trees specific to C and C++. 7609* Java Trees:: Trees specific to Java. 7610 7611 7612File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC 7613 761410.1 Deficiencies 7615================= 7616 7617There are many places in which this document is incomplet and incorrekt. 7618It is, as of yet, only _preliminary_ documentation. 7619 7620 7621File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC 7622 762310.2 Overview 7624============= 7625 7626The central data structure used by the internal representation is the 7627'tree'. These nodes, while all of the C type 'tree', are of many 7628varieties. A 'tree' is a pointer type, but the object to which it 7629points may be of a variety of types. From this point forward, we will 7630refer to trees in ordinary type, rather than in 'this font', except when 7631talking about the actual C type 'tree'. 7632 7633 You can tell what kind of node a particular tree is by using the 7634'TREE_CODE' macro. Many, many macros take trees as input and return 7635trees as output. However, most macros require a certain kind of tree 7636node as input. In other words, there is a type-system for trees, but it 7637is not reflected in the C type-system. 7638 7639 For safety, it is useful to configure GCC with '--enable-checking'. 7640Although this results in a significant performance penalty (since all 7641tree types are checked at run-time), and is therefore inappropriate in a 7642release version, it is extremely helpful during the development process. 7643 7644 Many macros behave as predicates. Many, although not all, of these 7645predicates end in '_P'. Do not rely on the result type of these macros 7646being of any particular type. You may, however, rely on the fact that 7647the type can be compared to '0', so that statements like 7648 if (TEST_P (t) && !TEST_P (y)) 7649 x = 1; 7650and 7651 int i = (TEST_P (t) != 0); 7652are legal. Macros that return 'int' values now may be changed to return 7653'tree' values, or other pointers in the future. Even those that 7654continue to return 'int' may return multiple nonzero codes where 7655previously they returned only zero and one. Therefore, you should not 7656write code like 7657 if (TEST_P (t) == 1) 7658as this code is not guaranteed to work correctly in the future. 7659 7660 You should not take the address of values returned by the macros or 7661functions described here. In particular, no guarantee is given that the 7662values are lvalues. 7663 7664 In general, the names of macros are all in uppercase, while the names 7665of functions are entirely in lowercase. There are rare exceptions to 7666this rule. You should assume that any macro or function whose name is 7667made up entirely of uppercase letters may evaluate its arguments more 7668than once. You may assume that a macro or function whose name is made 7669up entirely of lowercase letters will evaluate its arguments only once. 7670 7671 The 'error_mark_node' is a special tree. Its tree code is 7672'ERROR_MARK', but since there is only ever one node with that code, the 7673usual practice is to compare the tree against 'error_mark_node'. (This 7674test is just a test for pointer equality.) If an error has occurred 7675during front-end processing the flag 'errorcount' will be set. If the 7676front end has encountered code it cannot handle, it will issue a message 7677to the user and set 'sorrycount'. When these flags are set, any macro 7678or function which normally returns a tree of a particular kind may 7679instead return the 'error_mark_node'. Thus, if you intend to do any 7680processing of erroneous code, you must be prepared to deal with the 7681'error_mark_node'. 7682 7683 Occasionally, a particular tree slot (like an operand to an expression, 7684or a particular field in a declaration) will be referred to as "reserved 7685for the back end". These slots are used to store RTL when the tree is 7686converted to RTL for use by the GCC back end. However, if that process 7687is not taking place (e.g., if the front end is being hooked up to an 7688intelligent editor), then those slots may be used by the back end 7689presently in use. 7690 7691 If you encounter situations that do not match this documentation, such 7692as tree nodes of types not mentioned here, or macros documented to 7693return entities of a particular kind that instead return entities of 7694some different kind, you have found a bug, either in the front end or in 7695the documentation. Please report these bugs as you would any other bug. 7696 7697* Menu: 7698 7699* Macros and Functions::Macros and functions that can be used with all trees. 7700* Identifiers:: The names of things. 7701* Containers:: Lists and vectors. 7702 7703 7704File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 7705 770610.2.1 Trees 7707------------ 7708 7709All GENERIC trees have two fields in common. First, 'TREE_CHAIN' is a 7710pointer that can be used as a singly-linked list to other trees. The 7711other is 'TREE_TYPE'. Many trees store the type of an expression or 7712declaration in this field. 7713 7714 These are some other functions for handling trees: 7715 7716'tree_size' 7717 Return the number of bytes a tree takes. 7718 7719'build0' 7720'build1' 7721'build2' 7722'build3' 7723'build4' 7724'build5' 7725'build6' 7726 7727 These functions build a tree and supply values to put in each 7728 parameter. The basic signature is 'code, type, [operands]'. 7729 'code' is the 'TREE_CODE', and 'type' is a tree representing the 7730 'TREE_TYPE'. These are followed by the operands, each of which is 7731 also a tree. 7732 7733 7734File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 7735 773610.2.2 Identifiers 7737------------------ 7738 7739An 'IDENTIFIER_NODE' represents a slightly more general concept than the 7740standard C or C++ concept of identifier. In particular, an 7741'IDENTIFIER_NODE' may contain a '$', or other extraordinary characters. 7742 7743 There are never two distinct 'IDENTIFIER_NODE's representing the same 7744identifier. Therefore, you may use pointer equality to compare 7745'IDENTIFIER_NODE's, rather than using a routine like 'strcmp'. Use 7746'get_identifier' to obtain the unique 'IDENTIFIER_NODE' for a supplied 7747string. 7748 7749 You can use the following macros to access identifiers: 7750'IDENTIFIER_POINTER' 7751 The string represented by the identifier, represented as a 'char*'. 7752 This string is always 'NUL'-terminated, and contains no embedded 7753 'NUL' characters. 7754 7755'IDENTIFIER_LENGTH' 7756 The length of the string returned by 'IDENTIFIER_POINTER', not 7757 including the trailing 'NUL'. This value of 'IDENTIFIER_LENGTH 7758 (x)' is always the same as 'strlen (IDENTIFIER_POINTER (x))'. 7759 7760'IDENTIFIER_OPNAME_P' 7761 This predicate holds if the identifier represents the name of an 7762 overloaded operator. In this case, you should not depend on the 7763 contents of either the 'IDENTIFIER_POINTER' or the 7764 'IDENTIFIER_LENGTH'. 7765 7766'IDENTIFIER_TYPENAME_P' 7767 This predicate holds if the identifier represents the name of a 7768 user-defined conversion operator. In this case, the 'TREE_TYPE' of 7769 the 'IDENTIFIER_NODE' holds the type to which the conversion 7770 operator converts. 7771 7772 7773File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 7774 777510.2.3 Containers 7776----------------- 7777 7778Two common container data structures can be represented directly with 7779tree nodes. A 'TREE_LIST' is a singly linked list containing two trees 7780per node. These are the 'TREE_PURPOSE' and 'TREE_VALUE' of each node. 7781(Often, the 'TREE_PURPOSE' contains some kind of tag, or additional 7782information, while the 'TREE_VALUE' contains the majority of the 7783payload. In other cases, the 'TREE_PURPOSE' is simply 'NULL_TREE', 7784while in still others both the 'TREE_PURPOSE' and 'TREE_VALUE' are of 7785equal stature.) Given one 'TREE_LIST' node, the next node is found by 7786following the 'TREE_CHAIN'. If the 'TREE_CHAIN' is 'NULL_TREE', then 7787you have reached the end of the list. 7788 7789 A 'TREE_VEC' is a simple vector. The 'TREE_VEC_LENGTH' is an integer 7790(not a tree) giving the number of nodes in the vector. The nodes 7791themselves are accessed using the 'TREE_VEC_ELT' macro, which takes two 7792arguments. The first is the 'TREE_VEC' in question; the second is an 7793integer indicating which element in the vector is desired. The elements 7794are indexed from zero. 7795 7796 7797File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC 7798 779910.3 Types 7800========== 7801 7802All types have corresponding tree nodes. However, you should not assume 7803that there is exactly one tree node corresponding to each type. There 7804are often multiple nodes corresponding to the same type. 7805 7806 For the most part, different kinds of types have different tree codes. 7807(For example, pointer types use a 'POINTER_TYPE' code while arrays use 7808an 'ARRAY_TYPE' code.) However, pointers to member functions use the 7809'RECORD_TYPE' code. Therefore, when writing a 'switch' statement that 7810depends on the code associated with a particular type, you should take 7811care to handle pointers to member functions under the 'RECORD_TYPE' case 7812label. 7813 7814 The following functions and macros deal with cv-qualification of types: 7815'TYPE_MAIN_VARIANT' 7816 This macro returns the unqualified version of a type. It may be 7817 applied to an unqualified type, but it is not always the identity 7818 function in that case. 7819 7820 A few other macros and functions are usable with all types: 7821'TYPE_SIZE' 7822 The number of bits required to represent the type, represented as 7823 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 7824 'NULL_TREE'. 7825 7826'TYPE_ALIGN' 7827 The alignment of the type, in bits, represented as an 'int'. 7828 7829'TYPE_NAME' 7830 This macro returns a declaration (in the form of a 'TYPE_DECL') for 7831 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 7832 as you might expect, given its name!) You can look at the 7833 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 7834 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 7835 built-in type, the result of a typedef, or a named class type. 7836 7837'TYPE_CANONICAL' 7838 This macro returns the "canonical" type for the given type node. 7839 Canonical types are used to improve performance in the C++ and 7840 Objective-C++ front ends by allowing efficient comparison between 7841 two type nodes in 'same_type_p': if the 'TYPE_CANONICAL' values of 7842 the types are equal, the types are equivalent; otherwise, the types 7843 are not equivalent. The notion of equivalence for canonical types 7844 is the same as the notion of type equivalence in the language 7845 itself. For instance, 7846 7847 When 'TYPE_CANONICAL' is 'NULL_TREE', there is no canonical type 7848 for the given type node. In this case, comparison between this 7849 type and any other type requires the compiler to perform a deep, 7850 "structural" comparison to see if the two type nodes have the same 7851 form and properties. 7852 7853 The canonical type for a node is always the most fundamental type 7854 in the equivalence class of types. For instance, 'int' is its own 7855 canonical type. A typedef 'I' of 'int' will have 'int' as its 7856 canonical type. Similarly, 'I*' and a typedef 'IP' (defined to 7857 'I*') will has 'int*' as their canonical type. When building a new 7858 type node, be sure to set 'TYPE_CANONICAL' to the appropriate 7859 canonical type. If the new type is a compound type (built from 7860 other types), and any of those other types require structural 7861 equality, use 'SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the new 7862 type also requires structural equality. Finally, if for some 7863 reason you cannot guarantee that 'TYPE_CANONICAL' will point to the 7864 canonical type, use 'SET_TYPE_STRUCTURAL_EQUALITY' to make sure 7865 that the new type-and any type constructed based on it-requires 7866 structural equality. If you suspect that the canonical type system 7867 is miscomparing types, pass '--param verify-canonical-types=1' to 7868 the compiler or configure with '--enable-checking' to force the 7869 compiler to verify its canonical-type comparisons against the 7870 structural comparisons; the compiler will then print any warnings 7871 if the canonical types miscompare. 7872 7873'TYPE_STRUCTURAL_EQUALITY_P' 7874 This predicate holds when the node requires structural equality 7875 checks, e.g., when 'TYPE_CANONICAL' is 'NULL_TREE'. 7876 7877'SET_TYPE_STRUCTURAL_EQUALITY' 7878 This macro states that the type node it is given requires 7879 structural equality checks, e.g., it sets 'TYPE_CANONICAL' to 7880 'NULL_TREE'. 7881 7882'same_type_p' 7883 This predicate takes two types as input, and holds if they are the 7884 same type. For example, if one type is a 'typedef' for the other, 7885 or both are 'typedef's for the same type. This predicate also 7886 holds if the two trees given as input are simply copies of one 7887 another; i.e., there is no difference between them at the source 7888 level, but, for whatever reason, a duplicate has been made in the 7889 representation. You should never use '==' (pointer equality) to 7890 compare types; always use 'same_type_p' instead. 7891 7892 Detailed below are the various kinds of types, and the macros that can 7893be used to access them. Although other kinds of types are used 7894elsewhere in G++, the types described here are the only ones that you 7895will encounter while examining the intermediate representation. 7896 7897'VOID_TYPE' 7898 Used to represent the 'void' type. 7899 7900'INTEGER_TYPE' 7901 Used to represent the various integral types, including 'char', 7902 'short', 'int', 'long', and 'long long'. This code is not used for 7903 enumeration types, nor for the 'bool' type. The 'TYPE_PRECISION' 7904 is the number of bits used in the representation, represented as an 7905 'unsigned int'. (Note that in the general case this is not the 7906 same value as 'TYPE_SIZE'; suppose that there were a 24-bit integer 7907 type, but that alignment requirements for the ABI required 32-bit 7908 alignment. Then, 'TYPE_SIZE' would be an 'INTEGER_CST' for 32, 7909 while 'TYPE_PRECISION' would be 24.) The integer type is unsigned 7910 if 'TYPE_UNSIGNED' holds; otherwise, it is signed. 7911 7912 The 'TYPE_MIN_VALUE' is an 'INTEGER_CST' for the smallest integer 7913 that may be represented by this type. Similarly, the 7914 'TYPE_MAX_VALUE' is an 'INTEGER_CST' for the largest integer that 7915 may be represented by this type. 7916 7917'REAL_TYPE' 7918 Used to represent the 'float', 'double', and 'long double' types. 7919 The number of bits in the floating-point representation is given by 7920 'TYPE_PRECISION', as in the 'INTEGER_TYPE' case. 7921 7922'FIXED_POINT_TYPE' 7923 Used to represent the 'short _Fract', '_Fract', 'long _Fract', 7924 'long long _Fract', 'short _Accum', '_Accum', 'long _Accum', and 7925 'long long _Accum' types. The number of bits in the fixed-point 7926 representation is given by 'TYPE_PRECISION', as in the 7927 'INTEGER_TYPE' case. There may be padding bits, fractional bits 7928 and integral bits. The number of fractional bits is given by 7929 'TYPE_FBIT', and the number of integral bits is given by 7930 'TYPE_IBIT'. The fixed-point type is unsigned if 'TYPE_UNSIGNED' 7931 holds; otherwise, it is signed. The fixed-point type is saturating 7932 if 'TYPE_SATURATING' holds; otherwise, it is not saturating. 7933 7934'COMPLEX_TYPE' 7935 Used to represent GCC built-in '__complex__' data types. The 7936 'TREE_TYPE' is the type of the real and imaginary parts. 7937 7938'ENUMERAL_TYPE' 7939 Used to represent an enumeration type. The 'TYPE_PRECISION' gives 7940 (as an 'int'), the number of bits used to represent the type. If 7941 there are no negative enumeration constants, 'TYPE_UNSIGNED' will 7942 hold. The minimum and maximum enumeration constants may be 7943 obtained with 'TYPE_MIN_VALUE' and 'TYPE_MAX_VALUE', respectively; 7944 each of these macros returns an 'INTEGER_CST'. 7945 7946 The actual enumeration constants themselves may be obtained by 7947 looking at the 'TYPE_VALUES'. This macro will return a 7948 'TREE_LIST', containing the constants. The 'TREE_PURPOSE' of each 7949 node will be an 'IDENTIFIER_NODE' giving the name of the constant; 7950 the 'TREE_VALUE' will be an 'INTEGER_CST' giving the value assigned 7951 to that constant. These constants will appear in the order in 7952 which they were declared. The 'TREE_TYPE' of each of these 7953 constants will be the type of enumeration type itself. 7954 7955'BOOLEAN_TYPE' 7956 Used to represent the 'bool' type. 7957 7958'POINTER_TYPE' 7959 Used to represent pointer types, and pointer to data member types. 7960 The 'TREE_TYPE' gives the type to which this type points. 7961 7962'REFERENCE_TYPE' 7963 Used to represent reference types. The 'TREE_TYPE' gives the type 7964 to which this type refers. 7965 7966'FUNCTION_TYPE' 7967 Used to represent the type of non-member functions and of static 7968 member functions. The 'TREE_TYPE' gives the return type of the 7969 function. The 'TYPE_ARG_TYPES' are a 'TREE_LIST' of the argument 7970 types. The 'TREE_VALUE' of each node in this list is the type of 7971 the corresponding argument; the 'TREE_PURPOSE' is an expression for 7972 the default argument value, if any. If the last node in the list 7973 is 'void_list_node' (a 'TREE_LIST' node whose 'TREE_VALUE' is the 7974 'void_type_node'), then functions of this type do not take variable 7975 arguments. Otherwise, they do take a variable number of arguments. 7976 7977 Note that in C (but not in C++) a function declared like 'void f()' 7978 is an unprototyped function taking a variable number of arguments; 7979 the 'TYPE_ARG_TYPES' of such a function will be 'NULL'. 7980 7981'METHOD_TYPE' 7982 Used to represent the type of a non-static member function. Like a 7983 'FUNCTION_TYPE', the return type is given by the 'TREE_TYPE'. The 7984 type of '*this', i.e., the class of which functions of this type 7985 are a member, is given by the 'TYPE_METHOD_BASETYPE'. The 7986 'TYPE_ARG_TYPES' is the parameter list, as for a 'FUNCTION_TYPE', 7987 and includes the 'this' argument. 7988 7989'ARRAY_TYPE' 7990 Used to represent array types. The 'TREE_TYPE' gives the type of 7991 the elements in the array. If the array-bound is present in the 7992 type, the 'TYPE_DOMAIN' is an 'INTEGER_TYPE' whose 'TYPE_MIN_VALUE' 7993 and 'TYPE_MAX_VALUE' will be the lower and upper bounds of the 7994 array, respectively. The 'TYPE_MIN_VALUE' will always be an 7995 'INTEGER_CST' for zero, while the 'TYPE_MAX_VALUE' will be one less 7996 than the number of elements in the array, i.e., the highest value 7997 which may be used to index an element in the array. 7998 7999'RECORD_TYPE' 8000 Used to represent 'struct' and 'class' types, as well as pointers 8001 to member functions and similar constructs in other languages. 8002 'TYPE_FIELDS' contains the items contained in this type, each of 8003 which can be a 'FIELD_DECL', 'VAR_DECL', 'CONST_DECL', or 8004 'TYPE_DECL'. You may not make any assumptions about the ordering 8005 of the fields in the type or whether one or more of them overlap. 8006 8007'UNION_TYPE' 8008 Used to represent 'union' types. Similar to 'RECORD_TYPE' except 8009 that all 'FIELD_DECL' nodes in 'TYPE_FIELD' start at bit position 8010 zero. 8011 8012'QUAL_UNION_TYPE' 8013 Used to represent part of a variant record in Ada. Similar to 8014 'UNION_TYPE' except that each 'FIELD_DECL' has a 'DECL_QUALIFIER' 8015 field, which contains a boolean expression that indicates whether 8016 the field is present in the object. The type will only have one 8017 field, so each field's 'DECL_QUALIFIER' is only evaluated if none 8018 of the expressions in the previous fields in 'TYPE_FIELDS' are 8019 nonzero. Normally these expressions will reference a field in the 8020 outer object using a 'PLACEHOLDER_EXPR'. 8021 8022'LANG_TYPE' 8023 This node is used to represent a language-specific type. The front 8024 end must handle it. 8025 8026'OFFSET_TYPE' 8027 This node is used to represent a pointer-to-data member. For a 8028 data member 'X::m' the 'TYPE_OFFSET_BASETYPE' is 'X' and the 8029 'TREE_TYPE' is the type of 'm'. 8030 8031 There are variables whose values represent some of the basic types. 8032These include: 8033'void_type_node' 8034 A node for 'void'. 8035 8036'integer_type_node' 8037 A node for 'int'. 8038 8039'unsigned_type_node.' 8040 A node for 'unsigned int'. 8041 8042'char_type_node.' 8043 A node for 'char'. 8044It may sometimes be useful to compare one of these variables with a type 8045in hand, using 'same_type_p'. 8046 8047 8048File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC 8049 805010.4 Declarations 8051================= 8052 8053This section covers the various kinds of declarations that appear in the 8054internal representation, except for declarations of functions 8055(represented by 'FUNCTION_DECL' nodes), which are described in *note 8056Functions::. 8057 8058* Menu: 8059 8060* Working with declarations:: Macros and functions that work on 8061declarations. 8062* Internal structure:: How declaration nodes are represented. 8063 8064 8065File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 8066 806710.4.1 Working with declarations 8068-------------------------------- 8069 8070Some macros can be used with any kind of declaration. These include: 8071'DECL_NAME' 8072 This macro returns an 'IDENTIFIER_NODE' giving the name of the 8073 entity. 8074 8075'TREE_TYPE' 8076 This macro returns the type of the entity declared. 8077 8078'EXPR_FILENAME' 8079 This macro returns the name of the file in which the entity was 8080 declared, as a 'char*'. For an entity declared implicitly by the 8081 compiler (like '__builtin_memcpy'), this will be the string 8082 '"<internal>"'. 8083 8084'EXPR_LINENO' 8085 This macro returns the line number at which the entity was 8086 declared, as an 'int'. 8087 8088'DECL_ARTIFICIAL' 8089 This predicate holds if the declaration was implicitly generated by 8090 the compiler. For example, this predicate will hold of an 8091 implicitly declared member function, or of the 'TYPE_DECL' 8092 implicitly generated for a class type. Recall that in C++ code 8093 like: 8094 struct S {}; 8095 is roughly equivalent to C code like: 8096 struct S {}; 8097 typedef struct S S; 8098 The implicitly generated 'typedef' declaration is represented by a 8099 'TYPE_DECL' for which 'DECL_ARTIFICIAL' holds. 8100 8101 The various kinds of declarations include: 8102'LABEL_DECL' 8103 These nodes are used to represent labels in function bodies. For 8104 more information, see *note Functions::. These nodes only appear 8105 in block scopes. 8106 8107'CONST_DECL' 8108 These nodes are used to represent enumeration constants. The value 8109 of the constant is given by 'DECL_INITIAL' which will be an 8110 'INTEGER_CST' with the same type as the 'TREE_TYPE' of the 8111 'CONST_DECL', i.e., an 'ENUMERAL_TYPE'. 8112 8113'RESULT_DECL' 8114 These nodes represent the value returned by a function. When a 8115 value is assigned to a 'RESULT_DECL', that indicates that the value 8116 should be returned, via bitwise copy, by the function. You can use 8117 'DECL_SIZE' and 'DECL_ALIGN' on a 'RESULT_DECL', just as with a 8118 'VAR_DECL'. 8119 8120'TYPE_DECL' 8121 These nodes represent 'typedef' declarations. The 'TREE_TYPE' is 8122 the type declared to have the name given by 'DECL_NAME'. In some 8123 cases, there is no associated name. 8124 8125'VAR_DECL' 8126 These nodes represent variables with namespace or block scope, as 8127 well as static data members. The 'DECL_SIZE' and 'DECL_ALIGN' are 8128 analogous to 'TYPE_SIZE' and 'TYPE_ALIGN'. For a declaration, you 8129 should always use the 'DECL_SIZE' and 'DECL_ALIGN' rather than the 8130 'TYPE_SIZE' and 'TYPE_ALIGN' given by the 'TREE_TYPE', since 8131 special attributes may have been applied to the variable to give it 8132 a particular size and alignment. You may use the predicates 8133 'DECL_THIS_STATIC' or 'DECL_THIS_EXTERN' to test whether the 8134 storage class specifiers 'static' or 'extern' were used to declare 8135 a variable. 8136 8137 If this variable is initialized (but does not require a 8138 constructor), the 'DECL_INITIAL' will be an expression for the 8139 initializer. The initializer should be evaluated, and a bitwise 8140 copy into the variable performed. If the 'DECL_INITIAL' is the 8141 'error_mark_node', there is an initializer, but it is given by an 8142 explicit statement later in the code; no bitwise copy is required. 8143 8144 GCC provides an extension that allows either automatic variables, 8145 or global variables, to be placed in particular registers. This 8146 extension is being used for a particular 'VAR_DECL' if 8147 'DECL_REGISTER' holds for the 'VAR_DECL', and if 8148 'DECL_ASSEMBLER_NAME' is not equal to 'DECL_NAME'. In that case, 8149 'DECL_ASSEMBLER_NAME' is the name of the register into which the 8150 variable will be placed. 8151 8152'PARM_DECL' 8153 Used to represent a parameter to a function. Treat these nodes 8154 similarly to 'VAR_DECL' nodes. These nodes only appear in the 8155 'DECL_ARGUMENTS' for a 'FUNCTION_DECL'. 8156 8157 The 'DECL_ARG_TYPE' for a 'PARM_DECL' is the type that will 8158 actually be used when a value is passed to this function. It may 8159 be a wider type than the 'TREE_TYPE' of the parameter; for example, 8160 the ordinary type might be 'short' while the 'DECL_ARG_TYPE' is 8161 'int'. 8162 8163'DEBUG_EXPR_DECL' 8164 Used to represent an anonymous debug-information temporary created 8165 to hold an expression as it is optimized away, so that its value 8166 can be referenced in debug bind statements. 8167 8168'FIELD_DECL' 8169 These nodes represent non-static data members. The 'DECL_SIZE' and 8170 'DECL_ALIGN' behave as for 'VAR_DECL' nodes. The position of the 8171 field within the parent record is specified by a combination of 8172 three attributes. 'DECL_FIELD_OFFSET' is the position, counting in 8173 bytes, of the 'DECL_OFFSET_ALIGN'-bit sized word containing the bit 8174 of the field closest to the beginning of the structure. 8175 'DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 8176 field within this word; this may be nonzero even for fields that 8177 are not bit-fields, since 'DECL_OFFSET_ALIGN' may be greater than 8178 the natural alignment of the field's type. 8179 8180 If 'DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 8181 bit-field, 'DECL_BIT_FIELD_TYPE' also contains the type that was 8182 originally specified for it, while DECL_TYPE may be a modified type 8183 with lesser precision, according to the size of the bit field. 8184 8185'NAMESPACE_DECL' 8186 Namespaces provide a name hierarchy for other declarations. They 8187 appear in the 'DECL_CONTEXT' of other '_DECL' nodes. 8188 8189 8190File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 8191 819210.4.2 Internal structure 8193------------------------- 8194 8195'DECL' nodes are represented internally as a hierarchy of structures. 8196 8197* Menu: 8198 8199* Current structure hierarchy:: The current DECL node structure 8200hierarchy. 8201* Adding new DECL node types:: How to add a new DECL node to a 8202frontend. 8203 8204 8205File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 8206 820710.4.2.1 Current structure hierarchy 8208.................................... 8209 8210'struct tree_decl_minimal' 8211 This is the minimal structure to inherit from in order for common 8212 'DECL' macros to work. The fields it contains are a unique ID, 8213 source location, context, and name. 8214 8215'struct tree_decl_common' 8216 This structure inherits from 'struct tree_decl_minimal'. It 8217 contains fields that most 'DECL' nodes need, such as a field to 8218 store alignment, machine mode, size, and attributes. 8219 8220'struct tree_field_decl' 8221 This structure inherits from 'struct tree_decl_common'. It is used 8222 to represent 'FIELD_DECL'. 8223 8224'struct tree_label_decl' 8225 This structure inherits from 'struct tree_decl_common'. It is used 8226 to represent 'LABEL_DECL'. 8227 8228'struct tree_translation_unit_decl' 8229 This structure inherits from 'struct tree_decl_common'. It is used 8230 to represent 'TRANSLATION_UNIT_DECL'. 8231 8232'struct tree_decl_with_rtl' 8233 This structure inherits from 'struct tree_decl_common'. It 8234 contains a field to store the low-level RTL associated with a 8235 'DECL' node. 8236 8237'struct tree_result_decl' 8238 This structure inherits from 'struct tree_decl_with_rtl'. It is 8239 used to represent 'RESULT_DECL'. 8240 8241'struct tree_const_decl' 8242 This structure inherits from 'struct tree_decl_with_rtl'. It is 8243 used to represent 'CONST_DECL'. 8244 8245'struct tree_parm_decl' 8246 This structure inherits from 'struct tree_decl_with_rtl'. It is 8247 used to represent 'PARM_DECL'. 8248 8249'struct tree_decl_with_vis' 8250 This structure inherits from 'struct tree_decl_with_rtl'. It 8251 contains fields necessary to store visibility information, as well 8252 as a section name and assembler name. 8253 8254'struct tree_var_decl' 8255 This structure inherits from 'struct tree_decl_with_vis'. It is 8256 used to represent 'VAR_DECL'. 8257 8258'struct tree_function_decl' 8259 This structure inherits from 'struct tree_decl_with_vis'. It is 8260 used to represent 'FUNCTION_DECL'. 8261 8262 8263File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 8264 826510.4.2.2 Adding new DECL node types 8266................................... 8267 8268Adding a new 'DECL' tree consists of the following steps 8269 8270Add a new tree code for the 'DECL' node 8271 For language specific 'DECL' nodes, there is a '.def' file in each 8272 frontend directory where the tree code should be added. For 'DECL' 8273 nodes that are part of the middle-end, the code should be added to 8274 'tree.def'. 8275 8276Create a new structure type for the 'DECL' node 8277 These structures should inherit from one of the existing structures 8278 in the language hierarchy by using that structure as the first 8279 member. 8280 8281 struct tree_foo_decl 8282 { 8283 struct tree_decl_with_vis common; 8284 } 8285 8286 Would create a structure name 'tree_foo_decl' that inherits from 8287 'struct tree_decl_with_vis'. 8288 8289 For language specific 'DECL' nodes, this new structure type should 8290 go in the appropriate '.h' file. For 'DECL' nodes that are part of 8291 the middle-end, the structure type should go in 'tree.h'. 8292 8293Add a member to the tree structure enumerator for the node 8294 For garbage collection and dynamic checking purposes, each 'DECL' 8295 node structure type is required to have a unique enumerator value 8296 specified with it. For language specific 'DECL' nodes, this new 8297 enumerator value should go in the appropriate '.def' file. For 8298 'DECL' nodes that are part of the middle-end, the enumerator values 8299 are specified in 'treestruct.def'. 8300 8301Update 'union tree_node' 8302 In order to make your new structure type usable, it must be added 8303 to 'union tree_node'. For language specific 'DECL' nodes, a new 8304 entry should be added to the appropriate '.h' file of the form 8305 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 8306 For 'DECL' nodes that are part of the middle-end, the additional 8307 member goes directly into 'union tree_node' in 'tree.h'. 8308 8309Update dynamic checking info 8310 In order to be able to check whether accessing a named portion of 8311 'union tree_node' is legal, and whether a certain 'DECL' node 8312 contains one of the enumerated 'DECL' node structures in the 8313 hierarchy, a simple lookup table is used. This lookup table needs 8314 to be kept up to date with the tree structure hierarchy, or else 8315 checking and containment macros will fail inappropriately. 8316 8317 For language specific 'DECL' nodes, their is an 'init_ts' function 8318 in an appropriate '.c' file, which initializes the lookup table. 8319 Code setting up the table for new 'DECL' nodes should be added 8320 there. For each 'DECL' tree code and enumerator value representing 8321 a member of the inheritance hierarchy, the table should contain 1 8322 if that tree code inherits (directly or indirectly) from that 8323 member. Thus, a 'FOO_DECL' node derived from 'struct 8324 decl_with_rtl', and enumerator value 'TS_FOO_DECL', would be set up 8325 as follows 8326 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 8327 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 8328 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 8329 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 8330 8331 For 'DECL' nodes that are part of the middle-end, the setup code 8332 goes into 'tree.c'. 8333 8334Add macros to access any new fields and flags 8335 8336 Each added field or flag should have a macro that is used to access 8337 it, that performs appropriate checking to ensure only the right 8338 type of 'DECL' nodes access the field. 8339 8340 These macros generally take the following form 8341 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 8342 However, if the structure is simply a base class for further 8343 structures, something like the following should be used 8344 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 8345 #define BASE_STRUCT_FIELDNAME(NODE) \ 8346 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 8347 8348 Reading them from the generated 'all-tree.def' file (which in turn 8349 includes all the 'tree.def' files), 'gencheck.c' is used during 8350 GCC's build to generate the '*_CHECK' macros for all tree codes. 8351 8352 8353File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC 8354 835510.5 Attributes in trees 8356======================== 8357 8358Attributes, as specified using the '__attribute__' keyword, are 8359represented internally as a 'TREE_LIST'. The 'TREE_PURPOSE' is the name 8360of the attribute, as an 'IDENTIFIER_NODE'. The 'TREE_VALUE' is a 8361'TREE_LIST' of the arguments of the attribute, if any, or 'NULL_TREE' if 8362there are no arguments; the arguments are stored as the 'TREE_VALUE' of 8363successive entries in the list, and may be identifiers or expressions. 8364The 'TREE_CHAIN' of the attribute is the next attribute in a list of 8365attributes applying to the same declaration or type, or 'NULL_TREE' if 8366there are no further attributes in the list. 8367 8368 Attributes may be attached to declarations and to types; these 8369attributes may be accessed with the following macros. All attributes 8370are stored in this way, and many also cause other changes to the 8371declaration or type or to other internal compiler data structures. 8372 8373 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 8374 This macro returns the attributes on the declaration DECL. 8375 8376 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 8377 This macro returns the attributes on the type TYPE. 8378 8379 8380File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC 8381 838210.6 Expressions 8383================ 8384 8385The internal representation for expressions is for the most part quite 8386straightforward. However, there are a few facts that one must bear in 8387mind. In particular, the expression "tree" is actually a directed 8388acyclic graph. (For example there may be many references to the integer 8389constant zero throughout the source program; many of these will be 8390represented by the same expression node.) You should not rely on 8391certain kinds of node being shared, nor should you rely on certain kinds 8392of nodes being unshared. 8393 8394 The following macros can be used with all expression nodes: 8395 8396'TREE_TYPE' 8397 Returns the type of the expression. This value may not be 8398 precisely the same type that would be given the expression in the 8399 original program. 8400 8401 In what follows, some nodes that one might expect to always have type 8402'bool' are documented to have either integral or boolean type. At some 8403point in the future, the C front end may also make use of this same 8404intermediate representation, and at this point these nodes will 8405certainly have integral type. The previous sentence is not meant to 8406imply that the C++ front end does not or will not give these nodes 8407integral type. 8408 8409 Below, we list the various kinds of expression nodes. Except where 8410noted otherwise, the operands to an expression are accessed using the 8411'TREE_OPERAND' macro. For example, to access the first operand to a 8412binary plus expression 'expr', use: 8413 8414 TREE_OPERAND (expr, 0) 8415 8416 As this example indicates, the operands are zero-indexed. 8417 8418* Menu: 8419 8420* Constants: Constant expressions. 8421* Storage References:: 8422* Unary and Binary Expressions:: 8423* Vectors:: 8424 8425 8426File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees 8427 842810.6.1 Constant expressions 8429--------------------------- 8430 8431The table below begins with constants, moves on to unary expressions, 8432then proceeds to binary expressions, and concludes with various other 8433kinds of expressions: 8434 8435'INTEGER_CST' 8436 These nodes represent integer constants. Note that the type of 8437 these constants is obtained with 'TREE_TYPE'; they are not always 8438 of type 'int'. In particular, 'char' constants are represented 8439 with 'INTEGER_CST' nodes. The value of the integer constant 'e' is 8440 represented in an array of HOST_WIDE_INT. There are enough elements 8441 in the array to represent the value without taking extra elements 8442 for redundant 0s or -1. The number of elements used to represent 8443 'e' is available via 'TREE_INT_CST_NUNITS'. Element 'i' can be 8444 extracted by using 'TREE_INT_CST_ELT (e, i)'. 'TREE_INT_CST_LOW' 8445 is a shorthand for 'TREE_INT_CST_ELT (e, 0)'. 8446 8447 The functions 'tree_fits_shwi_p' and 'tree_fits_uhwi_p' can be used 8448 to tell if the value is small enough to fit in a signed 8449 HOST_WIDE_INT or an unsigned HOST_WIDE_INT respectively. The value 8450 can then be extracted using 'tree_to_shwi' and 'tree_to_uhwi'. 8451 8452'REAL_CST' 8453 8454 FIXME: Talk about how to obtain representations of this constant, 8455 do comparisons, and so forth. 8456 8457'FIXED_CST' 8458 8459 These nodes represent fixed-point constants. The type of these 8460 constants is obtained with 'TREE_TYPE'. 'TREE_FIXED_CST_PTR' 8461 points to a 'struct fixed_value'; 'TREE_FIXED_CST' returns the 8462 structure itself. 'struct fixed_value' contains 'data' with the 8463 size of two 'HOST_BITS_PER_WIDE_INT' and 'mode' as the associated 8464 fixed-point machine mode for 'data'. 8465 8466'COMPLEX_CST' 8467 These nodes are used to represent complex number constants, that is 8468 a '__complex__' whose parts are constant nodes. The 8469 'TREE_REALPART' and 'TREE_IMAGPART' return the real and the 8470 imaginary parts respectively. 8471 8472'VECTOR_CST' 8473 These nodes are used to represent vector constants, whose parts are 8474 constant nodes. Each individual constant node is either an integer 8475 or a double constant node. The first operand is a 'TREE_LIST' of 8476 the constant nodes and is accessed through 'TREE_VECTOR_CST_ELTS'. 8477 8478'STRING_CST' 8479 These nodes represent string-constants. The 'TREE_STRING_LENGTH' 8480 returns the length of the string, as an 'int'. The 8481 'TREE_STRING_POINTER' is a 'char*' containing the string itself. 8482 The string may not be 'NUL'-terminated, and it may contain embedded 8483 'NUL' characters. Therefore, the 'TREE_STRING_LENGTH' includes the 8484 trailing 'NUL' if it is present. 8485 8486 For wide string constants, the 'TREE_STRING_LENGTH' is the number 8487 of bytes in the string, and the 'TREE_STRING_POINTER' points to an 8488 array of the bytes of the string, as represented on the target 8489 system (that is, as integers in the target endianness). Wide and 8490 non-wide string constants are distinguished only by the 'TREE_TYPE' 8491 of the 'STRING_CST'. 8492 8493 FIXME: The formats of string constants are not well-defined when 8494 the target system bytes are not the same width as host system 8495 bytes. 8496 8497 8498File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees 8499 850010.6.2 References to storage 8501---------------------------- 8502 8503'ARRAY_REF' 8504 These nodes represent array accesses. The first operand is the 8505 array; the second is the index. To calculate the address of the 8506 memory accessed, you must scale the index by the size of the type 8507 of the array elements. The type of these expressions must be the 8508 type of a component of the array. The third and fourth operands 8509 are used after gimplification to represent the lower bound and 8510 component size but should not be used directly; call 8511 'array_ref_low_bound' and 'array_ref_element_size' instead. 8512 8513'ARRAY_RANGE_REF' 8514 These nodes represent access to a range (or "slice") of an array. 8515 The operands are the same as that for 'ARRAY_REF' and have the same 8516 meanings. The type of these expressions must be an array whose 8517 component type is the same as that of the first operand. The range 8518 of that array type determines the amount of data these expressions 8519 access. 8520 8521'TARGET_MEM_REF' 8522 These nodes represent memory accesses whose address directly map to 8523 an addressing mode of the target architecture. The first argument 8524 is 'TMR_SYMBOL' and must be a 'VAR_DECL' of an object with a fixed 8525 address. The second argument is 'TMR_BASE' and the third one is 8526 'TMR_INDEX'. The fourth argument is 'TMR_STEP' and must be an 8527 'INTEGER_CST'. The fifth argument is 'TMR_OFFSET' and must be an 8528 'INTEGER_CST'. Any of the arguments may be NULL if the appropriate 8529 component does not appear in the address. Address of the 8530 'TARGET_MEM_REF' is determined in the following way. 8531 8532 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 8533 8534 The sixth argument is the reference to the original memory access, 8535 which is preserved for the purposes of the RTL alias analysis. The 8536 seventh argument is a tag representing the results of tree level 8537 alias analysis. 8538 8539'ADDR_EXPR' 8540 These nodes are used to represent the address of an object. (These 8541 expressions will always have pointer or reference type.) The 8542 operand may be another expression, or it may be a declaration. 8543 8544 As an extension, GCC allows users to take the address of a label. 8545 In this case, the operand of the 'ADDR_EXPR' will be a 8546 'LABEL_DECL'. The type of such an expression is 'void*'. 8547 8548 If the object addressed is not an lvalue, a temporary is created, 8549 and the address of the temporary is used. 8550 8551'INDIRECT_REF' 8552 These nodes are used to represent the object pointed to by a 8553 pointer. The operand is the pointer being dereferenced; it will 8554 always have pointer or reference type. 8555 8556'MEM_REF' 8557 These nodes are used to represent the object pointed to by a 8558 pointer offset by a constant. The first operand is the pointer 8559 being dereferenced; it will always have pointer or reference type. 8560 The second operand is a pointer constant. Its type is specifying 8561 the type to be used for type-based alias analysis. 8562 8563'COMPONENT_REF' 8564 These nodes represent non-static data member accesses. The first 8565 operand is the object (rather than a pointer to it); the second 8566 operand is the 'FIELD_DECL' for the data member. The third operand 8567 represents the byte offset of the field, but should not be used 8568 directly; call 'component_ref_field_offset' instead. 8569 8570 8571File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees 8572 857310.6.3 Unary and Binary Expressions 8574----------------------------------- 8575 8576'NEGATE_EXPR' 8577 These nodes represent unary negation of the single operand, for 8578 both integer and floating-point types. The type of negation can be 8579 determined by looking at the type of the expression. 8580 8581 The behavior of this operation on signed arithmetic overflow is 8582 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 8583 8584'ABS_EXPR' 8585 These nodes represent the absolute value of the single operand, for 8586 both integer and floating-point types. This is typically used to 8587 implement the 'abs', 'labs' and 'llabs' builtins for integer types, 8588 and the 'fabs', 'fabsf' and 'fabsl' builtins for floating point 8589 types. The type of abs operation can be determined by looking at 8590 the type of the expression. 8591 8592 This node is not used for complex types. To represent the modulus 8593 or complex abs of a complex value, use the 'BUILT_IN_CABS', 8594 'BUILT_IN_CABSF' or 'BUILT_IN_CABSL' builtins, as used to implement 8595 the C99 'cabs', 'cabsf' and 'cabsl' built-in functions. 8596 8597'BIT_NOT_EXPR' 8598 These nodes represent bitwise complement, and will always have 8599 integral type. The only operand is the value to be complemented. 8600 8601'TRUTH_NOT_EXPR' 8602 These nodes represent logical negation, and will always have 8603 integral (or boolean) type. The operand is the value being 8604 negated. The type of the operand and that of the result are always 8605 of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 8606 8607'PREDECREMENT_EXPR' 8608'PREINCREMENT_EXPR' 8609'POSTDECREMENT_EXPR' 8610'POSTINCREMENT_EXPR' 8611 These nodes represent increment and decrement expressions. The 8612 value of the single operand is computed, and the operand 8613 incremented or decremented. In the case of 'PREDECREMENT_EXPR' and 8614 'PREINCREMENT_EXPR', the value of the expression is the value 8615 resulting after the increment or decrement; in the case of 8616 'POSTDECREMENT_EXPR' and 'POSTINCREMENT_EXPR' is the value before 8617 the increment or decrement occurs. The type of the operand, like 8618 that of the result, will be either integral, boolean, or 8619 floating-point. 8620 8621'FIX_TRUNC_EXPR' 8622 These nodes represent conversion of a floating-point value to an 8623 integer. The single operand will have a floating-point type, while 8624 the complete expression will have an integral (or boolean) type. 8625 The operand is rounded towards zero. 8626 8627'FLOAT_EXPR' 8628 These nodes represent conversion of an integral (or boolean) value 8629 to a floating-point value. The single operand will have integral 8630 type, while the complete expression will have a floating-point 8631 type. 8632 8633 FIXME: How is the operand supposed to be rounded? Is this 8634 dependent on '-mieee'? 8635 8636'COMPLEX_EXPR' 8637 These nodes are used to represent complex numbers constructed from 8638 two expressions of the same (integer or real) type. The first 8639 operand is the real part and the second operand is the imaginary 8640 part. 8641 8642'CONJ_EXPR' 8643 These nodes represent the conjugate of their operand. 8644 8645'REALPART_EXPR' 8646'IMAGPART_EXPR' 8647 These nodes represent respectively the real and the imaginary parts 8648 of complex numbers (their sole argument). 8649 8650'NON_LVALUE_EXPR' 8651 These nodes indicate that their one and only operand is not an 8652 lvalue. A back end can treat these identically to the single 8653 operand. 8654 8655'NOP_EXPR' 8656 These nodes are used to represent conversions that do not require 8657 any code-generation. For example, conversion of a 'char*' to an 8658 'int*' does not require any code be generated; such a conversion is 8659 represented by a 'NOP_EXPR'. The single operand is the expression 8660 to be converted. The conversion from a pointer to a reference is 8661 also represented with a 'NOP_EXPR'. 8662 8663'CONVERT_EXPR' 8664 These nodes are similar to 'NOP_EXPR's, but are used in those 8665 situations where code may need to be generated. For example, if an 8666 'int*' is converted to an 'int' code may need to be generated on 8667 some platforms. These nodes are never used for C++-specific 8668 conversions, like conversions between pointers to different classes 8669 in an inheritance hierarchy. Any adjustments that need to be made 8670 in such cases are always indicated explicitly. Similarly, a 8671 user-defined conversion is never represented by a 'CONVERT_EXPR'; 8672 instead, the function calls are made explicit. 8673 8674'FIXED_CONVERT_EXPR' 8675 These nodes are used to represent conversions that involve 8676 fixed-point values. For example, from a fixed-point value to 8677 another fixed-point value, from an integer to a fixed-point value, 8678 from a fixed-point value to an integer, from a floating-point value 8679 to a fixed-point value, or from a fixed-point value to a 8680 floating-point value. 8681 8682'LSHIFT_EXPR' 8683'RSHIFT_EXPR' 8684 These nodes represent left and right shifts, respectively. The 8685 first operand is the value to shift; it will always be of integral 8686 type. The second operand is an expression for the number of bits 8687 by which to shift. Right shift should be treated as arithmetic, 8688 i.e., the high-order bits should be zero-filled when the expression 8689 has unsigned type and filled with the sign bit when the expression 8690 has signed type. Note that the result is undefined if the second 8691 operand is larger than or equal to the first operand's type size. 8692 Unlike most nodes, these can have a vector as first operand and a 8693 scalar as second operand. 8694 8695'BIT_IOR_EXPR' 8696'BIT_XOR_EXPR' 8697'BIT_AND_EXPR' 8698 These nodes represent bitwise inclusive or, bitwise exclusive or, 8699 and bitwise and, respectively. Both operands will always have 8700 integral type. 8701 8702'TRUTH_ANDIF_EXPR' 8703'TRUTH_ORIF_EXPR' 8704 These nodes represent logical "and" and logical "or", respectively. 8705 These operators are not strict; i.e., the second operand is 8706 evaluated only if the value of the expression is not determined by 8707 evaluation of the first operand. The type of the operands and that 8708 of the result are always of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 8709 8710'TRUTH_AND_EXPR' 8711'TRUTH_OR_EXPR' 8712'TRUTH_XOR_EXPR' 8713 These nodes represent logical and, logical or, and logical 8714 exclusive or. They are strict; both arguments are always 8715 evaluated. There are no corresponding operators in C or C++, but 8716 the front end will sometimes generate these expressions anyhow, if 8717 it can tell that strictness does not matter. The type of the 8718 operands and that of the result are always of 'BOOLEAN_TYPE' or 8719 'INTEGER_TYPE'. 8720 8721'POINTER_PLUS_EXPR' 8722 This node represents pointer arithmetic. The first operand is 8723 always a pointer/reference type. The second operand is always an 8724 unsigned integer type compatible with sizetype. This is the only 8725 binary arithmetic operand that can operate on pointer types. 8726 8727'PLUS_EXPR' 8728'MINUS_EXPR' 8729'MULT_EXPR' 8730 These nodes represent various binary arithmetic operations. 8731 Respectively, these operations are addition, subtraction (of the 8732 second operand from the first) and multiplication. Their operands 8733 may have either integral or floating type, but there will never be 8734 case in which one operand is of floating type and the other is of 8735 integral type. 8736 8737 The behavior of these operations on signed arithmetic overflow is 8738 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 8739 8740'MULT_HIGHPART_EXPR' 8741 This node represents the "high-part" of a widening multiplication. 8742 For an integral type with B bits of precision, the result is the 8743 most significant B bits of the full 2B product. 8744 8745'RDIV_EXPR' 8746 This node represents a floating point division operation. 8747 8748'TRUNC_DIV_EXPR' 8749'FLOOR_DIV_EXPR' 8750'CEIL_DIV_EXPR' 8751'ROUND_DIV_EXPR' 8752 These nodes represent integer division operations that return an 8753 integer result. 'TRUNC_DIV_EXPR' rounds towards zero, 8754 'FLOOR_DIV_EXPR' rounds towards negative infinity, 'CEIL_DIV_EXPR' 8755 rounds towards positive infinity and 'ROUND_DIV_EXPR' rounds to the 8756 closest integer. Integer division in C and C++ is truncating, i.e. 8757 'TRUNC_DIV_EXPR'. 8758 8759 The behavior of these operations on signed arithmetic overflow, 8760 when dividing the minimum signed integer by minus one, is 8761 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 8762 8763'TRUNC_MOD_EXPR' 8764'FLOOR_MOD_EXPR' 8765'CEIL_MOD_EXPR' 8766'ROUND_MOD_EXPR' 8767 These nodes represent the integer remainder or modulus operation. 8768 The integer modulus of two operands 'a' and 'b' is defined as 'a - 8769 (a/b)*b' where the division calculated using the corresponding 8770 division operator. Hence for 'TRUNC_MOD_EXPR' this definition 8771 assumes division using truncation towards zero, i.e. 8772 'TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 8773 division, i.e. 'TRUNC_MOD_EXPR'. 8774 8775'EXACT_DIV_EXPR' 8776 The 'EXACT_DIV_EXPR' code is used to represent integer divisions 8777 where the numerator is known to be an exact multiple of the 8778 denominator. This allows the backend to choose between the faster 8779 of 'TRUNC_DIV_EXPR', 'CEIL_DIV_EXPR' and 'FLOOR_DIV_EXPR' for the 8780 current target. 8781 8782'LT_EXPR' 8783'LE_EXPR' 8784'GT_EXPR' 8785'GE_EXPR' 8786'EQ_EXPR' 8787'NE_EXPR' 8788 These nodes represent the less than, less than or equal to, greater 8789 than, greater than or equal to, equal, and not equal comparison 8790 operators. The first and second operands will either be both of 8791 integral type, both of floating type or both of vector type. The 8792 result type of these expressions will always be of integral, 8793 boolean or signed integral vector type. These operations return 8794 the result type's zero value for false, the result type's one value 8795 for true, and a vector whose elements are zero (false) or minus one 8796 (true) for vectors. 8797 8798 For floating point comparisons, if we honor IEEE NaNs and either 8799 operand is NaN, then 'NE_EXPR' always returns true and the 8800 remaining operators always return false. On some targets, 8801 comparisons against an IEEE NaN, other than equality and 8802 inequality, may generate a floating point exception. 8803 8804'ORDERED_EXPR' 8805'UNORDERED_EXPR' 8806 These nodes represent non-trapping ordered and unordered comparison 8807 operators. These operations take two floating point operands and 8808 determine whether they are ordered or unordered relative to each 8809 other. If either operand is an IEEE NaN, their comparison is 8810 defined to be unordered, otherwise the comparison is defined to be 8811 ordered. The result type of these expressions will always be of 8812 integral or boolean type. These operations return the result 8813 type's zero value for false, and the result type's one value for 8814 true. 8815 8816'UNLT_EXPR' 8817'UNLE_EXPR' 8818'UNGT_EXPR' 8819'UNGE_EXPR' 8820'UNEQ_EXPR' 8821'LTGT_EXPR' 8822 These nodes represent the unordered comparison operators. These 8823 operations take two floating point operands and determine whether 8824 the operands are unordered or are less than, less than or equal to, 8825 greater than, greater than or equal to, or equal respectively. For 8826 example, 'UNLT_EXPR' returns true if either operand is an IEEE NaN 8827 or the first operand is less than the second. With the possible 8828 exception of 'LTGT_EXPR', all of these operations are guaranteed 8829 not to generate a floating point exception. The result type of 8830 these expressions will always be of integral or boolean type. 8831 These operations return the result type's zero value for false, and 8832 the result type's one value for true. 8833 8834'MODIFY_EXPR' 8835 These nodes represent assignment. The left-hand side is the first 8836 operand; the right-hand side is the second operand. The left-hand 8837 side will be a 'VAR_DECL', 'INDIRECT_REF', 'COMPONENT_REF', or 8838 other lvalue. 8839 8840 These nodes are used to represent not only assignment with '=' but 8841 also compound assignments (like '+='), by reduction to '=' 8842 assignment. In other words, the representation for 'i += 3' looks 8843 just like that for 'i = i + 3'. 8844 8845'INIT_EXPR' 8846 These nodes are just like 'MODIFY_EXPR', but are used only when a 8847 variable is initialized, rather than assigned to subsequently. 8848 This means that we can assume that the target of the initialization 8849 is not used in computing its own value; any reference to the lhs in 8850 computing the rhs is undefined. 8851 8852'COMPOUND_EXPR' 8853 These nodes represent comma-expressions. The first operand is an 8854 expression whose value is computed and thrown away prior to the 8855 evaluation of the second operand. The value of the entire 8856 expression is the value of the second operand. 8857 8858'COND_EXPR' 8859 These nodes represent '?:' expressions. The first operand is of 8860 boolean or integral type. If it evaluates to a nonzero value, the 8861 second operand should be evaluated, and returned as the value of 8862 the expression. Otherwise, the third operand is evaluated, and 8863 returned as the value of the expression. 8864 8865 The second operand must have the same type as the entire 8866 expression, unless it unconditionally throws an exception or calls 8867 a noreturn function, in which case it should have void type. The 8868 same constraints apply to the third operand. This allows array 8869 bounds checks to be represented conveniently as '(i >= 0 && i < 10) 8870 ? i : abort()'. 8871 8872 As a GNU extension, the C language front-ends allow the second 8873 operand of the '?:' operator may be omitted in the source. For 8874 example, 'x ? : 3' is equivalent to 'x ? x : 3', assuming that 'x' 8875 is an expression without side-effects. In the tree representation, 8876 however, the second operand is always present, possibly protected 8877 by 'SAVE_EXPR' if the first argument does cause side-effects. 8878 8879'CALL_EXPR' 8880 These nodes are used to represent calls to functions, including 8881 non-static member functions. 'CALL_EXPR's are implemented as 8882 expression nodes with a variable number of operands. Rather than 8883 using 'TREE_OPERAND' to extract them, it is preferable to use the 8884 specialized accessor macros and functions that operate specifically 8885 on 'CALL_EXPR' nodes. 8886 8887 'CALL_EXPR_FN' returns a pointer to the function to call; it is 8888 always an expression whose type is a 'POINTER_TYPE'. 8889 8890 The number of arguments to the call is returned by 8891 'call_expr_nargs', while the arguments themselves can be accessed 8892 with the 'CALL_EXPR_ARG' macro. The arguments are zero-indexed and 8893 numbered left-to-right. You can iterate over the arguments using 8894 'FOR_EACH_CALL_EXPR_ARG', as in: 8895 8896 tree call, arg; 8897 call_expr_arg_iterator iter; 8898 FOR_EACH_CALL_EXPR_ARG (arg, iter, call) 8899 /* arg is bound to successive arguments of call. */ 8900 ...; 8901 8902 For non-static member functions, there will be an operand 8903 corresponding to the 'this' pointer. There will always be 8904 expressions corresponding to all of the arguments, even if the 8905 function is declared with default arguments and some arguments are 8906 not explicitly provided at the call sites. 8907 8908 'CALL_EXPR's also have a 'CALL_EXPR_STATIC_CHAIN' operand that is 8909 used to implement nested functions. This operand is otherwise 8910 null. 8911 8912'CLEANUP_POINT_EXPR' 8913 These nodes represent full-expressions. The single operand is an 8914 expression to evaluate. Any destructor calls engendered by the 8915 creation of temporaries during the evaluation of that expression 8916 should be performed immediately after the expression is evaluated. 8917 8918'CONSTRUCTOR' 8919 These nodes represent the brace-enclosed initializers for a 8920 structure or an array. They contain a sequence of component values 8921 made out of a vector of constructor_elt, which is a ('INDEX', 8922 'VALUE') pair. 8923 8924 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is a 'RECORD_TYPE', 8925 'UNION_TYPE' or 'QUAL_UNION_TYPE' then the 'INDEX' of each node in 8926 the sequence will be a 'FIELD_DECL' and the 'VALUE' will be the 8927 expression used to initialize that field. 8928 8929 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is an 'ARRAY_TYPE', then 8930 the 'INDEX' of each node in the sequence will be an 'INTEGER_CST' 8931 or a 'RANGE_EXPR' of two 'INTEGER_CST's. A single 'INTEGER_CST' 8932 indicates which element of the array is being assigned to. A 8933 'RANGE_EXPR' indicates an inclusive range of elements to 8934 initialize. In both cases the 'VALUE' is the corresponding 8935 initializer. It is re-evaluated for each element of a 8936 'RANGE_EXPR'. If the 'INDEX' is 'NULL_TREE', then the initializer 8937 is for the next available array element. 8938 8939 In the front end, you should not depend on the fields appearing in 8940 any particular order. However, in the middle end, fields must 8941 appear in declaration order. You should not assume that all fields 8942 will be represented. Unrepresented fields will be cleared 8943 (zeroed), unless the CONSTRUCTOR_NO_CLEARING flag is set, in which 8944 case their value becomes undefined. 8945 8946'COMPOUND_LITERAL_EXPR' 8947 These nodes represent ISO C99 compound literals. The 8948 'COMPOUND_LITERAL_EXPR_DECL_EXPR' is a 'DECL_EXPR' containing an 8949 anonymous 'VAR_DECL' for the unnamed object represented by the 8950 compound literal; the 'DECL_INITIAL' of that 'VAR_DECL' is a 8951 'CONSTRUCTOR' representing the brace-enclosed list of initializers 8952 in the compound literal. That anonymous 'VAR_DECL' can also be 8953 accessed directly by the 'COMPOUND_LITERAL_EXPR_DECL' macro. 8954 8955'SAVE_EXPR' 8956 8957 A 'SAVE_EXPR' represents an expression (possibly involving 8958 side-effects) that is used more than once. The side-effects should 8959 occur only the first time the expression is evaluated. Subsequent 8960 uses should just reuse the computed value. The first operand to 8961 the 'SAVE_EXPR' is the expression to evaluate. The side-effects 8962 should be executed where the 'SAVE_EXPR' is first encountered in a 8963 depth-first preorder traversal of the expression tree. 8964 8965'TARGET_EXPR' 8966 A 'TARGET_EXPR' represents a temporary object. The first operand 8967 is a 'VAR_DECL' for the temporary variable. The second operand is 8968 the initializer for the temporary. The initializer is evaluated 8969 and, if non-void, copied (bitwise) into the temporary. If the 8970 initializer is void, that means that it will perform the 8971 initialization itself. 8972 8973 Often, a 'TARGET_EXPR' occurs on the right-hand side of an 8974 assignment, or as the second operand to a comma-expression which is 8975 itself the right-hand side of an assignment, etc. In this case, we 8976 say that the 'TARGET_EXPR' is "normal"; otherwise, we say it is 8977 "orphaned". For a normal 'TARGET_EXPR' the temporary variable 8978 should be treated as an alias for the left-hand side of the 8979 assignment, rather than as a new temporary variable. 8980 8981 The third operand to the 'TARGET_EXPR', if present, is a 8982 cleanup-expression (i.e., destructor call) for the temporary. If 8983 this expression is orphaned, then this expression must be executed 8984 when the statement containing this expression is complete. These 8985 cleanups must always be executed in the order opposite to that in 8986 which they were encountered. Note that if a temporary is created 8987 on one branch of a conditional operator (i.e., in the second or 8988 third operand to a 'COND_EXPR'), the cleanup must be run only if 8989 that branch is actually executed. 8990 8991'VA_ARG_EXPR' 8992 This node is used to implement support for the C/C++ variable 8993 argument-list mechanism. It represents expressions like 'va_arg 8994 (ap, type)'. Its 'TREE_TYPE' yields the tree representation for 8995 'type' and its sole argument yields the representation for 'ap'. 8996 8997'ANNOTATE_EXPR' 8998 This node is used to attach markers to an expression. The first 8999 operand is the annotated expression, the second is an 'INTEGER_CST' 9000 with a value from 'enum annot_expr_kind'. 9001 9002 9003File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees 9004 900510.6.4 Vectors 9006-------------- 9007 9008'VEC_LSHIFT_EXPR' 9009'VEC_RSHIFT_EXPR' 9010 These nodes represent whole vector left and right shifts, 9011 respectively. The first operand is the vector to shift; it will 9012 always be of vector type. The second operand is an expression for 9013 the number of bits by which to shift. Note that the result is 9014 undefined if the second operand is larger than or equal to the 9015 first operand's type size. 9016 9017'VEC_WIDEN_MULT_HI_EXPR' 9018'VEC_WIDEN_MULT_LO_EXPR' 9019 These nodes represent widening vector multiplication of the high 9020 and low parts of the two input vectors, respectively. Their 9021 operands are vectors that contain the same number of elements ('N') 9022 of the same integral type. The result is a vector that contains 9023 half as many elements, of an integral type whose size is twice as 9024 wide. In the case of 'VEC_WIDEN_MULT_HI_EXPR' the high 'N/2' 9025 elements of the two vector are multiplied to produce the vector of 9026 'N/2' products. In the case of 'VEC_WIDEN_MULT_LO_EXPR' the low 9027 'N/2' elements of the two vector are multiplied to produce the 9028 vector of 'N/2' products. 9029 9030'VEC_UNPACK_HI_EXPR' 9031'VEC_UNPACK_LO_EXPR' 9032 These nodes represent unpacking of the high and low parts of the 9033 input vector, respectively. The single operand is a vector that 9034 contains 'N' elements of the same integral or floating point type. 9035 The result is a vector that contains half as many elements, of an 9036 integral or floating point type whose size is twice as wide. In 9037 the case of 'VEC_UNPACK_HI_EXPR' the high 'N/2' elements of the 9038 vector are extracted and widened (promoted). In the case of 9039 'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the vector are 9040 extracted and widened (promoted). 9041 9042'VEC_UNPACK_FLOAT_HI_EXPR' 9043'VEC_UNPACK_FLOAT_LO_EXPR' 9044 These nodes represent unpacking of the high and low parts of the 9045 input vector, where the values are converted from fixed point to 9046 floating point. The single operand is a vector that contains 'N' 9047 elements of the same integral type. The result is a vector that 9048 contains half as many elements of a floating point type whose size 9049 is twice as wide. In the case of 'VEC_UNPACK_HI_EXPR' the high 9050 'N/2' elements of the vector are extracted, converted and widened. 9051 In the case of 'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the 9052 vector are extracted, converted and widened. 9053 9054'VEC_PACK_TRUNC_EXPR' 9055 This node represents packing of truncated elements of the two input 9056 vectors into the output vector. Input operands are vectors that 9057 contain the same number of elements of the same integral or 9058 floating point type. The result is a vector that contains twice as 9059 many elements of an integral or floating point type whose size is 9060 half as wide. The elements of the two vectors are demoted and 9061 merged (concatenated) to form the output vector. 9062 9063'VEC_PACK_SAT_EXPR' 9064 This node represents packing of elements of the two input vectors 9065 into the output vector using saturation. Input operands are 9066 vectors that contain the same number of elements of the same 9067 integral type. The result is a vector that contains twice as many 9068 elements of an integral type whose size is half as wide. The 9069 elements of the two vectors are demoted and merged (concatenated) 9070 to form the output vector. 9071 9072'VEC_PACK_FIX_TRUNC_EXPR' 9073 This node represents packing of elements of the two input vectors 9074 into the output vector, where the values are converted from 9075 floating point to fixed point. Input operands are vectors that 9076 contain the same number of elements of a floating point type. The 9077 result is a vector that contains twice as many elements of an 9078 integral type whose size is half as wide. The elements of the two 9079 vectors are merged (concatenated) to form the output vector. 9080 9081'VEC_COND_EXPR' 9082 These nodes represent '?:' expressions. The three operands must be 9083 vectors of the same size and number of elements. The second and 9084 third operands must have the same type as the entire expression. 9085 The first operand is of signed integral vector type. If an element 9086 of the first operand evaluates to a zero value, the corresponding 9087 element of the result is taken from the third operand. If it 9088 evaluates to a minus one value, it is taken from the second 9089 operand. It should never evaluate to any other value currently, 9090 but optimizations should not rely on that property. In contrast 9091 with a 'COND_EXPR', all operands are always evaluated. 9092 9093'SAD_EXPR' 9094 This node represents the Sum of Absolute Differences operation. 9095 The three operands must be vectors of integral types. The first 9096 and second operand must have the same type. The size of the vector 9097 element of the third operand must be at lease twice of the size of 9098 the vector element of the first and second one. The SAD is 9099 calculated between the first and second operands, added to the 9100 third operand, and returned. 9101 9102 9103File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC 9104 910510.7 Statements 9106=============== 9107 9108Most statements in GIMPLE are assignment statements, represented by 9109'GIMPLE_ASSIGN'. No other C expressions can appear at statement level; 9110a reference to a volatile object is converted into a 'GIMPLE_ASSIGN'. 9111 9112 There are also several varieties of complex statements. 9113 9114* Menu: 9115 9116* Basic Statements:: 9117* Blocks:: 9118* Statement Sequences:: 9119* Empty Statements:: 9120* Jumps:: 9121* Cleanups:: 9122* OpenMP:: 9123* OpenACC:: 9124 9125 9126File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements 9127 912810.7.1 Basic Statements 9129----------------------- 9130 9131'ASM_EXPR' 9132 9133 Used to represent an inline assembly statement. For an inline 9134 assembly statement like: 9135 asm ("mov x, y"); 9136 The 'ASM_STRING' macro will return a 'STRING_CST' node for '"mov x, 9137 y"'. If the original statement made use of the extended-assembly 9138 syntax, then 'ASM_OUTPUTS', 'ASM_INPUTS', and 'ASM_CLOBBERS' will 9139 be the outputs, inputs, and clobbers for the statement, represented 9140 as 'STRING_CST' nodes. The extended-assembly syntax looks like: 9141 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 9142 The first string is the 'ASM_STRING', containing the instruction 9143 template. The next two strings are the output and inputs, 9144 respectively; this statement has no clobbers. As this example 9145 indicates, "plain" assembly statements are merely a special case of 9146 extended assembly statements; they have no cv-qualifiers, outputs, 9147 inputs, or clobbers. All of the strings will be 'NUL'-terminated, 9148 and will contain no embedded 'NUL'-characters. 9149 9150 If the assembly statement is declared 'volatile', or if the 9151 statement was not an extended assembly statement, and is therefore 9152 implicitly volatile, then the predicate 'ASM_VOLATILE_P' will hold 9153 of the 'ASM_EXPR'. 9154 9155'DECL_EXPR' 9156 9157 Used to represent a local declaration. The 'DECL_EXPR_DECL' macro 9158 can be used to obtain the entity declared. This declaration may be 9159 a 'LABEL_DECL', indicating that the label declared is a local 9160 label. (As an extension, GCC allows the declaration of labels with 9161 scope.) In C, this declaration may be a 'FUNCTION_DECL', 9162 indicating the use of the GCC nested function extension. For more 9163 information, *note Functions::. 9164 9165'LABEL_EXPR' 9166 9167 Used to represent a label. The 'LABEL_DECL' declared by this 9168 statement can be obtained with the 'LABEL_EXPR_LABEL' macro. The 9169 'IDENTIFIER_NODE' giving the name of the label can be obtained from 9170 the 'LABEL_DECL' with 'DECL_NAME'. 9171 9172'GOTO_EXPR' 9173 9174 Used to represent a 'goto' statement. The 'GOTO_DESTINATION' will 9175 usually be a 'LABEL_DECL'. However, if the "computed goto" 9176 extension has been used, the 'GOTO_DESTINATION' will be an 9177 arbitrary expression indicating the destination. This expression 9178 will always have pointer type. 9179 9180'RETURN_EXPR' 9181 9182 Used to represent a 'return' statement. Operand 0 represents the 9183 value to return. It should either be the 'RESULT_DECL' for the 9184 containing function, or a 'MODIFY_EXPR' or 'INIT_EXPR' setting the 9185 function's 'RESULT_DECL'. It will be 'NULL_TREE' if the statement 9186 was just 9187 return; 9188 9189'LOOP_EXPR' 9190 These nodes represent "infinite" loops. The 'LOOP_EXPR_BODY' 9191 represents the body of the loop. It should be executed forever, 9192 unless an 'EXIT_EXPR' is encountered. 9193 9194'EXIT_EXPR' 9195 These nodes represent conditional exits from the nearest enclosing 9196 'LOOP_EXPR'. The single operand is the condition; if it is 9197 nonzero, then the loop should be exited. An 'EXIT_EXPR' will only 9198 appear within a 'LOOP_EXPR'. 9199 9200'SWITCH_STMT' 9201 9202 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 9203 the expression on which the switch is occurring. See the 9204 documentation for an 'IF_STMT' for more information on the 9205 representation used for the condition. The 'SWITCH_STMT_BODY' is 9206 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 9207 original type of switch expression as given in the source, before 9208 any compiler conversions. 9209 9210'CASE_LABEL_EXPR' 9211 9212 Use to represent a 'case' label, range of 'case' labels, or a 9213 'default' label. If 'CASE_LOW' is 'NULL_TREE', then this is a 9214 'default' label. Otherwise, if 'CASE_HIGH' is 'NULL_TREE', then 9215 this is an ordinary 'case' label. In this case, 'CASE_LOW' is an 9216 expression giving the value of the label. Both 'CASE_LOW' and 9217 'CASE_HIGH' are 'INTEGER_CST' nodes. These values will have the 9218 same type as the condition expression in the switch statement. 9219 9220 Otherwise, if both 'CASE_LOW' and 'CASE_HIGH' are defined, the 9221 statement is a range of case labels. Such statements originate 9222 with the extension that allows users to write things of the form: 9223 case 2 ... 5: 9224 The first value will be 'CASE_LOW', while the second will be 9225 'CASE_HIGH'. 9226 9227 9228File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements 9229 923010.7.2 Blocks 9231------------- 9232 9233Block scopes and the variables they declare in GENERIC are expressed 9234using the 'BIND_EXPR' code, which in previous versions of GCC was 9235primarily used for the C statement-expression extension. 9236 9237 Variables in a block are collected into 'BIND_EXPR_VARS' in declaration 9238order through their 'TREE_CHAIN' field. Any runtime initialization is 9239moved out of 'DECL_INITIAL' and into a statement in the controlled 9240block. When gimplifying from C or C++, this initialization replaces the 9241'DECL_STMT'. These variables will never require cleanups. The scope of 9242these variables is just the body 9243 9244 Variable-length arrays (VLAs) complicate this process, as their size 9245often refers to variables initialized earlier in the block. To handle 9246this, we currently split the block at that point, and move the VLA into 9247a new, inner 'BIND_EXPR'. This strategy may change in the future. 9248 9249 A C++ program will usually contain more 'BIND_EXPR's than there are 9250syntactic blocks in the source code, since several C++ constructs have 9251implicit scopes associated with them. On the other hand, although the 9252C++ front end uses pseudo-scopes to handle cleanups for objects with 9253destructors, these don't translate into the GIMPLE form; multiple 9254declarations at the same level use the same 'BIND_EXPR'. 9255 9256 9257File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 9258 925910.7.3 Statement Sequences 9260-------------------------- 9261 9262Multiple statements at the same nesting level are collected into a 9263'STATEMENT_LIST'. Statement lists are modified and traversed using the 9264interface in 'tree-iterator.h'. 9265 9266 9267File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements 9268 926910.7.4 Empty Statements 9270----------------------- 9271 9272Whenever possible, statements with no effect are discarded. But if they 9273are nested within another construct which cannot be discarded for some 9274reason, they are instead replaced with an empty statement, generated by 9275'build_empty_stmt'. Initially, all empty statements were shared, after 9276the pattern of the Java front end, but this caused a lot of trouble in 9277practice. 9278 9279 An empty statement is represented as '(void)0'. 9280 9281 9282File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements 9283 928410.7.5 Jumps 9285------------ 9286 9287Other jumps are expressed by either 'GOTO_EXPR' or 'RETURN_EXPR'. 9288 9289 The operand of a 'GOTO_EXPR' must be either a label or a variable 9290containing the address to jump to. 9291 9292 The operand of a 'RETURN_EXPR' is either 'NULL_TREE', 'RESULT_DECL', or 9293a 'MODIFY_EXPR' which sets the return value. It would be nice to move 9294the 'MODIFY_EXPR' into a separate statement, but the special return 9295semantics in 'expand_return' make that difficult. It may still happen 9296in the future, perhaps by moving most of that logic into 9297'expand_assignment'. 9298 9299 9300File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements 9301 930210.7.6 Cleanups 9303--------------- 9304 9305Destructors for local C++ objects and similar dynamic cleanups are 9306represented in GIMPLE by a 'TRY_FINALLY_EXPR'. 'TRY_FINALLY_EXPR' has 9307two operands, both of which are a sequence of statements to execute. 9308The first sequence is executed. When it completes the second sequence 9309is executed. 9310 9311 The first sequence may complete in the following ways: 9312 9313 1. Execute the last statement in the sequence and fall off the end. 9314 9315 2. Execute a goto statement ('GOTO_EXPR') to an ordinary label outside 9316 the sequence. 9317 9318 3. Execute a return statement ('RETURN_EXPR'). 9319 9320 4. Throw an exception. This is currently not explicitly represented 9321 in GIMPLE. 9322 9323 The second sequence is not executed if the first sequence completes by 9324calling 'setjmp' or 'exit' or any other function that does not return. 9325The second sequence is also not executed if the first sequence completes 9326via a non-local goto or a computed goto (in general the compiler does 9327not know whether such a goto statement exits the first sequence or not, 9328so we assume that it doesn't). 9329 9330 After the second sequence is executed, if it completes normally by 9331falling off the end, execution continues wherever the first sequence 9332would have continued, by falling off the end, or doing a goto, etc. 9333 9334 'TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 9335to appear on every edge out of the controlled block; this reduces the 9336freedom to move code across these edges. Therefore, the EH lowering 9337pass which runs before most of the optimization passes eliminates these 9338expressions by explicitly adding the cleanup to each edge. Rethrowing 9339the exception is represented using 'RESX_EXPR'. 9340 9341 9342File: gccint.info, Node: OpenMP, Next: OpenACC, Prev: Cleanups, Up: Statements 9343 934410.7.7 OpenMP 9345------------- 9346 9347All the statements starting with 'OMP_' represent directives and clauses 9348used by the OpenMP API <http://www.openmp.org/>. 9349 9350'OMP_PARALLEL' 9351 9352 Represents '#pragma omp parallel [clause1 ... clauseN]'. It has 9353 four operands: 9354 9355 Operand 'OMP_PARALLEL_BODY' is valid while in GENERIC and High 9356 GIMPLE forms. It contains the body of code to be executed by all 9357 the threads. During GIMPLE lowering, this operand becomes 'NULL' 9358 and the body is emitted linearly after 'OMP_PARALLEL'. 9359 9360 Operand 'OMP_PARALLEL_CLAUSES' is the list of clauses associated 9361 with the directive. 9362 9363 Operand 'OMP_PARALLEL_FN' is created by 'pass_lower_omp', it 9364 contains the 'FUNCTION_DECL' for the function that will contain the 9365 body of the parallel region. 9366 9367 Operand 'OMP_PARALLEL_DATA_ARG' is also created by 9368 'pass_lower_omp'. If there are shared variables to be communicated 9369 to the children threads, this operand will contain the 'VAR_DECL' 9370 that contains all the shared values and variables. 9371 9372'OMP_FOR' 9373 9374 Represents '#pragma omp for [clause1 ... clauseN]'. It has six 9375 operands: 9376 9377 Operand 'OMP_FOR_BODY' contains the loop body. 9378 9379 Operand 'OMP_FOR_CLAUSES' is the list of clauses associated with 9380 the directive. 9381 9382 Operand 'OMP_FOR_INIT' is the loop initialization code of the form 9383 'VAR = N1'. 9384 9385 Operand 'OMP_FOR_COND' is the loop conditional expression of the 9386 form 'VAR {<,>,<=,>=} N2'. 9387 9388 Operand 'OMP_FOR_INCR' is the loop index increment of the form 'VAR 9389 {+=,-=} INCR'. 9390 9391 Operand 'OMP_FOR_PRE_BODY' contains side-effect code from operands 9392 'OMP_FOR_INIT', 'OMP_FOR_COND' and 'OMP_FOR_INC'. These 9393 side-effects are part of the 'OMP_FOR' block but must be evaluated 9394 before the start of loop body. 9395 9396 The loop index variable 'VAR' must be a signed integer variable, 9397 which is implicitly private to each thread. Bounds 'N1' and 'N2' 9398 and the increment expression 'INCR' are required to be loop 9399 invariant integer expressions that are evaluated without any 9400 synchronization. The evaluation order, frequency of evaluation and 9401 side-effects are unspecified by the standard. 9402 9403'OMP_SECTIONS' 9404 9405 Represents '#pragma omp sections [clause1 ... clauseN]'. 9406 9407 Operand 'OMP_SECTIONS_BODY' contains the sections body, which in 9408 turn contains a set of 'OMP_SECTION' nodes for each of the 9409 concurrent sections delimited by '#pragma omp section'. 9410 9411 Operand 'OMP_SECTIONS_CLAUSES' is the list of clauses associated 9412 with the directive. 9413 9414'OMP_SECTION' 9415 9416 Section delimiter for 'OMP_SECTIONS'. 9417 9418'OMP_SINGLE' 9419 9420 Represents '#pragma omp single'. 9421 9422 Operand 'OMP_SINGLE_BODY' contains the body of code to be executed 9423 by a single thread. 9424 9425 Operand 'OMP_SINGLE_CLAUSES' is the list of clauses associated with 9426 the directive. 9427 9428'OMP_MASTER' 9429 9430 Represents '#pragma omp master'. 9431 9432 Operand 'OMP_MASTER_BODY' contains the body of code to be executed 9433 by the master thread. 9434 9435'OMP_ORDERED' 9436 9437 Represents '#pragma omp ordered'. 9438 9439 Operand 'OMP_ORDERED_BODY' contains the body of code to be executed 9440 in the sequential order dictated by the loop index variable. 9441 9442'OMP_CRITICAL' 9443 9444 Represents '#pragma omp critical [name]'. 9445 9446 Operand 'OMP_CRITICAL_BODY' is the critical section. 9447 9448 Operand 'OMP_CRITICAL_NAME' is an optional identifier to label the 9449 critical section. 9450 9451'OMP_RETURN' 9452 9453 This does not represent any OpenMP directive, it is an artificial 9454 marker to indicate the end of the body of an OpenMP. It is used by 9455 the flow graph ('tree-cfg.c') and OpenMP region building code 9456 ('omp-low.c'). 9457 9458'OMP_CONTINUE' 9459 9460 Similarly, this instruction does not represent an OpenMP directive, 9461 it is used by 'OMP_FOR' (and similar codes) as well as 9462 'OMP_SECTIONS' to mark the place where the code needs to loop to 9463 the next iteration, or the next section, respectively. 9464 9465 In some cases, 'OMP_CONTINUE' is placed right before 'OMP_RETURN'. 9466 But if there are cleanups that need to occur right after the 9467 looping body, it will be emitted between 'OMP_CONTINUE' and 9468 'OMP_RETURN'. 9469 9470'OMP_ATOMIC' 9471 9472 Represents '#pragma omp atomic'. 9473 9474 Operand 0 is the address at which the atomic operation is to be 9475 performed. 9476 9477 Operand 1 is the expression to evaluate. The gimplifier tries 9478 three alternative code generation strategies. Whenever possible, 9479 an atomic update built-in is used. If that fails, a 9480 compare-and-swap loop is attempted. If that also fails, a regular 9481 critical section around the expression is used. 9482 9483'OMP_CLAUSE' 9484 9485 Represents clauses associated with one of the 'OMP_' directives. 9486 Clauses are represented by separate subcodes defined in 'tree.h'. 9487 Clauses codes can be one of: 'OMP_CLAUSE_PRIVATE', 9488 'OMP_CLAUSE_SHARED', 'OMP_CLAUSE_FIRSTPRIVATE', 9489 'OMP_CLAUSE_LASTPRIVATE', 'OMP_CLAUSE_COPYIN', 9490 'OMP_CLAUSE_COPYPRIVATE', 'OMP_CLAUSE_IF', 9491 'OMP_CLAUSE_NUM_THREADS', 'OMP_CLAUSE_SCHEDULE', 9492 'OMP_CLAUSE_NOWAIT', 'OMP_CLAUSE_ORDERED', 'OMP_CLAUSE_DEFAULT', 9493 'OMP_CLAUSE_REDUCTION', 'OMP_CLAUSE_COLLAPSE', 'OMP_CLAUSE_UNTIED', 9494 'OMP_CLAUSE_FINAL', and 'OMP_CLAUSE_MERGEABLE'. Each code 9495 represents the corresponding OpenMP clause. 9496 9497 Clauses associated with the same directive are chained together via 9498 'OMP_CLAUSE_CHAIN'. Those clauses that accept a list of variables 9499 are restricted to exactly one, accessed with 'OMP_CLAUSE_VAR'. 9500 Therefore, multiple variables under the same clause 'C' need to be 9501 represented as multiple 'C' clauses chained together. This 9502 facilitates adding new clauses during compilation. 9503 9504 9505File: gccint.info, Node: OpenACC, Prev: OpenMP, Up: Statements 9506 950710.7.8 OpenACC 9508-------------- 9509 9510All the statements starting with 'OACC_' represent directives and 9511clauses used by the OpenACC API <http://www.openacc.org/>. 9512 9513'OACC_CACHE' 9514 9515 Represents '#pragma acc cache (var ...)'. 9516 9517'OACC_DATA' 9518 9519 Represents '#pragma acc data [clause1 ... clauseN]'. 9520 9521'OACC_DECLARE' 9522 9523 Represents '#pragma acc declare [clause1 ... clauseN]'. 9524 9525'OACC_ENTER_DATA' 9526 9527 Represents '#pragma acc enter data [clause1 ... clauseN]'. 9528 9529'OACC_EXIT_DATA' 9530 9531 Represents '#pragma acc exit data [clause1 ... clauseN]'. 9532 9533'OACC_HOST_DATA' 9534 9535 Represents '#pragma acc host_data [clause1 ... clauseN]'. 9536 9537'OACC_KERNELS' 9538 9539 Represents '#pragma acc kernels [clause1 ... clauseN]'. 9540 9541'OACC_LOOP' 9542 9543 Represents '#pragma acc loop [clause1 ... clauseN]'. 9544 9545 See the description of the 'OMP_FOR' code. 9546 9547'OACC_PARALLEL' 9548 9549 Represents '#pragma acc parallel [clause1 ... clauseN]'. 9550 9551'OACC_UPDATE' 9552 9553 Represents '#pragma acc update [clause1 ... clauseN]'. 9554 9555 9556File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC 9557 955810.8 Functions 9559============== 9560 9561A function is represented by a 'FUNCTION_DECL' node. It stores the 9562basic pieces of the function such as body, parameters, and return type 9563as well as information on the surrounding context, visibility, and 9564linkage. 9565 9566* Menu: 9567 9568* Function Basics:: Function names, body, and parameters. 9569* Function Properties:: Context, linkage, etc. 9570 9571 9572File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions 9573 957410.8.1 Function Basics 9575---------------------- 9576 9577A function has four core parts: the name, the parameters, the result, 9578and the body. The following macros and functions access these parts of 9579a 'FUNCTION_DECL' as well as other basic features: 9580'DECL_NAME' 9581 This macro returns the unqualified name of the function, as an 9582 'IDENTIFIER_NODE'. For an instantiation of a function template, 9583 the 'DECL_NAME' is the unqualified name of the template, not 9584 something like 'f<int>'. The value of 'DECL_NAME' is undefined 9585 when used on a constructor, destructor, overloaded operator, or 9586 type-conversion operator, or any function that is implicitly 9587 generated by the compiler. See below for macros that can be used 9588 to distinguish these cases. 9589 9590'DECL_ASSEMBLER_NAME' 9591 This macro returns the mangled name of the function, also an 9592 'IDENTIFIER_NODE'. This name does not contain leading underscores 9593 on systems that prefix all identifiers with underscores. The 9594 mangled name is computed in the same way on all platforms; if 9595 special processing is required to deal with the object file format 9596 used on a particular platform, it is the responsibility of the back 9597 end to perform those modifications. (Of course, the back end 9598 should not modify 'DECL_ASSEMBLER_NAME' itself.) 9599 9600 Using 'DECL_ASSEMBLER_NAME' will cause additional memory to be 9601 allocated (for the mangled name of the entity) so it should be used 9602 only when emitting assembly code. It should not be used within the 9603 optimizers to determine whether or not two declarations are the 9604 same, even though some of the existing optimizers do use it in that 9605 way. These uses will be removed over time. 9606 9607'DECL_ARGUMENTS' 9608 This macro returns the 'PARM_DECL' for the first argument to the 9609 function. Subsequent 'PARM_DECL' nodes can be obtained by 9610 following the 'TREE_CHAIN' links. 9611 9612'DECL_RESULT' 9613 This macro returns the 'RESULT_DECL' for the function. 9614 9615'DECL_SAVED_TREE' 9616 This macro returns the complete body of the function. 9617 9618'TREE_TYPE' 9619 This macro returns the 'FUNCTION_TYPE' or 'METHOD_TYPE' for the 9620 function. 9621 9622'DECL_INITIAL' 9623 A function that has a definition in the current translation unit 9624 will have a non-'NULL' 'DECL_INITIAL'. However, back ends should 9625 not make use of the particular value given by 'DECL_INITIAL'. 9626 9627 It should contain a tree of 'BLOCK' nodes that mirrors the scopes 9628 that variables are bound in the function. Each block contains a 9629 list of decls declared in a basic block, a pointer to a chain of 9630 blocks at the next lower scope level, then a pointer to the next 9631 block at the same level and a backpointer to the parent 'BLOCK' or 9632 'FUNCTION_DECL'. So given a function as follows: 9633 9634 void foo() 9635 { 9636 int a; 9637 { 9638 int b; 9639 } 9640 int c; 9641 } 9642 9643 you would get the following: 9644 9645 tree foo = FUNCTION_DECL; 9646 tree decl_a = VAR_DECL; 9647 tree decl_b = VAR_DECL; 9648 tree decl_c = VAR_DECL; 9649 tree block_a = BLOCK; 9650 tree block_b = BLOCK; 9651 tree block_c = BLOCK; 9652 BLOCK_VARS(block_a) = decl_a; 9653 BLOCK_SUBBLOCKS(block_a) = block_b; 9654 BLOCK_CHAIN(block_a) = block_c; 9655 BLOCK_SUPERCONTEXT(block_a) = foo; 9656 BLOCK_VARS(block_b) = decl_b; 9657 BLOCK_SUPERCONTEXT(block_b) = block_a; 9658 BLOCK_VARS(block_c) = decl_c; 9659 BLOCK_SUPERCONTEXT(block_c) = foo; 9660 DECL_INITIAL(foo) = block_a; 9661 9662 9663File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions 9664 966510.8.2 Function Properties 9666-------------------------- 9667 9668To determine the scope of a function, you can use the 'DECL_CONTEXT' 9669macro. This macro will return the class (either a 'RECORD_TYPE' or a 9670'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 9671a member. For a virtual function, this macro returns the class in which 9672the function was actually defined, not the base class in which the 9673virtual declaration occurred. 9674 9675 In C, the 'DECL_CONTEXT' for a function maybe another function. This 9676representation indicates that the GNU nested function extension is in 9677use. For details on the semantics of nested functions, see the GCC 9678Manual. The nested function can refer to local variables in its 9679containing function. Such references are not explicitly marked in the 9680tree structure; back ends must look at the 'DECL_CONTEXT' for the 9681referenced 'VAR_DECL'. If the 'DECL_CONTEXT' for the referenced 9682'VAR_DECL' is not the same as the function currently being processed, 9683and neither 'DECL_EXTERNAL' nor 'TREE_STATIC' hold, then the reference 9684is to a local variable in a containing function, and the back end must 9685take appropriate action. 9686 9687'DECL_EXTERNAL' 9688 This predicate holds if the function is undefined. 9689 9690'TREE_PUBLIC' 9691 This predicate holds if the function has external linkage. 9692 9693'TREE_STATIC' 9694 This predicate holds if the function has been defined. 9695 9696'TREE_THIS_VOLATILE' 9697 This predicate holds if the function does not return normally. 9698 9699'TREE_READONLY' 9700 This predicate holds if the function can only read its arguments. 9701 9702'DECL_PURE_P' 9703 This predicate holds if the function can only read its arguments, 9704 but may also read global memory. 9705 9706'DECL_VIRTUAL_P' 9707 This predicate holds if the function is virtual. 9708 9709'DECL_ARTIFICIAL' 9710 This macro holds if the function was implicitly generated by the 9711 compiler, rather than explicitly declared. In addition to 9712 implicitly generated class member functions, this macro holds for 9713 the special functions created to implement static initialization 9714 and destruction, to compute run-time type information, and so 9715 forth. 9716 9717'DECL_FUNCTION_SPECIFIC_TARGET' 9718 This macro returns a tree node that holds the target options that 9719 are to be used to compile this particular function or 'NULL_TREE' 9720 if the function is to be compiled with the target options specified 9721 on the command line. 9722 9723'DECL_FUNCTION_SPECIFIC_OPTIMIZATION' 9724 This macro returns a tree node that holds the optimization options 9725 that are to be used to compile this particular function or 9726 'NULL_TREE' if the function is to be compiled with the optimization 9727 options specified on the command line. 9728 9729 9730File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC 9731 973210.9 Language-dependent trees 9733============================= 9734 9735Front ends may wish to keep some state associated with various GENERIC 9736trees while parsing. To support this, trees provide a set of flags that 9737may be used by the front end. They are accessed using 9738'TREE_LANG_FLAG_n' where 'n' is currently 0 through 6. 9739 9740 If necessary, a front end can use some language-dependent tree codes in 9741its GENERIC representation, so long as it provides a hook for converting 9742them to GIMPLE and doesn't expect them to work with any (hypothetical) 9743optimizers that run before the conversion to GIMPLE. The intermediate 9744representation used while parsing C and C++ looks very little like 9745GENERIC, but the C and C++ gimplifier hooks are perfectly happy to take 9746it as input and spit out GIMPLE. 9747 9748 9749File: gccint.info, Node: C and C++ Trees, Next: Java Trees, Prev: Language-dependent trees, Up: GENERIC 9750 975110.10 C and C++ Trees 9752===================== 9753 9754This section documents the internal representation used by GCC to 9755represent C and C++ source programs. When presented with a C or C++ 9756source program, GCC parses the program, performs semantic analysis 9757(including the generation of error messages), and then produces the 9758internal representation described here. This representation contains a 9759complete representation for the entire translation unit provided as 9760input to the front end. This representation is then typically processed 9761by a code-generator in order to produce machine code, but could also be 9762used in the creation of source browsers, intelligent editors, automatic 9763documentation generators, interpreters, and any other programs needing 9764the ability to process C or C++ code. 9765 9766 This section explains the internal representation. In particular, it 9767documents the internal representation for C and C++ source constructs, 9768and the macros, functions, and variables that can be used to access 9769these constructs. The C++ representation is largely a superset of the 9770representation used in the C front end. There is only one construct 9771used in C that does not appear in the C++ front end and that is the GNU 9772"nested function" extension. Many of the macros documented here do not 9773apply in C because the corresponding language constructs do not appear 9774in C. 9775 9776 The C and C++ front ends generate a mix of GENERIC trees and ones 9777specific to C and C++. These language-specific trees are higher-level 9778constructs than the ones in GENERIC to make the parser's job easier. 9779This section describes those trees that aren't part of GENERIC as well 9780as aspects of GENERIC trees that are treated in a language-specific 9781manner. 9782 9783 If you are developing a "back end", be it is a code-generator or some 9784other tool, that uses this representation, you may occasionally find 9785that you need to ask questions not easily answered by the functions and 9786macros available here. If that situation occurs, it is quite likely 9787that GCC already supports the functionality you desire, but that the 9788interface is simply not documented here. In that case, you should ask 9789the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting 9790the functionality you require. Similarly, if you find yourself writing 9791functions that do not deal directly with your back end, but instead 9792might be useful to other people using the GCC front end, you should 9793submit your patches for inclusion in GCC. 9794 9795* Menu: 9796 9797* Types for C++:: Fundamental and aggregate types. 9798* Namespaces:: Namespaces. 9799* Classes:: Classes. 9800* Functions for C++:: Overloading and accessors for C++. 9801* Statements for C++:: Statements specific to C and C++. 9802* C++ Expressions:: From 'typeid' to 'throw'. 9803 9804 9805File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees 9806 980710.10.1 Types for C++ 9808--------------------- 9809 9810In C++, an array type is not qualified; rather the type of the array 9811elements is qualified. This situation is reflected in the intermediate 9812representation. The macros described here will always examine the 9813qualification of the underlying element type when applied to an array 9814type. (If the element type is itself an array, then the recursion 9815continues until a non-array type is found, and the qualification of this 9816type is examined.) So, for example, 'CP_TYPE_CONST_P' will hold of the 9817type 'const int ()[7]', denoting an array of seven 'int's. 9818 9819 The following functions and macros deal with cv-qualification of types: 9820'cp_type_quals' 9821 This function returns the set of type qualifiers applied to this 9822 type. This value is 'TYPE_UNQUALIFIED' if no qualifiers have been 9823 applied. The 'TYPE_QUAL_CONST' bit is set if the type is 9824 'const'-qualified. The 'TYPE_QUAL_VOLATILE' bit is set if the type 9825 is 'volatile'-qualified. The 'TYPE_QUAL_RESTRICT' bit is set if 9826 the type is 'restrict'-qualified. 9827 9828'CP_TYPE_CONST_P' 9829 This macro holds if the type is 'const'-qualified. 9830 9831'CP_TYPE_VOLATILE_P' 9832 This macro holds if the type is 'volatile'-qualified. 9833 9834'CP_TYPE_RESTRICT_P' 9835 This macro holds if the type is 'restrict'-qualified. 9836 9837'CP_TYPE_CONST_NON_VOLATILE_P' 9838 This predicate holds for a type that is 'const'-qualified, but 9839 _not_ 'volatile'-qualified; other cv-qualifiers are ignored as 9840 well: only the 'const'-ness is tested. 9841 9842 A few other macros and functions are usable with all types: 9843'TYPE_SIZE' 9844 The number of bits required to represent the type, represented as 9845 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 9846 'NULL_TREE'. 9847 9848'TYPE_ALIGN' 9849 The alignment of the type, in bits, represented as an 'int'. 9850 9851'TYPE_NAME' 9852 This macro returns a declaration (in the form of a 'TYPE_DECL') for 9853 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 9854 as you might expect, given its name!) You can look at the 9855 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 9856 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 9857 built-in type, the result of a typedef, or a named class type. 9858 9859'CP_INTEGRAL_TYPE' 9860 This predicate holds if the type is an integral type. Notice that 9861 in C++, enumerations are _not_ integral types. 9862 9863'ARITHMETIC_TYPE_P' 9864 This predicate holds if the type is an integral type (in the C++ 9865 sense) or a floating point type. 9866 9867'CLASS_TYPE_P' 9868 This predicate holds for a class-type. 9869 9870'TYPE_BUILT_IN' 9871 This predicate holds for a built-in type. 9872 9873'TYPE_PTRDATAMEM_P' 9874 This predicate holds if the type is a pointer to data member. 9875 9876'TYPE_PTR_P' 9877 This predicate holds if the type is a pointer type, and the pointee 9878 is not a data member. 9879 9880'TYPE_PTRFN_P' 9881 This predicate holds for a pointer to function type. 9882 9883'TYPE_PTROB_P' 9884 This predicate holds for a pointer to object type. Note however 9885 that it does not hold for the generic pointer to object type 'void 9886 *'. You may use 'TYPE_PTROBV_P' to test for a pointer to object 9887 type as well as 'void *'. 9888 9889 The table below describes types specific to C and C++ as well as 9890language-dependent info about GENERIC types. 9891 9892'POINTER_TYPE' 9893 Used to represent pointer types, and pointer to data member types. 9894 If 'TREE_TYPE' is a pointer to data member type, then 9895 'TYPE_PTRDATAMEM_P' will hold. For a pointer to data member type 9896 of the form 'T X::*', 'TYPE_PTRMEM_CLASS_TYPE' will be the type 9897 'X', while 'TYPE_PTRMEM_POINTED_TO_TYPE' will be the type 'T'. 9898 9899'RECORD_TYPE' 9900 Used to represent 'struct' and 'class' types in C and C++. If 9901 'TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 9902 type. In that case, the 'TYPE_PTRMEMFUNC_FN_TYPE' is a 9903 'POINTER_TYPE' pointing to a 'METHOD_TYPE'. The 'METHOD_TYPE' is 9904 the type of a function pointed to by the pointer-to-member 9905 function. If 'TYPE_PTRMEMFUNC_P' does not hold, this type is a 9906 class type. For more information, *note Classes::. 9907 9908'UNKNOWN_TYPE' 9909 This node is used to represent a type the knowledge of which is 9910 insufficient for a sound processing. 9911 9912'TYPENAME_TYPE' 9913 Used to represent a construct of the form 'typename T::A'. The 9914 'TYPE_CONTEXT' is 'T'; the 'TYPE_NAME' is an 'IDENTIFIER_NODE' for 9915 'A'. If the type is specified via a template-id, then 9916 'TYPENAME_TYPE_FULLNAME' yields a 'TEMPLATE_ID_EXPR'. The 9917 'TREE_TYPE' is non-'NULL' if the node is implicitly generated in 9918 support for the implicit typename extension; in which case the 9919 'TREE_TYPE' is a type node for the base-class. 9920 9921'TYPEOF_TYPE' 9922 Used to represent the '__typeof__' extension. The 'TYPE_FIELDS' is 9923 the expression the type of which is being represented. 9924 9925 9926File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees 9927 992810.10.2 Namespaces 9929------------------ 9930 9931The root of the entire intermediate representation is the variable 9932'global_namespace'. This is the namespace specified with '::' in C++ 9933source code. All other namespaces, types, variables, functions, and so 9934forth can be found starting with this namespace. 9935 9936 However, except for the fact that it is distinguished as the root of 9937the representation, the global namespace is no different from any other 9938namespace. Thus, in what follows, we describe namespaces generally, 9939rather than the global namespace in particular. 9940 9941 A namespace is represented by a 'NAMESPACE_DECL' node. 9942 9943 The following macros and functions can be used on a 'NAMESPACE_DECL': 9944 9945'DECL_NAME' 9946 This macro is used to obtain the 'IDENTIFIER_NODE' corresponding to 9947 the unqualified name of the name of the namespace (*note 9948 Identifiers::). The name of the global namespace is '::', even 9949 though in C++ the global namespace is unnamed. However, you should 9950 use comparison with 'global_namespace', rather than 'DECL_NAME' to 9951 determine whether or not a namespace is the global one. An unnamed 9952 namespace will have a 'DECL_NAME' equal to 9953 'anonymous_namespace_name'. Within a single translation unit, all 9954 unnamed namespaces will have the same name. 9955 9956'DECL_CONTEXT' 9957 This macro returns the enclosing namespace. The 'DECL_CONTEXT' for 9958 the 'global_namespace' is 'NULL_TREE'. 9959 9960'DECL_NAMESPACE_ALIAS' 9961 If this declaration is for a namespace alias, then 9962 'DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 9963 alias. 9964 9965 Do not attempt to use 'cp_namespace_decls' for a namespace which is 9966 an alias. Instead, follow 'DECL_NAMESPACE_ALIAS' links until you 9967 reach an ordinary, non-alias, namespace, and call 9968 'cp_namespace_decls' there. 9969 9970'DECL_NAMESPACE_STD_P' 9971 This predicate holds if the namespace is the special '::std' 9972 namespace. 9973 9974'cp_namespace_decls' 9975 This function will return the declarations contained in the 9976 namespace, including types, overloaded functions, other namespaces, 9977 and so forth. If there are no declarations, this function will 9978 return 'NULL_TREE'. The declarations are connected through their 9979 'TREE_CHAIN' fields. 9980 9981 Although most entries on this list will be declarations, 9982 'TREE_LIST' nodes may also appear. In this case, the 'TREE_VALUE' 9983 will be an 'OVERLOAD'. The value of the 'TREE_PURPOSE' is 9984 unspecified; back ends should ignore this value. As with the other 9985 kinds of declarations returned by 'cp_namespace_decls', the 9986 'TREE_CHAIN' will point to the next declaration in this list. 9987 9988 For more information on the kinds of declarations that can occur on 9989 this list, *Note Declarations::. Some declarations will not appear 9990 on this list. In particular, no 'FIELD_DECL', 'LABEL_DECL', or 9991 'PARM_DECL' nodes will appear here. 9992 9993 This function cannot be used with namespaces that have 9994 'DECL_NAMESPACE_ALIAS' set. 9995 9996 9997File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees 9998 999910.10.3 Classes 10000--------------- 10001 10002Besides namespaces, the other high-level scoping construct in C++ is the 10003class. (Throughout this manual the term "class" is used to mean the 10004types referred to in the ANSI/ISO C++ Standard as classes; these include 10005types defined with the 'class', 'struct', and 'union' keywords.) 10006 10007 A class type is represented by either a 'RECORD_TYPE' or a 10008'UNION_TYPE'. A class declared with the 'union' tag is represented by a 10009'UNION_TYPE', while classes declared with either the 'struct' or the 10010'class' tag are represented by 'RECORD_TYPE's. You can use the 10011'CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 10012type is a 'class' as opposed to a 'struct'. This macro will be true 10013only for classes declared with the 'class' tag. 10014 10015 Almost all non-function members are available on the 'TYPE_FIELDS' 10016list. Given one member, the next can be found by following the 10017'TREE_CHAIN'. You should not depend in any way on the order in which 10018fields appear on this list. All nodes on this list will be 'DECL' 10019nodes. A 'FIELD_DECL' is used to represent a non-static data member, a 10020'VAR_DECL' is used to represent a static data member, and a 'TYPE_DECL' 10021is used to represent a type. Note that the 'CONST_DECL' for an 10022enumeration constant will appear on this list, if the enumeration type 10023was declared in the class. (Of course, the 'TYPE_DECL' for the 10024enumeration type will appear here as well.) There are no entries for 10025base classes on this list. In particular, there is no 'FIELD_DECL' for 10026the "base-class portion" of an object. 10027 10028 The 'TYPE_VFIELD' is a compiler-generated field used to point to 10029virtual function tables. It may or may not appear on the 'TYPE_FIELDS' 10030list. However, back ends should handle the 'TYPE_VFIELD' just like all 10031the entries on the 'TYPE_FIELDS' list. 10032 10033 The function members are available on the 'TYPE_METHODS' list. Again, 10034subsequent members are found by following the 'TREE_CHAIN' field. If a 10035function is overloaded, each of the overloaded functions appears; no 10036'OVERLOAD' nodes appear on the 'TYPE_METHODS' list. Implicitly declared 10037functions (including default constructors, copy constructors, assignment 10038operators, and destructors) will appear on this list as well. 10039 10040 Every class has an associated "binfo", which can be obtained with 10041'TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 10042given by 'TYPE_BINFO' is the degenerate case, whereby every class is 10043considered to be its own base-class. The base binfos for a particular 10044binfo are held in a vector, whose length is obtained with 10045'BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 10046'BINFO_BASE_BINFO' and 'BINFO_BASE_ITERATE'. To add a new binfo, use 10047'BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 10048'BINFO_BASE_BINFOS', but normally you do not need to use that. The 10049class type associated with a binfo is given by 'BINFO_TYPE'. It is not 10050always the case that 'BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 10051and qualified types. Neither is it the case that 'TYPE_BINFO 10052(BINFO_TYPE (y))' is the same binfo as 'y'. The reason is that if 'y' 10053is a binfo representing a base-class 'B' of a derived class 'D', then 10054'BINFO_TYPE (y)' will be 'B', and 'TYPE_BINFO (BINFO_TYPE (y))' will be 10055'B' as its own base-class, rather than as a base-class of 'D'. 10056 10057 The access to a base type can be found with 'BINFO_BASE_ACCESS'. This 10058will produce 'access_public_node', 'access_private_node' or 10059'access_protected_node'. If bases are always public, 10060'BINFO_BASE_ACCESSES' may be 'NULL'. 10061 10062 'BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 10063virtually or not. The other flags, 'BINFO_MARKED_P' and 'BINFO_FLAG_1' 10064to 'BINFO_FLAG_6' can be used for language specific use. 10065 10066 The following macros can be used on a tree node representing a 10067class-type. 10068 10069'LOCAL_CLASS_P' 10070 This predicate holds if the class is local class _i.e._ declared 10071 inside a function body. 10072 10073'TYPE_POLYMORPHIC_P' 10074 This predicate holds if the class has at least one virtual function 10075 (declared or inherited). 10076 10077'TYPE_HAS_DEFAULT_CONSTRUCTOR' 10078 This predicate holds whenever its argument represents a class-type 10079 with default constructor. 10080 10081'CLASSTYPE_HAS_MUTABLE' 10082'TYPE_HAS_MUTABLE_P' 10083 These predicates hold for a class-type having a mutable data 10084 member. 10085 10086'CLASSTYPE_NON_POD_P' 10087 This predicate holds only for class-types that are not PODs. 10088 10089'TYPE_HAS_NEW_OPERATOR' 10090 This predicate holds for a class-type that defines 'operator new'. 10091 10092'TYPE_HAS_ARRAY_NEW_OPERATOR' 10093 This predicate holds for a class-type for which 'operator new[]' is 10094 defined. 10095 10096'TYPE_OVERLOADS_CALL_EXPR' 10097 This predicate holds for class-type for which the function call 10098 'operator()' is overloaded. 10099 10100'TYPE_OVERLOADS_ARRAY_REF' 10101 This predicate holds for a class-type that overloads 'operator[]' 10102 10103'TYPE_OVERLOADS_ARROW' 10104 This predicate holds for a class-type for which 'operator->' is 10105 overloaded. 10106 10107 10108File: gccint.info, Node: Functions for C++, Next: Statements for C++, Prev: Classes, Up: C and C++ Trees 10109 1011010.10.4 Functions for C++ 10111------------------------- 10112 10113A function is represented by a 'FUNCTION_DECL' node. A set of 10114overloaded functions is sometimes represented by an 'OVERLOAD' node. 10115 10116 An 'OVERLOAD' node is not a declaration, so none of the 'DECL_' macros 10117should be used on an 'OVERLOAD'. An 'OVERLOAD' node is similar to a 10118'TREE_LIST'. Use 'OVL_CURRENT' to get the function associated with an 10119'OVERLOAD' node; use 'OVL_NEXT' to get the next 'OVERLOAD' node in the 10120list of overloaded functions. The macros 'OVL_CURRENT' and 'OVL_NEXT' 10121are actually polymorphic; you can use them to work with 'FUNCTION_DECL' 10122nodes as well as with overloads. In the case of a 'FUNCTION_DECL', 10123'OVL_CURRENT' will always return the function itself, and 'OVL_NEXT' 10124will always be 'NULL_TREE'. 10125 10126 To determine the scope of a function, you can use the 'DECL_CONTEXT' 10127macro. This macro will return the class (either a 'RECORD_TYPE' or a 10128'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 10129a member. For a virtual function, this macro returns the class in which 10130the function was actually defined, not the base class in which the 10131virtual declaration occurred. 10132 10133 If a friend function is defined in a class scope, the 10134'DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 10135it was defined. For example, in 10136 class C { friend void f() {} }; 10137the 'DECL_CONTEXT' for 'f' will be the 'global_namespace', but the 10138'DECL_FRIEND_CONTEXT' will be the 'RECORD_TYPE' for 'C'. 10139 10140 The following macros and functions can be used on a 'FUNCTION_DECL': 10141'DECL_MAIN_P' 10142 This predicate holds for a function that is the program entry point 10143 '::code'. 10144 10145'DECL_LOCAL_FUNCTION_P' 10146 This predicate holds if the function was declared at block scope, 10147 even though it has a global scope. 10148 10149'DECL_ANTICIPATED' 10150 This predicate holds if the function is a built-in function but its 10151 prototype is not yet explicitly declared. 10152 10153'DECL_EXTERN_C_FUNCTION_P' 10154 This predicate holds if the function is declared as an ''extern 10155 "C"'' function. 10156 10157'DECL_LINKONCE_P' 10158 This macro holds if multiple copies of this function may be emitted 10159 in various translation units. It is the responsibility of the 10160 linker to merge the various copies. Template instantiations are 10161 the most common example of functions for which 'DECL_LINKONCE_P' 10162 holds; G++ instantiates needed templates in all translation units 10163 which require them, and then relies on the linker to remove 10164 duplicate instantiations. 10165 10166 FIXME: This macro is not yet implemented. 10167 10168'DECL_FUNCTION_MEMBER_P' 10169 This macro holds if the function is a member of a class, rather 10170 than a member of a namespace. 10171 10172'DECL_STATIC_FUNCTION_P' 10173 This predicate holds if the function a static member function. 10174 10175'DECL_NONSTATIC_MEMBER_FUNCTION_P' 10176 This macro holds for a non-static member function. 10177 10178'DECL_CONST_MEMFUNC_P' 10179 This predicate holds for a 'const'-member function. 10180 10181'DECL_VOLATILE_MEMFUNC_P' 10182 This predicate holds for a 'volatile'-member function. 10183 10184'DECL_CONSTRUCTOR_P' 10185 This macro holds if the function is a constructor. 10186 10187'DECL_NONCONVERTING_P' 10188 This predicate holds if the constructor is a non-converting 10189 constructor. 10190 10191'DECL_COMPLETE_CONSTRUCTOR_P' 10192 This predicate holds for a function which is a constructor for an 10193 object of a complete type. 10194 10195'DECL_BASE_CONSTRUCTOR_P' 10196 This predicate holds for a function which is a constructor for a 10197 base class sub-object. 10198 10199'DECL_COPY_CONSTRUCTOR_P' 10200 This predicate holds for a function which is a copy-constructor. 10201 10202'DECL_DESTRUCTOR_P' 10203 This macro holds if the function is a destructor. 10204 10205'DECL_COMPLETE_DESTRUCTOR_P' 10206 This predicate holds if the function is the destructor for an 10207 object a complete type. 10208 10209'DECL_OVERLOADED_OPERATOR_P' 10210 This macro holds if the function is an overloaded operator. 10211 10212'DECL_CONV_FN_P' 10213 This macro holds if the function is a type-conversion operator. 10214 10215'DECL_GLOBAL_CTOR_P' 10216 This predicate holds if the function is a file-scope initialization 10217 function. 10218 10219'DECL_GLOBAL_DTOR_P' 10220 This predicate holds if the function is a file-scope finalization 10221 function. 10222 10223'DECL_THUNK_P' 10224 This predicate holds if the function is a thunk. 10225 10226 These functions represent stub code that adjusts the 'this' pointer 10227 and then jumps to another function. When the jumped-to function 10228 returns, control is transferred directly to the caller, without 10229 returning to the thunk. The first parameter to the thunk is always 10230 the 'this' pointer; the thunk should add 'THUNK_DELTA' to this 10231 value. (The 'THUNK_DELTA' is an 'int', not an 'INTEGER_CST'.) 10232 10233 Then, if 'THUNK_VCALL_OFFSET' (an 'INTEGER_CST') is nonzero the 10234 adjusted 'this' pointer must be adjusted again. The complete 10235 calculation is given by the following pseudo-code: 10236 10237 this += THUNK_DELTA 10238 if (THUNK_VCALL_OFFSET) 10239 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 10240 10241 Finally, the thunk should jump to the location given by 10242 'DECL_INITIAL'; this will always be an expression for the address 10243 of a function. 10244 10245'DECL_NON_THUNK_FUNCTION_P' 10246 This predicate holds if the function is _not_ a thunk function. 10247 10248'GLOBAL_INIT_PRIORITY' 10249 If either 'DECL_GLOBAL_CTOR_P' or 'DECL_GLOBAL_DTOR_P' holds, then 10250 this gives the initialization priority for the function. The 10251 linker will arrange that all functions for which 10252 'DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 10253 before 'main' is called. When the program exits, all functions for 10254 which 'DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 10255 10256'TYPE_RAISES_EXCEPTIONS' 10257 This macro returns the list of exceptions that a (member-)function 10258 can raise. The returned list, if non 'NULL', is comprised of nodes 10259 whose 'TREE_VALUE' represents a type. 10260 10261'TYPE_NOTHROW_P' 10262 This predicate holds when the exception-specification of its 10263 arguments is of the form ''()''. 10264 10265'DECL_ARRAY_DELETE_OPERATOR_P' 10266 This predicate holds if the function an overloaded 'operator 10267 delete[]'. 10268 10269 10270File: gccint.info, Node: Statements for C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees 10271 1027210.10.5 Statements for C++ 10273-------------------------- 10274 10275A function that has a definition in the current translation unit will 10276have a non-'NULL' 'DECL_INITIAL'. However, back ends should not make 10277use of the particular value given by 'DECL_INITIAL'. 10278 10279 The 'DECL_SAVED_TREE' macro will give the complete body of the 10280function. 10281 1028210.10.5.1 Statements 10283.................... 10284 10285There are tree nodes corresponding to all of the source-level statement 10286constructs, used within the C and C++ frontends. These are enumerated 10287here, together with a list of the various macros that can be used to 10288obtain information about them. There are a few macros that can be used 10289with all statements: 10290 10291'STMT_IS_FULL_EXPR_P' 10292 In C++, statements normally constitute "full expressions"; 10293 temporaries created during a statement are destroyed when the 10294 statement is complete. However, G++ sometimes represents 10295 expressions by statements; these statements will not have 10296 'STMT_IS_FULL_EXPR_P' set. Temporaries created during such 10297 statements should be destroyed when the innermost enclosing 10298 statement with 'STMT_IS_FULL_EXPR_P' set is exited. 10299 10300 Here is the list of the various statement nodes, and the macros used to 10301access them. This documentation describes the use of these nodes in 10302non-template functions (including instantiations of template functions). 10303In template functions, the same nodes are used, but sometimes in 10304slightly different ways. 10305 10306 Many of the statements have substatements. For example, a 'while' loop 10307will have a body, which is itself a statement. If the substatement is 10308'NULL_TREE', it is considered equivalent to a statement consisting of a 10309single ';', i.e., an expression statement in which the expression has 10310been omitted. A substatement may in fact be a list of statements, 10311connected via their 'TREE_CHAIN's. So, you should always process the 10312statement tree by looping over substatements, like this: 10313 void process_stmt (stmt) 10314 tree stmt; 10315 { 10316 while (stmt) 10317 { 10318 switch (TREE_CODE (stmt)) 10319 { 10320 case IF_STMT: 10321 process_stmt (THEN_CLAUSE (stmt)); 10322 /* More processing here. */ 10323 break; 10324 10325 ... 10326 } 10327 10328 stmt = TREE_CHAIN (stmt); 10329 } 10330 } 10331 In other words, while the 'then' clause of an 'if' statement in C++ can 10332be only one statement (although that one statement may be a compound 10333statement), the intermediate representation will sometimes use several 10334statements chained together. 10335 10336'BREAK_STMT' 10337 10338 Used to represent a 'break' statement. There are no additional 10339 fields. 10340 10341'CILK_SPAWN_STMT' 10342 10343 Used to represent a spawning function in the Cilk Plus language 10344 extension. This tree has one field that holds the name of the 10345 spawning function. '_Cilk_spawn' can be written in C in the 10346 following way: 10347 10348 _Cilk_spawn <function_name> (<parameters>); 10349 10350 Detailed description for usage and functionality of '_Cilk_spawn' 10351 can be found at <https://www.cilkplus.org>. 10352 10353'CILK_SYNC_STMT' 10354 10355 This statement is part of the Cilk Plus language extension. It 10356 indicates that the current function cannot continue in parallel 10357 with its spawned children. There are no additional fields. 10358 '_Cilk_sync' can be written in C in the following way: 10359 10360 _Cilk_sync; 10361 10362'CLEANUP_STMT' 10363 10364 Used to represent an action that should take place upon exit from 10365 the enclosing scope. Typically, these actions are calls to 10366 destructors for local objects, but back ends cannot rely on this 10367 fact. If these nodes are in fact representing such destructors, 10368 'CLEANUP_DECL' will be the 'VAR_DECL' destroyed. Otherwise, 10369 'CLEANUP_DECL' will be 'NULL_TREE'. In any case, the 10370 'CLEANUP_EXPR' is the expression to execute. The cleanups executed 10371 on exit from a scope should be run in the reverse order of the 10372 order in which the associated 'CLEANUP_STMT's were encountered. 10373 10374'CONTINUE_STMT' 10375 10376 Used to represent a 'continue' statement. There are no additional 10377 fields. 10378 10379'CTOR_STMT' 10380 10381 Used to mark the beginning (if 'CTOR_BEGIN_P' holds) or end (if 10382 'CTOR_END_P' holds of the main body of a constructor. See also 10383 'SUBOBJECT' for more information on how to use these nodes. 10384 10385'DO_STMT' 10386 10387 Used to represent a 'do' loop. The body of the loop is given by 10388 'DO_BODY' while the termination condition for the loop is given by 10389 'DO_COND'. The condition for a 'do'-statement is always an 10390 expression. 10391 10392'EMPTY_CLASS_EXPR' 10393 10394 Used to represent a temporary object of a class with no data whose 10395 address is never taken. (All such objects are interchangeable.) 10396 The 'TREE_TYPE' represents the type of the object. 10397 10398'EXPR_STMT' 10399 10400 Used to represent an expression statement. Use 'EXPR_STMT_EXPR' to 10401 obtain the expression. 10402 10403'FOR_STMT' 10404 10405 Used to represent a 'for' statement. The 'FOR_INIT_STMT' is the 10406 initialization statement for the loop. The 'FOR_COND' is the 10407 termination condition. The 'FOR_EXPR' is the expression executed 10408 right before the 'FOR_COND' on each loop iteration; often, this 10409 expression increments a counter. The body of the loop is given by 10410 'FOR_BODY'. Note that 'FOR_INIT_STMT' and 'FOR_BODY' return 10411 statements, while 'FOR_COND' and 'FOR_EXPR' return expressions. 10412 10413'HANDLER' 10414 10415 Used to represent a C++ 'catch' block. The 'HANDLER_TYPE' is the 10416 type of exception that will be caught by this handler; it is equal 10417 (by pointer equality) to 'NULL' if this handler is for all types. 10418 'HANDLER_PARMS' is the 'DECL_STMT' for the catch parameter, and 10419 'HANDLER_BODY' is the code for the block itself. 10420 10421'IF_STMT' 10422 10423 Used to represent an 'if' statement. The 'IF_COND' is the 10424 expression. 10425 10426 If the condition is a 'TREE_LIST', then the 'TREE_PURPOSE' is a 10427 statement (usually a 'DECL_STMT'). Each time the condition is 10428 evaluated, the statement should be executed. Then, the 10429 'TREE_VALUE' should be used as the conditional expression itself. 10430 This representation is used to handle C++ code like this: 10431 10432 C++ distinguishes between this and 'COND_EXPR' for handling 10433 templates. 10434 10435 if (int i = 7) ... 10436 10437 where there is a new local variable (or variables) declared within 10438 the condition. 10439 10440 The 'THEN_CLAUSE' represents the statement given by the 'then' 10441 condition, while the 'ELSE_CLAUSE' represents the statement given 10442 by the 'else' condition. 10443 10444'SUBOBJECT' 10445 10446 In a constructor, these nodes are used to mark the point at which a 10447 subobject of 'this' is fully constructed. If, after this point, an 10448 exception is thrown before a 'CTOR_STMT' with 'CTOR_END_P' set is 10449 encountered, the 'SUBOBJECT_CLEANUP' must be executed. The 10450 cleanups must be executed in the reverse order in which they 10451 appear. 10452 10453'SWITCH_STMT' 10454 10455 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 10456 the expression on which the switch is occurring. See the 10457 documentation for an 'IF_STMT' for more information on the 10458 representation used for the condition. The 'SWITCH_STMT_BODY' is 10459 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 10460 original type of switch expression as given in the source, before 10461 any compiler conversions. 10462 10463'TRY_BLOCK' 10464 Used to represent a 'try' block. The body of the try block is 10465 given by 'TRY_STMTS'. Each of the catch blocks is a 'HANDLER' 10466 node. The first handler is given by 'TRY_HANDLERS'. Subsequent 10467 handlers are obtained by following the 'TREE_CHAIN' link from one 10468 handler to the next. The body of the handler is given by 10469 'HANDLER_BODY'. 10470 10471 If 'CLEANUP_P' holds of the 'TRY_BLOCK', then the 'TRY_HANDLERS' 10472 will not be a 'HANDLER' node. Instead, it will be an expression 10473 that should be executed if an exception is thrown in the try block. 10474 It must rethrow the exception after executing that code. And, if 10475 an exception is thrown while the expression is executing, 10476 'terminate' must be called. 10477 10478'USING_STMT' 10479 Used to represent a 'using' directive. The namespace is given by 10480 'USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 10481 is needed inside template functions, to implement using directives 10482 during instantiation. 10483 10484'WHILE_STMT' 10485 10486 Used to represent a 'while' loop. The 'WHILE_COND' is the 10487 termination condition for the loop. See the documentation for an 10488 'IF_STMT' for more information on the representation used for the 10489 condition. 10490 10491 The 'WHILE_BODY' is the body of the loop. 10492 10493 10494File: gccint.info, Node: C++ Expressions, Prev: Statements for C++, Up: C and C++ Trees 10495 1049610.10.6 C++ Expressions 10497----------------------- 10498 10499This section describes expressions specific to the C and C++ front ends. 10500 10501'TYPEID_EXPR' 10502 10503 Used to represent a 'typeid' expression. 10504 10505'NEW_EXPR' 10506'VEC_NEW_EXPR' 10507 10508 Used to represent a call to 'new' and 'new[]' respectively. 10509 10510'DELETE_EXPR' 10511'VEC_DELETE_EXPR' 10512 10513 Used to represent a call to 'delete' and 'delete[]' respectively. 10514 10515'MEMBER_REF' 10516 10517 Represents a reference to a member of a class. 10518 10519'THROW_EXPR' 10520 10521 Represents an instance of 'throw' in the program. Operand 0, which 10522 is the expression to throw, may be 'NULL_TREE'. 10523 10524'AGGR_INIT_EXPR' 10525 An 'AGGR_INIT_EXPR' represents the initialization as the return 10526 value of a function call, or as the result of a constructor. An 10527 'AGGR_INIT_EXPR' will only appear as a full-expression, or as the 10528 second operand of a 'TARGET_EXPR'. 'AGGR_INIT_EXPR's have a 10529 representation similar to that of 'CALL_EXPR's. You can use the 10530 'AGGR_INIT_EXPR_FN' and 'AGGR_INIT_EXPR_ARG' macros to access the 10531 function to call and the arguments to pass. 10532 10533 If 'AGGR_INIT_VIA_CTOR_P' holds of the 'AGGR_INIT_EXPR', then the 10534 initialization is via a constructor call. The address of the 10535 'AGGR_INIT_EXPR_SLOT' operand, which is always a 'VAR_DECL', is 10536 taken, and this value replaces the first argument in the argument 10537 list. 10538 10539 In either case, the expression is void. 10540 10541 10542File: gccint.info, Node: Java Trees, Prev: C and C++ Trees, Up: GENERIC 10543 1054410.11 Java Trees 10545================ 10546 10547 10548File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top 10549 1055011 GIMPLE 10551********* 10552 10553GIMPLE is a three-address representation derived from GENERIC by 10554breaking down GENERIC expressions into tuples of no more than 3 operands 10555(with some exceptions like function calls). GIMPLE was heavily 10556influenced by the SIMPLE IL used by the McCAT compiler project at McGill 10557University, though we have made some different choices. For one thing, 10558SIMPLE doesn't support 'goto'. 10559 10560 Temporaries are introduced to hold intermediate values needed to 10561compute complex expressions. Additionally, all the control structures 10562used in GENERIC are lowered into conditional jumps, lexical scopes are 10563removed and exception regions are converted into an on the side 10564exception region tree. 10565 10566 The compiler pass which converts GENERIC into GIMPLE is referred to as 10567the 'gimplifier'. The gimplifier works recursively, generating GIMPLE 10568tuples out of the original GENERIC expressions. 10569 10570 One of the early implementation strategies used for the GIMPLE 10571representation was to use the same internal data structures used by 10572front ends to represent parse trees. This simplified implementation 10573because we could leverage existing functionality and interfaces. 10574However, GIMPLE is a much more restrictive representation than abstract 10575syntax trees (AST), therefore it does not require the full structural 10576complexity provided by the main tree data structure. 10577 10578 The GENERIC representation of a function is stored in the 10579'DECL_SAVED_TREE' field of the associated 'FUNCTION_DECL' tree node. It 10580is converted to GIMPLE by a call to 'gimplify_function_tree'. 10581 10582 If a front end wants to include language-specific tree codes in the 10583tree representation which it provides to the back end, it must provide a 10584definition of 'LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 10585front end trees to GIMPLE. Usually such a hook will involve much of the 10586same code for expanding front end trees to RTL. This function can 10587return fully lowered GIMPLE, or it can return GENERIC trees and let the 10588main gimplifier lower them the rest of the way; this is often simpler. 10589GIMPLE that is not fully lowered is known as "High GIMPLE" and consists 10590of the IL before the pass 'pass_lower_cf'. High GIMPLE contains some 10591container statements like lexical scopes (represented by 'GIMPLE_BIND') 10592and nested expressions (e.g., 'GIMPLE_TRY'), while "Low GIMPLE" exposes 10593all of the implicit jumps for control and exception expressions directly 10594in the IL and EH region trees. 10595 10596 The C and C++ front ends currently convert directly from front end 10597trees to GIMPLE, and hand that off to the back end rather than first 10598converting to GENERIC. Their gimplifier hooks know about all the 10599'_STMT' nodes and how to convert them to GENERIC forms. There was some 10600work done on a genericization pass which would run first, but the 10601existence of 'STMT_EXPR' meant that in order to convert all of the C 10602statements into GENERIC equivalents would involve walking the entire 10603tree anyway, so it was simpler to lower all the way. This might change 10604in the future if someone writes an optimization pass which would work 10605better with higher-level trees, but currently the optimizers all expect 10606GIMPLE. 10607 10608 You can request to dump a C-like representation of the GIMPLE form with 10609the flag '-fdump-tree-gimple'. 10610 10611* Menu: 10612 10613* Tuple representation:: 10614* Class hierarchy of GIMPLE statements:: 10615* GIMPLE instruction set:: 10616* GIMPLE Exception Handling:: 10617* Temporaries:: 10618* Operands:: 10619* Manipulating GIMPLE statements:: 10620* Tuple specific accessors:: 10621* GIMPLE sequences:: 10622* Sequence iterators:: 10623* Adding a new GIMPLE statement code:: 10624* Statement and operand traversals:: 10625 10626 10627File: gccint.info, Node: Tuple representation, Next: Class hierarchy of GIMPLE statements, Up: GIMPLE 10628 1062911.1 Tuple representation 10630========================= 10631 10632GIMPLE instructions are tuples of variable size divided in two groups: a 10633header describing the instruction and its locations, and a variable 10634length body with all the operands. Tuples are organized into a 10635hierarchy with 3 main classes of tuples. 10636 1063711.1.1 'gimple_statement_base' (gsbase) 10638--------------------------------------- 10639 10640This is the root of the hierarchy, it holds basic information needed by 10641most GIMPLE statements. There are some fields that may not be relevant 10642to every GIMPLE statement, but those were moved into the base structure 10643to take advantage of holes left by other fields (thus making the 10644structure more compact). The structure takes 4 words (32 bytes) on 64 10645bit hosts: 10646 10647Field Size (bits) 10648'code' 8 10649'subcode' 16 10650'no_warning' 1 10651'visited' 1 10652'nontemporal_move' 1 10653'plf' 2 10654'modified' 1 10655'has_volatile_ops' 1 10656'references_memory_p' 1 10657'uid' 32 10658'location' 32 10659'num_ops' 32 10660'bb' 64 10661'block' 63 10662Total size 32 bytes 10663 10664 * 'code' Main identifier for a GIMPLE instruction. 10665 10666 * 'subcode' Used to distinguish different variants of the same basic 10667 instruction or provide flags applicable to a given code. The 10668 'subcode' flags field has different uses depending on the code of 10669 the instruction, but mostly it distinguishes instructions of the 10670 same family. The most prominent use of this field is in 10671 assignments, where subcode indicates the operation done on the RHS 10672 of the assignment. For example, a = b + c is encoded as 10673 'GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'. 10674 10675 * 'no_warning' Bitflag to indicate whether a warning has already been 10676 issued on this statement. 10677 10678 * 'visited' General purpose "visited" marker. Set and cleared by 10679 each pass when needed. 10680 10681 * 'nontemporal_move' Bitflag used in assignments that represent 10682 non-temporal moves. Although this bitflag is only used in 10683 assignments, it was moved into the base to take advantage of the 10684 bit holes left by the previous fields. 10685 10686 * 'plf' Pass Local Flags. This 2-bit mask can be used as general 10687 purpose markers by any pass. Passes are responsible for clearing 10688 and setting these two flags accordingly. 10689 10690 * 'modified' Bitflag to indicate whether the statement has been 10691 modified. Used mainly by the operand scanner to determine when to 10692 re-scan a statement for operands. 10693 10694 * 'has_volatile_ops' Bitflag to indicate whether this statement 10695 contains operands that have been marked volatile. 10696 10697 * 'references_memory_p' Bitflag to indicate whether this statement 10698 contains memory references (i.e., its operands are either global 10699 variables, or pointer dereferences or anything that must reside in 10700 memory). 10701 10702 * 'uid' This is an unsigned integer used by passes that want to 10703 assign IDs to every statement. These IDs must be assigned and used 10704 by each pass. 10705 10706 * 'location' This is a 'location_t' identifier to specify source code 10707 location for this statement. It is inherited from the front end. 10708 10709 * 'num_ops' Number of operands that this statement has. This 10710 specifies the size of the operand vector embedded in the tuple. 10711 Only used in some tuples, but it is declared in the base tuple to 10712 take advantage of the 32-bit hole left by the previous fields. 10713 10714 * 'bb' Basic block holding the instruction. 10715 10716 * 'block' Lexical block holding this statement. Also used for debug 10717 information generation. 10718 1071911.1.2 'gimple_statement_with_ops' 10720---------------------------------- 10721 10722This tuple is actually split in two: 'gimple_statement_with_ops_base' 10723and 'gimple_statement_with_ops'. This is needed to accommodate the way 10724the operand vector is allocated. The operand vector is defined to be an 10725array of 1 element. So, to allocate a dynamic number of operands, the 10726memory allocator ('gimple_alloc') simply allocates enough memory to hold 10727the structure itself plus 'N - 1' operands which run "off the end" of 10728the structure. For example, to allocate space for a tuple with 3 10729operands, 'gimple_alloc' reserves 'sizeof (struct 10730gimple_statement_with_ops) + 2 * sizeof (tree)' bytes. 10731 10732 On the other hand, several fields in this tuple need to be shared with 10733the 'gimple_statement_with_memory_ops' tuple. So, these common fields 10734are placed in 'gimple_statement_with_ops_base' which is then inherited 10735from the other two tuples. 10736 10737'gsbase' 256 10738'def_ops' 64 10739'use_ops' 64 10740'op' 'num_ops' * 64 10741Total 48 + 8 * 'num_ops' bytes 10742size 10743 10744 * 'gsbase' Inherited from 'struct gimple_statement_base'. 10745 10746 * 'def_ops' Array of pointers into the operand array indicating all 10747 the slots that contain a variable written-to by the statement. 10748 This array is also used for immediate use chaining. Note that it 10749 would be possible to not rely on this array, but the changes 10750 required to implement this are pretty invasive. 10751 10752 * 'use_ops' Similar to 'def_ops' but for variables read by the 10753 statement. 10754 10755 * 'op' Array of trees with 'num_ops' slots. 10756 1075711.1.3 'gimple_statement_with_memory_ops' 10758----------------------------------------- 10759 10760This tuple is essentially identical to 'gimple_statement_with_ops', 10761except that it contains 4 additional fields to hold vectors related 10762memory stores and loads. Similar to the previous case, the structure is 10763split in two to accommodate for the operand vector 10764('gimple_statement_with_memory_ops_base' and 10765'gimple_statement_with_memory_ops'). 10766 10767Field Size (bits) 10768'gsbase' 256 10769'def_ops' 64 10770'use_ops' 64 10771'vdef_ops' 64 10772'vuse_ops' 64 10773'stores' 64 10774'loads' 64 10775'op' 'num_ops' * 64 10776Total size 80 + 8 * 'num_ops' bytes 10777 10778 * 'vdef_ops' Similar to 'def_ops' but for 'VDEF' operators. There is 10779 one entry per memory symbol written by this statement. This is 10780 used to maintain the memory SSA use-def and def-def chains. 10781 10782 * 'vuse_ops' Similar to 'use_ops' but for 'VUSE' operators. There is 10783 one entry per memory symbol loaded by this statement. This is used 10784 to maintain the memory SSA use-def chains. 10785 10786 * 'stores' Bitset with all the UIDs for the symbols written-to by the 10787 statement. This is different than 'vdef_ops' in that all the 10788 affected symbols are mentioned in this set. If memory partitioning 10789 is enabled, the 'vdef_ops' vector will refer to memory partitions. 10790 Furthermore, no SSA information is stored in this set. 10791 10792 * 'loads' Similar to 'stores', but for memory loads. (Note that 10793 there is some amount of redundancy here, it should be possible to 10794 reduce memory utilization further by removing these sets). 10795 10796 All the other tuples are defined in terms of these three basic ones. 10797Each tuple will add some fields. 10798 10799 10800File: gccint.info, Node: Class hierarchy of GIMPLE statements, Next: GIMPLE instruction set, Prev: Tuple representation, Up: GIMPLE 10801 1080211.2 Class hierarchy of GIMPLE statements 10803========================================= 10804 10805The following diagram shows the C++ inheritance hierarchy of statement 10806kinds, along with their relationships to 'GSS_' values (layouts) and 10807'GIMPLE_' values (codes): 10808 10809 gimple_statement_base 10810 | layout: GSS_BASE 10811 | used for 4 codes: GIMPLE_ERROR_MARK 10812 | GIMPLE_NOP 10813 | GIMPLE_OMP_SECTIONS_SWITCH 10814 | GIMPLE_PREDICT 10815 | 10816 + gimple_statement_with_ops_base 10817 | | (no GSS layout) 10818 | | 10819 | + gimple_statement_with_ops 10820 | | | layout: GSS_WITH_OPS 10821 | | | 10822 | | + gcond 10823 | | | code: GIMPLE_COND 10824 | | | 10825 | | + gdebug 10826 | | | code: GIMPLE_DEBUG 10827 | | | 10828 | | + ggoto 10829 | | | code: GIMPLE_GOTO 10830 | | | 10831 | | + glabel 10832 | | | code: GIMPLE_LABEL 10833 | | | 10834 | | + gswitch 10835 | | code: GIMPLE_SWITCH 10836 | | 10837 | + gimple_statement_with_memory_ops_base 10838 | | layout: GSS_WITH_MEM_OPS_BASE 10839 | | 10840 | + gimple_statement_with_memory_ops 10841 | | | layout: GSS_WITH_MEM_OPS 10842 | | | 10843 | | + gassign 10844 | | | code GIMPLE_ASSIGN 10845 | | | 10846 | | + greturn 10847 | | code GIMPLE_RETURN 10848 | | 10849 | + gcall 10850 | | layout: GSS_CALL, code: GIMPLE_CALL 10851 | | 10852 | + gasm 10853 | | layout: GSS_ASM, code: GIMPLE_ASM 10854 | | 10855 | + gtransaction 10856 | layout: GSS_TRANSACTION, code: GIMPLE_TRANSACTION 10857 | 10858 + gimple_statement_omp 10859 | | layout: GSS_OMP. Used for code GIMPLE_OMP_SECTION 10860 | | 10861 | + gomp_critical 10862 | | layout: GSS_OMP_CRITICAL, code: GIMPLE_OMP_CRITICAL 10863 | | 10864 | + gomp_for 10865 | | layout: GSS_OMP_FOR, code: GIMPLE_OMP_FOR 10866 | | 10867 | + gomp_parallel_layout 10868 | | | layout: GSS_OMP_PARALLEL_LAYOUT 10869 | | | 10870 | | + gimple_statement_omp_taskreg 10871 | | | | 10872 | | | + gomp_parallel 10873 | | | | code: GIMPLE_OMP_PARALLEL 10874 | | | | 10875 | | | + gomp_task 10876 | | | code: GIMPLE_OMP_TASK 10877 | | | 10878 | | + gimple_statement_omp_target 10879 | | code: GIMPLE_OMP_TARGET 10880 | | 10881 | + gomp_sections 10882 | | layout: GSS_OMP_SECTIONS, code: GIMPLE_OMP_SECTIONS 10883 | | 10884 | + gimple_statement_omp_single_layout 10885 | | layout: GSS_OMP_SINGLE_LAYOUT 10886 | | 10887 | + gomp_single 10888 | | code: GIMPLE_OMP_SINGLE 10889 | | 10890 | + gomp_teams 10891 | code: GIMPLE_OMP_TEAMS 10892 | 10893 + gbind 10894 | layout: GSS_BIND, code: GIMPLE_BIND 10895 | 10896 + gcatch 10897 | layout: GSS_CATCH, code: GIMPLE_CATCH 10898 | 10899 + geh_filter 10900 | layout: GSS_EH_FILTER, code: GIMPLE_EH_FILTER 10901 | 10902 + geh_else 10903 | layout: GSS_EH_ELSE, code: GIMPLE_EH_ELSE 10904 | 10905 + geh_mnt 10906 | layout: GSS_EH_MNT, code: GIMPLE_EH_MUST_NOT_THROW 10907 | 10908 + gphi 10909 | layout: GSS_PHI, code: GIMPLE_PHI 10910 | 10911 + gimple_statement_eh_ctrl 10912 | | layout: GSS_EH_CTRL 10913 | | 10914 | + gresx 10915 | | code: GIMPLE_RESX 10916 | | 10917 | + geh_dispatch 10918 | code: GIMPLE_EH_DISPATCH 10919 | 10920 + gtry 10921 | layout: GSS_TRY, code: GIMPLE_TRY 10922 | 10923 + gimple_statement_wce 10924 | layout: GSS_WCE, code: GIMPLE_WITH_CLEANUP_EXPR 10925 | 10926 + gomp_continue 10927 | layout: GSS_OMP_CONTINUE, code: GIMPLE_OMP_CONTINUE 10928 | 10929 + gomp_atomic_load 10930 | layout: GSS_OMP_ATOMIC_LOAD, code: GIMPLE_OMP_ATOMIC_LOAD 10931 | 10932 + gimple_statement_omp_atomic_store_layout 10933 | layout: GSS_OMP_ATOMIC_STORE_LAYOUT, 10934 | code: GIMPLE_OMP_ATOMIC_STORE 10935 | 10936 + gomp_atomic_store 10937 | code: GIMPLE_OMP_ATOMIC_STORE 10938 | 10939 + gomp_return 10940 code: GIMPLE_OMP_RETURN 10941 10942 10943File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Class hierarchy of GIMPLE statements, Up: GIMPLE 10944 1094511.3 GIMPLE instruction set 10946=========================== 10947 10948The following table briefly describes the GIMPLE instruction set. 10949 10950Instruction High GIMPLE Low GIMPLE 10951'GIMPLE_ASM' x x 10952'GIMPLE_ASSIGN' x x 10953'GIMPLE_BIND' x 10954'GIMPLE_CALL' x x 10955'GIMPLE_CATCH' x 10956'GIMPLE_COND' x x 10957'GIMPLE_DEBUG' x x 10958'GIMPLE_EH_FILTER' x 10959'GIMPLE_GOTO' x x 10960'GIMPLE_LABEL' x x 10961'GIMPLE_NOP' x x 10962'GIMPLE_OMP_ATOMIC_LOAD' x x 10963'GIMPLE_OMP_ATOMIC_STORE' x x 10964'GIMPLE_OMP_CONTINUE' x x 10965'GIMPLE_OMP_CRITICAL' x x 10966'GIMPLE_OMP_FOR' x x 10967'GIMPLE_OMP_MASTER' x x 10968'GIMPLE_OMP_ORDERED' x x 10969'GIMPLE_OMP_PARALLEL' x x 10970'GIMPLE_OMP_RETURN' x x 10971'GIMPLE_OMP_SECTION' x x 10972'GIMPLE_OMP_SECTIONS' x x 10973'GIMPLE_OMP_SECTIONS_SWITCH' x x 10974'GIMPLE_OMP_SINGLE' x x 10975'GIMPLE_PHI' x 10976'GIMPLE_RESX' x 10977'GIMPLE_RETURN' x x 10978'GIMPLE_SWITCH' x x 10979'GIMPLE_TRY' x 10980 10981 10982File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE 10983 1098411.4 Exception Handling 10985======================= 10986 10987Other exception handling constructs are represented using 10988'GIMPLE_TRY_CATCH'. 'GIMPLE_TRY_CATCH' has two operands. The first 10989operand is a sequence of statements to execute. If executing these 10990statements does not throw an exception, then the second operand is 10991ignored. Otherwise, if an exception is thrown, then the second operand 10992of the 'GIMPLE_TRY_CATCH' is checked. The second operand may have the 10993following forms: 10994 10995 1. A sequence of statements to execute. When an exception occurs, 10996 these statements are executed, and then the exception is rethrown. 10997 10998 2. A sequence of 'GIMPLE_CATCH' statements. Each 'GIMPLE_CATCH' has a 10999 list of applicable exception types and handler code. If the thrown 11000 exception matches one of the caught types, the associated handler 11001 code is executed. If the handler code falls off the bottom, 11002 execution continues after the original 'GIMPLE_TRY_CATCH'. 11003 11004 3. A 'GIMPLE_EH_FILTER' statement. This has a list of permitted 11005 exception types, and code to handle a match failure. If the thrown 11006 exception does not match one of the allowed types, the associated 11007 match failure code is executed. If the thrown exception does 11008 match, it continues unwinding the stack looking for the next 11009 handler. 11010 11011 Currently throwing an exception is not directly represented in GIMPLE, 11012since it is implemented by calling a function. At some point in the 11013future we will want to add some way to express that the call will throw 11014an exception of a known type. 11015 11016 Just before running the optimizers, the compiler lowers the high-level 11017EH constructs above into a set of 'goto's, magic labels, and EH regions. 11018Continuing to unwind at the end of a cleanup is represented with a 11019'GIMPLE_RESX'. 11020 11021 11022File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE 11023 1102411.5 Temporaries 11025================ 11026 11027When gimplification encounters a subexpression that is too complex, it 11028creates a new temporary variable to hold the value of the subexpression, 11029and adds a new statement to initialize it before the current statement. 11030These special temporaries are known as 'expression temporaries', and are 11031allocated using 'get_formal_tmp_var'. The compiler tries to always 11032evaluate identical expressions into the same temporary, to simplify 11033elimination of redundant calculations. 11034 11035 We can only use expression temporaries when we know that it will not be 11036reevaluated before its value is used, and that it will not be otherwise 11037modified(1). Other temporaries can be allocated using 11038'get_initialized_tmp_var' or 'create_tmp_var'. 11039 11040 Currently, an expression like 'a = b + 5' is not reduced any further. 11041We tried converting it to something like 11042 T1 = b + 5; 11043 a = T1; 11044 but this bloated the representation for minimal benefit. However, a 11045variable which must live in memory cannot appear in an expression; its 11046value is explicitly loaded into a temporary first. Similarly, storing 11047the value of an expression to a memory variable goes through a 11048temporary. 11049 11050 ---------- Footnotes ---------- 11051 11052 (1) These restrictions are derived from those in Morgan 4.8. 11053 11054 11055File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE 11056 1105711.6 Operands 11058============= 11059 11060In general, expressions in GIMPLE consist of an operation and the 11061appropriate number of simple operands; these operands must either be a 11062GIMPLE rvalue ('is_gimple_val'), i.e. a constant or a register variable. 11063More complex operands are factored out into temporaries, so that 11064 a = b + c + d 11065 becomes 11066 T1 = b + c; 11067 a = T1 + d; 11068 11069 The same rule holds for arguments to a 'GIMPLE_CALL'. 11070 11071 The target of an assignment is usually a variable, but can also be a 11072'MEM_REF' or a compound lvalue as described below. 11073 11074* Menu: 11075 11076* Compound Expressions:: 11077* Compound Lvalues:: 11078* Conditional Expressions:: 11079* Logical Operators:: 11080 11081 11082File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands 11083 1108411.6.1 Compound Expressions 11085--------------------------- 11086 11087The left-hand side of a C comma expression is simply moved into a 11088separate statement. 11089 11090 11091File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands 11092 1109311.6.2 Compound Lvalues 11094----------------------- 11095 11096Currently compound lvalues involving array and structure field 11097references are not broken down; an expression like 'a.b[2] = 42' is not 11098reduced any further (though complex array subscripts are). This 11099restriction is a workaround for limitations in later optimizers; if we 11100were to convert this to 11101 11102 T1 = &a.b; 11103 T1[2] = 42; 11104 11105 alias analysis would not remember that the reference to 'T1[2]' came by 11106way of 'a.b', so it would think that the assignment could alias another 11107member of 'a'; this broke 'struct-alias-1.c'. Future optimizer 11108improvements may make this limitation unnecessary. 11109 11110 11111File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands 11112 1111311.6.3 Conditional Expressions 11114------------------------------ 11115 11116A C '?:' expression is converted into an 'if' statement with each branch 11117assigning to the same temporary. So, 11118 11119 a = b ? c : d; 11120 becomes 11121 if (b == 1) 11122 T1 = c; 11123 else 11124 T1 = d; 11125 a = T1; 11126 11127 The GIMPLE level if-conversion pass re-introduces '?:' expression, if 11128appropriate. It is used to vectorize loops with conditions using vector 11129conditional operations. 11130 11131 Note that in GIMPLE, 'if' statements are represented using 11132'GIMPLE_COND', as described below. 11133 11134 11135File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands 11136 1113711.6.4 Logical Operators 11138------------------------ 11139 11140Except when they appear in the condition operand of a 'GIMPLE_COND', 11141logical 'and' and 'or' operators are simplified as follows: 'a = b && c' 11142becomes 11143 11144 T1 = (bool)b; 11145 if (T1 == true) 11146 T1 = (bool)c; 11147 a = T1; 11148 11149 Note that 'T1' in this example cannot be an expression temporary, 11150because it has two different assignments. 11151 1115211.6.5 Manipulating operands 11153---------------------------- 11154 11155All gimple operands are of type 'tree'. But only certain types of trees 11156are allowed to be used as operand tuples. Basic validation is 11157controlled by the function 'get_gimple_rhs_class', which given a tree 11158code, returns an 'enum' with the following values of type 'enum 11159gimple_rhs_class' 11160 11161 * 'GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand. 11162 11163 * 'GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation. 11164 11165 * 'GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation. 11166 11167 * 'GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation. 11168 11169 * 'GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be 11170 split into simpler operands (for instance, 'SSA_NAME', 'VAR_DECL', 11171 'COMPONENT_REF', etc). 11172 11173 This operand class also acts as an escape hatch for tree nodes that 11174 may be flattened out into the operand vector, but would need more 11175 than two slots on the RHS. For instance, a 'COND_EXPR' expression 11176 of the form '(a op b) ? x : y' could be flattened out on the 11177 operand vector using 4 slots, but it would also require additional 11178 processing to distinguish 'c = a op b' from 'c = a op b ? x : y'. 11179 Something similar occurs with 'ASSERT_EXPR'. In time, these 11180 special case tree expressions should be flattened into the operand 11181 vector. 11182 11183 For tree nodes in the categories 'GIMPLE_TERNARY_RHS', 11184'GIMPLE_BINARY_RHS' and 'GIMPLE_UNARY_RHS', they cannot be stored inside 11185tuples directly. They first need to be flattened and separated into 11186individual components. For instance, given the GENERIC expression 11187 11188 a = b + c 11189 11190 its tree representation is: 11191 11192 MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> 11193 11194 In this case, the GIMPLE form for this statement is logically identical 11195to its GENERIC form but in GIMPLE, the 'PLUS_EXPR' on the RHS of the 11196assignment is not represented as a tree, instead the two operands are 11197taken out of the 'PLUS_EXPR' sub-tree and flattened into the GIMPLE 11198tuple as follows: 11199 11200 GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> 11201 1120211.6.6 Operand vector allocation 11203-------------------------------- 11204 11205The operand vector is stored at the bottom of the three tuple structures 11206that accept operands. This means, that depending on the code of a given 11207statement, its operand vector will be at different offsets from the base 11208of the structure. To access tuple operands use the following accessors 11209 11210 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 11211 Returns the number of operands in statement G. 11212 11213 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 11214 Returns operand 'I' from statement 'G'. 11215 11216 -- GIMPLE function: tree * gimple_ops (gimple g) 11217 Returns a pointer into the operand vector for statement 'G'. This 11218 is computed using an internal table called 'gimple_ops_offset_'[]. 11219 This table is indexed by the gimple code of 'G'. 11220 11221 When the compiler is built, this table is filled-in using the sizes 11222 of the structures used by each statement code defined in 11223 gimple.def. Since the operand vector is at the bottom of the 11224 structure, for a gimple code 'C' the offset is computed as sizeof 11225 (struct-of 'C') - sizeof (tree). 11226 11227 This mechanism adds one memory indirection to every access when 11228 using 'gimple_op'(), if this becomes a bottleneck, a pass can 11229 choose to memoize the result from 'gimple_ops'() and use that to 11230 access the operands. 11231 1123211.6.7 Operand validation 11233------------------------- 11234 11235When adding a new operand to a gimple statement, the operand will be 11236validated according to what each tuple accepts in its operand vector. 11237These predicates are called by the 'gimple_NAME_set_...()'. Each tuple 11238will use one of the following predicates (Note, this list is not 11239exhaustive): 11240 11241 -- GIMPLE function: bool is_gimple_val (tree t) 11242 Returns true if t is a "GIMPLE value", which are all the 11243 non-addressable stack variables (variables for which 11244 'is_gimple_reg' returns true) and constants (expressions for which 11245 'is_gimple_min_invariant' returns true). 11246 11247 -- GIMPLE function: bool is_gimple_addressable (tree t) 11248 Returns true if t is a symbol or memory reference whose address can 11249 be taken. 11250 11251 -- GIMPLE function: bool is_gimple_asm_val (tree t) 11252 Similar to 'is_gimple_val' but it also accepts hard registers. 11253 11254 -- GIMPLE function: bool is_gimple_call_addr (tree t) 11255 Return true if t is a valid expression to use as the function 11256 called by a 'GIMPLE_CALL'. 11257 11258 -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t) 11259 Return true if t is a valid expression to use as first operand of a 11260 'MEM_REF' expression. 11261 11262 -- GIMPLE function: bool is_gimple_constant (tree t) 11263 Return true if t is a valid gimple constant. 11264 11265 -- GIMPLE function: bool is_gimple_min_invariant (tree t) 11266 Return true if t is a valid minimal invariant. This is different 11267 from constants, in that the specific value of t may not be known at 11268 compile time, but it is known that it doesn't change (e.g., the 11269 address of a function local variable). 11270 11271 -- GIMPLE function: bool is_gimple_ip_invariant (tree t) 11272 Return true if t is an interprocedural invariant. This means that 11273 t is a valid invariant in all functions (e.g. it can be an address 11274 of a global variable but not of a local one). 11275 11276 -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t) 11277 Return true if t is an 'ADDR_EXPR' that does not change once the 11278 program is running (and which is valid in all functions). 11279 1128011.6.8 Statement validation 11281--------------------------- 11282 11283 -- GIMPLE function: bool is_gimple_assign (gimple g) 11284 Return true if the code of g is 'GIMPLE_ASSIGN'. 11285 11286 -- GIMPLE function: bool is_gimple_call (gimple g) 11287 Return true if the code of g is 'GIMPLE_CALL'. 11288 11289 -- GIMPLE function: bool is_gimple_debug (gimple g) 11290 Return true if the code of g is 'GIMPLE_DEBUG'. 11291 11292 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple g) 11293 Return true if g is a 'GIMPLE_ASSIGN' that performs a type cast 11294 operation. 11295 11296 -- GIMPLE function: bool gimple_debug_bind_p (gimple g) 11297 Return true if g is a 'GIMPLE_DEBUG' that binds the value of an 11298 expression to a variable. 11299 11300 -- GIMPLE function: bool is_gimple_omp (gimple g) 11301 Return true if g is any of the OpenMP codes. 11302 11303 11304File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE 11305 1130611.7 Manipulating GIMPLE statements 11307=================================== 11308 11309This section documents all the functions available to handle each of the 11310GIMPLE instructions. 11311 1131211.7.1 Common accessors 11313----------------------- 11314 11315The following are common accessors for gimple statements. 11316 11317 -- GIMPLE function: enum gimple_code gimple_code (gimple g) 11318 Return the code for statement 'G'. 11319 11320 -- GIMPLE function: basic_block gimple_bb (gimple g) 11321 Return the basic block to which statement 'G' belongs to. 11322 11323 -- GIMPLE function: tree gimple_block (gimple g) 11324 Return the lexical scope block holding statement 'G'. 11325 11326 -- GIMPLE function: tree gimple_expr_type (gimple stmt) 11327 Return the type of the main expression computed by 'STMT'. Return 11328 'void_type_node' if 'STMT' computes nothing. This will only return 11329 something meaningful for 'GIMPLE_ASSIGN', 'GIMPLE_COND' and 11330 'GIMPLE_CALL'. For all other tuple codes, it will return 11331 'void_type_node'. 11332 11333 -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt) 11334 Return the tree code for the expression computed by 'STMT'. This 11335 is only meaningful for 'GIMPLE_CALL', 'GIMPLE_ASSIGN' and 11336 'GIMPLE_COND'. If 'STMT' is 'GIMPLE_CALL', it will return 11337 'CALL_EXPR'. For 'GIMPLE_COND', it returns the code of the 11338 comparison predicate. For 'GIMPLE_ASSIGN' it returns the code of 11339 the operation performed by the 'RHS' of the assignment. 11340 11341 -- GIMPLE function: void gimple_set_block (gimple g, tree block) 11342 Set the lexical scope block of 'G' to 'BLOCK'. 11343 11344 -- GIMPLE function: location_t gimple_locus (gimple g) 11345 Return locus information for statement 'G'. 11346 11347 -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus) 11348 Set locus information for statement 'G'. 11349 11350 -- GIMPLE function: bool gimple_locus_empty_p (gimple g) 11351 Return true if 'G' does not have locus information. 11352 11353 -- GIMPLE function: bool gimple_no_warning_p (gimple stmt) 11354 Return true if no warnings should be emitted for statement 'STMT'. 11355 11356 -- GIMPLE function: void gimple_set_visited (gimple stmt, bool 11357 visited_p) 11358 Set the visited status on statement 'STMT' to 'VISITED_P'. 11359 11360 -- GIMPLE function: bool gimple_visited_p (gimple stmt) 11361 Return the visited status on statement 'STMT'. 11362 11363 -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask 11364 plf, bool val_p) 11365 Set pass local flag 'PLF' on statement 'STMT' to 'VAL_P'. 11366 11367 -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum plf_mask 11368 plf) 11369 Return the value of pass local flag 'PLF' on statement 'STMT'. 11370 11371 -- GIMPLE function: bool gimple_has_ops (gimple g) 11372 Return true if statement 'G' has register or memory operands. 11373 11374 -- GIMPLE function: bool gimple_has_mem_ops (gimple g) 11375 Return true if statement 'G' has memory operands. 11376 11377 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 11378 Return the number of operands for statement 'G'. 11379 11380 -- GIMPLE function: tree * gimple_ops (gimple g) 11381 Return the array of operands for statement 'G'. 11382 11383 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 11384 Return operand 'I' for statement 'G'. 11385 11386 -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i) 11387 Return a pointer to operand 'I' for statement 'G'. 11388 11389 -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op) 11390 Set operand 'I' of statement 'G' to 'OP'. 11391 11392 -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt) 11393 Return the set of symbols that have had their address taken by 11394 'STMT'. 11395 11396 -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g) 11397 Return the set of 'DEF' operands for statement 'G'. 11398 11399 -- GIMPLE function: void gimple_set_def_ops (gimple g, struct 11400 def_optype_d *def) 11401 Set 'DEF' to be the set of 'DEF' operands for statement 'G'. 11402 11403 -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g) 11404 Return the set of 'USE' operands for statement 'G'. 11405 11406 -- GIMPLE function: void gimple_set_use_ops (gimple g, struct 11407 use_optype_d *use) 11408 Set 'USE' to be the set of 'USE' operands for statement 'G'. 11409 11410 -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g) 11411 Return the set of 'VUSE' operands for statement 'G'. 11412 11413 -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct 11414 voptype_d *ops) 11415 Set 'OPS' to be the set of 'VUSE' operands for statement 'G'. 11416 11417 -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g) 11418 Return the set of 'VDEF' operands for statement 'G'. 11419 11420 -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct 11421 voptype_d *ops) 11422 Set 'OPS' to be the set of 'VDEF' operands for statement 'G'. 11423 11424 -- GIMPLE function: bitmap gimple_loaded_syms (gimple g) 11425 Return the set of symbols loaded by statement 'G'. Each element of 11426 the set is the 'DECL_UID' of the corresponding symbol. 11427 11428 -- GIMPLE function: bitmap gimple_stored_syms (gimple g) 11429 Return the set of symbols stored by statement 'G'. Each element of 11430 the set is the 'DECL_UID' of the corresponding symbol. 11431 11432 -- GIMPLE function: bool gimple_modified_p (gimple g) 11433 Return true if statement 'G' has operands and the modified field 11434 has been set. 11435 11436 -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt) 11437 Return true if statement 'STMT' contains volatile operands. 11438 11439 -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, bool 11440 volatilep) 11441 Return true if statement 'STMT' contains volatile operands. 11442 11443 -- GIMPLE function: void update_stmt (gimple s) 11444 Mark statement 'S' as modified, and update it. 11445 11446 -- GIMPLE function: void update_stmt_if_modified (gimple s) 11447 Update statement 'S' if it has been marked modified. 11448 11449 -- GIMPLE function: gimple gimple_copy (gimple stmt) 11450 Return a deep copy of statement 'STMT'. 11451 11452 11453File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE 11454 1145511.8 Tuple specific accessors 11456============================= 11457 11458* Menu: 11459 11460* GIMPLE_ASM:: 11461* GIMPLE_ASSIGN:: 11462* GIMPLE_BIND:: 11463* GIMPLE_CALL:: 11464* GIMPLE_CATCH:: 11465* GIMPLE_COND:: 11466* GIMPLE_DEBUG:: 11467* GIMPLE_EH_FILTER:: 11468* GIMPLE_LABEL:: 11469* GIMPLE_GOTO:: 11470* GIMPLE_NOP:: 11471* GIMPLE_OMP_ATOMIC_LOAD:: 11472* GIMPLE_OMP_ATOMIC_STORE:: 11473* GIMPLE_OMP_CONTINUE:: 11474* GIMPLE_OMP_CRITICAL:: 11475* GIMPLE_OMP_FOR:: 11476* GIMPLE_OMP_MASTER:: 11477* GIMPLE_OMP_ORDERED:: 11478* GIMPLE_OMP_PARALLEL:: 11479* GIMPLE_OMP_RETURN:: 11480* GIMPLE_OMP_SECTION:: 11481* GIMPLE_OMP_SECTIONS:: 11482* GIMPLE_OMP_SINGLE:: 11483* GIMPLE_PHI:: 11484* GIMPLE_RESX:: 11485* GIMPLE_RETURN:: 11486* GIMPLE_SWITCH:: 11487* GIMPLE_TRY:: 11488* GIMPLE_WITH_CLEANUP_EXPR:: 11489 11490 11491File: gccint.info, Node: GIMPLE_ASM, Next: GIMPLE_ASSIGN, Up: Tuple specific accessors 11492 1149311.8.1 'GIMPLE_ASM' 11494------------------- 11495 11496 -- GIMPLE function: gasm *gimple_build_asm_vec ( const char *string, 11497 vec<tree, va_gc> *inputs, vec<tree, va_gc> *outputs, vec<tree, 11498 va_gc> *clobbers, vec<tree, va_gc> *labels) 11499 Build a 'GIMPLE_ASM' statement. This statement is used for 11500 building in-line assembly constructs. 'STRING' is the assembly 11501 code. 'INPUTS', 'OUTPUTS', 'CLOBBERS' and 'LABELS' are the inputs, 11502 outputs, clobbered registers and labels. 11503 11504 -- GIMPLE function: unsigned gimple_asm_ninputs (const gasm *g) 11505 Return the number of input operands for 'GIMPLE_ASM' 'G'. 11506 11507 -- GIMPLE function: unsigned gimple_asm_noutputs (const gasm *g) 11508 Return the number of output operands for 'GIMPLE_ASM' 'G'. 11509 11510 -- GIMPLE function: unsigned gimple_asm_nclobbers (const gasm *g) 11511 Return the number of clobber operands for 'GIMPLE_ASM' 'G'. 11512 11513 -- GIMPLE function: tree gimple_asm_input_op (const gasm *g, unsigned 11514 index) 11515 Return input operand 'INDEX' of 'GIMPLE_ASM' 'G'. 11516 11517 -- GIMPLE function: void gimple_asm_set_input_op (gasm *g, unsigned 11518 index, tree in_op) 11519 Set 'IN_OP' to be input operand 'INDEX' in 'GIMPLE_ASM' 'G'. 11520 11521 -- GIMPLE function: tree gimple_asm_output_op (const gasm *g, unsigned 11522 index) 11523 Return output operand 'INDEX' of 'GIMPLE_ASM' 'G'. 11524 11525 -- GIMPLE function: void gimple_asm_set_output_op (gasm *g, unsigned 11526 index, tree out_op) 11527 Set 'OUT_OP' to be output operand 'INDEX' in 'GIMPLE_ASM' 'G'. 11528 11529 -- GIMPLE function: tree gimple_asm_clobber_op (const gasm *g, unsigned 11530 index) 11531 Return clobber operand 'INDEX' of 'GIMPLE_ASM' 'G'. 11532 11533 -- GIMPLE function: void gimple_asm_set_clobber_op (gasm *g, unsigned 11534 index, tree clobber_op) 11535 Set 'CLOBBER_OP' to be clobber operand 'INDEX' in 'GIMPLE_ASM' 'G'. 11536 11537 -- GIMPLE function: const char * gimple_asm_string (const gasm *g) 11538 Return the string representing the assembly instruction in 11539 'GIMPLE_ASM' 'G'. 11540 11541 -- GIMPLE function: bool gimple_asm_volatile_p (const gasm *g) 11542 Return true if 'G' is an asm statement marked volatile. 11543 11544 -- GIMPLE function: void gimple_asm_set_volatile (gasm *g, bool 11545 volatile_p) 11546 Mark asm statement 'G' as volatile or non-volatile based on 11547 'VOLATILE_P'. 11548 11549 11550File: gccint.info, Node: GIMPLE_ASSIGN, Next: GIMPLE_BIND, Prev: GIMPLE_ASM, Up: Tuple specific accessors 11551 1155211.8.2 'GIMPLE_ASSIGN' 11553---------------------- 11554 11555 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, tree rhs) 11556 Build a 'GIMPLE_ASSIGN' statement. The left-hand side is an lvalue 11557 passed in lhs. The right-hand side can be either a unary or binary 11558 tree expression. The expression tree rhs will be flattened and its 11559 operands assigned to the corresponding operand slots in the new 11560 statement. This function is useful when you already have a tree 11561 expression that you want to convert into a tuple. However, try to 11562 avoid building expression trees for the sole purpose of calling 11563 this function. If you already have the operands in separate trees, 11564 it is better to use 'gimple_build_assign' with 'enum tree_code' 11565 argument and separate arguments for each operand. 11566 11567 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 11568 tree_code subcode, tree op1, tree op2, tree op3) 11569 This function is similar to two operand 'gimple_build_assign', but 11570 is used to build a 'GIMPLE_ASSIGN' statement when the operands of 11571 the right-hand side of the assignment are already split into 11572 different operands. 11573 11574 The left-hand side is an lvalue passed in lhs. Subcode is the 11575 'tree_code' for the right-hand side of the assignment. Op1, op2 11576 and op3 are the operands. 11577 11578 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 11579 tree_code subcode, tree op1, tree op2) 11580 Like the above 5 operand 'gimple_build_assign', but with the last 11581 argument 'NULL' - this overload should not be used for 11582 'GIMPLE_TERNARY_RHS' assignments. 11583 11584 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 11585 tree_code subcode, tree op1) 11586 Like the above 4 operand 'gimple_build_assign', but with the last 11587 argument 'NULL' - this overload should be used only for 11588 'GIMPLE_UNARY_RHS' and 'GIMPLE_SINGLE_RHS' assignments. 11589 11590 -- GIMPLE function: gimple gimplify_assign (tree dst, tree src, 11591 gimple_seq *seq_p) 11592 Build a new 'GIMPLE_ASSIGN' tuple and append it to the end of 11593 '*SEQ_P'. 11594 11595 'DST'/'SRC' are the destination and source respectively. You can pass 11596ungimplified trees in 'DST' or 'SRC', in which case they will be 11597converted to a gimple operand if necessary. 11598 11599 This function returns the newly created 'GIMPLE_ASSIGN' tuple. 11600 11601 -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g) 11602 Return the code of the expression computed on the 'RHS' of 11603 assignment statement 'G'. 11604 11605 -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class 11606 (gimple g) 11607 Return the gimple rhs class of the code for the expression computed 11608 on the rhs of assignment statement 'G'. This will never return 11609 'GIMPLE_INVALID_RHS'. 11610 11611 -- GIMPLE function: tree gimple_assign_lhs (gimple g) 11612 Return the 'LHS' of assignment statement 'G'. 11613 11614 -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g) 11615 Return a pointer to the 'LHS' of assignment statement 'G'. 11616 11617 -- GIMPLE function: tree gimple_assign_rhs1 (gimple g) 11618 Return the first operand on the 'RHS' of assignment statement 'G'. 11619 11620 -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g) 11621 Return the address of the first operand on the 'RHS' of assignment 11622 statement 'G'. 11623 11624 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 11625 Return the second operand on the 'RHS' of assignment statement 'G'. 11626 11627 -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g) 11628 Return the address of the second operand on the 'RHS' of assignment 11629 statement 'G'. 11630 11631 -- GIMPLE function: tree gimple_assign_rhs3 (gimple g) 11632 Return the third operand on the 'RHS' of assignment statement 'G'. 11633 11634 -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g) 11635 Return the address of the third operand on the 'RHS' of assignment 11636 statement 'G'. 11637 11638 -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs) 11639 Set 'LHS' to be the 'LHS' operand of assignment statement 'G'. 11640 11641 -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs) 11642 Set 'RHS' to be the first operand on the 'RHS' of assignment 11643 statement 'G'. 11644 11645 -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs) 11646 Set 'RHS' to be the second operand on the 'RHS' of assignment 11647 statement 'G'. 11648 11649 -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs) 11650 Set 'RHS' to be the third operand on the 'RHS' of assignment 11651 statement 'G'. 11652 11653 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple s) 11654 Return true if 'S' is a type-cast assignment. 11655 11656 11657File: gccint.info, Node: GIMPLE_BIND, Next: GIMPLE_CALL, Prev: GIMPLE_ASSIGN, Up: Tuple specific accessors 11658 1165911.8.3 'GIMPLE_BIND' 11660-------------------- 11661 11662 -- GIMPLE function: gbind *gimple_build_bind (tree vars, gimple_seq 11663 body) 11664 Build a 'GIMPLE_BIND' statement with a list of variables in 'VARS' 11665 and a body of statements in sequence 'BODY'. 11666 11667 -- GIMPLE function: tree gimple_bind_vars (const gbind *g) 11668 Return the variables declared in the 'GIMPLE_BIND' statement 'G'. 11669 11670 -- GIMPLE function: void gimple_bind_set_vars (gbind *g, tree vars) 11671 Set 'VARS' to be the set of variables declared in the 'GIMPLE_BIND' 11672 statement 'G'. 11673 11674 -- GIMPLE function: void gimple_bind_append_vars (gbind *g, tree vars) 11675 Append 'VARS' to the set of variables declared in the 'GIMPLE_BIND' 11676 statement 'G'. 11677 11678 -- GIMPLE function: gimple_seq gimple_bind_body (gbind *g) 11679 Return the GIMPLE sequence contained in the 'GIMPLE_BIND' statement 11680 'G'. 11681 11682 -- GIMPLE function: void gimple_bind_set_body (gbind *g, gimple_seq 11683 seq) 11684 Set 'SEQ' to be sequence contained in the 'GIMPLE_BIND' statement 11685 'G'. 11686 11687 -- GIMPLE function: void gimple_bind_add_stmt (gbind *gs, gimple stmt) 11688 Append a statement to the end of a 'GIMPLE_BIND''s body. 11689 11690 -- GIMPLE function: void gimple_bind_add_seq (gbind *gs, gimple_seq 11691 seq) 11692 Append a sequence of statements to the end of a 'GIMPLE_BIND''s 11693 body. 11694 11695 -- GIMPLE function: tree gimple_bind_block (const gbind *g) 11696 Return the 'TREE_BLOCK' node associated with 'GIMPLE_BIND' 11697 statement 'G'. This is analogous to the 'BIND_EXPR_BLOCK' field in 11698 trees. 11699 11700 -- GIMPLE function: void gimple_bind_set_block (gbind *g, tree block) 11701 Set 'BLOCK' to be the 'TREE_BLOCK' node associated with 11702 'GIMPLE_BIND' statement 'G'. 11703 11704 11705File: gccint.info, Node: GIMPLE_CALL, Next: GIMPLE_CATCH, Prev: GIMPLE_BIND, Up: Tuple specific accessors 11706 1170711.8.4 'GIMPLE_CALL' 11708-------------------- 11709 11710 -- GIMPLE function: gcall *gimple_build_call (tree fn, unsigned nargs, 11711 ...) 11712 Build a 'GIMPLE_CALL' statement to function 'FN'. The argument 11713 'FN' must be either a 'FUNCTION_DECL' or a gimple call address as 11714 determined by 'is_gimple_call_addr'. 'NARGS' are the number of 11715 arguments. The rest of the arguments follow the argument 'NARGS', 11716 and must be trees that are valid as rvalues in gimple (i.e., each 11717 operand is validated with 'is_gimple_operand'). 11718 11719 -- GIMPLE function: gcall *gimple_build_call_from_tree (tree call_expr) 11720 Build a 'GIMPLE_CALL' from a 'CALL_EXPR' node. The arguments and 11721 the function are taken from the expression directly. This routine 11722 assumes that 'call_expr' is already in GIMPLE form. That is, its 11723 operands are GIMPLE values and the function call needs no further 11724 simplification. All the call flags in 'call_expr' are copied over 11725 to the new 'GIMPLE_CALL'. 11726 11727 -- GIMPLE function: gcall *gimple_build_call_vec (tree fn, 'vec<tree>' 11728 args) 11729 Identical to 'gimple_build_call' but the arguments are stored in a 11730 'vec<tree>'. 11731 11732 -- GIMPLE function: tree gimple_call_lhs (gimple g) 11733 Return the 'LHS' of call statement 'G'. 11734 11735 -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g) 11736 Return a pointer to the 'LHS' of call statement 'G'. 11737 11738 -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs) 11739 Set 'LHS' to be the 'LHS' operand of call statement 'G'. 11740 11741 -- GIMPLE function: tree gimple_call_fn (gimple g) 11742 Return the tree node representing the function called by call 11743 statement 'G'. 11744 11745 -- GIMPLE function: void gimple_call_set_fn (gcall *g, tree fn) 11746 Set 'FN' to be the function called by call statement 'G'. This has 11747 to be a gimple value specifying the address of the called function. 11748 11749 -- GIMPLE function: tree gimple_call_fndecl (gimple g) 11750 If a given 'GIMPLE_CALL''s callee is a 'FUNCTION_DECL', return it. 11751 Otherwise return 'NULL'. This function is analogous to 11752 'get_callee_fndecl' in 'GENERIC'. 11753 11754 -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl) 11755 Set the called function to 'FNDECL'. 11756 11757 -- GIMPLE function: tree gimple_call_return_type (const gcall *g) 11758 Return the type returned by call statement 'G'. 11759 11760 -- GIMPLE function: tree gimple_call_chain (gimple g) 11761 Return the static chain for call statement 'G'. 11762 11763 -- GIMPLE function: void gimple_call_set_chain (gcall *g, tree chain) 11764 Set 'CHAIN' to be the static chain for call statement 'G'. 11765 11766 -- GIMPLE function: unsigned gimple_call_num_args (gimple g) 11767 Return the number of arguments used by call statement 'G'. 11768 11769 -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index) 11770 Return the argument at position 'INDEX' for call statement 'G'. 11771 The first argument is 0. 11772 11773 -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned 11774 index) 11775 Return a pointer to the argument at position 'INDEX' for call 11776 statement 'G'. 11777 11778 -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned index, 11779 tree arg) 11780 Set 'ARG' to be the argument at position 'INDEX' for call statement 11781 'G'. 11782 11783 -- GIMPLE function: void gimple_call_set_tail (gcall *s) 11784 Mark call statement 'S' as being a tail call (i.e., a call just 11785 before the exit of a function). These calls are candidate for tail 11786 call optimization. 11787 11788 -- GIMPLE function: bool gimple_call_tail_p (gcall *s) 11789 Return true if 'GIMPLE_CALL' 'S' is marked as a tail call. 11790 11791 -- GIMPLE function: bool gimple_call_noreturn_p (gimple s) 11792 Return true if 'S' is a noreturn call. 11793 11794 -- GIMPLE function: gimple gimple_call_copy_skip_args (gcall *stmt, 11795 bitmap args_to_skip) 11796 Build a 'GIMPLE_CALL' identical to 'STMT' but skipping the 11797 arguments in the positions marked by the set 'ARGS_TO_SKIP'. 11798 11799 11800File: gccint.info, Node: GIMPLE_CATCH, Next: GIMPLE_COND, Prev: GIMPLE_CALL, Up: Tuple specific accessors 11801 1180211.8.5 'GIMPLE_CATCH' 11803--------------------- 11804 11805 -- GIMPLE function: gcatch *gimple_build_catch (tree types, gimple_seq 11806 handler) 11807 Build a 'GIMPLE_CATCH' statement. 'TYPES' are the tree types this 11808 catch handles. 'HANDLER' is a sequence of statements with the code 11809 for the handler. 11810 11811 -- GIMPLE function: tree gimple_catch_types (const gcatch *g) 11812 Return the types handled by 'GIMPLE_CATCH' statement 'G'. 11813 11814 -- GIMPLE function: tree * gimple_catch_types_ptr (gcatch *g) 11815 Return a pointer to the types handled by 'GIMPLE_CATCH' statement 11816 'G'. 11817 11818 -- GIMPLE function: gimple_seq gimple_catch_handler (gcatch *g) 11819 Return the GIMPLE sequence representing the body of the handler of 11820 'GIMPLE_CATCH' statement 'G'. 11821 11822 -- GIMPLE function: void gimple_catch_set_types (gcatch *g, tree t) 11823 Set 'T' to be the set of types handled by 'GIMPLE_CATCH' 'G'. 11824 11825 -- GIMPLE function: void gimple_catch_set_handler (gcatch *g, 11826 gimple_seq handler) 11827 Set 'HANDLER' to be the body of 'GIMPLE_CATCH' 'G'. 11828 11829 11830File: gccint.info, Node: GIMPLE_COND, Next: GIMPLE_DEBUG, Prev: GIMPLE_CATCH, Up: Tuple specific accessors 11831 1183211.8.6 'GIMPLE_COND' 11833-------------------- 11834 11835 -- GIMPLE function: gcond *gimple_build_cond ( enum tree_code 11836 pred_code, tree lhs, tree rhs, tree t_label, tree f_label) 11837 Build a 'GIMPLE_COND' statement. 'A' 'GIMPLE_COND' statement 11838 compares 'LHS' and 'RHS' and if the condition in 'PRED_CODE' is 11839 true, jump to the label in 't_label', otherwise jump to the label 11840 in 'f_label'. 'PRED_CODE' are relational operator tree codes like 11841 'EQ_EXPR', 'LT_EXPR', 'LE_EXPR', 'NE_EXPR', etc. 11842 11843 -- GIMPLE function: gcond *gimple_build_cond_from_tree (tree cond, tree 11844 t_label, tree f_label) 11845 Build a 'GIMPLE_COND' statement from the conditional expression 11846 tree 'COND'. 'T_LABEL' and 'F_LABEL' are as in 11847 'gimple_build_cond'. 11848 11849 -- GIMPLE function: enum tree_code gimple_cond_code (gimple g) 11850 Return the code of the predicate computed by conditional statement 11851 'G'. 11852 11853 -- GIMPLE function: void gimple_cond_set_code (gcond *g, enum tree_code 11854 code) 11855 Set 'CODE' to be the predicate code for the conditional statement 11856 'G'. 11857 11858 -- GIMPLE function: tree gimple_cond_lhs (gimple g) 11859 Return the 'LHS' of the predicate computed by conditional statement 11860 'G'. 11861 11862 -- GIMPLE function: void gimple_cond_set_lhs (gcond *g, tree lhs) 11863 Set 'LHS' to be the 'LHS' operand of the predicate computed by 11864 conditional statement 'G'. 11865 11866 -- GIMPLE function: tree gimple_cond_rhs (gimple g) 11867 Return the 'RHS' operand of the predicate computed by conditional 11868 'G'. 11869 11870 -- GIMPLE function: void gimple_cond_set_rhs (gcond *g, tree rhs) 11871 Set 'RHS' to be the 'RHS' operand of the predicate computed by 11872 conditional statement 'G'. 11873 11874 -- GIMPLE function: tree gimple_cond_true_label (const gcond *g) 11875 Return the label used by conditional statement 'G' when its 11876 predicate evaluates to true. 11877 11878 -- GIMPLE function: void gimple_cond_set_true_label (gcond *g, tree 11879 label) 11880 Set 'LABEL' to be the label used by conditional statement 'G' when 11881 its predicate evaluates to true. 11882 11883 -- GIMPLE function: void gimple_cond_set_false_label (gcond *g, tree 11884 label) 11885 Set 'LABEL' to be the label used by conditional statement 'G' when 11886 its predicate evaluates to false. 11887 11888 -- GIMPLE function: tree gimple_cond_false_label (const gcond *g) 11889 Return the label used by conditional statement 'G' when its 11890 predicate evaluates to false. 11891 11892 -- GIMPLE function: void gimple_cond_make_false (gcond *g) 11893 Set the conditional 'COND_STMT' to be of the form 'if (1 == 0)'. 11894 11895 -- GIMPLE function: void gimple_cond_make_true (gcond *g) 11896 Set the conditional 'COND_STMT' to be of the form 'if (1 == 1)'. 11897 11898 11899File: gccint.info, Node: GIMPLE_DEBUG, Next: GIMPLE_EH_FILTER, Prev: GIMPLE_COND, Up: Tuple specific accessors 11900 1190111.8.7 'GIMPLE_DEBUG' 11902--------------------- 11903 11904 -- GIMPLE function: gdebug *gimple_build_debug_bind (tree var, tree 11905 value, gimple stmt) 11906 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BIND' of 11907 'subcode'. The effect of this statement is to tell debug 11908 information generation machinery that the value of user variable 11909 'var' is given by 'value' at that point, and to remain with that 11910 value until 'var' runs out of scope, a dynamically-subsequent debug 11911 bind statement overrides the binding, or conflicting values reach a 11912 control flow merge point. Even if components of the 'value' 11913 expression change afterwards, the variable is supposed to retain 11914 the same value, though not necessarily the same location. 11915 11916 It is expected that 'var' be most often a tree for automatic user 11917 variables ('VAR_DECL' or 'PARM_DECL') that satisfy the requirements 11918 for gimple registers, but it may also be a tree for a scalarized 11919 component of a user variable ('ARRAY_REF', 'COMPONENT_REF'), or a 11920 debug temporary ('DEBUG_EXPR_DECL'). 11921 11922 As for 'value', it can be an arbitrary tree expression, but it is 11923 recommended that it be in a suitable form for a gimple assignment 11924 'RHS'. It is not expected that user variables that could appear as 11925 'var' ever appear in 'value', because in the latter we'd have their 11926 'SSA_NAME's instead, but even if they were not in SSA form, user 11927 variables appearing in 'value' are to be regarded as part of the 11928 executable code space, whereas those in 'var' are to be regarded as 11929 part of the source code space. There is no way to refer to the 11930 value bound to a user variable within a 'value' expression. 11931 11932 If 'value' is 'GIMPLE_DEBUG_BIND_NOVALUE', debug information 11933 generation machinery is informed that the variable 'var' is 11934 unbound, i.e., that its value is indeterminate, which sometimes 11935 means it is really unavailable, and other times that the compiler 11936 could not keep track of it. 11937 11938 Block and location information for the newly-created stmt are taken 11939 from 'stmt', if given. 11940 11941 -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt) 11942 Return the user variable VAR that is bound at 'stmt'. 11943 11944 -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt) 11945 Return the value expression that is bound to a user variable at 11946 'stmt'. 11947 11948 -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple 11949 stmt) 11950 Return a pointer to the value expression that is bound to a user 11951 variable at 'stmt'. 11952 11953 -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree 11954 var) 11955 Modify the user variable bound at 'stmt' to VAR. 11956 11957 -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, tree 11958 var) 11959 Modify the value bound to the user variable bound at 'stmt' to 11960 VALUE. 11961 11962 -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt) 11963 Modify the value bound to the user variable bound at 'stmt' so that 11964 the variable becomes unbound. 11965 11966 -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt) 11967 Return 'TRUE' if 'stmt' binds a user variable to a value, and 11968 'FALSE' if it unbinds the variable. 11969 11970 11971File: gccint.info, Node: GIMPLE_EH_FILTER, Next: GIMPLE_LABEL, Prev: GIMPLE_DEBUG, Up: Tuple specific accessors 11972 1197311.8.8 'GIMPLE_EH_FILTER' 11974------------------------- 11975 11976 -- GIMPLE function: geh_filter *gimple_build_eh_filter (tree types, 11977 gimple_seq failure) 11978 Build a 'GIMPLE_EH_FILTER' statement. 'TYPES' are the filter's 11979 types. 'FAILURE' is a sequence with the filter's failure action. 11980 11981 -- GIMPLE function: tree gimple_eh_filter_types (gimple g) 11982 Return the types handled by 'GIMPLE_EH_FILTER' statement 'G'. 11983 11984 -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g) 11985 Return a pointer to the types handled by 'GIMPLE_EH_FILTER' 11986 statement 'G'. 11987 11988 -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g) 11989 Return the sequence of statement to execute when 'GIMPLE_EH_FILTER' 11990 statement fails. 11991 11992 -- GIMPLE function: void gimple_eh_filter_set_types (geh_filter *g, 11993 tree types) 11994 Set 'TYPES' to be the set of types handled by 'GIMPLE_EH_FILTER' 11995 'G'. 11996 11997 -- GIMPLE function: void gimple_eh_filter_set_failure (geh_filter *g, 11998 gimple_seq failure) 11999 Set 'FAILURE' to be the sequence of statements to execute on 12000 failure for 'GIMPLE_EH_FILTER' 'G'. 12001 12002 -- GIMPLE function: tree gimple_eh_must_not_throw_fndecl ( geh_mnt 12003 *eh_mnt_stmt) 12004 Get the function decl to be called by the MUST_NOT_THROW region. 12005 12006 -- GIMPLE function: void gimple_eh_must_not_throw_set_fndecl ( geh_mnt 12007 *eh_mnt_stmt, tree decl) 12008 Set the function decl to be called by GS to DECL. 12009 12010 12011File: gccint.info, Node: GIMPLE_LABEL, Next: GIMPLE_GOTO, Prev: GIMPLE_EH_FILTER, Up: Tuple specific accessors 12012 1201311.8.9 'GIMPLE_LABEL' 12014--------------------- 12015 12016 -- GIMPLE function: glabel *gimple_build_label (tree label) 12017 Build a 'GIMPLE_LABEL' statement with corresponding to the tree 12018 label, 'LABEL'. 12019 12020 -- GIMPLE function: tree gimple_label_label (const glabel *g) 12021 Return the 'LABEL_DECL' node used by 'GIMPLE_LABEL' statement 'G'. 12022 12023 -- GIMPLE function: void gimple_label_set_label (glabel *g, tree label) 12024 Set 'LABEL' to be the 'LABEL_DECL' node used by 'GIMPLE_LABEL' 12025 statement 'G'. 12026 12027 12028File: gccint.info, Node: GIMPLE_GOTO, Next: GIMPLE_NOP, Prev: GIMPLE_LABEL, Up: Tuple specific accessors 12029 1203011.8.10 'GIMPLE_GOTO' 12031--------------------- 12032 12033 -- GIMPLE function: ggoto *gimple_build_goto (tree dest) 12034 Build a 'GIMPLE_GOTO' statement to label 'DEST'. 12035 12036 -- GIMPLE function: tree gimple_goto_dest (gimple g) 12037 Return the destination of the unconditional jump 'G'. 12038 12039 -- GIMPLE function: void gimple_goto_set_dest (ggoto *g, tree dest) 12040 Set 'DEST' to be the destination of the unconditional jump 'G'. 12041 12042 12043File: gccint.info, Node: GIMPLE_NOP, Next: GIMPLE_OMP_ATOMIC_LOAD, Prev: GIMPLE_GOTO, Up: Tuple specific accessors 12044 1204511.8.11 'GIMPLE_NOP' 12046-------------------- 12047 12048 -- GIMPLE function: gimple gimple_build_nop (void) 12049 Build a 'GIMPLE_NOP' statement. 12050 12051 -- GIMPLE function: bool gimple_nop_p (gimple g) 12052 Returns 'TRUE' if statement 'G' is a 'GIMPLE_NOP'. 12053 12054 12055File: gccint.info, Node: GIMPLE_OMP_ATOMIC_LOAD, Next: GIMPLE_OMP_ATOMIC_STORE, Prev: GIMPLE_NOP, Up: Tuple specific accessors 12056 1205711.8.12 'GIMPLE_OMP_ATOMIC_LOAD' 12058-------------------------------- 12059 12060 -- GIMPLE function: gomp_atomic_load *gimple_build_omp_atomic_load ( 12061 tree lhs, tree rhs) 12062 Build a 'GIMPLE_OMP_ATOMIC_LOAD' statement. 'LHS' is the left-hand 12063 side of the assignment. 'RHS' is the right-hand side of the 12064 assignment. 12065 12066 -- GIMPLE function: void gimple_omp_atomic_load_set_lhs ( 12067 gomp_atomic_load *g, tree lhs) 12068 Set the 'LHS' of an atomic load. 12069 12070 -- GIMPLE function: tree gimple_omp_atomic_load_lhs ( const 12071 gomp_atomic_load *g) 12072 Get the 'LHS' of an atomic load. 12073 12074 -- GIMPLE function: void gimple_omp_atomic_load_set_rhs ( 12075 gomp_atomic_load *g, tree rhs) 12076 Set the 'RHS' of an atomic set. 12077 12078 -- GIMPLE function: tree gimple_omp_atomic_load_rhs ( const 12079 gomp_atomic_load *g) 12080 Get the 'RHS' of an atomic set. 12081 12082 12083File: gccint.info, Node: GIMPLE_OMP_ATOMIC_STORE, Next: GIMPLE_OMP_CONTINUE, Prev: GIMPLE_OMP_ATOMIC_LOAD, Up: Tuple specific accessors 12084 1208511.8.13 'GIMPLE_OMP_ATOMIC_STORE' 12086--------------------------------- 12087 12088 -- GIMPLE function: gomp_atomic_store *gimple_build_omp_atomic_store ( 12089 tree val) 12090 Build a 'GIMPLE_OMP_ATOMIC_STORE' statement. 'VAL' is the value to 12091 be stored. 12092 12093 -- GIMPLE function: void gimple_omp_atomic_store_set_val ( 12094 gomp_atomic_store *g, tree val) 12095 Set the value being stored in an atomic store. 12096 12097 -- GIMPLE function: tree gimple_omp_atomic_store_val ( const 12098 gomp_atomic_store *g) 12099 Return the value being stored in an atomic store. 12100 12101 12102File: gccint.info, Node: GIMPLE_OMP_CONTINUE, Next: GIMPLE_OMP_CRITICAL, Prev: GIMPLE_OMP_ATOMIC_STORE, Up: Tuple specific accessors 12103 1210411.8.14 'GIMPLE_OMP_CONTINUE' 12105----------------------------- 12106 12107 -- GIMPLE function: gomp_continue *gimple_build_omp_continue ( tree 12108 control_def, tree control_use) 12109 Build a 'GIMPLE_OMP_CONTINUE' statement. 'CONTROL_DEF' is the 12110 definition of the control variable. 'CONTROL_USE' is the use of 12111 the control variable. 12112 12113 -- GIMPLE function: tree gimple_omp_continue_control_def ( const 12114 gomp_continue *s) 12115 Return the definition of the control variable on a 12116 'GIMPLE_OMP_CONTINUE' in 'S'. 12117 12118 -- GIMPLE function: tree gimple_omp_continue_control_def_ptr ( 12119 gomp_continue *s) 12120 Same as above, but return the pointer. 12121 12122 -- GIMPLE function: tree gimple_omp_continue_set_control_def ( 12123 gomp_continue *s) 12124 Set the control variable definition for a 'GIMPLE_OMP_CONTINUE' 12125 statement in 'S'. 12126 12127 -- GIMPLE function: tree gimple_omp_continue_control_use ( const 12128 gomp_continue *s) 12129 Return the use of the control variable on a 'GIMPLE_OMP_CONTINUE' 12130 in 'S'. 12131 12132 -- GIMPLE function: tree gimple_omp_continue_control_use_ptr ( 12133 gomp_continue *s) 12134 Same as above, but return the pointer. 12135 12136 -- GIMPLE function: tree gimple_omp_continue_set_control_use ( 12137 gomp_continue *s) 12138 Set the control variable use for a 'GIMPLE_OMP_CONTINUE' statement 12139 in 'S'. 12140 12141 12142File: gccint.info, Node: GIMPLE_OMP_CRITICAL, Next: GIMPLE_OMP_FOR, Prev: GIMPLE_OMP_CONTINUE, Up: Tuple specific accessors 12143 1214411.8.15 'GIMPLE_OMP_CRITICAL' 12145----------------------------- 12146 12147 -- GIMPLE function: gomp_critical *gimple_build_omp_critical ( 12148 gimple_seq body, tree name) 12149 Build a 'GIMPLE_OMP_CRITICAL' statement. 'BODY' is the sequence of 12150 statements for which only one thread can execute. 'NAME' is an 12151 optional identifier for this critical block. 12152 12153 -- GIMPLE function: tree gimple_omp_critical_name ( const gomp_critical 12154 *g) 12155 Return the name associated with 'OMP_CRITICAL' statement 'G'. 12156 12157 -- GIMPLE function: tree * gimple_omp_critical_name_ptr ( gomp_critical 12158 *g) 12159 Return a pointer to the name associated with 'OMP' critical 12160 statement 'G'. 12161 12162 -- GIMPLE function: void gimple_omp_critical_set_name ( gomp_critical 12163 *g, tree name) 12164 Set 'NAME' to be the name associated with 'OMP' critical statement 12165 'G'. 12166 12167 12168File: gccint.info, Node: GIMPLE_OMP_FOR, Next: GIMPLE_OMP_MASTER, Prev: GIMPLE_OMP_CRITICAL, Up: Tuple specific accessors 12169 1217011.8.16 'GIMPLE_OMP_FOR' 12171------------------------ 12172 12173 -- GIMPLE function: gomp_for *gimple_build_omp_for (gimple_seq body, 12174 tree clauses, tree index, tree initial, tree final, tree incr, 12175 gimple_seq pre_body, enum tree_code omp_for_cond) 12176 Build a 'GIMPLE_OMP_FOR' statement. 'BODY' is sequence of 12177 statements inside the for loop. 'CLAUSES', are any of the loop 12178 construct's clauses. 'PRE_BODY' is the sequence of statements that 12179 are loop invariant. 'INDEX' is the index variable. 'INITIAL' is 12180 the initial value of 'INDEX'. 'FINAL' is final value of 'INDEX'. 12181 OMP_FOR_COND is the predicate used to compare 'INDEX' and 'FINAL'. 12182 'INCR' is the increment expression. 12183 12184 -- GIMPLE function: tree gimple_omp_for_clauses (gimple g) 12185 Return the clauses associated with 'OMP_FOR' 'G'. 12186 12187 -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g) 12188 Return a pointer to the 'OMP_FOR' 'G'. 12189 12190 -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree 12191 clauses) 12192 Set 'CLAUSES' to be the list of clauses associated with 'OMP_FOR' 12193 'G'. 12194 12195 -- GIMPLE function: tree gimple_omp_for_index (gimple g) 12196 Return the index variable for 'OMP_FOR' 'G'. 12197 12198 -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g) 12199 Return a pointer to the index variable for 'OMP_FOR' 'G'. 12200 12201 -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree 12202 index) 12203 Set 'INDEX' to be the index variable for 'OMP_FOR' 'G'. 12204 12205 -- GIMPLE function: tree gimple_omp_for_initial (gimple g) 12206 Return the initial value for 'OMP_FOR' 'G'. 12207 12208 -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g) 12209 Return a pointer to the initial value for 'OMP_FOR' 'G'. 12210 12211 -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree 12212 initial) 12213 Set 'INITIAL' to be the initial value for 'OMP_FOR' 'G'. 12214 12215 -- GIMPLE function: tree gimple_omp_for_final (gimple g) 12216 Return the final value for 'OMP_FOR' 'G'. 12217 12218 -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g) 12219 turn a pointer to the final value for 'OMP_FOR' 'G'. 12220 12221 -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree 12222 final) 12223 Set 'FINAL' to be the final value for 'OMP_FOR' 'G'. 12224 12225 -- GIMPLE function: tree gimple_omp_for_incr (gimple g) 12226 Return the increment value for 'OMP_FOR' 'G'. 12227 12228 -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g) 12229 Return a pointer to the increment value for 'OMP_FOR' 'G'. 12230 12231 -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr) 12232 Set 'INCR' to be the increment value for 'OMP_FOR' 'G'. 12233 12234 -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g) 12235 Return the sequence of statements to execute before the 'OMP_FOR' 12236 statement 'G' starts. 12237 12238 -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g, 12239 gimple_seq pre_body) 12240 Set 'PRE_BODY' to be the sequence of statements to execute before 12241 the 'OMP_FOR' statement 'G' starts. 12242 12243 -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum 12244 tree_code cond) 12245 Set 'COND' to be the condition code for 'OMP_FOR' 'G'. 12246 12247 -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g) 12248 Return the condition code associated with 'OMP_FOR' 'G'. 12249 12250 12251File: gccint.info, Node: GIMPLE_OMP_MASTER, Next: GIMPLE_OMP_ORDERED, Prev: GIMPLE_OMP_FOR, Up: Tuple specific accessors 12252 1225311.8.17 'GIMPLE_OMP_MASTER' 12254--------------------------- 12255 12256 -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body) 12257 Build a 'GIMPLE_OMP_MASTER' statement. 'BODY' is the sequence of 12258 statements to be executed by just the master. 12259 12260 12261File: gccint.info, Node: GIMPLE_OMP_ORDERED, Next: GIMPLE_OMP_PARALLEL, Prev: GIMPLE_OMP_MASTER, Up: Tuple specific accessors 12262 1226311.8.18 'GIMPLE_OMP_ORDERED' 12264---------------------------- 12265 12266 -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body) 12267 Build a 'GIMPLE_OMP_ORDERED' statement. 12268 12269 'BODY' is the sequence of statements inside a loop that will executed 12270in sequence. 12271 12272 12273File: gccint.info, Node: GIMPLE_OMP_PARALLEL, Next: GIMPLE_OMP_RETURN, Prev: GIMPLE_OMP_ORDERED, Up: Tuple specific accessors 12274 1227511.8.19 'GIMPLE_OMP_PARALLEL' 12276----------------------------- 12277 12278 -- GIMPLE function: gomp_parallel *gimple_build_omp_parallel 12279 (gimple_seq body, tree clauses, tree child_fn, tree data_arg) 12280 Build a 'GIMPLE_OMP_PARALLEL' statement. 12281 12282 'BODY' is sequence of statements which are executed in parallel. 12283'CLAUSES', are the 'OMP' parallel construct's clauses. 'CHILD_FN' is 12284the function created for the parallel threads to execute. 'DATA_ARG' 12285are the shared data argument(s). 12286 12287 -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g) 12288 Return true if 'OMP' parallel statement 'G' has the 12289 'GF_OMP_PARALLEL_COMBINED' flag set. 12290 12291 -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g) 12292 Set the 'GF_OMP_PARALLEL_COMBINED' field in 'OMP' parallel 12293 statement 'G'. 12294 12295 -- GIMPLE function: gimple_seq gimple_omp_body (gimple g) 12296 Return the body for the 'OMP' statement 'G'. 12297 12298 -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq 12299 body) 12300 Set 'BODY' to be the body for the 'OMP' statement 'G'. 12301 12302 -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g) 12303 Return the clauses associated with 'OMP_PARALLEL' 'G'. 12304 12305 -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr ( 12306 gomp_parallel *g) 12307 Return a pointer to the clauses associated with 'OMP_PARALLEL' 'G'. 12308 12309 -- GIMPLE function: void gimple_omp_parallel_set_clauses ( 12310 gomp_parallel *g, tree clauses) 12311 Set 'CLAUSES' to be the list of clauses associated with 12312 'OMP_PARALLEL' 'G'. 12313 12314 -- GIMPLE function: tree gimple_omp_parallel_child_fn ( const 12315 gomp_parallel *g) 12316 Return the child function used to hold the body of 'OMP_PARALLEL' 12317 'G'. 12318 12319 -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr ( 12320 gomp_parallel *g) 12321 Return a pointer to the child function used to hold the body of 12322 'OMP_PARALLEL' 'G'. 12323 12324 -- GIMPLE function: void gimple_omp_parallel_set_child_fn ( 12325 gomp_parallel *g, tree child_fn) 12326 Set 'CHILD_FN' to be the child function for 'OMP_PARALLEL' 'G'. 12327 12328 -- GIMPLE function: tree gimple_omp_parallel_data_arg ( const 12329 gomp_parallel *g) 12330 Return the artificial argument used to send variables and values 12331 from the parent to the children threads in 'OMP_PARALLEL' 'G'. 12332 12333 -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr ( 12334 gomp_parallel *g) 12335 Return a pointer to the data argument for 'OMP_PARALLEL' 'G'. 12336 12337 -- GIMPLE function: void gimple_omp_parallel_set_data_arg ( 12338 gomp_parallel *g, tree data_arg) 12339 Set 'DATA_ARG' to be the data argument for 'OMP_PARALLEL' 'G'. 12340 12341 12342File: gccint.info, Node: GIMPLE_OMP_RETURN, Next: GIMPLE_OMP_SECTION, Prev: GIMPLE_OMP_PARALLEL, Up: Tuple specific accessors 12343 1234411.8.20 'GIMPLE_OMP_RETURN' 12345--------------------------- 12346 12347 -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p) 12348 Build a 'GIMPLE_OMP_RETURN' statement. 'WAIT_P' is true if this is 12349 a non-waiting return. 12350 12351 -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s) 12352 Set the nowait flag on 'GIMPLE_OMP_RETURN' statement 'S'. 12353 12354 -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g) 12355 Return true if 'OMP' return statement 'G' has the 12356 'GF_OMP_RETURN_NOWAIT' flag set. 12357 12358 12359File: gccint.info, Node: GIMPLE_OMP_SECTION, Next: GIMPLE_OMP_SECTIONS, Prev: GIMPLE_OMP_RETURN, Up: Tuple specific accessors 12360 1236111.8.21 'GIMPLE_OMP_SECTION' 12362---------------------------- 12363 12364 -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body) 12365 Build a 'GIMPLE_OMP_SECTION' statement for a sections statement. 12366 12367 'BODY' is the sequence of statements in the section. 12368 12369 -- GIMPLE function: bool gimple_omp_section_last_p (gimple g) 12370 Return true if 'OMP' section statement 'G' has the 12371 'GF_OMP_SECTION_LAST' flag set. 12372 12373 -- GIMPLE function: void gimple_omp_section_set_last (gimple g) 12374 Set the 'GF_OMP_SECTION_LAST' flag on 'G'. 12375 12376 12377File: gccint.info, Node: GIMPLE_OMP_SECTIONS, Next: GIMPLE_OMP_SINGLE, Prev: GIMPLE_OMP_SECTION, Up: Tuple specific accessors 12378 1237911.8.22 'GIMPLE_OMP_SECTIONS' 12380----------------------------- 12381 12382 -- GIMPLE function: gomp_sections *gimple_build_omp_sections ( 12383 gimple_seq body, tree clauses) 12384 Build a 'GIMPLE_OMP_SECTIONS' statement. 'BODY' is a sequence of 12385 section statements. 'CLAUSES' are any of the 'OMP' sections 12386 construct's clauses: private, firstprivate, lastprivate, reduction, 12387 and nowait. 12388 12389 -- GIMPLE function: gimple gimple_build_omp_sections_switch (void) 12390 Build a 'GIMPLE_OMP_SECTIONS_SWITCH' statement. 12391 12392 -- GIMPLE function: tree gimple_omp_sections_control (gimple g) 12393 Return the control variable associated with the 12394 'GIMPLE_OMP_SECTIONS' in 'G'. 12395 12396 -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g) 12397 Return a pointer to the clauses associated with the 12398 'GIMPLE_OMP_SECTIONS' in 'G'. 12399 12400 -- GIMPLE function: void gimple_omp_sections_set_control (gimple g, 12401 tree control) 12402 Set 'CONTROL' to be the set of clauses associated with the 12403 'GIMPLE_OMP_SECTIONS' in 'G'. 12404 12405 -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g) 12406 Return the clauses associated with 'OMP_SECTIONS' 'G'. 12407 12408 -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g) 12409 Return a pointer to the clauses associated with 'OMP_SECTIONS' 'G'. 12410 12411 -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g, 12412 tree clauses) 12413 Set 'CLAUSES' to be the set of clauses associated with 12414 'OMP_SECTIONS' 'G'. 12415 12416 12417File: gccint.info, Node: GIMPLE_OMP_SINGLE, Next: GIMPLE_PHI, Prev: GIMPLE_OMP_SECTIONS, Up: Tuple specific accessors 12418 1241911.8.23 'GIMPLE_OMP_SINGLE' 12420--------------------------- 12421 12422 -- GIMPLE function: gomp_single *gimple_build_omp_single ( gimple_seq 12423 body, tree clauses) 12424 Build a 'GIMPLE_OMP_SINGLE' statement. 'BODY' is the sequence of 12425 statements that will be executed once. 'CLAUSES' are any of the 12426 'OMP' single construct's clauses: private, firstprivate, 12427 copyprivate, nowait. 12428 12429 -- GIMPLE function: tree gimple_omp_single_clauses (gimple g) 12430 Return the clauses associated with 'OMP_SINGLE' 'G'. 12431 12432 -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g) 12433 Return a pointer to the clauses associated with 'OMP_SINGLE' 'G'. 12434 12435 -- GIMPLE function: void gimple_omp_single_set_clauses ( gomp_single 12436 *g, tree clauses) 12437 Set 'CLAUSES' to be the clauses associated with 'OMP_SINGLE' 'G'. 12438 12439 12440File: gccint.info, Node: GIMPLE_PHI, Next: GIMPLE_RESX, Prev: GIMPLE_OMP_SINGLE, Up: Tuple specific accessors 12441 1244211.8.24 'GIMPLE_PHI' 12443-------------------- 12444 12445 -- GIMPLE function: unsigned gimple_phi_capacity (gimple g) 12446 Return the maximum number of arguments supported by 'GIMPLE_PHI' 12447 'G'. 12448 12449 -- GIMPLE function: unsigned gimple_phi_num_args (gimple g) 12450 Return the number of arguments in 'GIMPLE_PHI' 'G'. This must 12451 always be exactly the number of incoming edges for the basic block 12452 holding 'G'. 12453 12454 -- GIMPLE function: tree gimple_phi_result (gimple g) 12455 Return the 'SSA' name created by 'GIMPLE_PHI' 'G'. 12456 12457 -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g) 12458 Return a pointer to the 'SSA' name created by 'GIMPLE_PHI' 'G'. 12459 12460 -- GIMPLE function: void gimple_phi_set_result (gphi *g, tree result) 12461 Set 'RESULT' to be the 'SSA' name created by 'GIMPLE_PHI' 'G'. 12462 12463 -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index) 12464 Return the 'PHI' argument corresponding to incoming edge 'INDEX' 12465 for 'GIMPLE_PHI' 'G'. 12466 12467 -- GIMPLE function: void gimple_phi_set_arg (gphi *g, index, struct 12468 phi_arg_d * phiarg) 12469 Set 'PHIARG' to be the argument corresponding to incoming edge 12470 'INDEX' for 'GIMPLE_PHI' 'G'. 12471 12472 12473File: gccint.info, Node: GIMPLE_RESX, Next: GIMPLE_RETURN, Prev: GIMPLE_PHI, Up: Tuple specific accessors 12474 1247511.8.25 'GIMPLE_RESX' 12476--------------------- 12477 12478 -- GIMPLE function: gresx *gimple_build_resx (int region) 12479 Build a 'GIMPLE_RESX' statement which is a statement. This 12480 statement is a placeholder for _Unwind_Resume before we know if a 12481 function call or a branch is needed. 'REGION' is the exception 12482 region from which control is flowing. 12483 12484 -- GIMPLE function: int gimple_resx_region (const gresx *g) 12485 Return the region number for 'GIMPLE_RESX' 'G'. 12486 12487 -- GIMPLE function: void gimple_resx_set_region (gresx *g, int region) 12488 Set 'REGION' to be the region number for 'GIMPLE_RESX' 'G'. 12489 12490 12491File: gccint.info, Node: GIMPLE_RETURN, Next: GIMPLE_SWITCH, Prev: GIMPLE_RESX, Up: Tuple specific accessors 12492 1249311.8.26 'GIMPLE_RETURN' 12494----------------------- 12495 12496 -- GIMPLE function: greturn *gimple_build_return (tree retval) 12497 Build a 'GIMPLE_RETURN' statement whose return value is retval. 12498 12499 -- GIMPLE function: tree gimple_return_retval (const greturn *g) 12500 Return the return value for 'GIMPLE_RETURN' 'G'. 12501 12502 -- GIMPLE function: void gimple_return_set_retval (greturn *g, tree 12503 retval) 12504 Set 'RETVAL' to be the return value for 'GIMPLE_RETURN' 'G'. 12505 12506 12507File: gccint.info, Node: GIMPLE_SWITCH, Next: GIMPLE_TRY, Prev: GIMPLE_RETURN, Up: Tuple specific accessors 12508 1250911.8.27 'GIMPLE_SWITCH' 12510----------------------- 12511 12512 -- GIMPLE function: gswitch *gimple_build_switch (tree index, tree 12513 default_label, 'vec'<tree> *args) 12514 Build a 'GIMPLE_SWITCH' statement. 'INDEX' is the index variable 12515 to switch on, and 'DEFAULT_LABEL' represents the default label. 12516 'ARGS' is a vector of 'CASE_LABEL_EXPR' trees that contain the 12517 non-default case labels. Each label is a tree of code 12518 'CASE_LABEL_EXPR'. 12519 12520 -- GIMPLE function: unsigned gimple_switch_num_labels ( const gswitch 12521 *g) 12522 Return the number of labels associated with the switch statement 12523 'G'. 12524 12525 -- GIMPLE function: void gimple_switch_set_num_labels (gswitch *g, 12526 unsigned nlabels) 12527 Set 'NLABELS' to be the number of labels for the switch statement 12528 'G'. 12529 12530 -- GIMPLE function: tree gimple_switch_index (const gswitch *g) 12531 Return the index variable used by the switch statement 'G'. 12532 12533 -- GIMPLE function: void gimple_switch_set_index (gswitch *g, tree 12534 index) 12535 Set 'INDEX' to be the index variable for switch statement 'G'. 12536 12537 -- GIMPLE function: tree gimple_switch_label (const gswitch *g, 12538 unsigned index) 12539 Return the label numbered 'INDEX'. The default label is 0, 12540 followed by any labels in a switch statement. 12541 12542 -- GIMPLE function: void gimple_switch_set_label (gswitch *g, unsigned 12543 index, tree label) 12544 Set the label number 'INDEX' to 'LABEL'. 0 is always the default 12545 label. 12546 12547 -- GIMPLE function: tree gimple_switch_default_label ( const gswitch 12548 *g) 12549 Return the default label for a switch statement. 12550 12551 -- GIMPLE function: void gimple_switch_set_default_label (gswitch *g, 12552 tree label) 12553 Set the default label for a switch statement. 12554 12555 12556File: gccint.info, Node: GIMPLE_TRY, Next: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_SWITCH, Up: Tuple specific accessors 12557 1255811.8.28 'GIMPLE_TRY' 12559-------------------- 12560 12561 -- GIMPLE function: gtry *gimple_build_try (gimple_seq eval, gimple_seq 12562 cleanup, unsigned int kind) 12563 Build a 'GIMPLE_TRY' statement. 'EVAL' is a sequence with the 12564 expression to evaluate. 'CLEANUP' is a sequence of statements to 12565 run at clean-up time. 'KIND' is the enumeration value 12566 'GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct 12567 or 'GIMPLE_TRY_FINALLY' if this statement denotes a try/finally 12568 construct. 12569 12570 -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g) 12571 Return the kind of try block represented by 'GIMPLE_TRY' 'G'. This 12572 is either 'GIMPLE_TRY_CATCH' or 'GIMPLE_TRY_FINALLY'. 12573 12574 -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g) 12575 Return the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 12576 12577 -- GIMPLE function: gimple_seq gimple_try_eval (gimple g) 12578 Return the sequence of statements used as the body for 'GIMPLE_TRY' 12579 'G'. 12580 12581 -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g) 12582 Return the sequence of statements used as the cleanup body for 12583 'GIMPLE_TRY' 'G'. 12584 12585 -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g, 12586 bool catch_is_cleanup) 12587 Set the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 12588 12589 -- GIMPLE function: void gimple_try_set_eval (gtry *g, gimple_seq eval) 12590 Set 'EVAL' to be the sequence of statements to use as the body for 12591 'GIMPLE_TRY' 'G'. 12592 12593 -- GIMPLE function: void gimple_try_set_cleanup (gtry *g, gimple_seq 12594 cleanup) 12595 Set 'CLEANUP' to be the sequence of statements to use as the 12596 cleanup body for 'GIMPLE_TRY' 'G'. 12597 12598 12599File: gccint.info, Node: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_TRY, Up: Tuple specific accessors 12600 1260111.8.29 'GIMPLE_WITH_CLEANUP_EXPR' 12602---------------------------------- 12603 12604 -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup) 12605 Build a 'GIMPLE_WITH_CLEANUP_EXPR' statement. 'CLEANUP' is the 12606 clean-up expression. 12607 12608 -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g) 12609 Return the cleanup sequence for cleanup statement 'G'. 12610 12611 -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq 12612 cleanup) 12613 Set 'CLEANUP' to be the cleanup sequence for 'G'. 12614 12615 -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g) 12616 Return the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 12617 12618 -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, bool 12619 eh_only_p) 12620 Set the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 12621 12622 12623File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE 12624 1262511.9 GIMPLE sequences 12626===================== 12627 12628GIMPLE sequences are the tuple equivalent of 'STATEMENT_LIST''s used in 12629'GENERIC'. They are used to chain statements together, and when used in 12630conjunction with sequence iterators, provide a framework for iterating 12631through statements. 12632 12633 GIMPLE sequences are of type struct 'gimple_sequence', but are more 12634commonly passed by reference to functions dealing with sequences. The 12635type for a sequence pointer is 'gimple_seq' which is the same as struct 12636'gimple_sequence' *. When declaring a local sequence, you can define a 12637local variable of type struct 'gimple_sequence'. When declaring a 12638sequence allocated on the garbage collected heap, use the function 12639'gimple_seq_alloc' documented below. 12640 12641 There are convenience functions for iterating through sequences in the 12642section entitled Sequence Iterators. 12643 12644 Below is a list of functions to manipulate and query sequences. 12645 12646 -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple 12647 g) 12648 Link a gimple statement to the end of the sequence *'SEQ' if 'G' is 12649 not 'NULL'. If *'SEQ' is 'NULL', allocate a sequence before 12650 linking. 12651 12652 -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest, 12653 gimple_seq src) 12654 Append sequence 'SRC' to the end of sequence *'DEST' if 'SRC' is 12655 not 'NULL'. If *'DEST' is 'NULL', allocate a new sequence before 12656 appending. 12657 12658 -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src) 12659 Perform a deep copy of sequence 'SRC' and return the result. 12660 12661 -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq) 12662 Reverse the order of the statements in the sequence 'SEQ'. Return 12663 'SEQ'. 12664 12665 -- GIMPLE function: gimple gimple_seq_first (gimple_seq s) 12666 Return the first statement in sequence 'S'. 12667 12668 -- GIMPLE function: gimple gimple_seq_last (gimple_seq s) 12669 Return the last statement in sequence 'S'. 12670 12671 -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple 12672 last) 12673 Set the last statement in sequence 'S' to the statement in 'LAST'. 12674 12675 -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple 12676 first) 12677 Set the first statement in sequence 'S' to the statement in 12678 'FIRST'. 12679 12680 -- GIMPLE function: void gimple_seq_init (gimple_seq s) 12681 Initialize sequence 'S' to an empty sequence. 12682 12683 -- GIMPLE function: gimple_seq gimple_seq_alloc (void) 12684 Allocate a new sequence in the garbage collected store and return 12685 it. 12686 12687 -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq 12688 src) 12689 Copy the sequence 'SRC' into the sequence 'DEST'. 12690 12691 -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s) 12692 Return true if the sequence 'S' is empty. 12693 12694 -- GIMPLE function: gimple_seq bb_seq (basic_block bb) 12695 Returns the sequence of statements in 'BB'. 12696 12697 -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq) 12698 Sets the sequence of statements in 'BB' to 'SEQ'. 12699 12700 -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq) 12701 Determine whether 'SEQ' contains exactly one statement. 12702 12703 12704File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE 12705 1270611.10 Sequence iterators 12707======================== 12708 12709Sequence iterators are convenience constructs for iterating through 12710statements in a sequence. Given a sequence 'SEQ', here is a typical use 12711of gimple sequence iterators: 12712 12713 gimple_stmt_iterator gsi; 12714 12715 for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi)) 12716 { 12717 gimple g = gsi_stmt (gsi); 12718 /* Do something with gimple statement G. */ 12719 } 12720 12721 Backward iterations are possible: 12722 12723 for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi)) 12724 12725 Forward and backward iterations on basic blocks are possible with 12726'gsi_start_bb' and 'gsi_last_bb'. 12727 12728 In the documentation below we sometimes refer to enum 12729'gsi_iterator_update'. The valid options for this enumeration are: 12730 12731 * 'GSI_NEW_STMT' Only valid when a single statement is added. Move 12732 the iterator to it. 12733 12734 * 'GSI_SAME_STMT' Leave the iterator at the same statement. 12735 12736 * 'GSI_CONTINUE_LINKING' Move iterator to whatever position is 12737 suitable for linking other statements in the same direction. 12738 12739 Below is a list of the functions used to manipulate and use statement 12740iterators. 12741 12742 -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq) 12743 Return a new iterator pointing to the sequence 'SEQ''s first 12744 statement. If 'SEQ' is empty, the iterator's basic block is 12745 'NULL'. Use 'gsi_start_bb' instead when the iterator needs to 12746 always have the correct basic block set. 12747 12748 -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb) 12749 Return a new iterator pointing to the first statement in basic 12750 block 'BB'. 12751 12752 -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq) 12753 Return a new iterator initially pointing to the last statement of 12754 sequence 'SEQ'. If 'SEQ' is empty, the iterator's basic block is 12755 'NULL'. Use 'gsi_last_bb' instead when the iterator needs to 12756 always have the correct basic block set. 12757 12758 -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb) 12759 Return a new iterator pointing to the last statement in basic block 12760 'BB'. 12761 12762 -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i) 12763 Return 'TRUE' if at the end of 'I'. 12764 12765 -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i) 12766 Return 'TRUE' if we're one statement before the end of 'I'. 12767 12768 -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i) 12769 Advance the iterator to the next gimple statement. 12770 12771 -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i) 12772 Advance the iterator to the previous gimple statement. 12773 12774 -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i) 12775 Return the current stmt. 12776 12777 -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block 12778 bb) 12779 Return a block statement iterator that points to the first 12780 non-label statement in block 'BB'. 12781 12782 -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i) 12783 Return a pointer to the current stmt. 12784 12785 -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i) 12786 Return the basic block associated with this iterator. 12787 12788 -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i) 12789 Return the sequence associated with this iterator. 12790 12791 -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool 12792 remove_eh_info) 12793 Remove the current stmt from the sequence. The iterator is updated 12794 to point to the next statement. When 'REMOVE_EH_INFO' is true we 12795 remove the statement pointed to by iterator 'I' from the 'EH' 12796 tables. Otherwise we do not modify the 'EH' tables. Generally, 12797 'REMOVE_EH_INFO' should be true when the statement is going to be 12798 removed from the 'IL' and not reinserted elsewhere. 12799 12800 -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i, 12801 gimple_seq seq, enum gsi_iterator_update mode) 12802 Links the sequence of statements 'SEQ' before the statement pointed 12803 by iterator 'I'. 'MODE' indicates what to do with the iterator 12804 after insertion (see 'enum gsi_iterator_update' above). 12805 12806 -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i, 12807 gimple g, enum gsi_iterator_update mode) 12808 Links statement 'G' before the statement pointed-to by iterator 12809 'I'. Updates iterator 'I' according to 'MODE'. 12810 12811 -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i, 12812 gimple_seq seq, enum gsi_iterator_update mode) 12813 Links sequence 'SEQ' after the statement pointed-to by iterator 12814 'I'. 'MODE' is as in 'gsi_insert_after'. 12815 12816 -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i, 12817 gimple g, enum gsi_iterator_update mode) 12818 Links statement 'G' after the statement pointed-to by iterator 'I'. 12819 'MODE' is as in 'gsi_insert_after'. 12820 12821 -- GIMPLE function: gimple_seq gsi_split_seq_after 12822 (gimple_stmt_iterator i) 12823 Move all statements in the sequence after 'I' to a new sequence. 12824 Return this new sequence. 12825 12826 -- GIMPLE function: gimple_seq gsi_split_seq_before 12827 (gimple_stmt_iterator *i) 12828 Move all statements in the sequence before 'I' to a new sequence. 12829 Return this new sequence. 12830 12831 -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple 12832 stmt, bool update_eh_info) 12833 Replace the statement pointed-to by 'I' to 'STMT'. If 12834 'UPDATE_EH_INFO' is true, the exception handling information of the 12835 original statement is moved to the new statement. 12836 12837 -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i, 12838 gimple stmt, enum gsi_iterator_update mode) 12839 Insert statement 'STMT' before the statement pointed-to by iterator 12840 'I', update 'STMT''s basic block and scan it for new operands. 12841 'MODE' specifies how to update iterator 'I' after insertion (see 12842 enum 'gsi_iterator_update'). 12843 12844 -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator 12845 *i, gimple_seq seq, enum gsi_iterator_update mode) 12846 Like 'gsi_insert_before', but for all the statements in 'SEQ'. 12847 12848 -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i, 12849 gimple stmt, enum gsi_iterator_update mode) 12850 Insert statement 'STMT' after the statement pointed-to by iterator 12851 'I', update 'STMT''s basic block and scan it for new operands. 12852 'MODE' specifies how to update iterator 'I' after insertion (see 12853 enum 'gsi_iterator_update'). 12854 12855 -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator *i, 12856 gimple_seq seq, enum gsi_iterator_update mode) 12857 Like 'gsi_insert_after', but for all the statements in 'SEQ'. 12858 12859 -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt) 12860 Finds iterator for 'STMT'. 12861 12862 -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from, 12863 gimple_stmt_iterator *to) 12864 Move the statement at 'FROM' so it comes right after the statement 12865 at 'TO'. 12866 12867 -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from, 12868 gimple_stmt_iterator *to) 12869 Move the statement at 'FROM' so it comes right before the statement 12870 at 'TO'. 12871 12872 -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator 12873 *from, basic_block bb) 12874 Move the statement at 'FROM' to the end of basic block 'BB'. 12875 12876 -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt) 12877 Add 'STMT' to the pending list of edge 'E'. No actual insertion is 12878 made until a call to 'gsi_commit_edge_inserts'() is made. 12879 12880 -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq 12881 seq) 12882 Add the sequence of statements in 'SEQ' to the pending list of edge 12883 'E'. No actual insertion is made until a call to 12884 'gsi_commit_edge_inserts'() is made. 12885 12886 -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e, 12887 gimple stmt) 12888 Similar to 'gsi_insert_on_edge'+'gsi_commit_edge_inserts'. If a 12889 new block has to be created, it is returned. 12890 12891 -- GIMPLE function: void gsi_commit_one_edge_insert (edge e, 12892 basic_block *new_bb) 12893 Commit insertions pending at edge 'E'. If a new block is created, 12894 set 'NEW_BB' to this block, otherwise set it to 'NULL'. 12895 12896 -- GIMPLE function: void gsi_commit_edge_inserts (void) 12897 This routine will commit all pending edge insertions, creating any 12898 new basic blocks which are necessary. 12899 12900 12901File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE 12902 1290311.11 Adding a new GIMPLE statement code 12904======================================== 12905 12906The first step in adding a new GIMPLE statement code, is modifying the 12907file 'gimple.def', which contains all the GIMPLE codes. Then you must 12908add a corresponding gimple_statement_base subclass located in 12909'gimple.h'. This in turn, will require you to add a corresponding 'GTY' 12910tag in 'gsstruct.def', and code to handle this tag in 'gss_for_code' 12911which is located in 'gimple.c'. 12912 12913 In order for the garbage collector to know the size of the structure 12914you created in 'gimple.h', you need to add a case to handle your new 12915GIMPLE statement in 'gimple_size' which is located in 'gimple.c'. 12916 12917 You will probably want to create a function to build the new gimple 12918statement in 'gimple.c'. The function should be called 12919'gimple_build_NEW-TUPLE-NAME', and should return the new tuple as a 12920pointer to the appropriate gimple_statement_base subclass. 12921 12922 If your new statement requires accessors for any members or operands it 12923may have, put simple inline accessors in 'gimple.h' and any non-trivial 12924accessors in 'gimple.c' with a corresponding prototype in 'gimple.h'. 12925 12926 You should add the new statement subclass to the class hierarchy 12927diagram in 'gimple.texi'. 12928 12929 12930File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE 12931 1293211.12 Statement and operand traversals 12933====================================== 12934 12935There are two functions available for walking statements and sequences: 12936'walk_gimple_stmt' and 'walk_gimple_seq', accordingly, and a third 12937function for walking the operands in a statement: 'walk_gimple_op'. 12938 12939 -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi, 12940 walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct 12941 walk_stmt_info *wi) 12942 This function is used to walk the current statement in 'GSI', 12943 optionally using traversal state stored in 'WI'. If 'WI' is 12944 'NULL', no state is kept during the traversal. 12945 12946 The callback 'CALLBACK_STMT' is called. If 'CALLBACK_STMT' returns 12947 true, it means that the callback function has handled all the 12948 operands of the statement and it is not necessary to walk its 12949 operands. 12950 12951 If 'CALLBACK_STMT' is 'NULL' or it returns false, 'CALLBACK_OP' is 12952 called on each operand of the statement via 'walk_gimple_op'. If 12953 'walk_gimple_op' returns non-'NULL' for any operand, the remaining 12954 operands are not scanned. 12955 12956 The return value is that returned by the last call to 12957 'walk_gimple_op', or 'NULL_TREE' if no 'CALLBACK_OP' is specified. 12958 12959 -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn 12960 callback_op, struct walk_stmt_info *wi) 12961 Use this function to walk the operands of statement 'STMT'. Every 12962 operand is walked via 'walk_tree' with optional state information 12963 in 'WI'. 12964 12965 'CALLBACK_OP' is called on each operand of 'STMT' via 'walk_tree'. 12966 Additional parameters to 'walk_tree' must be stored in 'WI'. For 12967 each operand 'OP', 'walk_tree' is called as: 12968 12969 walk_tree (&OP, CALLBACK_OP, WI, PSET) 12970 12971 If 'CALLBACK_OP' returns non-'NULL' for an operand, the remaining 12972 operands are not scanned. The return value is that returned by the 12973 last call to 'walk_tree', or 'NULL_TREE' if no 'CALLBACK_OP' is 12974 specified. 12975 12976 -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn 12977 callback_stmt, walk_tree_fn callback_op, struct walk_stmt_info 12978 *wi) 12979 This function walks all the statements in the sequence 'SEQ' 12980 calling 'walk_gimple_stmt' on each one. 'WI' is as in 12981 'walk_gimple_stmt'. If 'walk_gimple_stmt' returns non-'NULL', the 12982 walk is stopped and the value returned. Otherwise, all the 12983 statements are walked and 'NULL_TREE' returned. 12984 12985 12986File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top 12987 1298812 Analysis and Optimization of GIMPLE tuples 12989********************************************* 12990 12991GCC uses three main intermediate languages to represent the program 12992during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 12993language-independent representation generated by each front end. It is 12994used to serve as an interface between the parser and optimizer. GENERIC 12995is a common representation that is able to represent programs written in 12996all the languages supported by GCC. 12997 12998 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 12999target and language independent optimizations (e.g., inlining, constant 13000propagation, tail call elimination, redundancy elimination, etc). Much 13001like GENERIC, GIMPLE is a language independent, tree based 13002representation. However, it differs from GENERIC in that the GIMPLE 13003grammar is more restrictive: expressions contain no more than 3 operands 13004(except function calls), it has no control flow structures and 13005expressions with side-effects are only allowed on the right hand side of 13006assignments. See the chapter describing GENERIC and GIMPLE for more 13007details. 13008 13009 This chapter describes the data structures and functions used in the 13010GIMPLE optimizers (also known as "tree optimizers" or "middle end"). In 13011particular, it focuses on all the macros, data structures, functions and 13012programming constructs needed to implement optimization passes for 13013GIMPLE. 13014 13015* Menu: 13016 13017* Annotations:: Attributes for variables. 13018* SSA Operands:: SSA names referenced by GIMPLE statements. 13019* SSA:: Static Single Assignment representation. 13020* Alias analysis:: Representing aliased loads and stores. 13021* Memory model:: Memory model used by the middle-end. 13022 13023 13024File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA 13025 1302612.1 Annotations 13027================ 13028 13029The optimizers need to associate attributes with variables during the 13030optimization process. For instance, we need to know whether a variable 13031has aliases. All these attributes are stored in data structures called 13032annotations which are then linked to the field 'ann' in 'struct 13033tree_common'. 13034 13035 13036File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 13037 1303812.2 SSA Operands 13039================= 13040 13041Almost every GIMPLE statement will contain a reference to a variable or 13042memory location. Since statements come in different shapes and sizes, 13043their operands are going to be located at various spots inside the 13044statement's tree. To facilitate access to the statement's operands, 13045they are organized into lists associated inside each statement's 13046annotation. Each element in an operand list is a pointer to a 13047'VAR_DECL', 'PARM_DECL' or 'SSA_NAME' tree node. This provides a very 13048convenient way of examining and replacing operands. 13049 13050 Data flow analysis and optimization is done on all tree nodes 13051representing variables. Any node for which 'SSA_VAR_P' returns nonzero 13052is considered when scanning statement operands. However, not all 13053'SSA_VAR_P' variables are processed in the same way. For the purposes 13054of optimization, we need to distinguish between references to local 13055scalar variables and references to globals, statics, structures, arrays, 13056aliased variables, etc. The reason is simple, the compiler can gather 13057complete data flow information for a local scalar. On the other hand, a 13058global variable may be modified by a function call, it may not be 13059possible to keep track of all the elements of an array or the fields of 13060a structure, etc. 13061 13062 The operand scanner gathers two kinds of operands: "real" and 13063"virtual". An operand for which 'is_gimple_reg' returns true is 13064considered real, otherwise it is a virtual operand. We also distinguish 13065between uses and definitions. An operand is used if its value is loaded 13066by the statement (e.g., the operand at the RHS of an assignment). If 13067the statement assigns a new value to the operand, the operand is 13068considered a definition (e.g., the operand at the LHS of an assignment). 13069 13070 Virtual and real operands also have very different data flow 13071properties. Real operands are unambiguous references to the full object 13072that they represent. For instance, given 13073 13074 { 13075 int a, b; 13076 a = b 13077 } 13078 13079 Since 'a' and 'b' are non-aliased locals, the statement 'a = b' will 13080have one real definition and one real use because variable 'a' is 13081completely modified with the contents of variable 'b'. Real definition 13082are also known as "killing definitions". Similarly, the use of 'b' 13083reads all its bits. 13084 13085 In contrast, virtual operands are used with variables that can have a 13086partial or ambiguous reference. This includes structures, arrays, 13087globals, and aliased variables. In these cases, we have two types of 13088definitions. For globals, structures, and arrays, we can determine from 13089a statement whether a variable of these types has a killing definition. 13090If the variable does, then the statement is marked as having a "must 13091definition" of that variable. However, if a statement is only defining 13092a part of the variable (i.e. a field in a structure), or if we know that 13093a statement might define the variable but we cannot say for sure, then 13094we mark that statement as having a "may definition". For instance, 13095given 13096 13097 { 13098 int a, b, *p; 13099 13100 if (...) 13101 p = &a; 13102 else 13103 p = &b; 13104 *p = 5; 13105 return *p; 13106 } 13107 13108 The assignment '*p = 5' may be a definition of 'a' or 'b'. If we 13109cannot determine statically where 'p' is pointing to at the time of the 13110store operation, we create virtual definitions to mark that statement as 13111a potential definition site for 'a' and 'b'. Memory loads are similarly 13112marked with virtual use operands. Virtual operands are shown in tree 13113dumps right before the statement that contains them. To request a tree 13114dump with virtual operands, use the '-vops' option to '-fdump-tree': 13115 13116 { 13117 int a, b, *p; 13118 13119 if (...) 13120 p = &a; 13121 else 13122 p = &b; 13123 # a = VDEF <a> 13124 # b = VDEF <b> 13125 *p = 5; 13126 13127 # VUSE <a> 13128 # VUSE <b> 13129 return *p; 13130 } 13131 13132 Notice that 'VDEF' operands have two copies of the referenced variable. 13133This indicates that this is not a killing definition of that variable. 13134In this case we refer to it as a "may definition" or "aliased store". 13135The presence of the second copy of the variable in the 'VDEF' operand 13136will become important when the function is converted into SSA form. 13137This will be used to link all the non-killing definitions to prevent 13138optimizations from making incorrect assumptions about them. 13139 13140 Operands are updated as soon as the statement is finished via a call to 13141'update_stmt'. If statement elements are changed via 'SET_USE' or 13142'SET_DEF', then no further action is required (i.e., those macros take 13143care of updating the statement). If changes are made by manipulating 13144the statement's tree directly, then a call must be made to 'update_stmt' 13145when complete. Calling one of the 'bsi_insert' routines or 13146'bsi_replace' performs an implicit call to 'update_stmt'. 13147 1314812.2.1 Operand Iterators And Access Routines 13149-------------------------------------------- 13150 13151Operands are collected by 'tree-ssa-operands.c'. They are stored inside 13152each statement's annotation and can be accessed through either the 13153operand iterators or an access routine. 13154 13155 The following access routines are available for examining operands: 13156 13157 1. 'SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 13158 NULL unless there is exactly one operand matching the specified 13159 flags. If there is exactly one operand, the operand is returned as 13160 either a 'tree', 'def_operand_p', or 'use_operand_p'. 13161 13162 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 13163 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 13164 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 13165 13166 2. 'ZERO_SSA_OPERANDS': This macro returns true if there are no 13167 operands matching the specified flags. 13168 13169 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 13170 return; 13171 13172 3. 'NUM_SSA_OPERANDS': This macro Returns the number of operands 13173 matching 'flags'. This actually executes a loop to perform the 13174 count, so only use this if it is really needed. 13175 13176 int count = NUM_SSA_OPERANDS (stmt, flags) 13177 13178 If you wish to iterate over some or all operands, use the 13179'FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 13180all the operands for a statement: 13181 13182 void 13183 print_ops (tree stmt) 13184 { 13185 ssa_op_iter; 13186 tree var; 13187 13188 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 13189 print_generic_expr (stderr, var, TDF_SLIM); 13190 } 13191 13192 How to choose the appropriate iterator: 13193 13194 1. Determine whether you are need to see the operand pointers, or just 13195 the trees, and choose the appropriate macro: 13196 13197 Need Macro: 13198 ---- ------- 13199 use_operand_p FOR_EACH_SSA_USE_OPERAND 13200 def_operand_p FOR_EACH_SSA_DEF_OPERAND 13201 tree FOR_EACH_SSA_TREE_OPERAND 13202 13203 2. You need to declare a variable of the type you are interested in, 13204 and an ssa_op_iter structure which serves as the loop controlling 13205 variable. 13206 13207 3. Determine which operands you wish to use, and specify the flags of 13208 those you are interested in. They are documented in 13209 'tree-ssa-operands.h': 13210 13211 #define SSA_OP_USE 0x01 /* Real USE operands. */ 13212 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 13213 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 13214 #define SSA_OP_VDEF 0x08 /* VDEF operands. */ 13215 13216 /* These are commonly grouped operand flags. */ 13217 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE) 13218 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF) 13219 #define SSA_OP_ALL_VIRTUALS (SSA_OP_VIRTUAL_USES | SSA_OP_VIRTUAL_DEFS) 13220 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 13221 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 13222 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 13223 13224 So if you want to look at the use pointers for all the 'USE' and 'VUSE' 13225operands, you would do something like: 13226 13227 use_operand_p use_p; 13228 ssa_op_iter iter; 13229 13230 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 13231 { 13232 process_use_ptr (use_p); 13233 } 13234 13235 The 'TREE' macro is basically the same as the 'USE' and 'DEF' macros, 13236only with the use or def dereferenced via 'USE_FROM_PTR (use_p)' and 13237'DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use and 13238defs flags can be mixed. 13239 13240 tree var; 13241 ssa_op_iter iter; 13242 13243 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE) 13244 { 13245 print_generic_expr (stderr, var, TDF_SLIM); 13246 } 13247 13248 'VDEF's are broken into two flags, one for the 'DEF' portion 13249('SSA_OP_VDEF') and one for the USE portion ('SSA_OP_VUSE'). 13250 13251 There are many examples in the code, in addition to the documentation 13252in 'tree-ssa-operands.h' and 'ssa-iterators.h'. 13253 13254 There are also a couple of variants on the stmt iterators regarding PHI 13255nodes. 13256 13257 'FOR_EACH_PHI_ARG' Works exactly like 'FOR_EACH_SSA_USE_OPERAND', 13258except it works over 'PHI' arguments instead of statement operands. 13259 13260 /* Look at every virtual PHI use. */ 13261 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 13262 { 13263 my_code; 13264 } 13265 13266 /* Look at every real PHI use. */ 13267 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 13268 my_code; 13269 13270 /* Look at every PHI use. */ 13271 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 13272 my_code; 13273 13274 'FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 13275'FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 13276statement or a 'PHI' node. These should be used when it is appropriate 13277but they are not quite as efficient as the individual 'FOR_EACH_PHI' and 13278'FOR_EACH_SSA' routines. 13279 13280 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 13281 { 13282 my_code; 13283 } 13284 13285 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 13286 { 13287 my_code; 13288 } 13289 1329012.2.2 Immediate Uses 13291--------------------- 13292 13293Immediate use information is now always available. Using the immediate 13294use iterators, you may examine every use of any 'SSA_NAME'. For 13295instance, to change each use of 'ssa_var' to 'ssa_var2' and call 13296fold_stmt on each stmt after that is done: 13297 13298 use_operand_p imm_use_p; 13299 imm_use_iterator iterator; 13300 tree ssa_var, stmt; 13301 13302 13303 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 13304 { 13305 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 13306 SET_USE (imm_use_p, ssa_var_2); 13307 fold_stmt (stmt); 13308 } 13309 13310 There are 2 iterators which can be used. 'FOR_EACH_IMM_USE_FAST' is 13311used when the immediate uses are not changed, i.e., you are looking at 13312the uses, but not setting them. 13313 13314 If they do get changed, then care must be taken that things are not 13315changed under the iterators, so use the 'FOR_EACH_IMM_USE_STMT' and 13316'FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 13317sanity of the use list by moving all the uses for a statement into a 13318controlled position, and then iterating over those uses. Then the 13319optimization can manipulate the stmt when all the uses have been 13320processed. This is a little slower than the FAST version since it adds 13321a placeholder element and must sort through the list a bit for each 13322statement. This placeholder element must be also be removed if the loop 13323is terminated early. The macro 'BREAK_FROM_IMM_USE_SAFE' is provided to 13324do this : 13325 13326 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 13327 { 13328 if (stmt == last_stmt) 13329 BREAK_FROM_SAFE_IMM_USE (iter); 13330 13331 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 13332 SET_USE (imm_use_p, ssa_var_2); 13333 fold_stmt (stmt); 13334 } 13335 13336 There are checks in 'verify_ssa' which verify that the immediate use 13337list is up to date, as well as checking that an optimization didn't 13338break from the loop without using this macro. It is safe to simply 13339'break'; from a 'FOR_EACH_IMM_USE_FAST' traverse. 13340 13341 Some useful functions and macros: 13342 1. 'has_zero_uses (ssa_var)' : Returns true if there are no uses of 13343 'ssa_var'. 13344 2. 'has_single_use (ssa_var)' : Returns true if there is only a single 13345 use of 'ssa_var'. 13346 3. 'single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 13347 Returns true if there is only a single use of 'ssa_var', and also 13348 returns the use pointer and statement it occurs in, in the second 13349 and third parameters. 13350 4. 'num_imm_uses (ssa_var)' : Returns the number of immediate uses of 13351 'ssa_var'. It is better not to use this if possible since it 13352 simply utilizes a loop to count the uses. 13353 5. 'PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a 'PHI' node, 13354 return the index number for the use. An assert is triggered if the 13355 use isn't located in a 'PHI' node. 13356 6. 'USE_STMT (use_p)' : Return the statement a use occurs in. 13357 13358 Note that uses are not put into an immediate use list until their 13359statement is actually inserted into the instruction stream via a 'bsi_*' 13360routine. 13361 13362 It is also still possible to utilize lazy updating of statements, but 13363this should be used only when absolutely required. Both alias analysis 13364and the dominator optimizations currently do this. 13365 13366 When lazy updating is being used, the immediate use information is out 13367of date and cannot be used reliably. Lazy updating is achieved by 13368simply marking statements modified via calls to 'mark_stmt_modified' 13369instead of 'update_stmt'. When lazy updating is no longer required, all 13370the modified statements must have 'update_stmt' called in order to bring 13371them up to date. This must be done before the optimization is finished, 13372or 'verify_ssa' will trigger an abort. 13373 13374 This is done with a simple loop over the instruction stream: 13375 block_stmt_iterator bsi; 13376 basic_block bb; 13377 FOR_EACH_BB (bb) 13378 { 13379 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 13380 update_stmt_if_modified (bsi_stmt (bsi)); 13381 } 13382 13383 13384File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA 13385 1338612.3 Static Single Assignment 13387============================= 13388 13389Most of the tree optimizers rely on the data flow information provided 13390by the Static Single Assignment (SSA) form. We implement the SSA form 13391as described in 'R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 13392Zadeck. Efficiently Computing Static Single Assignment Form and the 13393Control Dependence Graph. ACM Transactions on Programming Languages and 13394Systems, 13(4):451-490, October 1991'. 13395 13396 The SSA form is based on the premise that program variables are 13397assigned in exactly one location in the program. Multiple assignments 13398to the same variable create new versions of that variable. Naturally, 13399actual programs are seldom in SSA form initially because variables tend 13400to be assigned multiple times. The compiler modifies the program 13401representation so that every time a variable is assigned in the code, a 13402new version of the variable is created. Different versions of the same 13403variable are distinguished by subscripting the variable name with its 13404version number. Variables used in the right-hand side of expressions 13405are renamed so that their version number matches that of the most recent 13406assignment. 13407 13408 We represent variable versions using 'SSA_NAME' nodes. The renaming 13409process in 'tree-ssa.c' wraps every real and virtual operand with an 13410'SSA_NAME' node which contains the version number and the statement that 13411created the 'SSA_NAME'. Only definitions and virtual definitions may 13412create new 'SSA_NAME' nodes. 13413 13414 Sometimes, flow of control makes it impossible to determine the most 13415recent version of a variable. In these cases, the compiler inserts an 13416artificial definition for that variable called "PHI function" or "PHI 13417node". This new definition merges all the incoming versions of the 13418variable to create a new name for it. For instance, 13419 13420 if (...) 13421 a_1 = 5; 13422 else if (...) 13423 a_2 = 2; 13424 else 13425 a_3 = 13; 13426 13427 # a_4 = PHI <a_1, a_2, a_3> 13428 return a_4; 13429 13430 Since it is not possible to determine which of the three branches will 13431be taken at runtime, we don't know which of 'a_1', 'a_2' or 'a_3' to use 13432at the return statement. So, the SSA renamer creates a new version 13433'a_4' which is assigned the result of "merging" 'a_1', 'a_2' and 'a_3'. 13434Hence, PHI nodes mean "one of these operands. I don't know which". 13435 13436 The following functions can be used to examine PHI nodes 13437 13438 -- Function: gimple_phi_result (PHI) 13439 Returns the 'SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 13440 13441 -- Function: gimple_phi_num_args (PHI) 13442 Returns the number of arguments in PHI. This number is exactly the 13443 number of incoming edges to the basic block holding PHI. 13444 13445 -- Function: gimple_phi_arg (PHI, I) 13446 Returns Ith argument of PHI. 13447 13448 -- Function: gimple_phi_arg_edge (PHI, I) 13449 Returns the incoming edge for the Ith argument of PHI. 13450 13451 -- Function: gimple_phi_arg_def (PHI, I) 13452 Returns the 'SSA_NAME' for the Ith argument of PHI. 13453 1345412.3.1 Preserving the SSA form 13455------------------------------ 13456 13457Some optimization passes make changes to the function that invalidate 13458the SSA property. This can happen when a pass has added new symbols or 13459changed the program so that variables that were previously aliased 13460aren't anymore. Whenever something like this happens, the affected 13461symbols must be renamed into SSA form again. Transformations that emit 13462new code or replicate existing statements will also need to update the 13463SSA form. 13464 13465 Since GCC implements two different SSA forms for register and virtual 13466variables, keeping the SSA form up to date depends on whether you are 13467updating register or virtual names. In both cases, the general idea 13468behind incremental SSA updates is similar: when new SSA names are 13469created, they typically are meant to replace other existing names in the 13470program. 13471 13472 For instance, given the following code: 13473 13474 1 L0: 13475 2 x_1 = PHI (0, x_5) 13476 3 if (x_1 < 10) 13477 4 if (x_1 > 7) 13478 5 y_2 = 0 13479 6 else 13480 7 y_3 = x_1 + x_7 13481 8 endif 13482 9 x_5 = x_1 + 1 13483 10 goto L0; 13484 11 endif 13485 13486 Suppose that we insert new names 'x_10' and 'x_11' (lines '4' and '8'). 13487 13488 1 L0: 13489 2 x_1 = PHI (0, x_5) 13490 3 if (x_1 < 10) 13491 4 x_10 = ... 13492 5 if (x_1 > 7) 13493 6 y_2 = 0 13494 7 else 13495 8 x_11 = ... 13496 9 y_3 = x_1 + x_7 13497 10 endif 13498 11 x_5 = x_1 + 1 13499 12 goto L0; 13500 13 endif 13501 13502 We want to replace all the uses of 'x_1' with the new definitions of 13503'x_10' and 'x_11'. Note that the only uses that should be replaced are 13504those at lines '5', '9' and '11'. Also, the use of 'x_7' at line '9' 13505should _not_ be replaced (this is why we cannot just mark symbol 'x' for 13506renaming). 13507 13508 Additionally, we may need to insert a PHI node at line '11' because 13509that is a merge point for 'x_10' and 'x_11'. So the use of 'x_1' at 13510line '11' will be replaced with the new PHI node. The insertion of PHI 13511nodes is optional. They are not strictly necessary to preserve the SSA 13512form, and depending on what the caller inserted, they may not even be 13513useful for the optimizers. 13514 13515 Updating the SSA form is a two step process. First, the pass has to 13516identify which names need to be updated and/or which symbols need to be 13517renamed into SSA form for the first time. When new names are introduced 13518to replace existing names in the program, the mapping between the old 13519and the new names are registered by calling 'register_new_name_mapping' 13520(note that if your pass creates new code by duplicating basic blocks, 13521the call to 'tree_duplicate_bb' will set up the necessary mappings 13522automatically). 13523 13524 After the replacement mappings have been registered and new symbols 13525marked for renaming, a call to 'update_ssa' makes the registered 13526changes. This can be done with an explicit call or by creating 'TODO' 13527flags in the 'tree_opt_pass' structure for your pass. There are several 13528'TODO' flags that control the behavior of 'update_ssa': 13529 13530 * 'TODO_update_ssa'. Update the SSA form inserting PHI nodes for 13531 newly exposed symbols and virtual names marked for updating. When 13532 updating real names, only insert PHI nodes for a real name 'O_j' in 13533 blocks reached by all the new and old definitions for 'O_j'. If 13534 the iterated dominance frontier for 'O_j' is not pruned, we may end 13535 up inserting PHI nodes in blocks that have one or more edges with 13536 no incoming definition for 'O_j'. This would lead to uninitialized 13537 warnings for 'O_j''s symbol. 13538 13539 * 'TODO_update_ssa_no_phi'. Update the SSA form without inserting 13540 any new PHI nodes at all. This is used by passes that have either 13541 inserted all the PHI nodes themselves or passes that need only to 13542 patch use-def and def-def chains for virtuals (e.g., DCE). 13543 13544 * 'TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are 13545 needed. No pruning of the IDF is done. This is used by passes 13546 that need the PHI nodes for 'O_j' even if it means that some 13547 arguments will come from the default definition of 'O_j''s symbol 13548 (e.g., 'pass_linear_transform'). 13549 13550 WARNING: If you need to use this flag, chances are that your pass 13551 may be doing something wrong. Inserting PHI nodes for an old name 13552 where not all edges carry a new replacement may lead to silent 13553 codegen errors or spurious uninitialized warnings. 13554 13555 * 'TODO_update_ssa_only_virtuals'. Passes that update the SSA form 13556 on their own may want to delegate the updating of virtual names to 13557 the generic updater. Since FUD chains are easier to maintain, this 13558 simplifies the work they need to do. NOTE: If this flag is used, 13559 any OLD->NEW mappings for real names are explicitly destroyed and 13560 only the symbols marked for renaming are processed. 13561 1356212.3.2 Preserving the virtual SSA form 13563-------------------------------------- 13564 13565The virtual SSA form is harder to preserve than the non-virtual SSA form 13566mainly because the set of virtual operands for a statement may change at 13567what some would consider unexpected times. In general, statement 13568modifications should be bracketed between calls to 'push_stmt_changes' 13569and 'pop_stmt_changes'. For example, 13570 13571 munge_stmt (tree stmt) 13572 { 13573 push_stmt_changes (&stmt); 13574 ... rewrite STMT ... 13575 pop_stmt_changes (&stmt); 13576 } 13577 13578 The call to 'push_stmt_changes' saves the current state of the 13579statement operands and the call to 'pop_stmt_changes' compares the saved 13580state with the current one and does the appropriate symbol marking for 13581the SSA renamer. 13582 13583 It is possible to modify several statements at a time, provided that 13584'push_stmt_changes' and 'pop_stmt_changes' are called in LIFO order, as 13585when processing a stack of statements. 13586 13587 Additionally, if the pass discovers that it did not need to make 13588changes to the statement after calling 'push_stmt_changes', it can 13589simply discard the topmost change buffer by calling 13590'discard_stmt_changes'. This will avoid the expensive operand re-scan 13591operation and the buffer comparison that determines if symbols need to 13592be marked for renaming. 13593 1359412.3.3 Examining 'SSA_NAME' nodes 13595--------------------------------- 13596 13597The following macros can be used to examine 'SSA_NAME' nodes 13598 13599 -- Macro: SSA_NAME_DEF_STMT (VAR) 13600 Returns the statement S that creates the 'SSA_NAME' VAR. If S is 13601 an empty statement (i.e., 'IS_EMPTY_STMT (S)' returns 'true'), it 13602 means that the first reference to this variable is a USE or a VUSE. 13603 13604 -- Macro: SSA_NAME_VERSION (VAR) 13605 Returns the version number of the 'SSA_NAME' object VAR. 13606 1360712.3.4 Walking the dominator tree 13608--------------------------------- 13609 13610 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 13611 13612 This function walks the dominator tree for the current CFG calling 13613 a set of callback functions defined in STRUCT DOM_WALK_DATA in 13614 'domwalk.h'. The call back functions you need to define give you 13615 hooks to execute custom code at various points during traversal: 13616 13617 1. Once to initialize any local data needed while processing BB 13618 and its children. This local data is pushed into an internal 13619 stack which is automatically pushed and popped as the walker 13620 traverses the dominator tree. 13621 13622 2. Once before traversing all the statements in the BB. 13623 13624 3. Once for every statement inside BB. 13625 13626 4. Once after traversing all the statements and before recursing 13627 into BB's dominator children. 13628 13629 5. It then recurses into all the dominator children of BB. 13630 13631 6. After recursing into all the dominator children of BB it can, 13632 optionally, traverse every statement in BB again (i.e., 13633 repeating steps 2 and 3). 13634 13635 7. Once after walking the statements in BB and BB's dominator 13636 children. At this stage, the block local data stack is 13637 popped. 13638 13639 13640File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA 13641 1364212.4 Alias analysis 13643=================== 13644 13645Alias analysis in GIMPLE SSA form consists of two pieces. First the 13646virtual SSA web ties conflicting memory accesses and provides a SSA 13647use-def chain and SSA immediate-use chains for walking possibly 13648dependent memory accesses. Second an alias-oracle can be queried to 13649disambiguate explicit and implicit memory references. 13650 13651 1. Memory SSA form. 13652 13653 All statements that may use memory have exactly one accompanied use 13654 of a virtual SSA name that represents the state of memory at the 13655 given point in the IL. 13656 13657 All statements that may define memory have exactly one accompanied 13658 definition of a virtual SSA name using the previous state of memory 13659 and defining the new state of memory after the given point in the 13660 IL. 13661 13662 int i; 13663 int foo (void) 13664 { 13665 # .MEM_3 = VDEF <.MEM_2(D)> 13666 i = 1; 13667 # VUSE <.MEM_3> 13668 return i; 13669 } 13670 13671 The virtual SSA names in this case are '.MEM_2(D)' and '.MEM_3'. 13672 The store to the global variable 'i' defines '.MEM_3' invalidating 13673 '.MEM_2(D)'. The load from 'i' uses that new state '.MEM_3'. 13674 13675 The virtual SSA web serves as constraints to SSA optimizers 13676 preventing illegitimate code-motion and optimization. It also 13677 provides a way to walk related memory statements. 13678 13679 2. Points-to and escape analysis. 13680 13681 Points-to analysis builds a set of constraints from the GIMPLE SSA 13682 IL representing all pointer operations and facts we do or do not 13683 know about pointers. Solving this set of constraints yields a 13684 conservatively correct solution for each pointer variable in the 13685 program (though we are only interested in SSA name pointers) as to 13686 what it may possibly point to. 13687 13688 This points-to solution for a given SSA name pointer is stored in 13689 the 'pt_solution' sub-structure of the 'SSA_NAME_PTR_INFO' record. 13690 The following accessor functions are available: 13691 13692 * 'pt_solution_includes' 13693 * 'pt_solutions_intersect' 13694 13695 Points-to analysis also computes the solution for two special set 13696 of pointers, 'ESCAPED' and 'CALLUSED'. Those represent all memory 13697 that has escaped the scope of analysis or that is used by pure or 13698 nested const calls. 13699 13700 3. Type-based alias analysis 13701 13702 Type-based alias analysis is frontend dependent though generic 13703 support is provided by the middle-end in 'alias.c'. TBAA code is 13704 used by both tree optimizers and RTL optimizers. 13705 13706 Every language that wishes to perform language-specific alias 13707 analysis should define a function that computes, given a 'tree' 13708 node, an alias set for the node. Nodes in different alias sets are 13709 not allowed to alias. For an example, see the C front-end function 13710 'c_get_alias_set'. 13711 13712 4. Tree alias-oracle 13713 13714 The tree alias-oracle provides means to disambiguate two memory 13715 references and memory references against statements. The following 13716 queries are available: 13717 13718 * 'refs_may_alias_p' 13719 * 'ref_maybe_used_by_stmt_p' 13720 * 'stmt_may_clobber_ref_p' 13721 13722 In addition to those two kind of statement walkers are available 13723 walking statements related to a reference ref. 13724 'walk_non_aliased_vuses' walks over dominating memory defining 13725 statements and calls back if the statement does not clobber ref 13726 providing the non-aliased VUSE. The walk stops at the first 13727 clobbering statement or if asked to. 'walk_aliased_vdefs' walks 13728 over dominating memory defining statements and calls back on each 13729 statement clobbering ref providing its aliasing VDEF. The walk 13730 stops if asked to. 13731 13732 13733File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA 13734 1373512.5 Memory model 13736================= 13737 13738The memory model used by the middle-end models that of the C/C++ 13739languages. The middle-end has the notion of an effective type of a 13740memory region which is used for type-based alias analysis. 13741 13742 The following is a refinement of ISO C99 6.5/6, clarifying the block 13743copy case to follow common sense and extending the concept of a dynamic 13744effective type to objects with a declared type as required for C++. 13745 13746 The effective type of an object for an access to its stored value is 13747 the declared type of the object or the effective type determined by 13748 a previous store to it. If a value is stored into an object through 13749 an lvalue having a type that is not a character type, then the 13750 type of the lvalue becomes the effective type of the object for that 13751 access and for subsequent accesses that do not modify the stored value. 13752 If a value is copied into an object using memcpy or memmove, 13753 or is copied as an array of character type, then the effective type 13754 of the modified object for that access and for subsequent accesses that 13755 do not modify the value is undetermined. For all other accesses to an 13756 object, the effective type of the object is simply the type of the 13757 lvalue used for the access. 13758 13759 13760File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top 13761 1376213 RTL Representation 13763********************* 13764 13765The last part of the compiler work is done on a low-level intermediate 13766representation called Register Transfer Language. In this language, the 13767instructions to be output are described, pretty much one by one, in an 13768algebraic form that describes what the instruction does. 13769 13770 RTL is inspired by Lisp lists. It has both an internal form, made up 13771of structures that point at other structures, and a textual form that is 13772used in the machine description and in printed debugging dumps. The 13773textual form uses nested parentheses to indicate the pointers in the 13774internal form. 13775 13776* Menu: 13777 13778* RTL Objects:: Expressions vs vectors vs strings vs integers. 13779* RTL Classes:: Categories of RTL expression objects, and their structure. 13780* Accessors:: Macros to access expression operands or vector elts. 13781* Special Accessors:: Macros to access specific annotations on RTL. 13782* Flags:: Other flags in an RTL expression. 13783* Machine Modes:: Describing the size and format of a datum. 13784* Constants:: Expressions with constant values. 13785* Regs and Memory:: Expressions representing register contents or memory. 13786* Arithmetic:: Expressions representing arithmetic on other expressions. 13787* Comparisons:: Expressions representing comparison of expressions. 13788* Bit-Fields:: Expressions representing bit-fields in memory or reg. 13789* Vector Operations:: Expressions involving vector datatypes. 13790* Conversions:: Extending, truncating, floating or fixing. 13791* RTL Declarations:: Declaring volatility, constancy, etc. 13792* Side Effects:: Expressions for storing in registers, etc. 13793* Incdec:: Embedded side-effects for autoincrement addressing. 13794* Assembler:: Representing 'asm' with operands. 13795* Debug Information:: Expressions representing debugging information. 13796* Insns:: Expression types for entire insns. 13797* Calls:: RTL representation of function call insns. 13798* Sharing:: Some expressions are unique; others *must* be copied. 13799* Reading RTL:: Reading textual RTL from a file. 13800 13801 13802File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 13803 1380413.1 RTL Object Types 13805===================== 13806 13807RTL uses five kinds of objects: expressions, integers, wide integers, 13808strings and vectors. Expressions are the most important ones. An RTL 13809expression ("RTX", for short) is a C structure, but it is usually 13810referred to with a pointer; a type that is given the typedef name 'rtx'. 13811 13812 An integer is simply an 'int'; their written form uses decimal digits. 13813A wide integer is an integral object whose type is 'HOST_WIDE_INT'; 13814their written form uses decimal digits. 13815 13816 A string is a sequence of characters. In core it is represented as a 13817'char *' in usual C fashion, and it is written in C syntax as well. 13818However, strings in RTL may never be null. If you write an empty string 13819in a machine description, it is represented in core as a null pointer 13820rather than as a pointer to a null character. In certain contexts, 13821these null pointers instead of strings are valid. Within RTL code, 13822strings are most commonly found inside 'symbol_ref' expressions, but 13823they appear in other contexts in the RTL expressions that make up 13824machine descriptions. 13825 13826 In a machine description, strings are normally written with double 13827quotes, as you would in C. However, strings in machine descriptions may 13828extend over many lines, which is invalid C, and adjacent string 13829constants are not concatenated as they are in C. Any string constant 13830may be surrounded with a single set of parentheses. Sometimes this 13831makes the machine description easier to read. 13832 13833 There is also a special syntax for strings, which can be useful when C 13834code is embedded in a machine description. Wherever a string can 13835appear, it is also valid to write a C-style brace block. The entire 13836brace block, including the outermost pair of braces, is considered to be 13837the string constant. Double quote characters inside the braces are not 13838special. Therefore, if you write string constants in the C code, you 13839need not escape each quote character with a backslash. 13840 13841 A vector contains an arbitrary number of pointers to expressions. The 13842number of elements in the vector is explicitly present in the vector. 13843The written form of a vector consists of square brackets ('[...]') 13844surrounding the elements, in sequence and with whitespace separating 13845them. Vectors of length zero are not created; null pointers are used 13846instead. 13847 13848 Expressions are classified by "expression codes" (also called RTX 13849codes). The expression code is a name defined in 'rtl.def', which is 13850also (in uppercase) a C enumeration constant. The possible expression 13851codes and their meanings are machine-independent. The code of an RTX 13852can be extracted with the macro 'GET_CODE (X)' and altered with 13853'PUT_CODE (X, NEWCODE)'. 13854 13855 The expression code determines how many operands the expression 13856contains, and what kinds of objects they are. In RTL, unlike Lisp, you 13857cannot tell by looking at an operand what kind of object it is. 13858Instead, you must know from its context--from the expression code of the 13859containing expression. For example, in an expression of code 'subreg', 13860the first operand is to be regarded as an expression and the second 13861operand as an integer. In an expression of code 'plus', there are two 13862operands, both of which are to be regarded as expressions. In a 13863'symbol_ref' expression, there is one operand, which is to be regarded 13864as a string. 13865 13866 Expressions are written as parentheses containing the name of the 13867expression type, its flags and machine mode if any, and then the 13868operands of the expression (separated by spaces). 13869 13870 Expression code names in the 'md' file are written in lowercase, but 13871when they appear in C code they are written in uppercase. In this 13872manual, they are shown as follows: 'const_int'. 13873 13874 In a few contexts a null pointer is valid where an expression is 13875normally wanted. The written form of this is '(nil)'. 13876 13877 13878File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 13879 1388013.2 RTL Classes and Formats 13881============================ 13882 13883The various expression codes are divided into several "classes", which 13884are represented by single characters. You can determine the class of an 13885RTX code with the macro 'GET_RTX_CLASS (CODE)'. Currently, 'rtl.def' 13886defines these classes: 13887 13888'RTX_OBJ' 13889 An RTX code that represents an actual object, such as a register 13890 ('REG') or a memory location ('MEM', 'SYMBOL_REF'). 'LO_SUM') is 13891 also included; instead, 'SUBREG' and 'STRICT_LOW_PART' are not in 13892 this class, but in class 'x'. 13893 13894'RTX_CONST_OBJ' 13895 An RTX code that represents a constant object. 'HIGH' is also 13896 included in this class. 13897 13898'RTX_COMPARE' 13899 An RTX code for a non-symmetric comparison, such as 'GEU' or 'LT'. 13900 13901'RTX_COMM_COMPARE' 13902 An RTX code for a symmetric (commutative) comparison, such as 'EQ' 13903 or 'ORDERED'. 13904 13905'RTX_UNARY' 13906 An RTX code for a unary arithmetic operation, such as 'NEG', 'NOT', 13907 or 'ABS'. This category also includes value extension (sign or 13908 zero) and conversions between integer and floating point. 13909 13910'RTX_COMM_ARITH' 13911 An RTX code for a commutative binary operation, such as 'PLUS' or 13912 'AND'. 'NE' and 'EQ' are comparisons, so they have class '<'. 13913 13914'RTX_BIN_ARITH' 13915 An RTX code for a non-commutative binary operation, such as 13916 'MINUS', 'DIV', or 'ASHIFTRT'. 13917 13918'RTX_BITFIELD_OPS' 13919 An RTX code for a bit-field operation. Currently only 13920 'ZERO_EXTRACT' and 'SIGN_EXTRACT'. These have three inputs and are 13921 lvalues (so they can be used for insertion as well). *Note 13922 Bit-Fields::. 13923 13924'RTX_TERNARY' 13925 An RTX code for other three input operations. Currently only 13926 'IF_THEN_ELSE', 'VEC_MERGE', 'SIGN_EXTRACT', 'ZERO_EXTRACT', and 13927 'FMA'. 13928 13929'RTX_INSN' 13930 An RTX code for an entire instruction: 'INSN', 'JUMP_INSN', and 13931 'CALL_INSN'. *Note Insns::. 13932 13933'RTX_MATCH' 13934 An RTX code for something that matches in insns, such as 13935 'MATCH_DUP'. These only occur in machine descriptions. 13936 13937'RTX_AUTOINC' 13938 An RTX code for an auto-increment addressing mode, such as 13939 'POST_INC'. 'XEXP (X, 0)' gives the auto-modified register. 13940 13941'RTX_EXTRA' 13942 All other RTX codes. This category includes the remaining codes 13943 used only in machine descriptions ('DEFINE_*', etc.). It also 13944 includes all the codes describing side effects ('SET', 'USE', 13945 'CLOBBER', etc.) and the non-insns that may appear on an insn 13946 chain, such as 'NOTE', 'BARRIER', and 'CODE_LABEL'. 'SUBREG' is 13947 also part of this class. 13948 13949 For each expression code, 'rtl.def' specifies the number of contained 13950objects and their kinds using a sequence of characters called the 13951"format" of the expression code. For example, the format of 'subreg' is 13952'ei'. 13953 13954 These are the most commonly used format characters: 13955 13956'e' 13957 An expression (actually a pointer to an expression). 13958 13959'i' 13960 An integer. 13961 13962'w' 13963 A wide integer. 13964 13965's' 13966 A string. 13967 13968'E' 13969 A vector of expressions. 13970 13971 A few other format characters are used occasionally: 13972 13973'u' 13974 'u' is equivalent to 'e' except that it is printed differently in 13975 debugging dumps. It is used for pointers to insns. 13976 13977'n' 13978 'n' is equivalent to 'i' except that it is printed differently in 13979 debugging dumps. It is used for the line number or code number of 13980 a 'note' insn. 13981 13982'S' 13983 'S' indicates a string which is optional. In the RTL objects in 13984 core, 'S' is equivalent to 's', but when the object is read, from 13985 an 'md' file, the string value of this operand may be omitted. An 13986 omitted string is taken to be the null string. 13987 13988'V' 13989 'V' indicates a vector which is optional. In the RTL objects in 13990 core, 'V' is equivalent to 'E', but when the object is read from an 13991 'md' file, the vector value of this operand may be omitted. An 13992 omitted vector is effectively the same as a vector of no elements. 13993 13994'B' 13995 'B' indicates a pointer to basic block structure. 13996 13997'0' 13998 '0' means a slot whose contents do not fit any normal category. 13999 '0' slots are not printed at all in dumps, and are often used in 14000 special ways by small parts of the compiler. 14001 14002 There are macros to get the number of operands and the format of an 14003expression code: 14004 14005'GET_RTX_LENGTH (CODE)' 14006 Number of operands of an RTX of code CODE. 14007 14008'GET_RTX_FORMAT (CODE)' 14009 The format of an RTX of code CODE, as a C string. 14010 14011 Some classes of RTX codes always have the same format. For example, it 14012is safe to assume that all comparison operations have format 'ee'. 14013 14014'1' 14015 All codes of this class have format 'e'. 14016 14017'<' 14018'c' 14019'2' 14020 All codes of these classes have format 'ee'. 14021 14022'b' 14023'3' 14024 All codes of these classes have format 'eee'. 14025 14026'i' 14027 All codes of this class have formats that begin with 'iuueiee'. 14028 *Note Insns::. Note that not all RTL objects linked onto an insn 14029 chain are of class 'i'. 14030 14031'o' 14032'm' 14033'x' 14034 You can make no assumptions about the format of these codes. 14035 14036 14037File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 14038 1403913.3 Access to Operands 14040======================= 14041 14042Operands of expressions are accessed using the macros 'XEXP', 'XINT', 14043'XWINT' and 'XSTR'. Each of these macros takes two arguments: an 14044expression-pointer (RTX) and an operand number (counting from zero). 14045Thus, 14046 14047 XEXP (X, 2) 14048 14049accesses operand 2 of expression X, as an expression. 14050 14051 XINT (X, 2) 14052 14053accesses the same operand as an integer. 'XSTR', used in the same 14054fashion, would access it as a string. 14055 14056 Any operand can be accessed as an integer, as an expression or as a 14057string. You must choose the correct method of access for the kind of 14058value actually stored in the operand. You would do this based on the 14059expression code of the containing expression. That is also how you 14060would know how many operands there are. 14061 14062 For example, if X is a 'subreg' expression, you know that it has two 14063operands which can be correctly accessed as 'XEXP (X, 0)' and 'XINT (X, 140641)'. If you did 'XINT (X, 0)', you would get the address of the 14065expression operand but cast as an integer; that might occasionally be 14066useful, but it would be cleaner to write '(int) XEXP (X, 0)'. 'XEXP (X, 140671)' would also compile without error, and would return the second, 14068integer operand cast as an expression pointer, which would probably 14069result in a crash when accessed. Nothing stops you from writing 'XEXP 14070(X, 28)' either, but this will access memory past the end of the 14071expression with unpredictable results. 14072 14073 Access to operands which are vectors is more complicated. You can use 14074the macro 'XVEC' to get the vector-pointer itself, or the macros 14075'XVECEXP' and 'XVECLEN' to access the elements and length of a vector. 14076 14077'XVEC (EXP, IDX)' 14078 Access the vector-pointer which is operand number IDX in EXP. 14079 14080'XVECLEN (EXP, IDX)' 14081 Access the length (number of elements) in the vector which is in 14082 operand number IDX in EXP. This value is an 'int'. 14083 14084'XVECEXP (EXP, IDX, ELTNUM)' 14085 Access element number ELTNUM in the vector which is in operand 14086 number IDX in EXP. This value is an RTX. 14087 14088 It is up to you to make sure that ELTNUM is not negative and is 14089 less than 'XVECLEN (EXP, IDX)'. 14090 14091 All the macros defined in this section expand into lvalues and 14092therefore can be used to assign the operands, lengths and vector 14093elements as well as to access them. 14094 14095 14096File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 14097 1409813.4 Access to Special Operands 14099=============================== 14100 14101Some RTL nodes have special annotations associated with them. 14102 14103'MEM' 14104 'MEM_ALIAS_SET (X)' 14105 If 0, X is not in any alias set, and may alias anything. 14106 Otherwise, X can only alias 'MEM's in a conflicting alias set. 14107 This value is set in a language-dependent manner in the 14108 front-end, and should not be altered in the back-end. In some 14109 front-ends, these numbers may correspond in some way to types, 14110 or other language-level entities, but they need not, and the 14111 back-end makes no such assumptions. These set numbers are 14112 tested with 'alias_sets_conflict_p'. 14113 14114 'MEM_EXPR (X)' 14115 If this register is known to hold the value of some user-level 14116 declaration, this is that tree node. It may also be a 14117 'COMPONENT_REF', in which case this is some field reference, 14118 and 'TREE_OPERAND (X, 0)' contains the declaration, or another 14119 'COMPONENT_REF', or null if there is no compile-time object 14120 associated with the reference. 14121 14122 'MEM_OFFSET_KNOWN_P (X)' 14123 True if the offset of the memory reference from 'MEM_EXPR' is 14124 known. 'MEM_OFFSET (X)' provides the offset if so. 14125 14126 'MEM_OFFSET (X)' 14127 The offset from the start of 'MEM_EXPR'. The value is only 14128 valid if 'MEM_OFFSET_KNOWN_P (X)' is true. 14129 14130 'MEM_SIZE_KNOWN_P (X)' 14131 True if the size of the memory reference is known. 'MEM_SIZE 14132 (X)' provides its size if so. 14133 14134 'MEM_SIZE (X)' 14135 The size in bytes of the memory reference. This is mostly 14136 relevant for 'BLKmode' references as otherwise the size is 14137 implied by the mode. The value is only valid if 14138 'MEM_SIZE_KNOWN_P (X)' is true. 14139 14140 'MEM_ALIGN (X)' 14141 The known alignment in bits of the memory reference. 14142 14143 'MEM_ADDR_SPACE (X)' 14144 The address space of the memory reference. This will commonly 14145 be zero for the generic address space. 14146 14147'REG' 14148 'ORIGINAL_REGNO (X)' 14149 This field holds the number the register "originally" had; for 14150 a pseudo register turned into a hard reg this will hold the 14151 old pseudo register number. 14152 14153 'REG_EXPR (X)' 14154 If this register is known to hold the value of some user-level 14155 declaration, this is that tree node. 14156 14157 'REG_OFFSET (X)' 14158 If this register is known to hold the value of some user-level 14159 declaration, this is the offset into that logical storage. 14160 14161'SYMBOL_REF' 14162 'SYMBOL_REF_DECL (X)' 14163 If the 'symbol_ref' X was created for a 'VAR_DECL' or a 14164 'FUNCTION_DECL', that tree is recorded here. If this value is 14165 null, then X was created by back end code generation routines, 14166 and there is no associated front end symbol table entry. 14167 14168 'SYMBOL_REF_DECL' may also point to a tree of class ''c'', 14169 that is, some sort of constant. In this case, the 14170 'symbol_ref' is an entry in the per-file constant pool; again, 14171 there is no associated front end symbol table entry. 14172 14173 'SYMBOL_REF_CONSTANT (X)' 14174 If 'CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 14175 pool entry for X. It is null otherwise. 14176 14177 'SYMBOL_REF_DATA (X)' 14178 A field of opaque type used to store 'SYMBOL_REF_DECL' or 14179 'SYMBOL_REF_CONSTANT'. 14180 14181 'SYMBOL_REF_FLAGS (X)' 14182 In a 'symbol_ref', this is used to communicate various 14183 predicates about the symbol. Some of these are common enough 14184 to be computed by common code, some are specific to the 14185 target. The common bits are: 14186 14187 'SYMBOL_FLAG_FUNCTION' 14188 Set if the symbol refers to a function. 14189 14190 'SYMBOL_FLAG_LOCAL' 14191 Set if the symbol is local to this "module". See 14192 'TARGET_BINDS_LOCAL_P'. 14193 14194 'SYMBOL_FLAG_EXTERNAL' 14195 Set if this symbol is not defined in this translation 14196 unit. Note that this is not the inverse of 14197 'SYMBOL_FLAG_LOCAL'. 14198 14199 'SYMBOL_FLAG_SMALL' 14200 Set if the symbol is located in the small data section. 14201 See 'TARGET_IN_SMALL_DATA_P'. 14202 14203 'SYMBOL_REF_TLS_MODEL (X)' 14204 This is a multi-bit field accessor that returns the 14205 'tls_model' to be used for a thread-local storage symbol. 14206 It returns zero for non-thread-local symbols. 14207 14208 'SYMBOL_FLAG_HAS_BLOCK_INFO' 14209 Set if the symbol has 'SYMBOL_REF_BLOCK' and 14210 'SYMBOL_REF_BLOCK_OFFSET' fields. 14211 14212 'SYMBOL_FLAG_ANCHOR' 14213 Set if the symbol is used as a section anchor. "Section 14214 anchors" are symbols that have a known position within an 14215 'object_block' and that can be used to access nearby 14216 members of that block. They are used to implement 14217 '-fsection-anchors'. 14218 14219 If this flag is set, then 'SYMBOL_FLAG_HAS_BLOCK_INFO' 14220 will be too. 14221 14222 Bits beginning with 'SYMBOL_FLAG_MACH_DEP' are available for 14223 the target's use. 14224 14225'SYMBOL_REF_BLOCK (X)' 14226 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the 'object_block' 14227 structure to which the symbol belongs, or 'NULL' if it has not been 14228 assigned a block. 14229 14230'SYMBOL_REF_BLOCK_OFFSET (X)' 14231 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 14232 the first object in 'SYMBOL_REF_BLOCK (X)'. The value is negative 14233 if X has not yet been assigned to a block, or it has not been given 14234 an offset within that block. 14235 14236 14237File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 14238 1423913.5 Flags in an RTL Expression 14240=============================== 14241 14242RTL expressions contain several flags (one-bit bit-fields) that are used 14243in certain types of expression. Most often they are accessed with the 14244following macros, which expand into lvalues. 14245 14246'CONSTANT_POOL_ADDRESS_P (X)' 14247 Nonzero in a 'symbol_ref' if it refers to part of the current 14248 function's constant pool. For most targets these addresses are in 14249 a '.rodata' section entirely separate from the function, but for 14250 some targets the addresses are close to the beginning of the 14251 function. In either case GCC assumes these addresses can be 14252 addressed directly, perhaps with the help of base registers. 14253 Stored in the 'unchanging' field and printed as '/u'. 14254 14255'RTL_CONST_CALL_P (X)' 14256 In a 'call_insn' indicates that the insn represents a call to a 14257 const function. Stored in the 'unchanging' field and printed as 14258 '/u'. 14259 14260'RTL_PURE_CALL_P (X)' 14261 In a 'call_insn' indicates that the insn represents a call to a 14262 pure function. Stored in the 'return_val' field and printed as 14263 '/i'. 14264 14265'RTL_CONST_OR_PURE_CALL_P (X)' 14266 In a 'call_insn', true if 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' 14267 is true. 14268 14269'RTL_LOOPING_CONST_OR_PURE_CALL_P (X)' 14270 In a 'call_insn' indicates that the insn represents a possibly 14271 infinite looping call to a const or pure function. Stored in the 14272 'call' field and printed as '/c'. Only true if one of 14273 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' is true. 14274 14275'INSN_ANNULLED_BRANCH_P (X)' 14276 In a 'jump_insn', 'call_insn', or 'insn' indicates that the branch 14277 is an annulling one. See the discussion under 'sequence' below. 14278 Stored in the 'unchanging' field and printed as '/u'. 14279 14280'INSN_DELETED_P (X)' 14281 In an 'insn', 'call_insn', 'jump_insn', 'code_label', 14282 'jump_table_data', 'barrier', or 'note', nonzero if the insn has 14283 been deleted. Stored in the 'volatil' field and printed as '/v'. 14284 14285'INSN_FROM_TARGET_P (X)' 14286 In an 'insn' or 'jump_insn' or 'call_insn' in a delay slot of a 14287 branch, indicates that the insn is from the target of the branch. 14288 If the branch insn has 'INSN_ANNULLED_BRANCH_P' set, this insn will 14289 only be executed if the branch is taken. For annulled branches 14290 with 'INSN_FROM_TARGET_P' clear, the insn will be executed only if 14291 the branch is not taken. When 'INSN_ANNULLED_BRANCH_P' is not set, 14292 this insn will always be executed. Stored in the 'in_struct' field 14293 and printed as '/s'. 14294 14295'LABEL_PRESERVE_P (X)' 14296 In a 'code_label' or 'note', indicates that the label is referenced 14297 by code or data not visible to the RTL of a given function. Labels 14298 referenced by a non-local goto will have this bit set. Stored in 14299 the 'in_struct' field and printed as '/s'. 14300 14301'LABEL_REF_NONLOCAL_P (X)' 14302 In 'label_ref' and 'reg_label' expressions, nonzero if this is a 14303 reference to a non-local label. Stored in the 'volatil' field and 14304 printed as '/v'. 14305 14306'MEM_KEEP_ALIAS_SET_P (X)' 14307 In 'mem' expressions, 1 if we should keep the alias set for this 14308 mem unchanged when we access a component. Set to 1, for example, 14309 when we are already in a non-addressable component of an aggregate. 14310 Stored in the 'jump' field and printed as '/j'. 14311 14312'MEM_VOLATILE_P (X)' 14313 In 'mem', 'asm_operands', and 'asm_input' expressions, nonzero for 14314 volatile memory references. Stored in the 'volatil' field and 14315 printed as '/v'. 14316 14317'MEM_NOTRAP_P (X)' 14318 In 'mem', nonzero for memory references that will not trap. Stored 14319 in the 'call' field and printed as '/c'. 14320 14321'MEM_POINTER (X)' 14322 Nonzero in a 'mem' if the memory reference holds a pointer. Stored 14323 in the 'frame_related' field and printed as '/f'. 14324 14325'REG_FUNCTION_VALUE_P (X)' 14326 Nonzero in a 'reg' if it is the place in which this function's 14327 value is going to be returned. (This happens only in a hard 14328 register.) Stored in the 'return_val' field and printed as '/i'. 14329 14330'REG_POINTER (X)' 14331 Nonzero in a 'reg' if the register holds a pointer. Stored in the 14332 'frame_related' field and printed as '/f'. 14333 14334'REG_USERVAR_P (X)' 14335 In a 'reg', nonzero if it corresponds to a variable present in the 14336 user's source code. Zero for temporaries generated internally by 14337 the compiler. Stored in the 'volatil' field and printed as '/v'. 14338 14339 The same hard register may be used also for collecting the values 14340 of functions called by this one, but 'REG_FUNCTION_VALUE_P' is zero 14341 in this kind of use. 14342 14343'RTX_FRAME_RELATED_P (X)' 14344 Nonzero in an 'insn', 'call_insn', 'jump_insn', 'barrier', or 'set' 14345 which is part of a function prologue and sets the stack pointer, 14346 sets the frame pointer, or saves a register. This flag should also 14347 be set on an instruction that sets up a temporary register to use 14348 in place of the frame pointer. Stored in the 'frame_related' field 14349 and printed as '/f'. 14350 14351 In particular, on RISC targets where there are limits on the sizes 14352 of immediate constants, it is sometimes impossible to reach the 14353 register save area directly from the stack pointer. In that case, 14354 a temporary register is used that is near enough to the register 14355 save area, and the Canonical Frame Address, i.e., DWARF2's logical 14356 frame pointer, register must (temporarily) be changed to be this 14357 temporary register. So, the instruction that sets this temporary 14358 register must be marked as 'RTX_FRAME_RELATED_P'. 14359 14360 If the marked instruction is overly complex (defined in terms of 14361 what 'dwarf2out_frame_debug_expr' can handle), you will also have 14362 to create a 'REG_FRAME_RELATED_EXPR' note and attach it to the 14363 instruction. This note should contain a simple expression of the 14364 computation performed by this instruction, i.e., one that 14365 'dwarf2out_frame_debug_expr' can handle. 14366 14367 This flag is required for exception handling support on targets 14368 with RTL prologues. 14369 14370'MEM_READONLY_P (X)' 14371 Nonzero in a 'mem', if the memory is statically allocated and 14372 read-only. 14373 14374 Read-only in this context means never modified during the lifetime 14375 of the program, not necessarily in ROM or in write-disabled pages. 14376 A common example of the later is a shared library's global offset 14377 table. This table is initialized by the runtime loader, so the 14378 memory is technically writable, but after control is transferred 14379 from the runtime loader to the application, this memory will never 14380 be subsequently modified. 14381 14382 Stored in the 'unchanging' field and printed as '/u'. 14383 14384'SCHED_GROUP_P (X)' 14385 During instruction scheduling, in an 'insn', 'call_insn', 14386 'jump_insn' or 'jump_table_data', indicates that the previous insn 14387 must be scheduled together with this insn. This is used to ensure 14388 that certain groups of instructions will not be split up by the 14389 instruction scheduling pass, for example, 'use' insns before a 14390 'call_insn' may not be separated from the 'call_insn'. Stored in 14391 the 'in_struct' field and printed as '/s'. 14392 14393'SET_IS_RETURN_P (X)' 14394 For a 'set', nonzero if it is for a return. Stored in the 'jump' 14395 field and printed as '/j'. 14396 14397'SIBLING_CALL_P (X)' 14398 For a 'call_insn', nonzero if the insn is a sibling call. Stored 14399 in the 'jump' field and printed as '/j'. 14400 14401'STRING_POOL_ADDRESS_P (X)' 14402 For a 'symbol_ref' expression, nonzero if it addresses this 14403 function's string constant pool. Stored in the 'frame_related' 14404 field and printed as '/f'. 14405 14406'SUBREG_PROMOTED_UNSIGNED_P (X)' 14407 Returns a value greater then zero for a 'subreg' that has 14408 'SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 14409 kept zero-extended, zero if it is kept sign-extended, and less then 14410 zero if it is extended some other way via the 'ptr_extend' 14411 instruction. Stored in the 'unchanging' field and 'volatil' field, 14412 printed as '/u' and '/v'. This macro may only be used to get the 14413 value it may not be used to change the value. Use 14414 'SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 14415 14416'SUBREG_PROMOTED_UNSIGNED_SET (X)' 14417 Set the 'unchanging' and 'volatil' fields in a 'subreg' to reflect 14418 zero, sign, or other extension. If 'volatil' is zero, then 14419 'unchanging' as nonzero means zero extension and as zero means sign 14420 extension. If 'volatil' is nonzero then some other type of 14421 extension was done via the 'ptr_extend' instruction. 14422 14423'SUBREG_PROMOTED_VAR_P (X)' 14424 Nonzero in a 'subreg' if it was made when accessing an object that 14425 was promoted to a wider mode in accord with the 'PROMOTED_MODE' 14426 machine description macro (*note Storage Layout::). In this case, 14427 the mode of the 'subreg' is the declared mode of the object and the 14428 mode of 'SUBREG_REG' is the mode of the register that holds the 14429 object. Promoted variables are always either sign- or 14430 zero-extended to the wider mode on every assignment. Stored in the 14431 'in_struct' field and printed as '/s'. 14432 14433'SYMBOL_REF_USED (X)' 14434 In a 'symbol_ref', indicates that X has been used. This is 14435 normally only used to ensure that X is only declared external once. 14436 Stored in the 'used' field. 14437 14438'SYMBOL_REF_WEAK (X)' 14439 In a 'symbol_ref', indicates that X has been declared weak. Stored 14440 in the 'return_val' field and printed as '/i'. 14441 14442'SYMBOL_REF_FLAG (X)' 14443 In a 'symbol_ref', this is used as a flag for machine-specific 14444 purposes. Stored in the 'volatil' field and printed as '/v'. 14445 14446 Most uses of 'SYMBOL_REF_FLAG' are historic and may be subsumed by 14447 'SYMBOL_REF_FLAGS'. Certainly use of 'SYMBOL_REF_FLAGS' is 14448 mandatory if the target requires more than one bit of storage. 14449 14450'PREFETCH_SCHEDULE_BARRIER_P (X)' 14451 In a 'prefetch', indicates that the prefetch is a scheduling 14452 barrier. No other INSNs will be moved over it. Stored in the 14453 'volatil' field and printed as '/v'. 14454 14455 These are the fields to which the above macros refer: 14456 14457'call' 14458 In a 'mem', 1 means that the memory reference will not trap. 14459 14460 In a 'call', 1 means that this pure or const call may possibly 14461 infinite loop. 14462 14463 In an RTL dump, this flag is represented as '/c'. 14464 14465'frame_related' 14466 In an 'insn' or 'set' expression, 1 means that it is part of a 14467 function prologue and sets the stack pointer, sets the frame 14468 pointer, saves a register, or sets up a temporary register to use 14469 in place of the frame pointer. 14470 14471 In 'reg' expressions, 1 means that the register holds a pointer. 14472 14473 In 'mem' expressions, 1 means that the memory reference holds a 14474 pointer. 14475 14476 In 'symbol_ref' expressions, 1 means that the reference addresses 14477 this function's string constant pool. 14478 14479 In an RTL dump, this flag is represented as '/f'. 14480 14481'in_struct' 14482 In 'reg' expressions, it is 1 if the register has its entire life 14483 contained within the test expression of some loop. 14484 14485 In 'subreg' expressions, 1 means that the 'subreg' is accessing an 14486 object that has had its mode promoted from a wider mode. 14487 14488 In 'label_ref' expressions, 1 means that the referenced label is 14489 outside the innermost loop containing the insn in which the 14490 'label_ref' was found. 14491 14492 In 'code_label' expressions, it is 1 if the label may never be 14493 deleted. This is used for labels which are the target of non-local 14494 gotos. Such a label that would have been deleted is replaced with 14495 a 'note' of type 'NOTE_INSN_DELETED_LABEL'. 14496 14497 In an 'insn' during dead-code elimination, 1 means that the insn is 14498 dead code. 14499 14500 In an 'insn' or 'jump_insn' during reorg for an insn in the delay 14501 slot of a branch, 1 means that this insn is from the target of the 14502 branch. 14503 14504 In an 'insn' during instruction scheduling, 1 means that this insn 14505 must be scheduled as part of a group together with the previous 14506 insn. 14507 14508 In an RTL dump, this flag is represented as '/s'. 14509 14510'return_val' 14511 In 'reg' expressions, 1 means the register contains the value to be 14512 returned by the current function. On machines that pass parameters 14513 in registers, the same register number may be used for parameters 14514 as well, but this flag is not set on such uses. 14515 14516 In 'symbol_ref' expressions, 1 means the referenced symbol is weak. 14517 14518 In 'call' expressions, 1 means the call is pure. 14519 14520 In an RTL dump, this flag is represented as '/i'. 14521 14522'jump' 14523 In a 'mem' expression, 1 means we should keep the alias set for 14524 this mem unchanged when we access a component. 14525 14526 In a 'set', 1 means it is for a return. 14527 14528 In a 'call_insn', 1 means it is a sibling call. 14529 14530 In an RTL dump, this flag is represented as '/j'. 14531 14532'unchanging' 14533 In 'reg' and 'mem' expressions, 1 means that the value of the 14534 expression never changes. 14535 14536 In 'subreg' expressions, it is 1 if the 'subreg' references an 14537 unsigned object whose mode has been promoted to a wider mode. 14538 14539 In an 'insn' or 'jump_insn' in the delay slot of a branch 14540 instruction, 1 means an annulling branch should be used. 14541 14542 In a 'symbol_ref' expression, 1 means that this symbol addresses 14543 something in the per-function constant pool. 14544 14545 In a 'call_insn' 1 means that this instruction is a call to a const 14546 function. 14547 14548 In an RTL dump, this flag is represented as '/u'. 14549 14550'used' 14551 This flag is used directly (without an access macro) at the end of 14552 RTL generation for a function, to count the number of times an 14553 expression appears in insns. Expressions that appear more than 14554 once are copied, according to the rules for shared structure (*note 14555 Sharing::). 14556 14557 For a 'reg', it is used directly (without an access macro) by the 14558 leaf register renumbering code to ensure that each register is only 14559 renumbered once. 14560 14561 In a 'symbol_ref', it indicates that an external declaration for 14562 the symbol has already been written. 14563 14564'volatil' 14565 In a 'mem', 'asm_operands', or 'asm_input' expression, it is 1 if 14566 the memory reference is volatile. Volatile memory references may 14567 not be deleted, reordered or combined. 14568 14569 In a 'symbol_ref' expression, it is used for machine-specific 14570 purposes. 14571 14572 In a 'reg' expression, it is 1 if the value is a user-level 14573 variable. 0 indicates an internal compiler temporary. 14574 14575 In an 'insn', 1 means the insn has been deleted. 14576 14577 In 'label_ref' and 'reg_label' expressions, 1 means a reference to 14578 a non-local label. 14579 14580 In 'prefetch' expressions, 1 means that the containing insn is a 14581 scheduling barrier. 14582 14583 In an RTL dump, this flag is represented as '/v'. 14584 14585 14586File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 14587 1458813.6 Machine Modes 14589================== 14590 14591A machine mode describes a size of data object and the representation 14592used for it. In the C code, machine modes are represented by an 14593enumeration type, 'machine_mode', defined in 'machmode.def'. Each RTL 14594expression has room for a machine mode and so do certain kinds of tree 14595expressions (declarations and types, to be precise). 14596 14597 In debugging dumps and machine descriptions, the machine mode of an RTL 14598expression is written after the expression code with a colon to separate 14599them. The letters 'mode' which appear at the end of each machine mode 14600name are omitted. For example, '(reg:SI 38)' is a 'reg' expression with 14601machine mode 'SImode'. If the mode is 'VOIDmode', it is not written at 14602all. 14603 14604 Here is a table of machine modes. The term "byte" below refers to an 14605object of 'BITS_PER_UNIT' bits (*note Storage Layout::). 14606 14607'BImode' 14608 "Bit" mode represents a single bit, for predicate registers. 14609 14610'QImode' 14611 "Quarter-Integer" mode represents a single byte treated as an 14612 integer. 14613 14614'HImode' 14615 "Half-Integer" mode represents a two-byte integer. 14616 14617'PSImode' 14618 "Partial Single Integer" mode represents an integer which occupies 14619 four bytes but which doesn't really use all four. On some 14620 machines, this is the right mode to use for pointers. 14621 14622'SImode' 14623 "Single Integer" mode represents a four-byte integer. 14624 14625'PDImode' 14626 "Partial Double Integer" mode represents an integer which occupies 14627 eight bytes but which doesn't really use all eight. On some 14628 machines, this is the right mode to use for certain pointers. 14629 14630'DImode' 14631 "Double Integer" mode represents an eight-byte integer. 14632 14633'TImode' 14634 "Tetra Integer" (?) mode represents a sixteen-byte integer. 14635 14636'OImode' 14637 "Octa Integer" (?) mode represents a thirty-two-byte integer. 14638 14639'XImode' 14640 "Hexadeca Integer" (?) mode represents a sixty-four-byte integer. 14641 14642'QFmode' 14643 "Quarter-Floating" mode represents a quarter-precision (single 14644 byte) floating point number. 14645 14646'HFmode' 14647 "Half-Floating" mode represents a half-precision (two byte) 14648 floating point number. 14649 14650'TQFmode' 14651 "Three-Quarter-Floating" (?) mode represents a 14652 three-quarter-precision (three byte) floating point number. 14653 14654'SFmode' 14655 "Single Floating" mode represents a four byte floating point 14656 number. In the common case, of a processor with IEEE arithmetic 14657 and 8-bit bytes, this is a single-precision IEEE floating point 14658 number; it can also be used for double-precision (on processors 14659 with 16-bit bytes) and single-precision VAX and IBM types. 14660 14661'DFmode' 14662 "Double Floating" mode represents an eight byte floating point 14663 number. In the common case, of a processor with IEEE arithmetic 14664 and 8-bit bytes, this is a double-precision IEEE floating point 14665 number. 14666 14667'XFmode' 14668 "Extended Floating" mode represents an IEEE extended floating point 14669 number. This mode only has 80 meaningful bits (ten bytes). Some 14670 processors require such numbers to be padded to twelve bytes, 14671 others to sixteen; this mode is used for either. 14672 14673'SDmode' 14674 "Single Decimal Floating" mode represents a four byte decimal 14675 floating point number (as distinct from conventional binary 14676 floating point). 14677 14678'DDmode' 14679 "Double Decimal Floating" mode represents an eight byte decimal 14680 floating point number. 14681 14682'TDmode' 14683 "Tetra Decimal Floating" mode represents a sixteen byte decimal 14684 floating point number all 128 of whose bits are meaningful. 14685 14686'TFmode' 14687 "Tetra Floating" mode represents a sixteen byte floating point 14688 number all 128 of whose bits are meaningful. One common use is the 14689 IEEE quad-precision format. 14690 14691'QQmode' 14692 "Quarter-Fractional" mode represents a single byte treated as a 14693 signed fractional number. The default format is "s.7". 14694 14695'HQmode' 14696 "Half-Fractional" mode represents a two-byte signed fractional 14697 number. The default format is "s.15". 14698 14699'SQmode' 14700 "Single Fractional" mode represents a four-byte signed fractional 14701 number. The default format is "s.31". 14702 14703'DQmode' 14704 "Double Fractional" mode represents an eight-byte signed fractional 14705 number. The default format is "s.63". 14706 14707'TQmode' 14708 "Tetra Fractional" mode represents a sixteen-byte signed fractional 14709 number. The default format is "s.127". 14710 14711'UQQmode' 14712 "Unsigned Quarter-Fractional" mode represents a single byte treated 14713 as an unsigned fractional number. The default format is ".8". 14714 14715'UHQmode' 14716 "Unsigned Half-Fractional" mode represents a two-byte unsigned 14717 fractional number. The default format is ".16". 14718 14719'USQmode' 14720 "Unsigned Single Fractional" mode represents a four-byte unsigned 14721 fractional number. The default format is ".32". 14722 14723'UDQmode' 14724 "Unsigned Double Fractional" mode represents an eight-byte unsigned 14725 fractional number. The default format is ".64". 14726 14727'UTQmode' 14728 "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned 14729 fractional number. The default format is ".128". 14730 14731'HAmode' 14732 "Half-Accumulator" mode represents a two-byte signed accumulator. 14733 The default format is "s8.7". 14734 14735'SAmode' 14736 "Single Accumulator" mode represents a four-byte signed 14737 accumulator. The default format is "s16.15". 14738 14739'DAmode' 14740 "Double Accumulator" mode represents an eight-byte signed 14741 accumulator. The default format is "s32.31". 14742 14743'TAmode' 14744 "Tetra Accumulator" mode represents a sixteen-byte signed 14745 accumulator. The default format is "s64.63". 14746 14747'UHAmode' 14748 "Unsigned Half-Accumulator" mode represents a two-byte unsigned 14749 accumulator. The default format is "8.8". 14750 14751'USAmode' 14752 "Unsigned Single Accumulator" mode represents a four-byte unsigned 14753 accumulator. The default format is "16.16". 14754 14755'UDAmode' 14756 "Unsigned Double Accumulator" mode represents an eight-byte 14757 unsigned accumulator. The default format is "32.32". 14758 14759'UTAmode' 14760 "Unsigned Tetra Accumulator" mode represents a sixteen-byte 14761 unsigned accumulator. The default format is "64.64". 14762 14763'CCmode' 14764 "Condition Code" mode represents the value of a condition code, 14765 which is a machine-specific set of bits used to represent the 14766 result of a comparison operation. Other machine-specific modes may 14767 also be used for the condition code. These modes are not used on 14768 machines that use 'cc0' (*note Condition Code::). 14769 14770'BLKmode' 14771 "Block" mode represents values that are aggregates to which none of 14772 the other modes apply. In RTL, only memory references can have 14773 this mode, and only if they appear in string-move or vector 14774 instructions. On machines which have no such instructions, 14775 'BLKmode' will not appear in RTL. 14776 14777'VOIDmode' 14778 Void mode means the absence of a mode or an unspecified mode. For 14779 example, RTL expressions of code 'const_int' have mode 'VOIDmode' 14780 because they can be taken to have whatever mode the context 14781 requires. In debugging dumps of RTL, 'VOIDmode' is expressed by 14782 the absence of any mode. 14783 14784'QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 14785 These modes stand for a complex number represented as a pair of 14786 floating point values. The floating point values are in 'QFmode', 14787 'HFmode', 'SFmode', 'DFmode', 'XFmode', and 'TFmode', respectively. 14788 14789'CQImode, CHImode, CSImode, CDImode, CTImode, COImode' 14790 These modes stand for a complex number represented as a pair of 14791 integer values. The integer values are in 'QImode', 'HImode', 14792 'SImode', 'DImode', 'TImode', and 'OImode', respectively. 14793 14794'BND32mode BND64mode' 14795 These modes stand for bounds for pointer of 32 and 64 bit size 14796 respectively. Mode size is double pointer mode size. 14797 14798 The machine description defines 'Pmode' as a C macro which expands into 14799the machine mode used for addresses. Normally this is the mode whose 14800size is 'BITS_PER_WORD', 'SImode' on 32-bit machines. 14801 14802 The only modes which a machine description must support are 'QImode', 14803and the modes corresponding to 'BITS_PER_WORD', 'FLOAT_TYPE_SIZE' and 14804'DOUBLE_TYPE_SIZE'. The compiler will attempt to use 'DImode' for 148058-byte structures and unions, but this can be prevented by overriding 14806the definition of 'MAX_FIXED_MODE_SIZE'. Alternatively, you can have 14807the compiler use 'TImode' for 16-byte structures and unions. Likewise, 14808you can arrange for the C type 'short int' to avoid using 'HImode'. 14809 14810 Very few explicit references to machine modes remain in the compiler 14811and these few references will soon be removed. Instead, the machine 14812modes are divided into mode classes. These are represented by the 14813enumeration type 'enum mode_class' defined in 'machmode.h'. The 14814possible mode classes are: 14815 14816'MODE_INT' 14817 Integer modes. By default these are 'BImode', 'QImode', 'HImode', 14818 'SImode', 'DImode', 'TImode', and 'OImode'. 14819 14820'MODE_PARTIAL_INT' 14821 The "partial integer" modes, 'PQImode', 'PHImode', 'PSImode' and 14822 'PDImode'. 14823 14824'MODE_FLOAT' 14825 Floating point modes. By default these are 'QFmode', 'HFmode', 14826 'TQFmode', 'SFmode', 'DFmode', 'XFmode' and 'TFmode'. 14827 14828'MODE_DECIMAL_FLOAT' 14829 Decimal floating point modes. By default these are 'SDmode', 14830 'DDmode' and 'TDmode'. 14831 14832'MODE_FRACT' 14833 Signed fractional modes. By default these are 'QQmode', 'HQmode', 14834 'SQmode', 'DQmode' and 'TQmode'. 14835 14836'MODE_UFRACT' 14837 Unsigned fractional modes. By default these are 'UQQmode', 14838 'UHQmode', 'USQmode', 'UDQmode' and 'UTQmode'. 14839 14840'MODE_ACCUM' 14841 Signed accumulator modes. By default these are 'HAmode', 'SAmode', 14842 'DAmode' and 'TAmode'. 14843 14844'MODE_UACCUM' 14845 Unsigned accumulator modes. By default these are 'UHAmode', 14846 'USAmode', 'UDAmode' and 'UTAmode'. 14847 14848'MODE_COMPLEX_INT' 14849 Complex integer modes. (These are not currently implemented). 14850 14851'MODE_COMPLEX_FLOAT' 14852 Complex floating point modes. By default these are 'QCmode', 14853 'HCmode', 'SCmode', 'DCmode', 'XCmode', and 'TCmode'. 14854 14855'MODE_FUNCTION' 14856 Algol or Pascal function variables including a static chain. 14857 (These are not currently implemented). 14858 14859'MODE_CC' 14860 Modes representing condition code values. These are 'CCmode' plus 14861 any 'CC_MODE' modes listed in the 'MACHINE-modes.def'. *Note Jump 14862 Patterns::, also see *note Condition Code::. 14863 14864'MODE_POINTER_BOUNDS' 14865 Pointer bounds modes. Used to represent values of pointer bounds 14866 type. Operations in these modes may be executed as NOPs depending 14867 on hardware features and environment setup. 14868 14869'MODE_RANDOM' 14870 This is a catchall mode class for modes which don't fit into the 14871 above classes. Currently 'VOIDmode' and 'BLKmode' are in 14872 'MODE_RANDOM'. 14873 14874 Here are some C macros that relate to machine modes: 14875 14876'GET_MODE (X)' 14877 Returns the machine mode of the RTX X. 14878 14879'PUT_MODE (X, NEWMODE)' 14880 Alters the machine mode of the RTX X to be NEWMODE. 14881 14882'NUM_MACHINE_MODES' 14883 Stands for the number of machine modes available on the target 14884 machine. This is one greater than the largest numeric value of any 14885 machine mode. 14886 14887'GET_MODE_NAME (M)' 14888 Returns the name of mode M as a string. 14889 14890'GET_MODE_CLASS (M)' 14891 Returns the mode class of mode M. 14892 14893'GET_MODE_WIDER_MODE (M)' 14894 Returns the next wider natural mode. For example, the expression 14895 'GET_MODE_WIDER_MODE (QImode)' returns 'HImode'. 14896 14897'GET_MODE_SIZE (M)' 14898 Returns the size in bytes of a datum of mode M. 14899 14900'GET_MODE_BITSIZE (M)' 14901 Returns the size in bits of a datum of mode M. 14902 14903'GET_MODE_IBIT (M)' 14904 Returns the number of integral bits of a datum of fixed-point mode 14905 M. 14906 14907'GET_MODE_FBIT (M)' 14908 Returns the number of fractional bits of a datum of fixed-point 14909 mode M. 14910 14911'GET_MODE_MASK (M)' 14912 Returns a bitmask containing 1 for all bits in a word that fit 14913 within mode M. This macro can only be used for modes whose bitsize 14914 is less than or equal to 'HOST_BITS_PER_INT'. 14915 14916'GET_MODE_ALIGNMENT (M)' 14917 Return the required alignment, in bits, for an object of mode M. 14918 14919'GET_MODE_UNIT_SIZE (M)' 14920 Returns the size in bytes of the subunits of a datum of mode M. 14921 This is the same as 'GET_MODE_SIZE' except in the case of complex 14922 modes. For them, the unit size is the size of the real or 14923 imaginary part. 14924 14925'GET_MODE_NUNITS (M)' 14926 Returns the number of units contained in a mode, i.e., 14927 'GET_MODE_SIZE' divided by 'GET_MODE_UNIT_SIZE'. 14928 14929'GET_CLASS_NARROWEST_MODE (C)' 14930 Returns the narrowest mode in mode class C. 14931 14932 The following 3 variables are defined on every target. They can be 14933used to allocate buffers that are guaranteed to be large enough to hold 14934any value that can be represented on the target. The first two can be 14935overridden by defining them in the target's mode.def file, however, the 14936value must be a constant that can determined very early in the 14937compilation process. The third symbol cannot be overridden. 14938 14939'BITS_PER_UNIT' 14940 The number of bits in an addressable storage unit (byte). If you 14941 do not define this, the default is 8. 14942 14943'MAX_BITSIZE_MODE_ANY_INT' 14944 The maximum bitsize of any mode that is used in integer math. This 14945 should be overridden by the target if it uses large integers as 14946 containers for larger vectors but otherwise never uses the contents 14947 to compute integer values. 14948 14949'MAX_BITSIZE_MODE_ANY_MODE' 14950 The bitsize of the largest mode on the target. 14951 14952 The global variables 'byte_mode' and 'word_mode' contain modes whose 14953classes are 'MODE_INT' and whose bitsizes are either 'BITS_PER_UNIT' or 14954'BITS_PER_WORD', respectively. On 32-bit machines, these are 'QImode' 14955and 'SImode', respectively. 14956 14957 14958File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 14959 1496013.7 Constant Expression Types 14961============================== 14962 14963The simplest RTL expressions are those that represent constant values. 14964 14965'(const_int I)' 14966 This type of expression represents the integer value I. I is 14967 customarily accessed with the macro 'INTVAL' as in 'INTVAL (EXP)', 14968 which is equivalent to 'XWINT (EXP, 0)'. 14969 14970 Constants generated for modes with fewer bits than in 14971 'HOST_WIDE_INT' must be sign extended to full width (e.g., with 14972 'gen_int_mode'). For constants for modes with more bits than in 14973 'HOST_WIDE_INT' the implied high order bits of that constant are 14974 copies of the top bit. Note however that values are neither 14975 inherently signed nor inherently unsigned; where necessary, 14976 signedness is determined by the rtl operation instead. 14977 14978 There is only one expression object for the integer value zero; it 14979 is the value of the variable 'const0_rtx'. Likewise, the only 14980 expression for integer value one is found in 'const1_rtx', the only 14981 expression for integer value two is found in 'const2_rtx', and the 14982 only expression for integer value negative one is found in 14983 'constm1_rtx'. Any attempt to create an expression of code 14984 'const_int' and value zero, one, two or negative one will return 14985 'const0_rtx', 'const1_rtx', 'const2_rtx' or 'constm1_rtx' as 14986 appropriate. 14987 14988 Similarly, there is only one object for the integer whose value is 14989 'STORE_FLAG_VALUE'. It is found in 'const_true_rtx'. If 14990 'STORE_FLAG_VALUE' is one, 'const_true_rtx' and 'const1_rtx' will 14991 point to the same object. If 'STORE_FLAG_VALUE' is -1, 14992 'const_true_rtx' and 'constm1_rtx' will point to the same object. 14993 14994'(const_double:M I0 I1 ...)' 14995 This represents either a floating-point constant of mode M or (on 14996 older ports that do not define 'TARGET_SUPPORTS_WIDE_INT') an 14997 integer constant too large to fit into 'HOST_BITS_PER_WIDE_INT' 14998 bits but small enough to fit within twice that number of bits. In 14999 the latter case, M will be 'VOIDmode'. For integral values 15000 constants for modes with more bits than twice the number in 15001 'HOST_WIDE_INT' the implied high order bits of that constant are 15002 copies of the top bit of 'CONST_DOUBLE_HIGH'. Note however that 15003 integral values are neither inherently signed nor inherently 15004 unsigned; where necessary, signedness is determined by the rtl 15005 operation instead. 15006 15007 On more modern ports, 'CONST_DOUBLE' only represents floating point 15008 values. New ports define 'TARGET_SUPPORTS_WIDE_INT' to make this 15009 designation. 15010 15011 If M is 'VOIDmode', the bits of the value are stored in I0 and I1. 15012 I0 is customarily accessed with the macro 'CONST_DOUBLE_LOW' and I1 15013 with 'CONST_DOUBLE_HIGH'. 15014 15015 If the constant is floating point (regardless of its precision), 15016 then the number of integers used to store the value depends on the 15017 size of 'REAL_VALUE_TYPE' (*note Floating Point::). The integers 15018 represent a floating point number, but not precisely in the target 15019 machine's or host machine's floating point format. To convert them 15020 to the precise bit pattern used by the target machine, use the 15021 macro 'REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 15022 Output::). 15023 15024'(const_wide_int:M NUNITS ELT0 ...)' 15025 This contains an array of 'HOST_WIDE_INT's that is large enough to 15026 hold any constant that can be represented on the target. This form 15027 of rtl is only used on targets that define 15028 'TARGET_SUPPORTS_WIDE_INT' to be nonzero and then 'CONST_DOUBLE's 15029 are only used to hold floating-point values. If the target leaves 15030 'TARGET_SUPPORTS_WIDE_INT' defined as 0, 'CONST_WIDE_INT's are not 15031 used and 'CONST_DOUBLE's are as they were before. 15032 15033 The values are stored in a compressed format. The higher-order 0s 15034 or -1s are not represented if they are just the logical sign 15035 extension of the number that is represented. 15036 15037'CONST_WIDE_INT_VEC (CODE)' 15038 Returns the entire array of 'HOST_WIDE_INT's that are used to store 15039 the value. This macro should be rarely used. 15040 15041'CONST_WIDE_INT_NUNITS (CODE)' 15042 The number of 'HOST_WIDE_INT's used to represent the number. Note 15043 that this generally is smaller than the number of 'HOST_WIDE_INT's 15044 implied by the mode size. 15045 15046'CONST_WIDE_INT_NUNITS (CODE,I)' 15047 Returns the 'i'th element of the array. Element 0 is contains the 15048 low order bits of the constant. 15049 15050'(const_fixed:M ...)' 15051 Represents a fixed-point constant of mode M. The operand is a data 15052 structure of type 'struct fixed_value' and is accessed with the 15053 macro 'CONST_FIXED_VALUE'. The high part of data is accessed with 15054 'CONST_FIXED_VALUE_HIGH'; the low part is accessed with 15055 'CONST_FIXED_VALUE_LOW'. 15056 15057'(const_vector:M [X0 X1 ...])' 15058 Represents a vector constant. The square brackets stand for the 15059 vector containing the constant elements. X0, X1 and so on are the 15060 'const_int', 'const_double' or 'const_fixed' elements. 15061 15062 The number of units in a 'const_vector' is obtained with the macro 15063 'CONST_VECTOR_NUNITS' as in 'CONST_VECTOR_NUNITS (V)'. 15064 15065 Individual elements in a vector constant are accessed with the 15066 macro 'CONST_VECTOR_ELT' as in 'CONST_VECTOR_ELT (V, N)' where V is 15067 the vector constant and N is the element desired. 15068 15069'(const_string STR)' 15070 Represents a constant string with value STR. Currently this is 15071 used only for insn attributes (*note Insn Attributes::) since 15072 constant strings in C are placed in memory. 15073 15074'(symbol_ref:MODE SYMBOL)' 15075 Represents the value of an assembler label for data. SYMBOL is a 15076 string that describes the name of the assembler label. If it 15077 starts with a '*', the label is the rest of SYMBOL not including 15078 the '*'. Otherwise, the label is SYMBOL, usually prefixed with 15079 '_'. 15080 15081 The 'symbol_ref' contains a mode, which is usually 'Pmode'. 15082 Usually that is the only mode for which a symbol is directly valid. 15083 15084'(label_ref:MODE LABEL)' 15085 Represents the value of an assembler label for code. It contains 15086 one operand, an expression, which must be a 'code_label' or a 15087 'note' of type 'NOTE_INSN_DELETED_LABEL' that appears in the 15088 instruction sequence to identify the place where the label should 15089 go. 15090 15091 The reason for using a distinct expression type for code label 15092 references is so that jump optimization can distinguish them. 15093 15094 The 'label_ref' contains a mode, which is usually 'Pmode'. Usually 15095 that is the only mode for which a label is directly valid. 15096 15097'(const:M EXP)' 15098 Represents a constant that is the result of an assembly-time 15099 arithmetic computation. The operand, EXP, is an expression that 15100 contains only constants ('const_int', 'symbol_ref' and 'label_ref' 15101 expressions) combined with 'plus' and 'minus'. However, not all 15102 combinations are valid, since the assembler cannot do arbitrary 15103 arithmetic on relocatable symbols. 15104 15105 M should be 'Pmode'. 15106 15107'(high:M EXP)' 15108 Represents the high-order bits of EXP, usually a 'symbol_ref'. The 15109 number of bits is machine-dependent and is normally the number of 15110 bits specified in an instruction that initializes the high order 15111 bits of a register. It is used with 'lo_sum' to represent the 15112 typical two-instruction sequence used in RISC machines to reference 15113 a global memory location. 15114 15115 M should be 'Pmode'. 15116 15117 The macro 'CONST0_RTX (MODE)' refers to an expression with value 0 in 15118mode MODE. If mode MODE is of mode class 'MODE_INT', it returns 15119'const0_rtx'. If mode MODE is of mode class 'MODE_FLOAT', it returns a 15120'CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a 15121'CONST_VECTOR' expression in mode MODE. Similarly, the macro 15122'CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE 15123and similarly for 'CONST2_RTX'. The 'CONST1_RTX' and 'CONST2_RTX' 15124macros are undefined for vector modes. 15125 15126 15127File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 15128 1512913.8 Registers and Memory 15130========================= 15131 15132Here are the RTL expression types for describing access to machine 15133registers and to main memory. 15134 15135'(reg:M N)' 15136 For small values of the integer N (those that are less than 15137 'FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 15138 register number N: a "hard register". For larger values of N, it 15139 stands for a temporary value or "pseudo register". The compiler's 15140 strategy is to generate code assuming an unlimited number of such 15141 pseudo registers, and later convert them into hard registers or 15142 into memory references. 15143 15144 M is the machine mode of the reference. It is necessary because 15145 machines can generally refer to each register in more than one 15146 mode. For example, a register may contain a full word but there 15147 may be instructions to refer to it as a half word or as a single 15148 byte, as well as instructions to refer to it as a floating point 15149 number of various precisions. 15150 15151 Even for a register that the machine can access in only one mode, 15152 the mode must always be specified. 15153 15154 The symbol 'FIRST_PSEUDO_REGISTER' is defined by the machine 15155 description, since the number of hard registers on the machine is 15156 an invariant characteristic of the machine. Note, however, that 15157 not all of the machine registers must be general registers. All 15158 the machine registers that can be used for storage of data are 15159 given hard register numbers, even those that can be used only in 15160 certain instructions or can hold only certain types of data. 15161 15162 A hard register may be accessed in various modes throughout one 15163 function, but each pseudo register is given a natural mode and is 15164 accessed only in that mode. When it is necessary to describe an 15165 access to a pseudo register using a nonnatural mode, a 'subreg' 15166 expression is used. 15167 15168 A 'reg' expression with a machine mode that specifies more than one 15169 word of data may actually stand for several consecutive registers. 15170 If in addition the register number specifies a hardware register, 15171 then it actually represents several consecutive hardware registers 15172 starting with the specified one. 15173 15174 Each pseudo register number used in a function's RTL code is 15175 represented by a unique 'reg' expression. 15176 15177 Some pseudo register numbers, those within the range of 15178 'FIRST_VIRTUAL_REGISTER' to 'LAST_VIRTUAL_REGISTER' only appear 15179 during the RTL generation phase and are eliminated before the 15180 optimization phases. These represent locations in the stack frame 15181 that cannot be determined until RTL generation for the function has 15182 been completed. The following virtual register numbers are 15183 defined: 15184 15185 'VIRTUAL_INCOMING_ARGS_REGNUM' 15186 This points to the first word of the incoming arguments passed 15187 on the stack. Normally these arguments are placed there by 15188 the caller, but the callee may have pushed some arguments that 15189 were previously passed in registers. 15190 15191 When RTL generation is complete, this virtual register is 15192 replaced by the sum of the register given by 15193 'ARG_POINTER_REGNUM' and the value of 'FIRST_PARM_OFFSET'. 15194 15195 'VIRTUAL_STACK_VARS_REGNUM' 15196 If 'FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 15197 points to immediately above the first variable on the stack. 15198 Otherwise, it points to the first variable on the stack. 15199 15200 'VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 15201 register given by 'FRAME_POINTER_REGNUM' and the value 15202 'STARTING_FRAME_OFFSET'. 15203 15204 'VIRTUAL_STACK_DYNAMIC_REGNUM' 15205 This points to the location of dynamically allocated memory on 15206 the stack immediately after the stack pointer has been 15207 adjusted by the amount of memory desired. 15208 15209 This virtual register is replaced by the sum of the register 15210 given by 'STACK_POINTER_REGNUM' and the value 15211 'STACK_DYNAMIC_OFFSET'. 15212 15213 'VIRTUAL_OUTGOING_ARGS_REGNUM' 15214 This points to the location in the stack at which outgoing 15215 arguments should be written when the stack is pre-pushed 15216 (arguments pushed using push insns should always use 15217 'STACK_POINTER_REGNUM'). 15218 15219 This virtual register is replaced by the sum of the register 15220 given by 'STACK_POINTER_REGNUM' and the value 15221 'STACK_POINTER_OFFSET'. 15222 15223'(subreg:M1 REG:M2 BYTENUM)' 15224 15225 'subreg' expressions are used to refer to a register in a machine 15226 mode other than its natural one, or to refer to one register of a 15227 multi-part 'reg' that actually refers to several registers. 15228 15229 Each pseudo register has a natural mode. If it is necessary to 15230 operate on it in a different mode, the register must be enclosed in 15231 a 'subreg'. 15232 15233 There are currently three supported types for the first operand of 15234 a 'subreg': 15235 * pseudo registers This is the most common case. Most 'subreg's 15236 have pseudo 'reg's as their first operand. 15237 15238 * mem 'subreg's of 'mem' were common in earlier versions of GCC 15239 and are still supported. During the reload pass these are 15240 replaced by plain 'mem's. On machines that do not do 15241 instruction scheduling, use of 'subreg's of 'mem' are still 15242 used, but this is no longer recommended. Such 'subreg's are 15243 considered to be 'register_operand's rather than 15244 'memory_operand's before and during reload. Because of this, 15245 the scheduling passes cannot properly schedule instructions 15246 with 'subreg's of 'mem', so for machines that do scheduling, 15247 'subreg's of 'mem' should never be used. To support this, the 15248 combine and recog passes have explicit code to inhibit the 15249 creation of 'subreg's of 'mem' when 'INSN_SCHEDULING' is 15250 defined. 15251 15252 The use of 'subreg's of 'mem' after the reload pass is an area 15253 that is not well understood and should be avoided. There is 15254 still some code in the compiler to support this, but this code 15255 has possibly rotted. This use of 'subreg's is discouraged and 15256 will most likely not be supported in the future. 15257 15258 * hard registers It is seldom necessary to wrap hard registers 15259 in 'subreg's; such registers would normally reduce to a single 15260 'reg' rtx. This use of 'subreg's is discouraged and may not 15261 be supported in the future. 15262 15263 'subreg's of 'subreg's are not supported. Using 15264 'simplify_gen_subreg' is the recommended way to avoid this problem. 15265 15266 'subreg's come in two distinct flavors, each having its own usage 15267 and rules: 15268 15269 Paradoxical subregs 15270 When M1 is strictly wider than M2, the 'subreg' expression is 15271 called "paradoxical". The canonical test for this class of 15272 'subreg' is: 15273 15274 GET_MODE_SIZE (M1) > GET_MODE_SIZE (M2) 15275 15276 Paradoxical 'subreg's can be used as both lvalues and rvalues. 15277 When used as an lvalue, the low-order bits of the source value 15278 are stored in REG and the high-order bits are discarded. When 15279 used as an rvalue, the low-order bits of the 'subreg' are 15280 taken from REG while the high-order bits may or may not be 15281 defined. 15282 15283 The high-order bits of rvalues are in the following 15284 circumstances: 15285 15286 * 'subreg's of 'mem' When M2 is smaller than a word, the 15287 macro 'LOAD_EXTEND_OP', can control how the high-order 15288 bits are defined. 15289 15290 * 'subreg' of 'reg's The upper bits are defined when 15291 'SUBREG_PROMOTED_VAR_P' is true. 15292 'SUBREG_PROMOTED_UNSIGNED_P' describes what the upper 15293 bits hold. Such subregs usually represent local 15294 variables, register variables and parameter pseudo 15295 variables that have been promoted to a wider mode. 15296 15297 BYTENUM is always zero for a paradoxical 'subreg', even on 15298 big-endian targets. 15299 15300 For example, the paradoxical 'subreg': 15301 15302 (set (subreg:SI (reg:HI X) 0) Y) 15303 15304 stores the lower 2 bytes of Y in X and discards the upper 2 15305 bytes. A subsequent: 15306 15307 (set Z (subreg:SI (reg:HI X) 0)) 15308 15309 would set the lower two bytes of Z to Y and set the upper two 15310 bytes to an unknown value assuming 'SUBREG_PROMOTED_VAR_P' is 15311 false. 15312 15313 Normal subregs 15314 When M1 is at least as narrow as M2 the 'subreg' expression is 15315 called "normal". 15316 15317 Normal 'subreg's restrict consideration to certain bits of 15318 REG. There are two cases. If M1 is smaller than a word, the 15319 'subreg' refers to the least-significant part (or "lowpart") 15320 of one word of REG. If M1 is word-sized or greater, the 15321 'subreg' refers to one or more complete words. 15322 15323 When used as an lvalue, 'subreg' is a word-based accessor. 15324 Storing to a 'subreg' modifies all the words of REG that 15325 overlap the 'subreg', but it leaves the other words of REG 15326 alone. 15327 15328 When storing to a normal 'subreg' that is smaller than a word, 15329 the other bits of the referenced word are usually left in an 15330 undefined state. This laxity makes it easier to generate 15331 efficient code for such instructions. To represent an 15332 instruction that preserves all the bits outside of those in 15333 the 'subreg', use 'strict_low_part' or 'zero_extract' around 15334 the 'subreg'. 15335 15336 BYTENUM must identify the offset of the first byte of the 15337 'subreg' from the start of REG, assuming that REG is laid out 15338 in memory order. The memory order of bytes is defined by two 15339 target macros, 'WORDS_BIG_ENDIAN' and 'BYTES_BIG_ENDIAN': 15340 15341 * 'WORDS_BIG_ENDIAN', if set to 1, says that byte number 15342 zero is part of the most significant word; otherwise, it 15343 is part of the least significant word. 15344 15345 * 'BYTES_BIG_ENDIAN', if set to 1, says that byte number 15346 zero is the most significant byte within a word; 15347 otherwise, it is the least significant byte within a 15348 word. 15349 15350 On a few targets, 'FLOAT_WORDS_BIG_ENDIAN' disagrees with 15351 'WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 15352 floating point values as if they had the same endianness as 15353 integer values. This works because they handle them solely as 15354 a collection of integer values, with no particular numerical 15355 value. Only real.c and the runtime libraries care about 15356 'FLOAT_WORDS_BIG_ENDIAN'. 15357 15358 Thus, 15359 15360 (subreg:HI (reg:SI X) 2) 15361 15362 on a 'BYTES_BIG_ENDIAN', 'UNITS_PER_WORD == 4' target is the 15363 same as 15364 15365 (subreg:HI (reg:SI X) 0) 15366 15367 on a little-endian, 'UNITS_PER_WORD == 4' target. Both 15368 'subreg's access the lower two bytes of register X. 15369 15370 A 'MODE_PARTIAL_INT' mode behaves as if it were as wide as the 15371 corresponding 'MODE_INT' mode, except that it has an unknown number 15372 of undefined bits. For example: 15373 15374 (subreg:PSI (reg:SI 0) 0) 15375 15376 accesses the whole of '(reg:SI 0)', but the exact relationship 15377 between the 'PSImode' value and the 'SImode' value is not defined. 15378 If we assume 'UNITS_PER_WORD <= 4', then the following two 15379 'subreg's: 15380 15381 (subreg:PSI (reg:DI 0) 0) 15382 (subreg:PSI (reg:DI 0) 4) 15383 15384 represent independent 4-byte accesses to the two halves of '(reg:DI 15385 0)'. Both 'subreg's have an unknown number of undefined bits. 15386 15387 If 'UNITS_PER_WORD <= 2' then these two 'subreg's: 15388 15389 (subreg:HI (reg:PSI 0) 0) 15390 (subreg:HI (reg:PSI 0) 2) 15391 15392 represent independent 2-byte accesses that together span the whole 15393 of '(reg:PSI 0)'. Storing to the first 'subreg' does not affect 15394 the value of the second, and vice versa. '(reg:PSI 0)' has an 15395 unknown number of undefined bits, so the assignment: 15396 15397 (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4)) 15398 15399 does not guarantee that '(subreg:HI (reg:PSI 0) 0)' has the value 15400 '(reg:HI 4)'. 15401 15402 The rules above apply to both pseudo REGs and hard REGs. If the 15403 semantics are not correct for particular combinations of M1, M2 and 15404 hard REG, the target-specific code must ensure that those 15405 combinations are never used. For example: 15406 15407 CANNOT_CHANGE_MODE_CLASS (M2, M1, CLASS) 15408 15409 must be true for every class CLASS that includes REG. 15410 15411 The first operand of a 'subreg' expression is customarily accessed 15412 with the 'SUBREG_REG' macro and the second operand is customarily 15413 accessed with the 'SUBREG_BYTE' macro. 15414 15415 It has been several years since a platform in which 15416 'BYTES_BIG_ENDIAN' not equal to 'WORDS_BIG_ENDIAN' has been tested. 15417 Anyone wishing to support such a platform in the future may be 15418 confronted with code rot. 15419 15420'(scratch:M)' 15421 This represents a scratch register that will be required for the 15422 execution of a single instruction and not used subsequently. It is 15423 converted into a 'reg' by either the local register allocator or 15424 the reload pass. 15425 15426 'scratch' is usually present inside a 'clobber' operation (*note 15427 Side Effects::). 15428 15429'(cc0)' 15430 This refers to the machine's condition code register. It has no 15431 operands and may not have a machine mode. There are two ways to 15432 use it: 15433 15434 * To stand for a complete set of condition code flags. This is 15435 best on most machines, where each comparison sets the entire 15436 series of flags. 15437 15438 With this technique, '(cc0)' may be validly used in only two 15439 contexts: as the destination of an assignment (in test and 15440 compare instructions) and in comparison operators comparing 15441 against zero ('const_int' with value zero; that is to say, 15442 'const0_rtx'). 15443 15444 * To stand for a single flag that is the result of a single 15445 condition. This is useful on machines that have only a single 15446 flag bit, and in which comparison instructions must specify 15447 the condition to test. 15448 15449 With this technique, '(cc0)' may be validly used in only two 15450 contexts: as the destination of an assignment (in test and 15451 compare instructions) where the source is a comparison 15452 operator, and as the first operand of 'if_then_else' (in a 15453 conditional branch). 15454 15455 There is only one expression object of code 'cc0'; it is the value 15456 of the variable 'cc0_rtx'. Any attempt to create an expression of 15457 code 'cc0' will return 'cc0_rtx'. 15458 15459 Instructions can set the condition code implicitly. On many 15460 machines, nearly all instructions set the condition code based on 15461 the value that they compute or store. It is not necessary to 15462 record these actions explicitly in the RTL because the machine 15463 description includes a prescription for recognizing the 15464 instructions that do so (by means of the macro 'NOTICE_UPDATE_CC'). 15465 *Note Condition Code::. Only instructions whose sole purpose is to 15466 set the condition code, and instructions that use the condition 15467 code, need mention '(cc0)'. 15468 15469 On some machines, the condition code register is given a register 15470 number and a 'reg' is used instead of '(cc0)'. This is usually the 15471 preferable approach if only a small subset of instructions modify 15472 the condition code. Other machines store condition codes in 15473 general registers; in such cases a pseudo register should be used. 15474 15475 Some machines, such as the SPARC and RS/6000, have two sets of 15476 arithmetic instructions, one that sets and one that does not set 15477 the condition code. This is best handled by normally generating 15478 the instruction that does not set the condition code, and making a 15479 pattern that both performs the arithmetic and sets the condition 15480 code register (which would not be '(cc0)' in this case). For 15481 examples, search for 'addcc' and 'andcc' in 'sparc.md'. 15482 15483'(pc)' 15484 This represents the machine's program counter. It has no operands 15485 and may not have a machine mode. '(pc)' may be validly used only 15486 in certain specific contexts in jump instructions. 15487 15488 There is only one expression object of code 'pc'; it is the value 15489 of the variable 'pc_rtx'. Any attempt to create an expression of 15490 code 'pc' will return 'pc_rtx'. 15491 15492 All instructions that do not jump alter the program counter 15493 implicitly by incrementing it, but there is no need to mention this 15494 in the RTL. 15495 15496'(mem:M ADDR ALIAS)' 15497 This RTX represents a reference to main memory at an address 15498 represented by the expression ADDR. M specifies how large a unit 15499 of memory is accessed. ALIAS specifies an alias set for the 15500 reference. In general two items are in different alias sets if 15501 they cannot reference the same memory address. 15502 15503 The construct '(mem:BLK (scratch))' is considered to alias all 15504 other memories. Thus it may be used as a memory barrier in 15505 epilogue stack deallocation patterns. 15506 15507'(concatM RTX RTX)' 15508 This RTX represents the concatenation of two other RTXs. This is 15509 used for complex values. It should only appear in the RTL attached 15510 to declarations and during RTL generation. It should not appear in 15511 the ordinary insn chain. 15512 15513'(concatnM [RTX ...])' 15514 This RTX represents the concatenation of all the RTX to make a 15515 single value. Like 'concat', this should only appear in 15516 declarations, and not in the insn chain. 15517 15518 15519File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 15520 1552113.9 RTL Expressions for Arithmetic 15522=================================== 15523 15524Unless otherwise specified, all the operands of arithmetic expressions 15525must be valid for mode M. An operand is valid for mode M if it has mode 15526M, or if it is a 'const_int' or 'const_double' and M is a mode of class 15527'MODE_INT'. 15528 15529 For commutative binary operations, constants should be placed in the 15530second operand. 15531 15532'(plus:M X Y)' 15533'(ss_plus:M X Y)' 15534'(us_plus:M X Y)' 15535 15536 These three expressions all represent the sum of the values 15537 represented by X and Y carried out in machine mode M. They differ 15538 in their behavior on overflow of integer modes. 'plus' wraps round 15539 modulo the width of M; 'ss_plus' saturates at the maximum signed 15540 value representable in M; 'us_plus' saturates at the maximum 15541 unsigned value. 15542 15543'(lo_sum:M X Y)' 15544 15545 This expression represents the sum of X and the low-order bits of 15546 Y. It is used with 'high' (*note Constants::) to represent the 15547 typical two-instruction sequence used in RISC machines to reference 15548 a global memory location. 15549 15550 The number of low order bits is machine-dependent but is normally 15551 the number of bits in a 'Pmode' item minus the number of bits set 15552 by 'high'. 15553 15554 M should be 'Pmode'. 15555 15556'(minus:M X Y)' 15557'(ss_minus:M X Y)' 15558'(us_minus:M X Y)' 15559 15560 These three expressions represent the result of subtracting Y from 15561 X, carried out in mode M. Behavior on overflow is the same as for 15562 the three variants of 'plus' (see above). 15563 15564'(compare:M X Y)' 15565 Represents the result of subtracting Y from X for purposes of 15566 comparison. The result is computed without overflow, as if with 15567 infinite precision. 15568 15569 Of course, machines can't really subtract with infinite precision. 15570 However, they can pretend to do so when only the sign of the result 15571 will be used, which is the case when the result is stored in the 15572 condition code. And that is the _only_ way this kind of expression 15573 may validly be used: as a value to be stored in the condition 15574 codes, either '(cc0)' or a register. *Note Comparisons::. 15575 15576 The mode M is not related to the modes of X and Y, but instead is 15577 the mode of the condition code value. If '(cc0)' is used, it is 15578 'VOIDmode'. Otherwise it is some mode in class 'MODE_CC', often 15579 'CCmode'. *Note Condition Code::. If M is 'VOIDmode' or 'CCmode', 15580 the operation returns sufficient information (in an unspecified 15581 format) so that any comparison operator can be applied to the 15582 result of the 'COMPARE' operation. For other modes in class 15583 'MODE_CC', the operation only returns a subset of this information. 15584 15585 Normally, X and Y must have the same mode. Otherwise, 'compare' is 15586 valid only if the mode of X is in class 'MODE_INT' and Y is a 15587 'const_int' or 'const_double' with mode 'VOIDmode'. The mode of X 15588 determines what mode the comparison is to be done in; thus it must 15589 not be 'VOIDmode'. 15590 15591 If one of the operands is a constant, it should be placed in the 15592 second operand and the comparison code adjusted as appropriate. 15593 15594 A 'compare' specifying two 'VOIDmode' constants is not valid since 15595 there is no way to know in what mode the comparison is to be 15596 performed; the comparison must either be folded during the 15597 compilation or the first operand must be loaded into a register 15598 while its mode is still known. 15599 15600'(neg:M X)' 15601'(ss_neg:M X)' 15602'(us_neg:M X)' 15603 These two expressions represent the negation (subtraction from 15604 zero) of the value represented by X, carried out in mode M. They 15605 differ in the behavior on overflow of integer modes. In the case 15606 of 'neg', the negation of the operand may be a number not 15607 representable in mode M, in which case it is truncated to M. 15608 'ss_neg' and 'us_neg' ensure that an out-of-bounds result saturates 15609 to the maximum or minimum signed or unsigned value. 15610 15611'(mult:M X Y)' 15612'(ss_mult:M X Y)' 15613'(us_mult:M X Y)' 15614 Represents the signed product of the values represented by X and Y 15615 carried out in machine mode M. 'ss_mult' and 'us_mult' ensure that 15616 an out-of-bounds result saturates to the maximum or minimum signed 15617 or unsigned value. 15618 15619 Some machines support a multiplication that generates a product 15620 wider than the operands. Write the pattern for this as 15621 15622 (mult:M (sign_extend:M X) (sign_extend:M Y)) 15623 15624 where M is wider than the modes of X and Y, which need not be the 15625 same. 15626 15627 For unsigned widening multiplication, use the same idiom, but with 15628 'zero_extend' instead of 'sign_extend'. 15629 15630'(fma:M X Y Z)' 15631 Represents the 'fma', 'fmaf', and 'fmal' builtin functions, which 15632 compute 'X * Y + Z' without doing an intermediate rounding step. 15633 15634'(div:M X Y)' 15635'(ss_div:M X Y)' 15636 Represents the quotient in signed division of X by Y, carried out 15637 in machine mode M. If M is a floating point mode, it represents 15638 the exact quotient; otherwise, the integerized quotient. 'ss_div' 15639 ensures that an out-of-bounds result saturates to the maximum or 15640 minimum signed value. 15641 15642 Some machines have division instructions in which the operands and 15643 quotient widths are not all the same; you should represent such 15644 instructions using 'truncate' and 'sign_extend' as in, 15645 15646 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 15647 15648'(udiv:M X Y)' 15649'(us_div:M X Y)' 15650 Like 'div' but represents unsigned division. 'us_div' ensures that 15651 an out-of-bounds result saturates to the maximum or minimum 15652 unsigned value. 15653 15654'(mod:M X Y)' 15655'(umod:M X Y)' 15656 Like 'div' and 'udiv' but represent the remainder instead of the 15657 quotient. 15658 15659'(smin:M X Y)' 15660'(smax:M X Y)' 15661 Represents the smaller (for 'smin') or larger (for 'smax') of X and 15662 Y, interpreted as signed values in mode M. When used with floating 15663 point, if both operands are zeros, or if either operand is 'NaN', 15664 then it is unspecified which of the two operands is returned as the 15665 result. 15666 15667'(umin:M X Y)' 15668'(umax:M X Y)' 15669 Like 'smin' and 'smax', but the values are interpreted as unsigned 15670 integers. 15671 15672'(not:M X)' 15673 Represents the bitwise complement of the value represented by X, 15674 carried out in mode M, which must be a fixed-point machine mode. 15675 15676'(and:M X Y)' 15677 Represents the bitwise logical-and of the values represented by X 15678 and Y, carried out in machine mode M, which must be a fixed-point 15679 machine mode. 15680 15681'(ior:M X Y)' 15682 Represents the bitwise inclusive-or of the values represented by X 15683 and Y, carried out in machine mode M, which must be a fixed-point 15684 mode. 15685 15686'(xor:M X Y)' 15687 Represents the bitwise exclusive-or of the values represented by X 15688 and Y, carried out in machine mode M, which must be a fixed-point 15689 mode. 15690 15691'(ashift:M X C)' 15692'(ss_ashift:M X C)' 15693'(us_ashift:M X C)' 15694 These three expressions represent the result of arithmetically 15695 shifting X left by C places. They differ in their behavior on 15696 overflow of integer modes. An 'ashift' operation is a plain shift 15697 with no special behavior in case of a change in the sign bit; 15698 'ss_ashift' and 'us_ashift' saturates to the minimum or maximum 15699 representable value if any of the bits shifted out differs from the 15700 final sign bit. 15701 15702 X have mode M, a fixed-point machine mode. C be a fixed-point mode 15703 or be a constant with mode 'VOIDmode'; which mode is determined by 15704 the mode called for in the machine description entry for the 15705 left-shift instruction. For example, on the VAX, the mode of C is 15706 'QImode' regardless of M. 15707 15708'(lshiftrt:M X C)' 15709'(ashiftrt:M X C)' 15710 Like 'ashift' but for right shift. Unlike the case for left shift, 15711 these two operations are distinct. 15712 15713'(rotate:M X C)' 15714'(rotatert:M X C)' 15715 Similar but represent left and right rotate. If C is a constant, 15716 use 'rotate'. 15717 15718'(abs:M X)' 15719'(ss_abs:M X)' 15720 Represents the absolute value of X, computed in mode M. 'ss_abs' 15721 ensures that an out-of-bounds result saturates to the maximum 15722 signed value. 15723 15724'(sqrt:M X)' 15725 Represents the square root of X, computed in mode M. Most often M 15726 will be a floating point mode. 15727 15728'(ffs:M X)' 15729 Represents one plus the index of the least significant 1-bit in X, 15730 represented as an integer of mode M. (The value is zero if X is 15731 zero.) The mode of X must be M or 'VOIDmode'. 15732 15733'(clrsb:M X)' 15734 Represents the number of redundant leading sign bits in X, 15735 represented as an integer of mode M, starting at the most 15736 significant bit position. This is one less than the number of 15737 leading sign bits (either 0 or 1), with no special cases. The mode 15738 of X must be M or 'VOIDmode'. 15739 15740'(clz:M X)' 15741 Represents the number of leading 0-bits in X, represented as an 15742 integer of mode M, starting at the most significant bit position. 15743 If X is zero, the value is determined by 15744 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one 15745 of the few expressions that is not invariant under widening. The 15746 mode of X must be M or 'VOIDmode'. 15747 15748'(ctz:M X)' 15749 Represents the number of trailing 0-bits in X, represented as an 15750 integer of mode M, starting at the least significant bit position. 15751 If X is zero, the value is determined by 15752 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case, 15753 'ctz(x)' is equivalent to 'ffs(X) - 1'. The mode of X must be M or 15754 'VOIDmode'. 15755 15756'(popcount:M X)' 15757 Represents the number of 1-bits in X, represented as an integer of 15758 mode M. The mode of X must be M or 'VOIDmode'. 15759 15760'(parity:M X)' 15761 Represents the number of 1-bits modulo 2 in X, represented as an 15762 integer of mode M. The mode of X must be M or 'VOIDmode'. 15763 15764'(bswap:M X)' 15765 Represents the value X with the order of bytes reversed, carried 15766 out in mode M, which must be a fixed-point machine mode. The mode 15767 of X must be M or 'VOIDmode'. 15768 15769 15770File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 15771 1577213.10 Comparison Operations 15773=========================== 15774 15775Comparison operators test a relation on two operands and are considered 15776to represent a machine-dependent nonzero value described by, but not 15777necessarily equal to, 'STORE_FLAG_VALUE' (*note Misc::) if the relation 15778holds, or zero if it does not, for comparison operators whose results 15779have a 'MODE_INT' mode, 'FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 15780relation holds, or zero if it does not, for comparison operators that 15781return floating-point values, and a vector of either 15782'VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 15783zeros if it does not, for comparison operators that return vector 15784results. The mode of the comparison operation is independent of the 15785mode of the data being compared. If the comparison operation is being 15786tested (e.g., the first operand of an 'if_then_else'), the mode must be 15787'VOIDmode'. 15788 15789 There are two ways that comparison operations may be used. The 15790comparison operators may be used to compare the condition codes '(cc0)' 15791against zero, as in '(eq (cc0) (const_int 0))'. Such a construct 15792actually refers to the result of the preceding instruction in which the 15793condition codes were set. The instruction setting the condition code 15794must be adjacent to the instruction using the condition code; only 15795'note' insns may separate them. 15796 15797 Alternatively, a comparison operation may directly compare two data 15798objects. The mode of the comparison is determined by the operands; they 15799must both be valid for a common machine mode. A comparison with both 15800operands constant would be invalid as the machine mode could not be 15801deduced from it, but such a comparison should never exist in RTL due to 15802constant folding. 15803 15804 In the example above, if '(cc0)' were last set to '(compare X Y)', the 15805comparison operation is identical to '(eq X Y)'. Usually only one style 15806of comparisons is supported on a particular machine, but the combine 15807pass will try to merge the operations to produce the 'eq' shown in case 15808it exists in the context of the particular insn involved. 15809 15810 Inequality comparisons come in two flavors, signed and unsigned. Thus, 15811there are distinct expression codes 'gt' and 'gtu' for signed and 15812unsigned greater-than. These can produce different results for the same 15813pair of integer values: for example, 1 is signed greater-than -1 but not 15814unsigned greater-than, because -1 when regarded as unsigned is actually 15815'0xffffffff' which is greater than 1. 15816 15817 The signed comparisons are also used for floating point values. 15818Floating point comparisons are distinguished by the machine modes of the 15819operands. 15820 15821'(eq:M X Y)' 15822 'STORE_FLAG_VALUE' if the values represented by X and Y are equal, 15823 otherwise 0. 15824 15825'(ne:M X Y)' 15826 'STORE_FLAG_VALUE' if the values represented by X and Y are not 15827 equal, otherwise 0. 15828 15829'(gt:M X Y)' 15830 'STORE_FLAG_VALUE' if the X is greater than Y. If they are 15831 fixed-point, the comparison is done in a signed sense. 15832 15833'(gtu:M X Y)' 15834 Like 'gt' but does unsigned comparison, on fixed-point numbers 15835 only. 15836 15837'(lt:M X Y)' 15838'(ltu:M X Y)' 15839 Like 'gt' and 'gtu' but test for "less than". 15840 15841'(ge:M X Y)' 15842'(geu:M X Y)' 15843 Like 'gt' and 'gtu' but test for "greater than or equal". 15844 15845'(le:M X Y)' 15846'(leu:M X Y)' 15847 Like 'gt' and 'gtu' but test for "less than or equal". 15848 15849'(if_then_else COND THEN ELSE)' 15850 This is not a comparison operation but is listed here because it is 15851 always used in conjunction with a comparison operation. To be 15852 precise, COND is a comparison expression. This expression 15853 represents a choice, according to COND, between the value 15854 represented by THEN and the one represented by ELSE. 15855 15856 On most machines, 'if_then_else' expressions are valid only to 15857 express conditional jumps. 15858 15859'(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 15860 Similar to 'if_then_else', but more general. Each of TEST1, TEST2, 15861 ... is performed in turn. The result of this expression is the 15862 VALUE corresponding to the first nonzero test, or DEFAULT if none 15863 of the tests are nonzero expressions. 15864 15865 This is currently not valid for instruction patterns and is 15866 supported only for insn attributes. *Note Insn Attributes::. 15867 15868 15869File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 15870 1587113.11 Bit-Fields 15872================ 15873 15874Special expression codes exist to represent bit-field instructions. 15875 15876'(sign_extract:M LOC SIZE POS)' 15877 This represents a reference to a sign-extended bit-field contained 15878 or starting in LOC (a memory or register reference). The bit-field 15879 is SIZE bits wide and starts at bit POS. The compilation option 15880 'BITS_BIG_ENDIAN' says which end of the memory unit POS counts 15881 from. 15882 15883 If LOC is in memory, its mode must be a single-byte integer mode. 15884 If LOC is in a register, the mode to use is specified by the 15885 operand of the 'insv' or 'extv' pattern (*note Standard Names::) 15886 and is usually a full-word integer mode, which is the default if 15887 none is specified. 15888 15889 The mode of POS is machine-specific and is also specified in the 15890 'insv' or 'extv' pattern. 15891 15892 The mode M is the same as the mode that would be used for LOC if it 15893 were a register. 15894 15895 A 'sign_extract' can not appear as an lvalue, or part thereof, in 15896 RTL. 15897 15898'(zero_extract:M LOC SIZE POS)' 15899 Like 'sign_extract' but refers to an unsigned or zero-extended 15900 bit-field. The same sequence of bits are extracted, but they are 15901 filled to an entire word with zeros instead of by sign-extension. 15902 15903 Unlike 'sign_extract', this type of expressions can be lvalues in 15904 RTL; they may appear on the left side of an assignment, indicating 15905 insertion of a value into the specified bit-field. 15906 15907 15908File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 15909 1591013.12 Vector Operations 15911======================= 15912 15913All normal RTL expressions can be used with vector modes; they are 15914interpreted as operating on each part of the vector independently. 15915Additionally, there are a few new expressions to describe specific 15916vector operations. 15917 15918'(vec_merge:M VEC1 VEC2 ITEMS)' 15919 This describes a merge operation between two vectors. The result 15920 is a vector of mode M; its elements are selected from either VEC1 15921 or VEC2. Which elements are selected is described by ITEMS, which 15922 is a bit mask represented by a 'const_int'; a zero bit indicates 15923 the corresponding element in the result vector is taken from VEC2 15924 while a set bit indicates it is taken from VEC1. 15925 15926'(vec_select:M VEC1 SELECTION)' 15927 This describes an operation that selects parts of a vector. VEC1 15928 is the source vector, and SELECTION is a 'parallel' that contains a 15929 'const_int' for each of the subparts of the result vector, giving 15930 the number of the source subpart that should be stored into it. 15931 The result mode M is either the submode for a single element of 15932 VEC1 (if only one subpart is selected), or another vector mode with 15933 that element submode (if multiple subparts are selected). 15934 15935'(vec_concat:M X1 X2)' 15936 Describes a vector concat operation. The result is a concatenation 15937 of the vectors or scalars X1 and X2; its length is the sum of the 15938 lengths of the two inputs. 15939 15940'(vec_duplicate:M X)' 15941 This operation converts a scalar into a vector or a small vector 15942 into a larger one by duplicating the input values. The output 15943 vector mode must have the same submodes as the input vector mode or 15944 the scalar modes, and the number of output parts must be an integer 15945 multiple of the number of input parts. 15946 15947 15948File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 15949 1595013.13 Conversions 15951================= 15952 15953All conversions between machine modes must be represented by explicit 15954conversion operations. For example, an expression which is the sum of a 15955byte and a full word cannot be written as '(plus:SI (reg:QI 34) (reg:SI 1595680))' because the 'plus' operation requires two operands of the same 15957machine mode. Therefore, the byte-sized operand is enclosed in a 15958conversion operation, as in 15959 15960 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 15961 15962 The conversion operation is not a mere placeholder, because there may 15963be more than one way of converting from a given starting mode to the 15964desired final mode. The conversion operation code says how to do it. 15965 15966 For all conversion operations, X must not be 'VOIDmode' because the 15967mode in which to do the conversion would not be known. The conversion 15968must either be done at compile-time or X must be placed into a register. 15969 15970'(sign_extend:M X)' 15971 Represents the result of sign-extending the value X to machine mode 15972 M. M must be a fixed-point mode and X a fixed-point value of a 15973 mode narrower than M. 15974 15975'(zero_extend:M X)' 15976 Represents the result of zero-extending the value X to machine mode 15977 M. M must be a fixed-point mode and X a fixed-point value of a 15978 mode narrower than M. 15979 15980'(float_extend:M X)' 15981 Represents the result of extending the value X to machine mode M. 15982 M must be a floating point mode and X a floating point value of a 15983 mode narrower than M. 15984 15985'(truncate:M X)' 15986 Represents the result of truncating the value X to machine mode M. 15987 M must be a fixed-point mode and X a fixed-point value of a mode 15988 wider than M. 15989 15990'(ss_truncate:M X)' 15991 Represents the result of truncating the value X to machine mode M, 15992 using signed saturation in the case of overflow. Both M and the 15993 mode of X must be fixed-point modes. 15994 15995'(us_truncate:M X)' 15996 Represents the result of truncating the value X to machine mode M, 15997 using unsigned saturation in the case of overflow. Both M and the 15998 mode of X must be fixed-point modes. 15999 16000'(float_truncate:M X)' 16001 Represents the result of truncating the value X to machine mode M. 16002 M must be a floating point mode and X a floating point value of a 16003 mode wider than M. 16004 16005'(float:M X)' 16006 Represents the result of converting fixed point value X, regarded 16007 as signed, to floating point mode M. 16008 16009'(unsigned_float:M X)' 16010 Represents the result of converting fixed point value X, regarded 16011 as unsigned, to floating point mode M. 16012 16013'(fix:M X)' 16014 When M is a floating-point mode, represents the result of 16015 converting floating point value X (valid for mode M) to an integer, 16016 still represented in floating point mode M, by rounding towards 16017 zero. 16018 16019 When M is a fixed-point mode, represents the result of converting 16020 floating point value X to mode M, regarded as signed. How rounding 16021 is done is not specified, so this operation may be used validly in 16022 compiling C code only for integer-valued operands. 16023 16024'(unsigned_fix:M X)' 16025 Represents the result of converting floating point value X to fixed 16026 point mode M, regarded as unsigned. How rounding is done is not 16027 specified. 16028 16029'(fract_convert:M X)' 16030 Represents the result of converting fixed-point value X to 16031 fixed-point mode M, signed integer value X to fixed-point mode M, 16032 floating-point value X to fixed-point mode M, fixed-point value X 16033 to integer mode M regarded as signed, or fixed-point value X to 16034 floating-point mode M. When overflows or underflows happen, the 16035 results are undefined. 16036 16037'(sat_fract:M X)' 16038 Represents the result of converting fixed-point value X to 16039 fixed-point mode M, signed integer value X to fixed-point mode M, 16040 or floating-point value X to fixed-point mode M. When overflows or 16041 underflows happen, the results are saturated to the maximum or the 16042 minimum. 16043 16044'(unsigned_fract_convert:M X)' 16045 Represents the result of converting fixed-point value X to integer 16046 mode M regarded as unsigned, or unsigned integer value X to 16047 fixed-point mode M. When overflows or underflows happen, the 16048 results are undefined. 16049 16050'(unsigned_sat_fract:M X)' 16051 Represents the result of converting unsigned integer value X to 16052 fixed-point mode M. When overflows or underflows happen, the 16053 results are saturated to the maximum or the minimum. 16054 16055 16056File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 16057 1605813.14 Declarations 16059================== 16060 16061Declaration expression codes do not represent arithmetic operations but 16062rather state assertions about their operands. 16063 16064'(strict_low_part (subreg:M (reg:N R) 0))' 16065 This expression code is used in only one context: as the 16066 destination operand of a 'set' expression. In addition, the 16067 operand of this expression must be a non-paradoxical 'subreg' 16068 expression. 16069 16070 The presence of 'strict_low_part' says that the part of the 16071 register which is meaningful in mode N, but is not part of mode M, 16072 is not to be altered. Normally, an assignment to such a subreg is 16073 allowed to have undefined effects on the rest of the register when 16074 M is less than a word. 16075 16076 16077File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 16078 1607913.15 Side Effect Expressions 16080============================= 16081 16082The expression codes described so far represent values, not actions. 16083But machine instructions never produce values; they are meaningful only 16084for their side effects on the state of the machine. Special expression 16085codes are used to represent side effects. 16086 16087 The body of an instruction is always one of these side effect codes; 16088the codes described above, which represent values, appear only as the 16089operands of these. 16090 16091'(set LVAL X)' 16092 Represents the action of storing the value of X into the place 16093 represented by LVAL. LVAL must be an expression representing a 16094 place that can be stored in: 'reg' (or 'subreg', 'strict_low_part' 16095 or 'zero_extract'), 'mem', 'pc', 'parallel', or 'cc0'. 16096 16097 If LVAL is a 'reg', 'subreg' or 'mem', it has a machine mode; then 16098 X must be valid for that mode. 16099 16100 If LVAL is a 'reg' whose machine mode is less than the full width 16101 of the register, then it means that the part of the register 16102 specified by the machine mode is given the specified value and the 16103 rest of the register receives an undefined value. Likewise, if 16104 LVAL is a 'subreg' whose machine mode is narrower than the mode of 16105 the register, the rest of the register can be changed in an 16106 undefined way. 16107 16108 If LVAL is a 'strict_low_part' of a subreg, then the part of the 16109 register specified by the machine mode of the 'subreg' is given the 16110 value X and the rest of the register is not changed. 16111 16112 If LVAL is a 'zero_extract', then the referenced part of the 16113 bit-field (a memory or register reference) specified by the 16114 'zero_extract' is given the value X and the rest of the bit-field 16115 is not changed. Note that 'sign_extract' can not appear in LVAL. 16116 16117 If LVAL is '(cc0)', it has no machine mode, and X may be either a 16118 'compare' expression or a value that may have any mode. The latter 16119 case represents a "test" instruction. The expression '(set (cc0) 16120 (reg:M N))' is equivalent to '(set (cc0) (compare (reg:M N) 16121 (const_int 0)))'. Use the former expression to save space during 16122 the compilation. 16123 16124 If LVAL is a 'parallel', it is used to represent the case of a 16125 function returning a structure in multiple registers. Each element 16126 of the 'parallel' is an 'expr_list' whose first operand is a 'reg' 16127 and whose second operand is a 'const_int' representing the offset 16128 (in bytes) into the structure at which the data in that register 16129 corresponds. The first element may be null to indicate that the 16130 structure is also passed partly in memory. 16131 16132 If LVAL is '(pc)', we have a jump instruction, and the 16133 possibilities for X are very limited. It may be a 'label_ref' 16134 expression (unconditional jump). It may be an 'if_then_else' 16135 (conditional jump), in which case either the second or the third 16136 operand must be '(pc)' (for the case which does not jump) and the 16137 other of the two must be a 'label_ref' (for the case which does 16138 jump). X may also be a 'mem' or '(plus:SI (pc) Y)', where Y may be 16139 a 'reg' or a 'mem'; these unusual patterns are used to represent 16140 jumps through branch tables. 16141 16142 If LVAL is neither '(cc0)' nor '(pc)', the mode of LVAL must not be 16143 'VOIDmode' and the mode of X must be valid for the mode of LVAL. 16144 16145 LVAL is customarily accessed with the 'SET_DEST' macro and X with 16146 the 'SET_SRC' macro. 16147 16148'(return)' 16149 As the sole expression in a pattern, represents a return from the 16150 current function, on machines where this can be done with one 16151 instruction, such as VAXen. On machines where a multi-instruction 16152 "epilogue" must be executed in order to return from the function, 16153 returning is done by jumping to a label which precedes the 16154 epilogue, and the 'return' expression code is never used. 16155 16156 Inside an 'if_then_else' expression, represents the value to be 16157 placed in 'pc' to return to the caller. 16158 16159 Note that an insn pattern of '(return)' is logically equivalent to 16160 '(set (pc) (return))', but the latter form is never used. 16161 16162'(simple_return)' 16163 Like '(return)', but truly represents only a function return, while 16164 '(return)' may represent an insn that also performs other functions 16165 of the function epilogue. Like '(return)', this may also occur in 16166 conditional jumps. 16167 16168'(call FUNCTION NARGS)' 16169 Represents a function call. FUNCTION is a 'mem' expression whose 16170 address is the address of the function to be called. NARGS is an 16171 expression which can be used for two purposes: on some machines it 16172 represents the number of bytes of stack argument; on others, it 16173 represents the number of argument registers. 16174 16175 Each machine has a standard machine mode which FUNCTION must have. 16176 The machine description defines macro 'FUNCTION_MODE' to expand 16177 into the requisite mode name. The purpose of this mode is to 16178 specify what kind of addressing is allowed, on machines where the 16179 allowed kinds of addressing depend on the machine mode being 16180 addressed. 16181 16182'(clobber X)' 16183 Represents the storing or possible storing of an unpredictable, 16184 undescribed value into X, which must be a 'reg', 'scratch', 16185 'parallel' or 'mem' expression. 16186 16187 One place this is used is in string instructions that store 16188 standard values into particular hard registers. It may not be 16189 worth the trouble to describe the values that are stored, but it is 16190 essential to inform the compiler that the registers will be 16191 altered, lest it attempt to keep data in them across the string 16192 instruction. 16193 16194 If X is '(mem:BLK (const_int 0))' or '(mem:BLK (scratch))', it 16195 means that all memory locations must be presumed clobbered. If X 16196 is a 'parallel', it has the same meaning as a 'parallel' in a 'set' 16197 expression. 16198 16199 Note that the machine description classifies certain hard registers 16200 as "call-clobbered". All function call instructions are assumed by 16201 default to clobber these registers, so there is no need to use 16202 'clobber' expressions to indicate this fact. Also, each function 16203 call is assumed to have the potential to alter any memory location, 16204 unless the function is declared 'const'. 16205 16206 If the last group of expressions in a 'parallel' are each a 16207 'clobber' expression whose arguments are 'reg' or 'match_scratch' 16208 (*note RTL Template::) expressions, the combiner phase can add the 16209 appropriate 'clobber' expressions to an insn it has constructed 16210 when doing so will cause a pattern to be matched. 16211 16212 This feature can be used, for example, on a machine that whose 16213 multiply and add instructions don't use an MQ register but which 16214 has an add-accumulate instruction that does clobber the MQ 16215 register. Similarly, a combined instruction might require a 16216 temporary register while the constituent instructions might not. 16217 16218 When a 'clobber' expression for a register appears inside a 16219 'parallel' with other side effects, the register allocator 16220 guarantees that the register is unoccupied both before and after 16221 that insn if it is a hard register clobber. For pseudo-register 16222 clobber, the register allocator and the reload pass do not assign 16223 the same hard register to the clobber and the input operands if 16224 there is an insn alternative containing the '&' constraint (*note 16225 Modifiers::) for the clobber and the hard register is in register 16226 classes of the clobber in the alternative. You can clobber either 16227 a specific hard register, a pseudo register, or a 'scratch' 16228 expression; in the latter two cases, GCC will allocate a hard 16229 register that is available there for use as a temporary. 16230 16231 For instructions that require a temporary register, you should use 16232 'scratch' instead of a pseudo-register because this will allow the 16233 combiner phase to add the 'clobber' when required. You do this by 16234 coding ('clobber' ('match_scratch' ...)). If you do clobber a 16235 pseudo register, use one which appears nowhere else--generate a new 16236 one each time. Otherwise, you may confuse CSE. 16237 16238 There is one other known use for clobbering a pseudo register in a 16239 'parallel': when one of the input operands of the insn is also 16240 clobbered by the insn. In this case, using the same pseudo 16241 register in the clobber and elsewhere in the insn produces the 16242 expected results. 16243 16244'(use X)' 16245 Represents the use of the value of X. It indicates that the value 16246 in X at this point in the program is needed, even though it may not 16247 be apparent why this is so. Therefore, the compiler will not 16248 attempt to delete previous instructions whose only effect is to 16249 store a value in X. X must be a 'reg' expression. 16250 16251 In some situations, it may be tempting to add a 'use' of a register 16252 in a 'parallel' to describe a situation where the value of a 16253 special register will modify the behavior of the instruction. A 16254 hypothetical example might be a pattern for an addition that can 16255 either wrap around or use saturating addition depending on the 16256 value of a special control register: 16257 16258 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 16259 (reg:SI 4)] 0)) 16260 (use (reg:SI 1))]) 16261 16262 16263 This will not work, several of the optimizers only look at 16264 expressions locally; it is very likely that if you have multiple 16265 insns with identical inputs to the 'unspec', they will be optimized 16266 away even if register 1 changes in between. 16267 16268 This means that 'use' can _only_ be used to describe that the 16269 register is live. You should think twice before adding 'use' 16270 statements, more often you will want to use 'unspec' instead. The 16271 'use' RTX is most commonly useful to describe that a fixed register 16272 is implicitly used in an insn. It is also safe to use in patterns 16273 where the compiler knows for other reasons that the result of the 16274 whole pattern is variable, such as 'movmemM' or 'call' patterns. 16275 16276 During the reload phase, an insn that has a 'use' as pattern can 16277 carry a reg_equal note. These 'use' insns will be deleted before 16278 the reload phase exits. 16279 16280 During the delayed branch scheduling phase, X may be an insn. This 16281 indicates that X previously was located at this place in the code 16282 and its data dependencies need to be taken into account. These 16283 'use' insns will be deleted before the delayed branch scheduling 16284 phase exits. 16285 16286'(parallel [X0 X1 ...])' 16287 Represents several side effects performed in parallel. The square 16288 brackets stand for a vector; the operand of 'parallel' is a vector 16289 of expressions. X0, X1 and so on are individual side effect 16290 expressions--expressions of code 'set', 'call', 'return', 16291 'simple_return', 'clobber' or 'use'. 16292 16293 "In parallel" means that first all the values used in the 16294 individual side-effects are computed, and second all the actual 16295 side-effects are performed. For example, 16296 16297 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 16298 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 16299 16300 says unambiguously that the values of hard register 1 and the 16301 memory location addressed by it are interchanged. In both places 16302 where '(reg:SI 1)' appears as a memory address it refers to the 16303 value in register 1 _before_ the execution of the insn. 16304 16305 It follows that it is _incorrect_ to use 'parallel' and expect the 16306 result of one 'set' to be available for the next one. For example, 16307 people sometimes attempt to represent a jump-if-zero instruction 16308 this way: 16309 16310 (parallel [(set (cc0) (reg:SI 34)) 16311 (set (pc) (if_then_else 16312 (eq (cc0) (const_int 0)) 16313 (label_ref ...) 16314 (pc)))]) 16315 16316 But this is incorrect, because it says that the jump condition 16317 depends on the condition code value _before_ this instruction, not 16318 on the new value that is set by this instruction. 16319 16320 Peephole optimization, which takes place together with final 16321 assembly code output, can produce insns whose patterns consist of a 16322 'parallel' whose elements are the operands needed to output the 16323 resulting assembler code--often 'reg', 'mem' or constant 16324 expressions. This would not be well-formed RTL at any other stage 16325 in compilation, but it is OK then because no further optimization 16326 remains to be done. However, the definition of the macro 16327 'NOTICE_UPDATE_CC', if any, must deal with such insns if you define 16328 any peephole optimizations. 16329 16330'(cond_exec [COND EXPR])' 16331 Represents a conditionally executed expression. The EXPR is 16332 executed only if the COND is nonzero. The COND expression must not 16333 have side-effects, but the EXPR may very well have side-effects. 16334 16335'(sequence [INSNS ...])' 16336 Represents a sequence of insns. If a 'sequence' appears in the 16337 chain of insns, then each of the INSNS that appears in the sequence 16338 must be suitable for appearing in the chain of insns, i.e. must 16339 satisfy the 'INSN_P' predicate. 16340 16341 After delay-slot scheduling is completed, an insn and all the insns 16342 that reside in its delay slots are grouped together into a 16343 'sequence'. The insn requiring the delay slot is the first insn in 16344 the vector; subsequent insns are to be placed in the delay slot. 16345 16346 'INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 16347 indicate that a branch insn should be used that will conditionally 16348 annul the effect of the insns in the delay slots. In such a case, 16349 'INSN_FROM_TARGET_P' indicates that the insn is from the target of 16350 the branch and should be executed only if the branch is taken; 16351 otherwise the insn should be executed only if the branch is not 16352 taken. *Note Delay Slots::. 16353 16354 Some back ends also use 'sequence' objects for purposes other than 16355 delay-slot groups. This is not supported in the common parts of 16356 the compiler, which treat such sequences as delay-slot groups. 16357 16358 DWARF2 Call Frame Address (CFA) adjustments are sometimes also 16359 expressed using 'sequence' objects as the value of a 16360 'RTX_FRAME_RELATED_P' note. This only happens if the CFA 16361 adjustments cannot be easily derived from the pattern of the 16362 instruction to which the note is attached. In such cases, the 16363 value of the note is used instead of best-guesing the semantics of 16364 the instruction. The back end can attach notes containing a 16365 'sequence' of 'set' patterns that express the effect of the parent 16366 instruction. 16367 16368 These expression codes appear in place of a side effect, as the body of 16369an insn, though strictly speaking they do not always describe side 16370effects as such: 16371 16372'(asm_input S)' 16373 Represents literal assembler code as described by the string S. 16374 16375'(unspec [OPERANDS ...] INDEX)' 16376'(unspec_volatile [OPERANDS ...] INDEX)' 16377 Represents a machine-specific operation on OPERANDS. INDEX selects 16378 between multiple machine-specific operations. 'unspec_volatile' is 16379 used for volatile operations and operations that may trap; 'unspec' 16380 is used for other operations. 16381 16382 These codes may appear inside a 'pattern' of an insn, inside a 16383 'parallel', or inside an expression. 16384 16385'(addr_vec:M [LR0 LR1 ...])' 16386 Represents a table of jump addresses. The vector elements LR0, 16387 etc., are 'label_ref' expressions. The mode M specifies how much 16388 space is given to each address; normally M would be 'Pmode'. 16389 16390'(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 16391 Represents a table of jump addresses expressed as offsets from 16392 BASE. The vector elements LR0, etc., are 'label_ref' expressions 16393 and so is BASE. The mode M specifies how much space is given to 16394 each address-difference. MIN and MAX are set up by branch 16395 shortening and hold a label with a minimum and a maximum address, 16396 respectively. FLAGS indicates the relative position of BASE, MIN 16397 and MAX to the containing insn and of MIN and MAX to BASE. See 16398 rtl.def for details. 16399 16400'(prefetch:M ADDR RW LOCALITY)' 16401 Represents prefetch of memory at address ADDR. Operand RW is 1 if 16402 the prefetch is for data to be written, 0 otherwise; targets that 16403 do not support write prefetches should treat this as a normal 16404 prefetch. Operand LOCALITY specifies the amount of temporal 16405 locality; 0 if there is none or 1, 2, or 3 for increasing levels of 16406 temporal locality; targets that do not support locality hints 16407 should ignore this. 16408 16409 This insn is used to minimize cache-miss latency by moving data 16410 into a cache before it is accessed. It should use only 16411 non-faulting data prefetch instructions. 16412 16413 16414File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 16415 1641613.16 Embedded Side-Effects on Addresses 16417======================================== 16418 16419Six special side-effect expression codes appear as memory addresses. 16420 16421'(pre_dec:M X)' 16422 Represents the side effect of decrementing X by a standard amount 16423 and represents also the value that X has after being decremented. 16424 X must be a 'reg' or 'mem', but most machines allow only a 'reg'. 16425 M must be the machine mode for pointers on the machine in use. The 16426 amount X is decremented by is the length in bytes of the machine 16427 mode of the containing memory reference of which this expression 16428 serves as the address. Here is an example of its use: 16429 16430 (mem:DF (pre_dec:SI (reg:SI 39))) 16431 16432 This says to decrement pseudo register 39 by the length of a 16433 'DFmode' value and use the result to address a 'DFmode' value. 16434 16435'(pre_inc:M X)' 16436 Similar, but specifies incrementing X instead of decrementing it. 16437 16438'(post_dec:M X)' 16439 Represents the same side effect as 'pre_dec' but a different value. 16440 The value represented here is the value X has before being 16441 decremented. 16442 16443'(post_inc:M X)' 16444 Similar, but specifies incrementing X instead of decrementing it. 16445 16446'(post_modify:M X Y)' 16447 16448 Represents the side effect of setting X to Y and represents X 16449 before X is modified. X must be a 'reg' or 'mem', but most 16450 machines allow only a 'reg'. M must be the machine mode for 16451 pointers on the machine in use. 16452 16453 The expression Y must be one of three forms: '(plus:M X Z)', 16454 '(minus:M X Z)', or '(plus:M X I)', where Z is an index register 16455 and I is a constant. 16456 16457 Here is an example of its use: 16458 16459 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 16460 (reg:SI 48)))) 16461 16462 This says to modify pseudo register 42 by adding the contents of 16463 pseudo register 48 to it, after the use of what ever 42 points to. 16464 16465'(pre_modify:M X EXPR)' 16466 Similar except side effects happen before the use. 16467 16468 These embedded side effect expressions must be used with care. 16469Instruction patterns may not use them. Until the 'flow' pass of the 16470compiler, they may occur only to represent pushes onto the stack. The 16471'flow' pass finds cases where registers are incremented or decremented 16472in one instruction and used as an address shortly before or after; these 16473cases are then transformed to use pre- or post-increment or -decrement. 16474 16475 If a register used as the operand of these expressions is used in 16476another address in an insn, the original value of the register is used. 16477Uses of the register outside of an address are not permitted within the 16478same insn as a use in an embedded side effect expression because such 16479insns behave differently on different machines and hence must be treated 16480as ambiguous and disallowed. 16481 16482 An instruction that can be represented with an embedded side effect 16483could also be represented using 'parallel' containing an additional 16484'set' to describe how the address register is altered. This is not done 16485because machines that allow these operations at all typically allow them 16486wherever a memory address is called for. Describing them as additional 16487parallel stores would require doubling the number of entries in the 16488machine description. 16489 16490 16491File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL 16492 1649313.17 Assembler Instructions as Expressions 16494=========================================== 16495 16496The RTX code 'asm_operands' represents a value produced by a 16497user-specified assembler instruction. It is used to represent an 'asm' 16498statement with arguments. An 'asm' statement with a single output 16499operand, like this: 16500 16501 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 16502 16503is represented using a single 'asm_operands' RTX which represents the 16504value that is stored in 'outputvar': 16505 16506 (set RTX-FOR-OUTPUTVAR 16507 (asm_operands "foo %1,%2,%0" "a" 0 16508 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 16509 [(asm_input:M1 "g") 16510 (asm_input:M2 "di")])) 16511 16512Here the operands of the 'asm_operands' RTX are the assembler template 16513string, the output-operand's constraint, the index-number of the output 16514operand among the output operands specified, a vector of input operand 16515RTX's, and a vector of input-operand modes and constraints. The mode M1 16516is the mode of the sum 'x+y'; M2 is that of '*z'. 16517 16518 When an 'asm' statement has multiple output values, its insn has 16519several such 'set' RTX's inside of a 'parallel'. Each 'set' contains an 16520'asm_operands'; all of these share the same assembler template and 16521vectors, but each contains the constraint for the respective output 16522operand. They are also distinguished by the output-operand index 16523number, which is 0, 1, ... for successive output operands. 16524 16525 16526File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL 16527 1652813.18 Variable Location Debug Information in RTL 16529================================================ 16530 16531Variable tracking relies on 'MEM_EXPR' and 'REG_EXPR' annotations to 16532determine what user variables memory and register references refer to. 16533 16534 Variable tracking at assignments uses these notes only when they refer 16535to variables that live at fixed locations (e.g., addressable variables, 16536global non-automatic variables). For variables whose location may vary, 16537it relies on the following types of notes. 16538 16539'(var_location:MODE VAR EXP STAT)' 16540 Binds variable 'var', a tree, to value EXP, an RTL expression. It 16541 appears only in 'NOTE_INSN_VAR_LOCATION' and 'DEBUG_INSN's, with 16542 slightly different meanings. MODE, if present, represents the mode 16543 of EXP, which is useful if it is a modeless expression. STAT is 16544 only meaningful in notes, indicating whether the variable is known 16545 to be initialized or uninitialized. 16546 16547'(debug_expr:MODE DECL)' 16548 Stands for the value bound to the 'DEBUG_EXPR_DECL' DECL, that 16549 points back to it, within value expressions in 'VAR_LOCATION' 16550 nodes. 16551 16552 16553File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL 16554 1655513.19 Insns 16556=========== 16557 16558The RTL representation of the code for a function is a doubly-linked 16559chain of objects called "insns". Insns are expressions with special 16560codes that are used for no other purpose. Some insns are actual 16561instructions; others represent dispatch tables for 'switch' statements; 16562others represent labels to jump to or various sorts of declarative 16563information. 16564 16565 In addition to its own specific data, each insn must have a unique 16566id-number that distinguishes it from all other insns in the current 16567function (after delayed branch scheduling, copies of an insn with the 16568same id-number may be present in multiple places in a function, but 16569these copies will always be identical and will only appear inside a 16570'sequence'), and chain pointers to the preceding and following insns. 16571These three fields occupy the same position in every insn, independent 16572of the expression code of the insn. They could be accessed with 'XEXP' 16573and 'XINT', but instead three special macros are always used: 16574 16575'INSN_UID (I)' 16576 Accesses the unique id of insn I. 16577 16578'PREV_INSN (I)' 16579 Accesses the chain pointer to the insn preceding I. If I is the 16580 first insn, this is a null pointer. 16581 16582'NEXT_INSN (I)' 16583 Accesses the chain pointer to the insn following I. If I is the 16584 last insn, this is a null pointer. 16585 16586 The first insn in the chain is obtained by calling 'get_insns'; the 16587last insn is the result of calling 'get_last_insn'. Within the chain 16588delimited by these insns, the 'NEXT_INSN' and 'PREV_INSN' pointers must 16589always correspond: if INSN is not the first insn, 16590 16591 NEXT_INSN (PREV_INSN (INSN)) == INSN 16592 16593is always true and if INSN is not the last insn, 16594 16595 PREV_INSN (NEXT_INSN (INSN)) == INSN 16596 16597is always true. 16598 16599 After delay slot scheduling, some of the insns in the chain might be 16600'sequence' expressions, which contain a vector of insns. The value of 16601'NEXT_INSN' in all but the last of these insns is the next insn in the 16602vector; the value of 'NEXT_INSN' of the last insn in the vector is the 16603same as the value of 'NEXT_INSN' for the 'sequence' in which it is 16604contained. Similar rules apply for 'PREV_INSN'. 16605 16606 This means that the above invariants are not necessarily true for insns 16607inside 'sequence' expressions. Specifically, if INSN is the first insn 16608in a 'sequence', 'NEXT_INSN (PREV_INSN (INSN))' is the insn containing 16609the 'sequence' expression, as is the value of 'PREV_INSN (NEXT_INSN 16610(INSN))' if INSN is the last insn in the 'sequence' expression. You can 16611use these expressions to find the containing 'sequence' expression. 16612 16613 Every insn has one of the following expression codes: 16614 16615'insn' 16616 The expression code 'insn' is used for instructions that do not 16617 jump and do not do function calls. 'sequence' expressions are 16618 always contained in insns with code 'insn' even if one of those 16619 insns should jump or do function calls. 16620 16621 Insns with code 'insn' have four additional fields beyond the three 16622 mandatory ones listed above. These four are described in a table 16623 below. 16624 16625'jump_insn' 16626 The expression code 'jump_insn' is used for instructions that may 16627 jump (or, more generally, may contain 'label_ref' expressions to 16628 which 'pc' can be set in that instruction). If there is an 16629 instruction to return from the current function, it is recorded as 16630 a 'jump_insn'. 16631 16632 'jump_insn' insns have the same extra fields as 'insn' insns, 16633 accessed in the same way and in addition contain a field 16634 'JUMP_LABEL' which is defined once jump optimization has completed. 16635 16636 For simple conditional and unconditional jumps, this field contains 16637 the 'code_label' to which this insn will (possibly conditionally) 16638 branch. In a more complex jump, 'JUMP_LABEL' records one of the 16639 labels that the insn refers to; other jump target labels are 16640 recorded as 'REG_LABEL_TARGET' notes. The exception is 'addr_vec' 16641 and 'addr_diff_vec', where 'JUMP_LABEL' is 'NULL_RTX' and the only 16642 way to find the labels is to scan the entire body of the insn. 16643 16644 Return insns count as jumps, but their 'JUMP_LABEL' is 'RETURN' or 16645 'SIMPLE_RETURN'. 16646 16647'call_insn' 16648 The expression code 'call_insn' is used for instructions that may 16649 do function calls. It is important to distinguish these 16650 instructions because they imply that certain registers and memory 16651 locations may be altered unpredictably. 16652 16653 'call_insn' insns have the same extra fields as 'insn' insns, 16654 accessed in the same way and in addition contain a field 16655 'CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 16656 'expr_list' expressions) containing 'use', 'clobber' and sometimes 16657 'set' expressions that denote hard registers and 'mem's used or 16658 clobbered by the called function. 16659 16660 A 'mem' generally points to a stack slot in which arguments passed 16661 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 16662 Register Arguments.) are stored. If the argument is caller-copied 16663 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 16664 will be mentioned in 'clobber' and 'use' entries; if it's 16665 callee-copied, only a 'use' will appear, and the 'mem' may point to 16666 addresses that are not stack slots. 16667 16668 Registers occurring inside a 'clobber' in this list augment 16669 registers specified in 'CALL_USED_REGISTERS' (*note Register 16670 Basics::). 16671 16672 If the list contains a 'set' involving two registers, it indicates 16673 that the function returns one of its arguments. Such a 'set' may 16674 look like a no-op if the same register holds the argument and the 16675 return value. 16676 16677'code_label' 16678 A 'code_label' insn represents a label that a jump insn can jump 16679 to. It contains two special fields of data in addition to the 16680 three standard ones. 'CODE_LABEL_NUMBER' is used to hold the 16681 "label number", a number that identifies this label uniquely among 16682 all the labels in the compilation (not just in the current 16683 function). Ultimately, the label is represented in the assembler 16684 output as an assembler label, usually of the form 'LN' where N is 16685 the label number. 16686 16687 When a 'code_label' appears in an RTL expression, it normally 16688 appears within a 'label_ref' which represents the address of the 16689 label, as a number. 16690 16691 Besides as a 'code_label', a label can also be represented as a 16692 'note' of type 'NOTE_INSN_DELETED_LABEL'. 16693 16694 The field 'LABEL_NUSES' is only defined once the jump optimization 16695 phase is completed. It contains the number of times this label is 16696 referenced in the current function. 16697 16698 The field 'LABEL_KIND' differentiates four different types of 16699 labels: 'LABEL_NORMAL', 'LABEL_STATIC_ENTRY', 'LABEL_GLOBAL_ENTRY', 16700 and 'LABEL_WEAK_ENTRY'. The only labels that do not have type 16701 'LABEL_NORMAL' are "alternate entry points" to the current 16702 function. These may be static (visible only in the containing 16703 translation unit), global (exposed to all translation units), or 16704 weak (global, but can be overridden by another symbol with the same 16705 name). 16706 16707 Much of the compiler treats all four kinds of label identically. 16708 Some of it needs to know whether or not a label is an alternate 16709 entry point; for this purpose, the macro 'LABEL_ALT_ENTRY_P' is 16710 provided. It is equivalent to testing whether 'LABEL_KIND (label) 16711 == LABEL_NORMAL'. The only place that cares about the distinction 16712 between static, global, and weak alternate entry points, besides 16713 the front-end code that creates them, is the function 16714 'output_alternate_entry_point', in 'final.c'. 16715 16716 To set the kind of a label, use the 'SET_LABEL_KIND' macro. 16717 16718'jump_table_data' 16719 A 'jump_table_data' insn is a placeholder for the jump-table data 16720 of a 'casesi' or 'tablejump' insn. They are placed after a 16721 'tablejump_p' insn. A 'jump_table_data' insn is not part o a basic 16722 blockm but it is associated with the basic block that ends with the 16723 'tablejump_p' insn. The 'PATTERN' of a 'jump_table_data' is always 16724 either an 'addr_vec' or an 'addr_diff_vec', and a 'jump_table_data' 16725 insn is always preceded by a 'code_label'. The 'tablejump_p' insn 16726 refers to that 'code_label' via its 'JUMP_LABEL'. 16727 16728'barrier' 16729 Barriers are placed in the instruction stream when control cannot 16730 flow past them. They are placed after unconditional jump 16731 instructions to indicate that the jumps are unconditional and after 16732 calls to 'volatile' functions, which do not return (e.g., 'exit'). 16733 They contain no information beyond the three standard fields. 16734 16735'note' 16736 'note' insns are used to represent additional debugging and 16737 declarative information. They contain two nonstandard fields, an 16738 integer which is accessed with the macro 'NOTE_LINE_NUMBER' and a 16739 string accessed with 'NOTE_SOURCE_FILE'. 16740 16741 If 'NOTE_LINE_NUMBER' is positive, the note represents the position 16742 of a source line and 'NOTE_SOURCE_FILE' is the source file name 16743 that the line came from. These notes control generation of line 16744 number data in the assembler output. 16745 16746 Otherwise, 'NOTE_LINE_NUMBER' is not really a line number but a 16747 code with one of the following values (and 'NOTE_SOURCE_FILE' must 16748 contain a null pointer): 16749 16750 'NOTE_INSN_DELETED' 16751 Such a note is completely ignorable. Some passes of the 16752 compiler delete insns by altering them into notes of this 16753 kind. 16754 16755 'NOTE_INSN_DELETED_LABEL' 16756 This marks what used to be a 'code_label', but was not used 16757 for other purposes than taking its address and was transformed 16758 to mark that no code jumps to it. 16759 16760 'NOTE_INSN_BLOCK_BEG' 16761 'NOTE_INSN_BLOCK_END' 16762 These types of notes indicate the position of the beginning 16763 and end of a level of scoping of variable names. They control 16764 the output of debugging information. 16765 16766 'NOTE_INSN_EH_REGION_BEG' 16767 'NOTE_INSN_EH_REGION_END' 16768 These types of notes indicate the position of the beginning 16769 and end of a level of scoping for exception handling. 16770 'NOTE_EH_HANDLER' identifies which region is associated with 16771 these notes. 16772 16773 'NOTE_INSN_FUNCTION_BEG' 16774 Appears at the start of the function body, after the function 16775 prologue. 16776 16777 'NOTE_INSN_VAR_LOCATION' 16778 This note is used to generate variable location debugging 16779 information. It indicates that the user variable in its 16780 'VAR_LOCATION' operand is at the location given in the RTL 16781 expression, or holds a value that can be computed by 16782 evaluating the RTL expression from that static point in the 16783 program up to the next such note for the same user variable. 16784 16785 These codes are printed symbolically when they appear in debugging 16786 dumps. 16787 16788'debug_insn' 16789 The expression code 'debug_insn' is used for pseudo-instructions 16790 that hold debugging information for variable tracking at 16791 assignments (see '-fvar-tracking-assignments' option). They are 16792 the RTL representation of 'GIMPLE_DEBUG' statements (*note 16793 GIMPLE_DEBUG::), with a 'VAR_LOCATION' operand that binds a user 16794 variable tree to an RTL representation of the 'value' in the 16795 corresponding statement. A 'DEBUG_EXPR' in it stands for the value 16796 bound to the corresponding 'DEBUG_EXPR_DECL'. 16797 16798 Throughout optimization passes, binding information is kept in 16799 pseudo-instruction form, so that, unlike notes, it gets the same 16800 treatment and adjustments that regular instructions would. It is 16801 the variable tracking pass that turns these pseudo-instructions 16802 into var location notes, analyzing control flow, value equivalences 16803 and changes to registers and memory referenced in value 16804 expressions, propagating the values of debug temporaries and 16805 determining expressions that can be used to compute the value of 16806 each user variable at as many points (ranges, actually) in the 16807 program as possible. 16808 16809 Unlike 'NOTE_INSN_VAR_LOCATION', the value expression in an 16810 'INSN_VAR_LOCATION' denotes a value at that specific point in the 16811 program, rather than an expression that can be evaluated at any 16812 later point before an overriding 'VAR_LOCATION' is encountered. 16813 E.g., if a user variable is bound to a 'REG' and then a subsequent 16814 insn modifies the 'REG', the note location would keep mapping the 16815 user variable to the register across the insn, whereas the insn 16816 location would keep the variable bound to the value, so that the 16817 variable tracking pass would emit another location note for the 16818 variable at the point in which the register is modified. 16819 16820 The machine mode of an insn is normally 'VOIDmode', but some phases use 16821the mode for various purposes. 16822 16823 The common subexpression elimination pass sets the mode of an insn to 16824'QImode' when it is the first insn in a block that has already been 16825processed. 16826 16827 The second Haifa scheduling pass, for targets that can multiple issue, 16828sets the mode of an insn to 'TImode' when it is believed that the 16829instruction begins an issue group. That is, when the instruction cannot 16830issue simultaneously with the previous. This may be relied on by later 16831passes, in particular machine-dependent reorg. 16832 16833 Here is a table of the extra fields of 'insn', 'jump_insn' and 16834'call_insn' insns: 16835 16836'PATTERN (I)' 16837 An expression for the side effect performed by this insn. This 16838 must be one of the following codes: 'set', 'call', 'use', 16839 'clobber', 'return', 'simple_return', 'asm_input', 'asm_output', 16840 'addr_vec', 'addr_diff_vec', 'trap_if', 'unspec', 16841 'unspec_volatile', 'parallel', 'cond_exec', or 'sequence'. If it 16842 is a 'parallel', each element of the 'parallel' must be one these 16843 codes, except that 'parallel' expressions cannot be nested and 16844 'addr_vec' and 'addr_diff_vec' are not permitted inside a 16845 'parallel' expression. 16846 16847'INSN_CODE (I)' 16848 An integer that says which pattern in the machine description 16849 matches this insn, or -1 if the matching has not yet been 16850 attempted. 16851 16852 Such matching is never attempted and this field remains -1 on an 16853 insn whose pattern consists of a single 'use', 'clobber', 16854 'asm_input', 'addr_vec' or 'addr_diff_vec' expression. 16855 16856 Matching is also never attempted on insns that result from an 'asm' 16857 statement. These contain at least one 'asm_operands' expression. 16858 The function 'asm_noperands' returns a non-negative value for such 16859 insns. 16860 16861 In the debugging output, this field is printed as a number followed 16862 by a symbolic representation that locates the pattern in the 'md' 16863 file as some small positive or negative offset from a named 16864 pattern. 16865 16866'LOG_LINKS (I)' 16867 A list (chain of 'insn_list' expressions) giving information about 16868 dependencies between instructions within a basic block. Neither a 16869 jump nor a label may come between the related insns. These are 16870 only used by the schedulers and by combine. This is a deprecated 16871 data structure. Def-use and use-def chains are now preferred. 16872 16873'REG_NOTES (I)' 16874 A list (chain of 'expr_list', 'insn_list' and 'int_list' 16875 expressions) giving miscellaneous information about the insn. It 16876 is often information pertaining to the registers used in this insn. 16877 16878 The 'LOG_LINKS' field of an insn is a chain of 'insn_list' expressions. 16879Each of these has two operands: the first is an insn, and the second is 16880another 'insn_list' expression (the next one in the chain). The last 16881'insn_list' in the chain has a null pointer as second operand. The 16882significant thing about the chain is which insns appear in it (as first 16883operands of 'insn_list' expressions). Their order is not significant. 16884 16885 This list is originally set up by the flow analysis pass; it is a null 16886pointer until then. Flow only adds links for those data dependencies 16887which can be used for instruction combination. For each insn, the flow 16888analysis pass adds a link to insns which store into registers values 16889that are used for the first time in this insn. 16890 16891 The 'REG_NOTES' field of an insn is a chain similar to the 'LOG_LINKS' 16892field but it includes 'expr_list' and 'int_list' expressions in addition 16893to 'insn_list' expressions. There are several kinds of register notes, 16894which are distinguished by the machine mode, which in a register note is 16895really understood as being an 'enum reg_note'. The first operand OP of 16896the note is data whose meaning depends on the kind of note. 16897 16898 The macro 'REG_NOTE_KIND (X)' returns the kind of register note. Its 16899counterpart, the macro 'PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 16900register note type of X to be NEWKIND. 16901 16902 Register notes are of three classes: They may say something about an 16903input to an insn, they may say something about an output of an insn, or 16904they may create a linkage between two insns. There are also a set of 16905values that are only used in 'LOG_LINKS'. 16906 16907 These register notes annotate inputs to an insn: 16908 16909'REG_DEAD' 16910 The value in OP dies in this insn; that is to say, altering the 16911 value immediately after this insn would not affect the future 16912 behavior of the program. 16913 16914 It does not follow that the register OP has no useful value after 16915 this insn since OP is not necessarily modified by this insn. 16916 Rather, no subsequent instruction uses the contents of OP. 16917 16918'REG_UNUSED' 16919 The register OP being set by this insn will not be used in a 16920 subsequent insn. This differs from a 'REG_DEAD' note, which 16921 indicates that the value in an input will not be used subsequently. 16922 These two notes are independent; both may be present for the same 16923 register. 16924 16925'REG_INC' 16926 The register OP is incremented (or decremented; at this level there 16927 is no distinction) by an embedded side effect inside this insn. 16928 This means it appears in a 'post_inc', 'pre_inc', 'post_dec' or 16929 'pre_dec' expression. 16930 16931'REG_NONNEG' 16932 The register OP is known to have a nonnegative value when this insn 16933 is reached. This is used so that decrement and branch until zero 16934 instructions, such as the m68k dbra, can be matched. 16935 16936 The 'REG_NONNEG' note is added to insns only if the machine 16937 description has a 'decrement_and_branch_until_zero' pattern. 16938 16939'REG_LABEL_OPERAND' 16940 This insn uses OP, a 'code_label' or a 'note' of type 16941 'NOTE_INSN_DELETED_LABEL', but is not a 'jump_insn', or it is a 16942 'jump_insn' that refers to the operand as an ordinary operand. The 16943 label may still eventually be a jump target, but if so in an 16944 indirect jump in a subsequent insn. The presence of this note 16945 allows jump optimization to be aware that OP is, in fact, being 16946 used, and flow optimization to build an accurate flow graph. 16947 16948'REG_LABEL_TARGET' 16949 This insn is a 'jump_insn' but not an 'addr_vec' or 16950 'addr_diff_vec'. It uses OP, a 'code_label' as a direct or 16951 indirect jump target. Its purpose is similar to that of 16952 'REG_LABEL_OPERAND'. This note is only present if the insn has 16953 multiple targets; the last label in the insn (in the highest 16954 numbered insn-field) goes into the 'JUMP_LABEL' field and does not 16955 have a 'REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns. 16956 16957'REG_CROSSING_JUMP' 16958 This insn is a branching instruction (either an unconditional jump 16959 or an indirect jump) which crosses between hot and cold sections, 16960 which could potentially be very far apart in the executable. The 16961 presence of this note indicates to other optimizations that this 16962 branching instruction should not be "collapsed" into a simpler 16963 branching construct. It is used when the optimization to partition 16964 basic blocks into hot and cold sections is turned on. 16965 16966'REG_SETJMP' 16967 Appears attached to each 'CALL_INSN' to 'setjmp' or a related 16968 function. 16969 16970 The following notes describe attributes of outputs of an insn: 16971 16972'REG_EQUIV' 16973'REG_EQUAL' 16974 This note is only valid on an insn that sets only one register and 16975 indicates that that register will be equal to OP at run time; the 16976 scope of this equivalence differs between the two types of notes. 16977 The value which the insn explicitly copies into the register may 16978 look different from OP, but they will be equal at run time. If the 16979 output of the single 'set' is a 'strict_low_part' expression, the 16980 note refers to the register that is contained in 'SUBREG_REG' of 16981 the 'subreg' expression. 16982 16983 For 'REG_EQUIV', the register is equivalent to OP throughout the 16984 entire function, and could validly be replaced in all its 16985 occurrences by OP. ("Validly" here refers to the data flow of the 16986 program; simple replacement may make some insns invalid.) For 16987 example, when a constant is loaded into a register that is never 16988 assigned any other value, this kind of note is used. 16989 16990 When a parameter is copied into a pseudo-register at entry to a 16991 function, a note of this kind records that the register is 16992 equivalent to the stack slot where the parameter was passed. 16993 Although in this case the register may be set by other insns, it is 16994 still valid to replace the register by the stack slot throughout 16995 the function. 16996 16997 A 'REG_EQUIV' note is also used on an instruction which copies a 16998 register parameter into a pseudo-register at entry to a function, 16999 if there is a stack slot where that parameter could be stored. 17000 Although other insns may set the pseudo-register, it is valid for 17001 the compiler to replace the pseudo-register by stack slot 17002 throughout the function, provided the compiler ensures that the 17003 stack slot is properly initialized by making the replacement in the 17004 initial copy instruction as well. This is used on machines for 17005 which the calling convention allocates stack space for register 17006 parameters. See 'REG_PARM_STACK_SPACE' in *note Stack Arguments::. 17007 17008 In the case of 'REG_EQUAL', the register that is set by this insn 17009 will be equal to OP at run time at the end of this insn but not 17010 necessarily elsewhere in the function. In this case, OP is 17011 typically an arithmetic expression. For example, when a sequence 17012 of insns such as a library call is used to perform an arithmetic 17013 operation, this kind of note is attached to the insn that produces 17014 or copies the final value. 17015 17016 These two notes are used in different ways by the compiler passes. 17017 'REG_EQUAL' is used by passes prior to register allocation (such as 17018 common subexpression elimination and loop optimization) to tell 17019 them how to think of that value. 'REG_EQUIV' notes are used by 17020 register allocation to indicate that there is an available 17021 substitute expression (either a constant or a 'mem' expression for 17022 the location of a parameter on the stack) that may be used in place 17023 of a register if insufficient registers are available. 17024 17025 Except for stack homes for parameters, which are indicated by a 17026 'REG_EQUIV' note and are not useful to the early optimization 17027 passes and pseudo registers that are equivalent to a memory 17028 location throughout their entire life, which is not detected until 17029 later in the compilation, all equivalences are initially indicated 17030 by an attached 'REG_EQUAL' note. In the early stages of register 17031 allocation, a 'REG_EQUAL' note is changed into a 'REG_EQUIV' note 17032 if OP is a constant and the insn represents the only set of its 17033 destination register. 17034 17035 Thus, compiler passes prior to register allocation need only check 17036 for 'REG_EQUAL' notes and passes subsequent to register allocation 17037 need only check for 'REG_EQUIV' notes. 17038 17039 These notes describe linkages between insns. They occur in pairs: one 17040insn has one of a pair of notes that points to a second insn, which has 17041the inverse note pointing back to the first insn. 17042 17043'REG_CC_SETTER' 17044'REG_CC_USER' 17045 On machines that use 'cc0', the insns which set and use 'cc0' set 17046 and use 'cc0' are adjacent. However, when branch delay slot 17047 filling is done, this may no longer be true. In this case a 17048 'REG_CC_USER' note will be placed on the insn setting 'cc0' to 17049 point to the insn using 'cc0' and a 'REG_CC_SETTER' note will be 17050 placed on the insn using 'cc0' to point to the insn setting 'cc0'. 17051 17052 These values are only used in the 'LOG_LINKS' field, and indicate the 17053type of dependency that each link represents. Links which indicate a 17054data dependence (a read after write dependence) do not use any code, 17055they simply have mode 'VOIDmode', and are printed without any 17056descriptive text. 17057 17058'REG_DEP_TRUE' 17059 This indicates a true dependence (a read after write dependence). 17060 17061'REG_DEP_OUTPUT' 17062 This indicates an output dependence (a write after write 17063 dependence). 17064 17065'REG_DEP_ANTI' 17066 This indicates an anti dependence (a write after read dependence). 17067 17068 These notes describe information gathered from gcov profile data. They 17069are stored in the 'REG_NOTES' field of an insn. 17070 17071'REG_BR_PROB' 17072 This is used to specify the ratio of branches to non-branches of a 17073 branch insn according to the profile data. The note is represented 17074 as an 'int_list' expression whose integer value is between 0 and 17075 REG_BR_PROB_BASE. Larger values indicate a higher probability that 17076 the branch will be taken. 17077 17078'REG_BR_PRED' 17079 These notes are found in JUMP insns after delayed branch scheduling 17080 has taken place. They indicate both the direction and the 17081 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 17082 values. 17083 17084'REG_FRAME_RELATED_EXPR' 17085 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 17086 expression is used in place of the actual insn pattern. This is 17087 done in cases where the pattern is either complex or misleading. 17088 17089 For convenience, the machine mode in an 'insn_list' or 'expr_list' is 17090printed using these symbolic codes in debugging dumps. 17091 17092 The only difference between the expression codes 'insn_list' and 17093'expr_list' is that the first operand of an 'insn_list' is assumed to be 17094an insn and is printed in debugging dumps as the insn's unique id; the 17095first operand of an 'expr_list' is printed in the ordinary way as an 17096expression. 17097 17098 17099File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 17100 1710113.20 RTL Representation of Function-Call Insns 17102=============================================== 17103 17104Insns that call subroutines have the RTL expression code 'call_insn'. 17105These insns must satisfy special rules, and their bodies must use a 17106special RTL expression code, 'call'. 17107 17108 A 'call' expression has two operands, as follows: 17109 17110 (call (mem:FM ADDR) NBYTES) 17111 17112Here NBYTES is an operand that represents the number of bytes of 17113argument data being passed to the subroutine, FM is a machine mode 17114(which must equal as the definition of the 'FUNCTION_MODE' macro in the 17115machine description) and ADDR represents the address of the subroutine. 17116 17117 For a subroutine that returns no value, the 'call' expression as shown 17118above is the entire body of the insn, except that the insn might also 17119contain 'use' or 'clobber' expressions. 17120 17121 For a subroutine that returns a value whose mode is not 'BLKmode', the 17122value is returned in a hard register. If this register's number is R, 17123then the body of the call insn looks like this: 17124 17125 (set (reg:M R) 17126 (call (mem:FM ADDR) NBYTES)) 17127 17128This RTL expression makes it clear (to the optimizer passes) that the 17129appropriate register receives a useful value in this insn. 17130 17131 When a subroutine returns a 'BLKmode' value, it is handled by passing 17132to the subroutine the address of a place to store the value. So the 17133call insn itself does not "return" any value, and it has the same RTL 17134form as a call that returns nothing. 17135 17136 On some machines, the call instruction itself clobbers some register, 17137for example to contain the return address. 'call_insn' insns on these 17138machines should have a body which is a 'parallel' that contains both the 17139'call' expression and 'clobber' expressions that indicate which 17140registers are destroyed. Similarly, if the call instruction requires 17141some register other than the stack pointer that is not explicitly 17142mentioned in its RTL, a 'use' subexpression should mention that 17143register. 17144 17145 Functions that are called are assumed to modify all registers listed in 17146the configuration macro 'CALL_USED_REGISTERS' (*note Register Basics::) 17147and, with the exception of 'const' functions and library calls, to 17148modify all of memory. 17149 17150 Insns containing just 'use' expressions directly precede the 17151'call_insn' insn to indicate which registers contain inputs to the 17152function. Similarly, if registers other than those in 17153'CALL_USED_REGISTERS' are clobbered by the called function, insns 17154containing a single 'clobber' follow immediately after the call to 17155indicate which registers. 17156 17157 17158File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 17159 1716013.21 Structure Sharing Assumptions 17161=================================== 17162 17163The compiler assumes that certain kinds of RTL expressions are unique; 17164there do not exist two distinct objects representing the same value. In 17165other cases, it makes an opposite assumption: that no RTL expression 17166object of a certain kind appears in more than one place in the 17167containing structure. 17168 17169 These assumptions refer to a single function; except for the RTL 17170objects that describe global variables and external functions, and a few 17171standard objects such as small integer constants, no RTL objects are 17172common to two functions. 17173 17174 * Each pseudo-register has only a single 'reg' object to represent 17175 it, and therefore only a single machine mode. 17176 17177 * For any symbolic label, there is only one 'symbol_ref' object 17178 referring to it. 17179 17180 * All 'const_int' expressions with equal values are shared. 17181 17182 * There is only one 'pc' expression. 17183 17184 * There is only one 'cc0' expression. 17185 17186 * There is only one 'const_double' expression with value 0 for each 17187 floating point mode. Likewise for values 1 and 2. 17188 17189 * There is only one 'const_vector' expression with value 0 for each 17190 vector mode, be it an integer or a double constant vector. 17191 17192 * No 'label_ref' or 'scratch' appears in more than one place in the 17193 RTL structure; in other words, it is safe to do a tree-walk of all 17194 the insns in the function and assume that each time a 'label_ref' 17195 or 'scratch' is seen it is distinct from all others that are seen. 17196 17197 * Only one 'mem' object is normally created for each static variable 17198 or stack slot, so these objects are frequently shared in all the 17199 places they appear. However, separate but equal objects for these 17200 variables are occasionally made. 17201 17202 * When a single 'asm' statement has multiple output operands, a 17203 distinct 'asm_operands' expression is made for each output operand. 17204 However, these all share the vector which contains the sequence of 17205 input operands. This sharing is used later on to test whether two 17206 'asm_operands' expressions come from the same statement, so all 17207 optimizations must carefully preserve the sharing if they copy the 17208 vector at all. 17209 17210 * No RTL object appears in more than one place in the RTL structure 17211 except as described above. Many passes of the compiler rely on 17212 this by assuming that they can modify RTL objects in place without 17213 unwanted side-effects on other insns. 17214 17215 * During initial RTL generation, shared structure is freely 17216 introduced. After all the RTL for a function has been generated, 17217 all shared structure is copied by 'unshare_all_rtl' in 17218 'emit-rtl.c', after which the above rules are guaranteed to be 17219 followed. 17220 17221 * During the combiner pass, shared structure within an insn can exist 17222 temporarily. However, the shared structure is copied before the 17223 combiner is finished with the insn. This is done by calling 17224 'copy_rtx_if_shared', which is a subroutine of 'unshare_all_rtl'. 17225 17226 17227File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 17228 1722913.22 Reading RTL 17230================= 17231 17232To read an RTL object from a file, call 'read_rtx'. It takes one 17233argument, a stdio stream, and returns a single RTL object. This routine 17234is defined in 'read-rtl.c'. It is not available in the compiler itself, 17235only the various programs that generate the compiler back end from the 17236machine description. 17237 17238 People frequently have the idea of using RTL stored as text in a file 17239as an interface between a language front end and the bulk of GCC. This 17240idea is not feasible. 17241 17242 GCC was designed to use RTL internally only. Correct RTL for a given 17243program is very dependent on the particular target machine. And the RTL 17244does not contain all the information about the program. 17245 17246 The proper way to interface GCC to a new language front end is with the 17247"tree" data structure, described in the files 'tree.h' and 'tree.def'. 17248The documentation for this structure (*note GENERIC::) is incomplete. 17249 17250 17251File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top 17252 1725314 Control Flow Graph 17254********************* 17255 17256A control flow graph (CFG) is a data structure built on top of the 17257intermediate code representation (the RTL or 'GIMPLE' instruction 17258stream) abstracting the control flow behavior of a function that is 17259being compiled. The CFG is a directed graph where the vertices 17260represent basic blocks and edges represent possible transfer of control 17261flow from one basic block to another. The data structures used to 17262represent the control flow graph are defined in 'basic-block.h'. 17263 17264 In GCC, the representation of control flow is maintained throughout the 17265compilation process, from constructing the CFG early in 'pass_build_cfg' 17266to 'pass_free_cfg' (see 'passes.def'). The CFG takes various different 17267modes and may undergo extensive manipulations, but the graph is always 17268valid between its construction and its release. This way, transfer of 17269information such as data flow, a measured profile, or the loop tree, can 17270be propagated through the passes pipeline, and even from 'GIMPLE' to 17271'RTL'. 17272 17273 Often the CFG may be better viewed as integral part of instruction 17274chain, than structure built on the top of it. Updating the compiler's 17275intermediate representation for instructions can not be easily done 17276without proper maintenance of the CFG simultaneously. 17277 17278* Menu: 17279 17280* Basic Blocks:: The definition and representation of basic blocks. 17281* Edges:: Types of edges and their representation. 17282* Profile information:: Representation of frequencies and probabilities. 17283* Maintaining the CFG:: Keeping the control flow graph and up to date. 17284* Liveness information:: Using and maintaining liveness information. 17285 17286 17287File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 17288 1728914.1 Basic Blocks 17290================= 17291 17292A basic block is a straight-line sequence of code with only one entry 17293point and only one exit. In GCC, basic blocks are represented using the 17294'basic_block' data type. 17295 17296 Special basic blocks represent possible entry and exit points of a 17297function. These blocks are called 'ENTRY_BLOCK_PTR' and 17298'EXIT_BLOCK_PTR'. These blocks do not contain any code. 17299 17300 The 'BASIC_BLOCK' array contains all basic blocks in an unspecified 17301order. Each 'basic_block' structure has a field that holds a unique 17302integer identifier 'index' that is the index of the block in the 17303'BASIC_BLOCK' array. The total number of basic blocks in the function 17304is 'n_basic_blocks'. Both the basic block indices and the total number 17305of basic blocks may vary during the compilation process, as passes 17306reorder, create, duplicate, and destroy basic blocks. The index for any 17307block should never be greater than 'last_basic_block'. The indices 0 17308and 1 are special codes reserved for 'ENTRY_BLOCK' and 'EXIT_BLOCK', the 17309indices of 'ENTRY_BLOCK_PTR' and 'EXIT_BLOCK_PTR'. 17310 17311 Two pointer members of the 'basic_block' structure are the pointers 17312'next_bb' and 'prev_bb'. These are used to keep doubly linked chain of 17313basic blocks in the same order as the underlying instruction stream. 17314The chain of basic blocks is updated transparently by the provided API 17315for manipulating the CFG. The macro 'FOR_EACH_BB' can be used to visit 17316all the basic blocks in lexicographical order, except 'ENTRY_BLOCK' and 17317'EXIT_BLOCK'. The macro 'FOR_ALL_BB' also visits all basic blocks in 17318lexicographical order, including 'ENTRY_BLOCK' and 'EXIT_BLOCK'. 17319 17320 The functions 'post_order_compute' and 'inverted_post_order_compute' 17321can be used to compute topological orders of the CFG. The orders are 17322stored as vectors of basic block indices. The 'BASIC_BLOCK' array can 17323be used to iterate each basic block by index. Dominator traversals are 17324also possible using 'walk_dominator_tree'. Given two basic blocks A and 17325B, block A dominates block B if A is _always_ executed before B. 17326 17327 Each 'basic_block' also contains pointers to the first instruction (the 17328"head") and the last instruction (the "tail") or "end" of the 17329instruction stream contained in a basic block. In fact, since the 17330'basic_block' data type is used to represent blocks in both major 17331intermediate representations of GCC ('GIMPLE' and RTL), there are 17332pointers to the head and end of a basic block for both representations, 17333stored in intermediate representation specific data in the 'il' field of 17334'struct basic_block_def'. 17335 17336 For RTL, these pointers are 'BB_HEAD' and 'BB_END'. 17337 17338 In the RTL representation of a function, the instruction stream 17339contains not only the "real" instructions, but also "notes" or "insn 17340notes" (to distinguish them from "reg notes"). Any function that moves 17341or duplicates the basic blocks needs to take care of updating of these 17342notes. Many of these notes expect that the instruction stream consists 17343of linear regions, so updating can sometimes be tedious. All types of 17344insn notes are defined in 'insn-notes.def'. 17345 17346 In the RTL function representation, the instructions contained in a 17347basic block always follow a 'NOTE_INSN_BASIC_BLOCK', but zero or more 17348'CODE_LABEL' nodes can precede the block note. A basic block ends with 17349a control flow instruction or with the last instruction before the next 17350'CODE_LABEL' or 'NOTE_INSN_BASIC_BLOCK'. By definition, a 'CODE_LABEL' 17351cannot appear in the middle of the instruction stream of a basic block. 17352 17353 In addition to notes, the jump table vectors are also represented as 17354"pseudo-instructions" inside the insn stream. These vectors never 17355appear in the basic block and should always be placed just after the 17356table jump instructions referencing them. After removing the table-jump 17357it is often difficult to eliminate the code computing the address and 17358referencing the vector, so cleaning up these vectors is postponed until 17359after liveness analysis. Thus the jump table vectors may appear in the 17360insn stream unreferenced and without any purpose. Before any edge is 17361made "fall-thru", the existence of such construct in the way needs to be 17362checked by calling 'can_fallthru' function. 17363 17364 For the 'GIMPLE' representation, the PHI nodes and statements contained 17365in a basic block are in a 'gimple_seq' pointed to by the basic block 17366intermediate language specific pointers. Abstract containers and 17367iterators are used to access the PHI nodes and statements in a basic 17368blocks. These iterators are called "GIMPLE statement iterators" (GSIs). 17369Grep for '^gsi' in the various 'gimple-*' and 'tree-*' files. There is 17370a 'gimple_stmt_iterator' type for iterating over all kinds of statement, 17371and a 'gphi_iterator' subclass for iterating over PHI nodes. The 17372following snippet will pretty-print all PHI nodes the statements of the 17373current function in the GIMPLE representation. 17374 17375 basic_block bb; 17376 17377 FOR_EACH_BB (bb) 17378 { 17379 gphi_iterator pi; 17380 gimple_stmt_iterator si; 17381 17382 for (pi = gsi_start_phis (bb); !gsi_end_p (pi); gsi_next (&pi)) 17383 { 17384 gphi *phi = pi.phi (); 17385 print_gimple_stmt (dump_file, phi, 0, TDF_SLIM); 17386 } 17387 for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si)) 17388 { 17389 gimple stmt = gsi_stmt (si); 17390 print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM); 17391 } 17392 } 17393 17394 17395File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 17396 1739714.2 Edges 17398========== 17399 17400Edges represent possible control flow transfers from the end of some 17401basic block A to the head of another basic block B. We say that A is a 17402predecessor of B, and B is a successor of A. Edges are represented in 17403GCC with the 'edge' data type. Each 'edge' acts as a link between two 17404basic blocks: The 'src' member of an edge points to the predecessor 17405basic block of the 'dest' basic block. The members 'preds' and 'succs' 17406of the 'basic_block' data type point to type-safe vectors of edges to 17407the predecessors and successors of the block. 17408 17409 When walking the edges in an edge vector, "edge iterators" should be 17410used. Edge iterators are constructed using the 'edge_iterator' data 17411structure and several methods are available to operate on them: 17412 17413'ei_start' 17414 This function initializes an 'edge_iterator' that points to the 17415 first edge in a vector of edges. 17416 17417'ei_last' 17418 This function initializes an 'edge_iterator' that points to the 17419 last edge in a vector of edges. 17420 17421'ei_end_p' 17422 This predicate is 'true' if an 'edge_iterator' represents the last 17423 edge in an edge vector. 17424 17425'ei_one_before_end_p' 17426 This predicate is 'true' if an 'edge_iterator' represents the 17427 second last edge in an edge vector. 17428 17429'ei_next' 17430 This function takes a pointer to an 'edge_iterator' and makes it 17431 point to the next edge in the sequence. 17432 17433'ei_prev' 17434 This function takes a pointer to an 'edge_iterator' and makes it 17435 point to the previous edge in the sequence. 17436 17437'ei_edge' 17438 This function returns the 'edge' currently pointed to by an 17439 'edge_iterator'. 17440 17441'ei_safe_safe' 17442 This function returns the 'edge' currently pointed to by an 17443 'edge_iterator', but returns 'NULL' if the iterator is pointing at 17444 the end of the sequence. This function has been provided for 17445 existing code makes the assumption that a 'NULL' edge indicates the 17446 end of the sequence. 17447 17448 The convenience macro 'FOR_EACH_EDGE' can be used to visit all of the 17449edges in a sequence of predecessor or successor edges. It must not be 17450used when an element might be removed during the traversal, otherwise 17451elements will be missed. Here is an example of how to use the macro: 17452 17453 edge e; 17454 edge_iterator ei; 17455 17456 FOR_EACH_EDGE (e, ei, bb->succs) 17457 { 17458 if (e->flags & EDGE_FALLTHRU) 17459 break; 17460 } 17461 17462 There are various reasons why control flow may transfer from one block 17463to another. One possibility is that some instruction, for example a 17464'CODE_LABEL', in a linearized instruction stream just always starts a 17465new basic block. In this case a "fall-thru" edge links the basic block 17466to the first following basic block. But there are several other reasons 17467why edges may be created. The 'flags' field of the 'edge' data type is 17468used to store information about the type of edge we are dealing with. 17469Each edge is of one of the following types: 17470 17471_jump_ 17472 No type flags are set for edges corresponding to jump instructions. 17473 These edges are used for unconditional or conditional jumps and in 17474 RTL also for table jumps. They are the easiest to manipulate as 17475 they may be freely redirected when the flow graph is not in SSA 17476 form. 17477 17478_fall-thru_ 17479 Fall-thru edges are present in case where the basic block may 17480 continue execution to the following one without branching. These 17481 edges have the 'EDGE_FALLTHRU' flag set. Unlike other types of 17482 edges, these edges must come into the basic block immediately 17483 following in the instruction stream. The function 17484 'force_nonfallthru' is available to insert an unconditional jump in 17485 the case that redirection is needed. Note that this may require 17486 creation of a new basic block. 17487 17488_exception handling_ 17489 Exception handling edges represent possible control transfers from 17490 a trapping instruction to an exception handler. The definition of 17491 "trapping" varies. In C++, only function calls can throw, but for 17492 Java and Ada, exceptions like division by zero or segmentation 17493 fault are defined and thus each instruction possibly throwing this 17494 kind of exception needs to be handled as control flow instruction. 17495 Exception edges have the 'EDGE_ABNORMAL' and 'EDGE_EH' flags set. 17496 17497 When updating the instruction stream it is easy to change possibly 17498 trapping instruction to non-trapping, by simply removing the 17499 exception edge. The opposite conversion is difficult, but should 17500 not happen anyway. The edges can be eliminated via 17501 'purge_dead_edges' call. 17502 17503 In the RTL representation, the destination of an exception edge is 17504 specified by 'REG_EH_REGION' note attached to the insn. In case of 17505 a trapping call the 'EDGE_ABNORMAL_CALL' flag is set too. In the 17506 'GIMPLE' representation, this extra flag is not set. 17507 17508 In the RTL representation, the predicate 'may_trap_p' may be used 17509 to check whether instruction still may trap or not. For the tree 17510 representation, the 'tree_could_trap_p' predicate is available, but 17511 this predicate only checks for possible memory traps, as in 17512 dereferencing an invalid pointer location. 17513 17514_sibling calls_ 17515 Sibling calls or tail calls terminate the function in a 17516 non-standard way and thus an edge to the exit must be present. 17517 'EDGE_SIBCALL' and 'EDGE_ABNORMAL' are set in such case. These 17518 edges only exist in the RTL representation. 17519 17520_computed jumps_ 17521 Computed jumps contain edges to all labels in the function 17522 referenced from the code. All those edges have 'EDGE_ABNORMAL' 17523 flag set. The edges used to represent computed jumps often cause 17524 compile time performance problems, since functions consisting of 17525 many taken labels and many computed jumps may have _very_ dense 17526 flow graphs, so these edges need to be handled with special care. 17527 During the earlier stages of the compilation process, GCC tries to 17528 avoid such dense flow graphs by factoring computed jumps. For 17529 example, given the following series of jumps, 17530 17531 goto *x; 17532 [ ... ] 17533 17534 goto *x; 17535 [ ... ] 17536 17537 goto *x; 17538 [ ... ] 17539 17540 factoring the computed jumps results in the following code sequence 17541 which has a much simpler flow graph: 17542 17543 goto y; 17544 [ ... ] 17545 17546 goto y; 17547 [ ... ] 17548 17549 goto y; 17550 [ ... ] 17551 17552 y: 17553 goto *x; 17554 17555 However, the classic problem with this transformation is that it 17556 has a runtime cost in there resulting code: An extra jump. 17557 Therefore, the computed jumps are un-factored in the later passes 17558 of the compiler (in the pass called 17559 'pass_duplicate_computed_gotos'). Be aware of that when you work 17560 on passes in that area. There have been numerous examples already 17561 where the compile time for code with unfactored computed jumps 17562 caused some serious headaches. 17563 17564_nonlocal goto handlers_ 17565 GCC allows nested functions to return into caller using a 'goto' to 17566 a label passed to as an argument to the callee. The labels passed 17567 to nested functions contain special code to cleanup after function 17568 call. Such sections of code are referred to as "nonlocal goto 17569 receivers". If a function contains such nonlocal goto receivers, 17570 an edge from the call to the label is created with the 17571 'EDGE_ABNORMAL' and 'EDGE_ABNORMAL_CALL' flags set. 17572 17573_function entry points_ 17574 By definition, execution of function starts at basic block 0, so 17575 there is always an edge from the 'ENTRY_BLOCK_PTR' to basic block 17576 0. There is no 'GIMPLE' representation for alternate entry points 17577 at this moment. In RTL, alternate entry points are specified by 17578 'CODE_LABEL' with 'LABEL_ALTERNATE_NAME' defined. This feature is 17579 currently used for multiple entry point prologues and is limited to 17580 post-reload passes only. This can be used by back-ends to emit 17581 alternate prologues for functions called from different contexts. 17582 In future full support for multiple entry functions defined by 17583 Fortran 90 needs to be implemented. 17584 17585_function exits_ 17586 In the pre-reload representation a function terminates after the 17587 last instruction in the insn chain and no explicit return 17588 instructions are used. This corresponds to the fall-thru edge into 17589 exit block. After reload, optimal RTL epilogues are used that use 17590 explicit (conditional) return instructions that are represented by 17591 edges with no flags set. 17592 17593 17594File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 17595 1759614.3 Profile information 17597======================== 17598 17599In many cases a compiler must make a choice whether to trade speed in 17600one part of code for speed in another, or to trade code size for code 17601speed. In such cases it is useful to know information about how often 17602some given block will be executed. That is the purpose for maintaining 17603profile within the flow graph. GCC can handle profile information 17604obtained through "profile feedback", but it can also estimate branch 17605probabilities based on statics and heuristics. 17606 17607 The feedback based profile is produced by compiling the program with 17608instrumentation, executing it on a train run and reading the numbers of 17609executions of basic blocks and edges back to the compiler while 17610re-compiling the program to produce the final executable. This method 17611provides very accurate information about where a program spends most of 17612its time on the train run. Whether it matches the average run of course 17613depends on the choice of train data set, but several studies have shown 17614that the behavior of a program usually changes just marginally over 17615different data sets. 17616 17617 When profile feedback is not available, the compiler may be asked to 17618attempt to predict the behavior of each branch in the program using a 17619set of heuristics (see 'predict.def' for details) and compute estimated 17620frequencies of each basic block by propagating the probabilities over 17621the graph. 17622 17623 Each 'basic_block' contains two integer fields to represent profile 17624information: 'frequency' and 'count'. The 'frequency' is an estimation 17625how often is basic block executed within a function. It is represented 17626as an integer scaled in the range from 0 to 'BB_FREQ_BASE'. The most 17627frequently executed basic block in function is initially set to 17628'BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 17629During optimization, the frequency of the most frequent basic block can 17630both decrease (for instance by loop unrolling) or grow (for instance by 17631cross-jumping optimization), so scaling sometimes has to be performed 17632multiple times. 17633 17634 The 'count' contains hard-counted numbers of execution measured during 17635training runs and is nonzero only when profile feedback is available. 17636This value is represented as the host's widest integer (typically a 64 17637bit integer) of the special type 'gcov_type'. 17638 17639 Most optimization passes can use only the frequency information of a 17640basic block, but a few passes may want to know hard execution counts. 17641The frequencies should always match the counts after scaling, however 17642during updating of the profile information numerical error may 17643accumulate into quite large errors. 17644 17645 Each edge also contains a branch probability field: an integer in the 17646range from 0 to 'REG_BR_PROB_BASE'. It represents probability of 17647passing control from the end of the 'src' basic block to the 'dest' 17648basic block, i.e. the probability that control will flow along this 17649edge. The 'EDGE_FREQUENCY' macro is available to compute how frequently 17650a given edge is taken. There is a 'count' field for each edge as well, 17651representing same information as for a basic block. 17652 17653 The basic block frequencies are not represented in the instruction 17654stream, but in the RTL representation the edge frequencies are 17655represented for conditional jumps (via the 'REG_BR_PROB' macro) since 17656they are used when instructions are output to the assembly file and the 17657flow graph is no longer maintained. 17658 17659 The probability that control flow arrives via a given edge to its 17660destination basic block is called "reverse probability" and is not 17661directly represented, but it may be easily computed from frequencies of 17662basic blocks. 17663 17664 Updating profile information is a delicate task that can unfortunately 17665not be easily integrated with the CFG manipulation API. Many of the 17666functions and hooks to modify the CFG, such as 17667'redirect_edge_and_branch', do not have enough information to easily 17668update the profile, so updating it is in the majority of cases left up 17669to the caller. It is difficult to uncover bugs in the profile updating 17670code, because they manifest themselves only by producing worse code, and 17671checking profile consistency is not possible because of numeric error 17672accumulation. Hence special attention needs to be given to this issue 17673in each pass that modifies the CFG. 17674 17675 It is important to point out that 'REG_BR_PROB_BASE' and 'BB_FREQ_BASE' 17676are both set low enough to be possible to compute second power of any 17677frequency or probability in the flow graph, it is not possible to even 17678square the 'count' field, as modern CPUs are fast enough to execute 17679$2^32$ operations quickly. 17680 17681 17682File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 17683 1768414.4 Maintaining the CFG 17685======================== 17686 17687An important task of each compiler pass is to keep both the control flow 17688graph and all profile information up-to-date. Reconstruction of the 17689control flow graph after each pass is not an option, since it may be 17690very expensive and lost profile information cannot be reconstructed at 17691all. 17692 17693 GCC has two major intermediate representations, and both use the 17694'basic_block' and 'edge' data types to represent control flow. Both 17695representations share as much of the CFG maintenance code as possible. 17696For each representation, a set of "hooks" is defined so that each 17697representation can provide its own implementation of CFG manipulation 17698routines when necessary. These hooks are defined in 'cfghooks.h'. 17699There are hooks for almost all common CFG manipulations, including block 17700splitting and merging, edge redirection and creating and deleting basic 17701blocks. These hooks should provide everything you need to maintain and 17702manipulate the CFG in both the RTL and 'GIMPLE' representation. 17703 17704 At the moment, the basic block boundaries are maintained transparently 17705when modifying instructions, so there rarely is a need to move them 17706manually (such as in case someone wants to output instruction outside 17707basic block explicitly). 17708 17709 In the RTL representation, each instruction has a 'BLOCK_FOR_INSN' 17710value that represents pointer to the basic block that contains the 17711instruction. In the 'GIMPLE' representation, the function 'gimple_bb' 17712returns a pointer to the basic block containing the queried statement. 17713 17714 When changes need to be applied to a function in its 'GIMPLE' 17715representation, "GIMPLE statement iterators" should be used. These 17716iterators provide an integrated abstraction of the flow graph and the 17717instruction stream. Block statement iterators are constructed using the 17718'gimple_stmt_iterator' data structure and several modifiers are 17719available, including the following: 17720 17721'gsi_start' 17722 This function initializes a 'gimple_stmt_iterator' that points to 17723 the first non-empty statement in a basic block. 17724 17725'gsi_last' 17726 This function initializes a 'gimple_stmt_iterator' that points to 17727 the last statement in a basic block. 17728 17729'gsi_end_p' 17730 This predicate is 'true' if a 'gimple_stmt_iterator' represents the 17731 end of a basic block. 17732 17733'gsi_next' 17734 This function takes a 'gimple_stmt_iterator' and makes it point to 17735 its successor. 17736 17737'gsi_prev' 17738 This function takes a 'gimple_stmt_iterator' and makes it point to 17739 its predecessor. 17740 17741'gsi_insert_after' 17742 This function inserts a statement after the 'gimple_stmt_iterator' 17743 passed in. The final parameter determines whether the statement 17744 iterator is updated to point to the newly inserted statement, or 17745 left pointing to the original statement. 17746 17747'gsi_insert_before' 17748 This function inserts a statement before the 'gimple_stmt_iterator' 17749 passed in. The final parameter determines whether the statement 17750 iterator is updated to point to the newly inserted statement, or 17751 left pointing to the original statement. 17752 17753'gsi_remove' 17754 This function removes the 'gimple_stmt_iterator' passed in and 17755 rechains the remaining statements in a basic block, if any. 17756 17757 In the RTL representation, the macros 'BB_HEAD' and 'BB_END' may be 17758used to get the head and end 'rtx' of a basic block. No abstract 17759iterators are defined for traversing the insn chain, but you can just 17760use 'NEXT_INSN' and 'PREV_INSN' instead. *Note Insns::. 17761 17762 Usually a code manipulating pass simplifies the instruction stream and 17763the flow of control, possibly eliminating some edges. This may for 17764example happen when a conditional jump is replaced with an unconditional 17765jump, but also when simplifying possibly trapping instruction to 17766non-trapping while compiling Java. Updating of edges is not transparent 17767and each optimization pass is required to do so manually. However only 17768few cases occur in practice. The pass may call 'purge_dead_edges' on a 17769given basic block to remove superfluous edges, if any. 17770 17771 Another common scenario is redirection of branch instructions, but this 17772is best modeled as redirection of edges in the control flow graph and 17773thus use of 'redirect_edge_and_branch' is preferred over more low level 17774functions, such as 'redirect_jump' that operate on RTL chain only. The 17775CFG hooks defined in 'cfghooks.h' should provide the complete API 17776required for manipulating and maintaining the CFG. 17777 17778 It is also possible that a pass has to insert control flow instruction 17779into the middle of a basic block, thus creating an entry point in the 17780middle of the basic block, which is impossible by definition: The block 17781must be split to make sure it only has one entry point, i.e. the head of 17782the basic block. The CFG hook 'split_block' may be used when an 17783instruction in the middle of a basic block has to become the target of a 17784jump or branch instruction. 17785 17786 For a global optimizer, a common operation is to split edges in the 17787flow graph and insert instructions on them. In the RTL representation, 17788this can be easily done using the 'insert_insn_on_edge' function that 17789emits an instruction "on the edge", caching it for a later 17790'commit_edge_insertions' call that will take care of moving the inserted 17791instructions off the edge into the instruction stream contained in a 17792basic block. This includes the creation of new basic blocks where 17793needed. In the 'GIMPLE' representation, the equivalent functions are 17794'gsi_insert_on_edge' which inserts a block statement iterator on an 17795edge, and 'gsi_commit_edge_inserts' which flushes the instruction to 17796actual instruction stream. 17797 17798 While debugging the optimization pass, the 'verify_flow_info' function 17799may be useful to find bugs in the control flow graph updating code. 17800 17801 17802File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 17803 1780414.5 Liveness information 17805========================= 17806 17807Liveness information is useful to determine whether some register is 17808"live" at given point of program, i.e. that it contains a value that may 17809be used at a later point in the program. This information is used, for 17810instance, during register allocation, as the pseudo registers only need 17811to be assigned to a unique hard register or to a stack slot if they are 17812live. The hard registers and stack slots may be freely reused for other 17813values when a register is dead. 17814 17815 Liveness information is available in the back end starting with 17816'pass_df_initialize' and ending with 'pass_df_finish'. Three flavors of 17817live analysis are available: With 'LR', it is possible to determine at 17818any point 'P' in the function if the register may be used on some path 17819from 'P' to the end of the function. With 'UR', it is possible to 17820determine if there is a path from the beginning of the function to 'P' 17821that defines the variable. 'LIVE' is the intersection of the 'LR' and 17822'UR' and a variable is live at 'P' if there is both an assignment that 17823reaches it from the beginning of the function and a use that can be 17824reached on some path from 'P' to the end of the function. 17825 17826 In general 'LIVE' is the most useful of the three. The macros 17827'DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The 17828macros take a basic block number and return a bitmap that is indexed by 17829the register number. This information is only guaranteed to be up to 17830date after calls are made to 'df_analyze'. See the file 'df-core.c' for 17831details on using the dataflow. 17832 17833 The liveness information is stored partly in the RTL instruction stream 17834and partly in the flow graph. Local information is stored in the 17835instruction stream: Each instruction may contain 'REG_DEAD' notes 17836representing that the value of a given register is no longer needed, or 17837'REG_UNUSED' notes representing that the value computed by the 17838instruction is never used. The second is useful for instructions 17839computing multiple values at once. 17840 17841 17842File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top 17843 1784415 Analysis and Representation of Loops 17845*************************************** 17846 17847GCC provides extensive infrastructure for work with natural loops, i.e., 17848strongly connected components of CFG with only one entry block. This 17849chapter describes representation of loops in GCC, both on GIMPLE and in 17850RTL, as well as the interfaces to loop-related analyses (induction 17851variable analysis and number of iterations analysis). 17852 17853* Menu: 17854 17855* Loop representation:: Representation and analysis of loops. 17856* Loop querying:: Getting information about loops. 17857* Loop manipulation:: Loop manipulation functions. 17858* LCSSA:: Loop-closed SSA form. 17859* Scalar evolutions:: Induction variables on GIMPLE. 17860* loop-iv:: Induction variables on RTL. 17861* Number of iterations:: Number of iterations analysis. 17862* Dependency analysis:: Data dependency analysis. 17863* Omega:: A solver for linear programming problems. 17864 17865 17866File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 17867 1786815.1 Loop representation 17869======================== 17870 17871This chapter describes the representation of loops in GCC, and functions 17872that can be used to build, modify and analyze this representation. Most 17873of the interfaces and data structures are declared in 'cfgloop.h'. Loop 17874structures are analyzed and this information disposed or updated at the 17875discretion of individual passes. Still most of the generic CFG 17876manipulation routines are aware of loop structures and try to keep them 17877up-to-date. By this means an increasing part of the compilation 17878pipeline is setup to maintain loop structure across passes to allow 17879attaching meta information to individual loops for consumption by later 17880passes. 17881 17882 In general, a natural loop has one entry block (header) and possibly 17883several back edges (latches) leading to the header from the inside of 17884the loop. Loops with several latches may appear if several loops share 17885a single header, or if there is a branching in the middle of the loop. 17886The representation of loops in GCC however allows only loops with a 17887single latch. During loop analysis, headers of such loops are split and 17888forwarder blocks are created in order to disambiguate their structures. 17889Heuristic based on profile information and structure of the induction 17890variables in the loops is used to determine whether the latches 17891correspond to sub-loops or to control flow in a single loop. This means 17892that the analysis sometimes changes the CFG, and if you run it in the 17893middle of an optimization pass, you must be able to deal with the new 17894blocks. You may avoid CFG changes by passing 17895'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note 17896however that most other loop manipulation functions will not work 17897correctly for loops with multiple latch edges (the functions that only 17898query membership of blocks to loops and subloop relationships, or 17899enumerate and test loop exits, can be expected to work). 17900 17901 Body of the loop is the set of blocks that are dominated by its header, 17902and reachable from its latch against the direction of edges in CFG. The 17903loops are organized in a containment hierarchy (tree) such that all the 17904loops immediately contained inside loop L are the children of L in the 17905tree. This tree is represented by the 'struct loops' structure. The 17906root of this tree is a fake loop that contains all blocks in the 17907function. Each of the loops is represented in a 'struct loop' 17908structure. Each loop is assigned an index ('num' field of the 'struct 17909loop' structure), and the pointer to the loop is stored in the 17910corresponding field of the 'larray' vector in the loops structure. The 17911indices do not have to be continuous, there may be empty ('NULL') 17912entries in the 'larray' created by deleting loops. Also, there is no 17913guarantee on the relative order of a loop and its subloops in the 17914numbering. The index of a loop never changes. 17915 17916 The entries of the 'larray' field should not be accessed directly. The 17917function 'get_loop' returns the loop description for a loop with the 17918given index. 'number_of_loops' function returns number of loops in the 17919function. To traverse all loops, use 'FOR_EACH_LOOP' macro. The 17920'flags' argument of the macro is used to determine the direction of 17921traversal and the set of loops visited. Each loop is guaranteed to be 17922visited exactly once, regardless of the changes to the loop tree, and 17923the loops may be removed during the traversal. The newly created loops 17924are never traversed, if they need to be visited, this must be done 17925separately after their creation. The 'FOR_EACH_LOOP' macro allocates 17926temporary variables. If the 'FOR_EACH_LOOP' loop were ended using break 17927or goto, they would not be released; 'FOR_EACH_LOOP_BREAK' macro must be 17928used instead. 17929 17930 Each basic block contains the reference to the innermost loop it 17931belongs to ('loop_father'). For this reason, it is only possible to 17932have one 'struct loops' structure initialized at the same time for each 17933CFG. The global variable 'current_loops' contains the 'struct loops' 17934structure. Many of the loop manipulation functions assume that 17935dominance information is up-to-date. 17936 17937 The loops are analyzed through 'loop_optimizer_init' function. The 17938argument of this function is a set of flags represented in an integer 17939bitmask. These flags specify what other properties of the loop 17940structures should be calculated/enforced and preserved later: 17941 17942 * 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes 17943 to CFG will be performed in the loop analysis, in particular, loops 17944 with multiple latch edges will not be disambiguated. If a loop has 17945 multiple latches, its latch block is set to NULL. Most of the loop 17946 manipulation functions will not work for loops in this shape. No 17947 other flags that require CFG changes can be passed to 17948 loop_optimizer_init. 17949 * 'LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a way 17950 that each loop has only one entry edge, and additionally, the 17951 source block of this entry edge has only one successor. This 17952 creates a natural place where the code can be moved out of the 17953 loop, and ensures that the entry edge of the loop leads from its 17954 immediate super-loop. 17955 * 'LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 17956 the latch block of each loop to have only one successor. This 17957 ensures that the latch of the loop does not belong to any of its 17958 sub-loops, and makes manipulation with the loops significantly 17959 easier. Most of the loop manipulation functions assume that the 17960 loops are in this shape. Note that with this flag, the "normal" 17961 loop without any control flow inside and with one exit consists of 17962 two basic blocks. 17963 * 'LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 17964 the strongly connected components that are not natural loops (have 17965 more than one entry block) are marked with 'BB_IRREDUCIBLE_LOOP' 17966 and 'EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 17967 and edges that belong to natural loops that are in such an 17968 irreducible region (but it is set for the entry and exit edges of 17969 such a loop, if they lead to/from this region). 17970 * 'LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and 17971 updated for each loop. This makes some functions (e.g., 17972 'get_loop_exit_edges') more efficient. Some functions (e.g., 17973 'single_exit') can be used only if the lists of exits are recorded. 17974 17975 These properties may also be computed/enforced later, using functions 17976'create_preheaders', 'force_single_succ_latches', 17977'mark_irreducible_loops' and 'record_loop_exits'. The properties can be 17978queried using 'loops_state_satisfies_p'. 17979 17980 The memory occupied by the loops structures should be freed with 17981'loop_optimizer_finalize' function. When loop structures are setup to 17982be preserved across passes this function reduces the information to be 17983kept up-to-date to a minimum (only 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' 17984set). 17985 17986 The CFG manipulation functions in general do not update loop 17987structures. Specialized versions that additionally do so are provided 17988for the most common tasks. On GIMPLE, 'cleanup_tree_cfg_loop' function 17989can be used to cleanup CFG while updating the loops structures if 17990'current_loops' is set. 17991 17992 At the moment loop structure is preserved from the start of GIMPLE loop 17993optimizations until the end of RTL loop optimizations. During this time 17994a loop can be tracked by its 'struct loop' and number. 17995 17996 17997File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 17998 1799915.2 Loop querying 18000================== 18001 18002The functions to query the information about loops are declared in 18003'cfgloop.h'. Some of the information can be taken directly from the 18004structures. 'loop_father' field of each basic block contains the 18005innermost loop to that the block belongs. The most useful fields of 18006loop structure (that are kept up-to-date at all times) are: 18007 18008 * 'header', 'latch': Header and latch basic blocks of the loop. 18009 * 'num_nodes': Number of basic blocks in the loop (including the 18010 basic blocks of the sub-loops). 18011 * 'depth': The depth of the loop in the loops tree, i.e., the number 18012 of super-loops of the loop. 18013 * 'outer', 'inner', 'next': The super-loop, the first sub-loop, and 18014 the sibling of the loop in the loops tree. 18015 18016 There are other fields in the loop structures, many of them used only 18017by some of the passes, or not updated during CFG changes; in general, 18018they should not be accessed directly. 18019 18020 The most important functions to query loop structures are: 18021 18022 * 'flow_loops_dump': Dumps the information about loops to a file. 18023 * 'verify_loop_structure': Checks consistency of the loop structures. 18024 * 'loop_latch_edge': Returns the latch edge of a loop. 18025 * 'loop_preheader_edge': If loops have preheaders, returns the 18026 preheader edge of a loop. 18027 * 'flow_loop_nested_p': Tests whether loop is a sub-loop of another 18028 loop. 18029 * 'flow_bb_inside_loop_p': Tests whether a basic block belongs to a 18030 loop (including its sub-loops). 18031 * 'find_common_loop': Finds the common super-loop of two loops. 18032 * 'superloop_at_depth': Returns the super-loop of a loop with the 18033 given depth. 18034 * 'tree_num_loop_insns', 'num_loop_insns': Estimates the number of 18035 insns in the loop, on GIMPLE and on RTL. 18036 * 'loop_exit_edge_p': Tests whether edge is an exit from a loop. 18037 * 'mark_loop_exit_edges': Marks all exit edges of all loops with 18038 'EDGE_LOOP_EXIT' flag. 18039 * 'get_loop_body', 'get_loop_body_in_dom_order', 18040 'get_loop_body_in_bfs_order': Enumerates the basic blocks in the 18041 loop in depth-first search order in reversed CFG, ordered by 18042 dominance relation, and breath-first search order, respectively. 18043 * 'single_exit': Returns the single exit edge of the loop, or 'NULL' 18044 if the loop has more than one exit. You can only use this function 18045 if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used. 18046 * 'get_loop_exit_edges': Enumerates the exit edges of a loop. 18047 * 'just_once_each_iteration_p': Returns true if the basic block is 18048 executed exactly once during each iteration of a loop (that is, it 18049 does not belong to a sub-loop, and it dominates the latch of the 18050 loop). 18051 18052 18053File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 18054 1805515.3 Loop manipulation 18056====================== 18057 18058The loops tree can be manipulated using the following functions: 18059 18060 * 'flow_loop_tree_node_add': Adds a node to the tree. 18061 * 'flow_loop_tree_node_remove': Removes a node from the tree. 18062 * 'add_bb_to_loop': Adds a basic block to a loop. 18063 * 'remove_bb_from_loops': Removes a basic block from loops. 18064 18065 Most low-level CFG functions update loops automatically. The following 18066functions handle some more complicated cases of CFG manipulations: 18067 18068 * 'remove_path': Removes an edge and all blocks it dominates. 18069 * 'split_loop_exit_edge': Splits exit edge of the loop, ensuring that 18070 PHI node arguments remain in the loop (this ensures that 18071 loop-closed SSA form is preserved). Only useful on GIMPLE. 18072 18073 Finally, there are some higher-level loop transformations implemented. 18074While some of them are written so that they should work on non-innermost 18075loops, they are mostly untested in that case, and at the moment, they 18076are only reliable for the innermost loops: 18077 18078 * 'create_iv': Creates a new induction variable. Only works on 18079 GIMPLE. 'standard_iv_increment_position' can be used to find a 18080 suitable place for the iv increment. 18081 * 'duplicate_loop_to_header_edge', 18082 'tree_duplicate_loop_to_header_edge': These functions (on RTL and 18083 on GIMPLE) duplicate the body of the loop prescribed number of 18084 times on one of the edges entering loop header, thus performing 18085 either loop unrolling or loop peeling. 'can_duplicate_loop_p' 18086 ('can_unroll_loop_p' on GIMPLE) must be true for the duplicated 18087 loop. 18088 * 'loop_version', 'tree_ssa_loop_version': These function create a 18089 copy of a loop, and a branch before them that selects one of them 18090 depending on the prescribed condition. This is useful for 18091 optimizations that need to verify some assumptions in runtime (one 18092 of the copies of the loop is usually left unchanged, while the 18093 other one is transformed in some way). 18094 * 'tree_unroll_loop': Unrolls the loop, including peeling the extra 18095 iterations to make the number of iterations divisible by unroll 18096 factor, updating the exit condition, and removing the exits that 18097 now cannot be taken. Works only on GIMPLE. 18098 18099 18100File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 18101 1810215.4 Loop-closed SSA form 18103========================= 18104 18105Throughout the loop optimizations on tree level, one extra condition is 18106enforced on the SSA form: No SSA name is used outside of the loop in 18107that it is defined. The SSA form satisfying this condition is called 18108"loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 18109created at the exits of the loops for the SSA names that are used 18110outside of them. Only the real operands (not virtual SSA names) are 18111held in LCSSA, in order to save memory. 18112 18113 There are various benefits of LCSSA: 18114 18115 * Many optimizations (value range analysis, final value replacement) 18116 are interested in the values that are defined in the loop and used 18117 outside of it, i.e., exactly those for that we create new PHI 18118 nodes. 18119 * In induction variable analysis, it is not necessary to specify the 18120 loop in that the analysis should be performed - the scalar 18121 evolution analysis always returns the results with respect to the 18122 loop in that the SSA name is defined. 18123 * It makes updating of SSA form during loop transformations simpler. 18124 Without LCSSA, operations like loop unrolling may force creation of 18125 PHI nodes arbitrarily far from the loop, while in LCSSA, the SSA 18126 form can be updated locally. However, since we only keep real 18127 operands in LCSSA, we cannot use this advantage (we could have 18128 local updating of real operands, but it is not much more efficient 18129 than to use generic SSA form updating for it as well; the amount of 18130 changes to SSA is the same). 18131 18132 However, it also means LCSSA must be updated. This is usually 18133straightforward, unless you create a new value in loop and use it 18134outside, or unless you manipulate loop exit edges (functions are 18135provided to make these manipulations simple). 18136'rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, and 18137'verify_loop_closed_ssa' to check that the invariant of LCSSA is 18138preserved. 18139 18140 18141File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 18142 1814315.5 Scalar evolutions 18144====================== 18145 18146Scalar evolutions (SCEV) are used to represent results of induction 18147variable analysis on GIMPLE. They enable us to represent variables with 18148complicated behavior in a simple and consistent way (we only use it to 18149express values of polynomial induction variables, but it is possible to 18150extend it). The interfaces to SCEV analysis are declared in 18151'tree-scalar-evolution.h'. To use scalar evolutions analysis, 18152'scev_initialize' must be used. To stop using SCEV, 'scev_finalize' 18153should be used. SCEV analysis caches results in order to save time and 18154memory. This cache however is made invalid by most of the loop 18155transformations, including removal of code. If such a transformation is 18156performed, 'scev_reset' must be called to clean the caches. 18157 18158 Given an SSA name, its behavior in loops can be analyzed using the 18159'analyze_scalar_evolution' function. The returned SCEV however does not 18160have to be fully analyzed and it may contain references to other SSA 18161names defined in the loop. To resolve these (potentially recursive) 18162references, 'instantiate_parameters' or 'resolve_mixers' functions must 18163be used. 'instantiate_parameters' is useful when you use the results of 18164SCEV only for some analysis, and when you work with whole nest of loops 18165at once. It will try replacing all SSA names by their SCEV in all 18166loops, including the super-loops of the current loop, thus providing a 18167complete information about the behavior of the variable in the loop 18168nest. 'resolve_mixers' is useful if you work with only one loop at a 18169time, and if you possibly need to create code based on the value of the 18170induction variable. It will only resolve the SSA names defined in the 18171current loop, leaving the SSA names defined outside unchanged, even if 18172their evolution in the outer loops is known. 18173 18174 The SCEV is a normal tree expression, except for the fact that it may 18175contain several special tree nodes. One of them is 'SCEV_NOT_KNOWN', 18176used for SSA names whose value cannot be expressed. The other one is 18177'POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 18178and loop (both base and step may contain further polynomial chrecs). 18179Type of the expression and of base and step must be the same. A 18180variable has evolution 'POLYNOMIAL_CHREC(base, step, loop)' if it is (in 18181the specified loop) equivalent to 'x_1' in the following example 18182 18183 while (...) 18184 { 18185 x_1 = phi (base, x_2); 18186 x_2 = x_1 + step; 18187 } 18188 18189 Note that this includes the language restrictions on the operations. 18190For example, if we compile C code and 'x' has signed type, then the 18191overflow in addition would cause undefined behavior, and we may assume 18192that this does not happen. Hence, the value with this SCEV cannot 18193overflow (which restricts the number of iterations of such a loop). 18194 18195 In many cases, one wants to restrict the attention just to affine 18196induction variables. In this case, the extra expressive power of SCEV 18197is not useful, and may complicate the optimizations. In this case, 18198'simple_iv' function may be used to analyze a value - the result is a 18199loop-invariant base and step. 18200 18201 18202File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 18203 1820415.6 IV analysis on RTL 18205======================= 18206 18207The induction variable on RTL is simple and only allows analysis of 18208affine induction variables, and only in one loop at once. The interface 18209is declared in 'cfgloop.h'. Before analyzing induction variables in a 18210loop L, 'iv_analysis_loop_init' function must be called on L. After the 18211analysis (possibly calling 'iv_analysis_loop_init' for several loops) is 18212finished, 'iv_analysis_done' should be called. The following functions 18213can be used to access the results of the analysis: 18214 18215 * 'iv_analyze': Analyzes a single register used in the given insn. 18216 If no use of the register in this insn is found, the following 18217 insns are scanned, so that this function can be called on the insn 18218 returned by get_condition. 18219 * 'iv_analyze_result': Analyzes result of the assignment in the given 18220 insn. 18221 * 'iv_analyze_expr': Analyzes a more complicated expression. All its 18222 operands are analyzed by 'iv_analyze', and hence they must be used 18223 in the specified insn or one of the following insns. 18224 18225 The description of the induction variable is provided in 'struct 18226rtx_iv'. In order to handle subregs, the representation is a bit 18227complicated; if the value of the 'extend' field is not 'UNKNOWN', the 18228value of the induction variable in the i-th iteration is 18229 18230 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 18231 18232 with the following exception: if 'first_special' is true, then the 18233value in the first iteration (when 'i' is zero) is 'delta + mult * 18234base'. However, if 'extend' is equal to 'UNKNOWN', then 'first_special' 18235must be false, 'delta' 0, 'mult' 1 and the value in the i-th iteration 18236is 18237 18238 subreg_{mode} (base + i * step) 18239 18240 The function 'get_iv_value' can be used to perform these calculations. 18241 18242 18243File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 18244 1824515.7 Number of iterations analysis 18246================================== 18247 18248Both on GIMPLE and on RTL, there are functions available to determine 18249the number of iterations of a loop, with a similar interface. The 18250number of iterations of a loop in GCC is defined as the number of 18251executions of the loop latch. In many cases, it is not possible to 18252determine the number of iterations unconditionally - the determined 18253number is correct only if some assumptions are satisfied. The analysis 18254tries to verify these conditions using the information contained in the 18255program; if it fails, the conditions are returned together with the 18256result. The following information and conditions are provided by the 18257analysis: 18258 18259 * 'assumptions': If this condition is false, the rest of the 18260 information is invalid. 18261 * 'noloop_assumptions' on RTL, 'may_be_zero' on GIMPLE: If this 18262 condition is true, the loop exits in the first iteration. 18263 * 'infinite': If this condition is true, the loop is infinite. This 18264 condition is only available on RTL. On GIMPLE, conditions for 18265 finiteness of the loop are included in 'assumptions'. 18266 * 'niter_expr' on RTL, 'niter' on GIMPLE: The expression that gives 18267 number of iterations. The number of iterations is defined as the 18268 number of executions of the loop latch. 18269 18270 Both on GIMPLE and on RTL, it necessary for the induction variable 18271analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 18272On GIMPLE, the results are stored to 'struct tree_niter_desc' structure. 18273Number of iterations before the loop is exited through a given exit can 18274be determined using 'number_of_iterations_exit' function. On RTL, the 18275results are returned in 'struct niter_desc' structure. The 18276corresponding function is named 'check_simple_exit'. There are also 18277functions that pass through all the exits of a loop and try to find one 18278with easy to determine number of iterations - 'find_loop_niter' on 18279GIMPLE and 'find_simple_exit' on RTL. Finally, there are functions that 18280provide the same information, but additionally cache it, so that 18281repeated calls to number of iterations are not so costly - 18282'number_of_latch_executions' on GIMPLE and 'get_simple_loop_desc' on 18283RTL. 18284 18285 Note that some of these functions may behave slightly differently than 18286others - some of them return only the expression for the number of 18287iterations, and fail if there are some assumptions. The function 18288'number_of_latch_executions' works only for single-exit loops. The 18289function 'number_of_cond_exit_executions' can be used to determine 18290number of executions of the exit condition of a single-exit loop (i.e., 18291the 'number_of_latch_executions' increased by one). 18292 18293 18294File: gccint.info, Node: Dependency analysis, Next: Omega, Prev: Number of iterations, Up: Loop Analysis and Representation 18295 1829615.8 Data Dependency Analysis 18297============================= 18298 18299The code for the data dependence analysis can be found in 18300'tree-data-ref.c' and its interface and data structures are described in 18301'tree-data-ref.h'. The function that computes the data dependences for 18302all the array and pointer references for a given loop is 18303'compute_data_dependences_for_loop'. This function is currently used by 18304the linear loop transform and the vectorization passes. Before calling 18305this function, one has to allocate two vectors: a first vector will 18306contain the set of data references that are contained in the analyzed 18307loop body, and the second vector will contain the dependence relations 18308between the data references. Thus if the vector of data references is 18309of size 'n', the vector containing the dependence relations will contain 18310'n*n' elements. However if the analyzed loop contains side effects, 18311such as calls that potentially can interfere with the data references in 18312the current analyzed loop, the analysis stops while scanning the loop 18313body for data references, and inserts a single 'chrec_dont_know' in the 18314dependence relation array. 18315 18316 The data references are discovered in a particular order during the 18317scanning of the loop body: the loop body is analyzed in execution order, 18318and the data references of each statement are pushed at the end of the 18319data reference array. Two data references syntactically occur in the 18320program in the same order as in the array of data references. This 18321syntactic order is important in some classical data dependence tests, 18322and mapping this order to the elements of this array avoids costly 18323queries to the loop body representation. 18324 18325 Three types of data references are currently handled: ARRAY_REF, 18326INDIRECT_REF and COMPONENT_REF. The data structure for the data 18327reference is 'data_reference', where 'data_reference_p' is a name of a 18328pointer to the data reference structure. The structure contains the 18329following elements: 18330 18331 * 'base_object_info': Provides information about the base object of 18332 the data reference and its access functions. These access 18333 functions represent the evolution of the data reference in the loop 18334 relative to its base, in keeping with the classical meaning of the 18335 data reference access function for the support of arrays. For 18336 example, for a reference 'a.b[i][j]', the base object is 'a.b' and 18337 the access functions, one for each array subscript, are: '{i_init, 18338 + i_step}_1, {j_init, +, j_step}_2'. 18339 18340 * 'first_location_in_loop': Provides information about the first 18341 location accessed by the data reference in the loop and about the 18342 access function used to represent evolution relative to this 18343 location. This data is used to support pointers, and is not used 18344 for arrays (for which we have base objects). Pointer accesses are 18345 represented as a one-dimensional access that starts from the first 18346 location accessed in the loop. For example: 18347 18348 for1 i 18349 for2 j 18350 *((int *)p + i + j) = a[i][j]; 18351 18352 The access function of the pointer access is '{0, + 4B}_for2' 18353 relative to 'p + i'. The access functions of the array are 18354 '{i_init, + i_step}_for1' and '{j_init, +, j_step}_for2' relative 18355 to 'a'. 18356 18357 Usually, the object the pointer refers to is either unknown, or we 18358 can't prove that the access is confined to the boundaries of a 18359 certain object. 18360 18361 Two data references can be compared only if at least one of these 18362 two representations has all its fields filled for both data 18363 references. 18364 18365 The current strategy for data dependence tests is as follows: If 18366 both 'a' and 'b' are represented as arrays, compare 'a.base_object' 18367 and 'b.base_object'; if they are equal, apply dependence tests (use 18368 access functions based on base_objects). Else if both 'a' and 'b' 18369 are represented as pointers, compare 'a.first_location' and 18370 'b.first_location'; if they are equal, apply dependence tests (use 18371 access functions based on first location). However, if 'a' and 'b' 18372 are represented differently, only try to prove that the bases are 18373 definitely different. 18374 18375 * Aliasing information. 18376 * Alignment information. 18377 18378 The structure describing the relation between two data references is 18379'data_dependence_relation' and the shorter name for a pointer to such a 18380structure is 'ddr_p'. This structure contains: 18381 18382 * a pointer to each data reference, 18383 * a tree node 'are_dependent' that is set to 'chrec_known' if the 18384 analysis has proved that there is no dependence between these two 18385 data references, 'chrec_dont_know' if the analysis was not able to 18386 determine any useful result and potentially there could exist a 18387 dependence between these data references, and 'are_dependent' is 18388 set to 'NULL_TREE' if there exist a dependence relation between the 18389 data references, and the description of this dependence relation is 18390 given in the 'subscripts', 'dir_vects', and 'dist_vects' arrays, 18391 * a boolean that determines whether the dependence relation can be 18392 represented by a classical distance vector, 18393 * an array 'subscripts' that contains a description of each subscript 18394 of the data references. Given two array accesses a subscript is 18395 the tuple composed of the access functions for a given dimension. 18396 For example, given 'A[f1][f2][f3]' and 'B[g1][g2][g3]', there are 18397 three subscripts: '(f1, g1), (f2, g2), (f3, g3)'. 18398 * two arrays 'dir_vects' and 'dist_vects' that contain classical 18399 representations of the data dependences under the form of direction 18400 and distance dependence vectors, 18401 * an array of loops 'loop_nest' that contains the loops to which the 18402 distance and direction vectors refer to. 18403 18404 Several functions for pretty printing the information extracted by the 18405data dependence analysis are available: 'dump_ddrs' prints with a 18406maximum verbosity the details of a data dependence relations array, 18407'dump_dist_dir_vectors' prints only the classical distance and direction 18408vectors for a data dependence relations array, and 18409'dump_data_references' prints the details of the data references 18410contained in a data reference array. 18411 18412 18413File: gccint.info, Node: Omega, Prev: Dependency analysis, Up: Loop Analysis and Representation 18414 1841515.9 Omega a solver for linear programming problems 18416=================================================== 18417 18418The data dependence analysis contains several solvers triggered 18419sequentially from the less complex ones to the more sophisticated. For 18420ensuring the consistency of the results of these solvers, a data 18421dependence check pass has been implemented based on two different 18422solvers. The second method that has been integrated to GCC is based on 18423the Omega dependence solver, written in the 1990's by William Pugh and 18424David Wonnacott. Data dependence tests can be formulated using a subset 18425of the Presburger arithmetics that can be translated to linear 18426constraint systems. These linear constraint systems can then be solved 18427using the Omega solver. 18428 18429 The Omega solver is using Fourier-Motzkin's algorithm for variable 18430elimination: a linear constraint system containing 'n' variables is 18431reduced to a linear constraint system with 'n-1' variables. The Omega 18432solver can also be used for solving other problems that can be expressed 18433under the form of a system of linear equalities and inequalities. The 18434Omega solver is known to have an exponential worst case, also known 18435under the name of "omega nightmare" in the literature, but in practice, 18436the omega test is known to be efficient for the common data dependence 18437tests. 18438 18439 The interface used by the Omega solver for describing the linear 18440programming problems is described in 'omega.h', and the solver is 18441'omega_solve_problem'. 18442 18443 18444File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 18445 1844616 Machine Descriptions 18447*********************** 18448 18449A machine description has two parts: a file of instruction patterns 18450('.md' file) and a C header file of macro definitions. 18451 18452 The '.md' file for a target machine contains a pattern for each 18453instruction that the target machine supports (or at least each 18454instruction that is worth telling the compiler about). It may also 18455contain comments. A semicolon causes the rest of the line to be a 18456comment, unless the semicolon is inside a quoted string. 18457 18458 See the next chapter for information on the C header file. 18459 18460* Menu: 18461 18462* Overview:: How the machine description is used. 18463* Patterns:: How to write instruction patterns. 18464* Example:: An explained example of a 'define_insn' pattern. 18465* RTL Template:: The RTL template defines what insns match a pattern. 18466* Output Template:: The output template says how to make assembler code 18467 from such an insn. 18468* Output Statement:: For more generality, write C code to output 18469 the assembler code. 18470* Predicates:: Controlling what kinds of operands can be used 18471 for an insn. 18472* Constraints:: Fine-tuning operand selection. 18473* Standard Names:: Names mark patterns to use for code generation. 18474* Pattern Ordering:: When the order of patterns makes a difference. 18475* Dependent Patterns:: Having one pattern may make you need another. 18476* Jump Patterns:: Special considerations for patterns for jump insns. 18477* Looping Patterns:: How to define patterns for special looping insns. 18478* Insn Canonicalizations::Canonicalization of Instructions 18479* Expander Definitions::Generating a sequence of several RTL insns 18480 for a standard operation. 18481* Insn Splitting:: Splitting Instructions into Multiple Instructions. 18482* Including Patterns:: Including Patterns in Machine Descriptions. 18483* Peephole Definitions::Defining machine-specific peephole optimizations. 18484* Insn Attributes:: Specifying the value of attributes for generated insns. 18485* Conditional Execution::Generating 'define_insn' patterns for 18486 predication. 18487* Define Subst:: Generating 'define_insn' and 'define_expand' 18488 patterns from other patterns. 18489* Constant Definitions::Defining symbolic constants that can be used in the 18490 md file. 18491* Iterators:: Using iterators to generate patterns from a template. 18492 18493 18494File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 18495 1849616.1 Overview of How the Machine Description is Used 18497==================================================== 18498 18499There are three main conversions that happen in the compiler: 18500 18501 1. The front end reads the source code and builds a parse tree. 18502 18503 2. The parse tree is used to generate an RTL insn list based on named 18504 instruction patterns. 18505 18506 3. The insn list is matched against the RTL templates to produce 18507 assembler code. 18508 18509 For the generate pass, only the names of the insns matter, from either 18510a named 'define_insn' or a 'define_expand'. The compiler will choose 18511the pattern with the right name and apply the operands according to the 18512documentation later in this chapter, without regard for the RTL template 18513or operand constraints. Note that the names the compiler looks for are 18514hard-coded in the compiler--it will ignore unnamed patterns and patterns 18515with names it doesn't know about, but if you don't provide a named 18516pattern it needs, it will abort. 18517 18518 If a 'define_insn' is used, the template given is inserted into the 18519insn list. If a 'define_expand' is used, one of three things happens, 18520based on the condition logic. The condition logic may manually create 18521new insns for the insn list, say via 'emit_insn()', and invoke 'DONE'. 18522For certain named patterns, it may invoke 'FAIL' to tell the compiler to 18523use an alternate way of performing that task. If it invokes neither 18524'DONE' nor 'FAIL', the template given in the pattern is inserted, as if 18525the 'define_expand' were a 'define_insn'. 18526 18527 Once the insn list is generated, various optimization passes convert, 18528replace, and rearrange the insns in the insn list. This is where the 18529'define_split' and 'define_peephole' patterns get used, for example. 18530 18531 Finally, the insn list's RTL is matched up with the RTL templates in 18532the 'define_insn' patterns, and those patterns are used to emit the 18533final assembly code. For this purpose, each named 'define_insn' acts 18534like it's unnamed, since the names are ignored. 18535 18536 18537File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 18538 1853916.2 Everything about Instruction Patterns 18540========================================== 18541 18542A 'define_insn' expression is used to define instruction patterns to 18543which insns may be matched. A 'define_insn' expression contains an 18544incomplete RTL expression, with pieces to be filled in later, operand 18545constraints that restrict how the pieces can be filled in, and an output 18546template or C code to generate the assembler output. 18547 18548 A 'define_insn' is an RTL expression containing four or five operands: 18549 18550 1. An optional name. The presence of a name indicate that this 18551 instruction pattern can perform a certain standard job for the 18552 RTL-generation pass of the compiler. This pass knows certain names 18553 and will use the instruction patterns with those names, if the 18554 names are defined in the machine description. 18555 18556 The absence of a name is indicated by writing an empty string where 18557 the name should go. Nameless instruction patterns are never used 18558 for generating RTL code, but they may permit several simpler insns 18559 to be combined later on. 18560 18561 Names that are not thus known and used in RTL-generation have no 18562 effect; they are equivalent to no name at all. 18563 18564 For the purpose of debugging the compiler, you may also specify a 18565 name beginning with the '*' character. Such a name is used only 18566 for identifying the instruction in RTL dumps; it is equivalent to 18567 having a nameless pattern for all other purposes. Names beginning 18568 with the '*' character are not required to be unique. 18569 18570 2. The "RTL template": This is a vector of incomplete RTL expressions 18571 which describe the semantics of the instruction (*note RTL 18572 Template::). It is incomplete because it may contain 18573 'match_operand', 'match_operator', and 'match_dup' expressions that 18574 stand for operands of the instruction. 18575 18576 If the vector has multiple elements, the RTL template is treated as 18577 a 'parallel' expression. 18578 18579 3. The condition: This is a string which contains a C expression. 18580 When the compiler attempts to match RTL against a pattern, the 18581 condition is evaluated. If the condition evaluates to 'true', the 18582 match is permitted. The condition may be an empty string, which is 18583 treated as always 'true'. 18584 18585 For a named pattern, the condition may not depend on the data in 18586 the insn being matched, but only the target-machine-type flags. 18587 The compiler needs to test these conditions during initialization 18588 in order to learn exactly which named instructions are available in 18589 a particular run. 18590 18591 For nameless patterns, the condition is applied only when matching 18592 an individual insn, and only after the insn has matched the 18593 pattern's recognition template. The insn's operands may be found 18594 in the vector 'operands'. 18595 18596 For an insn where the condition has once matched, it cannot later 18597 be used to control register allocation by excluding certain 18598 register or value combinations. 18599 18600 4. The "output template" or "output statement": This is either a 18601 string, or a fragment of C code which returns a string. 18602 18603 When simple substitution isn't general enough, you can specify a 18604 piece of C code to compute the output. *Note Output Statement::. 18605 18606 5. The "insn attributes": This is an optional vector containing the 18607 values of attributes for insns matching this pattern (*note Insn 18608 Attributes::). 18609 18610 18611File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 18612 1861316.3 Example of 'define_insn' 18614============================= 18615 18616Here is an example of an instruction pattern, taken from the machine 18617description for the 68000/68020. 18618 18619 (define_insn "tstsi" 18620 [(set (cc0) 18621 (match_operand:SI 0 "general_operand" "rm"))] 18622 "" 18623 "* 18624 { 18625 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 18626 return \"tstl %0\"; 18627 return \"cmpl #0,%0\"; 18628 }") 18629 18630This can also be written using braced strings: 18631 18632 (define_insn "tstsi" 18633 [(set (cc0) 18634 (match_operand:SI 0 "general_operand" "rm"))] 18635 "" 18636 { 18637 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 18638 return "tstl %0"; 18639 return "cmpl #0,%0"; 18640 }) 18641 18642 This describes an instruction which sets the condition codes based on 18643the value of a general operand. It has no condition, so any insn with 18644an RTL description of the form shown may be matched to this pattern. 18645The name 'tstsi' means "test a 'SImode' value" and tells the RTL 18646generation pass that, when it is necessary to test such a value, an insn 18647to do so can be constructed using this pattern. 18648 18649 The output control string is a piece of C code which chooses which 18650output template to return based on the kind of operand and the specific 18651type of CPU for which code is being generated. 18652 18653 '"rm"' is an operand constraint. Its meaning is explained below. 18654 18655 18656File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 18657 1865816.4 RTL Template 18659================= 18660 18661The RTL template is used to define which insns match the particular 18662pattern and how to find their operands. For named patterns, the RTL 18663template also says how to construct an insn from specified operands. 18664 18665 Construction involves substituting specified operands into a copy of 18666the template. Matching involves determining the values that serve as 18667the operands in the insn being matched. Both of these activities are 18668controlled by special expression types that direct matching and 18669substitution of the operands. 18670 18671'(match_operand:M N PREDICATE CONSTRAINT)' 18672 This expression is a placeholder for operand number N of the insn. 18673 When constructing an insn, operand number N will be substituted at 18674 this point. When matching an insn, whatever appears at this 18675 position in the insn will be taken as operand number N; but it must 18676 satisfy PREDICATE or this instruction pattern will not match at 18677 all. 18678 18679 Operand numbers must be chosen consecutively counting from zero in 18680 each instruction pattern. There may be only one 'match_operand' 18681 expression in the pattern for each operand number. Usually 18682 operands are numbered in the order of appearance in 'match_operand' 18683 expressions. In the case of a 'define_expand', any operand numbers 18684 used only in 'match_dup' expressions have higher values than all 18685 other operand numbers. 18686 18687 PREDICATE is a string that is the name of a function that accepts 18688 two arguments, an expression and a machine mode. *Note 18689 Predicates::. During matching, the function will be called with 18690 the putative operand as the expression and M as the mode argument 18691 (if M is not specified, 'VOIDmode' will be used, which normally 18692 causes PREDICATE to accept any mode). If it returns zero, this 18693 instruction pattern fails to match. PREDICATE may be an empty 18694 string; then it means no test is to be done on the operand, so 18695 anything which occurs in this position is valid. 18696 18697 Most of the time, PREDICATE will reject modes other than M--but not 18698 always. For example, the predicate 'address_operand' uses M as the 18699 mode of memory ref that the address should be valid for. Many 18700 predicates accept 'const_int' nodes even though their mode is 18701 'VOIDmode'. 18702 18703 CONSTRAINT controls reloading and the choice of the best register 18704 class to use for a value, as explained later (*note Constraints::). 18705 If the constraint would be an empty string, it can be omitted. 18706 18707 People are often unclear on the difference between the constraint 18708 and the predicate. The predicate helps decide whether a given insn 18709 matches the pattern. The constraint plays no role in this 18710 decision; instead, it controls various decisions in the case of an 18711 insn which does match. 18712 18713'(match_scratch:M N CONSTRAINT)' 18714 This expression is also a placeholder for operand number N and 18715 indicates that operand must be a 'scratch' or 'reg' expression. 18716 18717 When matching patterns, this is equivalent to 18718 18719 (match_operand:M N "scratch_operand" CONSTRAINT) 18720 18721 but, when generating RTL, it produces a ('scratch':M) expression. 18722 18723 If the last few expressions in a 'parallel' are 'clobber' 18724 expressions whose operands are either a hard register or 18725 'match_scratch', the combiner can add or delete them when 18726 necessary. *Note Side Effects::. 18727 18728'(match_dup N)' 18729 This expression is also a placeholder for operand number N. It is 18730 used when the operand needs to appear more than once in the insn. 18731 18732 In construction, 'match_dup' acts just like 'match_operand': the 18733 operand is substituted into the insn being constructed. But in 18734 matching, 'match_dup' behaves differently. It assumes that operand 18735 number N has already been determined by a 'match_operand' appearing 18736 earlier in the recognition template, and it matches only an 18737 identical-looking expression. 18738 18739 Note that 'match_dup' should not be used to tell the compiler that 18740 a particular register is being used for two operands (example: 18741 'add' that adds one register to another; the second register is 18742 both an input operand and the output operand). Use a matching 18743 constraint (*note Simple Constraints::) for those. 'match_dup' is 18744 for the cases where one operand is used in two places in the 18745 template, such as an instruction that computes both a quotient and 18746 a remainder, where the opcode takes two input operands but the RTL 18747 template has to refer to each of those twice; once for the quotient 18748 pattern and once for the remainder pattern. 18749 18750'(match_operator:M N PREDICATE [OPERANDS...])' 18751 This pattern is a kind of placeholder for a variable RTL expression 18752 code. 18753 18754 When constructing an insn, it stands for an RTL expression whose 18755 expression code is taken from that of operand N, and whose operands 18756 are constructed from the patterns OPERANDS. 18757 18758 When matching an expression, it matches an expression if the 18759 function PREDICATE returns nonzero on that expression _and_ the 18760 patterns OPERANDS match the operands of the expression. 18761 18762 Suppose that the function 'commutative_operator' is defined as 18763 follows, to match any expression whose operator is one of the 18764 commutative arithmetic operators of RTL and whose mode is MODE: 18765 18766 int 18767 commutative_integer_operator (x, mode) 18768 rtx x; 18769 machine_mode mode; 18770 { 18771 enum rtx_code code = GET_CODE (x); 18772 if (GET_MODE (x) != mode) 18773 return 0; 18774 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 18775 || code == EQ || code == NE); 18776 } 18777 18778 Then the following pattern will match any RTL expression consisting 18779 of a commutative operator applied to two general operands: 18780 18781 (match_operator:SI 3 "commutative_operator" 18782 [(match_operand:SI 1 "general_operand" "g") 18783 (match_operand:SI 2 "general_operand" "g")]) 18784 18785 Here the vector '[OPERANDS...]' contains two patterns because the 18786 expressions to be matched all contain two operands. 18787 18788 When this pattern does match, the two operands of the commutative 18789 operator are recorded as operands 1 and 2 of the insn. (This is 18790 done by the two instances of 'match_operand'.) Operand 3 of the 18791 insn will be the entire commutative expression: use 'GET_CODE 18792 (operands[3])' to see which commutative operator was used. 18793 18794 The machine mode M of 'match_operator' works like that of 18795 'match_operand': it is passed as the second argument to the 18796 predicate function, and that function is solely responsible for 18797 deciding whether the expression to be matched "has" that mode. 18798 18799 When constructing an insn, argument 3 of the gen-function will 18800 specify the operation (i.e. the expression code) for the expression 18801 to be made. It should be an RTL expression, whose expression code 18802 is copied into a new expression whose operands are arguments 1 and 18803 2 of the gen-function. The subexpressions of argument 3 are not 18804 used; only its expression code matters. 18805 18806 When 'match_operator' is used in a pattern for matching an insn, it 18807 usually best if the operand number of the 'match_operator' is 18808 higher than that of the actual operands of the insn. This improves 18809 register allocation because the register allocator often looks at 18810 operands 1 and 2 of insns to see if it can do register tying. 18811 18812 There is no way to specify constraints in 'match_operator'. The 18813 operand of the insn which corresponds to the 'match_operator' never 18814 has any constraints because it is never reloaded as a whole. 18815 However, if parts of its OPERANDS are matched by 'match_operand' 18816 patterns, those parts may have constraints of their own. 18817 18818'(match_op_dup:M N[OPERANDS...])' 18819 Like 'match_dup', except that it applies to operators instead of 18820 operands. When constructing an insn, operand number N will be 18821 substituted at this point. But in matching, 'match_op_dup' behaves 18822 differently. It assumes that operand number N has already been 18823 determined by a 'match_operator' appearing earlier in the 18824 recognition template, and it matches only an identical-looking 18825 expression. 18826 18827'(match_parallel N PREDICATE [SUBPAT...])' 18828 This pattern is a placeholder for an insn that consists of a 18829 'parallel' expression with a variable number of elements. This 18830 expression should only appear at the top level of an insn pattern. 18831 18832 When constructing an insn, operand number N will be substituted at 18833 this point. When matching an insn, it matches if the body of the 18834 insn is a 'parallel' expression with at least as many elements as 18835 the vector of SUBPAT expressions in the 'match_parallel', if each 18836 SUBPAT matches the corresponding element of the 'parallel', _and_ 18837 the function PREDICATE returns nonzero on the 'parallel' that is 18838 the body of the insn. It is the responsibility of the predicate to 18839 validate elements of the 'parallel' beyond those listed in the 18840 'match_parallel'. 18841 18842 A typical use of 'match_parallel' is to match load and store 18843 multiple expressions, which can contain a variable number of 18844 elements in a 'parallel'. For example, 18845 18846 (define_insn "" 18847 [(match_parallel 0 "load_multiple_operation" 18848 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 18849 (match_operand:SI 2 "memory_operand" "m")) 18850 (use (reg:SI 179)) 18851 (clobber (reg:SI 179))])] 18852 "" 18853 "loadm 0,0,%1,%2") 18854 18855 This example comes from 'a29k.md'. The function 18856 'load_multiple_operation' is defined in 'a29k.c' and checks that 18857 subsequent elements in the 'parallel' are the same as the 'set' in 18858 the pattern, except that they are referencing subsequent registers 18859 and memory locations. 18860 18861 An insn that matches this pattern might look like: 18862 18863 (parallel 18864 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 18865 (use (reg:SI 179)) 18866 (clobber (reg:SI 179)) 18867 (set (reg:SI 21) 18868 (mem:SI (plus:SI (reg:SI 100) 18869 (const_int 4)))) 18870 (set (reg:SI 22) 18871 (mem:SI (plus:SI (reg:SI 100) 18872 (const_int 8))))]) 18873 18874'(match_par_dup N [SUBPAT...])' 18875 Like 'match_op_dup', but for 'match_parallel' instead of 18876 'match_operator'. 18877 18878 18879File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 18880 1888116.5 Output Templates and Operand Substitution 18882============================================== 18883 18884The "output template" is a string which specifies how to output the 18885assembler code for an instruction pattern. Most of the template is a 18886fixed string which is output literally. The character '%' is used to 18887specify where to substitute an operand; it can also be used to identify 18888places where different variants of the assembler require different 18889syntax. 18890 18891 In the simplest case, a '%' followed by a digit N says to output 18892operand N at that point in the string. 18893 18894 '%' followed by a letter and a digit says to output an operand in an 18895alternate fashion. Four letters have standard, built-in meanings 18896described below. The machine description macro 'PRINT_OPERAND' can 18897define additional letters with nonstandard meanings. 18898 18899 '%cDIGIT' can be used to substitute an operand that is a constant value 18900without the syntax that normally indicates an immediate operand. 18901 18902 '%nDIGIT' is like '%cDIGIT' except that the value of the constant is 18903negated before printing. 18904 18905 '%aDIGIT' can be used to substitute an operand as if it were a memory 18906reference, with the actual operand treated as the address. This may be 18907useful when outputting a "load address" instruction, because often the 18908assembler syntax for such an instruction requires you to write the 18909operand as if it were a memory reference. 18910 18911 '%lDIGIT' is used to substitute a 'label_ref' into a jump instruction. 18912 18913 '%=' outputs a number which is unique to each instruction in the entire 18914compilation. This is useful for making local labels to be referred to 18915more than once in a single template that generates multiple assembler 18916instructions. 18917 18918 '%' followed by a punctuation character specifies a substitution that 18919does not use an operand. Only one case is standard: '%%' outputs a '%' 18920into the assembler code. Other nonstandard cases can be defined in the 18921'PRINT_OPERAND' macro. You must also define which punctuation 18922characters are valid with the 'PRINT_OPERAND_PUNCT_VALID_P' macro. 18923 18924 The template may generate multiple assembler instructions. Write the 18925text for the instructions, with '\;' between them. 18926 18927 When the RTL contains two operands which are required by constraint to 18928match each other, the output template must refer only to the 18929lower-numbered operand. Matching operands are not always identical, and 18930the rest of the compiler arranges to put the proper RTL expression for 18931printing into the lower-numbered operand. 18932 18933 One use of nonstandard letters or punctuation following '%' is to 18934distinguish between different assembler languages for the same machine; 18935for example, Motorola syntax versus MIT syntax for the 68000. Motorola 18936syntax requires periods in most opcode names, while MIT syntax does not. 18937For example, the opcode 'movel' in MIT syntax is 'move.l' in Motorola 18938syntax. The same file of patterns is used for both kinds of output 18939syntax, but the character sequence '%.' is used in each place where 18940Motorola syntax wants a period. The 'PRINT_OPERAND' macro for Motorola 18941syntax defines the sequence to output a period; the macro for MIT syntax 18942defines it to do nothing. 18943 18944 As a special case, a template consisting of the single character '#' 18945instructs the compiler to first split the insn, and then output the 18946resulting instructions separately. This helps eliminate redundancy in 18947the output templates. If you have a 'define_insn' that needs to emit 18948multiple assembler instructions, and there is a matching 'define_split' 18949already defined, then you can simply use '#' as the output template 18950instead of writing an output template that emits the multiple assembler 18951instructions. 18952 18953 If the macro 'ASSEMBLER_DIALECT' is defined, you can use construct of 18954the form '{option0|option1|option2}' in the templates. These describe 18955multiple variants of assembler language syntax. *Note Instruction 18956Output::. 18957 18958 18959File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 18960 1896116.6 C Statements for Assembler Output 18962====================================== 18963 18964Often a single fixed template string cannot produce correct and 18965efficient assembler code for all the cases that are recognized by a 18966single instruction pattern. For example, the opcodes may depend on the 18967kinds of operands; or some unfortunate combinations of operands may 18968require extra machine instructions. 18969 18970 If the output control string starts with a '@', then it is actually a 18971series of templates, each on a separate line. (Blank lines and leading 18972spaces and tabs are ignored.) The templates correspond to the pattern's 18973constraint alternatives (*note Multi-Alternative::). For example, if a 18974target machine has a two-address add instruction 'addr' to add into a 18975register and another 'addm' to add a register to memory, you might write 18976this pattern: 18977 18978 (define_insn "addsi3" 18979 [(set (match_operand:SI 0 "general_operand" "=r,m") 18980 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 18981 (match_operand:SI 2 "general_operand" "g,r")))] 18982 "" 18983 "@ 18984 addr %2,%0 18985 addm %2,%0") 18986 18987 If the output control string starts with a '*', then it is not an 18988output template but rather a piece of C program that should compute a 18989template. It should execute a 'return' statement to return the 18990template-string you want. Most such templates use C string literals, 18991which require doublequote characters to delimit them. To include these 18992doublequote characters in the string, prefix each one with '\'. 18993 18994 If the output control string is written as a brace block instead of a 18995double-quoted string, it is automatically assumed to be C code. In that 18996case, it is not necessary to put in a leading asterisk, or to escape the 18997doublequotes surrounding C string literals. 18998 18999 The operands may be found in the array 'operands', whose C data type is 19000'rtx []'. 19001 19002 It is very common to select different ways of generating assembler code 19003based on whether an immediate operand is within a certain range. Be 19004careful when doing this, because the result of 'INTVAL' is an integer on 19005the host machine. If the host machine has more bits in an 'int' than 19006the target machine has in the mode in which the constant will be used, 19007then some of the bits you get from 'INTVAL' will be superfluous. For 19008proper results, you must carefully disregard the values of those bits. 19009 19010 It is possible to output an assembler instruction and then go on to 19011output or compute more of them, using the subroutine 'output_asm_insn'. 19012This receives two arguments: a template-string and a vector of operands. 19013The vector may be 'operands', or it may be another array of 'rtx' that 19014you declare locally and initialize yourself. 19015 19016 When an insn pattern has multiple alternatives in its constraints, 19017often the appearance of the assembler code is determined mostly by which 19018alternative was matched. When this is so, the C code can test the 19019variable 'which_alternative', which is the ordinal number of the 19020alternative that was actually satisfied (0 for the first, 1 for the 19021second alternative, etc.). 19022 19023 For example, suppose there are two opcodes for storing zero, 'clrreg' 19024for registers and 'clrmem' for memory locations. Here is how a pattern 19025could use 'which_alternative' to choose between them: 19026 19027 (define_insn "" 19028 [(set (match_operand:SI 0 "general_operand" "=r,m") 19029 (const_int 0))] 19030 "" 19031 { 19032 return (which_alternative == 0 19033 ? "clrreg %0" : "clrmem %0"); 19034 }) 19035 19036 The example above, where the assembler code to generate was _solely_ 19037determined by the alternative, could also have been specified as 19038follows, having the output control string start with a '@': 19039 19040 (define_insn "" 19041 [(set (match_operand:SI 0 "general_operand" "=r,m") 19042 (const_int 0))] 19043 "" 19044 "@ 19045 clrreg %0 19046 clrmem %0") 19047 19048 If you just need a little bit of C code in one (or a few) alternatives, 19049you can use '*' inside of a '@' multi-alternative template: 19050 19051 (define_insn "" 19052 [(set (match_operand:SI 0 "general_operand" "=r,<,m") 19053 (const_int 0))] 19054 "" 19055 "@ 19056 clrreg %0 19057 * return stack_mem_p (operands[0]) ? \"push 0\" : \"clrmem %0\"; 19058 clrmem %0") 19059 19060 19061File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 19062 1906316.7 Predicates 19064=============== 19065 19066A predicate determines whether a 'match_operand' or 'match_operator' 19067expression matches, and therefore whether the surrounding instruction 19068pattern will be used for that combination of operands. GCC has a number 19069of machine-independent predicates, and you can define machine-specific 19070predicates as needed. By convention, predicates used with 19071'match_operand' have names that end in '_operand', and those used with 19072'match_operator' have names that end in '_operator'. 19073 19074 All predicates are Boolean functions (in the mathematical sense) of two 19075arguments: the RTL expression that is being considered at that position 19076in the instruction pattern, and the machine mode that the 19077'match_operand' or 'match_operator' specifies. In this section, the 19078first argument is called OP and the second argument MODE. Predicates 19079can be called from C as ordinary two-argument functions; this can be 19080useful in output templates or other machine-specific code. 19081 19082 Operand predicates can allow operands that are not actually acceptable 19083to the hardware, as long as the constraints give reload the ability to 19084fix them up (*note Constraints::). However, GCC will usually generate 19085better code if the predicates specify the requirements of the machine 19086instructions as closely as possible. Reload cannot fix up operands that 19087must be constants ("immediate operands"); you must use a predicate that 19088allows only constants, or else enforce the requirement in the extra 19089condition. 19090 19091 Most predicates handle their MODE argument in a uniform manner. If 19092MODE is 'VOIDmode' (unspecified), then OP can have any mode. If MODE is 19093anything else, then OP must have the same mode, unless OP is a 19094'CONST_INT' or integer 'CONST_DOUBLE'. These RTL expressions always 19095have 'VOIDmode', so it would be counterproductive to check that their 19096mode matches. Instead, predicates that accept 'CONST_INT' and/or 19097integer 'CONST_DOUBLE' check that the value stored in the constant will 19098fit in the requested mode. 19099 19100 Predicates with this behavior are called "normal". 'genrecog' can 19101optimize the instruction recognizer based on knowledge of how normal 19102predicates treat modes. It can also diagnose certain kinds of common 19103errors in the use of normal predicates; for instance, it is almost 19104always an error to use a normal predicate without specifying a mode. 19105 19106 Predicates that do something different with their MODE argument are 19107called "special". The generic predicates 'address_operand' and 19108'pmode_register_operand' are special predicates. 'genrecog' does not do 19109any optimizations or diagnosis when special predicates are used. 19110 19111* Menu: 19112 19113* Machine-Independent Predicates:: Predicates available to all back ends. 19114* Defining Predicates:: How to write machine-specific predicate 19115 functions. 19116 19117 19118File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 19119 1912016.7.1 Machine-Independent Predicates 19121------------------------------------- 19122 19123These are the generic predicates available to all back ends. They are 19124defined in 'recog.c'. The first category of predicates allow only 19125constant, or "immediate", operands. 19126 19127 -- Function: immediate_operand 19128 This predicate allows any sort of constant that fits in MODE. It 19129 is an appropriate choice for instructions that take operands that 19130 must be constant. 19131 19132 -- Function: const_int_operand 19133 This predicate allows any 'CONST_INT' expression that fits in MODE. 19134 It is an appropriate choice for an immediate operand that does not 19135 allow a symbol or label. 19136 19137 -- Function: const_double_operand 19138 This predicate accepts any 'CONST_DOUBLE' expression that has 19139 exactly MODE. If MODE is 'VOIDmode', it will also accept 19140 'CONST_INT'. It is intended for immediate floating point 19141 constants. 19142 19143The second category of predicates allow only some kind of machine 19144register. 19145 19146 -- Function: register_operand 19147 This predicate allows any 'REG' or 'SUBREG' expression that is 19148 valid for MODE. It is often suitable for arithmetic instruction 19149 operands on a RISC machine. 19150 19151 -- Function: pmode_register_operand 19152 This is a slight variant on 'register_operand' which works around a 19153 limitation in the machine-description reader. 19154 19155 (match_operand N "pmode_register_operand" CONSTRAINT) 19156 19157 means exactly what 19158 19159 (match_operand:P N "register_operand" CONSTRAINT) 19160 19161 would mean, if the machine-description reader accepted ':P' mode 19162 suffixes. Unfortunately, it cannot, because 'Pmode' is an alias 19163 for some other mode, and might vary with machine-specific options. 19164 *Note Misc::. 19165 19166 -- Function: scratch_operand 19167 This predicate allows hard registers and 'SCRATCH' expressions, but 19168 not pseudo-registers. It is used internally by 'match_scratch'; it 19169 should not be used directly. 19170 19171The third category of predicates allow only some kind of memory 19172reference. 19173 19174 -- Function: memory_operand 19175 This predicate allows any valid reference to a quantity of mode 19176 MODE in memory, as determined by the weak form of 19177 'GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 19178 19179 -- Function: address_operand 19180 This predicate is a little unusual; it allows any operand that is a 19181 valid expression for the _address_ of a quantity of mode MODE, 19182 again determined by the weak form of 'GO_IF_LEGITIMATE_ADDRESS'. 19183 To first order, if '(mem:MODE (EXP))' is acceptable to 19184 'memory_operand', then EXP is acceptable to 'address_operand'. 19185 Note that EXP does not necessarily have the mode MODE. 19186 19187 -- Function: indirect_operand 19188 This is a stricter form of 'memory_operand' which allows only 19189 memory references with a 'general_operand' as the address 19190 expression. New uses of this predicate are discouraged, because 19191 'general_operand' is very permissive, so it's hard to tell what an 19192 'indirect_operand' does or does not allow. If a target has 19193 different requirements for memory operands for different 19194 instructions, it is better to define target-specific predicates 19195 which enforce the hardware's requirements explicitly. 19196 19197 -- Function: push_operand 19198 This predicate allows a memory reference suitable for pushing a 19199 value onto the stack. This will be a 'MEM' which refers to 19200 'stack_pointer_rtx', with a side-effect in its address expression 19201 (*note Incdec::); which one is determined by the 'STACK_PUSH_CODE' 19202 macro (*note Frame Layout::). 19203 19204 -- Function: pop_operand 19205 This predicate allows a memory reference suitable for popping a 19206 value off the stack. Again, this will be a 'MEM' referring to 19207 'stack_pointer_rtx', with a side-effect in its address expression. 19208 However, this time 'STACK_POP_CODE' is expected. 19209 19210The fourth category of predicates allow some combination of the above 19211operands. 19212 19213 -- Function: nonmemory_operand 19214 This predicate allows any immediate or register operand valid for 19215 MODE. 19216 19217 -- Function: nonimmediate_operand 19218 This predicate allows any register or memory operand valid for 19219 MODE. 19220 19221 -- Function: general_operand 19222 This predicate allows any immediate, register, or memory operand 19223 valid for MODE. 19224 19225Finally, there are two generic operator predicates. 19226 19227 -- Function: comparison_operator 19228 This predicate matches any expression which performs an arithmetic 19229 comparison in MODE; that is, 'COMPARISON_P' is true for the 19230 expression code. 19231 19232 -- Function: ordered_comparison_operator 19233 This predicate matches any expression which performs an arithmetic 19234 comparison in MODE and whose expression code is valid for integer 19235 modes; that is, the expression code will be one of 'eq', 'ne', 19236 'lt', 'ltu', 'le', 'leu', 'gt', 'gtu', 'ge', 'geu'. 19237 19238 19239File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 19240 1924116.7.2 Defining Machine-Specific Predicates 19242------------------------------------------- 19243 19244Many machines have requirements for their operands that cannot be 19245expressed precisely using the generic predicates. You can define 19246additional predicates using 'define_predicate' and 19247'define_special_predicate' expressions. These expressions have three 19248operands: 19249 19250 * The name of the predicate, as it will be referred to in 19251 'match_operand' or 'match_operator' expressions. 19252 19253 * An RTL expression which evaluates to true if the predicate allows 19254 the operand OP, false if it does not. This expression can only use 19255 the following RTL codes: 19256 19257 'MATCH_OPERAND' 19258 When written inside a predicate expression, a 'MATCH_OPERAND' 19259 expression evaluates to true if the predicate it names would 19260 allow OP. The operand number and constraint are ignored. Due 19261 to limitations in 'genrecog', you can only refer to generic 19262 predicates and predicates that have already been defined. 19263 19264 'MATCH_CODE' 19265 This expression evaluates to true if OP or a specified 19266 subexpression of OP has one of a given list of RTX codes. 19267 19268 The first operand of this expression is a string constant 19269 containing a comma-separated list of RTX code names (in lower 19270 case). These are the codes for which the 'MATCH_CODE' will be 19271 true. 19272 19273 The second operand is a string constant which indicates what 19274 subexpression of OP to examine. If it is absent or the empty 19275 string, OP itself is examined. Otherwise, the string constant 19276 must be a sequence of digits and/or lowercase letters. Each 19277 character indicates a subexpression to extract from the 19278 current expression; for the first character this is OP, for 19279 the second and subsequent characters it is the result of the 19280 previous character. A digit N extracts 'XEXP (E, N)'; a 19281 letter L extracts 'XVECEXP (E, 0, N)' where N is the 19282 alphabetic ordinal of L (0 for 'a', 1 for 'b', and so on). 19283 The 'MATCH_CODE' then examines the RTX code of the 19284 subexpression extracted by the complete string. It is not 19285 possible to extract components of an 'rtvec' that is not at 19286 position 0 within its RTX object. 19287 19288 'MATCH_TEST' 19289 This expression has one operand, a string constant containing 19290 a C expression. The predicate's arguments, OP and MODE, are 19291 available with those names in the C expression. The 19292 'MATCH_TEST' evaluates to true if the C expression evaluates 19293 to a nonzero value. 'MATCH_TEST' expressions must not have 19294 side effects. 19295 19296 'AND' 19297 'IOR' 19298 'NOT' 19299 'IF_THEN_ELSE' 19300 The basic 'MATCH_' expressions can be combined using these 19301 logical operators, which have the semantics of the C operators 19302 '&&', '||', '!', and '? :' respectively. As in Common Lisp, 19303 you may give an 'AND' or 'IOR' expression an arbitrary number 19304 of arguments; this has exactly the same effect as writing a 19305 chain of two-argument 'AND' or 'IOR' expressions. 19306 19307 * An optional block of C code, which should execute 'return true' if 19308 the predicate is found to match and 'return false' if it does not. 19309 It must not have any side effects. The predicate arguments, OP and 19310 MODE, are available with those names. 19311 19312 If a code block is present in a predicate definition, then the RTL 19313 expression must evaluate to true _and_ the code block must execute 19314 'return true' for the predicate to allow the operand. The RTL 19315 expression is evaluated first; do not re-check anything in the code 19316 block that was checked in the RTL expression. 19317 19318 The program 'genrecog' scans 'define_predicate' and 19319'define_special_predicate' expressions to determine which RTX codes are 19320possibly allowed. You should always make this explicit in the RTL 19321predicate expression, using 'MATCH_OPERAND' and 'MATCH_CODE'. 19322 19323 Here is an example of a simple predicate definition, from the IA64 19324machine description: 19325 19326 ;; True if OP is a 'SYMBOL_REF' which refers to the sdata section. 19327 (define_predicate "small_addr_symbolic_operand" 19328 (and (match_code "symbol_ref") 19329 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 19330 19331And here is another, showing the use of the C block. 19332 19333 ;; True if OP is a register operand that is (or could be) a GR reg. 19334 (define_predicate "gr_register_operand" 19335 (match_operand 0 "register_operand") 19336 { 19337 unsigned int regno; 19338 if (GET_CODE (op) == SUBREG) 19339 op = SUBREG_REG (op); 19340 19341 regno = REGNO (op); 19342 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 19343 }) 19344 19345 Predicates written with 'define_predicate' automatically include a test 19346that MODE is 'VOIDmode', or OP has the same mode as MODE, or OP is a 19347'CONST_INT' or 'CONST_DOUBLE'. They do _not_ check specifically for 19348integer 'CONST_DOUBLE', nor do they test that the value of either kind 19349of constant fits in the requested mode. This is because target-specific 19350predicates that take constants usually have to do more stringent value 19351checks anyway. If you need the exact same treatment of 'CONST_INT' or 19352'CONST_DOUBLE' that the generic predicates provide, use a 19353'MATCH_OPERAND' subexpression to call 'const_int_operand', 19354'const_double_operand', or 'immediate_operand'. 19355 19356 Predicates written with 'define_special_predicate' do not get any 19357automatic mode checks, and are treated as having special mode handling 19358by 'genrecog'. 19359 19360 The program 'genpreds' is responsible for generating code to test 19361predicates. It also writes a header file containing function 19362declarations for all machine-specific predicates. It is not necessary 19363to declare these predicates in 'CPU-protos.h'. 19364 19365 19366File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 19367 1936816.8 Operand Constraints 19369======================== 19370 19371Each 'match_operand' in an instruction pattern can specify constraints 19372for the operands allowed. The constraints allow you to fine-tune 19373matching within the set of operands allowed by the predicate. 19374 19375 Constraints can say whether an operand may be in a register, and which 19376kinds of register; whether the operand can be a memory reference, and 19377which kinds of address; whether the operand may be an immediate 19378constant, and which possible values it may have. Constraints can also 19379require two operands to match. Side-effects aren't allowed in operands 19380of inline 'asm', unless '<' or '>' constraints are used, because there 19381is no guarantee that the side-effects will happen exactly once in an 19382instruction that can update the addressing register. 19383 19384* Menu: 19385 19386* Simple Constraints:: Basic use of constraints. 19387* Multi-Alternative:: When an insn has two alternative constraint-patterns. 19388* Class Preferences:: Constraints guide which hard register to put things in. 19389* Modifiers:: More precise control over effects of constraints. 19390* Machine Constraints:: Existing constraints for some particular machines. 19391* Disable Insn Alternatives:: Disable insn alternatives using attributes. 19392* Define Constraints:: How to define machine-specific constraints. 19393* C Constraint Interface:: How to test constraints from C code. 19394 19395 19396File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 19397 1939816.8.1 Simple Constraints 19399------------------------- 19400 19401The simplest kind of constraint is a string full of letters, each of 19402which describes one kind of operand that is permitted. Here are the 19403letters that are allowed: 19404 19405whitespace 19406 Whitespace characters are ignored and can be inserted at any 19407 position except the first. This enables each alternative for 19408 different operands to be visually aligned in the machine 19409 description even if they have different number of constraints and 19410 modifiers. 19411 19412'm' 19413 A memory operand is allowed, with any kind of address that the 19414 machine supports in general. Note that the letter used for the 19415 general memory constraint can be re-defined by a back end using the 19416 'TARGET_MEM_CONSTRAINT' macro. 19417 19418'o' 19419 A memory operand is allowed, but only if the address is 19420 "offsettable". This means that adding a small integer (actually, 19421 the width in bytes of the operand, as determined by its machine 19422 mode) may be added to the address and the result is also a valid 19423 memory address. 19424 19425 For example, an address which is constant is offsettable; so is an 19426 address that is the sum of a register and a constant (as long as a 19427 slightly larger constant is also within the range of 19428 address-offsets supported by the machine); but an autoincrement or 19429 autodecrement address is not offsettable. More complicated 19430 indirect/indexed addresses may or may not be offsettable depending 19431 on the other addressing modes that the machine supports. 19432 19433 Note that in an output operand which can be matched by another 19434 operand, the constraint letter 'o' is valid only when accompanied 19435 by both '<' (if the target machine has predecrement addressing) and 19436 '>' (if the target machine has preincrement addressing). 19437 19438'V' 19439 A memory operand that is not offsettable. In other words, anything 19440 that would fit the 'm' constraint but not the 'o' constraint. 19441 19442'<' 19443 A memory operand with autodecrement addressing (either predecrement 19444 or postdecrement) is allowed. In inline 'asm' this constraint is 19445 only allowed if the operand is used exactly once in an instruction 19446 that can handle the side-effects. Not using an operand with '<' in 19447 constraint string in the inline 'asm' pattern at all or using it in 19448 multiple instructions isn't valid, because the side-effects 19449 wouldn't be performed or would be performed more than once. 19450 Furthermore, on some targets the operand with '<' in constraint 19451 string must be accompanied by special instruction suffixes like 19452 '%U0' instruction suffix on PowerPC or '%P0' on IA-64. 19453 19454'>' 19455 A memory operand with autoincrement addressing (either preincrement 19456 or postincrement) is allowed. In inline 'asm' the same 19457 restrictions as for '<' apply. 19458 19459'r' 19460 A register operand is allowed provided that it is in a general 19461 register. 19462 19463'i' 19464 An immediate integer operand (one with constant value) is allowed. 19465 This includes symbolic constants whose values will be known only at 19466 assembly time or later. 19467 19468'n' 19469 An immediate integer operand with a known numeric value is allowed. 19470 Many systems cannot support assembly-time constants for operands 19471 less than a word wide. Constraints for these operands should use 19472 'n' rather than 'i'. 19473 19474'I', 'J', 'K', ... 'P' 19475 Other letters in the range 'I' through 'P' may be defined in a 19476 machine-dependent fashion to permit immediate integer operands with 19477 explicit integer values in specified ranges. For example, on the 19478 68000, 'I' is defined to stand for the range of values 1 to 8. 19479 This is the range permitted as a shift count in the shift 19480 instructions. 19481 19482'E' 19483 An immediate floating operand (expression code 'const_double') is 19484 allowed, but only if the target floating point format is the same 19485 as that of the host machine (on which the compiler is running). 19486 19487'F' 19488 An immediate floating operand (expression code 'const_double' or 19489 'const_vector') is allowed. 19490 19491'G', 'H' 19492 'G' and 'H' may be defined in a machine-dependent fashion to permit 19493 immediate floating operands in particular ranges of values. 19494 19495's' 19496 An immediate integer operand whose value is not an explicit integer 19497 is allowed. 19498 19499 This might appear strange; if an insn allows a constant operand 19500 with a value not known at compile time, it certainly must allow any 19501 known value. So why use 's' instead of 'i'? Sometimes it allows 19502 better code to be generated. 19503 19504 For example, on the 68000 in a fullword instruction it is possible 19505 to use an immediate operand; but if the immediate value is between 19506 -128 and 127, better code results from loading the value into a 19507 register and using the register. This is because the load into the 19508 register can be done with a 'moveq' instruction. We arrange for 19509 this to happen by defining the letter 'K' to mean "any integer 19510 outside the range -128 to 127", and then specifying 'Ks' in the 19511 operand constraints. 19512 19513'g' 19514 Any register, memory or immediate integer operand is allowed, 19515 except for registers that are not general registers. 19516 19517'X' 19518 Any operand whatsoever is allowed, even if it does not satisfy 19519 'general_operand'. This is normally used in the constraint of a 19520 'match_scratch' when certain alternatives will not actually require 19521 a scratch register. 19522 19523'0', '1', '2', ... '9' 19524 An operand that matches the specified operand number is allowed. 19525 If a digit is used together with letters within the same 19526 alternative, the digit should come last. 19527 19528 This number is allowed to be more than a single digit. If multiple 19529 digits are encountered consecutively, they are interpreted as a 19530 single decimal integer. There is scant chance for ambiguity, since 19531 to-date it has never been desirable that '10' be interpreted as 19532 matching either operand 1 _or_ operand 0. Should this be desired, 19533 one can use multiple alternatives instead. 19534 19535 This is called a "matching constraint" and what it really means is 19536 that the assembler has only a single operand that fills two roles 19537 considered separate in the RTL insn. For example, an add insn has 19538 two input operands and one output operand in the RTL, but on most 19539 CISC machines an add instruction really has only two operands, one 19540 of them an input-output operand: 19541 19542 addl #35,r12 19543 19544 Matching constraints are used in these circumstances. More 19545 precisely, the two operands that match must include one input-only 19546 operand and one output-only operand. Moreover, the digit must be a 19547 smaller number than the number of the operand that uses it in the 19548 constraint. 19549 19550 For operands to match in a particular case usually means that they 19551 are identical-looking RTL expressions. But in a few special cases 19552 specific kinds of dissimilarity are allowed. For example, '*x' as 19553 an input operand will match '*x++' as an output operand. For 19554 proper results in such cases, the output template should always use 19555 the output-operand's number when printing the operand. 19556 19557'p' 19558 An operand that is a valid memory address is allowed. This is for 19559 "load address" and "push address" instructions. 19560 19561 'p' in the constraint must be accompanied by 'address_operand' as 19562 the predicate in the 'match_operand'. This predicate interprets 19563 the mode specified in the 'match_operand' as the mode of the memory 19564 reference for which the address would be valid. 19565 19566OTHER-LETTERS 19567 Other letters can be defined in machine-dependent fashion to stand 19568 for particular classes of registers or other arbitrary operand 19569 types. 'd', 'a' and 'f' are defined on the 68000/68020 to stand 19570 for data, address and floating point registers. 19571 19572 In order to have valid assembler code, each operand must satisfy its 19573constraint. But a failure to do so does not prevent the pattern from 19574applying to an insn. Instead, it directs the compiler to modify the 19575code so that the constraint will be satisfied. Usually this is done by 19576copying an operand into a register. 19577 19578 Contrast, therefore, the two instruction patterns that follow: 19579 19580 (define_insn "" 19581 [(set (match_operand:SI 0 "general_operand" "=r") 19582 (plus:SI (match_dup 0) 19583 (match_operand:SI 1 "general_operand" "r")))] 19584 "" 19585 "...") 19586 19587which has two operands, one of which must appear in two places, and 19588 19589 (define_insn "" 19590 [(set (match_operand:SI 0 "general_operand" "=r") 19591 (plus:SI (match_operand:SI 1 "general_operand" "0") 19592 (match_operand:SI 2 "general_operand" "r")))] 19593 "" 19594 "...") 19595 19596which has three operands, two of which are required by a constraint to 19597be identical. If we are considering an insn of the form 19598 19599 (insn N PREV NEXT 19600 (set (reg:SI 3) 19601 (plus:SI (reg:SI 6) (reg:SI 109))) 19602 ...) 19603 19604the first pattern would not apply at all, because this insn does not 19605contain two identical subexpressions in the right place. The pattern 19606would say, "That does not look like an add instruction; try other 19607patterns". The second pattern would say, "Yes, that's an add 19608instruction, but there is something wrong with it". It would direct the 19609reload pass of the compiler to generate additional insns to make the 19610constraint true. The results might look like this: 19611 19612 (insn N2 PREV N 19613 (set (reg:SI 3) (reg:SI 6)) 19614 ...) 19615 19616 (insn N N2 NEXT 19617 (set (reg:SI 3) 19618 (plus:SI (reg:SI 3) (reg:SI 109))) 19619 ...) 19620 19621 It is up to you to make sure that each operand, in each pattern, has 19622constraints that can handle any RTL expression that could be present for 19623that operand. (When multiple alternatives are in use, each pattern 19624must, for each possible combination of operand expressions, have at 19625least one alternative which can handle that combination of operands.) 19626The constraints don't need to _allow_ any possible operand--when this is 19627the case, they do not constrain--but they must at least point the way to 19628reloading any possible operand so that it will fit. 19629 19630 * If the constraint accepts whatever operands the predicate permits, 19631 there is no problem: reloading is never necessary for this operand. 19632 19633 For example, an operand whose constraints permit everything except 19634 registers is safe provided its predicate rejects registers. 19635 19636 An operand whose predicate accepts only constant values is safe 19637 provided its constraints include the letter 'i'. If any possible 19638 constant value is accepted, then nothing less than 'i' will do; if 19639 the predicate is more selective, then the constraints may also be 19640 more selective. 19641 19642 * Any operand expression can be reloaded by copying it into a 19643 register. So if an operand's constraints allow some kind of 19644 register, it is certain to be safe. It need not permit all classes 19645 of registers; the compiler knows how to copy a register into 19646 another register of the proper class in order to make an 19647 instruction valid. 19648 19649 * A nonoffsettable memory reference can be reloaded by copying the 19650 address into a register. So if the constraint uses the letter 'o', 19651 all memory references are taken care of. 19652 19653 * A constant operand can be reloaded by allocating space in memory to 19654 hold it as preinitialized data. Then the memory reference can be 19655 used in place of the constant. So if the constraint uses the 19656 letters 'o' or 'm', constant operands are not a problem. 19657 19658 * If the constraint permits a constant and a pseudo register used in 19659 an insn was not allocated to a hard register and is equivalent to a 19660 constant, the register will be replaced with the constant. If the 19661 predicate does not permit a constant and the insn is re-recognized 19662 for some reason, the compiler will crash. Thus the predicate must 19663 always recognize any objects allowed by the constraint. 19664 19665 If the operand's predicate can recognize registers, but the constraint 19666does not permit them, it can make the compiler crash. When this operand 19667happens to be a register, the reload pass will be stymied, because it 19668does not know how to copy a register temporarily into memory. 19669 19670 If the predicate accepts a unary operator, the constraint applies to 19671the operand. For example, the MIPS processor at ISA level 3 supports an 19672instruction which adds two registers in 'SImode' to produce a 'DImode' 19673result, but only if the registers are correctly sign extended. This 19674predicate for the input operands accepts a 'sign_extend' of an 'SImode' 19675register. Write the constraint to indicate the type of register that is 19676required for the operand of the 'sign_extend'. 19677 19678 19679File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 19680 1968116.8.2 Multiple Alternative Constraints 19682--------------------------------------- 19683 19684Sometimes a single instruction has multiple alternative sets of possible 19685operands. For example, on the 68000, a logical-or instruction can 19686combine register or an immediate value into memory, or it can combine 19687any kind of operand into a register; but it cannot combine one memory 19688location into another. 19689 19690 These constraints are represented as multiple alternatives. An 19691alternative can be described by a series of letters for each operand. 19692The overall constraint for an operand is made from the letters for this 19693operand from the first alternative, a comma, the letters for this 19694operand from the second alternative, a comma, and so on until the last 19695alternative. Here is how it is done for fullword logical-or on the 1969668000: 19697 19698 (define_insn "iorsi3" 19699 [(set (match_operand:SI 0 "general_operand" "=m,d") 19700 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 19701 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 19702 ...) 19703 19704 The first alternative has 'm' (memory) for operand 0, '0' for operand 1 19705(meaning it must match operand 0), and 'dKs' for operand 2. The second 19706alternative has 'd' (data register) for operand 0, '0' for operand 1, 19707and 'dmKs' for operand 2. The '=' and '%' in the constraints apply to 19708all the alternatives; their meaning is explained in the next section 19709(*note Class Preferences::). 19710 19711 If all the operands fit any one alternative, the instruction is valid. 19712Otherwise, for each alternative, the compiler counts how many 19713instructions must be added to copy the operands so that that alternative 19714applies. The alternative requiring the least copying is chosen. If two 19715alternatives need the same amount of copying, the one that comes first 19716is chosen. These choices can be altered with the '?' and '!' 19717characters: 19718 19719'?' 19720 Disparage slightly the alternative that the '?' appears in, as a 19721 choice when no alternative applies exactly. The compiler regards 19722 this alternative as one unit more costly for each '?' that appears 19723 in it. 19724 19725'!' 19726 Disparage severely the alternative that the '!' appears in. This 19727 alternative can still be used if it fits without reloading, but if 19728 reloading is needed, some other alternative will be used. 19729 19730'^' 19731 This constraint is analogous to '?' but it disparages slightly the 19732 alternative only if the operand with the '^' needs a reload. 19733 19734'$' 19735 This constraint is analogous to '!' but it disparages severely the 19736 alternative only if the operand with the '$' needs a reload. 19737 19738 When an insn pattern has multiple alternatives in its constraints, 19739often the appearance of the assembler code is determined mostly by which 19740alternative was matched. When this is so, the C code for writing the 19741assembler code can use the variable 'which_alternative', which is the 19742ordinal number of the alternative that was actually satisfied (0 for the 19743first, 1 for the second alternative, etc.). *Note Output Statement::. 19744 19745 19746File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 19747 1974816.8.3 Register Class Preferences 19749--------------------------------- 19750 19751The operand constraints have another function: they enable the compiler 19752to decide which kind of hardware register a pseudo register is best 19753allocated to. The compiler examines the constraints that apply to the 19754insns that use the pseudo register, looking for the machine-dependent 19755letters such as 'd' and 'a' that specify classes of registers. The 19756pseudo register is put in whichever class gets the most "votes". The 19757constraint letters 'g' and 'r' also vote: they vote in favor of a 19758general register. The machine description says which registers are 19759considered general. 19760 19761 Of course, on some machines all registers are equivalent, and no 19762register classes are defined. Then none of this complexity is relevant. 19763 19764 19765File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 19766 1976716.8.4 Constraint Modifier Characters 19768------------------------------------- 19769 19770Here are constraint modifier characters. 19771 19772'=' 19773 Means that this operand is written to by this instruction: the 19774 previous value is discarded and replaced by new data. 19775 19776'+' 19777 Means that this operand is both read and written by the 19778 instruction. 19779 19780 When the compiler fixes up the operands to satisfy the constraints, 19781 it needs to know which operands are read by the instruction and 19782 which are written by it. '=' identifies an operand which is only 19783 written; '+' identifies an operand that is both read and written; 19784 all other operands are assumed to only be read. 19785 19786 If you specify '=' or '+' in a constraint, you put it in the first 19787 character of the constraint string. 19788 19789'&' 19790 Means (in a particular alternative) that this operand is an 19791 "earlyclobber" operand, which is written before the instruction is 19792 finished using the input operands. Therefore, this operand may not 19793 lie in a register that is read by the instruction or as part of any 19794 memory address. 19795 19796 '&' applies only to the alternative in which it is written. In 19797 constraints with multiple alternatives, sometimes one alternative 19798 requires '&' while others do not. See, for example, the 'movdf' 19799 insn of the 68000. 19800 19801 A operand which is read by the instruction can be tied to an 19802 earlyclobber operand if its only use as an input occurs before the 19803 early result is written. Adding alternatives of this form often 19804 allows GCC to produce better code when only some of the read 19805 operands can be affected by the earlyclobber. See, for example, 19806 the 'mulsi3' insn of the ARM. 19807 19808 Furthermore, if the "earlyclobber" operand is also a read/write 19809 operand, then that operand is written only after it's used. 19810 19811 '&' does not obviate the need to write '=' or '+'. As 19812 "earlyclobber" operands are always written, a read-only 19813 "earlyclobber" operand is ill-formed and will be rejected by the 19814 compiler. 19815 19816'%' 19817 Declares the instruction to be commutative for this operand and the 19818 following operand. This means that the compiler may interchange 19819 the two operands if that is the cheapest way to make all operands 19820 fit the constraints. '%' applies to all alternatives and must 19821 appear as the first character in the constraint. Only read-only 19822 operands can use '%'. 19823 19824 This is often used in patterns for addition instructions that 19825 really have only two operands: the result must go in one of the 19826 arguments. Here for example, is how the 68000 halfword-add 19827 instruction is defined: 19828 19829 (define_insn "addhi3" 19830 [(set (match_operand:HI 0 "general_operand" "=m,r") 19831 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 19832 (match_operand:HI 2 "general_operand" "di,g")))] 19833 ...) 19834 GCC can only handle one commutative pair in an asm; if you use 19835 more, the compiler may fail. Note that you need not use the 19836 modifier if the two alternatives are strictly identical; this would 19837 only waste time in the reload pass. The modifier is not 19838 operational after register allocation, so the result of 19839 'define_peephole2' and 'define_split's performed after reload 19840 cannot rely on '%' to make the intended insn match. 19841 19842'#' 19843 Says that all following characters, up to the next comma, are to be 19844 ignored as a constraint. They are significant only for choosing 19845 register preferences. 19846 19847'*' 19848 Says that the following character should be ignored when choosing 19849 register preferences. '*' has no effect on the meaning of the 19850 constraint as a constraint, and no effect on reloading. For LRA 19851 '*' additionally disparages slightly the alternative if the 19852 following character matches the operand. 19853 19854 Here is an example: the 68000 has an instruction to sign-extend a 19855 halfword in a data register, and can also sign-extend a value by 19856 copying it into an address register. While either kind of register 19857 is acceptable, the constraints on an address-register destination 19858 are less strict, so it is best if register allocation makes an 19859 address register its goal. Therefore, '*' is used so that the 'd' 19860 constraint letter (for data register) is ignored when computing 19861 register preferences. 19862 19863 (define_insn "extendhisi2" 19864 [(set (match_operand:SI 0 "general_operand" "=*d,a") 19865 (sign_extend:SI 19866 (match_operand:HI 1 "general_operand" "0,g")))] 19867 ...) 19868 19869 19870File: gccint.info, Node: Machine Constraints, Next: Disable Insn Alternatives, Prev: Modifiers, Up: Constraints 19871 1987216.8.5 Constraints for Particular Machines 19873------------------------------------------ 19874 19875Whenever possible, you should use the general-purpose constraint letters 19876in 'asm' arguments, since they will convey meaning more readily to 19877people reading your code. Failing that, use the constraint letters that 19878usually have very similar meanings across architectures. The most 19879commonly used constraints are 'm' and 'r' (for memory and 19880general-purpose registers respectively; *note Simple Constraints::), and 19881'I', usually the letter indicating the most common immediate-constant 19882format. 19883 19884 Each architecture defines additional constraints. These constraints 19885are used by the compiler itself for instruction generation, as well as 19886for 'asm' statements; therefore, some of the constraints are not 19887particularly useful for 'asm'. Here is a summary of some of the 19888machine-dependent constraints available on some particular machines; it 19889includes both constraints that are useful for 'asm' and constraints that 19890aren't. The compiler source file mentioned in the table heading for 19891each architecture is the definitive reference for the meanings of that 19892architecture's constraints. 19893 19894_AArch64 family--'config/aarch64/constraints.md'_ 19895 'k' 19896 The stack pointer register ('SP') 19897 19898 'w' 19899 Floating point or SIMD vector register 19900 19901 'I' 19902 Integer constant that is valid as an immediate operand in an 19903 'ADD' instruction 19904 19905 'J' 19906 Integer constant that is valid as an immediate operand in a 19907 'SUB' instruction (once negated) 19908 19909 'K' 19910 Integer constant that can be used with a 32-bit logical 19911 instruction 19912 19913 'L' 19914 Integer constant that can be used with a 64-bit logical 19915 instruction 19916 19917 'M' 19918 Integer constant that is valid as an immediate operand in a 19919 32-bit 'MOV' pseudo instruction. The 'MOV' may be assembled 19920 to one of several different machine instructions depending on 19921 the value 19922 19923 'N' 19924 Integer constant that is valid as an immediate operand in a 19925 64-bit 'MOV' pseudo instruction 19926 19927 'S' 19928 An absolute symbolic address or a label reference 19929 19930 'Y' 19931 Floating point constant zero 19932 19933 'Z' 19934 Integer constant zero 19935 19936 'Ush' 19937 The high part (bits 12 and upwards) of the pc-relative address 19938 of a symbol within 4GB of the instruction 19939 19940 'Q' 19941 A memory address which uses a single base register with no 19942 offset 19943 19944 'Ump' 19945 A memory address suitable for a load/store pair instruction in 19946 SI, DI, SF and DF modes 19947 19948_ARC --'config/arc/constraints.md'_ 19949 'q' 19950 Registers usable in ARCompact 16-bit instructions: 'r0'-'r3', 19951 'r12'-'r15'. This constraint can only match when the '-mq' 19952 option is in effect. 19953 19954 'e' 19955 Registers usable as base-regs of memory addresses in ARCompact 19956 16-bit memory instructions: 'r0'-'r3', 'r12'-'r15', 'sp'. 19957 This constraint can only match when the '-mq' option is in 19958 effect. 19959 'D' 19960 ARC FPX (dpfp) 64-bit registers. 'D0', 'D1'. 19961 19962 'I' 19963 A signed 12-bit integer constant. 19964 19965 'Cal' 19966 constant for arithmetic/logical operations. This might be any 19967 constant that can be put into a long immediate by the assmbler 19968 or linker without involving a PIC relocation. 19969 19970 'K' 19971 A 3-bit unsigned integer constant. 19972 19973 'L' 19974 A 6-bit unsigned integer constant. 19975 19976 'CnL' 19977 One's complement of a 6-bit unsigned integer constant. 19978 19979 'CmL' 19980 Two's complement of a 6-bit unsigned integer constant. 19981 19982 'M' 19983 A 5-bit unsigned integer constant. 19984 19985 'O' 19986 A 7-bit unsigned integer constant. 19987 19988 'P' 19989 A 8-bit unsigned integer constant. 19990 19991 'H' 19992 Any const_double value. 19993 19994_ARM family--'config/arm/constraints.md'_ 19995 19996 'h' 19997 In Thumb state, the core registers 'r8'-'r15'. 19998 19999 'k' 20000 The stack pointer register. 20001 20002 'l' 20003 In Thumb State the core registers 'r0'-'r7'. In ARM state 20004 this is an alias for the 'r' constraint. 20005 20006 't' 20007 VFP floating-point registers 's0'-'s31'. Used for 32 bit 20008 values. 20009 20010 'w' 20011 VFP floating-point registers 'd0'-'d31' and the appropriate 20012 subset 'd0'-'d15' based on command line options. Used for 64 20013 bit values only. Not valid for Thumb1. 20014 20015 'y' 20016 The iWMMX co-processor registers. 20017 20018 'z' 20019 The iWMMX GR registers. 20020 20021 'G' 20022 The floating-point constant 0.0 20023 20024 'I' 20025 Integer that is valid as an immediate operand in a data 20026 processing instruction. That is, an integer in the range 0 to 20027 255 rotated by a multiple of 2 20028 20029 'J' 20030 Integer in the range -4095 to 4095 20031 20032 'K' 20033 Integer that satisfies constraint 'I' when inverted (ones 20034 complement) 20035 20036 'L' 20037 Integer that satisfies constraint 'I' when negated (twos 20038 complement) 20039 20040 'M' 20041 Integer in the range 0 to 32 20042 20043 'Q' 20044 A memory reference where the exact address is in a single 20045 register (''m'' is preferable for 'asm' statements) 20046 20047 'R' 20048 An item in the constant pool 20049 20050 'S' 20051 A symbol in the text segment of the current file 20052 20053 'Uv' 20054 A memory reference suitable for VFP load/store insns 20055 (reg+constant offset) 20056 20057 'Uy' 20058 A memory reference suitable for iWMMXt load/store 20059 instructions. 20060 20061 'Uq' 20062 A memory reference suitable for the ARMv4 ldrsb instruction. 20063 20064_AVR family--'config/avr/constraints.md'_ 20065 'l' 20066 Registers from r0 to r15 20067 20068 'a' 20069 Registers from r16 to r23 20070 20071 'd' 20072 Registers from r16 to r31 20073 20074 'w' 20075 Registers from r24 to r31. These registers can be used in 20076 'adiw' command 20077 20078 'e' 20079 Pointer register (r26-r31) 20080 20081 'b' 20082 Base pointer register (r28-r31) 20083 20084 'q' 20085 Stack pointer register (SPH:SPL) 20086 20087 't' 20088 Temporary register r0 20089 20090 'x' 20091 Register pair X (r27:r26) 20092 20093 'y' 20094 Register pair Y (r29:r28) 20095 20096 'z' 20097 Register pair Z (r31:r30) 20098 20099 'I' 20100 Constant greater than -1, less than 64 20101 20102 'J' 20103 Constant greater than -64, less than 1 20104 20105 'K' 20106 Constant integer 2 20107 20108 'L' 20109 Constant integer 0 20110 20111 'M' 20112 Constant that fits in 8 bits 20113 20114 'N' 20115 Constant integer -1 20116 20117 'O' 20118 Constant integer 8, 16, or 24 20119 20120 'P' 20121 Constant integer 1 20122 20123 'G' 20124 A floating point constant 0.0 20125 20126 'Q' 20127 A memory address based on Y or Z pointer with displacement. 20128 20129_Blackfin family--'config/bfin/constraints.md'_ 20130 'a' 20131 P register 20132 20133 'd' 20134 D register 20135 20136 'z' 20137 A call clobbered P register. 20138 20139 'qN' 20140 A single register. If N is in the range 0 to 7, the 20141 corresponding D register. If it is 'A', then the register P0. 20142 20143 'D' 20144 Even-numbered D register 20145 20146 'W' 20147 Odd-numbered D register 20148 20149 'e' 20150 Accumulator register. 20151 20152 'A' 20153 Even-numbered accumulator register. 20154 20155 'B' 20156 Odd-numbered accumulator register. 20157 20158 'b' 20159 I register 20160 20161 'v' 20162 B register 20163 20164 'f' 20165 M register 20166 20167 'c' 20168 Registers used for circular buffering, i.e. I, B, or L 20169 registers. 20170 20171 'C' 20172 The CC register. 20173 20174 't' 20175 LT0 or LT1. 20176 20177 'k' 20178 LC0 or LC1. 20179 20180 'u' 20181 LB0 or LB1. 20182 20183 'x' 20184 Any D, P, B, M, I or L register. 20185 20186 'y' 20187 Additional registers typically used only in prologues and 20188 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 20189 USP. 20190 20191 'w' 20192 Any register except accumulators or CC. 20193 20194 'Ksh' 20195 Signed 16 bit integer (in the range -32768 to 32767) 20196 20197 'Kuh' 20198 Unsigned 16 bit integer (in the range 0 to 65535) 20199 20200 'Ks7' 20201 Signed 7 bit integer (in the range -64 to 63) 20202 20203 'Ku7' 20204 Unsigned 7 bit integer (in the range 0 to 127) 20205 20206 'Ku5' 20207 Unsigned 5 bit integer (in the range 0 to 31) 20208 20209 'Ks4' 20210 Signed 4 bit integer (in the range -8 to 7) 20211 20212 'Ks3' 20213 Signed 3 bit integer (in the range -3 to 4) 20214 20215 'Ku3' 20216 Unsigned 3 bit integer (in the range 0 to 7) 20217 20218 'PN' 20219 Constant N, where N is a single-digit constant in the range 0 20220 to 4. 20221 20222 'PA' 20223 An integer equal to one of the MACFLAG_XXX constants that is 20224 suitable for use with either accumulator. 20225 20226 'PB' 20227 An integer equal to one of the MACFLAG_XXX constants that is 20228 suitable for use only with accumulator A1. 20229 20230 'M1' 20231 Constant 255. 20232 20233 'M2' 20234 Constant 65535. 20235 20236 'J' 20237 An integer constant with exactly a single bit set. 20238 20239 'L' 20240 An integer constant with all bits set except exactly one. 20241 20242 'H' 20243 20244 'Q' 20245 Any SYMBOL_REF. 20246 20247_CR16 Architecture--'config/cr16/cr16.h'_ 20248 20249 'b' 20250 Registers from r0 to r14 (registers without stack pointer) 20251 20252 't' 20253 Register from r0 to r11 (all 16-bit registers) 20254 20255 'p' 20256 Register from r12 to r15 (all 32-bit registers) 20257 20258 'I' 20259 Signed constant that fits in 4 bits 20260 20261 'J' 20262 Signed constant that fits in 5 bits 20263 20264 'K' 20265 Signed constant that fits in 6 bits 20266 20267 'L' 20268 Unsigned constant that fits in 4 bits 20269 20270 'M' 20271 Signed constant that fits in 32 bits 20272 20273 'N' 20274 Check for 64 bits wide constants for add/sub instructions 20275 20276 'G' 20277 Floating point constant that is legal for store immediate 20278 20279_Epiphany--'config/epiphany/constraints.md'_ 20280 'U16' 20281 An unsigned 16-bit constant. 20282 20283 'K' 20284 An unsigned 5-bit constant. 20285 20286 'L' 20287 A signed 11-bit constant. 20288 20289 'Cm1' 20290 A signed 11-bit constant added to -1. Can only match when the 20291 '-m1reg-REG' option is active. 20292 20293 'Cl1' 20294 Left-shift of -1, i.e., a bit mask with a block of leading 20295 ones, the rest being a block of trailing zeroes. Can only 20296 match when the '-m1reg-REG' option is active. 20297 20298 'Cr1' 20299 Right-shift of -1, i.e., a bit mask with a trailing block of 20300 ones, the rest being zeroes. Or to put it another way, one 20301 less than a power of two. Can only match when the 20302 '-m1reg-REG' option is active. 20303 20304 'Cal' 20305 Constant for arithmetic/logical operations. This is like 'i', 20306 except that for position independent code, no symbols / 20307 expressions needing relocations are allowed. 20308 20309 'Csy' 20310 Symbolic constant for call/jump instruction. 20311 20312 'Rcs' 20313 The register class usable in short insns. This is a register 20314 class constraint, and can thus drive register allocation. 20315 This constraint won't match unless '-mprefer-short-insn-regs' 20316 is in effect. 20317 20318 'Rsc' 20319 The the register class of registers that can be used to hold a 20320 sibcall call address. I.e., a caller-saved register. 20321 20322 'Rct' 20323 Core control register class. 20324 20325 'Rgs' 20326 The register group usable in short insns. This constraint 20327 does not use a register class, so that it only passively 20328 matches suitable registers, and doesn't drive register 20329 allocation. 20330 20331 'Car' 20332 Constant suitable for the addsi3_r pattern. This is a valid 20333 offset For byte, halfword, or word addressing. 20334 20335 'Rra' 20336 Matches the return address if it can be replaced with the link 20337 register. 20338 20339 'Rcc' 20340 Matches the integer condition code register. 20341 20342 'Sra' 20343 Matches the return address if it is in a stack slot. 20344 20345 'Cfm' 20346 Matches control register values to switch fp mode, which are 20347 encapsulated in 'UNSPEC_FP_MODE'. 20348 20349_FRV--'config/frv/frv.h'_ 20350 'a' 20351 Register in the class 'ACC_REGS' ('acc0' to 'acc7'). 20352 20353 'b' 20354 Register in the class 'EVEN_ACC_REGS' ('acc0' to 'acc7'). 20355 20356 'c' 20357 Register in the class 'CC_REGS' ('fcc0' to 'fcc3' and 'icc0' 20358 to 'icc3'). 20359 20360 'd' 20361 Register in the class 'GPR_REGS' ('gr0' to 'gr63'). 20362 20363 'e' 20364 Register in the class 'EVEN_REGS' ('gr0' to 'gr63'). Odd 20365 registers are excluded not in the class but through the use of 20366 a machine mode larger than 4 bytes. 20367 20368 'f' 20369 Register in the class 'FPR_REGS' ('fr0' to 'fr63'). 20370 20371 'h' 20372 Register in the class 'FEVEN_REGS' ('fr0' to 'fr63'). Odd 20373 registers are excluded not in the class but through the use of 20374 a machine mode larger than 4 bytes. 20375 20376 'l' 20377 Register in the class 'LR_REG' (the 'lr' register). 20378 20379 'q' 20380 Register in the class 'QUAD_REGS' ('gr2' to 'gr63'). Register 20381 numbers not divisible by 4 are excluded not in the class but 20382 through the use of a machine mode larger than 8 bytes. 20383 20384 't' 20385 Register in the class 'ICC_REGS' ('icc0' to 'icc3'). 20386 20387 'u' 20388 Register in the class 'FCC_REGS' ('fcc0' to 'fcc3'). 20389 20390 'v' 20391 Register in the class 'ICR_REGS' ('cc4' to 'cc7'). 20392 20393 'w' 20394 Register in the class 'FCR_REGS' ('cc0' to 'cc3'). 20395 20396 'x' 20397 Register in the class 'QUAD_FPR_REGS' ('fr0' to 'fr63'). 20398 Register numbers not divisible by 4 are excluded not in the 20399 class but through the use of a machine mode larger than 8 20400 bytes. 20401 20402 'z' 20403 Register in the class 'SPR_REGS' ('lcr' and 'lr'). 20404 20405 'A' 20406 Register in the class 'QUAD_ACC_REGS' ('acc0' to 'acc7'). 20407 20408 'B' 20409 Register in the class 'ACCG_REGS' ('accg0' to 'accg7'). 20410 20411 'C' 20412 Register in the class 'CR_REGS' ('cc0' to 'cc7'). 20413 20414 'G' 20415 Floating point constant zero 20416 20417 'I' 20418 6-bit signed integer constant 20419 20420 'J' 20421 10-bit signed integer constant 20422 20423 'L' 20424 16-bit signed integer constant 20425 20426 'M' 20427 16-bit unsigned integer constant 20428 20429 'N' 20430 12-bit signed integer constant that is negative--i.e. in the 20431 range of -2048 to -1 20432 20433 'O' 20434 Constant zero 20435 20436 'P' 20437 12-bit signed integer constant that is greater than zero--i.e. 20438 in the range of 1 to 2047. 20439 20440_Hewlett-Packard PA-RISC--'config/pa/pa.h'_ 20441 'a' 20442 General register 1 20443 20444 'f' 20445 Floating point register 20446 20447 'q' 20448 Shift amount register 20449 20450 'x' 20451 Floating point register (deprecated) 20452 20453 'y' 20454 Upper floating point register (32-bit), floating point 20455 register (64-bit) 20456 20457 'Z' 20458 Any register 20459 20460 'I' 20461 Signed 11-bit integer constant 20462 20463 'J' 20464 Signed 14-bit integer constant 20465 20466 'K' 20467 Integer constant that can be deposited with a 'zdepi' 20468 instruction 20469 20470 'L' 20471 Signed 5-bit integer constant 20472 20473 'M' 20474 Integer constant 0 20475 20476 'N' 20477 Integer constant that can be loaded with a 'ldil' instruction 20478 20479 'O' 20480 Integer constant whose value plus one is a power of 2 20481 20482 'P' 20483 Integer constant that can be used for 'and' operations in 20484 'depi' and 'extru' instructions 20485 20486 'S' 20487 Integer constant 31 20488 20489 'U' 20490 Integer constant 63 20491 20492 'G' 20493 Floating-point constant 0.0 20494 20495 'A' 20496 A 'lo_sum' data-linkage-table memory operand 20497 20498 'Q' 20499 A memory operand that can be used as the destination operand 20500 of an integer store instruction 20501 20502 'R' 20503 A scaled or unscaled indexed memory operand 20504 20505 'T' 20506 A memory operand for floating-point loads and stores 20507 20508 'W' 20509 A register indirect memory operand 20510 20511_Intel IA-64--'config/ia64/ia64.h'_ 20512 'a' 20513 General register 'r0' to 'r3' for 'addl' instruction 20514 20515 'b' 20516 Branch register 20517 20518 'c' 20519 Predicate register ('c' as in "conditional") 20520 20521 'd' 20522 Application register residing in M-unit 20523 20524 'e' 20525 Application register residing in I-unit 20526 20527 'f' 20528 Floating-point register 20529 20530 'm' 20531 Memory operand. If used together with '<' or '>', the operand 20532 can have postincrement and postdecrement which require 20533 printing with '%Pn' on IA-64. 20534 20535 'G' 20536 Floating-point constant 0.0 or 1.0 20537 20538 'I' 20539 14-bit signed integer constant 20540 20541 'J' 20542 22-bit signed integer constant 20543 20544 'K' 20545 8-bit signed integer constant for logical instructions 20546 20547 'L' 20548 8-bit adjusted signed integer constant for compare pseudo-ops 20549 20550 'M' 20551 6-bit unsigned integer constant for shift counts 20552 20553 'N' 20554 9-bit signed integer constant for load and store 20555 postincrements 20556 20557 'O' 20558 The constant zero 20559 20560 'P' 20561 0 or -1 for 'dep' instruction 20562 20563 'Q' 20564 Non-volatile memory for floating-point loads and stores 20565 20566 'R' 20567 Integer constant in the range 1 to 4 for 'shladd' instruction 20568 20569 'S' 20570 Memory operand except postincrement and postdecrement. This 20571 is now roughly the same as 'm' when not used together with '<' 20572 or '>'. 20573 20574_M32C--'config/m32c/m32c.c'_ 20575 'Rsp' 20576 'Rfb' 20577 'Rsb' 20578 '$sp', '$fb', '$sb'. 20579 20580 'Rcr' 20581 Any control register, when they're 16 bits wide (nothing if 20582 control registers are 24 bits wide) 20583 20584 'Rcl' 20585 Any control register, when they're 24 bits wide. 20586 20587 'R0w' 20588 'R1w' 20589 'R2w' 20590 'R3w' 20591 $r0, $r1, $r2, $r3. 20592 20593 'R02' 20594 $r0 or $r2, or $r2r0 for 32 bit values. 20595 20596 'R13' 20597 $r1 or $r3, or $r3r1 for 32 bit values. 20598 20599 'Rdi' 20600 A register that can hold a 64 bit value. 20601 20602 'Rhl' 20603 $r0 or $r1 (registers with addressable high/low bytes) 20604 20605 'R23' 20606 $r2 or $r3 20607 20608 'Raa' 20609 Address registers 20610 20611 'Raw' 20612 Address registers when they're 16 bits wide. 20613 20614 'Ral' 20615 Address registers when they're 24 bits wide. 20616 20617 'Rqi' 20618 Registers that can hold QI values. 20619 20620 'Rad' 20621 Registers that can be used with displacements ($a0, $a1, $sb). 20622 20623 'Rsi' 20624 Registers that can hold 32 bit values. 20625 20626 'Rhi' 20627 Registers that can hold 16 bit values. 20628 20629 'Rhc' 20630 Registers chat can hold 16 bit values, including all control 20631 registers. 20632 20633 'Rra' 20634 $r0 through R1, plus $a0 and $a1. 20635 20636 'Rfl' 20637 The flags register. 20638 20639 'Rmm' 20640 The memory-based pseudo-registers $mem0 through $mem15. 20641 20642 'Rpi' 20643 Registers that can hold pointers (16 bit registers for r8c, 20644 m16c; 24 bit registers for m32cm, m32c). 20645 20646 'Rpa' 20647 Matches multiple registers in a PARALLEL to form a larger 20648 register. Used to match function return values. 20649 20650 'Is3' 20651 -8 ... 7 20652 20653 'IS1' 20654 -128 ... 127 20655 20656 'IS2' 20657 -32768 ... 32767 20658 20659 'IU2' 20660 0 ... 65535 20661 20662 'In4' 20663 -8 ... -1 or 1 ... 8 20664 20665 'In5' 20666 -16 ... -1 or 1 ... 16 20667 20668 'In6' 20669 -32 ... -1 or 1 ... 32 20670 20671 'IM2' 20672 -65536 ... -1 20673 20674 'Ilb' 20675 An 8 bit value with exactly one bit set. 20676 20677 'Ilw' 20678 A 16 bit value with exactly one bit set. 20679 20680 'Sd' 20681 The common src/dest memory addressing modes. 20682 20683 'Sa' 20684 Memory addressed using $a0 or $a1. 20685 20686 'Si' 20687 Memory addressed with immediate addresses. 20688 20689 'Ss' 20690 Memory addressed using the stack pointer ($sp). 20691 20692 'Sf' 20693 Memory addressed using the frame base register ($fb). 20694 20695 'Ss' 20696 Memory addressed using the small base register ($sb). 20697 20698 'S1' 20699 $r1h 20700 20701_MeP--'config/mep/constraints.md'_ 20702 20703 'a' 20704 The $sp register. 20705 20706 'b' 20707 The $tp register. 20708 20709 'c' 20710 Any control register. 20711 20712 'd' 20713 Either the $hi or the $lo register. 20714 20715 'em' 20716 Coprocessor registers that can be directly loaded ($c0-$c15). 20717 20718 'ex' 20719 Coprocessor registers that can be moved to each other. 20720 20721 'er' 20722 Coprocessor registers that can be moved to core registers. 20723 20724 'h' 20725 The $hi register. 20726 20727 'j' 20728 The $rpc register. 20729 20730 'l' 20731 The $lo register. 20732 20733 't' 20734 Registers which can be used in $tp-relative addressing. 20735 20736 'v' 20737 The $gp register. 20738 20739 'x' 20740 The coprocessor registers. 20741 20742 'y' 20743 The coprocessor control registers. 20744 20745 'z' 20746 The $0 register. 20747 20748 'A' 20749 User-defined register set A. 20750 20751 'B' 20752 User-defined register set B. 20753 20754 'C' 20755 User-defined register set C. 20756 20757 'D' 20758 User-defined register set D. 20759 20760 'I' 20761 Offsets for $gp-rel addressing. 20762 20763 'J' 20764 Constants that can be used directly with boolean insns. 20765 20766 'K' 20767 Constants that can be moved directly to registers. 20768 20769 'L' 20770 Small constants that can be added to registers. 20771 20772 'M' 20773 Long shift counts. 20774 20775 'N' 20776 Small constants that can be compared to registers. 20777 20778 'O' 20779 Constants that can be loaded into the top half of registers. 20780 20781 'S' 20782 Signed 8-bit immediates. 20783 20784 'T' 20785 Symbols encoded for $tp-rel or $gp-rel addressing. 20786 20787 'U' 20788 Non-constant addresses for loading/saving coprocessor 20789 registers. 20790 20791 'W' 20792 The top half of a symbol's value. 20793 20794 'Y' 20795 A register indirect address without offset. 20796 20797 'Z' 20798 Symbolic references to the control bus. 20799 20800_MicroBlaze--'config/microblaze/constraints.md'_ 20801 'd' 20802 A general register ('r0' to 'r31'). 20803 20804 'z' 20805 A status register ('rmsr', '$fcc1' to '$fcc7'). 20806 20807_MIPS--'config/mips/constraints.md'_ 20808 'd' 20809 An address register. This is equivalent to 'r' unless 20810 generating MIPS16 code. 20811 20812 'f' 20813 A floating-point register (if available). 20814 20815 'h' 20816 Formerly the 'hi' register. This constraint is no longer 20817 supported. 20818 20819 'l' 20820 The 'lo' register. Use this register to store values that are 20821 no bigger than a word. 20822 20823 'x' 20824 The concatenated 'hi' and 'lo' registers. Use this register 20825 to store doubleword values. 20826 20827 'c' 20828 A register suitable for use in an indirect jump. This will 20829 always be '$25' for '-mabicalls'. 20830 20831 'v' 20832 Register '$3'. Do not use this constraint in new code; it is 20833 retained only for compatibility with glibc. 20834 20835 'y' 20836 Equivalent to 'r'; retained for backwards compatibility. 20837 20838 'z' 20839 A floating-point condition code register. 20840 20841 'I' 20842 A signed 16-bit constant (for arithmetic instructions). 20843 20844 'J' 20845 Integer zero. 20846 20847 'K' 20848 An unsigned 16-bit constant (for logic instructions). 20849 20850 'L' 20851 A signed 32-bit constant in which the lower 16 bits are zero. 20852 Such constants can be loaded using 'lui'. 20853 20854 'M' 20855 A constant that cannot be loaded using 'lui', 'addiu' or 20856 'ori'. 20857 20858 'N' 20859 A constant in the range -65535 to -1 (inclusive). 20860 20861 'O' 20862 A signed 15-bit constant. 20863 20864 'P' 20865 A constant in the range 1 to 65535 (inclusive). 20866 20867 'G' 20868 Floating-point zero. 20869 20870 'R' 20871 An address that can be used in a non-macro load or store. 20872 20873 'ZC' 20874 A memory operand whose address is formed by a base register 20875 and offset that is suitable for use in instructions with the 20876 same addressing mode as 'll' and 'sc'. 20877 20878 'ZD' 20879 An address suitable for a 'prefetch' instruction, or for any 20880 other instruction with the same addressing mode as 'prefetch'. 20881 20882_Motorola 680x0--'config/m68k/constraints.md'_ 20883 'a' 20884 Address register 20885 20886 'd' 20887 Data register 20888 20889 'f' 20890 68881 floating-point register, if available 20891 20892 'I' 20893 Integer in the range 1 to 8 20894 20895 'J' 20896 16-bit signed number 20897 20898 'K' 20899 Signed number whose magnitude is greater than 0x80 20900 20901 'L' 20902 Integer in the range -8 to -1 20903 20904 'M' 20905 Signed number whose magnitude is greater than 0x100 20906 20907 'N' 20908 Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate 20909 20910 'O' 20911 16 (for rotate using swap) 20912 20913 'P' 20914 Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate 20915 20916 'R' 20917 Numbers that mov3q can handle 20918 20919 'G' 20920 Floating point constant that is not a 68881 constant 20921 20922 'S' 20923 Operands that satisfy 'm' when -mpcrel is in effect 20924 20925 'T' 20926 Operands that satisfy 's' when -mpcrel is not in effect 20927 20928 'Q' 20929 Address register indirect addressing mode 20930 20931 'U' 20932 Register offset addressing 20933 20934 'W' 20935 const_call_operand 20936 20937 'Cs' 20938 symbol_ref or const 20939 20940 'Ci' 20941 const_int 20942 20943 'C0' 20944 const_int 0 20945 20946 'Cj' 20947 Range of signed numbers that don't fit in 16 bits 20948 20949 'Cmvq' 20950 Integers valid for mvq 20951 20952 'Capsw' 20953 Integers valid for a moveq followed by a swap 20954 20955 'Cmvz' 20956 Integers valid for mvz 20957 20958 'Cmvs' 20959 Integers valid for mvs 20960 20961 'Ap' 20962 push_operand 20963 20964 'Ac' 20965 Non-register operands allowed in clr 20966 20967_Moxie--'config/moxie/constraints.md'_ 20968 'A' 20969 An absolute address 20970 20971 'B' 20972 An offset address 20973 20974 'W' 20975 A register indirect memory operand 20976 20977 'I' 20978 A constant in the range of 0 to 255. 20979 20980 'N' 20981 A constant in the range of 0 to -255. 20982 20983_MSP430-'config/msp430/constraints.md'_ 20984 20985 'R12' 20986 Register R12. 20987 20988 'R13' 20989 Register R13. 20990 20991 'K' 20992 Integer constant 1. 20993 20994 'L' 20995 Integer constant -1^20..1^19. 20996 20997 'M' 20998 Integer constant 1-4. 20999 21000 'Ya' 21001 Memory references which do not require an extended MOVX 21002 instruction. 21003 21004 'Yl' 21005 Memory reference, labels only. 21006 21007 'Ys' 21008 Memory reference, stack only. 21009 21010_NDS32--'config/nds32/constraints.md'_ 21011 'w' 21012 LOW register class $r0 to $r7 constraint for V3/V3M ISA. 21013 'l' 21014 LOW register class $r0 to $r7. 21015 'd' 21016 MIDDLE register class $r0 to $r11, $r16 to $r19. 21017 'h' 21018 HIGH register class $r12 to $r14, $r20 to $r31. 21019 't' 21020 Temporary assist register $ta (i.e. $r15). 21021 'k' 21022 Stack register $sp. 21023 'Iu03' 21024 Unsigned immediate 3-bit value. 21025 'In03' 21026 Negative immediate 3-bit value in the range of -7-0. 21027 'Iu04' 21028 Unsigned immediate 4-bit value. 21029 'Is05' 21030 Signed immediate 5-bit value. 21031 'Iu05' 21032 Unsigned immediate 5-bit value. 21033 'In05' 21034 Negative immediate 5-bit value in the range of -31-0. 21035 'Ip05' 21036 Unsigned immediate 5-bit value for movpi45 instruction with 21037 range 16-47. 21038 'Iu06' 21039 Unsigned immediate 6-bit value constraint for addri36.sp 21040 instruction. 21041 'Iu08' 21042 Unsigned immediate 8-bit value. 21043 'Iu09' 21044 Unsigned immediate 9-bit value. 21045 'Is10' 21046 Signed immediate 10-bit value. 21047 'Is11' 21048 Signed immediate 11-bit value. 21049 'Is15' 21050 Signed immediate 15-bit value. 21051 'Iu15' 21052 Unsigned immediate 15-bit value. 21053 'Ic15' 21054 A constant which is not in the range of imm15u but ok for bclr 21055 instruction. 21056 'Ie15' 21057 A constant which is not in the range of imm15u but ok for bset 21058 instruction. 21059 'It15' 21060 A constant which is not in the range of imm15u but ok for btgl 21061 instruction. 21062 'Ii15' 21063 A constant whose compliment value is in the range of imm15u 21064 and ok for bitci instruction. 21065 'Is16' 21066 Signed immediate 16-bit value. 21067 'Is17' 21068 Signed immediate 17-bit value. 21069 'Is19' 21070 Signed immediate 19-bit value. 21071 'Is20' 21072 Signed immediate 20-bit value. 21073 'Ihig' 21074 The immediate value that can be simply set high 20-bit. 21075 'Izeb' 21076 The immediate value 0xff. 21077 'Izeh' 21078 The immediate value 0xffff. 21079 'Ixls' 21080 The immediate value 0x01. 21081 'Ix11' 21082 The immediate value 0x7ff. 21083 'Ibms' 21084 The immediate value with power of 2. 21085 'Ifex' 21086 The immediate value with power of 2 minus 1. 21087 'U33' 21088 Memory constraint for 333 format. 21089 'U45' 21090 Memory constraint for 45 format. 21091 'U37' 21092 Memory constraint for 37 format. 21093 21094_Nios II family--'config/nios2/constraints.md'_ 21095 21096 'I' 21097 Integer that is valid as an immediate operand in an 21098 instruction taking a signed 16-bit number. Range -32768 to 21099 32767. 21100 21101 'J' 21102 Integer that is valid as an immediate operand in an 21103 instruction taking an unsigned 16-bit number. Range 0 to 21104 65535. 21105 21106 'K' 21107 Integer that is valid as an immediate operand in an 21108 instruction taking only the upper 16-bits of a 32-bit number. 21109 Range 32-bit numbers with the lower 16-bits being 0. 21110 21111 'L' 21112 Integer that is valid as an immediate operand for a shift 21113 instruction. Range 0 to 31. 21114 21115 'M' 21116 Integer that is valid as an immediate operand for only the 21117 value 0. Can be used in conjunction with the format modifier 21118 'z' to use 'r0' instead of '0' in the assembly output. 21119 21120 'N' 21121 Integer that is valid as an immediate operand for a custom 21122 instruction opcode. Range 0 to 255. 21123 21124 'S' 21125 Matches immediates which are addresses in the small data 21126 section and therefore can be added to 'gp' as a 16-bit 21127 immediate to re-create their 32-bit value. 21128 21129 'T' 21130 A 'const' wrapped 'UNSPEC' expression, representing a 21131 supported PIC or TLS relocation. 21132 21133_PDP-11--'config/pdp11/constraints.md'_ 21134 'a' 21135 Floating point registers AC0 through AC3. These can be loaded 21136 from/to memory with a single instruction. 21137 21138 'd' 21139 Odd numbered general registers (R1, R3, R5). These are used 21140 for 16-bit multiply operations. 21141 21142 'f' 21143 Any of the floating point registers (AC0 through AC5). 21144 21145 'G' 21146 Floating point constant 0. 21147 21148 'I' 21149 An integer constant that fits in 16 bits. 21150 21151 'J' 21152 An integer constant whose low order 16 bits are zero. 21153 21154 'K' 21155 An integer constant that does not meet the constraints for 21156 codes 'I' or 'J'. 21157 21158 'L' 21159 The integer constant 1. 21160 21161 'M' 21162 The integer constant -1. 21163 21164 'N' 21165 The integer constant 0. 21166 21167 'O' 21168 Integer constants -4 through -1 and 1 through 4; shifts by 21169 these amounts are handled as multiple single-bit shifts rather 21170 than a single variable-length shift. 21171 21172 'Q' 21173 A memory reference which requires an additional word (address 21174 or offset) after the opcode. 21175 21176 'R' 21177 A memory reference that is encoded within the opcode. 21178 21179_PowerPC and IBM RS6000--'config/rs6000/constraints.md'_ 21180 'b' 21181 Address base register 21182 21183 'd' 21184 Floating point register (containing 64-bit value) 21185 21186 'f' 21187 Floating point register (containing 32-bit value) 21188 21189 'v' 21190 Altivec vector register 21191 21192 'wa' 21193 Any VSX register if the -mvsx option was used or NO_REGS. 21194 21195 When using any of the register constraints ('wa', 'wd', 'wf', 21196 'wg', 'wh', 'wi', 'wj', 'wk', 'wl', 'wm', 'ws', 'wt', 'wu', 21197 'wv', 'ww', or 'wy') that take VSX registers, you must use 21198 '%x<n>' in the template so that the correct register is used. 21199 Otherwise the register number output in the assembly file will 21200 be incorrect if an Altivec register is an operand of a VSX 21201 instruction that expects VSX register numbering. 21202 21203 asm ("xvadddp %x0,%x1,%x2" : "=wa" (v1) : "wa" (v2), "wa" (v3)); 21204 21205 is correct, but: 21206 21207 asm ("xvadddp %0,%1,%2" : "=wa" (v1) : "wa" (v2), "wa" (v3)); 21208 21209 is not correct. 21210 21211 'wd' 21212 VSX vector register to hold vector double data or NO_REGS. 21213 21214 'wf' 21215 VSX vector register to hold vector float data or NO_REGS. 21216 21217 'wg' 21218 If '-mmfpgpr' was used, a floating point register or NO_REGS. 21219 21220 'wh' 21221 Floating point register if direct moves are available, or 21222 NO_REGS. 21223 21224 'wi' 21225 FP or VSX register to hold 64-bit integers for VSX insns or 21226 NO_REGS. 21227 21228 'wj' 21229 FP or VSX register to hold 64-bit integers for direct moves or 21230 NO_REGS. 21231 21232 'wk' 21233 FP or VSX register to hold 64-bit doubles for direct moves or 21234 NO_REGS. 21235 21236 'wl' 21237 Floating point register if the LFIWAX instruction is enabled 21238 or NO_REGS. 21239 21240 'wm' 21241 VSX register if direct move instructions are enabled, or 21242 NO_REGS. 21243 21244 'wn' 21245 No register (NO_REGS). 21246 21247 'wr' 21248 General purpose register if 64-bit instructions are enabled or 21249 NO_REGS. 21250 21251 'ws' 21252 VSX vector register to hold scalar double values or NO_REGS. 21253 21254 'wt' 21255 VSX vector register to hold 128 bit integer or NO_REGS. 21256 21257 'wu' 21258 Altivec register to use for float/32-bit int loads/stores or 21259 NO_REGS. 21260 21261 'wv' 21262 Altivec register to use for double loads/stores or NO_REGS. 21263 21264 'ww' 21265 FP or VSX register to perform float operations under '-mvsx' 21266 or NO_REGS. 21267 21268 'wx' 21269 Floating point register if the STFIWX instruction is enabled 21270 or NO_REGS. 21271 21272 'wy' 21273 FP or VSX register to perform ISA 2.07 float ops or NO_REGS. 21274 21275 'wz' 21276 Floating point register if the LFIWZX instruction is enabled 21277 or NO_REGS. 21278 21279 'wD' 21280 Int constant that is the element number of the 64-bit scalar 21281 in a vector. 21282 21283 'wQ' 21284 A memory address that will work with the 'lq' and 'stq' 21285 instructions. 21286 21287 'h' 21288 'MQ', 'CTR', or 'LINK' register 21289 21290 'q' 21291 'MQ' register 21292 21293 'c' 21294 'CTR' register 21295 21296 'l' 21297 'LINK' register 21298 21299 'x' 21300 'CR' register (condition register) number 0 21301 21302 'y' 21303 'CR' register (condition register) 21304 21305 'z' 21306 'XER[CA]' carry bit (part of the XER register) 21307 21308 'I' 21309 Signed 16-bit constant 21310 21311 'J' 21312 Unsigned 16-bit constant shifted left 16 bits (use 'L' instead 21313 for 'SImode' constants) 21314 21315 'K' 21316 Unsigned 16-bit constant 21317 21318 'L' 21319 Signed 16-bit constant shifted left 16 bits 21320 21321 'M' 21322 Constant larger than 31 21323 21324 'N' 21325 Exact power of 2 21326 21327 'O' 21328 Zero 21329 21330 'P' 21331 Constant whose negation is a signed 16-bit constant 21332 21333 'G' 21334 Floating point constant that can be loaded into a register 21335 with one instruction per word 21336 21337 'H' 21338 Integer/Floating point constant that can be loaded into a 21339 register using three instructions 21340 21341 'm' 21342 Memory operand. Normally, 'm' does not allow addresses that 21343 update the base register. If '<' or '>' constraint is also 21344 used, they are allowed and therefore on PowerPC targets in 21345 that case it is only safe to use 'm<>' in an 'asm' statement 21346 if that 'asm' statement accesses the operand exactly once. 21347 The 'asm' statement must also use '%U<OPNO>' as a placeholder 21348 for the "update" flag in the corresponding load or store 21349 instruction. For example: 21350 21351 asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); 21352 21353 is correct but: 21354 21355 asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); 21356 21357 is not. 21358 21359 'es' 21360 A "stable" memory operand; that is, one which does not include 21361 any automodification of the base register. This used to be 21362 useful when 'm' allowed automodification of the base register, 21363 but as those are now only allowed when '<' or '>' is used, 21364 'es' is basically the same as 'm' without '<' and '>'. 21365 21366 'Q' 21367 Memory operand that is an offset from a register (it is 21368 usually better to use 'm' or 'es' in 'asm' statements) 21369 21370 'Z' 21371 Memory operand that is an indexed or indirect from a register 21372 (it is usually better to use 'm' or 'es' in 'asm' statements) 21373 21374 'R' 21375 AIX TOC entry 21376 21377 'a' 21378 Address operand that is an indexed or indirect from a register 21379 ('p' is preferable for 'asm' statements) 21380 21381 'S' 21382 Constant suitable as a 64-bit mask operand 21383 21384 'T' 21385 Constant suitable as a 32-bit mask operand 21386 21387 'U' 21388 System V Release 4 small data area reference 21389 21390 't' 21391 AND masks that can be performed by two rldic{l, r} 21392 instructions 21393 21394 'W' 21395 Vector constant that does not require memory 21396 21397 'j' 21398 Vector constant that is all zeros. 21399 21400_RL78--'config/rl78/constraints.md'_ 21401 21402 'Int3' 21403 An integer constant in the range 1 ... 7. 21404 'Int8' 21405 An integer constant in the range 0 ... 255. 21406 'J' 21407 An integer constant in the range -255 ... 0 21408 'K' 21409 The integer constant 1. 21410 'L' 21411 The integer constant -1. 21412 'M' 21413 The integer constant 0. 21414 'N' 21415 The integer constant 2. 21416 'O' 21417 The integer constant -2. 21418 'P' 21419 An integer constant in the range 1 ... 15. 21420 'Qbi' 21421 The built-in compare types-eq, ne, gtu, ltu, geu, and leu. 21422 'Qsc' 21423 The synthetic compare types-gt, lt, ge, and le. 21424 'Wab' 21425 A memory reference with an absolute address. 21426 'Wbc' 21427 A memory reference using 'BC' as a base register, with an 21428 optional offset. 21429 'Wca' 21430 A memory reference using 'AX', 'BC', 'DE', or 'HL' for the 21431 address, for calls. 21432 'Wcv' 21433 A memory reference using any 16-bit register pair for the 21434 address, for calls. 21435 'Wd2' 21436 A memory reference using 'DE' as a base register, with an 21437 optional offset. 21438 'Wde' 21439 A memory reference using 'DE' as a base register, without any 21440 offset. 21441 'Wfr' 21442 Any memory reference to an address in the far address space. 21443 'Wh1' 21444 A memory reference using 'HL' as a base register, with an 21445 optional one-byte offset. 21446 'Whb' 21447 A memory reference using 'HL' as a base register, with 'B' or 21448 'C' as the index register. 21449 'Whl' 21450 A memory reference using 'HL' as a base register, without any 21451 offset. 21452 'Ws1' 21453 A memory reference using 'SP' as a base register, with an 21454 optional one-byte offset. 21455 'Y' 21456 Any memory reference to an address in the near address space. 21457 'A' 21458 The 'AX' register. 21459 'B' 21460 The 'BC' register. 21461 'D' 21462 The 'DE' register. 21463 'R' 21464 'A' through 'L' registers. 21465 'S' 21466 The 'SP' register. 21467 'T' 21468 The 'HL' register. 21469 'Z08W' 21470 The 16-bit 'R8' register. 21471 'Z10W' 21472 The 16-bit 'R10' register. 21473 'Zint' 21474 The registers reserved for interrupts ('R24' to 'R31'). 21475 'a' 21476 The 'A' register. 21477 'b' 21478 The 'B' register. 21479 'c' 21480 The 'C' register. 21481 'd' 21482 The 'D' register. 21483 'e' 21484 The 'E' register. 21485 'h' 21486 The 'H' register. 21487 'l' 21488 The 'L' register. 21489 'v' 21490 The virtual registers. 21491 'w' 21492 The 'PSW' register. 21493 'x' 21494 The 'X' register. 21495 21496_RX--'config/rx/constraints.md'_ 21497 'Q' 21498 An address which does not involve register indirect addressing 21499 or pre/post increment/decrement addressing. 21500 21501 'Symbol' 21502 A symbol reference. 21503 21504 'Int08' 21505 A constant in the range -256 to 255, inclusive. 21506 21507 'Sint08' 21508 A constant in the range -128 to 127, inclusive. 21509 21510 'Sint16' 21511 A constant in the range -32768 to 32767, inclusive. 21512 21513 'Sint24' 21514 A constant in the range -8388608 to 8388607, inclusive. 21515 21516 'Uint04' 21517 A constant in the range 0 to 15, inclusive. 21518 21519_S/390 and zSeries--'config/s390/s390.h'_ 21520 'a' 21521 Address register (general purpose register except r0) 21522 21523 'c' 21524 Condition code register 21525 21526 'd' 21527 Data register (arbitrary general purpose register) 21528 21529 'f' 21530 Floating-point register 21531 21532 'I' 21533 Unsigned 8-bit constant (0-255) 21534 21535 'J' 21536 Unsigned 12-bit constant (0-4095) 21537 21538 'K' 21539 Signed 16-bit constant (-32768-32767) 21540 21541 'L' 21542 Value appropriate as displacement. 21543 '(0..4095)' 21544 for short displacement 21545 '(-524288..524287)' 21546 for long displacement 21547 21548 'M' 21549 Constant integer with a value of 0x7fffffff. 21550 21551 'N' 21552 Multiple letter constraint followed by 4 parameter letters. 21553 '0..9:' 21554 number of the part counting from most to least 21555 significant 21556 'H,Q:' 21557 mode of the part 21558 'D,S,H:' 21559 mode of the containing operand 21560 '0,F:' 21561 value of the other parts (F--all bits set) 21562 The constraint matches if the specified part of a constant has 21563 a value different from its other parts. 21564 21565 'Q' 21566 Memory reference without index register and with short 21567 displacement. 21568 21569 'R' 21570 Memory reference with index register and short displacement. 21571 21572 'S' 21573 Memory reference without index register but with long 21574 displacement. 21575 21576 'T' 21577 Memory reference with index register and long displacement. 21578 21579 'U' 21580 Pointer with short displacement. 21581 21582 'W' 21583 Pointer with long displacement. 21584 21585 'Y' 21586 Shift count operand. 21587 21588_SPARC--'config/sparc/sparc.h'_ 21589 'f' 21590 Floating-point register on the SPARC-V8 architecture and lower 21591 floating-point register on the SPARC-V9 architecture. 21592 21593 'e' 21594 Floating-point register. It is equivalent to 'f' on the 21595 SPARC-V8 architecture and contains both lower and upper 21596 floating-point registers on the SPARC-V9 architecture. 21597 21598 'c' 21599 Floating-point condition code register. 21600 21601 'd' 21602 Lower floating-point register. It is only valid on the 21603 SPARC-V9 architecture when the Visual Instruction Set is 21604 available. 21605 21606 'b' 21607 Floating-point register. It is only valid on the SPARC-V9 21608 architecture when the Visual Instruction Set is available. 21609 21610 'h' 21611 64-bit global or out register for the SPARC-V8+ architecture. 21612 21613 'C' 21614 The constant all-ones, for floating-point. 21615 21616 'A' 21617 Signed 5-bit constant 21618 21619 'D' 21620 A vector constant 21621 21622 'I' 21623 Signed 13-bit constant 21624 21625 'J' 21626 Zero 21627 21628 'K' 21629 32-bit constant with the low 12 bits clear (a constant that 21630 can be loaded with the 'sethi' instruction) 21631 21632 'L' 21633 A constant in the range supported by 'movcc' instructions 21634 (11-bit signed immediate) 21635 21636 'M' 21637 A constant in the range supported by 'movrcc' instructions 21638 (10-bit signed immediate) 21639 21640 'N' 21641 Same as 'K', except that it verifies that bits that are not in 21642 the lower 32-bit range are all zero. Must be used instead of 21643 'K' for modes wider than 'SImode' 21644 21645 'O' 21646 The constant 4096 21647 21648 'G' 21649 Floating-point zero 21650 21651 'H' 21652 Signed 13-bit constant, sign-extended to 32 or 64 bits 21653 21654 'P' 21655 The constant -1 21656 21657 'Q' 21658 Floating-point constant whose integral representation can be 21659 moved into an integer register using a single sethi 21660 instruction 21661 21662 'R' 21663 Floating-point constant whose integral representation can be 21664 moved into an integer register using a single mov instruction 21665 21666 'S' 21667 Floating-point constant whose integral representation can be 21668 moved into an integer register using a high/lo_sum instruction 21669 sequence 21670 21671 'T' 21672 Memory address aligned to an 8-byte boundary 21673 21674 'U' 21675 Even register 21676 21677 'W' 21678 Memory address for 'e' constraint registers 21679 21680 'w' 21681 Memory address with only a base register 21682 21683 'Y' 21684 Vector zero 21685 21686_SPU--'config/spu/spu.h'_ 21687 'a' 21688 An immediate which can be loaded with the il/ila/ilh/ilhu 21689 instructions. const_int is treated as a 64 bit value. 21690 21691 'c' 21692 An immediate for and/xor/or instructions. const_int is 21693 treated as a 64 bit value. 21694 21695 'd' 21696 An immediate for the 'iohl' instruction. const_int is treated 21697 as a 64 bit value. 21698 21699 'f' 21700 An immediate which can be loaded with 'fsmbi'. 21701 21702 'A' 21703 An immediate which can be loaded with the il/ila/ilh/ilhu 21704 instructions. const_int is treated as a 32 bit value. 21705 21706 'B' 21707 An immediate for most arithmetic instructions. const_int is 21708 treated as a 32 bit value. 21709 21710 'C' 21711 An immediate for and/xor/or instructions. const_int is 21712 treated as a 32 bit value. 21713 21714 'D' 21715 An immediate for the 'iohl' instruction. const_int is treated 21716 as a 32 bit value. 21717 21718 'I' 21719 A constant in the range [-64, 63] for shift/rotate 21720 instructions. 21721 21722 'J' 21723 An unsigned 7-bit constant for conversion/nop/channel 21724 instructions. 21725 21726 'K' 21727 A signed 10-bit constant for most arithmetic instructions. 21728 21729 'M' 21730 A signed 16 bit immediate for 'stop'. 21731 21732 'N' 21733 An unsigned 16-bit constant for 'iohl' and 'fsmbi'. 21734 21735 'O' 21736 An unsigned 7-bit constant whose 3 least significant bits are 21737 0. 21738 21739 'P' 21740 An unsigned 3-bit constant for 16-byte rotates and shifts 21741 21742 'R' 21743 Call operand, reg, for indirect calls 21744 21745 'S' 21746 Call operand, symbol, for relative calls. 21747 21748 'T' 21749 Call operand, const_int, for absolute calls. 21750 21751 'U' 21752 An immediate which can be loaded with the il/ila/ilh/ilhu 21753 instructions. const_int is sign extended to 128 bit. 21754 21755 'W' 21756 An immediate for shift and rotate instructions. const_int is 21757 treated as a 32 bit value. 21758 21759 'Y' 21760 An immediate for and/xor/or instructions. const_int is sign 21761 extended as a 128 bit. 21762 21763 'Z' 21764 An immediate for the 'iohl' instruction. const_int is sign 21765 extended to 128 bit. 21766 21767_TI C6X family--'config/c6x/constraints.md'_ 21768 'a' 21769 Register file A (A0-A31). 21770 21771 'b' 21772 Register file B (B0-B31). 21773 21774 'A' 21775 Predicate registers in register file A (A0-A2 on C64X and 21776 higher, A1 and A2 otherwise). 21777 21778 'B' 21779 Predicate registers in register file B (B0-B2). 21780 21781 'C' 21782 A call-used register in register file B (B0-B9, B16-B31). 21783 21784 'Da' 21785 Register file A, excluding predicate registers (A3-A31, plus 21786 A0 if not C64X or higher). 21787 21788 'Db' 21789 Register file B, excluding predicate registers (B3-B31). 21790 21791 'Iu4' 21792 Integer constant in the range 0 ... 15. 21793 21794 'Iu5' 21795 Integer constant in the range 0 ... 31. 21796 21797 'In5' 21798 Integer constant in the range -31 ... 0. 21799 21800 'Is5' 21801 Integer constant in the range -16 ... 15. 21802 21803 'I5x' 21804 Integer constant that can be the operand of an ADDA or a SUBA 21805 insn. 21806 21807 'IuB' 21808 Integer constant in the range 0 ... 65535. 21809 21810 'IsB' 21811 Integer constant in the range -32768 ... 32767. 21812 21813 'IsC' 21814 Integer constant in the range -2^{20} ... 2^{20} - 1. 21815 21816 'Jc' 21817 Integer constant that is a valid mask for the clr instruction. 21818 21819 'Js' 21820 Integer constant that is a valid mask for the set instruction. 21821 21822 'Q' 21823 Memory location with A base register. 21824 21825 'R' 21826 Memory location with B base register. 21827 21828 'S0' 21829 On C64x+ targets, a GP-relative small data reference. 21830 21831 'S1' 21832 Any kind of 'SYMBOL_REF', for use in a call address. 21833 21834 'Si' 21835 Any kind of immediate operand, unless it matches the S0 21836 constraint. 21837 21838 'T' 21839 Memory location with B base register, but not using a long 21840 offset. 21841 21842 'W' 21843 A memory operand with an address that can't be used in an 21844 unaligned access. 21845 21846 'Z' 21847 Register B14 (aka DP). 21848 21849_TILE-Gx--'config/tilegx/constraints.md'_ 21850 'R00' 21851 'R01' 21852 'R02' 21853 'R03' 21854 'R04' 21855 'R05' 21856 'R06' 21857 'R07' 21858 'R08' 21859 'R09' 21860 'R10' 21861 Each of these represents a register constraint for an 21862 individual register, from r0 to r10. 21863 21864 'I' 21865 Signed 8-bit integer constant. 21866 21867 'J' 21868 Signed 16-bit integer constant. 21869 21870 'K' 21871 Unsigned 16-bit integer constant. 21872 21873 'L' 21874 Integer constant that fits in one signed byte when incremented 21875 by one (-129 ... 126). 21876 21877 'm' 21878 Memory operand. If used together with '<' or '>', the operand 21879 can have postincrement which requires printing with '%In' and 21880 '%in' on TILE-Gx. For example: 21881 21882 asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val)); 21883 21884 'M' 21885 A bit mask suitable for the BFINS instruction. 21886 21887 'N' 21888 Integer constant that is a byte tiled out eight times. 21889 21890 'O' 21891 The integer zero constant. 21892 21893 'P' 21894 Integer constant that is a sign-extended byte tiled out as 21895 four shorts. 21896 21897 'Q' 21898 Integer constant that fits in one signed byte when incremented 21899 (-129 ... 126), but excluding -1. 21900 21901 'S' 21902 Integer constant that has all 1 bits consecutive and starting 21903 at bit 0. 21904 21905 'T' 21906 A 16-bit fragment of a got, tls, or pc-relative reference. 21907 21908 'U' 21909 Memory operand except postincrement. This is roughly the same 21910 as 'm' when not used together with '<' or '>'. 21911 21912 'W' 21913 An 8-element vector constant with identical elements. 21914 21915 'Y' 21916 A 4-element vector constant with identical elements. 21917 21918 'Z0' 21919 The integer constant 0xffffffff. 21920 21921 'Z1' 21922 The integer constant 0xffffffff00000000. 21923 21924_TILEPro--'config/tilepro/constraints.md'_ 21925 'R00' 21926 'R01' 21927 'R02' 21928 'R03' 21929 'R04' 21930 'R05' 21931 'R06' 21932 'R07' 21933 'R08' 21934 'R09' 21935 'R10' 21936 Each of these represents a register constraint for an 21937 individual register, from r0 to r10. 21938 21939 'I' 21940 Signed 8-bit integer constant. 21941 21942 'J' 21943 Signed 16-bit integer constant. 21944 21945 'K' 21946 Nonzero integer constant with low 16 bits zero. 21947 21948 'L' 21949 Integer constant that fits in one signed byte when incremented 21950 by one (-129 ... 126). 21951 21952 'm' 21953 Memory operand. If used together with '<' or '>', the operand 21954 can have postincrement which requires printing with '%In' and 21955 '%in' on TILEPro. For example: 21956 21957 asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val)); 21958 21959 'M' 21960 A bit mask suitable for the MM instruction. 21961 21962 'N' 21963 Integer constant that is a byte tiled out four times. 21964 21965 'O' 21966 The integer zero constant. 21967 21968 'P' 21969 Integer constant that is a sign-extended byte tiled out as two 21970 shorts. 21971 21972 'Q' 21973 Integer constant that fits in one signed byte when incremented 21974 (-129 ... 126), but excluding -1. 21975 21976 'T' 21977 A symbolic operand, or a 16-bit fragment of a got, tls, or 21978 pc-relative reference. 21979 21980 'U' 21981 Memory operand except postincrement. This is roughly the same 21982 as 'm' when not used together with '<' or '>'. 21983 21984 'W' 21985 A 4-element vector constant with identical elements. 21986 21987 'Y' 21988 A 2-element vector constant with identical elements. 21989 21990_Visium--'config/visium/constraints.md'_ 21991 'b' 21992 EAM register 'mdb' 21993 21994 'c' 21995 EAM register 'mdc' 21996 21997 'f' 21998 Floating point register 21999 22000 'k' 22001 Register for sibcall optimization 22002 22003 'l' 22004 General register, but not 'r29', 'r30' and 'r31' 22005 22006 't' 22007 Register 'r1' 22008 22009 'u' 22010 Register 'r2' 22011 22012 'v' 22013 Register 'r3' 22014 22015 'G' 22016 Floating-point constant 0.0 22017 22018 'J' 22019 Integer constant in the range 0 .. 65535 (16-bit immediate) 22020 22021 'K' 22022 Integer constant in the range 1 .. 31 (5-bit immediate) 22023 22024 'L' 22025 Integer constant in the range -65535 .. -1 (16-bit negative 22026 immediate) 22027 22028 'M' 22029 Integer constant -1 22030 22031 'O' 22032 Integer constant 0 22033 22034 'P' 22035 Integer constant 32 22036 22037_x86 family--'config/i386/constraints.md'_ 22038 'R' 22039 Legacy register--the eight integer registers available on all 22040 i386 processors ('a', 'b', 'c', 'd', 'si', 'di', 'bp', 'sp'). 22041 22042 'q' 22043 Any register accessible as 'Rl'. In 32-bit mode, 'a', 'b', 22044 'c', and 'd'; in 64-bit mode, any integer register. 22045 22046 'Q' 22047 Any register accessible as 'Rh': 'a', 'b', 'c', and 'd'. 22048 22049 'l' 22050 Any register that can be used as the index in a base+index 22051 memory access: that is, any general register except the stack 22052 pointer. 22053 22054 'a' 22055 The 'a' register. 22056 22057 'b' 22058 The 'b' register. 22059 22060 'c' 22061 The 'c' register. 22062 22063 'd' 22064 The 'd' register. 22065 22066 'S' 22067 The 'si' register. 22068 22069 'D' 22070 The 'di' register. 22071 22072 'A' 22073 The 'a' and 'd' registers. This class is used for 22074 instructions that return double word results in the 'ax:dx' 22075 register pair. Single word values will be allocated either in 22076 'ax' or 'dx'. For example on i386 the following implements 22077 'rdtsc': 22078 22079 unsigned long long rdtsc (void) 22080 { 22081 unsigned long long tick; 22082 __asm__ __volatile__("rdtsc":"=A"(tick)); 22083 return tick; 22084 } 22085 22086 This is not correct on x86-64 as it would allocate tick in 22087 either 'ax' or 'dx'. You have to use the following variant 22088 instead: 22089 22090 unsigned long long rdtsc (void) 22091 { 22092 unsigned int tickl, tickh; 22093 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); 22094 return ((unsigned long long)tickh << 32)|tickl; 22095 } 22096 22097 'f' 22098 Any 80387 floating-point (stack) register. 22099 22100 't' 22101 Top of 80387 floating-point stack ('%st(0)'). 22102 22103 'u' 22104 Second from top of 80387 floating-point stack ('%st(1)'). 22105 22106 'y' 22107 Any MMX register. 22108 22109 'x' 22110 Any SSE register. 22111 22112 'Yz' 22113 First SSE register ('%xmm0'). 22114 22115 'Y2' 22116 Any SSE register, when SSE2 is enabled. 22117 22118 'Yi' 22119 Any SSE register, when SSE2 and inter-unit moves are enabled. 22120 22121 'Ym' 22122 Any MMX register, when inter-unit moves are enabled. 22123 22124 'I' 22125 Integer constant in the range 0 ... 31, for 32-bit shifts. 22126 22127 'J' 22128 Integer constant in the range 0 ... 63, for 64-bit shifts. 22129 22130 'K' 22131 Signed 8-bit integer constant. 22132 22133 'L' 22134 '0xFF' or '0xFFFF', for andsi as a zero-extending move. 22135 22136 'M' 22137 0, 1, 2, or 3 (shifts for the 'lea' instruction). 22138 22139 'N' 22140 Unsigned 8-bit integer constant (for 'in' and 'out' 22141 instructions). 22142 22143 'O' 22144 Integer constant in the range 0 ... 127, for 128-bit shifts. 22145 22146 'G' 22147 Standard 80387 floating point constant. 22148 22149 'C' 22150 SSE constant zero operand. 22151 22152 'e' 22153 32-bit signed integer constant, or a symbolic reference known 22154 to fit that range (for immediate operands in sign-extending 22155 x86-64 instructions). 22156 22157 'Z' 22158 32-bit unsigned integer constant, or a symbolic reference 22159 known to fit that range (for immediate operands in 22160 zero-extending x86-64 instructions). 22161 22162_Xstormy16--'config/stormy16/stormy16.h'_ 22163 'a' 22164 Register r0. 22165 22166 'b' 22167 Register r1. 22168 22169 'c' 22170 Register r2. 22171 22172 'd' 22173 Register r8. 22174 22175 'e' 22176 Registers r0 through r7. 22177 22178 't' 22179 Registers r0 and r1. 22180 22181 'y' 22182 The carry register. 22183 22184 'z' 22185 Registers r8 and r9. 22186 22187 'I' 22188 A constant between 0 and 3 inclusive. 22189 22190 'J' 22191 A constant that has exactly one bit set. 22192 22193 'K' 22194 A constant that has exactly one bit clear. 22195 22196 'L' 22197 A constant between 0 and 255 inclusive. 22198 22199 'M' 22200 A constant between -255 and 0 inclusive. 22201 22202 'N' 22203 A constant between -3 and 0 inclusive. 22204 22205 'O' 22206 A constant between 1 and 4 inclusive. 22207 22208 'P' 22209 A constant between -4 and -1 inclusive. 22210 22211 'Q' 22212 A memory reference that is a stack push. 22213 22214 'R' 22215 A memory reference that is a stack pop. 22216 22217 'S' 22218 A memory reference that refers to a constant address of known 22219 value. 22220 22221 'T' 22222 The register indicated by Rx (not implemented yet). 22223 22224 'U' 22225 A constant that is not between 2 and 15 inclusive. 22226 22227 'Z' 22228 The constant 0. 22229 22230_Xtensa--'config/xtensa/constraints.md'_ 22231 'a' 22232 General-purpose 32-bit register 22233 22234 'b' 22235 One-bit boolean register 22236 22237 'A' 22238 MAC16 40-bit accumulator register 22239 22240 'I' 22241 Signed 12-bit integer constant, for use in MOVI instructions 22242 22243 'J' 22244 Signed 8-bit integer constant, for use in ADDI instructions 22245 22246 'K' 22247 Integer constant valid for BccI instructions 22248 22249 'L' 22250 Unsigned constant valid for BccUI instructions 22251 22252 22253File: gccint.info, Node: Disable Insn Alternatives, Next: Define Constraints, Prev: Machine Constraints, Up: Constraints 22254 2225516.8.6 Disable insn alternatives using the 'enabled' attribute 22256-------------------------------------------------------------- 22257 22258There are three insn attributes that may be used to selectively disable 22259instruction alternatives: 22260 22261'enabled' 22262 Says whether an alternative is available on the current subtarget. 22263 22264'preferred_for_size' 22265 Says whether an enabled alternative should be used in code that is 22266 optimized for size. 22267 22268'preferred_for_speed' 22269 Says whether an enabled alternative should be used in code that is 22270 optimized for speed. 22271 22272 All these attributes should use '(const_int 1)' to allow an alternative 22273or '(const_int 0)' to disallow it. The attributes must be a static 22274property of the subtarget; they cannot for example depend on the current 22275operands, on the current optimization level, on the location of the insn 22276within the body of a loop, on whether register allocation has finished, 22277or on the current compiler pass. 22278 22279 The 'enabled' attribute is a correctness property. It tells GCC to act 22280as though the disabled alternatives were never defined in the first 22281place. This is useful when adding new instructions to an existing 22282pattern in cases where the new instructions are only available for 22283certain cpu architecture levels (typically mapped to the '-march=' 22284command-line option). 22285 22286 In contrast, the 'preferred_for_size' and 'preferred_for_speed' 22287attributes are strong optimization hints rather than correctness 22288properties. 'preferred_for_size' tells GCC which alternatives to 22289consider when adding or modifying an instruction that GCC wants to 22290optimize for size. 'preferred_for_speed' does the same thing for speed. 22291Note that things like code motion can lead to cases where code optimized 22292for size uses alternatives that are not preferred for size, and 22293similarly for speed. 22294 22295 Although 'define_insn's can in principle specify the 'enabled' 22296attribute directly, it is often clearer to have subsiduary attributes 22297for each architectural feature of interest. The 'define_insn's can then 22298use these subsiduary attributes to say which alternatives require which 22299features. The example below does this for 'cpu_facility'. 22300 22301 E.g. the following two patterns could easily be merged using the 22302'enabled' attribute: 22303 22304 22305 (define_insn "*movdi_old" 22306 [(set (match_operand:DI 0 "register_operand" "=d") 22307 (match_operand:DI 1 "register_operand" " d"))] 22308 "!TARGET_NEW" 22309 "lgr %0,%1") 22310 22311 (define_insn "*movdi_new" 22312 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 22313 (match_operand:DI 1 "register_operand" " d,d,f"))] 22314 "TARGET_NEW" 22315 "@ 22316 lgr %0,%1 22317 ldgr %0,%1 22318 lgdr %0,%1") 22319 22320 22321 to: 22322 22323 22324 (define_insn "*movdi_combined" 22325 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 22326 (match_operand:DI 1 "register_operand" " d,d,f"))] 22327 "" 22328 "@ 22329 lgr %0,%1 22330 ldgr %0,%1 22331 lgdr %0,%1" 22332 [(set_attr "cpu_facility" "*,new,new")]) 22333 22334 22335 with the 'enabled' attribute defined like this: 22336 22337 22338 (define_attr "cpu_facility" "standard,new" (const_string "standard")) 22339 22340 (define_attr "enabled" "" 22341 (cond [(eq_attr "cpu_facility" "standard") (const_int 1) 22342 (and (eq_attr "cpu_facility" "new") 22343 (ne (symbol_ref "TARGET_NEW") (const_int 0))) 22344 (const_int 1)] 22345 (const_int 0))) 22346 22347 22348 22349File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Disable Insn Alternatives, Up: Constraints 22350 2235116.8.7 Defining Machine-Specific Constraints 22352-------------------------------------------- 22353 22354Machine-specific constraints fall into two categories: register and 22355non-register constraints. Within the latter category, constraints which 22356allow subsets of all possible memory or address operands should be 22357specially marked, to give 'reload' more information. 22358 22359 Machine-specific constraints can be given names of arbitrary length, 22360but they must be entirely composed of letters, digits, underscores 22361('_'), and angle brackets ('< >'). Like C identifiers, they must begin 22362with a letter or underscore. 22363 22364 In order to avoid ambiguity in operand constraint strings, no 22365constraint can have a name that begins with any other constraint's name. 22366For example, if 'x' is defined as a constraint name, 'xy' may not be, 22367and vice versa. As a consequence of this rule, no constraint may begin 22368with one of the generic constraint letters: 'E F V X g i m n o p r s'. 22369 22370 Register constraints correspond directly to register classes. *Note 22371Register Classes::. There is thus not much flexibility in their 22372definitions. 22373 22374 -- MD Expression: define_register_constraint name regclass docstring 22375 All three arguments are string constants. NAME is the name of the 22376 constraint, as it will appear in 'match_operand' expressions. If 22377 NAME is a multi-letter constraint its length shall be the same for 22378 all constraints starting with the same letter. REGCLASS can be 22379 either the name of the corresponding register class (*note Register 22380 Classes::), or a C expression which evaluates to the appropriate 22381 register class. If it is an expression, it must have no side 22382 effects, and it cannot look at the operand. The usual use of 22383 expressions is to map some register constraints to 'NO_REGS' when 22384 the register class is not available on a given subarchitecture. 22385 22386 DOCSTRING is a sentence documenting the meaning of the constraint. 22387 Docstrings are explained further below. 22388 22389 Non-register constraints are more like predicates: the constraint 22390definition gives a Boolean expression which indicates whether the 22391constraint matches. 22392 22393 -- MD Expression: define_constraint name docstring exp 22394 The NAME and DOCSTRING arguments are the same as for 22395 'define_register_constraint', but note that the docstring comes 22396 immediately after the name for these expressions. EXP is an RTL 22397 expression, obeying the same rules as the RTL expressions in 22398 predicate definitions. *Note Defining Predicates::, for details. 22399 If it evaluates true, the constraint matches; if it evaluates 22400 false, it doesn't. Constraint expressions should indicate which 22401 RTL codes they might match, just like predicate expressions. 22402 22403 'match_test' C expressions have access to the following variables: 22404 22405 OP 22406 The RTL object defining the operand. 22407 MODE 22408 The machine mode of OP. 22409 IVAL 22410 'INTVAL (OP)', if OP is a 'const_int'. 22411 HVAL 22412 'CONST_DOUBLE_HIGH (OP)', if OP is an integer 'const_double'. 22413 LVAL 22414 'CONST_DOUBLE_LOW (OP)', if OP is an integer 'const_double'. 22415 RVAL 22416 'CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 22417 'const_double'. 22418 22419 The *VAL variables should only be used once another piece of the 22420 expression has verified that OP is the appropriate kind of RTL 22421 object. 22422 22423 Most non-register constraints should be defined with 22424'define_constraint'. The remaining two definition expressions are only 22425appropriate for constraints that should be handled specially by 'reload' 22426if they fail to match. 22427 22428 -- MD Expression: define_memory_constraint name docstring exp 22429 Use this expression for constraints that match a subset of all 22430 memory operands: that is, 'reload' can make them match by 22431 converting the operand to the form '(mem (reg X))', where X is a 22432 base register (from the register class specified by 22433 'BASE_REG_CLASS', *note Register Classes::). 22434 22435 For example, on the S/390, some instructions do not accept 22436 arbitrary memory references, but only those that do not make use of 22437 an index register. The constraint letter 'Q' is defined to 22438 represent a memory address of this type. If 'Q' is defined with 22439 'define_memory_constraint', a 'Q' constraint can handle any memory 22440 operand, because 'reload' knows it can simply copy the memory 22441 address into a base register if required. This is analogous to the 22442 way an 'o' constraint can handle any memory operand. 22443 22444 The syntax and semantics are otherwise identical to 22445 'define_constraint'. 22446 22447 -- MD Expression: define_address_constraint name docstring exp 22448 Use this expression for constraints that match a subset of all 22449 address operands: that is, 'reload' can make the constraint match 22450 by converting the operand to the form '(reg X)', again with X a 22451 base register. 22452 22453 Constraints defined with 'define_address_constraint' can only be 22454 used with the 'address_operand' predicate, or machine-specific 22455 predicates that work the same way. They are treated analogously to 22456 the generic 'p' constraint. 22457 22458 The syntax and semantics are otherwise identical to 22459 'define_constraint'. 22460 22461 For historical reasons, names beginning with the letters 'G H' are 22462reserved for constraints that match only 'const_double's, and names 22463beginning with the letters 'I J K L M N O P' are reserved for 22464constraints that match only 'const_int's. This may change in the 22465future. For the time being, constraints with these names must be 22466written in a stylized form, so that 'genpreds' can tell you did it 22467correctly: 22468 22469 (define_constraint "[GHIJKLMNOP]..." 22470 "DOC..." 22471 (and (match_code "const_int") ; 'const_double' for G/H 22472 CONDITION...)) ; usually a 'match_test' 22473 22474 It is fine to use names beginning with other letters for constraints 22475that match 'const_double's or 'const_int's. 22476 22477 Each docstring in a constraint definition should be one or more 22478complete sentences, marked up in Texinfo format. _They are currently 22479unused._ In the future they will be copied into the GCC manual, in 22480*note Machine Constraints::, replacing the hand-maintained tables 22481currently found in that section. Also, in the future the compiler may 22482use this to give more helpful diagnostics when poor choice of 'asm' 22483constraints causes a reload failure. 22484 22485 If you put the pseudo-Texinfo directive '@internal' at the beginning of 22486a docstring, then (in the future) it will appear only in the internals 22487manual's version of the machine-specific constraint tables. Use this 22488for constraints that should not appear in 'asm' statements. 22489 22490 22491File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 22492 2249316.8.8 Testing constraints from C 22494--------------------------------- 22495 22496It is occasionally useful to test a constraint from C code rather than 22497implicitly via the constraint string in a 'match_operand'. The 22498generated file 'tm_p.h' declares a few interfaces for working with 22499constraints. At present these are defined for all constraints except 22500'g' (which is equivalent to 'general_operand'). 22501 22502 Some valid constraint names are not valid C identifiers, so there is a 22503mangling scheme for referring to them from C. Constraint names that do 22504not contain angle brackets or underscores are left unchanged. 22505Underscores are doubled, each '<' is replaced with '_l', and each '>' 22506with '_g'. Here are some examples: 22507 22508 *Original* *Mangled* 22509 x x 22510 P42x P42x 22511 P4_x P4__x 22512 P4>x P4_gx 22513 P4>> P4_g_g 22514 P4_g> P4__g_g 22515 22516 Throughout this section, the variable C is either a constraint in the 22517abstract sense, or a constant from 'enum constraint_num'; the variable M 22518is a mangled constraint name (usually as part of a larger identifier). 22519 22520 -- Enum: constraint_num 22521 For each constraint except 'g', there is a corresponding 22522 enumeration constant: 'CONSTRAINT_' plus the mangled name of the 22523 constraint. Functions that take an 'enum constraint_num' as an 22524 argument expect one of these constants. 22525 22526 -- Function: inline bool satisfies_constraint_M (rtx EXP) 22527 For each non-register constraint M except 'g', there is one of 22528 these functions; it returns 'true' if EXP satisfies the constraint. 22529 These functions are only visible if 'rtl.h' was included before 22530 'tm_p.h'. 22531 22532 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 22533 C) 22534 Like the 'satisfies_constraint_M' functions, but the constraint to 22535 test is given as an argument, C. If C specifies a register 22536 constraint, this function will always return 'false'. 22537 22538 -- Function: enum reg_class reg_class_for_constraint (enum 22539 constraint_num C) 22540 Returns the register class associated with C. If C is not a 22541 register constraint, or those registers are not available for the 22542 currently selected subtarget, returns 'NO_REGS'. 22543 22544 Here is an example use of 'satisfies_constraint_M'. In peephole 22545optimizations (*note Peephole Definitions::), operand constraint strings 22546are ignored, so if there are relevant constraints, they must be tested 22547in the C condition. In the example, the optimization is applied if 22548operand 2 does _not_ satisfy the 'K' constraint. (This is a simplified 22549version of a peephole definition from the i386 machine description.) 22550 22551 (define_peephole2 22552 [(match_scratch:SI 3 "r") 22553 (set (match_operand:SI 0 "register_operand" "") 22554 (mult:SI (match_operand:SI 1 "memory_operand" "") 22555 (match_operand:SI 2 "immediate_operand" "")))] 22556 22557 "!satisfies_constraint_K (operands[2])" 22558 22559 [(set (match_dup 3) (match_dup 1)) 22560 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 22561 22562 "") 22563 22564 22565File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 22566 2256716.9 Standard Pattern Names For Generation 22568========================================== 22569 22570Here is a table of the instruction names that are meaningful in the RTL 22571generation pass of the compiler. Giving one of these names to an 22572instruction pattern tells the RTL generation pass that it can use the 22573pattern to accomplish a certain task. 22574 22575'movM' 22576 Here M stands for a two-letter machine mode name, in lowercase. 22577 This instruction pattern moves data with that machine mode from 22578 operand 1 to operand 0. For example, 'movsi' moves full-word data. 22579 22580 If operand 0 is a 'subreg' with mode M of a register whose own mode 22581 is wider than M, the effect of this instruction is to store the 22582 specified value in the part of the register that corresponds to 22583 mode M. Bits outside of M, but which are within the same target 22584 word as the 'subreg' are undefined. Bits which are outside the 22585 target word are left unchanged. 22586 22587 This class of patterns is special in several ways. First of all, 22588 each of these names up to and including full word size _must_ be 22589 defined, because there is no other way to copy a datum from one 22590 place to another. If there are patterns accepting operands in 22591 larger modes, 'movM' must be defined for integer modes of those 22592 sizes. 22593 22594 Second, these patterns are not used solely in the RTL generation 22595 pass. Even the reload pass can generate move insns to copy values 22596 from stack slots into temporary registers. When it does so, one of 22597 the operands is a hard register and the other is an operand that 22598 can need to be reloaded into a register. 22599 22600 Therefore, when given such a pair of operands, the pattern must 22601 generate RTL which needs no reloading and needs no temporary 22602 registers--no registers other than the operands. For example, if 22603 you support the pattern with a 'define_expand', then in such a case 22604 the 'define_expand' mustn't call 'force_reg' or any other such 22605 function which might generate new pseudo registers. 22606 22607 This requirement exists even for subword modes on a RISC machine 22608 where fetching those modes from memory normally requires several 22609 insns and some temporary registers. 22610 22611 During reload a memory reference with an invalid address may be 22612 passed as an operand. Such an address will be replaced with a 22613 valid address later in the reload pass. In this case, nothing may 22614 be done with the address except to use it as it stands. If it is 22615 copied, it will not be replaced with a valid address. No attempt 22616 should be made to make such an address into a valid address and no 22617 routine (such as 'change_address') that will do so may be called. 22618 Note that 'general_operand' will fail when applied to such an 22619 address. 22620 22621 The global variable 'reload_in_progress' (which must be explicitly 22622 declared if required) can be used to determine whether such special 22623 handling is required. 22624 22625 The variety of operands that have reloads depends on the rest of 22626 the machine description, but typically on a RISC machine these can 22627 only be pseudo registers that did not get hard registers, while on 22628 other machines explicit memory references will get optional 22629 reloads. 22630 22631 If a scratch register is required to move an object to or from 22632 memory, it can be allocated using 'gen_reg_rtx' prior to life 22633 analysis. 22634 22635 If there are cases which need scratch registers during or after 22636 reload, you must provide an appropriate secondary_reload target 22637 hook. 22638 22639 The macro 'can_create_pseudo_p' can be used to determine if it is 22640 unsafe to create new pseudo registers. If this variable is 22641 nonzero, then it is unsafe to call 'gen_reg_rtx' to allocate a new 22642 pseudo. 22643 22644 The constraints on a 'movM' must permit moving any hard register to 22645 any other hard register provided that 'HARD_REGNO_MODE_OK' permits 22646 mode M in both registers and 'TARGET_REGISTER_MOVE_COST' applied to 22647 their classes returns a value of 2. 22648 22649 It is obligatory to support floating point 'movM' instructions into 22650 and out of any registers that can hold fixed point values, because 22651 unions and structures (which have modes 'SImode' or 'DImode') can 22652 be in those registers and they may have floating point members. 22653 22654 There may also be a need to support fixed point 'movM' instructions 22655 in and out of floating point registers. Unfortunately, I have 22656 forgotten why this was so, and I don't know whether it is still 22657 true. If 'HARD_REGNO_MODE_OK' rejects fixed point values in 22658 floating point registers, then the constraints of the fixed point 22659 'movM' instructions must be designed to avoid ever trying to reload 22660 into a floating point register. 22661 22662'reload_inM' 22663'reload_outM' 22664 These named patterns have been obsoleted by the target hook 22665 'secondary_reload'. 22666 22667 Like 'movM', but used when a scratch register is required to move 22668 between operand 0 and operand 1. Operand 2 describes the scratch 22669 register. See the discussion of the 'SECONDARY_RELOAD_CLASS' macro 22670 in *note Register Classes::. 22671 22672 There are special restrictions on the form of the 'match_operand's 22673 used in these patterns. First, only the predicate for the reload 22674 operand is examined, i.e., 'reload_in' examines operand 1, but not 22675 the predicates for operand 0 or 2. Second, there may be only one 22676 alternative in the constraints. Third, only a single register 22677 class letter may be used for the constraint; subsequent constraint 22678 letters are ignored. As a special exception, an empty constraint 22679 string matches the 'ALL_REGS' register class. This may relieve 22680 ports of the burden of defining an 'ALL_REGS' constraint letter 22681 just for these patterns. 22682 22683'movstrictM' 22684 Like 'movM' except that if operand 0 is a 'subreg' with mode M of a 22685 register whose natural mode is wider, the 'movstrictM' instruction 22686 is guaranteed not to alter any of the register except the part 22687 which belongs to mode M. 22688 22689'movmisalignM' 22690 This variant of a move pattern is designed to load or store a value 22691 from a memory address that is not naturally aligned for its mode. 22692 For a store, the memory will be in operand 0; for a load, the 22693 memory will be in operand 1. The other operand is guaranteed not 22694 to be a memory, so that it's easy to tell whether this is a load or 22695 store. 22696 22697 This pattern is used by the autovectorizer, and when expanding a 22698 'MISALIGNED_INDIRECT_REF' expression. 22699 22700'load_multiple' 22701 Load several consecutive memory locations into consecutive 22702 registers. Operand 0 is the first of the consecutive registers, 22703 operand 1 is the first memory location, and operand 2 is a 22704 constant: the number of consecutive registers. 22705 22706 Define this only if the target machine really has such an 22707 instruction; do not define this if the most efficient way of 22708 loading consecutive registers from memory is to do them one at a 22709 time. 22710 22711 On some machines, there are restrictions as to which consecutive 22712 registers can be stored into memory, such as particular starting or 22713 ending register numbers or only a range of valid counts. For those 22714 machines, use a 'define_expand' (*note Expander Definitions::) and 22715 make the pattern fail if the restrictions are not met. 22716 22717 Write the generated insn as a 'parallel' with elements being a 22718 'set' of one register from the appropriate memory location (you may 22719 also need 'use' or 'clobber' elements). Use a 'match_parallel' 22720 (*note RTL Template::) to recognize the insn. See 'rs6000.md' for 22721 examples of the use of this insn pattern. 22722 22723'store_multiple' 22724 Similar to 'load_multiple', but store several consecutive registers 22725 into consecutive memory locations. Operand 0 is the first of the 22726 consecutive memory locations, operand 1 is the first register, and 22727 operand 2 is a constant: the number of consecutive registers. 22728 22729'vec_load_lanesMN' 22730 Perform an interleaved load of several vectors from memory operand 22731 1 into register operand 0. Both operands have mode M. The 22732 register operand is viewed as holding consecutive vectors of mode 22733 N, while the memory operand is a flat array that contains the same 22734 number of elements. The operation is equivalent to: 22735 22736 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 22737 for (j = 0; j < GET_MODE_NUNITS (N); j++) 22738 for (i = 0; i < c; i++) 22739 operand0[i][j] = operand1[j * c + i]; 22740 22741 For example, 'vec_load_lanestiv4hi' loads 8 16-bit values from 22742 memory into a register of mode 'TI'. The register contains two 22743 consecutive vectors of mode 'V4HI'. 22744 22745 This pattern can only be used if: 22746 TARGET_ARRAY_MODE_SUPPORTED_P (N, C) 22747 is true. GCC assumes that, if a target supports this kind of 22748 instruction for some mode N, it also supports unaligned loads for 22749 vectors of mode N. 22750 22751'vec_store_lanesMN' 22752 Equivalent to 'vec_load_lanesMN', with the memory and register 22753 operands reversed. That is, the instruction is equivalent to: 22754 22755 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 22756 for (j = 0; j < GET_MODE_NUNITS (N); j++) 22757 for (i = 0; i < c; i++) 22758 operand0[j * c + i] = operand1[i][j]; 22759 22760 for a memory operand 0 and register operand 1. 22761 22762'vec_setM' 22763 Set given field in the vector value. Operand 0 is the vector to 22764 modify, operand 1 is new value of field and operand 2 specify the 22765 field index. 22766 22767'vec_extractM' 22768 Extract given field from the vector value. Operand 1 is the 22769 vector, operand 2 specify field index and operand 0 place to store 22770 value into. 22771 22772'vec_initM' 22773 Initialize the vector to given values. Operand 0 is the vector to 22774 initialize and operand 1 is parallel containing values for 22775 individual fields. 22776 22777'vcondMN' 22778 Output a conditional vector move. Operand 0 is the destination to 22779 receive a combination of operand 1 and operand 2, which are of mode 22780 M, dependent on the outcome of the predicate in operand 3 which is 22781 a vector comparison with operands of mode N in operands 4 and 5. 22782 The modes M and N should have the same size. Operand 0 will be set 22783 to the value OP1 & MSK | OP2 & ~MSK where MSK is computed by 22784 element-wise evaluation of the vector comparison with a truth value 22785 of all-ones and a false value of all-zeros. 22786 22787'vec_permM' 22788 Output a (variable) vector permutation. Operand 0 is the 22789 destination to receive elements from operand 1 and operand 2, which 22790 are of mode M. Operand 3 is the "selector". It is an integral 22791 mode vector of the same width and number of elements as mode M. 22792 22793 The input elements are numbered from 0 in operand 1 through 2*N-1 22794 in operand 2. The elements of the selector must be computed modulo 22795 2*N. Note that if 'rtx_equal_p(operand1, operand2)', this can be 22796 implemented with just operand 1 and selector elements modulo N. 22797 22798 In order to make things easy for a number of targets, if there is 22799 no 'vec_perm' pattern for mode M, but there is for mode Q where Q 22800 is a vector of 'QImode' of the same width as M, the middle-end will 22801 lower the mode M 'VEC_PERM_EXPR' to mode Q. 22802 22803'vec_perm_constM' 22804 Like 'vec_perm' except that the permutation is a compile-time 22805 constant. That is, operand 3, the "selector", is a 'CONST_VECTOR'. 22806 22807 Some targets cannot perform a permutation with a variable selector, 22808 but can efficiently perform a constant permutation. Further, the 22809 target hook 'vec_perm_ok' is queried to determine if the specific 22810 constant permutation is available efficiently; the named pattern is 22811 never expanded without 'vec_perm_ok' returning true. 22812 22813 There is no need for a target to supply both 'vec_permM' and 22814 'vec_perm_constM' if the former can trivially implement the 22815 operation with, say, the vector constant loaded into a register. 22816 22817'pushM1' 22818 Output a push instruction. Operand 0 is value to push. Used only 22819 when 'PUSH_ROUNDING' is defined. For historical reason, this 22820 pattern may be missing and in such case an 'mov' expander is used 22821 instead, with a 'MEM' expression forming the push operation. The 22822 'mov' expander method is deprecated. 22823 22824'addM3' 22825 Add operand 2 and operand 1, storing the result in operand 0. All 22826 operands must have mode M. This can be used even on two-address 22827 machines, by means of constraints requiring operands 1 and 0 to be 22828 the same location. 22829 22830'ssaddM3', 'usaddM3' 22831'subM3', 'sssubM3', 'ussubM3' 22832'mulM3', 'ssmulM3', 'usmulM3' 22833'divM3', 'ssdivM3' 22834'udivM3', 'usdivM3' 22835'modM3', 'umodM3' 22836'uminM3', 'umaxM3' 22837'andM3', 'iorM3', 'xorM3' 22838 Similar, for other arithmetic operations. 22839 22840'addvM4' 22841 Like 'addM3' but takes a 'code_label' as operand 3 and emits code 22842 to jump to it if signed overflow occurs during the addition. This 22843 pattern is used to implement the built-in functions performing 22844 signed integer addition with overflow checking. 22845 22846'subvM4', 'mulvM4' 22847 Similar, for other signed arithmetic operations. 22848 22849'umulvM4' 22850 Like 'mulvM4' but for unsigned multiplication. That is to say, the 22851 operation is the same as signed multiplication but the jump is 22852 taken only on unsigned overflow. 22853 22854'addptrM3' 22855 Like 'addM3' but is guaranteed to only be used for address 22856 calculations. The expanded code is not allowed to clobber the 22857 condition code. It only needs to be defined if 'addM3' sets the 22858 condition code. If adds used for address calculations and normal 22859 adds are not compatible it is required to expand a distinct pattern 22860 (e.g. using an unspec). The pattern is used by LRA to emit 22861 address calculations. 'addM3' is used if 'addptrM3' is not 22862 defined. 22863 22864'fmaM4' 22865 Multiply operand 2 and operand 1, then add operand 3, storing the 22866 result in operand 0 without doing an intermediate rounding step. 22867 All operands must have mode M. This pattern is used to implement 22868 the 'fma', 'fmaf', and 'fmal' builtin functions from the ISO C99 22869 standard. 22870 22871'fmsM4' 22872 Like 'fmaM4', except operand 3 subtracted from the product instead 22873 of added to the product. This is represented in the rtl as 22874 22875 (fma:M OP1 OP2 (neg:M OP3)) 22876 22877'fnmaM4' 22878 Like 'fmaM4' except that the intermediate product is negated before 22879 being added to operand 3. This is represented in the rtl as 22880 22881 (fma:M (neg:M OP1) OP2 OP3) 22882 22883'fnmsM4' 22884 Like 'fmsM4' except that the intermediate product is negated before 22885 subtracting operand 3. This is represented in the rtl as 22886 22887 (fma:M (neg:M OP1) OP2 (neg:M OP3)) 22888 22889'sminM3', 'smaxM3' 22890 Signed minimum and maximum operations. When used with floating 22891 point, if both operands are zeros, or if either operand is 'NaN', 22892 then it is unspecified which of the two operands is returned as the 22893 result. 22894 22895'reduc_smin_M', 'reduc_smax_M' 22896 Find the signed minimum/maximum of the elements of a vector. The 22897 vector is operand 1, and the result is stored in the least 22898 significant bits of operand 0 (also a vector). The output and 22899 input vector should have the same modes. These are legacy optabs, 22900 and platforms should prefer to implement 'reduc_smin_scal_M' and 22901 'reduc_smax_scal_M'. 22902 22903'reduc_umin_M', 'reduc_umax_M' 22904 Find the unsigned minimum/maximum of the elements of a vector. The 22905 vector is operand 1, and the result is stored in the least 22906 significant bits of operand 0 (also a vector). The output and 22907 input vector should have the same modes. These are legacy optabs, 22908 and platforms should prefer to implement 'reduc_umin_scal_M' and 22909 'reduc_umax_scal_M'. 22910 22911'reduc_splus_M', 'reduc_uplus_M' 22912 Compute the sum of the signed/unsigned elements of a vector. The 22913 vector is operand 1, and the result is stored in the least 22914 significant bits of operand 0 (also a vector). The output and 22915 input vector should have the same modes. These are legacy optabs, 22916 and platforms should prefer to implement 'reduc_plus_scal_M'. 22917 22918'reduc_smin_scal_M', 'reduc_smax_scal_M' 22919 Find the signed minimum/maximum of the elements of a vector. The 22920 vector is operand 1, and operand 0 is the scalar result, with mode 22921 equal to the mode of the elements of the input vector. 22922 22923'reduc_umin_scal_M', 'reduc_umax_scal_M' 22924 Find the unsigned minimum/maximum of the elements of a vector. The 22925 vector is operand 1, and operand 0 is the scalar result, with mode 22926 equal to the mode of the elements of the input vector. 22927 22928'reduc_plus_scal_M' 22929 Compute the sum of the elements of a vector. The vector is operand 22930 1, and operand 0 is the scalar result, with mode equal to the mode 22931 of the elements of the input vector. 22932 22933'sdot_prodM' 22934'udot_prodM' 22935 Compute the sum of the products of two signed/unsigned elements. 22936 Operand 1 and operand 2 are of the same mode. Their product, which 22937 is of a wider mode, is computed and added to operand 3. Operand 3 22938 is of a mode equal or wider than the mode of the product. The 22939 result is placed in operand 0, which is of the same mode as operand 22940 3. 22941 22942'ssadM' 22943'usadM' 22944 Compute the sum of absolute differences of two signed/unsigned 22945 elements. Operand 1 and operand 2 are of the same mode. Their 22946 absolute difference, which is of a wider mode, is computed and 22947 added to operand 3. Operand 3 is of a mode equal or wider than the 22948 mode of the absolute difference. The result is placed in operand 22949 0, which is of the same mode as operand 3. 22950 22951'ssum_widenM3' 22952'usum_widenM3' 22953 Operands 0 and 2 are of the same mode, which is wider than the mode 22954 of operand 1. Add operand 1 to operand 2 and place the widened 22955 result in operand 0. (This is used express accumulation of 22956 elements into an accumulator of a wider mode.) 22957 22958'vec_shr_M' 22959 Whole vector right shift in bits, i.e. towards element 0. Operand 22960 1 is a vector to be shifted. Operand 2 is an integer shift amount 22961 in bits. Operand 0 is where the resulting shifted vector is 22962 stored. The output and input vectors should have the same modes. 22963 22964'vec_pack_trunc_M' 22965 Narrow (demote) and merge the elements of two vectors. Operands 1 22966 and 2 are vectors of the same mode having N integral or floating 22967 point elements of size S. Operand 0 is the resulting vector in 22968 which 2*N elements of size N/2 are concatenated after narrowing 22969 them down using truncation. 22970 22971'vec_pack_ssat_M', 'vec_pack_usat_M' 22972 Narrow (demote) and merge the elements of two vectors. Operands 1 22973 and 2 are vectors of the same mode having N integral elements of 22974 size S. Operand 0 is the resulting vector in which the elements of 22975 the two input vectors are concatenated after narrowing them down 22976 using signed/unsigned saturating arithmetic. 22977 22978'vec_pack_sfix_trunc_M', 'vec_pack_ufix_trunc_M' 22979 Narrow, convert to signed/unsigned integral type and merge the 22980 elements of two vectors. Operands 1 and 2 are vectors of the same 22981 mode having N floating point elements of size S. Operand 0 is the 22982 resulting vector in which 2*N elements of size N/2 are 22983 concatenated. 22984 22985'vec_unpacks_hi_M', 'vec_unpacks_lo_M' 22986 Extract and widen (promote) the high/low part of a vector of signed 22987 integral or floating point elements. The input vector (operand 1) 22988 has N elements of size S. Widen (promote) the high/low elements of 22989 the vector using signed or floating point extension and place the 22990 resulting N/2 values of size 2*S in the output vector (operand 0). 22991 22992'vec_unpacku_hi_M', 'vec_unpacku_lo_M' 22993 Extract and widen (promote) the high/low part of a vector of 22994 unsigned integral elements. The input vector (operand 1) has N 22995 elements of size S. Widen (promote) the high/low elements of the 22996 vector using zero extension and place the resulting N/2 values of 22997 size 2*S in the output vector (operand 0). 22998 22999'vec_unpacks_float_hi_M', 'vec_unpacks_float_lo_M' 23000'vec_unpacku_float_hi_M', 'vec_unpacku_float_lo_M' 23001 Extract, convert to floating point type and widen the high/low part 23002 of a vector of signed/unsigned integral elements. The input vector 23003 (operand 1) has N elements of size S. Convert the high/low 23004 elements of the vector using floating point conversion and place 23005 the resulting N/2 values of size 2*S in the output vector (operand 23006 0). 23007 23008'vec_widen_umult_hi_M', 'vec_widen_umult_lo_M' 23009'vec_widen_smult_hi_M', 'vec_widen_smult_lo_M' 23010'vec_widen_umult_even_M', 'vec_widen_umult_odd_M' 23011'vec_widen_smult_even_M', 'vec_widen_smult_odd_M' 23012 Signed/Unsigned widening multiplication. The two inputs (operands 23013 1 and 2) are vectors with N signed/unsigned elements of size S. 23014 Multiply the high/low or even/odd elements of the two vectors, and 23015 put the N/2 products of size 2*S in the output vector (operand 0). 23016 A target shouldn't implement even/odd pattern pair if it is less 23017 efficient than lo/hi one. 23018 23019'vec_widen_ushiftl_hi_M', 'vec_widen_ushiftl_lo_M' 23020'vec_widen_sshiftl_hi_M', 'vec_widen_sshiftl_lo_M' 23021 Signed/Unsigned widening shift left. The first input (operand 1) 23022 is a vector with N signed/unsigned elements of size S. Operand 2 23023 is a constant. Shift the high/low elements of operand 1, and put 23024 the N/2 results of size 2*S in the output vector (operand 0). 23025 23026'mulhisi3' 23027 Multiply operands 1 and 2, which have mode 'HImode', and store a 23028 'SImode' product in operand 0. 23029 23030'mulqihi3', 'mulsidi3' 23031 Similar widening-multiplication instructions of other widths. 23032 23033'umulqihi3', 'umulhisi3', 'umulsidi3' 23034 Similar widening-multiplication instructions that do unsigned 23035 multiplication. 23036 23037'usmulqihi3', 'usmulhisi3', 'usmulsidi3' 23038 Similar widening-multiplication instructions that interpret the 23039 first operand as unsigned and the second operand as signed, then do 23040 a signed multiplication. 23041 23042'smulM3_highpart' 23043 Perform a signed multiplication of operands 1 and 2, which have 23044 mode M, and store the most significant half of the product in 23045 operand 0. The least significant half of the product is discarded. 23046 23047'umulM3_highpart' 23048 Similar, but the multiplication is unsigned. 23049 23050'maddMN4' 23051 Multiply operands 1 and 2, sign-extend them to mode N, add operand 23052 3, and store the result in operand 0. Operands 1 and 2 have mode M 23053 and operands 0 and 3 have mode N. Both modes must be integer or 23054 fixed-point modes and N must be twice the size of M. 23055 23056 In other words, 'maddMN4' is like 'mulMN3' except that it also adds 23057 operand 3. 23058 23059 These instructions are not allowed to 'FAIL'. 23060 23061'umaddMN4' 23062 Like 'maddMN4', but zero-extend the multiplication operands instead 23063 of sign-extending them. 23064 23065'ssmaddMN4' 23066 Like 'maddMN4', but all involved operations must be 23067 signed-saturating. 23068 23069'usmaddMN4' 23070 Like 'umaddMN4', but all involved operations must be 23071 unsigned-saturating. 23072 23073'msubMN4' 23074 Multiply operands 1 and 2, sign-extend them to mode N, subtract the 23075 result from operand 3, and store the result in operand 0. Operands 23076 1 and 2 have mode M and operands 0 and 3 have mode N. Both modes 23077 must be integer or fixed-point modes and N must be twice the size 23078 of M. 23079 23080 In other words, 'msubMN4' is like 'mulMN3' except that it also 23081 subtracts the result from operand 3. 23082 23083 These instructions are not allowed to 'FAIL'. 23084 23085'umsubMN4' 23086 Like 'msubMN4', but zero-extend the multiplication operands instead 23087 of sign-extending them. 23088 23089'ssmsubMN4' 23090 Like 'msubMN4', but all involved operations must be 23091 signed-saturating. 23092 23093'usmsubMN4' 23094 Like 'umsubMN4', but all involved operations must be 23095 unsigned-saturating. 23096 23097'divmodM4' 23098 Signed division that produces both a quotient and a remainder. 23099 Operand 1 is divided by operand 2 to produce a quotient stored in 23100 operand 0 and a remainder stored in operand 3. 23101 23102 For machines with an instruction that produces both a quotient and 23103 a remainder, provide a pattern for 'divmodM4' but do not provide 23104 patterns for 'divM3' and 'modM3'. This allows optimization in the 23105 relatively common case when both the quotient and remainder are 23106 computed. 23107 23108 If an instruction that just produces a quotient or just a remainder 23109 exists and is more efficient than the instruction that produces 23110 both, write the output routine of 'divmodM4' to call 23111 'find_reg_note' and look for a 'REG_UNUSED' note on the quotient or 23112 remainder and generate the appropriate instruction. 23113 23114'udivmodM4' 23115 Similar, but does unsigned division. 23116 23117'ashlM3', 'ssashlM3', 'usashlM3' 23118 Arithmetic-shift operand 1 left by a number of bits specified by 23119 operand 2, and store the result in operand 0. Here M is the mode 23120 of operand 0 and operand 1; operand 2's mode is specified by the 23121 instruction pattern, and the compiler will convert the operand to 23122 that mode before generating the instruction. The meaning of 23123 out-of-range shift counts can optionally be specified by 23124 'TARGET_SHIFT_TRUNCATION_MASK'. *Note 23125 TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type. 23126 23127'ashrM3', 'lshrM3', 'rotlM3', 'rotrM3' 23128 Other shift and rotate instructions, analogous to the 'ashlM3' 23129 instructions. Operand 2 is always a scalar type. 23130 23131'vashlM3', 'vashrM3', 'vlshrM3', 'vrotlM3', 'vrotrM3' 23132 Vector shift and rotate instructions that take vectors as operand 2 23133 instead of a scalar type. 23134 23135'bswapM2' 23136 Reverse the order of bytes of operand 1 and store the result in 23137 operand 0. 23138 23139'negM2', 'ssnegM2', 'usnegM2' 23140 Negate operand 1 and store the result in operand 0. 23141 23142'negvM3' 23143 Like 'negM2' but takes a 'code_label' as operand 2 and emits code 23144 to jump to it if signed overflow occurs during the negation. 23145 23146'absM2' 23147 Store the absolute value of operand 1 into operand 0. 23148 23149'sqrtM2' 23150 Store the square root of operand 1 into operand 0. 23151 23152 The 'sqrt' built-in function of C always uses the mode which 23153 corresponds to the C data type 'double' and the 'sqrtf' built-in 23154 function uses the mode which corresponds to the C data type 23155 'float'. 23156 23157'fmodM3' 23158 Store the remainder of dividing operand 1 by operand 2 into operand 23159 0, rounded towards zero to an integer. 23160 23161 The 'fmod' built-in function of C always uses the mode which 23162 corresponds to the C data type 'double' and the 'fmodf' built-in 23163 function uses the mode which corresponds to the C data type 23164 'float'. 23165 23166'remainderM3' 23167 Store the remainder of dividing operand 1 by operand 2 into operand 23168 0, rounded to the nearest integer. 23169 23170 The 'remainder' built-in function of C always uses the mode which 23171 corresponds to the C data type 'double' and the 'remainderf' 23172 built-in function uses the mode which corresponds to the C data 23173 type 'float'. 23174 23175'cosM2' 23176 Store the cosine of operand 1 into operand 0. 23177 23178 The 'cos' built-in function of C always uses the mode which 23179 corresponds to the C data type 'double' and the 'cosf' built-in 23180 function uses the mode which corresponds to the C data type 23181 'float'. 23182 23183'sinM2' 23184 Store the sine of operand 1 into operand 0. 23185 23186 The 'sin' built-in function of C always uses the mode which 23187 corresponds to the C data type 'double' and the 'sinf' built-in 23188 function uses the mode which corresponds to the C data type 23189 'float'. 23190 23191'sincosM3' 23192 Store the cosine of operand 2 into operand 0 and the sine of 23193 operand 2 into operand 1. 23194 23195 The 'sin' and 'cos' built-in functions of C always use the mode 23196 which corresponds to the C data type 'double' and the 'sinf' and 23197 'cosf' built-in function use the mode which corresponds to the C 23198 data type 'float'. Targets that can calculate the sine and cosine 23199 simultaneously can implement this pattern as opposed to 23200 implementing individual 'sinM2' and 'cosM2' patterns. The 'sin' 23201 and 'cos' built-in functions will then be expanded to the 23202 'sincosM3' pattern, with one of the output values left unused. 23203 23204'expM2' 23205 Store the exponential of operand 1 into operand 0. 23206 23207 The 'exp' built-in function of C always uses the mode which 23208 corresponds to the C data type 'double' and the 'expf' built-in 23209 function uses the mode which corresponds to the C data type 23210 'float'. 23211 23212'logM2' 23213 Store the natural logarithm of operand 1 into operand 0. 23214 23215 The 'log' built-in function of C always uses the mode which 23216 corresponds to the C data type 'double' and the 'logf' built-in 23217 function uses the mode which corresponds to the C data type 23218 'float'. 23219 23220'powM3' 23221 Store the value of operand 1 raised to the exponent operand 2 into 23222 operand 0. 23223 23224 The 'pow' built-in function of C always uses the mode which 23225 corresponds to the C data type 'double' and the 'powf' built-in 23226 function uses the mode which corresponds to the C data type 23227 'float'. 23228 23229'atan2M3' 23230 Store the arc tangent (inverse tangent) of operand 1 divided by 23231 operand 2 into operand 0, using the signs of both arguments to 23232 determine the quadrant of the result. 23233 23234 The 'atan2' built-in function of C always uses the mode which 23235 corresponds to the C data type 'double' and the 'atan2f' built-in 23236 function uses the mode which corresponds to the C data type 23237 'float'. 23238 23239'floorM2' 23240 Store the largest integral value not greater than argument. 23241 23242 The 'floor' built-in function of C always uses the mode which 23243 corresponds to the C data type 'double' and the 'floorf' built-in 23244 function uses the mode which corresponds to the C data type 23245 'float'. 23246 23247'btruncM2' 23248 Store the argument rounded to integer towards zero. 23249 23250 The 'trunc' built-in function of C always uses the mode which 23251 corresponds to the C data type 'double' and the 'truncf' built-in 23252 function uses the mode which corresponds to the C data type 23253 'float'. 23254 23255'roundM2' 23256 Store the argument rounded to integer away from zero. 23257 23258 The 'round' built-in function of C always uses the mode which 23259 corresponds to the C data type 'double' and the 'roundf' built-in 23260 function uses the mode which corresponds to the C data type 23261 'float'. 23262 23263'ceilM2' 23264 Store the argument rounded to integer away from zero. 23265 23266 The 'ceil' built-in function of C always uses the mode which 23267 corresponds to the C data type 'double' and the 'ceilf' built-in 23268 function uses the mode which corresponds to the C data type 23269 'float'. 23270 23271'nearbyintM2' 23272 Store the argument rounded according to the default rounding mode 23273 23274 The 'nearbyint' built-in function of C always uses the mode which 23275 corresponds to the C data type 'double' and the 'nearbyintf' 23276 built-in function uses the mode which corresponds to the C data 23277 type 'float'. 23278 23279'rintM2' 23280 Store the argument rounded according to the default rounding mode 23281 and raise the inexact exception when the result differs in value 23282 from the argument 23283 23284 The 'rint' built-in function of C always uses the mode which 23285 corresponds to the C data type 'double' and the 'rintf' built-in 23286 function uses the mode which corresponds to the C data type 23287 'float'. 23288 23289'lrintMN2' 23290 Convert operand 1 (valid for floating point mode M) to fixed point 23291 mode N as a signed number according to the current rounding mode 23292 and store in operand 0 (which has mode N). 23293 23294'lroundMN2' 23295 Convert operand 1 (valid for floating point mode M) to fixed point 23296 mode N as a signed number rounding to nearest and away from zero 23297 and store in operand 0 (which has mode N). 23298 23299'lfloorMN2' 23300 Convert operand 1 (valid for floating point mode M) to fixed point 23301 mode N as a signed number rounding down and store in operand 0 23302 (which has mode N). 23303 23304'lceilMN2' 23305 Convert operand 1 (valid for floating point mode M) to fixed point 23306 mode N as a signed number rounding up and store in operand 0 (which 23307 has mode N). 23308 23309'copysignM3' 23310 Store a value with the magnitude of operand 1 and the sign of 23311 operand 2 into operand 0. 23312 23313 The 'copysign' built-in function of C always uses the mode which 23314 corresponds to the C data type 'double' and the 'copysignf' 23315 built-in function uses the mode which corresponds to the C data 23316 type 'float'. 23317 23318'ffsM2' 23319 Store into operand 0 one plus the index of the least significant 23320 1-bit of operand 1. If operand 1 is zero, store zero. M is the 23321 mode of operand 0; operand 1's mode is specified by the instruction 23322 pattern, and the compiler will convert the operand to that mode 23323 before generating the instruction. 23324 23325 The 'ffs' built-in function of C always uses the mode which 23326 corresponds to the C data type 'int'. 23327 23328'clrsbM2' 23329 Count leading redundant sign bits. Store into operand 0 the number 23330 of redundant sign bits in operand 1, starting at the most 23331 significant bit position. A redundant sign bit is defined as any 23332 sign bit after the first. As such, this count will be one less 23333 than the count of leading sign bits. 23334 23335'clzM2' 23336 Store into operand 0 the number of leading 0-bits in operand 1, 23337 starting at the most significant bit position. If operand 1 is 0, 23338 the 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 23339 result is undefined or has a useful value. M is the mode of 23340 operand 0; operand 1's mode is specified by the instruction 23341 pattern, and the compiler will convert the operand to that mode 23342 before generating the instruction. 23343 23344'ctzM2' 23345 Store into operand 0 the number of trailing 0-bits in operand 1, 23346 starting at the least significant bit position. If operand 1 is 0, 23347 the 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 23348 result is undefined or has a useful value. M is the mode of 23349 operand 0; operand 1's mode is specified by the instruction 23350 pattern, and the compiler will convert the operand to that mode 23351 before generating the instruction. 23352 23353'popcountM2' 23354 Store into operand 0 the number of 1-bits in operand 1. M is the 23355 mode of operand 0; operand 1's mode is specified by the instruction 23356 pattern, and the compiler will convert the operand to that mode 23357 before generating the instruction. 23358 23359'parityM2' 23360 Store into operand 0 the parity of operand 1, i.e. the number of 23361 1-bits in operand 1 modulo 2. M is the mode of operand 0; operand 23362 1's mode is specified by the instruction pattern, and the compiler 23363 will convert the operand to that mode before generating the 23364 instruction. 23365 23366'one_cmplM2' 23367 Store the bitwise-complement of operand 1 into operand 0. 23368 23369'movmemM' 23370 Block move instruction. The destination and source blocks of 23371 memory are the first two operands, and both are 'mem:BLK's with an 23372 address in mode 'Pmode'. 23373 23374 The number of bytes to move is the third operand, in mode M. 23375 Usually, you specify 'Pmode' for M. However, if you can generate 23376 better code knowing the range of valid lengths is smaller than 23377 those representable in a full Pmode pointer, you should provide a 23378 pattern with a mode corresponding to the range of values you can 23379 handle efficiently (e.g., 'QImode' for values in the range 0-127; 23380 note we avoid numbers that appear negative) and also a pattern with 23381 'Pmode'. 23382 23383 The fourth operand is the known shared alignment of the source and 23384 destination, in the form of a 'const_int' rtx. Thus, if the 23385 compiler knows that both source and destination are word-aligned, 23386 it may provide the value 4 for this operand. 23387 23388 Optional operands 5 and 6 specify expected alignment and size of 23389 block respectively. The expected alignment differs from alignment 23390 in operand 4 in a way that the blocks are not required to be 23391 aligned according to it in all cases. This expected alignment is 23392 also in bytes, just like operand 4. Expected size, when unknown, 23393 is set to '(const_int -1)'. 23394 23395 Descriptions of multiple 'movmemM' patterns can only be beneficial 23396 if the patterns for smaller modes have fewer restrictions on their 23397 first, second and fourth operands. Note that the mode M in 23398 'movmemM' does not impose any restriction on the mode of 23399 individually moved data units in the block. 23400 23401 These patterns need not give special consideration to the 23402 possibility that the source and destination strings might overlap. 23403 23404'movstr' 23405 String copy instruction, with 'stpcpy' semantics. Operand 0 is an 23406 output operand in mode 'Pmode'. The addresses of the destination 23407 and source strings are operands 1 and 2, and both are 'mem:BLK's 23408 with addresses in mode 'Pmode'. The execution of the expansion of 23409 this pattern should store in operand 0 the address in which the 23410 'NUL' terminator was stored in the destination string. 23411 23412 This patern has also several optional operands that are same as in 23413 'setmem'. 23414 23415'setmemM' 23416 Block set instruction. The destination string is the first 23417 operand, given as a 'mem:BLK' whose address is in mode 'Pmode'. 23418 The number of bytes to set is the second operand, in mode M. The 23419 value to initialize the memory with is the third operand. Targets 23420 that only support the clearing of memory should reject any value 23421 that is not the constant 0. See 'movmemM' for a discussion of the 23422 choice of mode. 23423 23424 The fourth operand is the known alignment of the destination, in 23425 the form of a 'const_int' rtx. Thus, if the compiler knows that 23426 the destination is word-aligned, it may provide the value 4 for 23427 this operand. 23428 23429 Optional operands 5 and 6 specify expected alignment and size of 23430 block respectively. The expected alignment differs from alignment 23431 in operand 4 in a way that the blocks are not required to be 23432 aligned according to it in all cases. This expected alignment is 23433 also in bytes, just like operand 4. Expected size, when unknown, 23434 is set to '(const_int -1)'. Operand 7 is the minimal size of the 23435 block and operand 8 is the maximal size of the block (NULL if it 23436 can not be represented as CONST_INT). Operand 9 is the probable 23437 maximal size (i.e. we can not rely on it for correctness, but it 23438 can be used for choosing proper code sequence for a given size). 23439 23440 The use for multiple 'setmemM' is as for 'movmemM'. 23441 23442'cmpstrnM' 23443 String compare instruction, with five operands. Operand 0 is the 23444 output; it has mode M. The remaining four operands are like the 23445 operands of 'movmemM'. The two memory blocks specified are 23446 compared byte by byte in lexicographic order starting at the 23447 beginning of each string. The instruction is not allowed to 23448 prefetch more than one byte at a time since either string may end 23449 in the first byte and reading past that may access an invalid page 23450 or segment and cause a fault. The comparison terminates early if 23451 the fetched bytes are different or if they are equal to zero. The 23452 effect of the instruction is to store a value in operand 0 whose 23453 sign indicates the result of the comparison. 23454 23455'cmpstrM' 23456 String compare instruction, without known maximum length. Operand 23457 0 is the output; it has mode M. The second and third operand are 23458 the blocks of memory to be compared; both are 'mem:BLK' with an 23459 address in mode 'Pmode'. 23460 23461 The fourth operand is the known shared alignment of the source and 23462 destination, in the form of a 'const_int' rtx. Thus, if the 23463 compiler knows that both source and destination are word-aligned, 23464 it may provide the value 4 for this operand. 23465 23466 The two memory blocks specified are compared byte by byte in 23467 lexicographic order starting at the beginning of each string. The 23468 instruction is not allowed to prefetch more than one byte at a time 23469 since either string may end in the first byte and reading past that 23470 may access an invalid page or segment and cause a fault. The 23471 comparison will terminate when the fetched bytes are different or 23472 if they are equal to zero. The effect of the instruction is to 23473 store a value in operand 0 whose sign indicates the result of the 23474 comparison. 23475 23476'cmpmemM' 23477 Block compare instruction, with five operands like the operands of 23478 'cmpstrM'. The two memory blocks specified are compared byte by 23479 byte in lexicographic order starting at the beginning of each 23480 block. Unlike 'cmpstrM' the instruction can prefetch any bytes in 23481 the two memory blocks. Also unlike 'cmpstrM' the comparison will 23482 not stop if both bytes are zero. The effect of the instruction is 23483 to store a value in operand 0 whose sign indicates the result of 23484 the comparison. 23485 23486'strlenM' 23487 Compute the length of a string, with three operands. Operand 0 is 23488 the result (of mode M), operand 1 is a 'mem' referring to the first 23489 character of the string, operand 2 is the character to search for 23490 (normally zero), and operand 3 is a constant describing the known 23491 alignment of the beginning of the string. 23492 23493'floatMN2' 23494 Convert signed integer operand 1 (valid for fixed point mode M) to 23495 floating point mode N and store in operand 0 (which has mode N). 23496 23497'floatunsMN2' 23498 Convert unsigned integer operand 1 (valid for fixed point mode M) 23499 to floating point mode N and store in operand 0 (which has mode N). 23500 23501'fixMN2' 23502 Convert operand 1 (valid for floating point mode M) to fixed point 23503 mode N as a signed number and store in operand 0 (which has mode 23504 N). This instruction's result is defined only when the value of 23505 operand 1 is an integer. 23506 23507 If the machine description defines this pattern, it also needs to 23508 define the 'ftrunc' pattern. 23509 23510'fixunsMN2' 23511 Convert operand 1 (valid for floating point mode M) to fixed point 23512 mode N as an unsigned number and store in operand 0 (which has mode 23513 N). This instruction's result is defined only when the value of 23514 operand 1 is an integer. 23515 23516'ftruncM2' 23517 Convert operand 1 (valid for floating point mode M) to an integer 23518 value, still represented in floating point mode M, and store it in 23519 operand 0 (valid for floating point mode M). 23520 23521'fix_truncMN2' 23522 Like 'fixMN2' but works for any floating point value of mode M by 23523 converting the value to an integer. 23524 23525'fixuns_truncMN2' 23526 Like 'fixunsMN2' but works for any floating point value of mode M 23527 by converting the value to an integer. 23528 23529'truncMN2' 23530 Truncate operand 1 (valid for mode M) to mode N and store in 23531 operand 0 (which has mode N). Both modes must be fixed point or 23532 both floating point. 23533 23534'extendMN2' 23535 Sign-extend operand 1 (valid for mode M) to mode N and store in 23536 operand 0 (which has mode N). Both modes must be fixed point or 23537 both floating point. 23538 23539'zero_extendMN2' 23540 Zero-extend operand 1 (valid for mode M) to mode N and store in 23541 operand 0 (which has mode N). Both modes must be fixed point. 23542 23543'fractMN2' 23544 Convert operand 1 of mode M to mode N and store in operand 0 (which 23545 has mode N). Mode M and mode N could be fixed-point to 23546 fixed-point, signed integer to fixed-point, fixed-point to signed 23547 integer, floating-point to fixed-point, or fixed-point to 23548 floating-point. When overflows or underflows happen, the results 23549 are undefined. 23550 23551'satfractMN2' 23552 Convert operand 1 of mode M to mode N and store in operand 0 (which 23553 has mode N). Mode M and mode N could be fixed-point to 23554 fixed-point, signed integer to fixed-point, or floating-point to 23555 fixed-point. When overflows or underflows happen, the instruction 23556 saturates the results to the maximum or the minimum. 23557 23558'fractunsMN2' 23559 Convert operand 1 of mode M to mode N and store in operand 0 (which 23560 has mode N). Mode M and mode N could be unsigned integer to 23561 fixed-point, or fixed-point to unsigned integer. When overflows or 23562 underflows happen, the results are undefined. 23563 23564'satfractunsMN2' 23565 Convert unsigned integer operand 1 of mode M to fixed-point mode N 23566 and store in operand 0 (which has mode N). When overflows or 23567 underflows happen, the instruction saturates the results to the 23568 maximum or the minimum. 23569 23570'extvM' 23571 Extract a bit-field from register operand 1, sign-extend it, and 23572 store it in operand 0. Operand 2 specifies the width of the field 23573 in bits and operand 3 the starting bit, which counts from the most 23574 significant bit if 'BITS_BIG_ENDIAN' is true and from the least 23575 significant bit otherwise. 23576 23577 Operands 0 and 1 both have mode M. Operands 2 and 3 have a 23578 target-specific mode. 23579 23580'extvmisalignM' 23581 Extract a bit-field from memory operand 1, sign extend it, and 23582 store it in operand 0. Operand 2 specifies the width in bits and 23583 operand 3 the starting bit. The starting bit is always somewhere 23584 in the first byte of operand 1; it counts from the most significant 23585 bit if 'BITS_BIG_ENDIAN' is true and from the least significant bit 23586 otherwise. 23587 23588 Operand 0 has mode M while operand 1 has 'BLK' mode. Operands 2 23589 and 3 have a target-specific mode. 23590 23591 The instruction must not read beyond the last byte of the 23592 bit-field. 23593 23594'extzvM' 23595 Like 'extvM' except that the bit-field value is zero-extended. 23596 23597'extzvmisalignM' 23598 Like 'extvmisalignM' except that the bit-field value is 23599 zero-extended. 23600 23601'insvM' 23602 Insert operand 3 into a bit-field of register operand 0. Operand 1 23603 specifies the width of the field in bits and operand 2 the starting 23604 bit, which counts from the most significant bit if 23605 'BITS_BIG_ENDIAN' is true and from the least significant bit 23606 otherwise. 23607 23608 Operands 0 and 3 both have mode M. Operands 1 and 2 have a 23609 target-specific mode. 23610 23611'insvmisalignM' 23612 Insert operand 3 into a bit-field of memory operand 0. Operand 1 23613 specifies the width of the field in bits and operand 2 the starting 23614 bit. The starting bit is always somewhere in the first byte of 23615 operand 0; it counts from the most significant bit if 23616 'BITS_BIG_ENDIAN' is true and from the least significant bit 23617 otherwise. 23618 23619 Operand 3 has mode M while operand 0 has 'BLK' mode. Operands 1 23620 and 2 have a target-specific mode. 23621 23622 The instruction must not read or write beyond the last byte of the 23623 bit-field. 23624 23625'extv' 23626 Extract a bit-field from operand 1 (a register or memory operand), 23627 where operand 2 specifies the width in bits and operand 3 the 23628 starting bit, and store it in operand 0. Operand 0 must have mode 23629 'word_mode'. Operand 1 may have mode 'byte_mode' or 'word_mode'; 23630 often 'word_mode' is allowed only for registers. Operands 2 and 3 23631 must be valid for 'word_mode'. 23632 23633 The RTL generation pass generates this instruction only with 23634 constants for operands 2 and 3 and the constant is never zero for 23635 operand 2. 23636 23637 The bit-field value is sign-extended to a full word integer before 23638 it is stored in operand 0. 23639 23640 This pattern is deprecated; please use 'extvM' and 'extvmisalignM' 23641 instead. 23642 23643'extzv' 23644 Like 'extv' except that the bit-field value is zero-extended. 23645 23646 This pattern is deprecated; please use 'extzvM' and 23647 'extzvmisalignM' instead. 23648 23649'insv' 23650 Store operand 3 (which must be valid for 'word_mode') into a 23651 bit-field in operand 0, where operand 1 specifies the width in bits 23652 and operand 2 the starting bit. Operand 0 may have mode 23653 'byte_mode' or 'word_mode'; often 'word_mode' is allowed only for 23654 registers. Operands 1 and 2 must be valid for 'word_mode'. 23655 23656 The RTL generation pass generates this instruction only with 23657 constants for operands 1 and 2 and the constant is never zero for 23658 operand 1. 23659 23660 This pattern is deprecated; please use 'insvM' and 'insvmisalignM' 23661 instead. 23662 23663'movMODEcc' 23664 Conditionally move operand 2 or operand 3 into operand 0 according 23665 to the comparison in operand 1. If the comparison is true, operand 23666 2 is moved into operand 0, otherwise operand 3 is moved. 23667 23668 The mode of the operands being compared need not be the same as the 23669 operands being moved. Some machines, sparc64 for example, have 23670 instructions that conditionally move an integer value based on the 23671 floating point condition codes and vice versa. 23672 23673 If the machine does not have conditional move instructions, do not 23674 define these patterns. 23675 23676'addMODEcc' 23677 Similar to 'movMODEcc' but for conditional addition. Conditionally 23678 move operand 2 or (operands 2 + operand 3) into operand 0 according 23679 to the comparison in operand 1. If the comparison is false, 23680 operand 2 is moved into operand 0, otherwise (operand 2 + operand 23681 3) is moved. 23682 23683'cstoreMODE4' 23684 Store zero or nonzero in operand 0 according to whether a 23685 comparison is true. Operand 1 is a comparison operator. Operand 2 23686 and operand 3 are the first and second operand of the comparison, 23687 respectively. You specify the mode that operand 0 must have when 23688 you write the 'match_operand' expression. The compiler 23689 automatically sees which mode you have used and supplies an operand 23690 of that mode. 23691 23692 The value stored for a true condition must have 1 as its low bit, 23693 or else must be negative. Otherwise the instruction is not 23694 suitable and you should omit it from the machine description. You 23695 describe to the compiler exactly which value is stored by defining 23696 the macro 'STORE_FLAG_VALUE' (*note Misc::). If a description 23697 cannot be found that can be used for all the possible comparison 23698 operators, you should pick one and use a 'define_expand' to map all 23699 results onto the one you chose. 23700 23701 These operations may 'FAIL', but should do so only in relatively 23702 uncommon cases; if they would 'FAIL' for common cases involving 23703 integer comparisons, it is best to restrict the predicates to not 23704 allow these operands. Likewise if a given comparison operator will 23705 always fail, independent of the operands (for floating-point modes, 23706 the 'ordered_comparison_operator' predicate is often useful in this 23707 case). 23708 23709 If this pattern is omitted, the compiler will generate a 23710 conditional branch--for example, it may copy a constant one to the 23711 target and branching around an assignment of zero to the target--or 23712 a libcall. If the predicate for operand 1 only rejects some 23713 operators, it will also try reordering the operands and/or 23714 inverting the result value (e.g. by an exclusive OR). These 23715 possibilities could be cheaper or equivalent to the instructions 23716 used for the 'cstoreMODE4' pattern followed by those required to 23717 convert a positive result from 'STORE_FLAG_VALUE' to 1; in this 23718 case, you can and should make operand 1's predicate reject some 23719 operators in the 'cstoreMODE4' pattern, or remove the pattern 23720 altogether from the machine description. 23721 23722'cbranchMODE4' 23723 Conditional branch instruction combined with a compare instruction. 23724 Operand 0 is a comparison operator. Operand 1 and operand 2 are 23725 the first and second operands of the comparison, respectively. 23726 Operand 3 is the 'code_label' to jump to. 23727 23728'jump' 23729 A jump inside a function; an unconditional branch. Operand 0 is 23730 the 'code_label' to jump to. This pattern name is mandatory on all 23731 machines. 23732 23733'call' 23734 Subroutine call instruction returning no value. Operand 0 is the 23735 function to call; operand 1 is the number of bytes of arguments 23736 pushed as a 'const_int'; operand 2 is the number of registers used 23737 as operands. 23738 23739 On most machines, operand 2 is not actually stored into the RTL 23740 pattern. It is supplied for the sake of some RISC machines which 23741 need to put this information into the assembler code; they can put 23742 it in the RTL instead of operand 1. 23743 23744 Operand 0 should be a 'mem' RTX whose address is the address of the 23745 function. Note, however, that this address can be a 'symbol_ref' 23746 expression even if it would not be a legitimate memory address on 23747 the target machine. If it is also not a valid argument for a call 23748 instruction, the pattern for this operation should be a 23749 'define_expand' (*note Expander Definitions::) that places the 23750 address into a register and uses that register in the call 23751 instruction. 23752 23753'call_value' 23754 Subroutine call instruction returning a value. Operand 0 is the 23755 hard register in which the value is returned. There are three more 23756 operands, the same as the three operands of the 'call' instruction 23757 (but with numbers increased by one). 23758 23759 Subroutines that return 'BLKmode' objects use the 'call' insn. 23760 23761'call_pop', 'call_value_pop' 23762 Similar to 'call' and 'call_value', except used if defined and if 23763 'RETURN_POPS_ARGS' is nonzero. They should emit a 'parallel' that 23764 contains both the function call and a 'set' to indicate the 23765 adjustment made to the frame pointer. 23766 23767 For machines where 'RETURN_POPS_ARGS' can be nonzero, the use of 23768 these patterns increases the number of functions for which the 23769 frame pointer can be eliminated, if desired. 23770 23771'untyped_call' 23772 Subroutine call instruction returning a value of any type. Operand 23773 0 is the function to call; operand 1 is a memory location where the 23774 result of calling the function is to be stored; operand 2 is a 23775 'parallel' expression where each element is a 'set' expression that 23776 indicates the saving of a function return value into the result 23777 block. 23778 23779 This instruction pattern should be defined to support 23780 '__builtin_apply' on machines where special instructions are needed 23781 to call a subroutine with arbitrary arguments or to save the value 23782 returned. This instruction pattern is required on machines that 23783 have multiple registers that can hold a return value (i.e. 23784 'FUNCTION_VALUE_REGNO_P' is true for more than one register). 23785 23786'return' 23787 Subroutine return instruction. This instruction pattern name 23788 should be defined only if a single instruction can do all the work 23789 of returning from a function. 23790 23791 Like the 'movM' patterns, this pattern is also used after the RTL 23792 generation phase. In this case it is to support machines where 23793 multiple instructions are usually needed to return from a function, 23794 but some class of functions only requires one instruction to 23795 implement a return. Normally, the applicable functions are those 23796 which do not need to save any registers or allocate stack space. 23797 23798 It is valid for this pattern to expand to an instruction using 23799 'simple_return' if no epilogue is required. 23800 23801'simple_return' 23802 Subroutine return instruction. This instruction pattern name 23803 should be defined only if a single instruction can do all the work 23804 of returning from a function on a path where no epilogue is 23805 required. This pattern is very similar to the 'return' instruction 23806 pattern, but it is emitted only by the shrink-wrapping optimization 23807 on paths where the function prologue has not been executed, and a 23808 function return should occur without any of the effects of the 23809 epilogue. Additional uses may be introduced on paths where both 23810 the prologue and the epilogue have executed. 23811 23812 For such machines, the condition specified in this pattern should 23813 only be true when 'reload_completed' is nonzero and the function's 23814 epilogue would only be a single instruction. For machines with 23815 register windows, the routine 'leaf_function_p' may be used to 23816 determine if a register window push is required. 23817 23818 Machines that have conditional return instructions should define 23819 patterns such as 23820 23821 (define_insn "" 23822 [(set (pc) 23823 (if_then_else (match_operator 23824 0 "comparison_operator" 23825 [(cc0) (const_int 0)]) 23826 (return) 23827 (pc)))] 23828 "CONDITION" 23829 "...") 23830 23831 where CONDITION would normally be the same condition specified on 23832 the named 'return' pattern. 23833 23834'untyped_return' 23835 Untyped subroutine return instruction. This instruction pattern 23836 should be defined to support '__builtin_return' on machines where 23837 special instructions are needed to return a value of any type. 23838 23839 Operand 0 is a memory location where the result of calling a 23840 function with '__builtin_apply' is stored; operand 1 is a 23841 'parallel' expression where each element is a 'set' expression that 23842 indicates the restoring of a function return value from the result 23843 block. 23844 23845'nop' 23846 No-op instruction. This instruction pattern name should always be 23847 defined to output a no-op in assembler code. '(const_int 0)' will 23848 do as an RTL pattern. 23849 23850'indirect_jump' 23851 An instruction to jump to an address which is operand zero. This 23852 pattern name is mandatory on all machines. 23853 23854'casesi' 23855 Instruction to jump through a dispatch table, including bounds 23856 checking. This instruction takes five operands: 23857 23858 1. The index to dispatch on, which has mode 'SImode'. 23859 23860 2. The lower bound for indices in the table, an integer constant. 23861 23862 3. The total range of indices in the table--the largest index 23863 minus the smallest one (both inclusive). 23864 23865 4. A label that precedes the table itself. 23866 23867 5. A label to jump to if the index has a value outside the 23868 bounds. 23869 23870 The table is an 'addr_vec' or 'addr_diff_vec' inside of a 23871 'jump_table_data'. The number of elements in the table is one plus 23872 the difference between the upper bound and the lower bound. 23873 23874'tablejump' 23875 Instruction to jump to a variable address. This is a low-level 23876 capability which can be used to implement a dispatch table when 23877 there is no 'casesi' pattern. 23878 23879 This pattern requires two operands: the address or offset, and a 23880 label which should immediately precede the jump table. If the 23881 macro 'CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 23882 the first operand is an offset which counts from the address of the 23883 table; otherwise, it is an absolute address to jump to. In either 23884 case, the first operand has mode 'Pmode'. 23885 23886 The 'tablejump' insn is always the last insn before the jump table 23887 it uses. Its assembler code normally has no need to use the second 23888 operand, but you should incorporate it in the RTL pattern so that 23889 the jump optimizer will not delete the table as unreachable code. 23890 23891'decrement_and_branch_until_zero' 23892 Conditional branch instruction that decrements a register and jumps 23893 if the register is nonzero. Operand 0 is the register to decrement 23894 and test; operand 1 is the label to jump to if the register is 23895 nonzero. *Note Looping Patterns::. 23896 23897 This optional instruction pattern is only used by the combiner, 23898 typically for loops reversed by the loop optimizer when strength 23899 reduction is enabled. 23900 23901'doloop_end' 23902 Conditional branch instruction that decrements a register and jumps 23903 if the register is nonzero. Operand 0 is the register to decrement 23904 and test; operand 1 is the label to jump to if the register is 23905 nonzero. *Note Looping Patterns::. 23906 23907 This optional instruction pattern should be defined for machines 23908 with low-overhead looping instructions as the loop optimizer will 23909 try to modify suitable loops to utilize it. The target hook 23910 'TARGET_CAN_USE_DOLOOP_P' controls the conditions under which 23911 low-overhead loops can be used. 23912 23913'doloop_begin' 23914 Companion instruction to 'doloop_end' required for machines that 23915 need to perform some initialization, such as loading a special 23916 counter register. Operand 1 is the associated 'doloop_end' pattern 23917 and operand 0 is the register that it decrements. 23918 23919 If initialization insns do not always need to be emitted, use a 23920 'define_expand' (*note Expander Definitions::) and make it fail. 23921 23922'canonicalize_funcptr_for_compare' 23923 Canonicalize the function pointer in operand 1 and store the result 23924 into operand 0. 23925 23926 Operand 0 is always a 'reg' and has mode 'Pmode'; operand 1 may be 23927 a 'reg', 'mem', 'symbol_ref', 'const_int', etc and also has mode 23928 'Pmode'. 23929 23930 Canonicalization of a function pointer usually involves computing 23931 the address of the function which would be called if the function 23932 pointer were used in an indirect call. 23933 23934 Only define this pattern if function pointers on the target machine 23935 can have different values but still call the same function when 23936 used in an indirect call. 23937 23938'save_stack_block' 23939'save_stack_function' 23940'save_stack_nonlocal' 23941'restore_stack_block' 23942'restore_stack_function' 23943'restore_stack_nonlocal' 23944 Most machines save and restore the stack pointer by copying it to 23945 or from an object of mode 'Pmode'. Do not define these patterns on 23946 such machines. 23947 23948 Some machines require special handling for stack pointer saves and 23949 restores. On those machines, define the patterns corresponding to 23950 the non-standard cases by using a 'define_expand' (*note Expander 23951 Definitions::) that produces the required insns. The three types 23952 of saves and restores are: 23953 23954 1. 'save_stack_block' saves the stack pointer at the start of a 23955 block that allocates a variable-sized object, and 23956 'restore_stack_block' restores the stack pointer when the 23957 block is exited. 23958 23959 2. 'save_stack_function' and 'restore_stack_function' do a 23960 similar job for the outermost block of a function and are used 23961 when the function allocates variable-sized objects or calls 23962 'alloca'. Only the epilogue uses the restored stack pointer, 23963 allowing a simpler save or restore sequence on some machines. 23964 23965 3. 'save_stack_nonlocal' is used in functions that contain labels 23966 branched to by nested functions. It saves the stack pointer 23967 in such a way that the inner function can use 23968 'restore_stack_nonlocal' to restore the stack pointer. The 23969 compiler generates code to restore the frame and argument 23970 pointer registers, but some machines require saving and 23971 restoring additional data such as register window information 23972 or stack backchains. Place insns in these patterns to save 23973 and restore any such required data. 23974 23975 When saving the stack pointer, operand 0 is the save area and 23976 operand 1 is the stack pointer. The mode used to allocate the save 23977 area defaults to 'Pmode' but you can override that choice by 23978 defining the 'STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 23979 You must specify an integral mode, or 'VOIDmode' if no save area is 23980 needed for a particular type of save (either because no save is 23981 needed or because a machine-specific save area can be used). 23982 Operand 0 is the stack pointer and operand 1 is the save area for 23983 restore operations. If 'save_stack_block' is defined, operand 0 23984 must not be 'VOIDmode' since these saves can be arbitrarily nested. 23985 23986 A save area is a 'mem' that is at a constant offset from 23987 'virtual_stack_vars_rtx' when the stack pointer is saved for use by 23988 nonlocal gotos and a 'reg' in the other two cases. 23989 23990'allocate_stack' 23991 Subtract (or add if 'STACK_GROWS_DOWNWARD' is undefined) operand 1 23992 from the stack pointer to create space for dynamically allocated 23993 data. 23994 23995 Store the resultant pointer to this space into operand 0. If you 23996 are allocating space from the main stack, do this by emitting a 23997 move insn to copy 'virtual_stack_dynamic_rtx' to operand 0. If you 23998 are allocating the space elsewhere, generate code to copy the 23999 location of the space to operand 0. In the latter case, you must 24000 ensure this space gets freed when the corresponding space on the 24001 main stack is free. 24002 24003 Do not define this pattern if all that must be done is the 24004 subtraction. Some machines require other operations such as stack 24005 probes or maintaining the back chain. Define this pattern to emit 24006 those operations in addition to updating the stack pointer. 24007 24008'check_stack' 24009 If stack checking (*note Stack Checking::) cannot be done on your 24010 system by probing the stack, define this pattern to perform the 24011 needed check and signal an error if the stack has overflowed. The 24012 single operand is the address in the stack farthest from the 24013 current stack pointer that you need to validate. Normally, on 24014 platforms where this pattern is needed, you would obtain the stack 24015 limit from a global or thread-specific variable or register. 24016 24017'probe_stack_address' 24018 If stack checking (*note Stack Checking::) can be done on your 24019 system by probing the stack but without the need to actually access 24020 it, define this pattern and signal an error if the stack has 24021 overflowed. The single operand is the memory address in the stack 24022 that needs to be probed. 24023 24024'probe_stack' 24025 If stack checking (*note Stack Checking::) can be done on your 24026 system by probing the stack but doing it with a "store zero" 24027 instruction is not valid or optimal, define this pattern to do the 24028 probing differently and signal an error if the stack has 24029 overflowed. The single operand is the memory reference in the 24030 stack that needs to be probed. 24031 24032'nonlocal_goto' 24033 Emit code to generate a non-local goto, e.g., a jump from one 24034 function to a label in an outer function. This pattern has four 24035 arguments, each representing a value to be used in the jump. The 24036 first argument is to be loaded into the frame pointer, the second 24037 is the address to branch to (code to dispatch to the actual label), 24038 the third is the address of a location where the stack is saved, 24039 and the last is the address of the label, to be placed in the 24040 location for the incoming static chain. 24041 24042 On most machines you need not define this pattern, since GCC will 24043 already generate the correct code, which is to load the frame 24044 pointer and static chain, restore the stack (using the 24045 'restore_stack_nonlocal' pattern, if defined), and jump indirectly 24046 to the dispatcher. You need only define this pattern if this code 24047 will not work on your machine. 24048 24049'nonlocal_goto_receiver' 24050 This pattern, if defined, contains code needed at the target of a 24051 nonlocal goto after the code already generated by GCC. You will 24052 not normally need to define this pattern. A typical reason why you 24053 might need this pattern is if some value, such as a pointer to a 24054 global table, must be restored when the frame pointer is restored. 24055 Note that a nonlocal goto only occurs within a unit-of-translation, 24056 so a global table pointer that is shared by all functions of a 24057 given module need not be restored. There are no arguments. 24058 24059'exception_receiver' 24060 This pattern, if defined, contains code needed at the site of an 24061 exception handler that isn't needed at the site of a nonlocal goto. 24062 You will not normally need to define this pattern. A typical 24063 reason why you might need this pattern is if some value, such as a 24064 pointer to a global table, must be restored after control flow is 24065 branched to the handler of an exception. There are no arguments. 24066 24067'builtin_setjmp_setup' 24068 This pattern, if defined, contains additional code needed to 24069 initialize the 'jmp_buf'. You will not normally need to define 24070 this pattern. A typical reason why you might need this pattern is 24071 if some value, such as a pointer to a global table, must be 24072 restored. Though it is preferred that the pointer value be 24073 recalculated if possible (given the address of a label for 24074 instance). The single argument is a pointer to the 'jmp_buf'. 24075 Note that the buffer is five words long and that the first three 24076 are normally used by the generic mechanism. 24077 24078'builtin_setjmp_receiver' 24079 This pattern, if defined, contains code needed at the site of a 24080 built-in setjmp that isn't needed at the site of a nonlocal goto. 24081 You will not normally need to define this pattern. A typical 24082 reason why you might need this pattern is if some value, such as a 24083 pointer to a global table, must be restored. It takes one 24084 argument, which is the label to which builtin_longjmp transferred 24085 control; this pattern may be emitted at a small offset from that 24086 label. 24087 24088'builtin_longjmp' 24089 This pattern, if defined, performs the entire action of the 24090 longjmp. You will not normally need to define this pattern unless 24091 you also define 'builtin_setjmp_setup'. The single argument is a 24092 pointer to the 'jmp_buf'. 24093 24094'eh_return' 24095 This pattern, if defined, affects the way '__builtin_eh_return', 24096 and thence the call frame exception handling library routines, are 24097 built. It is intended to handle non-trivial actions needed along 24098 the abnormal return path. 24099 24100 The address of the exception handler to which the function should 24101 return is passed as operand to this pattern. It will normally need 24102 to copied by the pattern to some special register or memory 24103 location. If the pattern needs to determine the location of the 24104 target call frame in order to do so, it may use 24105 'EH_RETURN_STACKADJ_RTX', if defined; it will have already been 24106 assigned. 24107 24108 If this pattern is not defined, the default action will be to 24109 simply copy the return address to 'EH_RETURN_HANDLER_RTX'. Either 24110 that macro or this pattern needs to be defined if call frame 24111 exception handling is to be used. 24112 24113'prologue' 24114 This pattern, if defined, emits RTL for entry to a function. The 24115 function entry is responsible for setting up the stack frame, 24116 initializing the frame pointer register, saving callee saved 24117 registers, etc. 24118 24119 Using a prologue pattern is generally preferred over defining 24120 'TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 24121 prologue. 24122 24123 The 'prologue' pattern is particularly useful for targets which 24124 perform instruction scheduling. 24125 24126'window_save' 24127 This pattern, if defined, emits RTL for a register window save. It 24128 should be defined if the target machine has register windows but 24129 the window events are decoupled from calls to subroutines. The 24130 canonical example is the SPARC architecture. 24131 24132'epilogue' 24133 This pattern emits RTL for exit from a function. The function exit 24134 is responsible for deallocating the stack frame, restoring callee 24135 saved registers and emitting the return instruction. 24136 24137 Using an epilogue pattern is generally preferred over defining 24138 'TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 24139 epilogue. 24140 24141 The 'epilogue' pattern is particularly useful for targets which 24142 perform instruction scheduling or which have delay slots for their 24143 return instruction. 24144 24145'sibcall_epilogue' 24146 This pattern, if defined, emits RTL for exit from a function 24147 without the final branch back to the calling function. This 24148 pattern will be emitted before any sibling call (aka tail call) 24149 sites. 24150 24151 The 'sibcall_epilogue' pattern must not clobber any arguments used 24152 for parameter passing or any stack slots for arguments passed to 24153 the current function. 24154 24155'trap' 24156 This pattern, if defined, signals an error, typically by causing 24157 some kind of signal to be raised. Among other places, it is used 24158 by the Java front end to signal 'invalid array index' exceptions. 24159 24160'ctrapMM4' 24161 Conditional trap instruction. Operand 0 is a piece of RTL which 24162 performs a comparison, and operands 1 and 2 are the arms of the 24163 comparison. Operand 3 is the trap code, an integer. 24164 24165 A typical 'ctrap' pattern looks like 24166 24167 (define_insn "ctrapsi4" 24168 [(trap_if (match_operator 0 "trap_operator" 24169 [(match_operand 1 "register_operand") 24170 (match_operand 2 "immediate_operand")]) 24171 (match_operand 3 "const_int_operand" "i"))] 24172 "" 24173 "...") 24174 24175'prefetch' 24176 This pattern, if defined, emits code for a non-faulting data 24177 prefetch instruction. Operand 0 is the address of the memory to 24178 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 24179 for a write to the memory address, or a constant 0 otherwise. 24180 Operand 2 is the expected degree of temporal locality of the data 24181 and is a value between 0 and 3, inclusive; 0 means that the data 24182 has no temporal locality, so it need not be left in the cache after 24183 the access; 3 means that the data has a high degree of temporal 24184 locality and should be left in all levels of cache possible; 1 and 24185 2 mean, respectively, a low or moderate degree of temporal 24186 locality. 24187 24188 Targets that do not support write prefetches or locality hints can 24189 ignore the values of operands 1 and 2. 24190 24191'blockage' 24192 This pattern defines a pseudo insn that prevents the instruction 24193 scheduler and other passes from moving instructions and using 24194 register equivalences across the boundary defined by the blockage 24195 insn. This needs to be an UNSPEC_VOLATILE pattern or a volatile 24196 ASM. 24197 24198'memory_barrier' 24199 If the target memory model is not fully synchronous, then this 24200 pattern should be defined to an instruction that orders both loads 24201 and stores before the instruction with respect to loads and stores 24202 after the instruction. This pattern has no operands. 24203 24204'sync_compare_and_swapMODE' 24205 This pattern, if defined, emits code for an atomic compare-and-swap 24206 operation. Operand 1 is the memory on which the atomic operation 24207 is performed. Operand 2 is the "old" value to be compared against 24208 the current contents of the memory location. Operand 3 is the 24209 "new" value to store in the memory if the compare succeeds. 24210 Operand 0 is the result of the operation; it should contain the 24211 contents of the memory before the operation. If the compare 24212 succeeds, this should obviously be a copy of operand 2. 24213 24214 This pattern must show that both operand 0 and operand 1 are 24215 modified. 24216 24217 This pattern must issue any memory barrier instructions such that 24218 all memory operations before the atomic operation occur before the 24219 atomic operation and all memory operations after the atomic 24220 operation occur after the atomic operation. 24221 24222 For targets where the success or failure of the compare-and-swap 24223 operation is available via the status flags, it is possible to 24224 avoid a separate compare operation and issue the subsequent branch 24225 or store-flag operation immediately after the compare-and-swap. To 24226 this end, GCC will look for a 'MODE_CC' set in the output of 24227 'sync_compare_and_swapMODE'; if the machine description includes 24228 such a set, the target should also define special 'cbranchcc4' 24229 and/or 'cstorecc4' instructions. GCC will then be able to take the 24230 destination of the 'MODE_CC' set and pass it to the 'cbranchcc4' or 24231 'cstorecc4' pattern as the first operand of the comparison (the 24232 second will be '(const_int 0)'). 24233 24234 For targets where the operating system may provide support for this 24235 operation via library calls, the 'sync_compare_and_swap_optab' may 24236 be initialized to a function with the same interface as the 24237 '__sync_val_compare_and_swap_N' built-in. If the entire set of 24238 __SYNC builtins are supported via library calls, the target can 24239 initialize all of the optabs at once with 'init_sync_libfuncs'. 24240 For the purposes of C++11 'std::atomic::is_lock_free', it is 24241 assumed that these library calls do _not_ use any kind of 24242 interruptable locking. 24243 24244'sync_addMODE', 'sync_subMODE' 24245'sync_iorMODE', 'sync_andMODE' 24246'sync_xorMODE', 'sync_nandMODE' 24247 These patterns emit code for an atomic operation on memory. 24248 Operand 0 is the memory on which the atomic operation is performed. 24249 Operand 1 is the second operand to the binary operator. 24250 24251 This pattern must issue any memory barrier instructions such that 24252 all memory operations before the atomic operation occur before the 24253 atomic operation and all memory operations after the atomic 24254 operation occur after the atomic operation. 24255 24256 If these patterns are not defined, the operation will be 24257 constructed from a compare-and-swap operation, if defined. 24258 24259'sync_old_addMODE', 'sync_old_subMODE' 24260'sync_old_iorMODE', 'sync_old_andMODE' 24261'sync_old_xorMODE', 'sync_old_nandMODE' 24262 These patterns emit code for an atomic operation on memory, and 24263 return the value that the memory contained before the operation. 24264 Operand 0 is the result value, operand 1 is the memory on which the 24265 atomic operation is performed, and operand 2 is the second operand 24266 to the binary operator. 24267 24268 This pattern must issue any memory barrier instructions such that 24269 all memory operations before the atomic operation occur before the 24270 atomic operation and all memory operations after the atomic 24271 operation occur after the atomic operation. 24272 24273 If these patterns are not defined, the operation will be 24274 constructed from a compare-and-swap operation, if defined. 24275 24276'sync_new_addMODE', 'sync_new_subMODE' 24277'sync_new_iorMODE', 'sync_new_andMODE' 24278'sync_new_xorMODE', 'sync_new_nandMODE' 24279 These patterns are like their 'sync_old_OP' counterparts, except 24280 that they return the value that exists in the memory location after 24281 the operation, rather than before the operation. 24282 24283'sync_lock_test_and_setMODE' 24284 This pattern takes two forms, based on the capabilities of the 24285 target. In either case, operand 0 is the result of the operand, 24286 operand 1 is the memory on which the atomic operation is performed, 24287 and operand 2 is the value to set in the lock. 24288 24289 In the ideal case, this operation is an atomic exchange operation, 24290 in which the previous value in memory operand is copied into the 24291 result operand, and the value operand is stored in the memory 24292 operand. 24293 24294 For less capable targets, any value operand that is not the 24295 constant 1 should be rejected with 'FAIL'. In this case the target 24296 may use an atomic test-and-set bit operation. The result operand 24297 should contain 1 if the bit was previously set and 0 if the bit was 24298 previously clear. The true contents of the memory operand are 24299 implementation defined. 24300 24301 This pattern must issue any memory barrier instructions such that 24302 the pattern as a whole acts as an acquire barrier, that is all 24303 memory operations after the pattern do not occur until the lock is 24304 acquired. 24305 24306 If this pattern is not defined, the operation will be constructed 24307 from a compare-and-swap operation, if defined. 24308 24309'sync_lock_releaseMODE' 24310 This pattern, if defined, releases a lock set by 24311 'sync_lock_test_and_setMODE'. Operand 0 is the memory that 24312 contains the lock; operand 1 is the value to store in the lock. 24313 24314 If the target doesn't implement full semantics for 24315 'sync_lock_test_and_setMODE', any value operand which is not the 24316 constant 0 should be rejected with 'FAIL', and the true contents of 24317 the memory operand are implementation defined. 24318 24319 This pattern must issue any memory barrier instructions such that 24320 the pattern as a whole acts as a release barrier, that is the lock 24321 is released only after all previous memory operations have 24322 completed. 24323 24324 If this pattern is not defined, then a 'memory_barrier' pattern 24325 will be emitted, followed by a store of the value to the memory 24326 operand. 24327 24328'atomic_compare_and_swapMODE' 24329 This pattern, if defined, emits code for an atomic compare-and-swap 24330 operation with memory model semantics. Operand 2 is the memory on 24331 which the atomic operation is performed. Operand 0 is an output 24332 operand which is set to true or false based on whether the 24333 operation succeeded. Operand 1 is an output operand which is set 24334 to the contents of the memory before the operation was attempted. 24335 Operand 3 is the value that is expected to be in memory. Operand 4 24336 is the value to put in memory if the expected value is found there. 24337 Operand 5 is set to 1 if this compare and swap is to be treated as 24338 a weak operation. Operand 6 is the memory model to be used if the 24339 operation is a success. Operand 7 is the memory model to be used 24340 if the operation fails. 24341 24342 If memory referred to in operand 2 contains the value in operand 3, 24343 then operand 4 is stored in memory pointed to by operand 2 and 24344 fencing based on the memory model in operand 6 is issued. 24345 24346 If memory referred to in operand 2 does not contain the value in 24347 operand 3, then fencing based on the memory model in operand 7 is 24348 issued. 24349 24350 If a target does not support weak compare-and-swap operations, or 24351 the port elects not to implement weak operations, the argument in 24352 operand 5 can be ignored. Note a strong implementation must be 24353 provided. 24354 24355 If this pattern is not provided, the '__atomic_compare_exchange' 24356 built-in functions will utilize the legacy 'sync_compare_and_swap' 24357 pattern with an '__ATOMIC_SEQ_CST' memory model. 24358 24359'atomic_loadMODE' 24360 This pattern implements an atomic load operation with memory model 24361 semantics. Operand 1 is the memory address being loaded from. 24362 Operand 0 is the result of the load. Operand 2 is the memory model 24363 to be used for the load operation. 24364 24365 If not present, the '__atomic_load' built-in function will either 24366 resort to a normal load with memory barriers, or a compare-and-swap 24367 operation if a normal load would not be atomic. 24368 24369'atomic_storeMODE' 24370 This pattern implements an atomic store operation with memory model 24371 semantics. Operand 0 is the memory address being stored to. 24372 Operand 1 is the value to be written. Operand 2 is the memory 24373 model to be used for the operation. 24374 24375 If not present, the '__atomic_store' built-in function will attempt 24376 to perform a normal store and surround it with any required memory 24377 fences. If the store would not be atomic, then an 24378 '__atomic_exchange' is attempted with the result being ignored. 24379 24380'atomic_exchangeMODE' 24381 This pattern implements an atomic exchange operation with memory 24382 model semantics. Operand 1 is the memory location the operation is 24383 performed on. Operand 0 is an output operand which is set to the 24384 original value contained in the memory pointed to by operand 1. 24385 Operand 2 is the value to be stored. Operand 3 is the memory model 24386 to be used. 24387 24388 If this pattern is not present, the built-in function 24389 '__atomic_exchange' will attempt to preform the operation with a 24390 compare and swap loop. 24391 24392'atomic_addMODE', 'atomic_subMODE' 24393'atomic_orMODE', 'atomic_andMODE' 24394'atomic_xorMODE', 'atomic_nandMODE' 24395 These patterns emit code for an atomic operation on memory with 24396 memory model semantics. Operand 0 is the memory on which the 24397 atomic operation is performed. Operand 1 is the second operand to 24398 the binary operator. Operand 2 is the memory model to be used by 24399 the operation. 24400 24401 If these patterns are not defined, attempts will be made to use 24402 legacy 'sync' patterns, or equivalent patterns which return a 24403 result. If none of these are available a compare-and-swap loop 24404 will be used. 24405 24406'atomic_fetch_addMODE', 'atomic_fetch_subMODE' 24407'atomic_fetch_orMODE', 'atomic_fetch_andMODE' 24408'atomic_fetch_xorMODE', 'atomic_fetch_nandMODE' 24409 These patterns emit code for an atomic operation on memory with 24410 memory model semantics, and return the original value. Operand 0 24411 is an output operand which contains the value of the memory 24412 location before the operation was performed. Operand 1 is the 24413 memory on which the atomic operation is performed. Operand 2 is 24414 the second operand to the binary operator. Operand 3 is the memory 24415 model to be used by the operation. 24416 24417 If these patterns are not defined, attempts will be made to use 24418 legacy 'sync' patterns. If none of these are available a 24419 compare-and-swap loop will be used. 24420 24421'atomic_add_fetchMODE', 'atomic_sub_fetchMODE' 24422'atomic_or_fetchMODE', 'atomic_and_fetchMODE' 24423'atomic_xor_fetchMODE', 'atomic_nand_fetchMODE' 24424 These patterns emit code for an atomic operation on memory with 24425 memory model semantics and return the result after the operation is 24426 performed. Operand 0 is an output operand which contains the value 24427 after the operation. Operand 1 is the memory on which the atomic 24428 operation is performed. Operand 2 is the second operand to the 24429 binary operator. Operand 3 is the memory model to be used by the 24430 operation. 24431 24432 If these patterns are not defined, attempts will be made to use 24433 legacy 'sync' patterns, or equivalent patterns which return the 24434 result before the operation followed by the arithmetic operation 24435 required to produce the result. If none of these are available a 24436 compare-and-swap loop will be used. 24437 24438'atomic_test_and_set' 24439 This pattern emits code for '__builtin_atomic_test_and_set'. 24440 Operand 0 is an output operand which is set to true if the previous 24441 previous contents of the byte was "set", and false otherwise. 24442 Operand 1 is the 'QImode' memory to be modified. Operand 2 is the 24443 memory model to be used. 24444 24445 The specific value that defines "set" is implementation defined, 24446 and is normally based on what is performed by the native atomic 24447 test and set instruction. 24448 24449'mem_thread_fenceMODE' 24450 This pattern emits code required to implement a thread fence with 24451 memory model semantics. Operand 0 is the memory model to be used. 24452 24453 If this pattern is not specified, all memory models except 24454 '__ATOMIC_RELAXED' will result in issuing a 'sync_synchronize' 24455 barrier pattern. 24456 24457'mem_signal_fenceMODE' 24458 This pattern emits code required to implement a signal fence with 24459 memory model semantics. Operand 0 is the memory model to be used. 24460 24461 This pattern should impact the compiler optimizers the same way 24462 that mem_signal_fence does, but it does not need to issue any 24463 barrier instructions. 24464 24465 If this pattern is not specified, all memory models except 24466 '__ATOMIC_RELAXED' will result in issuing a 'sync_synchronize' 24467 barrier pattern. 24468 24469'get_thread_pointerMODE' 24470'set_thread_pointerMODE' 24471 These patterns emit code that reads/sets the TLS thread pointer. 24472 Currently, these are only needed if the target needs to support the 24473 '__builtin_thread_pointer' and '__builtin_set_thread_pointer' 24474 builtins. 24475 24476 The get/set patterns have a single output/input operand 24477 respectively, with MODE intended to be 'Pmode'. 24478 24479'stack_protect_set' 24480 This pattern, if defined, moves a 'ptr_mode' value from the memory 24481 in operand 1 to the memory in operand 0 without leaving the value 24482 in a register afterward. This is to avoid leaking the value some 24483 place that an attacker might use to rewrite the stack guard slot 24484 after having clobbered it. 24485 24486 If this pattern is not defined, then a plain move pattern is 24487 generated. 24488 24489'stack_protect_test' 24490 This pattern, if defined, compares a 'ptr_mode' value from the 24491 memory in operand 1 with the memory in operand 0 without leaving 24492 the value in a register afterward and branches to operand 2 if the 24493 values were equal. 24494 24495 If this pattern is not defined, then a plain compare pattern and 24496 conditional branch pattern is used. 24497 24498'clear_cache' 24499 This pattern, if defined, flushes the instruction cache for a 24500 region of memory. The region is bounded to by the Pmode pointers 24501 in operand 0 inclusive and operand 1 exclusive. 24502 24503 If this pattern is not defined, a call to the library function 24504 '__clear_cache' is used. 24505 24506 24507File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 24508 2450916.10 When the Order of Patterns Matters 24510======================================== 24511 24512Sometimes an insn can match more than one instruction pattern. Then the 24513pattern that appears first in the machine description is the one used. 24514Therefore, more specific patterns (patterns that will match fewer 24515things) and faster instructions (those that will produce better code 24516when they do match) should usually go first in the description. 24517 24518 In some cases the effect of ordering the patterns can be used to hide a 24519pattern when it is not valid. For example, the 68000 has an instruction 24520for converting a fullword to floating point and another for converting a 24521byte to floating point. An instruction converting an integer to 24522floating point could match either one. We put the pattern to convert 24523the fullword first to make sure that one will be used rather than the 24524other. (Otherwise a large integer might be generated as a single-byte 24525immediate quantity, which would not work.) Instead of using this 24526pattern ordering it would be possible to make the pattern for 24527convert-a-byte smart enough to deal properly with any constant value. 24528 24529 24530File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 24531 2453216.11 Interdependence of Patterns 24533================================= 24534 24535In some cases machines support instructions identical except for the 24536machine mode of one or more operands. For example, there may be 24537"sign-extend halfword" and "sign-extend byte" instructions whose 24538patterns are 24539 24540 (set (match_operand:SI 0 ...) 24541 (extend:SI (match_operand:HI 1 ...))) 24542 24543 (set (match_operand:SI 0 ...) 24544 (extend:SI (match_operand:QI 1 ...))) 24545 24546Constant integers do not specify a machine mode, so an instruction to 24547extend a constant value could match either pattern. The pattern it 24548actually will match is the one that appears first in the file. For 24549correct results, this must be the one for the widest possible mode 24550('HImode', here). If the pattern matches the 'QImode' instruction, the 24551results will be incorrect if the constant value does not actually fit 24552that mode. 24553 24554 Such instructions to extend constants are rarely generated because they 24555are optimized away, but they do occasionally happen in nonoptimized 24556compilations. 24557 24558 If a constraint in a pattern allows a constant, the reload pass may 24559replace a register with a constant permitted by the constraint in some 24560cases. Similarly for memory references. Because of this substitution, 24561you should not provide separate patterns for increment and decrement 24562instructions. Instead, they should be generated from the same pattern 24563that supports register-register add insns by examining the operands and 24564generating the appropriate machine instruction. 24565 24566 24567File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 24568 2456916.12 Defining Jump Instruction Patterns 24570======================================== 24571 24572GCC does not assume anything about how the machine realizes jumps. The 24573machine description should define a single pattern, usually a 24574'define_expand', which expands to all the required insns. 24575 24576 Usually, this would be a comparison insn to set the condition code and 24577a separate branch insn testing the condition code and branching or not 24578according to its value. For many machines, however, separating compares 24579and branches is limiting, which is why the more flexible approach with 24580one 'define_expand' is used in GCC. The machine description becomes 24581clearer for architectures that have compare-and-branch instructions but 24582no condition code. It also works better when different sets of 24583comparison operators are supported by different kinds of conditional 24584branches (e.g. integer vs. floating-point), or by conditional branches 24585with respect to conditional stores. 24586 24587 Two separate insns are always used if the machine description 24588represents a condition code register using the legacy RTL expression 24589'(cc0)', and on most machines that use a separate condition code 24590register (*note Condition Code::). For machines that use '(cc0)', in 24591fact, the set and use of the condition code must be separate and 24592adjacent(1), thus allowing flags in 'cc_status' to be used (*note 24593Condition Code::) and so that the comparison and branch insns could be 24594located from each other by using the functions 'prev_cc0_setter' and 24595'next_cc0_user'. 24596 24597 Even in this case having a single entry point for conditional branches 24598is advantageous, because it handles equally well the case where a single 24599comparison instruction records the results of both signed and unsigned 24600comparison of the given operands (with the branch insns coming in 24601distinct signed and unsigned flavors) as in the x86 or SPARC, and the 24602case where there are distinct signed and unsigned compare instructions 24603and only one set of conditional branch instructions as in the PowerPC. 24604 24605 ---------- Footnotes ---------- 24606 24607 (1) 'note' insns can separate them, though. 24608 24609 24610File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 24611 2461216.13 Defining Looping Instruction Patterns 24613=========================================== 24614 24615Some machines have special jump instructions that can be utilized to 24616make loops more efficient. A common example is the 68000 'dbra' 24617instruction which performs a decrement of a register and a branch if the 24618result was greater than zero. Other machines, in particular digital 24619signal processors (DSPs), have special block repeat instructions to 24620provide low-overhead loop support. For example, the TI TMS320C3x/C4x 24621DSPs have a block repeat instruction that loads special registers to 24622mark the top and end of a loop and to count the number of loop 24623iterations. This avoids the need for fetching and executing a 24624'dbra'-like instruction and avoids pipeline stalls associated with the 24625jump. 24626 24627 GCC has three special named patterns to support low overhead looping. 24628They are 'decrement_and_branch_until_zero', 'doloop_begin', and 24629'doloop_end'. The first pattern, 'decrement_and_branch_until_zero', is 24630not emitted during RTL generation but may be emitted during the 24631instruction combination phase. This requires the assistance of the loop 24632optimizer, using information collected during strength reduction, to 24633reverse a loop to count down to zero. Some targets also require the 24634loop optimizer to add a 'REG_NONNEG' note to indicate that the iteration 24635count is always positive. This is needed if the target performs a 24636signed loop termination test. For example, the 68000 uses a pattern 24637similar to the following for its 'dbra' instruction: 24638 24639 (define_insn "decrement_and_branch_until_zero" 24640 [(set (pc) 24641 (if_then_else 24642 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am") 24643 (const_int -1)) 24644 (const_int 0)) 24645 (label_ref (match_operand 1 "" "")) 24646 (pc))) 24647 (set (match_dup 0) 24648 (plus:SI (match_dup 0) 24649 (const_int -1)))] 24650 "find_reg_note (insn, REG_NONNEG, 0)" 24651 "...") 24652 24653 Note that since the insn is both a jump insn and has an output, it must 24654deal with its own reloads, hence the 'm' constraints. Also note that 24655since this insn is generated by the instruction combination phase 24656combining two sequential insns together into an implicit parallel insn, 24657the iteration counter needs to be biased by the same amount as the 24658decrement operation, in this case -1. Note that the following similar 24659pattern will not be matched by the combiner. 24660 24661 (define_insn "decrement_and_branch_until_zero" 24662 [(set (pc) 24663 (if_then_else 24664 (ge (match_operand:SI 0 "general_operand" "+d*am") 24665 (const_int 1)) 24666 (label_ref (match_operand 1 "" "")) 24667 (pc))) 24668 (set (match_dup 0) 24669 (plus:SI (match_dup 0) 24670 (const_int -1)))] 24671 "find_reg_note (insn, REG_NONNEG, 0)" 24672 "...") 24673 24674 The other two special looping patterns, 'doloop_begin' and 24675'doloop_end', are emitted by the loop optimizer for certain well-behaved 24676loops with a finite number of loop iterations using information 24677collected during strength reduction. 24678 24679 The 'doloop_end' pattern describes the actual looping instruction (or 24680the implicit looping operation) and the 'doloop_begin' pattern is an 24681optional companion pattern that can be used for initialization needed 24682for some low-overhead looping instructions. 24683 24684 Note that some machines require the actual looping instruction to be 24685emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 24686the true RTL for a looping instruction at the top of the loop can cause 24687problems with flow analysis. So instead, a dummy 'doloop' insn is 24688emitted at the end of the loop. The machine dependent reorg pass checks 24689for the presence of this 'doloop' insn and then searches back to the top 24690of the loop, where it inserts the true looping insn (provided there are 24691no instructions in the loop which would cause problems). Any additional 24692labels can be emitted at this point. In addition, if the desired 24693special iteration counter register was not allocated, this machine 24694dependent reorg pass could emit a traditional compare and jump 24695instruction pair. 24696 24697 The essential difference between the 'decrement_and_branch_until_zero' 24698and the 'doloop_end' patterns is that the loop optimizer allocates an 24699additional pseudo register for the latter as an iteration counter. This 24700pseudo register cannot be used within the loop (i.e., general induction 24701variables cannot be derived from it), however, in many cases the loop 24702induction variable may become redundant and removed by the flow pass. 24703 24704 24705File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 24706 2470716.14 Canonicalization of Instructions 24708====================================== 24709 24710There are often cases where multiple RTL expressions could represent an 24711operation performed by a single machine instruction. This situation is 24712most commonly encountered with logical, branch, and multiply-accumulate 24713instructions. In such cases, the compiler attempts to convert these 24714multiple RTL expressions into a single canonical form to reduce the 24715number of insn patterns required. 24716 24717 In addition to algebraic simplifications, following canonicalizations 24718are performed: 24719 24720 * For commutative and comparison operators, a constant is always made 24721 the second operand. If a machine only supports a constant as the 24722 second operand, only patterns that match a constant in the second 24723 operand need be supplied. 24724 24725 * For associative operators, a sequence of operators will always 24726 chain to the left; for instance, only the left operand of an 24727 integer 'plus' can itself be a 'plus'. 'and', 'ior', 'xor', 24728 'plus', 'mult', 'smin', 'smax', 'umin', and 'umax' are associative 24729 when applied to integers, and sometimes to floating-point. 24730 24731 * For these operators, if only one operand is a 'neg', 'not', 'mult', 24732 'plus', or 'minus' expression, it will be the first operand. 24733 24734 * In combinations of 'neg', 'mult', 'plus', and 'minus', the 'neg' 24735 operations (if any) will be moved inside the operations as far as 24736 possible. For instance, '(neg (mult A B))' is canonicalized as 24737 '(mult (neg A) B)', but '(plus (mult (neg B) C) A)' is 24738 canonicalized as '(minus A (mult B C))'. 24739 24740 * For the 'compare' operator, a constant is always the second operand 24741 if the first argument is a condition code register or '(cc0)'. 24742 24743 * An operand of 'neg', 'not', 'mult', 'plus', or 'minus' is made the 24744 first operand under the same conditions as above. 24745 24746 * '(ltu (plus A B) B)' is converted to '(ltu (plus A B) A)'. 24747 Likewise with 'geu' instead of 'ltu'. 24748 24749 * '(minus X (const_int N))' is converted to '(plus X (const_int 24750 -N))'. 24751 24752 * Within address computations (i.e., inside 'mem'), a left shift is 24753 converted into the appropriate multiplication by a power of two. 24754 24755 * De Morgan's Law is used to move bitwise negation inside a bitwise 24756 logical-and or logical-or operation. If this results in only one 24757 operand being a 'not' expression, it will be the first one. 24758 24759 A machine that has an instruction that performs a bitwise 24760 logical-and of one operand with the bitwise negation of the other 24761 should specify the pattern for that instruction as 24762 24763 (define_insn "" 24764 [(set (match_operand:M 0 ...) 24765 (and:M (not:M (match_operand:M 1 ...)) 24766 (match_operand:M 2 ...)))] 24767 "..." 24768 "...") 24769 24770 Similarly, a pattern for a "NAND" instruction should be written 24771 24772 (define_insn "" 24773 [(set (match_operand:M 0 ...) 24774 (ior:M (not:M (match_operand:M 1 ...)) 24775 (not:M (match_operand:M 2 ...))))] 24776 "..." 24777 "...") 24778 24779 In both cases, it is not necessary to include patterns for the many 24780 logically equivalent RTL expressions. 24781 24782 * The only possible RTL expressions involving both bitwise 24783 exclusive-or and bitwise negation are '(xor:M X Y)' and '(not:M 24784 (xor:M X Y))'. 24785 24786 * The sum of three items, one of which is a constant, will only 24787 appear in the form 24788 24789 (plus:M (plus:M X Y) CONSTANT) 24790 24791 * Equality comparisons of a group of bits (usually a single bit) with 24792 zero will be written using 'zero_extract' rather than the 24793 equivalent 'and' or 'sign_extract' operations. 24794 24795 * '(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))' 24796 is converted to '(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))', 24797 and likewise for 'zero_extend'. 24798 24799 * '(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))' 24800 is converted to '(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S)) 24801 (sign_extend:M1 Y))', and likewise for patterns using 'zero_extend' 24802 and 'lshiftrt'. If the second operand of 'mult' is also a shift, 24803 then that is extended also. This transformation is only applied 24804 when it can be proven that the original operation had sufficient 24805 precision to prevent overflow. 24806 24807 Further canonicalization rules are defined in the function 24808'commutative_operand_precedence' in 'gcc/rtlanal.c'. 24809 24810 24811File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 24812 2481316.15 Defining RTL Sequences for Code Generation 24814================================================ 24815 24816On some target machines, some standard pattern names for RTL generation 24817cannot be handled with single insn, but a sequence of RTL insns can 24818represent them. For these target machines, you can write a 24819'define_expand' to specify how to generate the sequence of RTL. 24820 24821 A 'define_expand' is an RTL expression that looks almost like a 24822'define_insn'; but, unlike the latter, a 'define_expand' is used only 24823for RTL generation and it can produce more than one RTL insn. 24824 24825 A 'define_expand' RTX has four operands: 24826 24827 * The name. Each 'define_expand' must have a name, since the only 24828 use for it is to refer to it by name. 24829 24830 * The RTL template. This is a vector of RTL expressions representing 24831 a sequence of separate instructions. Unlike 'define_insn', there 24832 is no implicit surrounding 'PARALLEL'. 24833 24834 * The condition, a string containing a C expression. This expression 24835 is used to express how the availability of this pattern depends on 24836 subclasses of target machine, selected by command-line options when 24837 GCC is run. This is just like the condition of a 'define_insn' 24838 that has a standard name. Therefore, the condition (if present) 24839 may not depend on the data in the insn being matched, but only the 24840 target-machine-type flags. The compiler needs to test these 24841 conditions during initialization in order to learn exactly which 24842 named instructions are available in a particular run. 24843 24844 * The preparation statements, a string containing zero or more C 24845 statements which are to be executed before RTL code is generated 24846 from the RTL template. 24847 24848 Usually these statements prepare temporary registers for use as 24849 internal operands in the RTL template, but they can also generate 24850 RTL insns directly by calling routines such as 'emit_insn', etc. 24851 Any such insns precede the ones that come from the RTL template. 24852 24853 * Optionally, a vector containing the values of attributes. *Note 24854 Insn Attributes::. 24855 24856 Every RTL insn emitted by a 'define_expand' must match some 24857'define_insn' in the machine description. Otherwise, the compiler will 24858crash when trying to generate code for the insn or trying to optimize 24859it. 24860 24861 The RTL template, in addition to controlling generation of RTL insns, 24862also describes the operands that need to be specified when this pattern 24863is used. In particular, it gives a predicate for each operand. 24864 24865 A true operand, which needs to be specified in order to generate RTL 24866from the pattern, should be described with a 'match_operand' in its 24867first occurrence in the RTL template. This enters information on the 24868operand's predicate into the tables that record such things. GCC uses 24869the information to preload the operand into a register if that is 24870required for valid RTL code. If the operand is referred to more than 24871once, subsequent references should use 'match_dup'. 24872 24873 The RTL template may also refer to internal "operands" which are 24874temporary registers or labels used only within the sequence made by the 24875'define_expand'. Internal operands are substituted into the RTL 24876template with 'match_dup', never with 'match_operand'. The values of 24877the internal operands are not passed in as arguments by the compiler 24878when it requests use of this pattern. Instead, they are computed within 24879the pattern, in the preparation statements. These statements compute 24880the values and store them into the appropriate elements of 'operands' so 24881that 'match_dup' can find them. 24882 24883 There are two special macros defined for use in the preparation 24884statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 24885a statement. 24886 24887'DONE' 24888 Use the 'DONE' macro to end RTL generation for the pattern. The 24889 only RTL insns resulting from the pattern on this occasion will be 24890 those already emitted by explicit calls to 'emit_insn' within the 24891 preparation statements; the RTL template will not be generated. 24892 24893'FAIL' 24894 Make the pattern fail on this occasion. When a pattern fails, it 24895 means that the pattern was not truly available. The calling 24896 routines in the compiler will try other strategies for code 24897 generation using other patterns. 24898 24899 Failure is currently supported only for binary (addition, 24900 multiplication, shifting, etc.) and bit-field ('extv', 'extzv', 24901 and 'insv') operations. 24902 24903 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 24904then the 'define_expand' acts like a 'define_insn' in that the RTL 24905template is used to generate the insn. 24906 24907 The RTL template is not used for matching, only for generating the 24908initial insn list. If the preparation statement always invokes 'DONE' 24909or 'FAIL', the RTL template may be reduced to a simple list of operands, 24910such as this example: 24911 24912 (define_expand "addsi3" 24913 [(match_operand:SI 0 "register_operand" "") 24914 (match_operand:SI 1 "register_operand" "") 24915 (match_operand:SI 2 "register_operand" "")] 24916 "" 24917 " 24918 { 24919 handle_add (operands[0], operands[1], operands[2]); 24920 DONE; 24921 }") 24922 24923 Here is an example, the definition of left-shift for the SPUR chip: 24924 24925 (define_expand "ashlsi3" 24926 [(set (match_operand:SI 0 "register_operand" "") 24927 (ashift:SI 24928 (match_operand:SI 1 "register_operand" "") 24929 (match_operand:SI 2 "nonmemory_operand" "")))] 24930 "" 24931 " 24932 24933 { 24934 if (GET_CODE (operands[2]) != CONST_INT 24935 || (unsigned) INTVAL (operands[2]) > 3) 24936 FAIL; 24937 }") 24938 24939This example uses 'define_expand' so that it can generate an RTL insn 24940for shifting when the shift-count is in the supported range of 0 to 3 24941but fail in other cases where machine insns aren't available. When it 24942fails, the compiler tries another strategy using different patterns 24943(such as, a library call). 24944 24945 If the compiler were able to handle nontrivial condition-strings in 24946patterns with names, then it would be possible to use a 'define_insn' in 24947that case. Here is another case (zero-extension on the 68000) which 24948makes more use of the power of 'define_expand': 24949 24950 (define_expand "zero_extendhisi2" 24951 [(set (match_operand:SI 0 "general_operand" "") 24952 (const_int 0)) 24953 (set (strict_low_part 24954 (subreg:HI 24955 (match_dup 0) 24956 0)) 24957 (match_operand:HI 1 "general_operand" ""))] 24958 "" 24959 "operands[1] = make_safe_from (operands[1], operands[0]);") 24960 24961Here two RTL insns are generated, one to clear the entire output operand 24962and the other to copy the input operand into its low half. This 24963sequence is incorrect if the input operand refers to [the old value of] 24964the output operand, so the preparation statement makes sure this isn't 24965so. The function 'make_safe_from' copies the 'operands[1]' into a 24966temporary register if it refers to 'operands[0]'. It does this by 24967emitting another RTL insn. 24968 24969 Finally, a third example shows the use of an internal operand. 24970Zero-extension on the SPUR chip is done by 'and'-ing the result against 24971a halfword mask. But this mask cannot be represented by a 'const_int' 24972because the constant value is too large to be legitimate on this 24973machine. So it must be copied into a register with 'force_reg' and then 24974the register used in the 'and'. 24975 24976 (define_expand "zero_extendhisi2" 24977 [(set (match_operand:SI 0 "register_operand" "") 24978 (and:SI (subreg:SI 24979 (match_operand:HI 1 "register_operand" "") 24980 0) 24981 (match_dup 2)))] 24982 "" 24983 "operands[2] 24984 = force_reg (SImode, GEN_INT (65535)); ") 24985 24986 _Note:_ If the 'define_expand' is used to serve a standard binary or 24987unary arithmetic operation or a bit-field operation, then the last insn 24988it generates must not be a 'code_label', 'barrier' or 'note'. It must 24989be an 'insn', 'jump_insn' or 'call_insn'. If you don't need a real insn 24990at the end, emit an insn to copy the result of the operation into 24991itself. Such an insn will generate no code, but it can avoid problems 24992in the compiler. 24993 24994 24995File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 24996 2499716.16 Defining How to Split Instructions 24998======================================== 24999 25000There are two cases where you should specify how to split a pattern into 25001multiple insns. On machines that have instructions requiring delay 25002slots (*note Delay Slots::) or that have instructions whose output is 25003not available for multiple cycles (*note Processor pipeline 25004description::), the compiler phases that optimize these cases need to be 25005able to move insns into one-instruction delay slots. However, some 25006insns may generate more than one machine instruction. These insns 25007cannot be placed into a delay slot. 25008 25009 Often you can rewrite the single insn as a list of individual insns, 25010each corresponding to one machine instruction. The disadvantage of 25011doing so is that it will cause the compilation to be slower and require 25012more space. If the resulting insns are too complex, it may also 25013suppress some optimizations. The compiler splits the insn if there is a 25014reason to believe that it might improve instruction or delay slot 25015scheduling. 25016 25017 The insn combiner phase also splits putative insns. If three insns are 25018merged into one insn with a complex expression that cannot be matched by 25019some 'define_insn' pattern, the combiner phase attempts to split the 25020complex pattern into two insns that are recognized. Usually it can 25021break the complex pattern into two patterns by splitting out some 25022subexpression. However, in some other cases, such as performing an 25023addition of a large constant in two insns on a RISC machine, the way to 25024split the addition into two insns is machine-dependent. 25025 25026 The 'define_split' definition tells the compiler how to split a complex 25027insn into several simpler insns. It looks like this: 25028 25029 (define_split 25030 [INSN-PATTERN] 25031 "CONDITION" 25032 [NEW-INSN-PATTERN-1 25033 NEW-INSN-PATTERN-2 25034 ...] 25035 "PREPARATION-STATEMENTS") 25036 25037 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 25038final condition to be tested, as in a 'define_insn'. When an insn 25039matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 25040in the insn list with the insns given by NEW-INSN-PATTERN-1, 25041NEW-INSN-PATTERN-2, etc. 25042 25043 The PREPARATION-STATEMENTS are similar to those statements that are 25044specified for 'define_expand' (*note Expander Definitions::) and are 25045executed before the new RTL is generated to prepare for the generated 25046code or emit some insns whose pattern is not fixed. Unlike those in 25047'define_expand', however, these statements must not generate any new 25048pseudo-registers. Once reload has completed, they also must not 25049allocate any space in the stack frame. 25050 25051 Patterns are matched against INSN-PATTERN in two different 25052circumstances. If an insn needs to be split for delay slot scheduling 25053or insn scheduling, the insn is already known to be valid, which means 25054that it must have been matched by some 'define_insn' and, if 25055'reload_completed' is nonzero, is known to satisfy the constraints of 25056that 'define_insn'. In that case, the new insn patterns must also be 25057insns that are matched by some 'define_insn' and, if 'reload_completed' 25058is nonzero, must also satisfy the constraints of those definitions. 25059 25060 As an example of this usage of 'define_split', consider the following 25061example from 'a29k.md', which splits a 'sign_extend' from 'HImode' to 25062'SImode' into a pair of shift insns: 25063 25064 (define_split 25065 [(set (match_operand:SI 0 "gen_reg_operand" "") 25066 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 25067 "" 25068 [(set (match_dup 0) 25069 (ashift:SI (match_dup 1) 25070 (const_int 16))) 25071 (set (match_dup 0) 25072 (ashiftrt:SI (match_dup 0) 25073 (const_int 16)))] 25074 " 25075 { operands[1] = gen_lowpart (SImode, operands[1]); }") 25076 25077 When the combiner phase tries to split an insn pattern, it is always 25078the case that the pattern is _not_ matched by any 'define_insn'. The 25079combiner pass first tries to split a single 'set' expression and then 25080the same 'set' expression inside a 'parallel', but followed by a 25081'clobber' of a pseudo-reg to use as a scratch register. In these cases, 25082the combiner expects exactly two new insn patterns to be generated. It 25083will verify that these patterns match some 'define_insn' definitions, so 25084you need not do this test in the 'define_split' (of course, there is no 25085point in writing a 'define_split' that will never produce insns that 25086match). 25087 25088 Here is an example of this use of 'define_split', taken from 25089'rs6000.md': 25090 25091 (define_split 25092 [(set (match_operand:SI 0 "gen_reg_operand" "") 25093 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 25094 (match_operand:SI 2 "non_add_cint_operand" "")))] 25095 "" 25096 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 25097 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 25098 " 25099 { 25100 int low = INTVAL (operands[2]) & 0xffff; 25101 int high = (unsigned) INTVAL (operands[2]) >> 16; 25102 25103 if (low & 0x8000) 25104 high++, low |= 0xffff0000; 25105 25106 operands[3] = GEN_INT (high << 16); 25107 operands[4] = GEN_INT (low); 25108 }") 25109 25110 Here the predicate 'non_add_cint_operand' matches any 'const_int' that 25111is _not_ a valid operand of a single add insn. The add with the smaller 25112displacement is written so that it can be substituted into the address 25113of a subsequent operation. 25114 25115 An example that uses a scratch register, from the same file, generates 25116an equality comparison of a register and a large constant: 25117 25118 (define_split 25119 [(set (match_operand:CC 0 "cc_reg_operand" "") 25120 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 25121 (match_operand:SI 2 "non_short_cint_operand" ""))) 25122 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 25123 "find_single_use (operands[0], insn, 0) 25124 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 25125 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 25126 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 25127 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 25128 " 25129 { 25130 /* Get the constant we are comparing against, C, and see what it 25131 looks like sign-extended to 16 bits. Then see what constant 25132 could be XOR'ed with C to get the sign-extended value. */ 25133 25134 int c = INTVAL (operands[2]); 25135 int sextc = (c << 16) >> 16; 25136 int xorv = c ^ sextc; 25137 25138 operands[4] = GEN_INT (xorv); 25139 operands[5] = GEN_INT (sextc); 25140 }") 25141 25142 To avoid confusion, don't write a single 'define_split' that accepts 25143some insns that match some 'define_insn' as well as some insns that 25144don't. Instead, write two separate 'define_split' definitions, one for 25145the insns that are valid and one for the insns that are not valid. 25146 25147 The splitter is allowed to split jump instructions into sequence of 25148jumps or create new jumps in while splitting non-jump instructions. As 25149the central flowgraph and branch prediction information needs to be 25150updated, several restriction apply. 25151 25152 Splitting of jump instruction into sequence that over by another jump 25153instruction is always valid, as compiler expect identical behavior of 25154new jump. When new sequence contains multiple jump instructions or new 25155labels, more assistance is needed. Splitter is required to create only 25156unconditional jumps, or simple conditional jump instructions. 25157Additionally it must attach a 'REG_BR_PROB' note to each conditional 25158jump. A global variable 'split_branch_probability' holds the 25159probability of the original branch in case it was a simple conditional 25160jump, -1 otherwise. To simplify recomputing of edge frequencies, the 25161new sequence is required to have only forward jumps to the newly created 25162labels. 25163 25164 For the common case where the pattern of a define_split exactly matches 25165the pattern of a define_insn, use 'define_insn_and_split'. It looks 25166like this: 25167 25168 (define_insn_and_split 25169 [INSN-PATTERN] 25170 "CONDITION" 25171 "OUTPUT-TEMPLATE" 25172 "SPLIT-CONDITION" 25173 [NEW-INSN-PATTERN-1 25174 NEW-INSN-PATTERN-2 25175 ...] 25176 "PREPARATION-STATEMENTS" 25177 [INSN-ATTRIBUTES]) 25178 25179 25180 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 25181as in 'define_insn'. The NEW-INSN-PATTERN vector and the 25182PREPARATION-STATEMENTS are used as in a 'define_split'. The 25183SPLIT-CONDITION is also used as in 'define_split', with the additional 25184behavior that if the condition starts with '&&', the condition used for 25185the split will be the constructed as a logical "and" of the split 25186condition with the insn condition. For example, from i386.md: 25187 25188 (define_insn_and_split "zero_extendhisi2_and" 25189 [(set (match_operand:SI 0 "register_operand" "=r") 25190 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 25191 (clobber (reg:CC 17))] 25192 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 25193 "#" 25194 "&& reload_completed" 25195 [(parallel [(set (match_dup 0) 25196 (and:SI (match_dup 0) (const_int 65535))) 25197 (clobber (reg:CC 17))])] 25198 "" 25199 [(set_attr "type" "alu1")]) 25200 25201 25202 In this case, the actual split condition will be 25203'TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 25204 25205 The 'define_insn_and_split' construction provides exactly the same 25206functionality as two separate 'define_insn' and 'define_split' patterns. 25207It exists for compactness, and as a maintenance tool to prevent having 25208to ensure the two patterns' templates match. 25209 25210 25211File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 25212 2521316.17 Including Patterns in Machine Descriptions. 25214================================================= 25215 25216The 'include' pattern tells the compiler tools where to look for 25217patterns that are in files other than in the file '.md'. This is used 25218only at build time and there is no preprocessing allowed. 25219 25220 It looks like: 25221 25222 25223 (include 25224 PATHNAME) 25225 25226 For example: 25227 25228 25229 (include "filestuff") 25230 25231 25232 Where PATHNAME is a string that specifies the location of the file, 25233specifies the include file to be in 'gcc/config/target/filestuff'. The 25234directory 'gcc/config/target' is regarded as the default directory. 25235 25236 Machine descriptions may be split up into smaller more manageable 25237subsections and placed into subdirectories. 25238 25239 By specifying: 25240 25241 25242 (include "BOGUS/filestuff") 25243 25244 25245 the include file is specified to be in 25246'gcc/config/TARGET/BOGUS/filestuff'. 25247 25248 Specifying an absolute path for the include file such as; 25249 25250 (include "/u2/BOGUS/filestuff") 25251 25252 is permitted but is not encouraged. 25253 2525416.17.1 RTL Generation Tool Options for Directory Search 25255-------------------------------------------------------- 25256 25257The '-IDIR' option specifies directories to search for machine 25258descriptions. For example: 25259 25260 25261 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 25262 25263 25264 Add the directory DIR to the head of the list of directories to be 25265searched for header files. This can be used to override a system 25266machine definition file, substituting your own version, since these 25267directories are searched before the default machine description file 25268directories. If you use more than one '-I' option, the directories are 25269scanned in left-to-right order; the standard default directory come 25270after. 25271 25272 25273File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 25274 2527516.18 Machine-Specific Peephole Optimizers 25276========================================== 25277 25278In addition to instruction patterns the 'md' file may contain 25279definitions of machine-specific peephole optimizations. 25280 25281 The combiner does not notice certain peephole optimizations when the 25282data flow in the program does not suggest that it should try them. For 25283example, sometimes two consecutive insns related in purpose can be 25284combined even though the second one does not appear to use a register 25285computed in the first one. A machine-specific peephole optimizer can 25286detect such opportunities. 25287 25288 There are two forms of peephole definitions that may be used. The 25289original 'define_peephole' is run at assembly output time to match insns 25290and substitute assembly text. Use of 'define_peephole' is deprecated. 25291 25292 A newer 'define_peephole2' matches insns and substitutes new insns. 25293The 'peephole2' pass is run after register allocation but before 25294scheduling, which may result in much better code for targets that do 25295scheduling. 25296 25297* Menu: 25298 25299* define_peephole:: RTL to Text Peephole Optimizers 25300* define_peephole2:: RTL to RTL Peephole Optimizers 25301 25302 25303File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 25304 2530516.18.1 RTL to Text Peephole Optimizers 25306--------------------------------------- 25307 25308A definition looks like this: 25309 25310 (define_peephole 25311 [INSN-PATTERN-1 25312 INSN-PATTERN-2 25313 ...] 25314 "CONDITION" 25315 "TEMPLATE" 25316 "OPTIONAL-INSN-ATTRIBUTES") 25317 25318The last string operand may be omitted if you are not using any 25319machine-specific information in this machine description. If present, 25320it must obey the same rules as in a 'define_insn'. 25321 25322 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 25323consecutive insns. The optimization applies to a sequence of insns when 25324INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 25325and so on. 25326 25327 Each of the insns matched by a peephole must also match a 25328'define_insn'. Peepholes are checked only at the last stage just before 25329code generation, and only optionally. Therefore, any insn which would 25330match a peephole but no 'define_insn' will cause a crash in code 25331generation in an unoptimized compilation, or at various optimization 25332stages. 25333 25334 The operands of the insns are matched with 'match_operands', 25335'match_operator', and 'match_dup', as usual. What is not usual is that 25336the operand numbers apply to all the insn patterns in the definition. 25337So, you can check for identical operands in two insns by using 25338'match_operand' in one insn and 'match_dup' in the other. 25339 25340 The operand constraints used in 'match_operand' patterns do not have 25341any direct effect on the applicability of the peephole, but they will be 25342validated afterward, so make sure your constraints are general enough to 25343apply whenever the peephole matches. If the peephole matches but the 25344constraints are not satisfied, the compiler will crash. 25345 25346 It is safe to omit constraints in all the operands of the peephole; or 25347you can write constraints which serve as a double-check on the criteria 25348previously tested. 25349 25350 Once a sequence of insns matches the patterns, the CONDITION is 25351checked. This is a C expression which makes the final decision whether 25352to perform the optimization (we do so if the expression is nonzero). If 25353CONDITION is omitted (in other words, the string is empty) then the 25354optimization is applied to every sequence of insns that matches the 25355patterns. 25356 25357 The defined peephole optimizations are applied after register 25358allocation is complete. Therefore, the peephole definition can check 25359which operands have ended up in which kinds of registers, just by 25360looking at the operands. 25361 25362 The way to refer to the operands in CONDITION is to write 'operands[I]' 25363for operand number I (as matched by '(match_operand I ...)'). Use the 25364variable 'insn' to refer to the last of the insns being matched; use 25365'prev_active_insn' to find the preceding insns. 25366 25367 When optimizing computations with intermediate results, you can use 25368CONDITION to match only when the intermediate results are not used 25369elsewhere. Use the C expression 'dead_or_set_p (INSN, OP)', where INSN 25370is the insn in which you expect the value to be used for the last time 25371(from the value of 'insn', together with use of 'prev_nonnote_insn'), 25372and OP is the intermediate value (from 'operands[I]'). 25373 25374 Applying the optimization means replacing the sequence of insns with 25375one new insn. The TEMPLATE controls ultimate output of assembler code 25376for this combined insn. It works exactly like the template of a 25377'define_insn'. Operand numbers in this template are the same ones used 25378in matching the original sequence of insns. 25379 25380 The result of a defined peephole optimizer does not need to match any 25381of the insn patterns in the machine description; it does not even have 25382an opportunity to match them. The peephole optimizer definition itself 25383serves as the insn pattern to control how the insn is output. 25384 25385 Defined peephole optimizers are run as assembler code is being output, 25386so the insns they produce are never combined or rearranged in any way. 25387 25388 Here is an example, taken from the 68000 machine description: 25389 25390 (define_peephole 25391 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 25392 (set (match_operand:DF 0 "register_operand" "=f") 25393 (match_operand:DF 1 "register_operand" "ad"))] 25394 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 25395 { 25396 rtx xoperands[2]; 25397 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 25398 #ifdef MOTOROLA 25399 output_asm_insn ("move.l %1,(sp)", xoperands); 25400 output_asm_insn ("move.l %1,-(sp)", operands); 25401 return "fmove.d (sp)+,%0"; 25402 #else 25403 output_asm_insn ("movel %1,sp@", xoperands); 25404 output_asm_insn ("movel %1,sp@-", operands); 25405 return "fmoved sp@+,%0"; 25406 #endif 25407 }) 25408 25409 The effect of this optimization is to change 25410 25411 jbsr _foobar 25412 addql #4,sp 25413 movel d1,sp@- 25414 movel d0,sp@- 25415 fmoved sp@+,fp0 25416 25417into 25418 25419 jbsr _foobar 25420 movel d1,sp@ 25421 movel d0,sp@- 25422 fmoved sp@+,fp0 25423 25424 INSN-PATTERN-1 and so on look _almost_ like the second operand of 25425'define_insn'. There is one important difference: the second operand of 25426'define_insn' consists of one or more RTX's enclosed in square brackets. 25427Usually, there is only one: then the same action can be written as an 25428element of a 'define_peephole'. But when there are multiple actions in 25429a 'define_insn', they are implicitly enclosed in a 'parallel'. Then you 25430must explicitly write the 'parallel', and the square brackets within it, 25431in the 'define_peephole'. Thus, if an insn pattern looks like this, 25432 25433 (define_insn "divmodsi4" 25434 [(set (match_operand:SI 0 "general_operand" "=d") 25435 (div:SI (match_operand:SI 1 "general_operand" "0") 25436 (match_operand:SI 2 "general_operand" "dmsK"))) 25437 (set (match_operand:SI 3 "general_operand" "=d") 25438 (mod:SI (match_dup 1) (match_dup 2)))] 25439 "TARGET_68020" 25440 "divsl%.l %2,%3:%0") 25441 25442then the way to mention this insn in a peephole is as follows: 25443 25444 (define_peephole 25445 [... 25446 (parallel 25447 [(set (match_operand:SI 0 "general_operand" "=d") 25448 (div:SI (match_operand:SI 1 "general_operand" "0") 25449 (match_operand:SI 2 "general_operand" "dmsK"))) 25450 (set (match_operand:SI 3 "general_operand" "=d") 25451 (mod:SI (match_dup 1) (match_dup 2)))]) 25452 ...] 25453 ...) 25454 25455 25456File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 25457 2545816.18.2 RTL to RTL Peephole Optimizers 25459-------------------------------------- 25460 25461The 'define_peephole2' definition tells the compiler how to substitute 25462one sequence of instructions for another sequence, what additional 25463scratch registers may be needed and what their lifetimes must be. 25464 25465 (define_peephole2 25466 [INSN-PATTERN-1 25467 INSN-PATTERN-2 25468 ...] 25469 "CONDITION" 25470 [NEW-INSN-PATTERN-1 25471 NEW-INSN-PATTERN-2 25472 ...] 25473 "PREPARATION-STATEMENTS") 25474 25475 The definition is almost identical to 'define_split' (*note Insn 25476Splitting::) except that the pattern to match is not a single 25477instruction, but a sequence of instructions. 25478 25479 It is possible to request additional scratch registers for use in the 25480output template. If appropriate registers are not free, the pattern 25481will simply not match. 25482 25483 Scratch registers are requested with a 'match_scratch' pattern at the 25484top level of the input pattern. The allocated register (initially) will 25485be dead at the point requested within the original sequence. If the 25486scratch is used at more than a single point, a 'match_dup' pattern at 25487the top level of the input pattern marks the last position in the input 25488sequence at which the register must be available. 25489 25490 Here is an example from the IA-32 machine description: 25491 25492 (define_peephole2 25493 [(match_scratch:SI 2 "r") 25494 (parallel [(set (match_operand:SI 0 "register_operand" "") 25495 (match_operator:SI 3 "arith_or_logical_operator" 25496 [(match_dup 0) 25497 (match_operand:SI 1 "memory_operand" "")])) 25498 (clobber (reg:CC 17))])] 25499 "! optimize_size && ! TARGET_READ_MODIFY" 25500 [(set (match_dup 2) (match_dup 1)) 25501 (parallel [(set (match_dup 0) 25502 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 25503 (clobber (reg:CC 17))])] 25504 "") 25505 25506This pattern tries to split a load from its use in the hopes that we'll 25507be able to schedule around the memory load latency. It allocates a 25508single 'SImode' register of class 'GENERAL_REGS' ('"r"') that needs to 25509be live only at the point just before the arithmetic. 25510 25511 A real example requiring extended scratch lifetimes is harder to come 25512by, so here's a silly made-up example: 25513 25514 (define_peephole2 25515 [(match_scratch:SI 4 "r") 25516 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 25517 (set (match_operand:SI 2 "" "") (match_dup 1)) 25518 (match_dup 4) 25519 (set (match_operand:SI 3 "" "") (match_dup 1))] 25520 "/* determine 1 does not overlap 0 and 2 */" 25521 [(set (match_dup 4) (match_dup 1)) 25522 (set (match_dup 0) (match_dup 4)) 25523 (set (match_dup 2) (match_dup 4)) 25524 (set (match_dup 3) (match_dup 4))] 25525 "") 25526 25527If we had not added the '(match_dup 4)' in the middle of the input 25528sequence, it might have been the case that the register we chose at the 25529beginning of the sequence is killed by the first or second 'set'. 25530 25531 25532File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 25533 2553416.19 Instruction Attributes 25535============================ 25536 25537In addition to describing the instruction supported by the target 25538machine, the 'md' file also defines a group of "attributes" and a set of 25539values for each. Every generated insn is assigned a value for each 25540attribute. One possible attribute would be the effect that the insn has 25541on the machine's condition code. This attribute can then be used by 25542'NOTICE_UPDATE_CC' to track the condition codes. 25543 25544* Menu: 25545 25546* Defining Attributes:: Specifying attributes and their values. 25547* Expressions:: Valid expressions for attribute values. 25548* Tagging Insns:: Assigning attribute values to insns. 25549* Attr Example:: An example of assigning attributes. 25550* Insn Lengths:: Computing the length of insns. 25551* Constant Attributes:: Defining attributes that are constant. 25552* Mnemonic Attribute:: Obtain the instruction mnemonic as attribute value. 25553* Delay Slots:: Defining delay slots required for a machine. 25554* Processor pipeline description:: Specifying information for insn scheduling. 25555 25556 25557File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 25558 2555916.19.1 Defining Attributes and their Values 25560-------------------------------------------- 25561 25562The 'define_attr' expression is used to define each attribute required 25563by the target machine. It looks like: 25564 25565 (define_attr NAME LIST-OF-VALUES DEFAULT) 25566 25567 NAME is a string specifying the name of the attribute being defined. 25568Some attributes are used in a special way by the rest of the compiler. 25569The 'enabled' attribute can be used to conditionally enable or disable 25570insn alternatives (*note Disable Insn Alternatives::). The 'predicable' 25571attribute, together with a suitable 'define_cond_exec' (*note 25572Conditional Execution::), can be used to automatically generate 25573conditional variants of instruction patterns. The 'mnemonic' attribute 25574can be used to check for the instruction mnemonic (*note Mnemonic 25575Attribute::). The compiler internally uses the names 'ce_enabled' and 25576'nonce_enabled', so they should not be used elsewhere as alternative 25577names. 25578 25579 LIST-OF-VALUES is either a string that specifies a comma-separated list 25580of values that can be assigned to the attribute, or a null string to 25581indicate that the attribute takes numeric values. 25582 25583 DEFAULT is an attribute expression that gives the value of this 25584attribute for insns that match patterns whose definition does not 25585include an explicit value for this attribute. *Note Attr Example::, for 25586more information on the handling of defaults. *Note Constant 25587Attributes::, for information on attributes that do not depend on any 25588particular insn. 25589 25590 For each defined attribute, a number of definitions are written to the 25591'insn-attr.h' file. For cases where an explicit set of values is 25592specified for an attribute, the following are defined: 25593 25594 * A '#define' is written for the symbol 'HAVE_ATTR_NAME'. 25595 25596 * An enumerated class is defined for 'attr_NAME' with elements of the 25597 form 'UPPER-NAME_UPPER-VALUE' where the attribute name and value 25598 are first converted to uppercase. 25599 25600 * A function 'get_attr_NAME' is defined that is passed an insn and 25601 returns the attribute value for that insn. 25602 25603 For example, if the following is present in the 'md' file: 25604 25605 (define_attr "type" "branch,fp,load,store,arith" ...) 25606 25607the following lines will be written to the file 'insn-attr.h'. 25608 25609 #define HAVE_ATTR_type 1 25610 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 25611 TYPE_STORE, TYPE_ARITH}; 25612 extern enum attr_type get_attr_type (); 25613 25614 If the attribute takes numeric values, no 'enum' type will be defined 25615and the function to obtain the attribute's value will return 'int'. 25616 25617 There are attributes which are tied to a specific meaning. These 25618attributes are not free to use for other purposes: 25619 25620'length' 25621 The 'length' attribute is used to calculate the length of emitted 25622 code chunks. This is especially important when verifying branch 25623 distances. *Note Insn Lengths::. 25624 25625'enabled' 25626 The 'enabled' attribute can be defined to prevent certain 25627 alternatives of an insn definition from being used during code 25628 generation. *Note Disable Insn Alternatives::. 25629 25630'mnemonic' 25631 The 'mnemonic' attribute can be defined to implement instruction 25632 specific checks in e.g. the pipeline description. *Note Mnemonic 25633 Attribute::. 25634 25635 For each of these special attributes, the corresponding 25636'HAVE_ATTR_NAME' '#define' is also written when the attribute is not 25637defined; in that case, it is defined as '0'. 25638 25639 Another way of defining an attribute is to use: 25640 25641 (define_enum_attr "ATTR" "ENUM" DEFAULT) 25642 25643 This works in just the same way as 'define_attr', except that the list 25644of values is taken from a separate enumeration called ENUM (*note 25645define_enum::). This form allows you to use the same list of values for 25646several attributes without having to repeat the list each time. For 25647example: 25648 25649 (define_enum "processor" [ 25650 model_a 25651 model_b 25652 ... 25653 ]) 25654 (define_enum_attr "arch" "processor" 25655 (const (symbol_ref "target_arch"))) 25656 (define_enum_attr "tune" "processor" 25657 (const (symbol_ref "target_tune"))) 25658 25659 defines the same attributes as: 25660 25661 (define_attr "arch" "model_a,model_b,..." 25662 (const (symbol_ref "target_arch"))) 25663 (define_attr "tune" "model_a,model_b,..." 25664 (const (symbol_ref "target_tune"))) 25665 25666 but without duplicating the processor list. The second example defines 25667two separate C enums ('attr_arch' and 'attr_tune') whereas the first 25668defines a single C enum ('processor'). 25669 25670 25671File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 25672 2567316.19.2 Attribute Expressions 25674----------------------------- 25675 25676RTL expressions used to define attributes use the codes described above 25677plus a few specific to attribute definitions, to be discussed below. 25678Attribute value expressions must have one of the following forms: 25679 25680'(const_int I)' 25681 The integer I specifies the value of a numeric attribute. I must 25682 be non-negative. 25683 25684 The value of a numeric attribute can be specified either with a 25685 'const_int', or as an integer represented as a string in 25686 'const_string', 'eq_attr' (see below), 'attr', 'symbol_ref', simple 25687 arithmetic expressions, and 'set_attr' overrides on specific 25688 instructions (*note Tagging Insns::). 25689 25690'(const_string VALUE)' 25691 The string VALUE specifies a constant attribute value. If VALUE is 25692 specified as '"*"', it means that the default value of the 25693 attribute is to be used for the insn containing this expression. 25694 '"*"' obviously cannot be used in the DEFAULT expression of a 25695 'define_attr'. 25696 25697 If the attribute whose value is being specified is numeric, VALUE 25698 must be a string containing a non-negative integer (normally 25699 'const_int' would be used in this case). Otherwise, it must 25700 contain one of the valid values for the attribute. 25701 25702'(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 25703 TEST specifies an attribute test, whose format is defined below. 25704 The value of this expression is TRUE-VALUE if TEST is true, 25705 otherwise it is FALSE-VALUE. 25706 25707'(cond [TEST1 VALUE1 ...] DEFAULT)' 25708 The first operand of this expression is a vector containing an even 25709 number of expressions and consisting of pairs of TEST and VALUE 25710 expressions. The value of the 'cond' expression is that of the 25711 VALUE corresponding to the first true TEST expression. If none of 25712 the TEST expressions are true, the value of the 'cond' expression 25713 is that of the DEFAULT expression. 25714 25715 TEST expressions can have one of the following forms: 25716 25717'(const_int I)' 25718 This test is true if I is nonzero and false otherwise. 25719 25720'(not TEST)' 25721'(ior TEST1 TEST2)' 25722'(and TEST1 TEST2)' 25723 These tests are true if the indicated logical function is true. 25724 25725'(match_operand:M N PRED CONSTRAINTS)' 25726 This test is true if operand N of the insn whose attribute value is 25727 being determined has mode M (this part of the test is ignored if M 25728 is 'VOIDmode') and the function specified by the string PRED 25729 returns a nonzero value when passed operand N and mode M (this part 25730 of the test is ignored if PRED is the null string). 25731 25732 The CONSTRAINTS operand is ignored and should be the null string. 25733 25734'(match_test C-EXPR)' 25735 The test is true if C expression C-EXPR is true. In non-constant 25736 attributes, C-EXPR has access to the following variables: 25737 25738 INSN 25739 The rtl instruction under test. 25740 WHICH_ALTERNATIVE 25741 The 'define_insn' alternative that INSN matches. *Note Output 25742 Statement::. 25743 OPERANDS 25744 An array of INSN's rtl operands. 25745 25746 C-EXPR behaves like the condition in a C 'if' statement, so there 25747 is no need to explicitly convert the expression into a boolean 0 or 25748 1 value. For example, the following two tests are equivalent: 25749 25750 (match_test "x & 2") 25751 (match_test "(x & 2) != 0") 25752 25753'(le ARITH1 ARITH2)' 25754'(leu ARITH1 ARITH2)' 25755'(lt ARITH1 ARITH2)' 25756'(ltu ARITH1 ARITH2)' 25757'(gt ARITH1 ARITH2)' 25758'(gtu ARITH1 ARITH2)' 25759'(ge ARITH1 ARITH2)' 25760'(geu ARITH1 ARITH2)' 25761'(ne ARITH1 ARITH2)' 25762'(eq ARITH1 ARITH2)' 25763 These tests are true if the indicated comparison of the two 25764 arithmetic expressions is true. Arithmetic expressions are formed 25765 with 'plus', 'minus', 'mult', 'div', 'mod', 'abs', 'neg', 'and', 25766 'ior', 'xor', 'not', 'ashift', 'lshiftrt', and 'ashiftrt' 25767 expressions. 25768 25769 'const_int' and 'symbol_ref' are always valid terms (*note Insn 25770 Lengths::,for additional forms). 'symbol_ref' is a string denoting 25771 a C expression that yields an 'int' when evaluated by the 25772 'get_attr_...' routine. It should normally be a global variable. 25773 25774'(eq_attr NAME VALUE)' 25775 NAME is a string specifying the name of an attribute. 25776 25777 VALUE is a string that is either a valid value for attribute NAME, 25778 a comma-separated list of values, or '!' followed by a value or 25779 list. If VALUE does not begin with a '!', this test is true if the 25780 value of the NAME attribute of the current insn is in the list 25781 specified by VALUE. If VALUE begins with a '!', this test is true 25782 if the attribute's value is _not_ in the specified list. 25783 25784 For example, 25785 25786 (eq_attr "type" "load,store") 25787 25788 is equivalent to 25789 25790 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 25791 25792 If NAME specifies an attribute of 'alternative', it refers to the 25793 value of the compiler variable 'which_alternative' (*note Output 25794 Statement::) and the values must be small integers. For example, 25795 25796 (eq_attr "alternative" "2,3") 25797 25798 is equivalent to 25799 25800 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 25801 (eq (symbol_ref "which_alternative") (const_int 3))) 25802 25803 Note that, for most attributes, an 'eq_attr' test is simplified in 25804 cases where the value of the attribute being tested is known for 25805 all insns matching a particular pattern. This is by far the most 25806 common case. 25807 25808'(attr_flag NAME)' 25809 The value of an 'attr_flag' expression is true if the flag 25810 specified by NAME is true for the 'insn' currently being scheduled. 25811 25812 NAME is a string specifying one of a fixed set of flags to test. 25813 Test the flags 'forward' and 'backward' to determine the direction 25814 of a conditional branch. 25815 25816 This example describes a conditional branch delay slot which can be 25817 nullified for forward branches that are taken (annul-true) or for 25818 backward branches which are not taken (annul-false). 25819 25820 (define_delay (eq_attr "type" "cbranch") 25821 [(eq_attr "in_branch_delay" "true") 25822 (and (eq_attr "in_branch_delay" "true") 25823 (attr_flag "forward")) 25824 (and (eq_attr "in_branch_delay" "true") 25825 (attr_flag "backward"))]) 25826 25827 The 'forward' and 'backward' flags are false if the current 'insn' 25828 being scheduled is not a conditional branch. 25829 25830 'attr_flag' is only used during delay slot scheduling and has no 25831 meaning to other passes of the compiler. 25832 25833'(attr NAME)' 25834 The value of another attribute is returned. This is most useful 25835 for numeric attributes, as 'eq_attr' and 'attr_flag' produce more 25836 efficient code for non-numeric attributes. 25837 25838 25839File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 25840 2584116.19.3 Assigning Attribute Values to Insns 25842------------------------------------------- 25843 25844The value assigned to an attribute of an insn is primarily determined by 25845which pattern is matched by that insn (or which 'define_peephole' 25846generated it). Every 'define_insn' and 'define_peephole' can have an 25847optional last argument to specify the values of attributes for matching 25848insns. The value of any attribute not specified in a particular insn is 25849set to the default value for that attribute, as specified in its 25850'define_attr'. Extensive use of default values for attributes permits 25851the specification of the values for only one or two attributes in the 25852definition of most insn patterns, as seen in the example in the next 25853section. 25854 25855 The optional last argument of 'define_insn' and 'define_peephole' is a 25856vector of expressions, each of which defines the value for a single 25857attribute. The most general way of assigning an attribute's value is to 25858use a 'set' expression whose first operand is an 'attr' expression 25859giving the name of the attribute being set. The second operand of the 25860'set' is an attribute expression (*note Expressions::) giving the value 25861of the attribute. 25862 25863 When the attribute value depends on the 'alternative' attribute (i.e., 25864which is the applicable alternative in the constraint of the insn), the 25865'set_attr_alternative' expression can be used. It allows the 25866specification of a vector of attribute expressions, one for each 25867alternative. 25868 25869 When the generality of arbitrary attribute expressions is not required, 25870the simpler 'set_attr' expression can be used, which allows specifying a 25871string giving either a single attribute value or a list of attribute 25872values, one for each alternative. 25873 25874 The form of each of the above specifications is shown below. In each 25875case, NAME is a string specifying the attribute to be set. 25876 25877'(set_attr NAME VALUE-STRING)' 25878 VALUE-STRING is either a string giving the desired attribute value, 25879 or a string containing a comma-separated list giving the values for 25880 succeeding alternatives. The number of elements must match the 25881 number of alternatives in the constraint of the insn pattern. 25882 25883 Note that it may be useful to specify '*' for some alternative, in 25884 which case the attribute will assume its default value for insns 25885 matching that alternative. 25886 25887'(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 25888 Depending on the alternative of the insn, the value will be one of 25889 the specified values. This is a shorthand for using a 'cond' with 25890 tests on the 'alternative' attribute. 25891 25892'(set (attr NAME) VALUE)' 25893 The first operand of this 'set' must be the special RTL expression 25894 'attr', whose sole operand is a string giving the name of the 25895 attribute being set. VALUE is the value of the attribute. 25896 25897 The following shows three different ways of representing the same 25898attribute value specification: 25899 25900 (set_attr "type" "load,store,arith") 25901 25902 (set_attr_alternative "type" 25903 [(const_string "load") (const_string "store") 25904 (const_string "arith")]) 25905 25906 (set (attr "type") 25907 (cond [(eq_attr "alternative" "1") (const_string "load") 25908 (eq_attr "alternative" "2") (const_string "store")] 25909 (const_string "arith"))) 25910 25911 The 'define_asm_attributes' expression provides a mechanism to specify 25912the attributes assigned to insns produced from an 'asm' statement. It 25913has the form: 25914 25915 (define_asm_attributes [ATTR-SETS]) 25916 25917where ATTR-SETS is specified the same as for both the 'define_insn' and 25918the 'define_peephole' expressions. 25919 25920 These values will typically be the "worst case" attribute values. For 25921example, they might indicate that the condition code will be clobbered. 25922 25923 A specification for a 'length' attribute is handled specially. The way 25924to compute the length of an 'asm' insn is to multiply the length 25925specified in the expression 'define_asm_attributes' by the number of 25926machine instructions specified in the 'asm' statement, determined by 25927counting the number of semicolons and newlines in the string. 25928Therefore, the value of the 'length' attribute specified in a 25929'define_asm_attributes' should be the maximum possible length of a 25930single machine instruction. 25931 25932 25933File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 25934 2593516.19.4 Example of Attribute Specifications 25936------------------------------------------- 25937 25938The judicious use of defaulting is important in the efficient use of 25939insn attributes. Typically, insns are divided into "types" and an 25940attribute, customarily called 'type', is used to represent this value. 25941This attribute is normally used only to define the default value for 25942other attributes. An example will clarify this usage. 25943 25944 Assume we have a RISC machine with a condition code and in which only 25945full-word operations are performed in registers. Let us assume that we 25946can divide all insns into loads, stores, (integer) arithmetic 25947operations, floating point operations, and branches. 25948 25949 Here we will concern ourselves with determining the effect of an insn 25950on the condition code and will limit ourselves to the following possible 25951effects: The condition code can be set unpredictably (clobbered), not be 25952changed, be set to agree with the results of the operation, or only 25953changed if the item previously set into the condition code has been 25954modified. 25955 25956 Here is part of a sample 'md' file for such a machine: 25957 25958 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 25959 25960 (define_attr "cc" "clobber,unchanged,set,change0" 25961 (cond [(eq_attr "type" "load") 25962 (const_string "change0") 25963 (eq_attr "type" "store,branch") 25964 (const_string "unchanged") 25965 (eq_attr "type" "arith") 25966 (if_then_else (match_operand:SI 0 "" "") 25967 (const_string "set") 25968 (const_string "clobber"))] 25969 (const_string "clobber"))) 25970 25971 (define_insn "" 25972 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 25973 (match_operand:SI 1 "general_operand" "r,m,r"))] 25974 "" 25975 "@ 25976 move %0,%1 25977 load %0,%1 25978 store %0,%1" 25979 [(set_attr "type" "arith,load,store")]) 25980 25981 Note that we assume in the above example that arithmetic operations 25982performed on quantities smaller than a machine word clobber the 25983condition code since they will set the condition code to a value 25984corresponding to the full-word result. 25985 25986 25987File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 25988 2598916.19.5 Computing the Length of an Insn 25990--------------------------------------- 25991 25992For many machines, multiple types of branch instructions are provided, 25993each for different length branch displacements. In most cases, the 25994assembler will choose the correct instruction to use. However, when the 25995assembler cannot do so, GCC can when a special attribute, the 'length' 25996attribute, is defined. This attribute must be defined to have numeric 25997values by specifying a null string in its 'define_attr'. 25998 25999 In the case of the 'length' attribute, two additional forms of 26000arithmetic terms are allowed in test expressions: 26001 26002'(match_dup N)' 26003 This refers to the address of operand N of the current insn, which 26004 must be a 'label_ref'. 26005 26006'(pc)' 26007 For non-branch instructions and backward branch instructions, this 26008 refers to the address of the current insn. But for forward branch 26009 instructions, this refers to the address of the next insn, because 26010 the length of the current insn is to be computed. 26011 26012 For normal insns, the length will be determined by value of the 26013'length' attribute. In the case of 'addr_vec' and 'addr_diff_vec' insn 26014patterns, the length is computed as the number of vectors multiplied by 26015the size of each vector. 26016 26017 Lengths are measured in addressable storage units (bytes). 26018 26019 Note that it is possible to call functions via the 'symbol_ref' 26020mechanism to compute the length of an insn. However, if you use this 26021mechanism you must provide dummy clauses to express the maximum length 26022without using the function call. You can an example of this in the 'pa' 26023machine description for the 'call_symref' pattern. 26024 26025 The following macros can be used to refine the length computation: 26026 26027'ADJUST_INSN_LENGTH (INSN, LENGTH)' 26028 If defined, modifies the length assigned to instruction INSN as a 26029 function of the context in which it is used. LENGTH is an lvalue 26030 that contains the initially computed length of the insn and should 26031 be updated with the correct length of the insn. 26032 26033 This macro will normally not be required. A case in which it is 26034 required is the ROMP. On this machine, the size of an 'addr_vec' 26035 insn must be increased by two to compensate for the fact that 26036 alignment may be required. 26037 26038 The routine that returns 'get_attr_length' (the value of the 'length' 26039attribute) can be used by the output routine to determine the form of 26040the branch instruction to be written, as the example below illustrates. 26041 26042 As an example of the specification of variable-length branches, 26043consider the IBM 360. If we adopt the convention that a register will 26044be set to the starting address of a function, we can jump to labels 26045within 4k of the start using a four-byte instruction. Otherwise, we 26046need a six-byte sequence to load the address from memory and then branch 26047to it. 26048 26049 On such a machine, a pattern for a branch instruction might be 26050specified as follows: 26051 26052 (define_insn "jump" 26053 [(set (pc) 26054 (label_ref (match_operand 0 "" "")))] 26055 "" 26056 { 26057 return (get_attr_length (insn) == 4 26058 ? "b %l0" : "l r15,=a(%l0); br r15"); 26059 } 26060 [(set (attr "length") 26061 (if_then_else (lt (match_dup 0) (const_int 4096)) 26062 (const_int 4) 26063 (const_int 6)))]) 26064 26065 26066File: gccint.info, Node: Constant Attributes, Next: Mnemonic Attribute, Prev: Insn Lengths, Up: Insn Attributes 26067 2606816.19.6 Constant Attributes 26069--------------------------- 26070 26071A special form of 'define_attr', where the expression for the default 26072value is a 'const' expression, indicates an attribute that is constant 26073for a given run of the compiler. Constant attributes may be used to 26074specify which variety of processor is used. For example, 26075 26076 (define_attr "cpu" "m88100,m88110,m88000" 26077 (const 26078 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 26079 (symbol_ref "TARGET_88110") (const_string "m88110")] 26080 (const_string "m88000")))) 26081 26082 (define_attr "memory" "fast,slow" 26083 (const 26084 (if_then_else (symbol_ref "TARGET_FAST_MEM") 26085 (const_string "fast") 26086 (const_string "slow")))) 26087 26088 The routine generated for constant attributes has no parameters as it 26089does not depend on any particular insn. RTL expressions used to define 26090the value of a constant attribute may use the 'symbol_ref' form, but may 26091not use either the 'match_operand' form or 'eq_attr' forms involving 26092insn attributes. 26093 26094 26095File: gccint.info, Node: Mnemonic Attribute, Next: Delay Slots, Prev: Constant Attributes, Up: Insn Attributes 26096 2609716.19.7 Mnemonic Attribute 26098-------------------------- 26099 26100The 'mnemonic' attribute is a string type attribute holding the 26101instruction mnemonic for an insn alternative. The attribute values will 26102automatically be generated by the machine description parser if there is 26103an attribute definition in the md file: 26104 26105 (define_attr "mnemonic" "unknown" (const_string "unknown")) 26106 26107 The default value can be freely chosen as long as it does not collide 26108with any of the instruction mnemonics. This value will be used whenever 26109the machine description parser is not able to determine the mnemonic 26110string. This might be the case for output templates containing more 26111than a single instruction as in '"mvcle\t%0,%1,0\;jo\t.-4"'. 26112 26113 The 'mnemonic' attribute set is not generated automatically if the 26114instruction string is generated via C code. 26115 26116 An existing 'mnemonic' attribute set in an insn definition will not be 26117overriden by the md file parser. That way it is possible to manually 26118set the instruction mnemonics for the cases where the md file parser 26119fails to determine it automatically. 26120 26121 The 'mnemonic' attribute is useful for dealing with instruction 26122specific properties in the pipeline description without defining 26123additional insn attributes. 26124 26125 (define_attr "ooo_expanded" "" 26126 (cond [(eq_attr "mnemonic" "dlr,dsgr,d,dsgf,stam,dsgfr,dlgr") 26127 (const_int 1)] 26128 (const_int 0))) 26129 26130 26131File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Mnemonic Attribute, Up: Insn Attributes 26132 2613316.19.8 Delay Slot Scheduling 26134----------------------------- 26135 26136The insn attribute mechanism can be used to specify the requirements for 26137delay slots, if any, on a target machine. An instruction is said to 26138require a "delay slot" if some instructions that are physically after 26139the instruction are executed as if they were located before it. Classic 26140examples are branch and call instructions, which often execute the 26141following instruction before the branch or call is performed. 26142 26143 On some machines, conditional branch instructions can optionally 26144"annul" instructions in the delay slot. This means that the instruction 26145will not be executed for certain branch outcomes. Both instructions 26146that annul if the branch is true and instructions that annul if the 26147branch is false are supported. 26148 26149 Delay slot scheduling differs from instruction scheduling in that 26150determining whether an instruction needs a delay slot is dependent only 26151on the type of instruction being generated, not on data flow between the 26152instructions. See the next section for a discussion of data-dependent 26153instruction scheduling. 26154 26155 The requirement of an insn needing one or more delay slots is indicated 26156via the 'define_delay' expression. It has the following form: 26157 26158 (define_delay TEST 26159 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 26160 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 26161 ...]) 26162 26163 TEST is an attribute test that indicates whether this 'define_delay' 26164applies to a particular insn. If so, the number of required delay slots 26165is determined by the length of the vector specified as the second 26166argument. An insn placed in delay slot N must satisfy attribute test 26167DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 26168may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 26169specifies which insns in the delay slot may be annulled if the branch is 26170false. If annulling is not supported for that delay slot, '(nil)' 26171should be coded. 26172 26173 For example, in the common case where branch and call insns require a 26174single delay slot, which may contain any insn other than a branch or 26175call, the following would be placed in the 'md' file: 26176 26177 (define_delay (eq_attr "type" "branch,call") 26178 [(eq_attr "type" "!branch,call") (nil) (nil)]) 26179 26180 Multiple 'define_delay' expressions may be specified. In this case, 26181each such expression specifies different delay slot requirements and 26182there must be no insn for which tests in two 'define_delay' expressions 26183are both true. 26184 26185 For example, if we have a machine that requires one delay slot for 26186branches but two for calls, no delay slot can contain a branch or call 26187insn, and any valid insn in the delay slot for the branch can be 26188annulled if the branch is true, we might represent this as follows: 26189 26190 (define_delay (eq_attr "type" "branch") 26191 [(eq_attr "type" "!branch,call") 26192 (eq_attr "type" "!branch,call") 26193 (nil)]) 26194 26195 (define_delay (eq_attr "type" "call") 26196 [(eq_attr "type" "!branch,call") (nil) (nil) 26197 (eq_attr "type" "!branch,call") (nil) (nil)]) 26198 26199 26200File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 26201 2620216.19.9 Specifying processor pipeline description 26203------------------------------------------------- 26204 26205To achieve better performance, most modern processors (super-pipelined, 26206superscalar RISC, and VLIW processors) have many "functional units" on 26207which several instructions can be executed simultaneously. An 26208instruction starts execution if its issue conditions are satisfied. If 26209not, the instruction is stalled until its conditions are satisfied. 26210Such "interlock (pipeline) delay" causes interruption of the fetching of 26211successor instructions (or demands nop instructions, e.g. for some MIPS 26212processors). 26213 26214 There are two major kinds of interlock delays in modern processors. 26215The first one is a data dependence delay determining "instruction 26216latency time". The instruction execution is not started until all 26217source data have been evaluated by prior instructions (there are more 26218complex cases when the instruction execution starts even when the data 26219are not available but will be ready in given time after the instruction 26220execution start). Taking the data dependence delays into account is 26221simple. The data dependence (true, output, and anti-dependence) delay 26222between two instructions is given by a constant. In most cases this 26223approach is adequate. The second kind of interlock delays is a 26224reservation delay. The reservation delay means that two instructions 26225under execution will be in need of shared processors resources, i.e. 26226buses, internal registers, and/or functional units, which are reserved 26227for some time. Taking this kind of delay into account is complex 26228especially for modern RISC processors. 26229 26230 The task of exploiting more processor parallelism is solved by an 26231instruction scheduler. For a better solution to this problem, the 26232instruction scheduler has to have an adequate description of the 26233processor parallelism (or "pipeline description"). GCC machine 26234descriptions describe processor parallelism and functional unit 26235reservations for groups of instructions with the aid of "regular 26236expressions". 26237 26238 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 26239figure out the possibility of the instruction issue by the processor on 26240a given simulated processor cycle. The pipeline hazard recognizer is 26241automatically generated from the processor pipeline description. The 26242pipeline hazard recognizer generated from the machine description is 26243based on a deterministic finite state automaton (DFA): the instruction 26244issue is possible if there is a transition from one automaton state to 26245another one. This algorithm is very fast, and furthermore, its speed is 26246not dependent on processor complexity(1). 26247 26248 The rest of this section describes the directives that constitute an 26249automaton-based processor pipeline description. The order of these 26250constructions within the machine description file is not important. 26251 26252 The following optional construction describes names of automata 26253generated and used for the pipeline hazards recognition. Sometimes the 26254generated finite state automaton used by the pipeline hazard recognizer 26255is large. If we use more than one automaton and bind functional units 26256to the automata, the total size of the automata is usually less than the 26257size of the single automaton. If there is no one such construction, 26258only one finite state automaton is generated. 26259 26260 (define_automaton AUTOMATA-NAMES) 26261 26262 AUTOMATA-NAMES is a string giving names of the automata. The names are 26263separated by commas. All the automata should have unique names. The 26264automaton name is used in the constructions 'define_cpu_unit' and 26265'define_query_cpu_unit'. 26266 26267 Each processor functional unit used in the description of instruction 26268reservations should be described by the following construction. 26269 26270 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 26271 26272 UNIT-NAMES is a string giving the names of the functional units 26273separated by commas. Don't use name 'nothing', it is reserved for other 26274goals. 26275 26276 AUTOMATON-NAME is a string giving the name of the automaton with which 26277the unit is bound. The automaton should be described in construction 26278'define_automaton'. You should give "automaton-name", if there is a 26279defined automaton. 26280 26281 The assignment of units to automata are constrained by the uses of the 26282units in insn reservations. The most important constraint is: if a unit 26283reservation is present on a particular cycle of an alternative for an 26284insn reservation, then some unit from the same automaton must be present 26285on the same cycle for the other alternatives of the insn reservation. 26286The rest of the constraints are mentioned in the description of the 26287subsequent constructions. 26288 26289 The following construction describes CPU functional units analogously 26290to 'define_cpu_unit'. The reservation of such units can be queried for 26291an automaton state. The instruction scheduler never queries reservation 26292of functional units for given automaton state. So as a rule, you don't 26293need this construction. This construction could be used for future code 26294generation goals (e.g. to generate VLIW insn templates). 26295 26296 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 26297 26298 UNIT-NAMES is a string giving names of the functional units separated 26299by commas. 26300 26301 AUTOMATON-NAME is a string giving the name of the automaton with which 26302the unit is bound. 26303 26304 The following construction is the major one to describe pipeline 26305characteristics of an instruction. 26306 26307 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 26308 CONDITION REGEXP) 26309 26310 DEFAULT_LATENCY is a number giving latency time of the instruction. 26311There is an important difference between the old description and the 26312automaton based pipeline description. The latency time is used for all 26313dependencies when we use the old description. In the automaton based 26314pipeline description, the given latency time is only used for true 26315dependencies. The cost of anti-dependencies is always zero and the cost 26316of output dependencies is the difference between latency times of the 26317producing and consuming insns (if the difference is negative, the cost 26318is considered to be zero). You can always change the default costs for 26319any description by using the target hook 'TARGET_SCHED_ADJUST_COST' 26320(*note Scheduling::). 26321 26322 INSN-NAME is a string giving the internal name of the insn. The 26323internal names are used in constructions 'define_bypass' and in the 26324automaton description file generated for debugging. The internal name 26325has nothing in common with the names in 'define_insn'. It is a good 26326practice to use insn classes described in the processor manual. 26327 26328 CONDITION defines what RTL insns are described by this construction. 26329You should remember that you will be in trouble if CONDITION for two or 26330more different 'define_insn_reservation' constructions is TRUE for an 26331insn. In this case what reservation will be used for the insn is not 26332defined. Such cases are not checked during generation of the pipeline 26333hazards recognizer because in general recognizing that two conditions 26334may have the same value is quite difficult (especially if the conditions 26335contain 'symbol_ref'). It is also not checked during the pipeline 26336hazard recognizer work because it would slow down the recognizer 26337considerably. 26338 26339 REGEXP is a string describing the reservation of the cpu's functional 26340units by the instruction. The reservations are described by a regular 26341expression according to the following syntax: 26342 26343 regexp = regexp "," oneof 26344 | oneof 26345 26346 oneof = oneof "|" allof 26347 | allof 26348 26349 allof = allof "+" repeat 26350 | repeat 26351 26352 repeat = element "*" number 26353 | element 26354 26355 element = cpu_function_unit_name 26356 | reservation_name 26357 | result_name 26358 | "nothing" 26359 | "(" regexp ")" 26360 26361 * ',' is used for describing the start of the next cycle in the 26362 reservation. 26363 26364 * '|' is used for describing a reservation described by the first 26365 regular expression *or* a reservation described by the second 26366 regular expression *or* etc. 26367 26368 * '+' is used for describing a reservation described by the first 26369 regular expression *and* a reservation described by the second 26370 regular expression *and* etc. 26371 26372 * '*' is used for convenience and simply means a sequence in which 26373 the regular expression are repeated NUMBER times with cycle 26374 advancing (see ','). 26375 26376 * 'cpu_function_unit_name' denotes reservation of the named 26377 functional unit. 26378 26379 * 'reservation_name' -- see description of construction 26380 'define_reservation'. 26381 26382 * 'nothing' denotes no unit reservations. 26383 26384 Sometimes unit reservations for different insns contain common parts. 26385In such case, you can simplify the pipeline description by describing 26386the common part by the following construction 26387 26388 (define_reservation RESERVATION-NAME REGEXP) 26389 26390 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 26391names and reservation names are in the same name space. So the 26392reservation names should be different from the functional unit names and 26393can not be the reserved name 'nothing'. 26394 26395 The following construction is used to describe exceptions in the 26396latency time for given instruction pair. This is so called bypasses. 26397 26398 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 26399 [GUARD]) 26400 26401 NUMBER defines when the result generated by the instructions given in 26402string OUT_INSN_NAMES will be ready for the instructions given in string 26403IN_INSN_NAMES. Each of these strings is a comma-separated list of 26404filename-style globs and they refer to the names of 26405'define_insn_reservation's. For example: 26406 (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*") 26407 defines a bypass between instructions that start with 'cpu1_load_' or 26408'cpu1_store_' and those that start with 'cpu1_load_'. 26409 26410 GUARD is an optional string giving the name of a C function which 26411defines an additional guard for the bypass. The function will get the 26412two insns as parameters. If the function returns zero the bypass will 26413be ignored for this case. The additional guard is necessary to 26414recognize complicated bypasses, e.g. when the consumer is only an 26415address of insn 'store' (not a stored value). 26416 26417 If there are more one bypass with the same output and input insns, the 26418chosen bypass is the first bypass with a guard in description whose 26419guard function returns nonzero. If there is no such bypass, then bypass 26420without the guard function is chosen. 26421 26422 The following five constructions are usually used to describe VLIW 26423processors, or more precisely, to describe a placement of small 26424instructions into VLIW instruction slots. They can be used for RISC 26425processors, too. 26426 26427 (exclusion_set UNIT-NAMES UNIT-NAMES) 26428 (presence_set UNIT-NAMES PATTERNS) 26429 (final_presence_set UNIT-NAMES PATTERNS) 26430 (absence_set UNIT-NAMES PATTERNS) 26431 (final_absence_set UNIT-NAMES PATTERNS) 26432 26433 UNIT-NAMES is a string giving names of functional units separated by 26434commas. 26435 26436 PATTERNS is a string giving patterns of functional units separated by 26437comma. Currently pattern is one unit or units separated by 26438white-spaces. 26439 26440 The first construction ('exclusion_set') means that each functional 26441unit in the first string can not be reserved simultaneously with a unit 26442whose name is in the second string and vice versa. For example, the 26443construction is useful for describing processors (e.g. some SPARC 26444processors) with a fully pipelined floating point functional unit which 26445can execute simultaneously only single floating point insns or only 26446double floating point insns. 26447 26448 The second construction ('presence_set') means that each functional 26449unit in the first string can not be reserved unless at least one of 26450pattern of units whose names are in the second string is reserved. This 26451is an asymmetric relation. For example, it is useful for description 26452that VLIW 'slot1' is reserved after 'slot0' reservation. We could 26453describe it by the following construction 26454 26455 (presence_set "slot1" "slot0") 26456 26457 Or 'slot1' is reserved only after 'slot0' and unit 'b0' reservation. 26458In this case we could write 26459 26460 (presence_set "slot1" "slot0 b0") 26461 26462 The third construction ('final_presence_set') is analogous to 26463'presence_set'. The difference between them is when checking is done. 26464When an instruction is issued in given automaton state reflecting all 26465current and planned unit reservations, the automaton state is changed. 26466The first state is a source state, the second one is a result state. 26467Checking for 'presence_set' is done on the source state reservation, 26468checking for 'final_presence_set' is done on the result reservation. 26469This construction is useful to describe a reservation which is actually 26470two subsequent reservations. For example, if we use 26471 26472 (presence_set "slot1" "slot0") 26473 26474 the following insn will be never issued (because 'slot1' requires 26475'slot0' which is absent in the source state). 26476 26477 (define_reservation "insn_and_nop" "slot0 + slot1") 26478 26479 but it can be issued if we use analogous 'final_presence_set'. 26480 26481 The forth construction ('absence_set') means that each functional unit 26482in the first string can be reserved only if each pattern of units whose 26483names are in the second string is not reserved. This is an asymmetric 26484relation (actually 'exclusion_set' is analogous to this one but it is 26485symmetric). For example it might be useful in a VLIW description to say 26486that 'slot0' cannot be reserved after either 'slot1' or 'slot2' have 26487been reserved. This can be described as: 26488 26489 (absence_set "slot0" "slot1, slot2") 26490 26491 Or 'slot2' can not be reserved if 'slot0' and unit 'b0' are reserved or 26492'slot1' and unit 'b1' are reserved. In this case we could write 26493 26494 (absence_set "slot2" "slot0 b0, slot1 b1") 26495 26496 All functional units mentioned in a set should belong to the same 26497automaton. 26498 26499 The last construction ('final_absence_set') is analogous to 26500'absence_set' but checking is done on the result (state) reservation. 26501See comments for 'final_presence_set'. 26502 26503 You can control the generator of the pipeline hazard recognizer with 26504the following construction. 26505 26506 (automata_option OPTIONS) 26507 26508 OPTIONS is a string giving options which affect the generated code. 26509Currently there are the following options: 26510 26511 * "no-minimization" makes no minimization of the automaton. This is 26512 only worth to do when we are debugging the description and need to 26513 look more accurately at reservations of states. 26514 26515 * "time" means printing time statistics about the generation of 26516 automata. 26517 26518 * "stats" means printing statistics about the generated automata such 26519 as the number of DFA states, NDFA states and arcs. 26520 26521 * "v" means a generation of the file describing the result automata. 26522 The file has suffix '.dfa' and can be used for the description 26523 verification and debugging. 26524 26525 * "w" means a generation of warning instead of error for non-critical 26526 errors. 26527 26528 * "no-comb-vect" prevents the automaton generator from generating two 26529 data structures and comparing them for space efficiency. Using a 26530 comb vector to represent transitions may be better, but it can be 26531 very expensive to construct. This option is useful if the build 26532 process spends an unacceptably long time in genautomata. 26533 26534 * "ndfa" makes nondeterministic finite state automata. This affects 26535 the treatment of operator '|' in the regular expressions. The 26536 usual treatment of the operator is to try the first alternative 26537 and, if the reservation is not possible, the second alternative. 26538 The nondeterministic treatment means trying all alternatives, some 26539 of them may be rejected by reservations in the subsequent insns. 26540 26541 * "collapse-ndfa" modifies the behaviour of the generator when 26542 producing an automaton. An additional state transition to collapse 26543 a nondeterministic NDFA state to a deterministic DFA state is 26544 generated. It can be triggered by passing 'const0_rtx' to 26545 state_transition. In such an automaton, cycle advance transitions 26546 are available only for these collapsed states. This option is 26547 useful for ports that want to use the 'ndfa' option, but also want 26548 to use 'define_query_cpu_unit' to assign units to insns issued in a 26549 cycle. 26550 26551 * "progress" means output of a progress bar showing how many states 26552 were generated so far for automaton being processed. This is 26553 useful during debugging a DFA description. If you see too many 26554 generated states, you could interrupt the generator of the pipeline 26555 hazard recognizer and try to figure out a reason for generation of 26556 the huge automaton. 26557 26558 As an example, consider a superscalar RISC machine which can issue 26559three insns (two integer insns and one floating point insn) on the cycle 26560but can finish only two insns. To describe this, we define the 26561following functional units. 26562 26563 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 26564 (define_cpu_unit "port0, port1") 26565 26566 All simple integer insns can be executed in any integer pipeline and 26567their result is ready in two cycles. The simple integer insns are 26568issued into the first pipeline unless it is reserved, otherwise they are 26569issued into the second pipeline. Integer division and multiplication 26570insns can be executed only in the second integer pipeline and their 26571results are ready correspondingly in 8 and 4 cycles. The integer 26572division is not pipelined, i.e. the subsequent integer division insn can 26573not be issued until the current division insn finished. Floating point 26574insns are fully pipelined and their results are ready in 3 cycles. 26575Where the result of a floating point insn is used by an integer insn, an 26576additional delay of one cycle is incurred. To describe all of this we 26577could specify 26578 26579 (define_cpu_unit "div") 26580 26581 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 26582 "(i0_pipeline | i1_pipeline), (port0 | port1)") 26583 26584 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 26585 "i1_pipeline, nothing*2, (port0 | port1)") 26586 26587 (define_insn_reservation "div" 8 (eq_attr "type" "div") 26588 "i1_pipeline, div*7, div + (port0 | port1)") 26589 26590 (define_insn_reservation "float" 3 (eq_attr "type" "float") 26591 "f_pipeline, nothing, (port0 | port1)) 26592 26593 (define_bypass 4 "float" "simple,mult,div") 26594 26595 To simplify the description we could describe the following reservation 26596 26597 (define_reservation "finish" "port0|port1") 26598 26599 and use it in all 'define_insn_reservation' as in the following 26600construction 26601 26602 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 26603 "(i0_pipeline | i1_pipeline), finish") 26604 26605 ---------- Footnotes ---------- 26606 26607 (1) However, the size of the automaton depends on processor 26608complexity. To limit this effect, machine descriptions can split 26609orthogonal parts of the machine description among several automata: but 26610then, since each of these must be stepped independently, this does cause 26611a small decrease in the algorithm's performance. 26612 26613 26614File: gccint.info, Node: Conditional Execution, Next: Define Subst, Prev: Insn Attributes, Up: Machine Desc 26615 2661616.20 Conditional Execution 26617=========================== 26618 26619A number of architectures provide for some form of conditional 26620execution, or predication. The hallmark of this feature is the ability 26621to nullify most of the instructions in the instruction set. When the 26622instruction set is large and not entirely symmetric, it can be quite 26623tedious to describe these forms directly in the '.md' file. An 26624alternative is the 'define_cond_exec' template. 26625 26626 (define_cond_exec 26627 [PREDICATE-PATTERN] 26628 "CONDITION" 26629 "OUTPUT-TEMPLATE" 26630 "OPTIONAL-INSN-ATTRIBUES") 26631 26632 PREDICATE-PATTERN is the condition that must be true for the insn to be 26633executed at runtime and should match a relational operator. One can use 26634'match_operator' to match several relational operators at once. Any 26635'match_operand' operands must have no more than one alternative. 26636 26637 CONDITION is a C expression that must be true for the generated pattern 26638to match. 26639 26640 OUTPUT-TEMPLATE is a string similar to the 'define_insn' output 26641template (*note Output Template::), except that the '*' and '@' special 26642cases do not apply. This is only useful if the assembly text for the 26643predicate is a simple prefix to the main insn. In order to handle the 26644general case, there is a global variable 'current_insn_predicate' that 26645will contain the entire predicate if the current insn is predicated, and 26646will otherwise be 'NULL'. 26647 26648 OPTIONAL-INSN-ATTRIBUTES is an optional vector of attributes that gets 26649appended to the insn attributes of the produced cond_exec rtx. It can 26650be used to add some distinguishing attribute to cond_exec rtxs produced 26651that way. An example usage would be to use this attribute in 26652conjunction with attributes on the main pattern to disable particular 26653alternatives under certain conditions. 26654 26655 When 'define_cond_exec' is used, an implicit reference to the 26656'predicable' instruction attribute is made. *Note Insn Attributes::. 26657This attribute must be a boolean (i.e. have exactly two elements in its 26658LIST-OF-VALUES), with the possible values being 'no' and 'yes'. The 26659default and all uses in the insns must be a simple constant, not a 26660complex expressions. It may, however, depend on the alternative, by 26661using a comma-separated list of values. If that is the case, the port 26662should also define an 'enabled' attribute (*note Disable Insn 26663Alternatives::), which should also allow only 'no' and 'yes' as its 26664values. 26665 26666 For each 'define_insn' for which the 'predicable' attribute is true, a 26667new 'define_insn' pattern will be generated that matches a predicated 26668version of the instruction. For example, 26669 26670 (define_insn "addsi" 26671 [(set (match_operand:SI 0 "register_operand" "r") 26672 (plus:SI (match_operand:SI 1 "register_operand" "r") 26673 (match_operand:SI 2 "register_operand" "r")))] 26674 "TEST1" 26675 "add %2,%1,%0") 26676 26677 (define_cond_exec 26678 [(ne (match_operand:CC 0 "register_operand" "c") 26679 (const_int 0))] 26680 "TEST2" 26681 "(%0)") 26682 26683generates a new pattern 26684 26685 (define_insn "" 26686 [(cond_exec 26687 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 26688 (set (match_operand:SI 0 "register_operand" "r") 26689 (plus:SI (match_operand:SI 1 "register_operand" "r") 26690 (match_operand:SI 2 "register_operand" "r"))))] 26691 "(TEST2) && (TEST1)" 26692 "(%3) add %2,%1,%0") 26693 26694 26695File: gccint.info, Node: Define Subst, Next: Constant Definitions, Prev: Conditional Execution, Up: Machine Desc 26696 2669716.21 RTL Templates Transformations 26698=================================== 26699 26700For some hardware architectures there are common cases when the RTL 26701templates for the instructions can be derived from the other RTL 26702templates using simple transformations. E.g., 'i386.md' contains an RTL 26703template for the ordinary 'sub' instruction-- '*subsi_1', and for the 26704'sub' instruction with subsequent zero-extension--'*subsi_1_zext'. Such 26705cases can be easily implemented by a single meta-template capable of 26706generating a modified case based on the initial one: 26707 26708 (define_subst "NAME" 26709 [INPUT-TEMPLATE] 26710 "CONDITION" 26711 [OUTPUT-TEMPLATE]) 26712 INPUT-TEMPLATE is a pattern describing the source RTL template, which 26713will be transformed. 26714 26715 CONDITION is a C expression that is conjunct with the condition from 26716the input-template to generate a condition to be used in the 26717output-template. 26718 26719 OUTPUT-TEMPLATE is a pattern that will be used in the resulting 26720template. 26721 26722 'define_subst' mechanism is tightly coupled with the notion of the 26723subst attribute (*note Subst Iterators::). The use of 'define_subst' is 26724triggered by a reference to a subst attribute in the transforming RTL 26725template. This reference initiates duplication of the source RTL 26726template and substitution of the attributes with their values. The 26727source RTL template is left unchanged, while the copy is transformed by 26728'define_subst'. This transformation can fail in the case when the 26729source RTL template is not matched against the input-template of the 26730'define_subst'. In such case the copy is deleted. 26731 26732 'define_subst' can be used only in 'define_insn' and 'define_expand', 26733it cannot be used in other expressions (e.g. in 26734'define_insn_and_split'). 26735 26736* Menu: 26737 26738* Define Subst Example:: Example of 'define_subst' work. 26739* Define Subst Pattern Matching:: Process of template comparison. 26740* Define Subst Output Template:: Generation of output template. 26741 26742 26743File: gccint.info, Node: Define Subst Example, Next: Define Subst Pattern Matching, Up: Define Subst 26744 2674516.21.1 'define_subst' Example 26746------------------------------ 26747 26748To illustrate how 'define_subst' works, let us examine a simple template 26749transformation. 26750 26751 Suppose there are two kinds of instructions: one that touches flags and 26752the other that does not. The instructions of the second type could be 26753generated with the following 'define_subst': 26754 26755 (define_subst "add_clobber_subst" 26756 [(set (match_operand:SI 0 "" "") 26757 (match_operand:SI 1 "" ""))] 26758 "" 26759 [(set (match_dup 0) 26760 (match_dup 1)) 26761 (clobber (reg:CC FLAGS_REG))] 26762 26763 This 'define_subst' can be applied to any RTL pattern containing 'set' 26764of mode SI and generates a copy with clobber when it is applied. 26765 26766 Assume there is an RTL template for a 'max' instruction to be used in 26767'define_subst' mentioned above: 26768 26769 (define_insn "maxsi" 26770 [(set (match_operand:SI 0 "register_operand" "=r") 26771 (max:SI 26772 (match_operand:SI 1 "register_operand" "r") 26773 (match_operand:SI 2 "register_operand" "r")))] 26774 "" 26775 "max\t{%2, %1, %0|%0, %1, %2}" 26776 [...]) 26777 26778 To mark the RTL template for 'define_subst' application, 26779subst-attributes are used. They should be declared in advance: 26780 26781 (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber") 26782 26783 Here 'add_clobber_name' is the attribute name, 'add_clobber_subst' is 26784the name of the corresponding 'define_subst', the third argument 26785('_noclobber') is the attribute value that would be substituted into the 26786unchanged version of the source RTL template, and the last argument 26787('_clobber') is the value that would be substituted into the second, 26788transformed, version of the RTL template. 26789 26790 Once the subst-attribute has been defined, it should be used in RTL 26791templates which need to be processed by the 'define_subst'. So, the 26792original RTL template should be changed: 26793 26794 (define_insn "maxsi<add_clobber_name>" 26795 [(set (match_operand:SI 0 "register_operand" "=r") 26796 (max:SI 26797 (match_operand:SI 1 "register_operand" "r") 26798 (match_operand:SI 2 "register_operand" "r")))] 26799 "" 26800 "max\t{%2, %1, %0|%0, %1, %2}" 26801 [...]) 26802 26803 The result of the 'define_subst' usage would look like the following: 26804 26805 (define_insn "maxsi_noclobber" 26806 [(set (match_operand:SI 0 "register_operand" "=r") 26807 (max:SI 26808 (match_operand:SI 1 "register_operand" "r") 26809 (match_operand:SI 2 "register_operand" "r")))] 26810 "" 26811 "max\t{%2, %1, %0|%0, %1, %2}" 26812 [...]) 26813 (define_insn "maxsi_clobber" 26814 [(set (match_operand:SI 0 "register_operand" "=r") 26815 (max:SI 26816 (match_operand:SI 1 "register_operand" "r") 26817 (match_operand:SI 2 "register_operand" "r"))) 26818 (clobber (reg:CC FLAGS_REG))] 26819 "" 26820 "max\t{%2, %1, %0|%0, %1, %2}" 26821 [...]) 26822 26823 26824File: gccint.info, Node: Define Subst Pattern Matching, Next: Define Subst Output Template, Prev: Define Subst Example, Up: Define Subst 26825 2682616.21.2 Pattern Matching in 'define_subst' 26827------------------------------------------ 26828 26829All expressions, allowed in 'define_insn' or 'define_expand', are 26830allowed in the input-template of 'define_subst', except 'match_par_dup', 26831'match_scratch', 'match_parallel'. The meanings of expressions in the 26832input-template were changed: 26833 26834 'match_operand' matches any expression (possibly, a subtree in 26835RTL-template), if modes of the 'match_operand' and this expression are 26836the same, or mode of the 'match_operand' is 'VOIDmode', or this 26837expression is 'match_dup', 'match_op_dup'. If the expression is 26838'match_operand' too, and predicate of 'match_operand' from the input 26839pattern is not empty, then the predicates are compared. That can be 26840used for more accurate filtering of accepted RTL-templates. 26841 26842 'match_operator' matches common operators (like 'plus', 'minus'), 26843'unspec', 'unspec_volatile' operators and 'match_operator's from the 26844original pattern if the modes match and 'match_operator' from the input 26845pattern has the same number of operands as the operator from the 26846original pattern. 26847 26848 26849File: gccint.info, Node: Define Subst Output Template, Prev: Define Subst Pattern Matching, Up: Define Subst 26850 2685116.21.3 Generation of output template in 'define_subst' 26852------------------------------------------------------- 26853 26854If all necessary checks for 'define_subst' application pass, a new 26855RTL-pattern, based on the output-template, is created to replace the old 26856template. Like in input-patterns, meanings of some RTL expressions are 26857changed when they are used in output-patterns of a 'define_subst'. 26858Thus, 'match_dup' is used for copying the whole expression from the 26859original pattern, which matched corresponding 'match_operand' from the 26860input pattern. 26861 26862 'match_dup N' is used in the output template to be replaced with the 26863expression from the original pattern, which matched 'match_operand N' 26864from the input pattern. As a consequence, 'match_dup' cannot be used to 26865point to 'match_operand's from the output pattern, it should always 26866refer to a 'match_operand' from the input pattern. 26867 26868 In the output template one can refer to the expressions from the 26869original pattern and create new ones. For instance, some operands could 26870be added by means of standard 'match_operand'. 26871 26872 After replacing 'match_dup' with some RTL-subtree from the original 26873pattern, it could happen that several 'match_operand's in the output 26874pattern have the same indexes. It is unknown, how many and what indexes 26875would be used in the expression which would replace 'match_dup', so such 26876conflicts in indexes are inevitable. To overcome this issue, 26877'match_operands' and 'match_operators', which were introduced into the 26878output pattern, are renumerated when all 'match_dup's are replaced. 26879 26880 Number of alternatives in 'match_operand's introduced into the output 26881template 'M' could differ from the number of alternatives in the 26882original pattern 'N', so in the resultant pattern there would be 'N*M' 26883alternatives. Thus, constraints from the original pattern would be 26884duplicated 'N' times, constraints from the output pattern would be 26885duplicated 'M' times, producing all possible combinations. 26886 26887 26888File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Define Subst, Up: Machine Desc 26889 2689016.22 Constant Definitions 26891========================== 26892 26893Using literal constants inside instruction patterns reduces legibility 26894and can be a maintenance problem. 26895 26896 To overcome this problem, you may use the 'define_constants' 26897expression. It contains a vector of name-value pairs. From that point 26898on, wherever any of the names appears in the MD file, it is as if the 26899corresponding value had been written instead. You may use 26900'define_constants' multiple times; each appearance adds more constants 26901to the table. It is an error to redefine a constant with a different 26902value. 26903 26904 To come back to the a29k load multiple example, instead of 26905 26906 (define_insn "" 26907 [(match_parallel 0 "load_multiple_operation" 26908 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 26909 (match_operand:SI 2 "memory_operand" "m")) 26910 (use (reg:SI 179)) 26911 (clobber (reg:SI 179))])] 26912 "" 26913 "loadm 0,0,%1,%2") 26914 26915 You could write: 26916 26917 (define_constants [ 26918 (R_BP 177) 26919 (R_FC 178) 26920 (R_CR 179) 26921 (R_Q 180) 26922 ]) 26923 26924 (define_insn "" 26925 [(match_parallel 0 "load_multiple_operation" 26926 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 26927 (match_operand:SI 2 "memory_operand" "m")) 26928 (use (reg:SI R_CR)) 26929 (clobber (reg:SI R_CR))])] 26930 "" 26931 "loadm 0,0,%1,%2") 26932 26933 The constants that are defined with a define_constant are also output 26934in the insn-codes.h header file as #defines. 26935 26936 You can also use the machine description file to define enumerations. 26937Like the constants defined by 'define_constant', these enumerations are 26938visible to both the machine description file and the main C code. 26939 26940 The syntax is as follows: 26941 26942 (define_c_enum "NAME" [ 26943 VALUE0 26944 VALUE1 26945 ... 26946 VALUEN 26947 ]) 26948 26949 This definition causes the equivalent of the following C code to appear 26950in 'insn-constants.h': 26951 26952 enum NAME { 26953 VALUE0 = 0, 26954 VALUE1 = 1, 26955 ... 26956 VALUEN = N 26957 }; 26958 #define NUM_CNAME_VALUES (N + 1) 26959 26960 where CNAME is the capitalized form of NAME. It also makes each VALUEI 26961available in the machine description file, just as if it had been 26962declared with: 26963 26964 (define_constants [(VALUEI I)]) 26965 26966 Each VALUEI is usually an upper-case identifier and usually begins with 26967CNAME. 26968 26969 You can split the enumeration definition into as many statements as you 26970like. The above example is directly equivalent to: 26971 26972 (define_c_enum "NAME" [VALUE0]) 26973 (define_c_enum "NAME" [VALUE1]) 26974 ... 26975 (define_c_enum "NAME" [VALUEN]) 26976 26977 Splitting the enumeration helps to improve the modularity of each 26978individual '.md' file. For example, if a port defines its 26979synchronization instructions in a separate 'sync.md' file, it is 26980convenient to define all synchronization-specific enumeration values in 26981'sync.md' rather than in the main '.md' file. 26982 26983 Some enumeration names have special significance to GCC: 26984 26985'unspecv' 26986 If an enumeration called 'unspecv' is defined, GCC will use it when 26987 printing out 'unspec_volatile' expressions. For example: 26988 26989 (define_c_enum "unspecv" [ 26990 UNSPECV_BLOCKAGE 26991 ]) 26992 26993 causes GCC to print '(unspec_volatile ... 0)' as: 26994 26995 (unspec_volatile ... UNSPECV_BLOCKAGE) 26996 26997'unspec' 26998 If an enumeration called 'unspec' is defined, GCC will use it when 26999 printing out 'unspec' expressions. GCC will also use it when 27000 printing out 'unspec_volatile' expressions unless an 'unspecv' 27001 enumeration is also defined. You can therefore decide whether to 27002 keep separate enumerations for volatile and non-volatile 27003 expressions or whether to use the same enumeration for both. 27004 27005 Another way of defining an enumeration is to use 'define_enum': 27006 27007 (define_enum "NAME" [ 27008 VALUE0 27009 VALUE1 27010 ... 27011 VALUEN 27012 ]) 27013 27014 This directive implies: 27015 27016 (define_c_enum "NAME" [ 27017 CNAME_CVALUE0 27018 CNAME_CVALUE1 27019 ... 27020 CNAME_CVALUEN 27021 ]) 27022 27023 where CVALUEI is the capitalized form of VALUEI. However, unlike 27024'define_c_enum', the enumerations defined by 'define_enum' can be used 27025in attribute specifications (*note define_enum_attr::). 27026 27027 27028File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc 27029 2703016.23 Iterators 27031=============== 27032 27033Ports often need to define similar patterns for more than one machine 27034mode or for more than one rtx code. GCC provides some simple iterator 27035facilities to make this process easier. 27036 27037* Menu: 27038 27039* Mode Iterators:: Generating variations of patterns for different modes. 27040* Code Iterators:: Doing the same for codes. 27041* Int Iterators:: Doing the same for integers. 27042* Subst Iterators:: Generating variations of patterns for define_subst. 27043 27044 27045File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators 27046 2704716.23.1 Mode Iterators 27048---------------------- 27049 27050Ports often need to define similar patterns for two or more different 27051modes. For example: 27052 27053 * If a processor has hardware support for both single and double 27054 floating-point arithmetic, the 'SFmode' patterns tend to be very 27055 similar to the 'DFmode' ones. 27056 27057 * If a port uses 'SImode' pointers in one configuration and 'DImode' 27058 pointers in another, it will usually have very similar 'SImode' and 27059 'DImode' patterns for manipulating pointers. 27060 27061 Mode iterators allow several patterns to be instantiated from one '.md' 27062file template. They can be used with any type of rtx-based construct, 27063such as a 'define_insn', 'define_split', or 'define_peephole2'. 27064 27065* Menu: 27066 27067* Defining Mode Iterators:: Defining a new mode iterator. 27068* Substitutions:: Combining mode iterators with substitutions 27069* Examples:: Examples 27070 27071 27072File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators 27073 2707416.23.1.1 Defining Mode Iterators 27075................................. 27076 27077The syntax for defining a mode iterator is: 27078 27079 (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 27080 27081 This allows subsequent '.md' file constructs to use the mode suffix 27082':NAME'. Every construct that does so will be expanded N times, once 27083with every use of ':NAME' replaced by ':MODE1', once with every use 27084replaced by ':MODE2', and so on. In the expansion for a particular 27085MODEI, every C condition will also require that CONDI be true. 27086 27087 For example: 27088 27089 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 27090 27091 defines a new mode suffix ':P'. Every construct that uses ':P' will be 27092expanded twice, once with every ':P' replaced by ':SI' and once with 27093every ':P' replaced by ':DI'. The ':SI' version will only apply if 27094'Pmode == SImode' and the ':DI' version will only apply if 'Pmode == 27095DImode'. 27096 27097 As with other '.md' conditions, an empty string is treated as "always 27098true". '(MODE "")' can also be abbreviated to 'MODE'. For example: 27099 27100 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 27101 27102 means that the ':DI' expansion only applies if 'TARGET_64BIT' but that 27103the ':SI' expansion has no such constraint. 27104 27105 Iterators are applied in the order they are defined. This can be 27106significant if two iterators are used in a construct that requires 27107substitutions. *Note Substitutions::. 27108 27109 27110File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators 27111 2711216.23.1.2 Substitution in Mode Iterators 27113........................................ 27114 27115If an '.md' file construct uses mode iterators, each version of the 27116construct will often need slightly different strings or modes. For 27117example: 27118 27119 * When a 'define_expand' defines several 'addM3' patterns (*note 27120 Standard Names::), each expander will need to use the appropriate 27121 mode name for M. 27122 27123 * When a 'define_insn' defines several instruction patterns, each 27124 instruction will often use a different assembler mnemonic. 27125 27126 * When a 'define_insn' requires operands with different modes, using 27127 an iterator for one of the operand modes usually requires a 27128 specific mode for the other operand(s). 27129 27130 GCC supports such variations through a system of "mode attributes". 27131There are two standard attributes: 'mode', which is the name of the mode 27132in lower case, and 'MODE', which is the same thing in upper case. You 27133can define other attributes using: 27134 27135 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 27136 27137 where NAME is the name of the attribute and VALUEI is the value 27138associated with MODEI. 27139 27140 When GCC replaces some :ITERATOR with :MODE, it will scan each string 27141and mode in the pattern for sequences of the form '<ITERATOR:ATTR>', 27142where ATTR is the name of a mode attribute. If the attribute is defined 27143for MODE, the whole '<...>' sequence will be replaced by the appropriate 27144attribute value. 27145 27146 For example, suppose an '.md' file has: 27147 27148 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 27149 (define_mode_attr load [(SI "lw") (DI "ld")]) 27150 27151 If one of the patterns that uses ':P' contains the string 27152'"<P:load>\t%0,%1"', the 'SI' version of that pattern will use 27153'"lw\t%0,%1"' and the 'DI' version will use '"ld\t%0,%1"'. 27154 27155 Here is an example of using an attribute for a mode: 27156 27157 (define_mode_iterator LONG [SI DI]) 27158 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 27159 (define_insn ... 27160 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 27161 27162 The 'ITERATOR:' prefix may be omitted, in which case the substitution 27163will be attempted for every iterator expansion. 27164 27165 27166File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators 27167 2716816.23.1.3 Mode Iterator Examples 27169................................ 27170 27171Here is an example from the MIPS port. It defines the following modes 27172and attributes (among others): 27173 27174 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 27175 (define_mode_attr d [(SI "") (DI "d")]) 27176 27177 and uses the following template to define both 'subsi3' and 'subdi3': 27178 27179 (define_insn "sub<mode>3" 27180 [(set (match_operand:GPR 0 "register_operand" "=d") 27181 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 27182 (match_operand:GPR 2 "register_operand" "d")))] 27183 "" 27184 "<d>subu\t%0,%1,%2" 27185 [(set_attr "type" "arith") 27186 (set_attr "mode" "<MODE>")]) 27187 27188 This is exactly equivalent to: 27189 27190 (define_insn "subsi3" 27191 [(set (match_operand:SI 0 "register_operand" "=d") 27192 (minus:SI (match_operand:SI 1 "register_operand" "d") 27193 (match_operand:SI 2 "register_operand" "d")))] 27194 "" 27195 "subu\t%0,%1,%2" 27196 [(set_attr "type" "arith") 27197 (set_attr "mode" "SI")]) 27198 27199 (define_insn "subdi3" 27200 [(set (match_operand:DI 0 "register_operand" "=d") 27201 (minus:DI (match_operand:DI 1 "register_operand" "d") 27202 (match_operand:DI 2 "register_operand" "d")))] 27203 "" 27204 "dsubu\t%0,%1,%2" 27205 [(set_attr "type" "arith") 27206 (set_attr "mode" "DI")]) 27207 27208 27209File: gccint.info, Node: Code Iterators, Next: Int Iterators, Prev: Mode Iterators, Up: Iterators 27210 2721116.23.2 Code Iterators 27212---------------------- 27213 27214Code iterators operate in a similar way to mode iterators. *Note Mode 27215Iterators::. 27216 27217 The construct: 27218 27219 (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 27220 27221 defines a pseudo rtx code NAME that can be instantiated as CODEI if 27222condition CONDI is true. Each CODEI must have the same rtx format. 27223*Note RTL Classes::. 27224 27225 As with mode iterators, each pattern that uses NAME will be expanded N 27226times, once with all uses of NAME replaced by CODE1, once with all uses 27227replaced by CODE2, and so on. *Note Defining Mode Iterators::. 27228 27229 It is possible to define attributes for codes as well as for modes. 27230There are two standard code attributes: 'code', the name of the code in 27231lower case, and 'CODE', the name of the code in upper case. Other 27232attributes are defined using: 27233 27234 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 27235 27236 Here's an example of code iterators in action, taken from the MIPS 27237port: 27238 27239 (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt 27240 eq ne gt ge lt le gtu geu ltu leu]) 27241 27242 (define_expand "b<code>" 27243 [(set (pc) 27244 (if_then_else (any_cond:CC (cc0) 27245 (const_int 0)) 27246 (label_ref (match_operand 0 "")) 27247 (pc)))] 27248 "" 27249 { 27250 gen_conditional_branch (operands, <CODE>); 27251 DONE; 27252 }) 27253 27254 This is equivalent to: 27255 27256 (define_expand "bunordered" 27257 [(set (pc) 27258 (if_then_else (unordered:CC (cc0) 27259 (const_int 0)) 27260 (label_ref (match_operand 0 "")) 27261 (pc)))] 27262 "" 27263 { 27264 gen_conditional_branch (operands, UNORDERED); 27265 DONE; 27266 }) 27267 27268 (define_expand "bordered" 27269 [(set (pc) 27270 (if_then_else (ordered:CC (cc0) 27271 (const_int 0)) 27272 (label_ref (match_operand 0 "")) 27273 (pc)))] 27274 "" 27275 { 27276 gen_conditional_branch (operands, ORDERED); 27277 DONE; 27278 }) 27279 27280 ... 27281 27282 27283File: gccint.info, Node: Int Iterators, Next: Subst Iterators, Prev: Code Iterators, Up: Iterators 27284 2728516.23.3 Int Iterators 27286--------------------- 27287 27288Int iterators operate in a similar way to code iterators. *Note Code 27289Iterators::. 27290 27291 The construct: 27292 27293 (define_int_iterator NAME [(INT1 "COND1") ... (INTN "CONDN")]) 27294 27295 defines a pseudo integer constant NAME that can be instantiated as INTI 27296if condition CONDI is true. Each INT must have the same rtx format. 27297*Note RTL Classes::. Int iterators can appear in only those rtx fields 27298that have 'i' as the specifier. This means that each INT has to be a 27299constant defined using define_constant or define_c_enum. 27300 27301 As with mode and code iterators, each pattern that uses NAME will be 27302expanded N times, once with all uses of NAME replaced by INT1, once with 27303all uses replaced by INT2, and so on. *Note Defining Mode Iterators::. 27304 27305 It is possible to define attributes for ints as well as for codes and 27306modes. Attributes are defined using: 27307 27308 (define_int_attr NAME [(INT1 "VALUE1") ... (INTN "VALUEN")]) 27309 27310 Here's an example of int iterators in action, taken from the ARM port: 27311 27312 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 27313 27314 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 27315 27316 (define_insn "neon_vq<absneg><mode>" 27317 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 27318 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 27319 (match_operand:SI 2 "immediate_operand" "i")] 27320 QABSNEG))] 27321 "TARGET_NEON" 27322 "vq<absneg>.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 27323 [(set_attr "type" "neon_vqneg_vqabs")] 27324 ) 27325 27326 27327 This is equivalent to: 27328 27329 (define_insn "neon_vqabs<mode>" 27330 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 27331 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 27332 (match_operand:SI 2 "immediate_operand" "i")] 27333 UNSPEC_VQABS))] 27334 "TARGET_NEON" 27335 "vqabs.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 27336 [(set_attr "type" "neon_vqneg_vqabs")] 27337 ) 27338 27339 (define_insn "neon_vqneg<mode>" 27340 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 27341 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 27342 (match_operand:SI 2 "immediate_operand" "i")] 27343 UNSPEC_VQNEG))] 27344 "TARGET_NEON" 27345 "vqneg.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 27346 [(set_attr "type" "neon_vqneg_vqabs")] 27347 ) 27348 27349 27350 27351File: gccint.info, Node: Subst Iterators, Prev: Int Iterators, Up: Iterators 27352 2735316.23.4 Subst Iterators 27354----------------------- 27355 27356Subst iterators are special type of iterators with the following 27357restrictions: they could not be declared explicitly, they always have 27358only two values, and they do not have explicit dedicated name. 27359Subst-iterators are triggered only when corresponding subst-attribute is 27360used in RTL-pattern. 27361 27362 Subst iterators transform templates in the following way: the templates 27363are duplicated, the subst-attributes in these templates are replaced 27364with the corresponding values, and a new attribute is implicitly added 27365to the given 'define_insn'/'define_expand'. The name of the added 27366attribute matches the name of 'define_subst'. Such attributes are 27367declared implicitly, and it is not allowed to have a 'define_attr' named 27368as a 'define_subst'. 27369 27370 Each subst iterator is linked to a 'define_subst'. It is declared 27371implicitly by the first appearance of the corresponding 27372'define_subst_attr', and it is not allowed to define it explicitly. 27373 27374 Declarations of subst-attributes have the following syntax: 27375 27376 (define_subst_attr "NAME" 27377 "SUBST-NAME" 27378 "NO-SUBST-VALUE" 27379 "SUBST-APPLIED-VALUE") 27380 27381 NAME is a string with which the given subst-attribute could be referred 27382to. 27383 27384 SUBST-NAME shows which 'define_subst' should be applied to an 27385RTL-template if the given subst-attribute is present in the 27386RTL-template. 27387 27388 NO-SUBST-VALUE is a value with which subst-attribute would be replaced 27389in the first copy of the original RTL-template. 27390 27391 SUBST-APPLIED-VALUE is a value with which subst-attribute would be 27392replaced in the second copy of the original RTL-template. 27393 27394 27395File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 27396 2739717 Target Description Macros and Functions 27398****************************************** 27399 27400In addition to the file 'MACHINE.md', a machine description includes a C 27401header file conventionally given the name 'MACHINE.h' and a C source 27402file named 'MACHINE.c'. The header file defines numerous macros that 27403convey the information about the target machine that does not fit into 27404the scheme of the '.md' file. The file 'tm.h' should be a link to 27405'MACHINE.h'. The header file 'config.h' includes 'tm.h' and most 27406compiler source files include 'config.h'. The source file defines a 27407variable 'targetm', which is a structure containing pointers to 27408functions and data relating to the target machine. 'MACHINE.c' should 27409also contain their definitions, if they are not defined elsewhere in 27410GCC, and other functions called through the macros defined in the '.h' 27411file. 27412 27413* Menu: 27414 27415* Target Structure:: The 'targetm' variable. 27416* Driver:: Controlling how the driver runs the compilation passes. 27417* Run-time Target:: Defining '-m' options like '-m68000' and '-m68020'. 27418* Per-Function Data:: Defining data structures for per-function information. 27419* Storage Layout:: Defining sizes and alignments of data. 27420* Type Layout:: Defining sizes and properties of basic user data types. 27421* Registers:: Naming and describing the hardware registers. 27422* Register Classes:: Defining the classes of hardware registers. 27423* Stack and Calling:: Defining which way the stack grows and by how much. 27424* Varargs:: Defining the varargs macros. 27425* Trampolines:: Code set up at run time to enter a nested function. 27426* Library Calls:: Controlling how library routines are implicitly called. 27427* Addressing Modes:: Defining addressing modes valid for memory operands. 27428* Anchored Addresses:: Defining how '-fsection-anchors' should work. 27429* Condition Code:: Defining how insns update the condition code. 27430* Costs:: Defining relative costs of different operations. 27431* Scheduling:: Adjusting the behavior of the instruction scheduler. 27432* Sections:: Dividing storage into text, data, and other sections. 27433* PIC:: Macros for position independent code. 27434* Assembler Format:: Defining how to write insns and pseudo-ops to output. 27435* Debugging Info:: Defining the format of debugging output. 27436* Floating Point:: Handling floating point for cross-compilers. 27437* Mode Switching:: Insertion of mode-switching instructions. 27438* Target Attributes:: Defining target-specific uses of '__attribute__'. 27439* Emulated TLS:: Emulated TLS support. 27440* MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 27441* PCH Target:: Validity checking for precompiled headers. 27442* C++ ABI:: Controlling C++ ABI changes. 27443* Named Address Spaces:: Adding support for named address spaces 27444* Misc:: Everything else. 27445 27446 27447File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 27448 2744917.1 The Global 'targetm' Variable 27450================================== 27451 27452 -- Variable: struct gcc_target targetm 27453 The target '.c' file must define the global 'targetm' variable 27454 which contains pointers to functions and data relating to the 27455 target machine. The variable is declared in 'target.h'; 27456 'target-def.h' defines the macro 'TARGET_INITIALIZER' which is used 27457 to initialize the variable, and macros for the default initializers 27458 for elements of the structure. The '.c' file should override those 27459 macros for which the default definition is inappropriate. For 27460 example: 27461 #include "target.h" 27462 #include "target-def.h" 27463 27464 /* Initialize the GCC target structure. */ 27465 27466 #undef TARGET_COMP_TYPE_ATTRIBUTES 27467 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 27468 27469 struct gcc_target targetm = TARGET_INITIALIZER; 27470 27471 Where a macro should be defined in the '.c' file in this manner to form 27472part of the 'targetm' structure, it is documented below as a "Target 27473Hook" with a prototype. Many macros will change in future from being 27474defined in the '.h' file to being part of the 'targetm' structure. 27475 27476 Similarly, there is a 'targetcm' variable for hooks that are specific 27477to front ends for C-family languages, documented as "C Target Hook". 27478This is declared in 'c-family/c-target.h', the initializer 27479'TARGETCM_INITIALIZER' in 'c-family/c-target-def.h'. If targets 27480initialize 'targetcm' themselves, they should set 27481'target_has_targetcm=yes' in 'config.gcc'; otherwise a default 27482definition is used. 27483 27484 Similarly, there is a 'targetm_common' variable for hooks that are 27485shared between the compiler driver and the compilers proper, documented 27486as "Common Target Hook". This is declared in 'common/common-target.h', 27487the initializer 'TARGETM_COMMON_INITIALIZER' in 27488'common/common-target-def.h'. If targets initialize 'targetm_common' 27489themselves, they should set 'target_has_targetm_common=yes' in 27490'config.gcc'; otherwise a default definition is used. 27491 27492 27493File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 27494 2749517.2 Controlling the Compilation Driver, 'gcc' 27496============================================== 27497 27498You can control the compilation driver. 27499 27500 -- Macro: DRIVER_SELF_SPECS 27501 A list of specs for the driver itself. It should be a suitable 27502 initializer for an array of strings, with no surrounding braces. 27503 27504 The driver applies these specs to its own command line between 27505 loading default 'specs' files (but not command-line specified ones) 27506 and choosing the multilib directory or running any subcommands. It 27507 applies them in the order given, so each spec can depend on the 27508 options added by earlier ones. It is also possible to remove 27509 options using '%<OPTION' in the usual way. 27510 27511 This macro can be useful when a port has several interdependent 27512 target options. It provides a way of standardizing the command 27513 line so that the other specs are easier to write. 27514 27515 Do not define this macro if it does not need to do anything. 27516 27517 -- Macro: OPTION_DEFAULT_SPECS 27518 A list of specs used to support configure-time default options 27519 (i.e. '--with' options) in the driver. It should be a suitable 27520 initializer for an array of structures, each containing two 27521 strings, without the outermost pair of surrounding braces. 27522 27523 The first item in the pair is the name of the default. This must 27524 match the code in 'config.gcc' for the target. The second item is 27525 a spec to apply if a default with this name was specified. The 27526 string '%(VALUE)' in the spec will be replaced by the value of the 27527 default everywhere it occurs. 27528 27529 The driver will apply these specs to its own command line between 27530 loading default 'specs' files and processing 'DRIVER_SELF_SPECS', 27531 using the same mechanism as 'DRIVER_SELF_SPECS'. 27532 27533 Do not define this macro if it does not need to do anything. 27534 27535 -- Macro: CPP_SPEC 27536 A C string constant that tells the GCC driver program options to 27537 pass to CPP. It can also specify how to translate options you give 27538 to GCC into options for GCC to pass to the CPP. 27539 27540 Do not define this macro if it does not need to do anything. 27541 27542 -- Macro: CPLUSPLUS_CPP_SPEC 27543 This macro is just like 'CPP_SPEC', but is used for C++, rather 27544 than C. If you do not define this macro, then the value of 27545 'CPP_SPEC' (if any) will be used instead. 27546 27547 -- Macro: CC1_SPEC 27548 A C string constant that tells the GCC driver program options to 27549 pass to 'cc1', 'cc1plus', 'f771', and the other language front 27550 ends. It can also specify how to translate options you give to GCC 27551 into options for GCC to pass to front ends. 27552 27553 Do not define this macro if it does not need to do anything. 27554 27555 -- Macro: CC1PLUS_SPEC 27556 A C string constant that tells the GCC driver program options to 27557 pass to 'cc1plus'. It can also specify how to translate options 27558 you give to GCC into options for GCC to pass to the 'cc1plus'. 27559 27560 Do not define this macro if it does not need to do anything. Note 27561 that everything defined in CC1_SPEC is already passed to 'cc1plus' 27562 so there is no need to duplicate the contents of CC1_SPEC in 27563 CC1PLUS_SPEC. 27564 27565 -- Macro: ASM_SPEC 27566 A C string constant that tells the GCC driver program options to 27567 pass to the assembler. It can also specify how to translate 27568 options you give to GCC into options for GCC to pass to the 27569 assembler. See the file 'sun3.h' for an example of this. 27570 27571 Do not define this macro if it does not need to do anything. 27572 27573 -- Macro: ASM_FINAL_SPEC 27574 A C string constant that tells the GCC driver program how to run 27575 any programs which cleanup after the normal assembler. Normally, 27576 this is not needed. See the file 'mips.h' for an example of this. 27577 27578 Do not define this macro if it does not need to do anything. 27579 27580 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 27581 Define this macro, with no value, if the driver should give the 27582 assembler an argument consisting of a single dash, '-', to instruct 27583 it to read from its standard input (which will be a pipe connected 27584 to the output of the compiler proper). This argument is given 27585 after any '-o' option specifying the name of the output file. 27586 27587 If you do not define this macro, the assembler is assumed to read 27588 its standard input if given no non-option arguments. If your 27589 assembler cannot read standard input at all, use a '%{pipe:%e}' 27590 construct; see 'mips.h' for instance. 27591 27592 -- Macro: LINK_SPEC 27593 A C string constant that tells the GCC driver program options to 27594 pass to the linker. It can also specify how to translate options 27595 you give to GCC into options for GCC to pass to the linker. 27596 27597 Do not define this macro if it does not need to do anything. 27598 27599 -- Macro: LIB_SPEC 27600 Another C string constant used much like 'LINK_SPEC'. The 27601 difference between the two is that 'LIB_SPEC' is used at the end of 27602 the command given to the linker. 27603 27604 If this macro is not defined, a default is provided that loads the 27605 standard C library from the usual place. See 'gcc.c'. 27606 27607 -- Macro: LIBGCC_SPEC 27608 Another C string constant that tells the GCC driver program how and 27609 when to place a reference to 'libgcc.a' into the linker command 27610 line. This constant is placed both before and after the value of 27611 'LIB_SPEC'. 27612 27613 If this macro is not defined, the GCC driver provides a default 27614 that passes the string '-lgcc' to the linker. 27615 27616 -- Macro: REAL_LIBGCC_SPEC 27617 By default, if 'ENABLE_SHARED_LIBGCC' is defined, the 'LIBGCC_SPEC' 27618 is not directly used by the driver program but is instead modified 27619 to refer to different versions of 'libgcc.a' depending on the 27620 values of the command line flags '-static', '-shared', 27621 '-static-libgcc', and '-shared-libgcc'. On targets where these 27622 modifications are inappropriate, define 'REAL_LIBGCC_SPEC' instead. 27623 'REAL_LIBGCC_SPEC' tells the driver how to place a reference to 27624 'libgcc' on the link command line, but, unlike 'LIBGCC_SPEC', it is 27625 used unmodified. 27626 27627 -- Macro: USE_LD_AS_NEEDED 27628 A macro that controls the modifications to 'LIBGCC_SPEC' mentioned 27629 in 'REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 27630 uses '--as-needed' or equivalent options and the shared 'libgcc' in 27631 place of the static exception handler library, when linking without 27632 any of '-static', '-static-libgcc', or '-shared-libgcc'. 27633 27634 -- Macro: LINK_EH_SPEC 27635 If defined, this C string constant is added to 'LINK_SPEC'. When 27636 'USE_LD_AS_NEEDED' is zero or undefined, it also affects the 27637 modifications to 'LIBGCC_SPEC' mentioned in 'REAL_LIBGCC_SPEC'. 27638 27639 -- Macro: STARTFILE_SPEC 27640 Another C string constant used much like 'LINK_SPEC'. The 27641 difference between the two is that 'STARTFILE_SPEC' is used at the 27642 very beginning of the command given to the linker. 27643 27644 If this macro is not defined, a default is provided that loads the 27645 standard C startup file from the usual place. See 'gcc.c'. 27646 27647 -- Macro: ENDFILE_SPEC 27648 Another C string constant used much like 'LINK_SPEC'. The 27649 difference between the two is that 'ENDFILE_SPEC' is used at the 27650 very end of the command given to the linker. 27651 27652 Do not define this macro if it does not need to do anything. 27653 27654 -- Macro: THREAD_MODEL_SPEC 27655 GCC '-v' will print the thread model GCC was configured to use. 27656 However, this doesn't work on platforms that are multilibbed on 27657 thread models, such as AIX 4.3. On such platforms, define 27658 'THREAD_MODEL_SPEC' such that it evaluates to a string without 27659 blanks that names one of the recognized thread models. '%*', the 27660 default value of this macro, will expand to the value of 27661 'thread_file' set in 'config.gcc'. 27662 27663 -- Macro: SYSROOT_SUFFIX_SPEC 27664 Define this macro to add a suffix to the target sysroot when GCC is 27665 configured with a sysroot. This will cause GCC to search for 27666 usr/lib, et al, within sysroot+suffix. 27667 27668 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 27669 Define this macro to add a headers_suffix to the target sysroot 27670 when GCC is configured with a sysroot. This will cause GCC to pass 27671 the updated sysroot+headers_suffix to CPP, causing it to search for 27672 usr/include, et al, within sysroot+headers_suffix. 27673 27674 -- Macro: EXTRA_SPECS 27675 Define this macro to provide additional specifications to put in 27676 the 'specs' file that can be used in various specifications like 27677 'CC1_SPEC'. 27678 27679 The definition should be an initializer for an array of structures, 27680 containing a string constant, that defines the specification name, 27681 and a string constant that provides the specification. 27682 27683 Do not define this macro if it does not need to do anything. 27684 27685 'EXTRA_SPECS' is useful when an architecture contains several 27686 related targets, which have various '..._SPECS' which are similar 27687 to each other, and the maintainer would like one central place to 27688 keep these definitions. 27689 27690 For example, the PowerPC System V.4 targets use 'EXTRA_SPECS' to 27691 define either '_CALL_SYSV' when the System V calling sequence is 27692 used or '_CALL_AIX' when the older AIX-based calling sequence is 27693 used. 27694 27695 The 'config/rs6000/rs6000.h' target file defines: 27696 27697 #define EXTRA_SPECS \ 27698 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 27699 27700 #define CPP_SYS_DEFAULT "" 27701 27702 The 'config/rs6000/sysv.h' target file defines: 27703 #undef CPP_SPEC 27704 #define CPP_SPEC \ 27705 "%{posix: -D_POSIX_SOURCE } \ 27706 %{mcall-sysv: -D_CALL_SYSV } \ 27707 %{!mcall-sysv: %(cpp_sysv_default) } \ 27708 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 27709 27710 #undef CPP_SYSV_DEFAULT 27711 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 27712 27713 while the 'config/rs6000/eabiaix.h' target file defines 27714 'CPP_SYSV_DEFAULT' as: 27715 27716 #undef CPP_SYSV_DEFAULT 27717 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 27718 27719 -- Macro: LINK_LIBGCC_SPECIAL_1 27720 Define this macro if the driver program should find the library 27721 'libgcc.a'. If you do not define this macro, the driver program 27722 will pass the argument '-lgcc' to tell the linker to do the search. 27723 27724 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 27725 The sequence in which libgcc and libc are specified to the linker. 27726 By default this is '%G %L %G'. 27727 27728 -- Macro: LINK_COMMAND_SPEC 27729 A C string constant giving the complete command line need to 27730 execute the linker. When you do this, you will need to update your 27731 port each time a change is made to the link command line within 27732 'gcc.c'. Therefore, define this macro only if you need to 27733 completely redefine the command line for invoking the linker and 27734 there is no other way to accomplish the effect you need. 27735 Overriding this macro may be avoidable by overriding 27736 'LINK_GCC_C_SEQUENCE_SPEC' instead. 27737 27738 -- Common Target Hook: bool TARGET_ALWAYS_STRIP_DOTDOT 27739 True if '..' components should always be removed from directory 27740 names computed relative to GCC's internal directories, false 27741 (default) if such components should be preserved and directory 27742 names containing them passed to other tools such as the linker. 27743 27744 -- Macro: MULTILIB_DEFAULTS 27745 Define this macro as a C expression for the initializer of an array 27746 of string to tell the driver program which options are defaults for 27747 this target and thus do not need to be handled specially when using 27748 'MULTILIB_OPTIONS'. 27749 27750 Do not define this macro if 'MULTILIB_OPTIONS' is not defined in 27751 the target makefile fragment or if none of the options listed in 27752 'MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 27753 27754 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 27755 Define this macro to tell 'gcc' that it should only translate a 27756 '-B' prefix into a '-L' linker option if the prefix indicates an 27757 absolute file name. 27758 27759 -- Macro: MD_EXEC_PREFIX 27760 If defined, this macro is an additional prefix to try after 27761 'STANDARD_EXEC_PREFIX'. 'MD_EXEC_PREFIX' is not searched when the 27762 compiler is built as a cross compiler. If you define 27763 'MD_EXEC_PREFIX', then be sure to add it to the list of directories 27764 used to find the assembler in 'configure.in'. 27765 27766 -- Macro: STANDARD_STARTFILE_PREFIX 27767 Define this macro as a C string constant if you wish to override 27768 the standard choice of 'libdir' as the default prefix to try when 27769 searching for startup files such as 'crt0.o'. 27770 'STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 27771 built as a cross compiler. 27772 27773 -- Macro: STANDARD_STARTFILE_PREFIX_1 27774 Define this macro as a C string constant if you wish to override 27775 the standard choice of '/lib' as a prefix to try after the default 27776 prefix when searching for startup files such as 'crt0.o'. 27777 'STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 27778 built as a cross compiler. 27779 27780 -- Macro: STANDARD_STARTFILE_PREFIX_2 27781 Define this macro as a C string constant if you wish to override 27782 the standard choice of '/lib' as yet another prefix to try after 27783 the default prefix when searching for startup files such as 27784 'crt0.o'. 'STANDARD_STARTFILE_PREFIX_2' is not searched when the 27785 compiler is built as a cross compiler. 27786 27787 -- Macro: MD_STARTFILE_PREFIX 27788 If defined, this macro supplies an additional prefix to try after 27789 the standard prefixes. 'MD_EXEC_PREFIX' is not searched when the 27790 compiler is built as a cross compiler. 27791 27792 -- Macro: MD_STARTFILE_PREFIX_1 27793 If defined, this macro supplies yet another prefix to try after the 27794 standard prefixes. It is not searched when the compiler is built 27795 as a cross compiler. 27796 27797 -- Macro: INIT_ENVIRONMENT 27798 Define this macro as a C string constant if you wish to set 27799 environment variables for programs called by the driver, such as 27800 the assembler and loader. The driver passes the value of this 27801 macro to 'putenv' to initialize the necessary environment 27802 variables. 27803 27804 -- Macro: LOCAL_INCLUDE_DIR 27805 Define this macro as a C string constant if you wish to override 27806 the standard choice of '/usr/local/include' as the default prefix 27807 to try when searching for local header files. 'LOCAL_INCLUDE_DIR' 27808 comes before 'NATIVE_SYSTEM_HEADER_DIR' (set in 'config.gcc', 27809 normally '/usr/include') in the search order. 27810 27811 Cross compilers do not search either '/usr/local/include' or its 27812 replacement. 27813 27814 -- Macro: NATIVE_SYSTEM_HEADER_COMPONENT 27815 The "component" corresponding to 'NATIVE_SYSTEM_HEADER_DIR'. See 27816 'INCLUDE_DEFAULTS', below, for the description of components. If 27817 you do not define this macro, no component is used. 27818 27819 -- Macro: INCLUDE_DEFAULTS 27820 Define this macro if you wish to override the entire default search 27821 path for include files. For a native compiler, the default search 27822 path usually consists of 'GCC_INCLUDE_DIR', 'LOCAL_INCLUDE_DIR', 27823 'GPLUSPLUS_INCLUDE_DIR', and 'NATIVE_SYSTEM_HEADER_DIR'. In 27824 addition, 'GPLUSPLUS_INCLUDE_DIR' and 'GCC_INCLUDE_DIR' are defined 27825 automatically by 'Makefile', and specify private search areas for 27826 GCC. The directory 'GPLUSPLUS_INCLUDE_DIR' is used only for C++ 27827 programs. 27828 27829 The definition should be an initializer for an array of structures. 27830 Each array element should have four elements: the directory name (a 27831 string constant), the component name (also a string constant), a 27832 flag for C++-only directories, and a flag showing that the includes 27833 in the directory don't need to be wrapped in 'extern 'C'' when 27834 compiling C++. Mark the end of the array with a null element. 27835 27836 The component name denotes what GNU package the include file is 27837 part of, if any, in all uppercase letters. For example, it might 27838 be 'GCC' or 'BINUTILS'. If the package is part of a 27839 vendor-supplied operating system, code the component name as '0'. 27840 27841 For example, here is the definition used for VAX/VMS: 27842 27843 #define INCLUDE_DEFAULTS \ 27844 { \ 27845 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 27846 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 27847 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 27848 { ".", 0, 0, 0}, \ 27849 { 0, 0, 0, 0} \ 27850 } 27851 27852 Here is the order of prefixes tried for exec files: 27853 27854 1. Any prefixes specified by the user with '-B'. 27855 27856 2. The environment variable 'GCC_EXEC_PREFIX' or, if 'GCC_EXEC_PREFIX' 27857 is not set and the compiler has not been installed in the 27858 configure-time PREFIX, the location in which the compiler has 27859 actually been installed. 27860 27861 3. The directories specified by the environment variable 27862 'COMPILER_PATH'. 27863 27864 4. The macro 'STANDARD_EXEC_PREFIX', if the compiler has been 27865 installed in the configured-time PREFIX. 27866 27867 5. The location '/usr/libexec/gcc/', but only if this is a native 27868 compiler. 27869 27870 6. The location '/usr/lib/gcc/', but only if this is a native 27871 compiler. 27872 27873 7. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 27874 native compiler. 27875 27876 Here is the order of prefixes tried for startfiles: 27877 27878 1. Any prefixes specified by the user with '-B'. 27879 27880 2. The environment variable 'GCC_EXEC_PREFIX' or its automatically 27881 determined value based on the installed toolchain location. 27882 27883 3. The directories specified by the environment variable 27884 'LIBRARY_PATH' (or port-specific name; native only, cross compilers 27885 do not use this). 27886 27887 4. The macro 'STANDARD_EXEC_PREFIX', but only if the toolchain is 27888 installed in the configured PREFIX or this is a native compiler. 27889 27890 5. The location '/usr/lib/gcc/', but only if this is a native 27891 compiler. 27892 27893 6. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 27894 native compiler. 27895 27896 7. The macro 'MD_STARTFILE_PREFIX', if defined, but only if this is a 27897 native compiler, or we have a target system root. 27898 27899 8. The macro 'MD_STARTFILE_PREFIX_1', if defined, but only if this is 27900 a native compiler, or we have a target system root. 27901 27902 9. The macro 'STANDARD_STARTFILE_PREFIX', with any sysroot 27903 modifications. If this path is relative it will be prefixed by 27904 'GCC_EXEC_PREFIX' and the machine suffix or 'STANDARD_EXEC_PREFIX' 27905 and the machine suffix. 27906 27907 10. The macro 'STANDARD_STARTFILE_PREFIX_1', but only if this is a 27908 native compiler, or we have a target system root. The default for 27909 this macro is '/lib/'. 27910 27911 11. The macro 'STANDARD_STARTFILE_PREFIX_2', but only if this is a 27912 native compiler, or we have a target system root. The default for 27913 this macro is '/usr/lib/'. 27914 27915 27916File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 27917 2791817.3 Run-time Target Specification 27919================================== 27920 27921Here are run-time target specifications. 27922 27923 -- Macro: TARGET_CPU_CPP_BUILTINS () 27924 This function-like macro expands to a block of code that defines 27925 built-in preprocessor macros and assertions for the target CPU, 27926 using the functions 'builtin_define', 'builtin_define_std' and 27927 'builtin_assert'. When the front end calls this macro it provides 27928 a trailing semicolon, and since it has finished command line option 27929 processing your code can use those results freely. 27930 27931 'builtin_assert' takes a string in the form you pass to the 27932 command-line option '-A', such as 'cpu=mips', and creates the 27933 assertion. 'builtin_define' takes a string in the form accepted by 27934 option '-D' and unconditionally defines the macro. 27935 27936 'builtin_define_std' takes a string representing the name of an 27937 object-like macro. If it doesn't lie in the user's namespace, 27938 'builtin_define_std' defines it unconditionally. Otherwise, it 27939 defines a version with two leading underscores, and another version 27940 with two leading and trailing underscores, and defines the original 27941 only if an ISO standard was not requested on the command line. For 27942 example, passing 'unix' defines '__unix', '__unix__' and possibly 27943 'unix'; passing '_mips' defines '__mips', '__mips__' and possibly 27944 '_mips', and passing '_ABI64' defines only '_ABI64'. 27945 27946 You can also test for the C dialect being compiled. The variable 27947 'c_language' is set to one of 'clk_c', 'clk_cplusplus' or 27948 'clk_objective_c'. Note that if we are preprocessing assembler, 27949 this variable will be 'clk_c' but the function-like macro 27950 'preprocessing_asm_p()' will return true, so you might want to 27951 check for that first. If you need to check for strict ANSI, the 27952 variable 'flag_iso' can be used. The function-like macro 27953 'preprocessing_trad_p()' can be used to check for traditional 27954 preprocessing. 27955 27956 -- Macro: TARGET_OS_CPP_BUILTINS () 27957 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 27958 and is used for the target operating system instead. 27959 27960 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 27961 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 27962 and is used for the target object format. 'elfos.h' uses this 27963 macro to define '__ELF__', so you probably do not need to define it 27964 yourself. 27965 27966 -- Variable: extern int target_flags 27967 This variable is declared in 'options.h', which is included before 27968 any target-specific headers. 27969 27970 -- Common Target Hook: int TARGET_DEFAULT_TARGET_FLAGS 27971 This variable specifies the initial value of 'target_flags'. Its 27972 default setting is 0. 27973 27974 -- Common Target Hook: bool TARGET_HANDLE_OPTION (struct gcc_options 27975 *OPTS, struct gcc_options *OPTS_SET, const struct 27976 cl_decoded_option *DECODED, location_t LOC) 27977 This hook is called whenever the user specifies one of the 27978 target-specific options described by the '.opt' definition files 27979 (*note Options::). It has the opportunity to do some 27980 option-specific processing and should return true if the option is 27981 valid. The default definition does nothing but return true. 27982 27983 DECODED specifies the option and its arguments. OPTS and OPTS_SET 27984 are the 'gcc_options' structures to be used for storing option 27985 state, and LOC is the location at which the option was passed 27986 ('UNKNOWN_LOCATION' except for options passed via attributes). 27987 27988 -- C Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char 27989 *ARG, int VALUE) 27990 This target hook is called whenever the user specifies one of the 27991 target-specific C language family options described by the '.opt' 27992 definition files(*note Options::). It has the opportunity to do 27993 some option-specific processing and should return true if the 27994 option is valid. The arguments are like for 27995 'TARGET_HANDLE_OPTION'. The default definition does nothing but 27996 return false. 27997 27998 In general, you should use 'TARGET_HANDLE_OPTION' to handle 27999 options. However, if processing an option requires routines that 28000 are only available in the C (and related language) front ends, then 28001 you should use 'TARGET_HANDLE_C_OPTION' instead. 28002 28003 -- C Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree 28004 STRING) 28005 Targets may provide a string object type that can be used within 28006 and between C, C++ and their respective Objective-C dialects. A 28007 string object might, for example, embed encoding and length 28008 information. These objects are considered opaque to the compiler 28009 and handled as references. An ideal implementation makes the 28010 composition of the string object match that of the Objective-C 28011 'NSString' ('NXString' for GNUStep), allowing efficient 28012 interworking between C-only and Objective-C code. If a target 28013 implements string objects then this hook should return a reference 28014 to such an object constructed from the normal 'C' string 28015 representation provided in STRING. At present, the hook is used by 28016 Objective-C only, to obtain a common-format string object when the 28017 target provides one. 28018 28019 -- C Target Hook: void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE 28020 (const char *CLASSNAME) 28021 Declare that Objective C class CLASSNAME is referenced by the 28022 current TU. 28023 28024 -- C Target Hook: void TARGET_OBJC_DECLARE_CLASS_DEFINITION (const char 28025 *CLASSNAME) 28026 Declare that Objective C class CLASSNAME is defined by the current 28027 TU. 28028 28029 -- C Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree 28030 STRINGREF) 28031 If a target implements string objects then this hook should return 28032 'true' if STRINGREF is a valid reference to such an object. 28033 28034 -- C Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree 28035 FORMAT_ARG, tree ARGS_LIST) 28036 If a target implements string objects then this hook should should 28037 provide a facility to check the function arguments in ARGS_LIST 28038 against the format specifiers in FORMAT_ARG where the type of 28039 FORMAT_ARG is one recognized as a valid string reference type. 28040 28041 -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void) 28042 This target function is similar to the hook 28043 'TARGET_OPTION_OVERRIDE' but is called when the optimize level is 28044 changed via an attribute or pragma or when it is reset at the end 28045 of the code affected by the attribute or pragma. It is not called 28046 at the beginning of compilation when 'TARGET_OPTION_OVERRIDE' is 28047 called so if you want to perform these actions then, you should 28048 have 'TARGET_OPTION_OVERRIDE' call 28049 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'. 28050 28051 -- Macro: C_COMMON_OVERRIDE_OPTIONS 28052 This is similar to the 'TARGET_OPTION_OVERRIDE' hook but is only 28053 used in the C language frontends (C, Objective-C, C++, 28054 Objective-C++) and so can be used to alter option flag variables 28055 which only exist in those frontends. 28056 28057 -- Common Target Hook: const struct default_options * 28058 TARGET_OPTION_OPTIMIZATION_TABLE 28059 Some machines may desire to change what optimizations are performed 28060 for various optimization levels. This variable, if defined, 28061 describes options to enable at particular sets of optimization 28062 levels. These options are processed once just after the 28063 optimization level is determined and before the remainder of the 28064 command options have been parsed, so may be overridden by other 28065 options passed explicitly. 28066 28067 This processing is run once at program startup and when the 28068 optimization options are changed via '#pragma GCC optimize' or by 28069 using the 'optimize' attribute. 28070 28071 -- Common Target Hook: void TARGET_OPTION_INIT_STRUCT (struct 28072 gcc_options *OPTS) 28073 Set target-dependent initial values of fields in OPTS. 28074 28075 -- Common Target Hook: void TARGET_OPTION_DEFAULT_PARAMS (void) 28076 Set target-dependent default values for '--param' settings, using 28077 calls to 'set_default_param_value'. 28078 28079 -- Macro: SWITCHABLE_TARGET 28080 Some targets need to switch between substantially different 28081 subtargets during compilation. For example, the MIPS target has 28082 one subtarget for the traditional MIPS architecture and another for 28083 MIPS16. Source code can switch between these two subarchitectures 28084 using the 'mips16' and 'nomips16' attributes. 28085 28086 Such subtargets can differ in things like the set of available 28087 registers, the set of available instructions, the costs of various 28088 operations, and so on. GCC caches a lot of this type of 28089 information in global variables, and recomputing them for each 28090 subtarget takes a significant amount of time. The compiler 28091 therefore provides a facility for maintaining several versions of 28092 the global variables and quickly switching between them; see 28093 'target-globals.h' for details. 28094 28095 Define this macro to 1 if your target needs this facility. The 28096 default is 0. 28097 28098 -- Target Hook: bool TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P 28099 (void) 28100 Returns true if the target supports IEEE 754 floating-point 28101 exceptions and rounding modes, false otherwise. This is intended 28102 to relate to the 'float' and 'double' types, but not necessarily 28103 'long double'. By default, returns true if the 'adddf3' 28104 instruction pattern is available and false otherwise, on the 28105 assumption that hardware floating point supports exceptions and 28106 rounding modes but software floating point does not. 28107 28108 28109File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 28110 2811117.4 Defining data structures for per-function information. 28112=========================================================== 28113 28114If the target needs to store information on a per-function basis, GCC 28115provides a macro and a couple of variables to allow this. Note, just 28116using statics to store the information is a bad idea, since GCC supports 28117nested functions, so you can be halfway through encoding one function 28118when another one comes along. 28119 28120 GCC defines a data structure called 'struct function' which contains 28121all of the data specific to an individual function. This structure 28122contains a field called 'machine' whose type is 'struct machine_function 28123*', which can be used by targets to point to their own specific data. 28124 28125 If a target needs per-function specific data it should define the type 28126'struct machine_function' and also the macro 'INIT_EXPANDERS'. This 28127macro should be used to initialize the function pointer 28128'init_machine_status'. This pointer is explained below. 28129 28130 One typical use of per-function, target specific data is to create an 28131RTX to hold the register containing the function's return address. This 28132RTX can then be used to implement the '__builtin_return_address' 28133function, for level 0. 28134 28135 Note--earlier implementations of GCC used a single data area to hold 28136all of the per-function information. Thus when processing of a nested 28137function began the old per-function data had to be pushed onto a stack, 28138and when the processing was finished, it had to be popped off the stack. 28139GCC used to provide function pointers called 'save_machine_status' and 28140'restore_machine_status' to handle the saving and restoring of the 28141target specific information. Since the single data area approach is no 28142longer used, these pointers are no longer supported. 28143 28144 -- Macro: INIT_EXPANDERS 28145 Macro called to initialize any target specific information. This 28146 macro is called once per function, before generation of any RTL has 28147 begun. The intention of this macro is to allow the initialization 28148 of the function pointer 'init_machine_status'. 28149 28150 -- Variable: void (*)(struct function *) init_machine_status 28151 If this function pointer is non-'NULL' it will be called once per 28152 function, before function compilation starts, in order to allow the 28153 target to perform any target specific initialization of the 'struct 28154 function' structure. It is intended that this would be used to 28155 initialize the 'machine' of that structure. 28156 28157 'struct machine_function' structures are expected to be freed by 28158 GC. Generally, any memory that they reference must be allocated by 28159 using GC allocation, including the structure itself. 28160 28161 28162File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 28163 2816417.5 Storage Layout 28165=================== 28166 28167Note that the definitions of the macros in this table which are sizes or 28168alignments measured in bits do not need to be constant. They can be C 28169expressions that refer to static variables, such as the 'target_flags'. 28170*Note Run-time Target::. 28171 28172 -- Macro: BITS_BIG_ENDIAN 28173 Define this macro to have the value 1 if the most significant bit 28174 in a byte has the lowest number; otherwise define it to have the 28175 value zero. This means that bit-field instructions count from the 28176 most significant bit. If the machine has no bit-field 28177 instructions, then this must still be defined, but it doesn't 28178 matter which value it is defined to. This macro need not be a 28179 constant. 28180 28181 This macro does not affect the way structure fields are packed into 28182 bytes or words; that is controlled by 'BYTES_BIG_ENDIAN'. 28183 28184 -- Macro: BYTES_BIG_ENDIAN 28185 Define this macro to have the value 1 if the most significant byte 28186 in a word has the lowest number. This macro need not be a 28187 constant. 28188 28189 -- Macro: WORDS_BIG_ENDIAN 28190 Define this macro to have the value 1 if, in a multiword object, 28191 the most significant word has the lowest number. This applies to 28192 both memory locations and registers; see 'REG_WORDS_BIG_ENDIAN' if 28193 the order of words in memory is not the same as the order in 28194 registers. This macro need not be a constant. 28195 28196 -- Macro: REG_WORDS_BIG_ENDIAN 28197 On some machines, the order of words in a multiword object differs 28198 between registers in memory. In such a situation, define this 28199 macro to describe the order of words in a register. The macro 28200 'WORDS_BIG_ENDIAN' controls the order of words in memory. 28201 28202 -- Macro: FLOAT_WORDS_BIG_ENDIAN 28203 Define this macro to have the value 1 if 'DFmode', 'XFmode' or 28204 'TFmode' floating point numbers are stored in memory with the word 28205 containing the sign bit at the lowest address; otherwise define it 28206 to have the value 0. This macro need not be a constant. 28207 28208 You need not define this macro if the ordering is the same as for 28209 multi-word integers. 28210 28211 -- Macro: BITS_PER_WORD 28212 Number of bits in a word. If you do not define this macro, the 28213 default is 'BITS_PER_UNIT * UNITS_PER_WORD'. 28214 28215 -- Macro: MAX_BITS_PER_WORD 28216 Maximum number of bits in a word. If this is undefined, the 28217 default is 'BITS_PER_WORD'. Otherwise, it is the constant value 28218 that is the largest value that 'BITS_PER_WORD' can have at 28219 run-time. 28220 28221 -- Macro: UNITS_PER_WORD 28222 Number of storage units in a word; normally the size of a 28223 general-purpose register, a power of two from 1 or 8. 28224 28225 -- Macro: MIN_UNITS_PER_WORD 28226 Minimum number of units in a word. If this is undefined, the 28227 default is 'UNITS_PER_WORD'. Otherwise, it is the constant value 28228 that is the smallest value that 'UNITS_PER_WORD' can have at 28229 run-time. 28230 28231 -- Macro: POINTER_SIZE 28232 Width of a pointer, in bits. You must specify a value no wider 28233 than the width of 'Pmode'. If it is not equal to the width of 28234 'Pmode', you must define 'POINTERS_EXTEND_UNSIGNED'. If you do not 28235 specify a value the default is 'BITS_PER_WORD'. 28236 28237 -- Macro: POINTERS_EXTEND_UNSIGNED 28238 A C expression that determines how pointers should be extended from 28239 'ptr_mode' to either 'Pmode' or 'word_mode'. It is greater than 28240 zero if pointers should be zero-extended, zero if they should be 28241 sign-extended, and negative if some other sort of conversion is 28242 needed. In the last case, the extension is done by the target's 28243 'ptr_extend' instruction. 28244 28245 You need not define this macro if the 'ptr_mode', 'Pmode' and 28246 'word_mode' are all the same width. 28247 28248 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 28249 A macro to update M and UNSIGNEDP when an object whose type is TYPE 28250 and which has the specified mode and signedness is to be stored in 28251 a register. This macro is only called when TYPE is a scalar type. 28252 28253 On most RISC machines, which only have operations that operate on a 28254 full register, define this macro to set M to 'word_mode' if M is an 28255 integer mode narrower than 'BITS_PER_WORD'. In most cases, only 28256 integer modes should be widened because wider-precision 28257 floating-point operations are usually more expensive than their 28258 narrower counterparts. 28259 28260 For most machines, the macro definition does not change UNSIGNEDP. 28261 However, some machines, have instructions that preferentially 28262 handle either signed or unsigned quantities of certain modes. For 28263 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 28264 instructions sign-extend the result to 64 bits. On such machines, 28265 set UNSIGNEDP according to which kind of extension is more 28266 efficient. 28267 28268 Do not define this macro if it would never modify M. 28269 28270 -- Target Hook: machine_mode TARGET_PROMOTE_FUNCTION_MODE (const_tree 28271 TYPE, machine_mode MODE, int *PUNSIGNEDP, const_tree FUNTYPE, 28272 int FOR_RETURN) 28273 Like 'PROMOTE_MODE', but it is applied to outgoing function 28274 arguments or function return values. The target hook should return 28275 the new mode and possibly change '*PUNSIGNEDP' if the promotion 28276 should change signedness. This function is called only for scalar 28277 _or pointer_ types. 28278 28279 FOR_RETURN allows to distinguish the promotion of arguments and 28280 return values. If it is '1', a return value is being promoted and 28281 'TARGET_FUNCTION_VALUE' must perform the same promotions done here. 28282 If it is '2', the returned mode should be that of the register in 28283 which an incoming parameter is copied, or the outgoing result is 28284 computed; then the hook should return the same mode as 28285 'promote_mode', though the signedness may be different. 28286 28287 TYPE can be NULL when promoting function arguments of libcalls. 28288 28289 The default is to not promote arguments and return values. You can 28290 also define the hook to 28291 'default_promote_function_mode_always_promote' if you would like to 28292 apply the same rules given by 'PROMOTE_MODE'. 28293 28294 -- Macro: PARM_BOUNDARY 28295 Normal alignment required for function parameters on the stack, in 28296 bits. All stack parameters receive at least this much alignment 28297 regardless of data type. On most machines, this is the same as the 28298 size of an integer. 28299 28300 -- Macro: STACK_BOUNDARY 28301 Define this macro to the minimum alignment enforced by hardware for 28302 the stack pointer on this machine. The definition is a C 28303 expression for the desired alignment (measured in bits). This 28304 value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not 28305 defined. On most machines, this should be the same as 28306 'PARM_BOUNDARY'. 28307 28308 -- Macro: PREFERRED_STACK_BOUNDARY 28309 Define this macro if you wish to preserve a certain alignment for 28310 the stack pointer, greater than what the hardware enforces. The 28311 definition is a C expression for the desired alignment (measured in 28312 bits). This macro must evaluate to a value equal to or larger than 28313 'STACK_BOUNDARY'. 28314 28315 -- Macro: INCOMING_STACK_BOUNDARY 28316 Define this macro if the incoming stack boundary may be different 28317 from 'PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a 28318 value equal to or larger than 'STACK_BOUNDARY'. 28319 28320 -- Macro: FUNCTION_BOUNDARY 28321 Alignment required for a function entry point, in bits. 28322 28323 -- Macro: BIGGEST_ALIGNMENT 28324 Biggest alignment that any data type can require on this machine, 28325 in bits. Note that this is not the biggest alignment that is 28326 supported, just the biggest alignment that, when violated, may 28327 cause a fault. 28328 28329 -- Target Hook: HOST_WIDE_INT TARGET_ABSOLUTE_BIGGEST_ALIGNMENT 28330 If defined, this target hook specifies the absolute biggest 28331 alignment that a type or variable can have on this machine, 28332 otherwise, 'BIGGEST_ALIGNMENT' is used. 28333 28334 -- Macro: MALLOC_ABI_ALIGNMENT 28335 Alignment, in bits, a C conformant malloc implementation has to 28336 provide. If not defined, the default value is 'BITS_PER_WORD'. 28337 28338 -- Macro: ATTRIBUTE_ALIGNED_VALUE 28339 Alignment used by the '__attribute__ ((aligned))' construct. If 28340 not defined, the default value is 'BIGGEST_ALIGNMENT'. 28341 28342 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 28343 If defined, the smallest alignment, in bits, that can be given to 28344 an object that can be referenced in one operation, without 28345 disturbing any nearby object. Normally, this is 'BITS_PER_UNIT', 28346 but may be larger on machines that don't have byte or half-word 28347 store operations. 28348 28349 -- Macro: BIGGEST_FIELD_ALIGNMENT 28350 Biggest alignment that any structure or union field can require on 28351 this machine, in bits. If defined, this overrides 28352 'BIGGEST_ALIGNMENT' for structure and union fields only, unless the 28353 field alignment has been set by the '__attribute__ ((aligned (N)))' 28354 construct. 28355 28356 -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED) 28357 An expression for the alignment of a structure field FIELD if the 28358 alignment computed in the usual way (including applying of 28359 'BIGGEST_ALIGNMENT' and 'BIGGEST_FIELD_ALIGNMENT' to the alignment) 28360 is COMPUTED. It overrides alignment only if the field alignment 28361 has not been set by the '__attribute__ ((aligned (N)))' construct. 28362 28363 -- Macro: MAX_STACK_ALIGNMENT 28364 Biggest stack alignment guaranteed by the backend. Use this macro 28365 to specify the maximum alignment of a variable on stack. 28366 28367 If not defined, the default value is 'STACK_BOUNDARY'. 28368 28369 -- Macro: MAX_OFILE_ALIGNMENT 28370 Biggest alignment supported by the object file format of this 28371 machine. Use this macro to limit the alignment which can be 28372 specified using the '__attribute__ ((aligned (N)))' construct. If 28373 not defined, the default value is 'BIGGEST_ALIGNMENT'. 28374 28375 On systems that use ELF, the default (in 'config/elfos.h') is the 28376 largest supported 32-bit ELF section alignment representable on a 28377 32-bit host e.g. '(((uint64_t) 1 << 28) * 8)'. On 32-bit ELF the 28378 largest supported section alignment in bits is '(0x80000000 * 8)', 28379 but this is not representable on 32-bit hosts. 28380 28381 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 28382 If defined, a C expression to compute the alignment for a variable 28383 in the static store. TYPE is the data type, and BASIC-ALIGN is the 28384 alignment that the object would ordinarily have. The value of this 28385 macro is used instead of that alignment to align the object. 28386 28387 If this macro is not defined, then BASIC-ALIGN is used. 28388 28389 One use of this macro is to increase alignment of medium-size data 28390 to make it all fit in fewer cache lines. Another is to cause 28391 character arrays to be word-aligned so that 'strcpy' calls that 28392 copy constants to character arrays can be done inline. 28393 28394 -- Macro: DATA_ABI_ALIGNMENT (TYPE, BASIC-ALIGN) 28395 Similar to 'DATA_ALIGNMENT', but for the cases where the ABI 28396 mandates some alignment increase, instead of optimization only 28397 purposes. E.g. AMD x86-64 psABI says that variables with array 28398 type larger than 15 bytes must be aligned to 16 byte boundaries. 28399 28400 If this macro is not defined, then BASIC-ALIGN is used. 28401 28402 -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN) 28403 If defined, a C expression to compute the alignment given to a 28404 constant that is being placed in memory. CONSTANT is the constant 28405 and BASIC-ALIGN is the alignment that the object would ordinarily 28406 have. The value of this macro is used instead of that alignment to 28407 align the object. 28408 28409 If this macro is not defined, then BASIC-ALIGN is used. 28410 28411 The typical use of this macro is to increase alignment for string 28412 constants to be word aligned so that 'strcpy' calls that copy 28413 constants can be done inline. 28414 28415 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 28416 If defined, a C expression to compute the alignment for a variable 28417 in the local store. TYPE is the data type, and BASIC-ALIGN is the 28418 alignment that the object would ordinarily have. The value of this 28419 macro is used instead of that alignment to align the object. 28420 28421 If this macro is not defined, then BASIC-ALIGN is used. 28422 28423 One use of this macro is to increase alignment of medium-size data 28424 to make it all fit in fewer cache lines. 28425 28426 If the value of this macro has a type, it should be an unsigned 28427 type. 28428 28429 -- Target Hook: HOST_WIDE_INT TARGET_VECTOR_ALIGNMENT (const_tree TYPE) 28430 This hook can be used to define the alignment for a vector of type 28431 TYPE, in order to comply with a platform ABI. The default is to 28432 require natural alignment for vector types. The alignment returned 28433 by this hook must be a power-of-two multiple of the default 28434 alignment of the vector element type. 28435 28436 -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN) 28437 If defined, a C expression to compute the alignment for stack slot. 28438 TYPE is the data type, MODE is the widest mode available, and 28439 BASIC-ALIGN is the alignment that the slot would ordinarily have. 28440 The value of this macro is used instead of that alignment to align 28441 the slot. 28442 28443 If this macro is not defined, then BASIC-ALIGN is used when TYPE is 28444 'NULL'. Otherwise, 'LOCAL_ALIGNMENT' will be used. 28445 28446 This macro is to set alignment of stack slot to the maximum 28447 alignment of all possible modes which the slot may have. 28448 28449 If the value of this macro has a type, it should be an unsigned 28450 type. 28451 28452 -- Macro: LOCAL_DECL_ALIGNMENT (DECL) 28453 If defined, a C expression to compute the alignment for a local 28454 variable DECL. 28455 28456 If this macro is not defined, then 'LOCAL_ALIGNMENT (TREE_TYPE 28457 (DECL), DECL_ALIGN (DECL))' is used. 28458 28459 One use of this macro is to increase alignment of medium-size data 28460 to make it all fit in fewer cache lines. 28461 28462 If the value of this macro has a type, it should be an unsigned 28463 type. 28464 28465 -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN) 28466 If defined, a C expression to compute the minimum required 28467 alignment for dynamic stack realignment purposes for EXP (a type or 28468 decl), MODE, assuming normal alignment ALIGN. 28469 28470 If this macro is not defined, then ALIGN will be used. 28471 28472 -- Macro: EMPTY_FIELD_BOUNDARY 28473 Alignment in bits to be given to a structure bit-field that follows 28474 an empty field such as 'int : 0;'. 28475 28476 If 'PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 28477 28478 -- Macro: STRUCTURE_SIZE_BOUNDARY 28479 Number of bits which any structure or union's size must be a 28480 multiple of. Each structure or union's size is rounded up to a 28481 multiple of this. 28482 28483 If you do not define this macro, the default is the same as 28484 'BITS_PER_UNIT'. 28485 28486 -- Macro: STRICT_ALIGNMENT 28487 Define this macro to be the value 1 if instructions will fail to 28488 work if given data not on the nominal alignment. If instructions 28489 will merely go slower in that case, define this macro as 0. 28490 28491 -- Macro: PCC_BITFIELD_TYPE_MATTERS 28492 Define this if you wish to imitate the way many other C compilers 28493 handle alignment of bit-fields and the structures that contain 28494 them. 28495 28496 The behavior is that the type written for a named bit-field ('int', 28497 'short', or other integer type) imposes an alignment for the entire 28498 structure, as if the structure really did contain an ordinary field 28499 of that type. In addition, the bit-field is placed within the 28500 structure so that it would fit within such a field, not crossing a 28501 boundary for it. 28502 28503 Thus, on most machines, a named bit-field whose type is written as 28504 'int' would not cross a four-byte boundary, and would force 28505 four-byte alignment for the whole structure. (The alignment used 28506 may not be four bytes; it is controlled by the other alignment 28507 parameters.) 28508 28509 An unnamed bit-field will not affect the alignment of the 28510 containing structure. 28511 28512 If the macro is defined, its definition should be a C expression; a 28513 nonzero value for the expression enables this behavior. 28514 28515 Note that if this macro is not defined, or its value is zero, some 28516 bit-fields may cross more than one alignment boundary. The 28517 compiler can support such references if there are 'insv', 'extv', 28518 and 'extzv' insns that can directly reference memory. 28519 28520 The other known way of making bit-fields work is to define 28521 'STRUCTURE_SIZE_BOUNDARY' as large as 'BIGGEST_ALIGNMENT'. Then 28522 every structure can be accessed with fullwords. 28523 28524 Unless the machine has bit-field instructions or you define 28525 'STRUCTURE_SIZE_BOUNDARY' that way, you must define 28526 'PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 28527 28528 If your aim is to make GCC use the same conventions for laying out 28529 bit-fields as are used by another compiler, here is how to 28530 investigate what the other compiler does. Compile and run this 28531 program: 28532 28533 struct foo1 28534 { 28535 char x; 28536 char :0; 28537 char y; 28538 }; 28539 28540 struct foo2 28541 { 28542 char x; 28543 int :0; 28544 char y; 28545 }; 28546 28547 main () 28548 { 28549 printf ("Size of foo1 is %d\n", 28550 sizeof (struct foo1)); 28551 printf ("Size of foo2 is %d\n", 28552 sizeof (struct foo2)); 28553 exit (0); 28554 } 28555 28556 If this prints 2 and 5, then the compiler's behavior is what you 28557 would get from 'PCC_BITFIELD_TYPE_MATTERS'. 28558 28559 -- Macro: BITFIELD_NBYTES_LIMITED 28560 Like 'PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 28561 to aligning a bit-field within the structure. 28562 28563 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void) 28564 When 'PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 28565 whether unnamed bitfields affect the alignment of the containing 28566 structure. The hook should return true if the structure should 28567 inherit the alignment requirements of an unnamed bitfield's type. 28568 28569 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void) 28570 This target hook should return 'true' if accesses to volatile 28571 bitfields should use the narrowest mode possible. It should return 28572 'false' if these accesses should use the bitfield container type. 28573 28574 The default is 'false'. 28575 28576 -- Target Hook: bool TARGET_MEMBER_TYPE_FORCES_BLK (const_tree FIELD, 28577 machine_mode MODE) 28578 Return true if a structure, union or array containing FIELD should 28579 be accessed using 'BLKMODE'. 28580 28581 If FIELD is the only field in the structure, MODE is its mode, 28582 otherwise MODE is VOIDmode. MODE is provided in the case where 28583 structures of one field would require the structure's mode to 28584 retain the field's mode. 28585 28586 Normally, this is not needed. 28587 28588 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 28589 Define this macro as an expression for the alignment of a type 28590 (given by TYPE as a tree node) if the alignment computed in the 28591 usual way is COMPUTED and the alignment explicitly specified was 28592 SPECIFIED. 28593 28594 The default is to use SPECIFIED if it is larger; otherwise, use the 28595 smaller of COMPUTED and 'BIGGEST_ALIGNMENT' 28596 28597 -- Macro: MAX_FIXED_MODE_SIZE 28598 An integer expression for the size in bits of the largest integer 28599 machine mode that should actually be used. All integer machine 28600 modes of this size or smaller can be used for structures and unions 28601 with the appropriate sizes. If this macro is undefined, 28602 'GET_MODE_BITSIZE (DImode)' is assumed. 28603 28604 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 28605 If defined, an expression of type 'machine_mode' that specifies the 28606 mode of the save area operand of a 'save_stack_LEVEL' named pattern 28607 (*note Standard Names::). SAVE_LEVEL is one of 'SAVE_BLOCK', 28608 'SAVE_FUNCTION', or 'SAVE_NONLOCAL' and selects which of the three 28609 named patterns is having its mode specified. 28610 28611 You need not define this macro if it always returns 'Pmode'. You 28612 would most commonly define this macro if the 'save_stack_LEVEL' 28613 patterns need to support both a 32- and a 64-bit mode. 28614 28615 -- Macro: STACK_SIZE_MODE 28616 If defined, an expression of type 'machine_mode' that specifies the 28617 mode of the size increment operand of an 'allocate_stack' named 28618 pattern (*note Standard Names::). 28619 28620 You need not define this macro if it always returns 'word_mode'. 28621 You would most commonly define this macro if the 'allocate_stack' 28622 pattern needs to support both a 32- and a 64-bit mode. 28623 28624 -- Target Hook: machine_mode TARGET_LIBGCC_CMP_RETURN_MODE (void) 28625 This target hook should return the mode to be used for the return 28626 value of compare instructions expanded to libgcc calls. If not 28627 defined 'word_mode' is returned which is the right choice for a 28628 majority of targets. 28629 28630 -- Target Hook: machine_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void) 28631 This target hook should return the mode to be used for the shift 28632 count operand of shift instructions expanded to libgcc calls. If 28633 not defined 'word_mode' is returned which is the right choice for a 28634 majority of targets. 28635 28636 -- Target Hook: machine_mode TARGET_UNWIND_WORD_MODE (void) 28637 Return machine mode to be used for '_Unwind_Word' type. The 28638 default is to use 'word_mode'. 28639 28640 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 28641 RECORD_TYPE) 28642 This target hook returns 'true' if bit-fields in the given 28643 RECORD_TYPE are to be laid out following the rules of Microsoft 28644 Visual C/C++, namely: (i) a bit-field won't share the same storage 28645 unit with the previous bit-field if their underlying types have 28646 different sizes, and the bit-field will be aligned to the highest 28647 alignment of the underlying types of itself and of the previous 28648 bit-field; (ii) a zero-sized bit-field will affect the alignment of 28649 the whole enclosing structure, even if it is unnamed; except that 28650 (iii) a zero-sized bit-field will be disregarded unless it follows 28651 another bit-field of nonzero size. If this hook returns 'true', 28652 other macros that control bit-field layout are ignored. 28653 28654 When a bit-field is inserted into a packed record, the whole size 28655 of the underlying type is used by one or more same-size adjacent 28656 bit-fields (that is, if its long:3, 32 bits is used in the record, 28657 and any additional adjacent long bit-fields are packed into the 28658 same chunk of 32 bits. However, if the size changes, a new field 28659 of that size is allocated). In an unpacked record, this is the 28660 same as using alignment, but not equivalent when packing. 28661 28662 If both MS bit-fields and '__attribute__((packed))' are used, the 28663 latter will take precedence. If '__attribute__((packed))' is used 28664 on a single field when MS bit-fields are in use, it will take 28665 precedence for that field, but the alignment of the rest of the 28666 structure may affect its placement. 28667 28668 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 28669 Returns true if the target supports decimal floating point. 28670 28671 -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void) 28672 Returns true if the target supports fixed-point arithmetic. 28673 28674 -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void) 28675 This hook is called just before expansion into rtl, allowing the 28676 target to perform additional initializations or analysis before the 28677 expansion. For example, the rs6000 port uses it to allocate a 28678 scratch stack slot for use in copying SDmode values between memory 28679 and floating point registers whenever the function being expanded 28680 has any SDmode usage. 28681 28682 -- Target Hook: void TARGET_INSTANTIATE_DECLS (void) 28683 This hook allows the backend to perform additional instantiations 28684 on rtl that are not actually in any insns yet, but will be later. 28685 28686 -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE) 28687 If your target defines any fundamental types, or any types your 28688 target uses should be mangled differently from the default, define 28689 this hook to return the appropriate encoding for these types as 28690 part of a C++ mangled name. The TYPE argument is the tree 28691 structure representing the type to be mangled. The hook may be 28692 applied to trees which are not target-specific fundamental types; 28693 it should return 'NULL' for all such types, as well as arguments it 28694 does not recognize. If the return value is not 'NULL', it must 28695 point to a statically-allocated string constant. 28696 28697 Target-specific fundamental types might be new fundamental types or 28698 qualified versions of ordinary fundamental types. Encode new 28699 fundamental types as 'u N NAME', where NAME is the name used for 28700 the type in source code, and N is the length of NAME in decimal. 28701 Encode qualified versions of ordinary types as 'U N NAME CODE', 28702 where NAME is the name used for the type qualifier in source code, 28703 N is the length of NAME as above, and CODE is the code used to 28704 represent the unqualified version of this type. (See 28705 'write_builtin_type' in 'cp/mangle.c' for the list of codes.) In 28706 both cases the spaces are for clarity; do not include any spaces in 28707 your string. 28708 28709 This hook is applied to types prior to typedef resolution. If the 28710 mangled name for a particular type depends only on that type's main 28711 variant, you can perform typedef resolution yourself using 28712 'TYPE_MAIN_VARIANT' before mangling. 28713 28714 The default version of this hook always returns 'NULL', which is 28715 appropriate for a target that does not define any new fundamental 28716 types. 28717 28718 28719File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 28720 2872117.6 Layout of Source Language Data Types 28722========================================= 28723 28724These macros define the sizes and other characteristics of the standard 28725basic data types used in programs being compiled. Unlike the macros in 28726the previous section, these apply to specific features of C and related 28727languages, rather than to fundamental aspects of storage layout. 28728 28729 -- Macro: INT_TYPE_SIZE 28730 A C expression for the size in bits of the type 'int' on the target 28731 machine. If you don't define this, the default is one word. 28732 28733 -- Macro: SHORT_TYPE_SIZE 28734 A C expression for the size in bits of the type 'short' on the 28735 target machine. If you don't define this, the default is half a 28736 word. (If this would be less than one storage unit, it is rounded 28737 up to one unit.) 28738 28739 -- Macro: LONG_TYPE_SIZE 28740 A C expression for the size in bits of the type 'long' on the 28741 target machine. If you don't define this, the default is one word. 28742 28743 -- Macro: ADA_LONG_TYPE_SIZE 28744 On some machines, the size used for the Ada equivalent of the type 28745 'long' by a native Ada compiler differs from that used by C. In 28746 that situation, define this macro to be a C expression to be used 28747 for the size of that type. If you don't define this, the default 28748 is the value of 'LONG_TYPE_SIZE'. 28749 28750 -- Macro: LONG_LONG_TYPE_SIZE 28751 A C expression for the size in bits of the type 'long long' on the 28752 target machine. If you don't define this, the default is two 28753 words. If you want to support GNU Ada on your machine, the value 28754 of this macro must be at least 64. 28755 28756 -- Macro: CHAR_TYPE_SIZE 28757 A C expression for the size in bits of the type 'char' on the 28758 target machine. If you don't define this, the default is 28759 'BITS_PER_UNIT'. 28760 28761 -- Macro: BOOL_TYPE_SIZE 28762 A C expression for the size in bits of the C++ type 'bool' and C99 28763 type '_Bool' on the target machine. If you don't define this, and 28764 you probably shouldn't, the default is 'CHAR_TYPE_SIZE'. 28765 28766 -- Macro: FLOAT_TYPE_SIZE 28767 A C expression for the size in bits of the type 'float' on the 28768 target machine. If you don't define this, the default is one word. 28769 28770 -- Macro: DOUBLE_TYPE_SIZE 28771 A C expression for the size in bits of the type 'double' on the 28772 target machine. If you don't define this, the default is two 28773 words. 28774 28775 -- Macro: LONG_DOUBLE_TYPE_SIZE 28776 A C expression for the size in bits of the type 'long double' on 28777 the target machine. If you don't define this, the default is two 28778 words. 28779 28780 -- Macro: SHORT_FRACT_TYPE_SIZE 28781 A C expression for the size in bits of the type 'short _Fract' on 28782 the target machine. If you don't define this, the default is 28783 'BITS_PER_UNIT'. 28784 28785 -- Macro: FRACT_TYPE_SIZE 28786 A C expression for the size in bits of the type '_Fract' on the 28787 target machine. If you don't define this, the default is 28788 'BITS_PER_UNIT * 2'. 28789 28790 -- Macro: LONG_FRACT_TYPE_SIZE 28791 A C expression for the size in bits of the type 'long _Fract' on 28792 the target machine. If you don't define this, the default is 28793 'BITS_PER_UNIT * 4'. 28794 28795 -- Macro: LONG_LONG_FRACT_TYPE_SIZE 28796 A C expression for the size in bits of the type 'long long _Fract' 28797 on the target machine. If you don't define this, the default is 28798 'BITS_PER_UNIT * 8'. 28799 28800 -- Macro: SHORT_ACCUM_TYPE_SIZE 28801 A C expression for the size in bits of the type 'short _Accum' on 28802 the target machine. If you don't define this, the default is 28803 'BITS_PER_UNIT * 2'. 28804 28805 -- Macro: ACCUM_TYPE_SIZE 28806 A C expression for the size in bits of the type '_Accum' on the 28807 target machine. If you don't define this, the default is 28808 'BITS_PER_UNIT * 4'. 28809 28810 -- Macro: LONG_ACCUM_TYPE_SIZE 28811 A C expression for the size in bits of the type 'long _Accum' on 28812 the target machine. If you don't define this, the default is 28813 'BITS_PER_UNIT * 8'. 28814 28815 -- Macro: LONG_LONG_ACCUM_TYPE_SIZE 28816 A C expression for the size in bits of the type 'long long _Accum' 28817 on the target machine. If you don't define this, the default is 28818 'BITS_PER_UNIT * 16'. 28819 28820 -- Macro: LIBGCC2_GNU_PREFIX 28821 This macro corresponds to the 'TARGET_LIBFUNC_GNU_PREFIX' target 28822 hook and should be defined if that hook is overriden to be true. 28823 It causes function names in libgcc to be changed to use a '__gnu_' 28824 prefix for their name rather than the default '__'. A port which 28825 uses this macro should also arrange to use 't-gnu-prefix' in the 28826 libgcc 'config.host'. 28827 28828 -- Macro: TARGET_FLT_EVAL_METHOD 28829 A C expression for the value for 'FLT_EVAL_METHOD' in 'float.h', 28830 assuming, if applicable, that the floating-point control word is in 28831 its default state. If you do not define this macro the value of 28832 'FLT_EVAL_METHOD' will be zero. 28833 28834 -- Macro: WIDEST_HARDWARE_FP_SIZE 28835 A C expression for the size in bits of the widest floating-point 28836 format supported by the hardware. If you define this macro, you 28837 must specify a value less than or equal to the value of 28838 'LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 28839 value of 'LONG_DOUBLE_TYPE_SIZE' is the default. 28840 28841 -- Macro: DEFAULT_SIGNED_CHAR 28842 An expression whose value is 1 or 0, according to whether the type 28843 'char' should be signed or unsigned by default. The user can 28844 always override this default with the options '-fsigned-char' and 28845 '-funsigned-char'. 28846 28847 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 28848 This target hook should return true if the compiler should give an 28849 'enum' type only as many bytes as it takes to represent the range 28850 of possible values of that type. It should return false if all 28851 'enum' types should be allocated like 'int'. 28852 28853 The default is to return false. 28854 28855 -- Macro: SIZE_TYPE 28856 A C expression for a string describing the name of the data type to 28857 use for size values. The typedef name 'size_t' is defined using 28858 the contents of the string. 28859 28860 The string can contain more than one keyword. If so, separate them 28861 with spaces, and write first any length keyword, then 'unsigned' if 28862 appropriate, and finally 'int'. The string must exactly match one 28863 of the data type names defined in the function 28864 'c_common_nodes_and_builtins' in the file 'c-family/c-common.c'. 28865 You may not omit 'int' or change the order--that would cause the 28866 compiler to crash on startup. 28867 28868 If you don't define this macro, the default is '"long unsigned 28869 int"'. 28870 28871 -- Macro: SIZETYPE 28872 GCC defines internal types ('sizetype', 'ssizetype', 'bitsizetype' 28873 and 'sbitsizetype') for expressions dealing with size. This macro 28874 is a C expression for a string describing the name of the data type 28875 from which the precision of 'sizetype' is extracted. 28876 28877 The string has the same restrictions as 'SIZE_TYPE' string. 28878 28879 If you don't define this macro, the default is 'SIZE_TYPE'. 28880 28881 -- Macro: PTRDIFF_TYPE 28882 A C expression for a string describing the name of the data type to 28883 use for the result of subtracting two pointers. The typedef name 28884 'ptrdiff_t' is defined using the contents of the string. See 28885 'SIZE_TYPE' above for more information. 28886 28887 If you don't define this macro, the default is '"long int"'. 28888 28889 -- Macro: WCHAR_TYPE 28890 A C expression for a string describing the name of the data type to 28891 use for wide characters. The typedef name 'wchar_t' is defined 28892 using the contents of the string. See 'SIZE_TYPE' above for more 28893 information. 28894 28895 If you don't define this macro, the default is '"int"'. 28896 28897 -- Macro: WCHAR_TYPE_SIZE 28898 A C expression for the size in bits of the data type for wide 28899 characters. This is used in 'cpp', which cannot make use of 28900 'WCHAR_TYPE'. 28901 28902 -- Macro: WINT_TYPE 28903 A C expression for a string describing the name of the data type to 28904 use for wide characters passed to 'printf' and returned from 28905 'getwc'. The typedef name 'wint_t' is defined using the contents 28906 of the string. See 'SIZE_TYPE' above for more information. 28907 28908 If you don't define this macro, the default is '"unsigned int"'. 28909 28910 -- Macro: INTMAX_TYPE 28911 A C expression for a string describing the name of the data type 28912 that can represent any value of any standard or extended signed 28913 integer type. The typedef name 'intmax_t' is defined using the 28914 contents of the string. See 'SIZE_TYPE' above for more 28915 information. 28916 28917 If you don't define this macro, the default is the first of 28918 '"int"', '"long int"', or '"long long int"' that has as much 28919 precision as 'long long int'. 28920 28921 -- Macro: UINTMAX_TYPE 28922 A C expression for a string describing the name of the data type 28923 that can represent any value of any standard or extended unsigned 28924 integer type. The typedef name 'uintmax_t' is defined using the 28925 contents of the string. See 'SIZE_TYPE' above for more 28926 information. 28927 28928 If you don't define this macro, the default is the first of 28929 '"unsigned int"', '"long unsigned int"', or '"long long unsigned 28930 int"' that has as much precision as 'long long unsigned int'. 28931 28932 -- Macro: SIG_ATOMIC_TYPE 28933 -- Macro: INT8_TYPE 28934 -- Macro: INT16_TYPE 28935 -- Macro: INT32_TYPE 28936 -- Macro: INT64_TYPE 28937 -- Macro: UINT8_TYPE 28938 -- Macro: UINT16_TYPE 28939 -- Macro: UINT32_TYPE 28940 -- Macro: UINT64_TYPE 28941 -- Macro: INT_LEAST8_TYPE 28942 -- Macro: INT_LEAST16_TYPE 28943 -- Macro: INT_LEAST32_TYPE 28944 -- Macro: INT_LEAST64_TYPE 28945 -- Macro: UINT_LEAST8_TYPE 28946 -- Macro: UINT_LEAST16_TYPE 28947 -- Macro: UINT_LEAST32_TYPE 28948 -- Macro: UINT_LEAST64_TYPE 28949 -- Macro: INT_FAST8_TYPE 28950 -- Macro: INT_FAST16_TYPE 28951 -- Macro: INT_FAST32_TYPE 28952 -- Macro: INT_FAST64_TYPE 28953 -- Macro: UINT_FAST8_TYPE 28954 -- Macro: UINT_FAST16_TYPE 28955 -- Macro: UINT_FAST32_TYPE 28956 -- Macro: UINT_FAST64_TYPE 28957 -- Macro: INTPTR_TYPE 28958 -- Macro: UINTPTR_TYPE 28959 C expressions for the standard types 'sig_atomic_t', 'int8_t', 28960 'int16_t', 'int32_t', 'int64_t', 'uint8_t', 'uint16_t', 'uint32_t', 28961 'uint64_t', 'int_least8_t', 'int_least16_t', 'int_least32_t', 28962 'int_least64_t', 'uint_least8_t', 'uint_least16_t', 28963 'uint_least32_t', 'uint_least64_t', 'int_fast8_t', 'int_fast16_t', 28964 'int_fast32_t', 'int_fast64_t', 'uint_fast8_t', 'uint_fast16_t', 28965 'uint_fast32_t', 'uint_fast64_t', 'intptr_t', and 'uintptr_t'. See 28966 'SIZE_TYPE' above for more information. 28967 28968 If any of these macros evaluates to a null pointer, the 28969 corresponding type is not supported; if GCC is configured to 28970 provide '<stdint.h>' in such a case, the header provided may not 28971 conform to C99, depending on the type in question. The defaults 28972 for all of these macros are null pointers. 28973 28974 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 28975 The C++ compiler represents a pointer-to-member-function with a 28976 struct that looks like: 28977 28978 struct { 28979 union { 28980 void (*fn)(); 28981 ptrdiff_t vtable_index; 28982 }; 28983 ptrdiff_t delta; 28984 }; 28985 28986 The C++ compiler must use one bit to indicate whether the function 28987 that will be called through a pointer-to-member-function is 28988 virtual. Normally, we assume that the low-order bit of a function 28989 pointer must always be zero. Then, by ensuring that the 28990 vtable_index is odd, we can distinguish which variant of the union 28991 is in use. But, on some platforms function pointers can be odd, 28992 and so this doesn't work. In that case, we use the low-order bit 28993 of the 'delta' field, and shift the remainder of the 'delta' field 28994 to the left. 28995 28996 GCC will automatically make the right selection about where to 28997 store this bit using the 'FUNCTION_BOUNDARY' setting for your 28998 platform. However, some platforms such as ARM/Thumb have 28999 'FUNCTION_BOUNDARY' set such that functions always start at even 29000 addresses, but the lowest bit of pointers to functions indicate 29001 whether the function at that address is in ARM or Thumb mode. If 29002 this is the case of your architecture, you should define this macro 29003 to 'ptrmemfunc_vbit_in_delta'. 29004 29005 In general, you should not have to define this macro. On 29006 architectures in which function addresses are always even, 29007 according to 'FUNCTION_BOUNDARY', GCC will automatically define 29008 this macro to 'ptrmemfunc_vbit_in_pfn'. 29009 29010 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 29011 Normally, the C++ compiler uses function pointers in vtables. This 29012 macro allows the target to change to use "function descriptors" 29013 instead. Function descriptors are found on targets for whom a 29014 function pointer is actually a small data structure. Normally the 29015 data structure consists of the actual code address plus a data 29016 pointer to which the function's data is relative. 29017 29018 If vtables are used, the value of this macro should be the number 29019 of words that the function descriptor occupies. 29020 29021 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 29022 By default, the vtable entries are void pointers, the so the 29023 alignment is the same as pointer alignment. The value of this 29024 macro specifies the alignment of the vtable entry in bits. It 29025 should be defined only when special alignment is necessary. */ 29026 29027 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 29028 There are a few non-descriptor entries in the vtable at offsets 29029 below zero. If these entries must be padded (say, to preserve the 29030 alignment specified by 'TARGET_VTABLE_ENTRY_ALIGN'), set this to 29031 the number of words in each data entry. 29032 29033 29034File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 29035 2903617.7 Register Usage 29037=================== 29038 29039This section explains how to describe what registers the target machine 29040has, and how (in general) they can be used. 29041 29042 The description of which registers a specific instruction can use is 29043done with register classes; see *note Register Classes::. For 29044information on using registers to access a stack frame, see *note Frame 29045Registers::. For passing values in registers, see *note Register 29046Arguments::. For returning values in registers, see *note Scalar 29047Return::. 29048 29049* Menu: 29050 29051* Register Basics:: Number and kinds of registers. 29052* Allocation Order:: Order in which registers are allocated. 29053* Values in Registers:: What kinds of values each reg can hold. 29054* Leaf Functions:: Renumbering registers for leaf functions. 29055* Stack Registers:: Handling a register stack such as 80387. 29056 29057 29058File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 29059 2906017.7.1 Basic Characteristics of Registers 29061----------------------------------------- 29062 29063Registers have various characteristics. 29064 29065 -- Macro: FIRST_PSEUDO_REGISTER 29066 Number of hardware registers known to the compiler. They receive 29067 numbers 0 through 'FIRST_PSEUDO_REGISTER-1'; thus, the first pseudo 29068 register's number really is assigned the number 29069 'FIRST_PSEUDO_REGISTER'. 29070 29071 -- Macro: FIXED_REGISTERS 29072 An initializer that says which registers are used for fixed 29073 purposes all throughout the compiled code and are therefore not 29074 available for general allocation. These would include the stack 29075 pointer, the frame pointer (except on machines where that can be 29076 used as a general register when no frame pointer is needed), the 29077 program counter on machines where that is considered one of the 29078 addressable registers, and any other numbered register with a 29079 standard use. 29080 29081 This information is expressed as a sequence of numbers, separated 29082 by commas and surrounded by braces. The Nth number is 1 if 29083 register N is fixed, 0 otherwise. 29084 29085 The table initialized from this macro, and the table initialized by 29086 the following one, may be overridden at run time either 29087 automatically, by the actions of the macro 29088 'CONDITIONAL_REGISTER_USAGE', or by the user with the command 29089 options '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG'. 29090 29091 -- Macro: CALL_USED_REGISTERS 29092 Like 'FIXED_REGISTERS' but has 1 for each register that is 29093 clobbered (in general) by function calls as well as for fixed 29094 registers. This macro therefore identifies the registers that are 29095 not available for general allocation of values that must live 29096 across function calls. 29097 29098 If a register has 0 in 'CALL_USED_REGISTERS', the compiler 29099 automatically saves it on function entry and restores it on 29100 function exit, if the register is used within the function. 29101 29102 -- Macro: CALL_REALLY_USED_REGISTERS 29103 Like 'CALL_USED_REGISTERS' except this macro doesn't require that 29104 the entire set of 'FIXED_REGISTERS' be included. 29105 ('CALL_USED_REGISTERS' must be a superset of 'FIXED_REGISTERS'). 29106 This macro is optional. If not specified, it defaults to the value 29107 of 'CALL_USED_REGISTERS'. 29108 29109 -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE) 29110 A C expression that is nonzero if it is not permissible to store a 29111 value of mode MODE in hard register number REGNO across a call 29112 without some part of it being clobbered. For most machines this 29113 macro need not be defined. It is only required for machines that 29114 do not preserve the entire contents of a register across a call. 29115 29116 -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void) 29117 This hook may conditionally modify five variables 'fixed_regs', 29118 'call_used_regs', 'global_regs', 'reg_names', and 29119 'reg_class_contents', to take into account any dependence of these 29120 register sets on target flags. The first three of these are of 29121 type 'char []' (interpreted as Boolean vectors). 'global_regs' is 29122 a 'const char *[]', and 'reg_class_contents' is a 'HARD_REG_SET'. 29123 Before the macro is called, 'fixed_regs', 'call_used_regs', 29124 'reg_class_contents', and 'reg_names' have been initialized from 29125 'FIXED_REGISTERS', 'CALL_USED_REGISTERS', 'REG_CLASS_CONTENTS', and 29126 'REGISTER_NAMES', respectively. 'global_regs' has been cleared, 29127 and any '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG' 29128 command options have been applied. 29129 29130 If the usage of an entire class of registers depends on the target 29131 flags, you may indicate this to GCC by using this macro to modify 29132 'fixed_regs' and 'call_used_regs' to 1 for each of the registers in 29133 the classes which should not be used by GCC. Also make 29134 'define_register_constraint's return 'NO_REGS' for constraints that 29135 shouldn't be used. 29136 29137 (However, if this class is not included in 'GENERAL_REGS' and all 29138 of the insn patterns whose constraints permit this class are 29139 controlled by target switches, then GCC will automatically avoid 29140 using these registers when the target switches are opposed to 29141 them.) 29142 29143 -- Macro: INCOMING_REGNO (OUT) 29144 Define this macro if the target machine has register windows. This 29145 C expression returns the register number as seen by the called 29146 function corresponding to the register number OUT as seen by the 29147 calling function. Return OUT if register number OUT is not an 29148 outbound register. 29149 29150 -- Macro: OUTGOING_REGNO (IN) 29151 Define this macro if the target machine has register windows. This 29152 C expression returns the register number as seen by the calling 29153 function corresponding to the register number IN as seen by the 29154 called function. Return IN if register number IN is not an inbound 29155 register. 29156 29157 -- Macro: LOCAL_REGNO (REGNO) 29158 Define this macro if the target machine has register windows. This 29159 C expression returns true if the register is call-saved but is in 29160 the register window. Unlike most call-saved registers, such 29161 registers need not be explicitly restored on function exit or 29162 during non-local gotos. 29163 29164 -- Macro: PC_REGNUM 29165 If the program counter has a register number, define this as that 29166 register number. Otherwise, do not define it. 29167 29168 29169File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 29170 2917117.7.2 Order of Allocation of Registers 29172--------------------------------------- 29173 29174Registers are allocated in order. 29175 29176 -- Macro: REG_ALLOC_ORDER 29177 If defined, an initializer for a vector of integers, containing the 29178 numbers of hard registers in the order in which GCC should prefer 29179 to use them (from most preferred to least). 29180 29181 If this macro is not defined, registers are used lowest numbered 29182 first (all else being equal). 29183 29184 One use of this macro is on machines where the highest numbered 29185 registers must always be saved and the save-multiple-registers 29186 instruction supports only sequences of consecutive registers. On 29187 such machines, define 'REG_ALLOC_ORDER' to be an initializer that 29188 lists the highest numbered allocable register first. 29189 29190 -- Macro: ADJUST_REG_ALLOC_ORDER 29191 A C statement (sans semicolon) to choose the order in which to 29192 allocate hard registers for pseudo-registers local to a basic 29193 block. 29194 29195 Store the desired register order in the array 'reg_alloc_order'. 29196 Element 0 should be the register to allocate first; element 1, the 29197 next register; and so on. 29198 29199 The macro body should not assume anything about the contents of 29200 'reg_alloc_order' before execution of the macro. 29201 29202 On most machines, it is not necessary to define this macro. 29203 29204 -- Macro: HONOR_REG_ALLOC_ORDER 29205 Normally, IRA tries to estimate the costs for saving a register in 29206 the prologue and restoring it in the epilogue. This discourages it 29207 from using call-saved registers. If a machine wants to ensure that 29208 IRA allocates registers in the order given by REG_ALLOC_ORDER even 29209 if some call-saved registers appear earlier than call-used ones, 29210 then define this macro as a C expression to nonzero. Default is 0. 29211 29212 -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO) 29213 In some case register allocation order is not enough for the 29214 Integrated Register Allocator (IRA) to generate a good code. If 29215 this macro is defined, it should return a floating point value 29216 based on REGNO. The cost of using REGNO for a pseudo will be 29217 increased by approximately the pseudo's usage frequency times the 29218 value returned by this macro. Not defining this macro is 29219 equivalent to having it always return '0.0'. 29220 29221 On most machines, it is not necessary to define this macro. 29222 29223 29224File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 29225 2922617.7.3 How Values Fit in Registers 29227---------------------------------- 29228 29229This section discusses the macros that describe which kinds of values 29230(specifically, which machine modes) each register can hold, and how many 29231consecutive registers are needed for a given mode. 29232 29233 -- Macro: HARD_REGNO_NREGS (REGNO, MODE) 29234 A C expression for the number of consecutive hard registers, 29235 starting at register number REGNO, required to hold a value of mode 29236 MODE. This macro must never return zero, even if a register cannot 29237 hold the requested mode - indicate that with HARD_REGNO_MODE_OK 29238 and/or CANNOT_CHANGE_MODE_CLASS instead. 29239 29240 On a machine where all registers are exactly one word, a suitable 29241 definition of this macro is 29242 29243 #define HARD_REGNO_NREGS(REGNO, MODE) \ 29244 ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ 29245 / UNITS_PER_WORD) 29246 29247 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 29248 A C expression that is nonzero if a value of mode MODE, stored in 29249 memory, ends with padding that causes it to take up more space than 29250 in registers starting at register number REGNO (as determined by 29251 multiplying GCC's notion of the size of the register when 29252 containing this mode by the number of registers returned by 29253 'HARD_REGNO_NREGS'). By default this is zero. 29254 29255 For example, if a floating-point value is stored in three 32-bit 29256 registers but takes up 128 bits in memory, then this would be 29257 nonzero. 29258 29259 This macros only needs to be defined if there are cases where 29260 'subreg_get_info' would otherwise wrongly determine that a 'subreg' 29261 can be represented by an offset to the register number, when in 29262 fact such a 'subreg' would contain some of the padding not stored 29263 in registers and so not be representable. 29264 29265 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 29266 For values of REGNO and MODE for which 29267 'HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 29268 returning the greater number of registers required to hold the 29269 value including any padding. In the example above, the value would 29270 be four. 29271 29272 -- Macro: REGMODE_NATURAL_SIZE (MODE) 29273 Define this macro if the natural size of registers that hold values 29274 of mode MODE is not the word size. It is a C expression that 29275 should give the natural size in bytes for the specified mode. It 29276 is used by the register allocator to try to optimize its results. 29277 This happens for example on SPARC 64-bit where the natural size of 29278 floating-point registers is still 32-bit. 29279 29280 -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE) 29281 A C expression that is nonzero if it is permissible to store a 29282 value of mode MODE in hard register number REGNO (or in several 29283 registers starting with that one). For a machine where all 29284 registers are equivalent, a suitable definition is 29285 29286 #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 29287 29288 You need not include code to check for the numbers of fixed 29289 registers, because the allocation mechanism considers them to be 29290 always occupied. 29291 29292 On some machines, double-precision values must be kept in even/odd 29293 register pairs. You can implement that by defining this macro to 29294 reject odd register numbers for such modes. 29295 29296 The minimum requirement for a mode to be OK in a register is that 29297 the 'movMODE' instruction pattern support moves between the 29298 register and other hard register in the same class and that moving 29299 a value into the register and back out not alter it. 29300 29301 Since the same instruction used to move 'word_mode' will work for 29302 all narrower integer modes, it is not necessary on any machine for 29303 'HARD_REGNO_MODE_OK' to distinguish between these modes, provided 29304 you define patterns 'movhi', etc., to take advantage of this. This 29305 is useful because of the interaction between 'HARD_REGNO_MODE_OK' 29306 and 'MODES_TIEABLE_P'; it is very desirable for all integer modes 29307 to be tieable. 29308 29309 Many machines have special registers for floating point arithmetic. 29310 Often people assume that floating point machine modes are allowed 29311 only in floating point registers. This is not true. Any registers 29312 that can hold integers can safely _hold_ a floating point machine 29313 mode, whether or not floating arithmetic can be done on it in those 29314 registers. Integer move instructions can be used to move the 29315 values. 29316 29317 On some machines, though, the converse is true: fixed-point machine 29318 modes may not go in floating registers. This is true if the 29319 floating registers normalize any value stored in them, because 29320 storing a non-floating value there would garble it. In this case, 29321 'HARD_REGNO_MODE_OK' should reject fixed-point machine modes in 29322 floating registers. But if the floating registers do not 29323 automatically normalize, if you can store any bit pattern in one 29324 and retrieve it unchanged without a trap, then any machine mode may 29325 go in a floating register, so you can define this macro to say so. 29326 29327 The primary significance of special floating registers is rather 29328 that they are the registers acceptable in floating point arithmetic 29329 instructions. However, this is of no concern to 29330 'HARD_REGNO_MODE_OK'. You handle it by writing the proper 29331 constraints for those instructions. 29332 29333 On some machines, the floating registers are especially slow to 29334 access, so that it is better to store a value in a stack frame than 29335 in such a register if floating point arithmetic is not being done. 29336 As long as the floating registers are not in class 'GENERAL_REGS', 29337 they will not be used unless some pattern's constraint asks for 29338 one. 29339 29340 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 29341 A C expression that is nonzero if it is OK to rename a hard 29342 register FROM to another hard register TO. 29343 29344 One common use of this macro is to prevent renaming of a register 29345 to another register that is not saved by a prologue in an interrupt 29346 handler. 29347 29348 The default is always nonzero. 29349 29350 -- Macro: MODES_TIEABLE_P (MODE1, MODE2) 29351 A C expression that is nonzero if a value of mode MODE1 is 29352 accessible in mode MODE2 without copying. 29353 29354 If 'HARD_REGNO_MODE_OK (R, MODE1)' and 'HARD_REGNO_MODE_OK (R, 29355 MODE2)' are always the same for any R, then 'MODES_TIEABLE_P 29356 (MODE1, MODE2)' should be nonzero. If they differ for any R, you 29357 should define this macro to return zero unless some other mechanism 29358 ensures the accessibility of the value in a narrower mode. 29359 29360 You should define this macro to return nonzero in as many cases as 29361 possible since doing so will allow GCC to perform better register 29362 allocation. 29363 29364 -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO) 29365 This target hook should return 'true' if it is OK to use a hard 29366 register REGNO as scratch reg in peephole2. 29367 29368 One common use of this macro is to prevent using of a register that 29369 is not saved by a prologue in an interrupt handler. 29370 29371 The default version of this hook always returns 'true'. 29372 29373 -- Macro: AVOID_CCMODE_COPIES 29374 Define this macro if the compiler should avoid copies to/from 29375 'CCmode' registers. You should only define this macro if support 29376 for copying to/from 'CCmode' is incomplete. 29377 29378 29379File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 29380 2938117.7.4 Handling Leaf Functions 29382------------------------------ 29383 29384On some machines, a leaf function (i.e., one which makes no calls) can 29385run more efficiently if it does not make its own register window. Often 29386this means it is required to receive its arguments in the registers 29387where they are passed by the caller, instead of the registers where they 29388would normally arrive. 29389 29390 The special treatment for leaf functions generally applies only when 29391other conditions are met; for example, often they may use only those 29392registers for its own variables and temporaries. We use the term "leaf 29393function" to mean a function that is suitable for this special handling, 29394so that functions with no calls are not necessarily "leaf functions". 29395 29396 GCC assigns register numbers before it knows whether the function is 29397suitable for leaf function treatment. So it needs to renumber the 29398registers in order to output a leaf function. The following macros 29399accomplish this. 29400 29401 -- Macro: LEAF_REGISTERS 29402 Name of a char vector, indexed by hard register number, which 29403 contains 1 for a register that is allowable in a candidate for leaf 29404 function treatment. 29405 29406 If leaf function treatment involves renumbering the registers, then 29407 the registers marked here should be the ones before 29408 renumbering--those that GCC would ordinarily allocate. The 29409 registers which will actually be used in the assembler code, after 29410 renumbering, should not be marked with 1 in this vector. 29411 29412 Define this macro only if the target machine offers a way to 29413 optimize the treatment of leaf functions. 29414 29415 -- Macro: LEAF_REG_REMAP (REGNO) 29416 A C expression whose value is the register number to which REGNO 29417 should be renumbered, when a function is treated as a leaf 29418 function. 29419 29420 If REGNO is a register number which should not appear in a leaf 29421 function before renumbering, then the expression should yield -1, 29422 which will cause the compiler to abort. 29423 29424 Define this macro only if the target machine offers a way to 29425 optimize the treatment of leaf functions, and registers need to be 29426 renumbered to do this. 29427 29428 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' must 29429usually treat leaf functions specially. They can test the C variable 29430'current_function_is_leaf' which is nonzero for leaf functions. 29431'current_function_is_leaf' is set prior to local register allocation and 29432is valid for the remaining compiler passes. They can also test the C 29433variable 'current_function_uses_only_leaf_regs' which is nonzero for 29434leaf functions which only use leaf registers. 29435'current_function_uses_only_leaf_regs' is valid after all passes that 29436modify the instructions have been run and is only useful if 29437'LEAF_REGISTERS' is defined. 29438 29439 29440File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 29441 2944217.7.5 Registers That Form a Stack 29443---------------------------------- 29444 29445There are special features to handle computers where some of the 29446"registers" form a stack. Stack registers are normally written by 29447pushing onto the stack, and are numbered relative to the top of the 29448stack. 29449 29450 Currently, GCC can only handle one group of stack-like registers, and 29451they must be consecutively numbered. Furthermore, the existing support 29452for stack-like registers is specific to the 80387 floating point 29453coprocessor. If you have a new architecture that uses stack-like 29454registers, you will need to do substantial work on 'reg-stack.c' and 29455write your machine description to cooperate with it, as well as defining 29456these macros. 29457 29458 -- Macro: STACK_REGS 29459 Define this if the machine has any stack-like registers. 29460 29461 -- Macro: STACK_REG_COVER_CLASS 29462 This is a cover class containing the stack registers. Define this 29463 if the machine has any stack-like registers. 29464 29465 -- Macro: FIRST_STACK_REG 29466 The number of the first stack-like register. This one is the top 29467 of the stack. 29468 29469 -- Macro: LAST_STACK_REG 29470 The number of the last stack-like register. This one is the bottom 29471 of the stack. 29472 29473 29474File: gccint.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros 29475 2947617.8 Register Classes 29477===================== 29478 29479On many machines, the numbered registers are not all equivalent. For 29480example, certain registers may not be allowed for indexed addressing; 29481certain registers may not be allowed in some instructions. These 29482machine restrictions are described to the compiler using "register 29483classes". 29484 29485 You define a number of register classes, giving each one a name and 29486saying which of the registers belong to it. Then you can specify 29487register classes that are allowed as operands to particular instruction 29488patterns. 29489 29490 In general, each register will belong to several classes. In fact, one 29491class must be named 'ALL_REGS' and contain all the registers. Another 29492class must be named 'NO_REGS' and contain no registers. Often the union 29493of two classes will be another class; however, this is not required. 29494 29495 One of the classes must be named 'GENERAL_REGS'. There is nothing 29496terribly special about the name, but the operand constraint letters 'r' 29497and 'g' specify this class. If 'GENERAL_REGS' is the same as 29498'ALL_REGS', just define it as a macro which expands to 'ALL_REGS'. 29499 29500 Order the classes so that if class X is contained in class Y then X has 29501a lower class number than Y. 29502 29503 The way classes other than 'GENERAL_REGS' are specified in operand 29504constraints is through machine-dependent operand constraint letters. 29505You can define such letters to correspond to various classes, then use 29506them in operand constraints. 29507 29508 You must define the narrowest register classes for allocatable 29509registers, so that each class either has no subclasses, or that for some 29510mode, the move cost between registers within the class is cheaper than 29511moving a register in the class to or from memory (*note Costs::). 29512 29513 You should define a class for the union of two classes whenever some 29514instruction allows both classes. For example, if an instruction allows 29515either a floating point (coprocessor) register or a general register for 29516a certain operand, you should define a class 'FLOAT_OR_GENERAL_REGS' 29517which includes both of them. Otherwise you will get suboptimal code, or 29518even internal compiler errors when reload cannot find a register in the 29519class computed via 'reg_class_subunion'. 29520 29521 You must also specify certain redundant information about the register 29522classes: for each class, which classes contain it and which ones are 29523contained in it; for each pair of classes, the largest class contained 29524in their union. 29525 29526 When a value occupying several consecutive registers is expected in a 29527certain class, all the registers used must belong to that class. 29528Therefore, register classes cannot be used to enforce a requirement for 29529a register pair to start with an even-numbered register. The way to 29530specify this requirement is with 'HARD_REGNO_MODE_OK'. 29531 29532 Register classes used for input-operands of bitwise-and or shift 29533instructions have a special requirement: each such class must have, for 29534each fixed-point machine mode, a subclass whose registers can transfer 29535that mode to or from memory. For example, on some machines, the 29536operations for single-byte values ('QImode') are limited to certain 29537registers. When this is so, each register class that is used in a 29538bitwise-and or shift instruction must have a subclass consisting of 29539registers from which single-byte values can be loaded or stored. This 29540is so that 'PREFERRED_RELOAD_CLASS' can always have a possible value to 29541return. 29542 29543 -- Data type: enum reg_class 29544 An enumerated type that must be defined with all the register class 29545 names as enumerated values. 'NO_REGS' must be first. 'ALL_REGS' 29546 must be the last register class, followed by one more enumerated 29547 value, 'LIM_REG_CLASSES', which is not a register class but rather 29548 tells how many classes there are. 29549 29550 Each register class has a number, which is the value of casting the 29551 class name to type 'int'. The number serves as an index in many of 29552 the tables described below. 29553 29554 -- Macro: N_REG_CLASSES 29555 The number of distinct register classes, defined as follows: 29556 29557 #define N_REG_CLASSES (int) LIM_REG_CLASSES 29558 29559 -- Macro: REG_CLASS_NAMES 29560 An initializer containing the names of the register classes as C 29561 string constants. These names are used in writing some of the 29562 debugging dumps. 29563 29564 -- Macro: REG_CLASS_CONTENTS 29565 An initializer containing the contents of the register classes, as 29566 integers which are bit masks. The Nth integer specifies the 29567 contents of class N. The way the integer MASK is interpreted is 29568 that register R is in the class if 'MASK & (1 << R)' is 1. 29569 29570 When the machine has more than 32 registers, an integer does not 29571 suffice. Then the integers are replaced by sub-initializers, 29572 braced groupings containing several integers. Each sub-initializer 29573 must be suitable as an initializer for the type 'HARD_REG_SET' 29574 which is defined in 'hard-reg-set.h'. In this situation, the first 29575 integer in each sub-initializer corresponds to registers 0 through 29576 31, the second integer to registers 32 through 63, and so on. 29577 29578 -- Macro: REGNO_REG_CLASS (REGNO) 29579 A C expression whose value is a register class containing hard 29580 register REGNO. In general there is more than one such class; 29581 choose a class which is "minimal", meaning that no smaller class 29582 also contains the register. 29583 29584 -- Macro: BASE_REG_CLASS 29585 A macro whose definition is the name of the class to which a valid 29586 base register must belong. A base register is one used in an 29587 address which is the register value plus a displacement. 29588 29589 -- Macro: MODE_BASE_REG_CLASS (MODE) 29590 This is a variation of the 'BASE_REG_CLASS' macro which allows the 29591 selection of a base register in a mode dependent manner. If MODE 29592 is VOIDmode then it should return the same value as 29593 'BASE_REG_CLASS'. 29594 29595 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 29596 A C expression whose value is the register class to which a valid 29597 base register must belong in order to be used in a base plus index 29598 register address. You should define this macro if base plus index 29599 addresses have different requirements than other base register 29600 uses. 29601 29602 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, ADDRESS_SPACE, OUTER_CODE, 29603 INDEX_CODE) 29604 A C expression whose value is the register class to which a valid 29605 base register for a memory reference in mode MODE to address space 29606 ADDRESS_SPACE must belong. OUTER_CODE and INDEX_CODE define the 29607 context in which the base register occurs. OUTER_CODE is the code 29608 of the immediately enclosing expression ('MEM' for the top level of 29609 an address, 'ADDRESS' for something that occurs in an 29610 'address_operand'). INDEX_CODE is the code of the corresponding 29611 index expression if OUTER_CODE is 'PLUS'; 'SCRATCH' otherwise. 29612 29613 -- Macro: INDEX_REG_CLASS 29614 A macro whose definition is the name of the class to which a valid 29615 index register must belong. An index register is one used in an 29616 address where its value is either multiplied by a scale factor or 29617 added to another register (as well as added to a displacement). 29618 29619 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 29620 A C expression which is nonzero if register number NUM is suitable 29621 for use as a base register in operand addresses. 29622 29623 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 29624 A C expression that is just like 'REGNO_OK_FOR_BASE_P', except that 29625 that expression may examine the mode of the memory reference in 29626 MODE. You should define this macro if the mode of the memory 29627 reference affects whether a register may be used as a base 29628 register. If you define this macro, the compiler will use it 29629 instead of 'REGNO_OK_FOR_BASE_P'. The mode may be 'VOIDmode' for 29630 addresses that appear outside a 'MEM', i.e., as an 29631 'address_operand'. 29632 29633 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 29634 A C expression which is nonzero if register number NUM is suitable 29635 for use as a base register in base plus index operand addresses, 29636 accessing memory in mode MODE. It may be either a suitable hard 29637 register or a pseudo register that has been allocated such a hard 29638 register. You should define this macro if base plus index 29639 addresses have different requirements than other base register 29640 uses. 29641 29642 Use of this macro is deprecated; please use the more general 29643 'REGNO_MODE_CODE_OK_FOR_BASE_P'. 29644 29645 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE, 29646 OUTER_CODE, INDEX_CODE) 29647 A C expression which is nonzero if register number NUM is suitable 29648 for use as a base register in operand addresses, accessing memory 29649 in mode MODE in address space ADDRESS_SPACE. This is similar to 29650 'REGNO_MODE_OK_FOR_BASE_P', except that that expression may examine 29651 the context in which the register appears in the memory reference. 29652 OUTER_CODE is the code of the immediately enclosing expression 29653 ('MEM' if at the top level of the address, 'ADDRESS' for something 29654 that occurs in an 'address_operand'). INDEX_CODE is the code of 29655 the corresponding index expression if OUTER_CODE is 'PLUS'; 29656 'SCRATCH' otherwise. The mode may be 'VOIDmode' for addresses that 29657 appear outside a 'MEM', i.e., as an 'address_operand'. 29658 29659 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 29660 A C expression which is nonzero if register number NUM is suitable 29661 for use as an index register in operand addresses. It may be 29662 either a suitable hard register or a pseudo register that has been 29663 allocated such a hard register. 29664 29665 The difference between an index register and a base register is 29666 that the index register may be scaled. If an address involves the 29667 sum of two registers, neither one of them scaled, then either one 29668 may be labeled the "base" and the other the "index"; but whichever 29669 labeling is used must fit the machine's constraints of which 29670 registers may serve in each capacity. The compiler will try both 29671 labelings, looking for one that is valid, and will reload one or 29672 both registers only if neither labeling works. 29673 29674 -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t 29675 RCLASS) 29676 A target hook that places additional preference on the register 29677 class to use when it is necessary to rename a register in class 29678 RCLASS to another class, or perhaps NO_REGS, if no preferred 29679 register class is found or hook 'preferred_rename_class' is not 29680 implemented. Sometimes returning a more restrictive class makes 29681 better code. For example, on ARM, thumb-2 instructions using 29682 'LO_REGS' may be smaller than instructions using 'GENERIC_REGS'. 29683 By returning 'LO_REGS' from 'preferred_rename_class', code size can 29684 be reduced. 29685 29686 -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X, 29687 reg_class_t RCLASS) 29688 A target hook that places additional restrictions on the register 29689 class to use when it is necessary to copy value X into a register 29690 in class RCLASS. The value is a register class; perhaps RCLASS, or 29691 perhaps another, smaller class. 29692 29693 The default version of this hook always returns value of 'rclass' 29694 argument. 29695 29696 Sometimes returning a more restrictive class makes better code. 29697 For example, on the 68000, when X is an integer constant that is in 29698 range for a 'moveq' instruction, the value of this macro is always 29699 'DATA_REGS' as long as RCLASS includes the data registers. 29700 Requiring a data register guarantees that a 'moveq' will be used. 29701 29702 One case where 'TARGET_PREFERRED_RELOAD_CLASS' must not return 29703 RCLASS is if X is a legitimate constant which cannot be loaded into 29704 some register class. By returning 'NO_REGS' you can force X into a 29705 memory location. For example, rs6000 can load immediate values 29706 into general-purpose registers, but does not have an instruction 29707 for loading an immediate value into a floating-point register, so 29708 'TARGET_PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 29709 floating-point constant. If the constant can't be loaded into any 29710 kind of register, code generation will be better if 29711 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 29712 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 29713 29714 If an insn has pseudos in it after register allocation, reload will 29715 go through the alternatives and call repeatedly 29716 'TARGET_PREFERRED_RELOAD_CLASS' to find the best one. Returning 29717 'NO_REGS', in this case, makes reload add a '!' in front of the 29718 constraint: the x86 back-end uses this feature to discourage usage 29719 of 387 registers when math is done in the SSE registers (and vice 29720 versa). 29721 29722 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 29723 A C expression that places additional restrictions on the register 29724 class to use when it is necessary to copy value X into a register 29725 in class CLASS. The value is a register class; perhaps CLASS, or 29726 perhaps another, smaller class. On many machines, the following 29727 definition is safe: 29728 29729 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 29730 29731 Sometimes returning a more restrictive class makes better code. 29732 For example, on the 68000, when X is an integer constant that is in 29733 range for a 'moveq' instruction, the value of this macro is always 29734 'DATA_REGS' as long as CLASS includes the data registers. 29735 Requiring a data register guarantees that a 'moveq' will be used. 29736 29737 One case where 'PREFERRED_RELOAD_CLASS' must not return CLASS is if 29738 X is a legitimate constant which cannot be loaded into some 29739 register class. By returning 'NO_REGS' you can force X into a 29740 memory location. For example, rs6000 can load immediate values 29741 into general-purpose registers, but does not have an instruction 29742 for loading an immediate value into a floating-point register, so 29743 'PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 29744 floating-point constant. If the constant can't be loaded into any 29745 kind of register, code generation will be better if 29746 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 29747 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 29748 29749 If an insn has pseudos in it after register allocation, reload will 29750 go through the alternatives and call repeatedly 29751 'PREFERRED_RELOAD_CLASS' to find the best one. Returning 29752 'NO_REGS', in this case, makes reload add a '!' in front of the 29753 constraint: the x86 back-end uses this feature to discourage usage 29754 of 387 registers when math is done in the SSE registers (and vice 29755 versa). 29756 29757 -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx 29758 X, reg_class_t RCLASS) 29759 Like 'TARGET_PREFERRED_RELOAD_CLASS', but for output reloads 29760 instead of input reloads. 29761 29762 The default version of this hook always returns value of 'rclass' 29763 argument. 29764 29765 You can also use 'TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to 29766 discourage reload from using some alternatives, like 29767 'TARGET_PREFERRED_RELOAD_CLASS'. 29768 29769 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 29770 A C expression that places additional restrictions on the register 29771 class to use when it is necessary to be able to hold a value of 29772 mode MODE in a reload register for which class CLASS would 29773 ordinarily be used. 29774 29775 Unlike 'PREFERRED_RELOAD_CLASS', this macro should be used when 29776 there are certain modes that simply can't go in certain reload 29777 classes. 29778 29779 The value is a register class; perhaps CLASS, or perhaps another, 29780 smaller class. 29781 29782 Don't define this macro unless the target machine has limitations 29783 which require the macro to do something nontrivial. 29784 29785 -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X, 29786 reg_class_t RELOAD_CLASS, machine_mode RELOAD_MODE, 29787 secondary_reload_info *SRI) 29788 Many machines have some registers that cannot be copied directly to 29789 or from memory or even from other types of registers. An example 29790 is the 'MQ' register, which on most machines, can only be copied to 29791 or from general registers, but not memory. Below, we shall be 29792 using the term 'intermediate register' when a move operation cannot 29793 be performed directly, but has to be done by copying the source 29794 into the intermediate register first, and then copying the 29795 intermediate register to the destination. An intermediate register 29796 always has the same mode as source and destination. Since it holds 29797 the actual value being copied, reload might apply optimizations to 29798 re-use an intermediate register and eliding the copy from the 29799 source when it can determine that the intermediate register still 29800 holds the required value. 29801 29802 Another kind of secondary reload is required on some machines which 29803 allow copying all registers to and from memory, but require a 29804 scratch register for stores to some memory locations (e.g., those 29805 with symbolic address on the RT, and those with certain symbolic 29806 address on the SPARC when compiling PIC). Scratch registers need 29807 not have the same mode as the value being copied, and usually hold 29808 a different value than that being copied. Special patterns in the 29809 md file are needed to describe how the copy is performed with the 29810 help of the scratch register; these patterns also describe the 29811 number, register class(es) and mode(s) of the scratch register(s). 29812 29813 In some cases, both an intermediate and a scratch register are 29814 required. 29815 29816 For input reloads, this target hook is called with nonzero IN_P, 29817 and X is an rtx that needs to be copied to a register of class 29818 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 29819 is called with zero IN_P, and a register of class RELOAD_CLASS 29820 needs to be copied to rtx X in RELOAD_MODE. 29821 29822 If copying a register of RELOAD_CLASS from/to X requires an 29823 intermediate register, the hook 'secondary_reload' should return 29824 the register class required for this intermediate register. If no 29825 intermediate register is required, it should return NO_REGS. If 29826 more than one intermediate register is required, describe the one 29827 that is closest in the copy chain to the reload register. 29828 29829 If scratch registers are needed, you also have to describe how to 29830 perform the copy from/to the reload register to/from this closest 29831 intermediate register. Or if no intermediate register is required, 29832 but still a scratch register is needed, describe the copy from/to 29833 the reload register to/from the reload operand X. 29834 29835 You do this by setting 'sri->icode' to the instruction code of a 29836 pattern in the md file which performs the move. Operands 0 and 1 29837 are the output and input of this copy, respectively. Operands from 29838 operand 2 onward are for scratch operands. These scratch operands 29839 must have a mode, and a single-register-class output constraint. 29840 29841 When an intermediate register is used, the 'secondary_reload' hook 29842 will be called again to determine how to copy the intermediate 29843 register to/from the reload operand X, so your hook must also have 29844 code to handle the register class of the intermediate operand. 29845 29846 X might be a pseudo-register or a 'subreg' of a pseudo-register, 29847 which could either be in a hard register or in memory. Use 29848 'true_regnum' to find out; it will return -1 if the pseudo is in 29849 memory and the hard register number if it is in a register. 29850 29851 Scratch operands in memory (constraint '"=m"' / '"=&m"') are 29852 currently not supported. For the time being, you will have to 29853 continue to use 'SECONDARY_MEMORY_NEEDED' for that purpose. 29854 29855 'copy_cost' also uses this target hook to find out how values are 29856 copied. If you want it to include some extra cost for the need to 29857 allocate (a) scratch register(s), set 'sri->extra_cost' to the 29858 additional cost. Or if two dependent moves are supposed to have a 29859 lower cost than the sum of the individual moves due to expected 29860 fortuitous scheduling and/or special forwarding logic, you can set 29861 'sri->extra_cost' to a negative amount. 29862 29863 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 29864 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 29865 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 29866 These macros are obsolete, new ports should use the target hook 29867 'TARGET_SECONDARY_RELOAD' instead. 29868 29869 These are obsolete macros, replaced by the 29870 'TARGET_SECONDARY_RELOAD' target hook. Older ports still define 29871 these macros to indicate to the reload phase that it may need to 29872 allocate at least one register for a reload in addition to the 29873 register to contain the data. Specifically, if copying X to a 29874 register CLASS in MODE requires an intermediate register, you were 29875 supposed to define 'SECONDARY_INPUT_RELOAD_CLASS' to return the 29876 largest register class all of whose registers can be used as 29877 intermediate registers or scratch registers. 29878 29879 If copying a register CLASS in MODE to X requires an intermediate 29880 or scratch register, 'SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 29881 to be defined be defined to return the largest register class 29882 required. If the requirements for input and output reloads were 29883 the same, the macro 'SECONDARY_RELOAD_CLASS' should have been used 29884 instead of defining both macros identically. 29885 29886 The values returned by these macros are often 'GENERAL_REGS'. 29887 Return 'NO_REGS' if no spare register is needed; i.e., if X can be 29888 directly copied to or from a register of CLASS in MODE without 29889 requiring a scratch register. Do not define this macro if it would 29890 always return 'NO_REGS'. 29891 29892 If a scratch register is required (either with or without an 29893 intermediate register), you were supposed to define patterns for 29894 'reload_inM' or 'reload_outM', as required (*note Standard Names::. 29895 These patterns, which were normally implemented with a 29896 'define_expand', should be similar to the 'movM' patterns, except 29897 that operand 2 is the scratch register. 29898 29899 These patterns need constraints for the reload register and scratch 29900 register that contain a single register class. If the original 29901 reload register (whose class is CLASS) can meet the constraint 29902 given in the pattern, the value returned by these macros is used 29903 for the class of the scratch register. Otherwise, two additional 29904 reload registers are required. Their classes are obtained from the 29905 constraints in the insn pattern. 29906 29907 X might be a pseudo-register or a 'subreg' of a pseudo-register, 29908 which could either be in a hard register or in memory. Use 29909 'true_regnum' to find out; it will return -1 if the pseudo is in 29910 memory and the hard register number if it is in a register. 29911 29912 These macros should not be used in the case where a particular 29913 class of registers can only be copied to memory and not to another 29914 class of registers. In that case, secondary reload registers are 29915 not needed and would not be helpful. Instead, a stack location 29916 must be used to perform the copy and the 'movM' pattern should use 29917 memory as an intermediate storage. This case often occurs between 29918 floating-point and general registers. 29919 29920 -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M) 29921 Certain machines have the property that some registers cannot be 29922 copied to some other registers without using memory. Define this 29923 macro on those machines to be a C expression that is nonzero if 29924 objects of mode M in registers of CLASS1 can only be copied to 29925 registers of class CLASS2 by storing a register of CLASS1 into 29926 memory and loading that memory location into a register of CLASS2. 29927 29928 Do not define this macro if its value would always be zero. 29929 29930 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 29931 Normally when 'SECONDARY_MEMORY_NEEDED' is defined, the compiler 29932 allocates a stack slot for a memory location needed for register 29933 copies. If this macro is defined, the compiler instead uses the 29934 memory location defined by this macro. 29935 29936 Do not define this macro if you do not define 29937 'SECONDARY_MEMORY_NEEDED'. 29938 29939 -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE) 29940 When the compiler needs a secondary memory location to copy between 29941 two registers of mode MODE, it normally allocates sufficient memory 29942 to hold a quantity of 'BITS_PER_WORD' bits and performs the store 29943 and load operations in a mode that many bits wide and whose class 29944 is the same as that of MODE. 29945 29946 This is right thing to do on most machines because it ensures that 29947 all bits of the register are copied and prevents accesses to the 29948 registers in a narrower mode, which some machines prohibit for 29949 floating-point registers. 29950 29951 However, this default behavior is not correct on some machines, 29952 such as the DEC Alpha, that store short integers in floating-point 29953 registers differently than in integer registers. On those 29954 machines, the default widening will not work correctly and you must 29955 define this macro to suppress that widening in some cases. See the 29956 file 'alpha.h' for details. 29957 29958 Do not define this macro if you do not define 29959 'SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is 29960 'BITS_PER_WORD' bits wide is correct for your machine. 29961 29962 -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS) 29963 A target hook which returns 'true' if pseudos that have been 29964 assigned to registers of class RCLASS would likely be spilled 29965 because registers of RCLASS are needed for spill registers. 29966 29967 The default version of this target hook returns 'true' if RCLASS 29968 has exactly one register and 'false' otherwise. On most machines, 29969 this default should be used. For generally register-starved 29970 machines, such as i386, or machines with right register 29971 constraints, such as SH, this hook can be used to avoid excessive 29972 spilling. 29973 29974 This hook is also used by some of the global intra-procedural code 29975 transformations to throtle code motion, to avoid increasing 29976 register pressure. 29977 29978 -- Target Hook: unsigned char TARGET_CLASS_MAX_NREGS (reg_class_t 29979 RCLASS, machine_mode MODE) 29980 A target hook returns the maximum number of consecutive registers 29981 of class RCLASS needed to hold a value of mode MODE. 29982 29983 This is closely related to the macro 'HARD_REGNO_NREGS'. In fact, 29984 the value returned by 'TARGET_CLASS_MAX_NREGS (RCLASS, MODE)' 29985 target hook should be the maximum value of 'HARD_REGNO_NREGS 29986 (REGNO, MODE)' for all REGNO values in the class RCLASS. 29987 29988 This target hook helps control the handling of multiple-word values 29989 in the reload pass. 29990 29991 The default version of this target hook returns the size of MODE in 29992 words. 29993 29994 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 29995 A C expression for the maximum number of consecutive registers of 29996 class CLASS needed to hold a value of mode MODE. 29997 29998 This is closely related to the macro 'HARD_REGNO_NREGS'. In fact, 29999 the value of the macro 'CLASS_MAX_NREGS (CLASS, MODE)' should be 30000 the maximum value of 'HARD_REGNO_NREGS (REGNO, MODE)' for all REGNO 30001 values in the class CLASS. 30002 30003 This macro helps control the handling of multiple-word values in 30004 the reload pass. 30005 30006 -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS) 30007 If defined, a C expression that returns nonzero for a CLASS for 30008 which a change from mode FROM to mode TO is invalid. 30009 30010 For example, loading 32-bit integer or floating-point objects into 30011 floating-point registers on Alpha extends them to 64 bits. 30012 Therefore loading a 64-bit object and then storing it as a 32-bit 30013 object does not store the low-order 32 bits, as would be the case 30014 for a normal register. Therefore, 'alpha.h' defines 30015 'CANNOT_CHANGE_MODE_CLASS' as below: 30016 30017 #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ 30018 (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ 30019 ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0) 30020 30021 Even if storing from a register in mode TO would be valid, if both 30022 FROM and 'raw_reg_mode' for CLASS are wider than 'word_mode', then 30023 we must prevent TO narrowing the mode. This happens when the 30024 middle-end assumes that it can load or store pieces of an N-word 30025 pseudo, and that the pseudo will eventually be allocated to N 30026 'word_mode' hard registers. Failure to prevent this kind of mode 30027 change will result in the entire 'raw_reg_mode' being modified 30028 instead of the partial value that the middle-end intended. 30029 30030 -- Target Hook: bool TARGET_LRA_P (void) 30031 A target hook which returns true if we use LRA instead of reload 30032 pass. It means that LRA was ported to the target. The default 30033 version of this target hook returns always false. 30034 30035 -- Target Hook: int TARGET_REGISTER_PRIORITY (int) 30036 A target hook which returns the register priority number to which 30037 the register HARD_REGNO belongs to. The bigger the number, the 30038 more preferable the hard register usage (when all other conditions 30039 are the same). This hook can be used to prefer some hard register 30040 over others in LRA. For example, some x86-64 register usage needs 30041 additional prefix which makes instructions longer. The hook can 30042 return lower priority number for such registers make them less 30043 favorable and as result making the generated code smaller. The 30044 default version of this target hook returns always zero. 30045 30046 -- Target Hook: bool TARGET_REGISTER_USAGE_LEVELING_P (void) 30047 A target hook which returns true if we need register usage 30048 leveling. That means if a few hard registers are equally good for 30049 the assignment, we choose the least used hard register. The 30050 register usage leveling may be profitable for some targets. Don't 30051 use the usage leveling for targets with conditional execution or 30052 targets with big register files as it hurts if-conversion and 30053 cross-jumping optimizations. The default version of this target 30054 hook returns always false. 30055 30056 -- Target Hook: bool TARGET_DIFFERENT_ADDR_DISPLACEMENT_P (void) 30057 A target hook which returns true if an address with the same 30058 structure can have different maximal legitimate displacement. For 30059 example, the displacement can depend on memory mode or on operand 30060 combinations in the insn. The default version of this target hook 30061 returns always false. 30062 30063 -- Target Hook: bool TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P (rtx SUBST) 30064 A target hook which returns 'true' if SUBST can't substitute safely 30065 pseudos with equivalent memory values during register allocation. 30066 The default version of this target hook returns 'false'. On most 30067 machines, this default should be used. For generally machines with 30068 non orthogonal register usage for addressing, such as SH, this hook 30069 can be used to avoid excessive spilling. 30070 30071 -- Target Hook: bool TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT (rtx *DISP, 30072 rtx *OFFSET, machine_mode MODE) 30073 A target hook which returns 'true' if *DISP is legitimezed to valid 30074 address displacement with subtracting *OFFSET at memory mode MODE. 30075 The default version of this target hook returns 'false'. This hook 30076 will benefit machines with limited base plus displacement 30077 addressing. 30078 30079 -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t, 30080 MACHINE_MODE) 30081 This hook defines a class of registers which could be used for 30082 spilling pseudos of the given mode and class, or 'NO_REGS' if only 30083 memory should be used. Not defining this hook is equivalent to 30084 returning 'NO_REGS' for all inputs. 30085 30086 -- Target Hook: machine_mode TARGET_CSTORE_MODE (enum insn_code ICODE) 30087 This hook defines the machine mode to use for the boolean result of 30088 conditional store patterns. The ICODE argument is the instruction 30089 code for the cstore being performed. Not definiting this hook is 30090 the same as accepting the mode encoded into operand 0 of the cstore 30091 expander patterns. 30092 30093 30094File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros 30095 3009617.9 Stack Layout and Calling Conventions 30097========================================= 30098 30099This describes the stack layout and calling conventions. 30100 30101* Menu: 30102 30103* Frame Layout:: 30104* Exception Handling:: 30105* Stack Checking:: 30106* Frame Registers:: 30107* Elimination:: 30108* Stack Arguments:: 30109* Register Arguments:: 30110* Scalar Return:: 30111* Aggregate Return:: 30112* Caller Saves:: 30113* Function Entry:: 30114* Profiling:: 30115* Tail Calls:: 30116* Stack Smashing Protection:: 30117* Miscellaneous Register Hooks:: 30118 30119 30120File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 30121 3012217.9.1 Basic Stack Layout 30123------------------------- 30124 30125Here is the basic stack layout. 30126 30127 -- Macro: STACK_GROWS_DOWNWARD 30128 Define this macro if pushing a word onto the stack moves the stack 30129 pointer to a smaller address. 30130 30131 When we say, "define this macro if ...", it means that the compiler 30132 checks this macro only with '#ifdef' so the precise definition used 30133 does not matter. 30134 30135 -- Macro: STACK_PUSH_CODE 30136 This macro defines the operation used when something is pushed on 30137 the stack. In RTL, a push operation will be '(set (mem 30138 (STACK_PUSH_CODE (reg sp))) ...)' 30139 30140 The choices are 'PRE_DEC', 'POST_DEC', 'PRE_INC', and 'POST_INC'. 30141 Which of these is correct depends on the stack direction and on 30142 whether the stack pointer points to the last item on the stack or 30143 whether it points to the space for the next item on the stack. 30144 30145 The default is 'PRE_DEC' when 'STACK_GROWS_DOWNWARD' is defined, 30146 which is almost always right, and 'PRE_INC' otherwise, which is 30147 often wrong. 30148 30149 -- Macro: FRAME_GROWS_DOWNWARD 30150 Define this macro to nonzero value if the addresses of local 30151 variable slots are at negative offsets from the frame pointer. 30152 30153 -- Macro: ARGS_GROW_DOWNWARD 30154 Define this macro if successive arguments to a function occupy 30155 decreasing addresses on the stack. 30156 30157 -- Macro: STARTING_FRAME_OFFSET 30158 Offset from the frame pointer to the first local variable slot to 30159 be allocated. 30160 30161 If 'FRAME_GROWS_DOWNWARD', find the next slot's offset by 30162 subtracting the first slot's length from 'STARTING_FRAME_OFFSET'. 30163 Otherwise, it is found by adding the length of the first slot to 30164 the value 'STARTING_FRAME_OFFSET'. 30165 30166 -- Macro: STACK_ALIGNMENT_NEEDED 30167 Define to zero to disable final alignment of the stack during 30168 reload. The nonzero default for this macro is suitable for most 30169 ports. 30170 30171 On ports where 'STARTING_FRAME_OFFSET' is nonzero or where there is 30172 a register save block following the local block that doesn't 30173 require alignment to 'STACK_BOUNDARY', it may be beneficial to 30174 disable stack alignment and do it in the backend. 30175 30176 -- Macro: STACK_POINTER_OFFSET 30177 Offset from the stack pointer register to the first location at 30178 which outgoing arguments are placed. If not specified, the default 30179 value of zero is used. This is the proper value for most machines. 30180 30181 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 30182 the first location at which outgoing arguments are placed. 30183 30184 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 30185 Offset from the argument pointer register to the first argument's 30186 address. On some machines it may depend on the data type of the 30187 function. 30188 30189 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 30190 the first argument's address. 30191 30192 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 30193 Offset from the stack pointer register to an item dynamically 30194 allocated on the stack, e.g., by 'alloca'. 30195 30196 The default value for this macro is 'STACK_POINTER_OFFSET' plus the 30197 length of the outgoing arguments. The default is correct for most 30198 machines. See 'function.c' for details. 30199 30200 -- Macro: INITIAL_FRAME_ADDRESS_RTX 30201 A C expression whose value is RTL representing the address of the 30202 initial stack frame. This address is passed to 'RETURN_ADDR_RTX' 30203 and 'DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 30204 reasonable default value will be used. Define this macro in order 30205 to make frame pointer elimination work in the presence of 30206 '__builtin_frame_address (count)' and '__builtin_return_address 30207 (count)' for 'count' not equal to zero. 30208 30209 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 30210 A C expression whose value is RTL representing the address in a 30211 stack frame where the pointer to the caller's frame is stored. 30212 Assume that FRAMEADDR is an RTL expression for the address of the 30213 stack frame itself. 30214 30215 If you don't define this macro, the default is to return the value 30216 of FRAMEADDR--that is, the stack frame address is also the address 30217 of the stack word that points to the previous frame. 30218 30219 -- Macro: SETUP_FRAME_ADDRESSES 30220 If defined, a C expression that produces the machine-specific code 30221 to setup the stack so that arbitrary frames can be accessed. For 30222 example, on the SPARC, we must flush all of the register windows to 30223 the stack before we can access arbitrary stack frames. You will 30224 seldom need to define this macro. 30225 30226 -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void) 30227 This target hook should return an rtx that is used to store the 30228 address of the current frame into the built in 'setjmp' buffer. 30229 The default value, 'virtual_stack_vars_rtx', is correct for most 30230 machines. One reason you may need to define this target hook is if 30231 'hard_frame_pointer_rtx' is the appropriate value on your machine. 30232 30233 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 30234 A C expression whose value is RTL representing the value of the 30235 frame address for the current frame. FRAMEADDR is the frame 30236 pointer of the current frame. This is used for 30237 __builtin_frame_address. You need only define this macro if the 30238 frame address is not the same as the frame pointer. Most machines 30239 do not need to define it. 30240 30241 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 30242 A C expression whose value is RTL representing the value of the 30243 return address for the frame COUNT steps up from the current frame, 30244 after the prologue. FRAMEADDR is the frame pointer of the COUNT 30245 frame, or the frame pointer of the COUNT - 1 frame if 30246 'RETURN_ADDR_IN_PREVIOUS_FRAME' is nonzero. 30247 30248 The value of the expression must always be the correct address when 30249 COUNT is zero, but may be 'NULL_RTX' if there is no way to 30250 determine the return address of other frames. 30251 30252 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 30253 Define this macro to nonzero value if the return address of a 30254 particular stack frame is accessed from the frame pointer of the 30255 previous stack frame. The zero default for this macro is suitable 30256 for most ports. 30257 30258 -- Macro: INCOMING_RETURN_ADDR_RTX 30259 A C expression whose value is RTL representing the location of the 30260 incoming return address at the beginning of any function, before 30261 the prologue. This RTL is either a 'REG', indicating that the 30262 return value is saved in 'REG', or a 'MEM' representing a location 30263 in the stack. 30264 30265 You only need to define this macro if you want to support call 30266 frame debugging information like that provided by DWARF 2. 30267 30268 If this RTL is a 'REG', you should also define 30269 'DWARF_FRAME_RETURN_COLUMN' to 'DWARF_FRAME_REGNUM (REGNO)'. 30270 30271 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 30272 A C expression whose value is an integer giving a DWARF 2 column 30273 number that may be used as an alternative return column. The 30274 column must not correspond to any gcc hard register (that is, it 30275 must not be in the range of 'DWARF_FRAME_REGNUM'). 30276 30277 This macro can be useful if 'DWARF_FRAME_RETURN_COLUMN' is set to a 30278 general register, but an alternative column needs to be used for 30279 signal frames. Some targets have also used different frame return 30280 columns over time. 30281 30282 -- Macro: DWARF_ZERO_REG 30283 A C expression whose value is an integer giving a DWARF 2 register 30284 number that is considered to always have the value zero. This 30285 should only be defined if the target has an architected zero 30286 register, and someone decided it was a good idea to use that 30287 register number to terminate the stack backtrace. New ports should 30288 avoid this. 30289 30290 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 30291 *LABEL, rtx PATTERN, int INDEX) 30292 This target hook allows the backend to emit frame-related insns 30293 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 30294 debugging info engine will invoke it on insns of the form 30295 (set (reg) (unspec [...] UNSPEC_INDEX)) 30296 and 30297 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 30298 to let the backend emit the call frame instructions. LABEL is the 30299 CFI label attached to the insn, PATTERN is the pattern of the insn 30300 and INDEX is 'UNSPEC_INDEX' or 'UNSPECV_INDEX'. 30301 30302 -- Macro: INCOMING_FRAME_SP_OFFSET 30303 A C expression whose value is an integer giving the offset, in 30304 bytes, from the value of the stack pointer register to the top of 30305 the stack frame at the beginning of any function, before the 30306 prologue. The top of the frame is defined to be the value of the 30307 stack pointer in the previous frame, just before the call 30308 instruction. 30309 30310 You only need to define this macro if you want to support call 30311 frame debugging information like that provided by DWARF 2. 30312 30313 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 30314 A C expression whose value is an integer giving the offset, in 30315 bytes, from the argument pointer to the canonical frame address 30316 (cfa). The final value should coincide with that calculated by 30317 'INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 30318 during virtual register instantiation. 30319 30320 The default value for this macro is 'FIRST_PARM_OFFSET (fundecl) + 30321 crtl->args.pretend_args_size', which is correct for most machines; 30322 in general, the arguments are found immediately before the stack 30323 frame. Note that this is not the case on some targets that save 30324 registers into the caller's frame, such as SPARC and rs6000, and so 30325 such targets need to define this macro. 30326 30327 You only need to define this macro if the default is incorrect, and 30328 you want to support call frame debugging information like that 30329 provided by DWARF 2. 30330 30331 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 30332 If defined, a C expression whose value is an integer giving the 30333 offset in bytes from the frame pointer to the canonical frame 30334 address (cfa). The final value should coincide with that 30335 calculated by 'INCOMING_FRAME_SP_OFFSET'. 30336 30337 Normally the CFA is calculated as an offset from the argument 30338 pointer, via 'ARG_POINTER_CFA_OFFSET', but if the argument pointer 30339 is variable due to the ABI, this may not be possible. If this 30340 macro is defined, it implies that the virtual register 30341 instantiation should be based on the frame pointer instead of the 30342 argument pointer. Only one of 'FRAME_POINTER_CFA_OFFSET' and 30343 'ARG_POINTER_CFA_OFFSET' should be defined. 30344 30345 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 30346 If defined, a C expression whose value is an integer giving the 30347 offset in bytes from the canonical frame address (cfa) to the frame 30348 base used in DWARF 2 debug information. The default is zero. A 30349 different value may reduce the size of debug information on some 30350 ports. 30351 30352 30353File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 30354 3035517.9.2 Exception Handling Support 30356--------------------------------- 30357 30358 -- Macro: EH_RETURN_DATA_REGNO (N) 30359 A C expression whose value is the Nth register number used for data 30360 by exception handlers, or 'INVALID_REGNUM' if fewer than N 30361 registers are usable. 30362 30363 The exception handling library routines communicate with the 30364 exception handlers via a set of agreed upon registers. Ideally 30365 these registers should be call-clobbered; it is possible to use 30366 call-saved registers, but may negatively impact code size. The 30367 target must support at least 2 data registers, but should define 4 30368 if there are enough free registers. 30369 30370 You must define this macro if you want to support call frame 30371 exception handling like that provided by DWARF 2. 30372 30373 -- Macro: EH_RETURN_STACKADJ_RTX 30374 A C expression whose value is RTL representing a location in which 30375 to store a stack adjustment to be applied before function return. 30376 This is used to unwind the stack to an exception handler's call 30377 frame. It will be assigned zero on code paths that return 30378 normally. 30379 30380 Typically this is a call-clobbered hard register that is otherwise 30381 untouched by the epilogue, but could also be a stack slot. 30382 30383 Do not define this macro if the stack pointer is saved and restored 30384 by the regular prolog and epilog code in the call frame itself; in 30385 this case, the exception handling library routines will update the 30386 stack location to be restored in place. Otherwise, you must define 30387 this macro if you want to support call frame exception handling 30388 like that provided by DWARF 2. 30389 30390 -- Macro: EH_RETURN_HANDLER_RTX 30391 A C expression whose value is RTL representing a location in which 30392 to store the address of an exception handler to which we should 30393 return. It will not be assigned on code paths that return 30394 normally. 30395 30396 Typically this is the location in the call frame at which the 30397 normal return address is stored. For targets that return by 30398 popping an address off the stack, this might be a memory address 30399 just below the _target_ call frame rather than inside the current 30400 call frame. If defined, 'EH_RETURN_STACKADJ_RTX' will have already 30401 been assigned, so it may be used to calculate the location of the 30402 target call frame. 30403 30404 Some targets have more complex requirements than storing to an 30405 address calculable during initial code generation. In that case 30406 the 'eh_return' instruction pattern should be used instead. 30407 30408 If you want to support call frame exception handling, you must 30409 define either this macro or the 'eh_return' instruction pattern. 30410 30411 -- Macro: RETURN_ADDR_OFFSET 30412 If defined, an integer-valued C expression for which rtl will be 30413 generated to add it to the exception handler address before it is 30414 searched in the exception handling tables, and to subtract it again 30415 from the address before using it to return to the exception 30416 handler. 30417 30418 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 30419 This macro chooses the encoding of pointers embedded in the 30420 exception handling sections. If at all possible, this should be 30421 defined such that the exception handling section will not require 30422 dynamic relocations, and so may be read-only. 30423 30424 CODE is 0 for data, 1 for code labels, 2 for function pointers. 30425 GLOBAL is true if the symbol may be affected by dynamic 30426 relocations. The macro should return a combination of the 30427 'DW_EH_PE_*' defines as found in 'dwarf2.h'. 30428 30429 If this macro is not defined, pointers will not be encoded but 30430 represented directly. 30431 30432 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 30433 ADDR, DONE) 30434 This macro allows the target to emit whatever special magic is 30435 required to represent the encoding chosen by 30436 'ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 30437 pc-relative and indirect encodings; this must be defined if the 30438 target uses text-relative or data-relative encodings. 30439 30440 This is a C statement that branches to DONE if the format was 30441 handled. ENCODING is the format chosen, SIZE is the number of 30442 bytes that the format occupies, ADDR is the 'SYMBOL_REF' to be 30443 emitted. 30444 30445 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 30446 This macro allows the target to add CPU and operating system 30447 specific code to the call-frame unwinder for use when there is no 30448 unwind data available. The most common reason to implement this 30449 macro is to unwind through signal frames. 30450 30451 This macro is called from 'uw_frame_state_for' in 'unwind-dw2.c', 30452 'unwind-dw2-xtensa.c' and 'unwind-ia64.c'. CONTEXT is an 30453 '_Unwind_Context'; FS is an '_Unwind_FrameState'. Examine 30454 'context->ra' for the address of the code being executed and 30455 'context->cfa' for the stack pointer value. If the frame can be 30456 decoded, the register save addresses should be updated in FS and 30457 the macro should evaluate to '_URC_NO_REASON'. If the frame cannot 30458 be decoded, the macro should evaluate to '_URC_END_OF_STACK'. 30459 30460 For proper signal handling in Java this macro is accompanied by 30461 'MAKE_THROW_FRAME', defined in 'libjava/include/*-signal.h' 30462 headers. 30463 30464 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 30465 This macro allows the target to add operating system specific code 30466 to the call-frame unwinder to handle the IA-64 '.unwabi' unwinding 30467 directive, usually used for signal or interrupt frames. 30468 30469 This macro is called from 'uw_update_context' in libgcc's 30470 'unwind-ia64.c'. CONTEXT is an '_Unwind_Context'; FS is an 30471 '_Unwind_FrameState'. Examine 'fs->unwabi' for the abi and context 30472 in the '.unwabi' directive. If the '.unwabi' directive can be 30473 handled, the register save addresses should be updated in FS. 30474 30475 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 30476 A C expression that evaluates to true if the target requires unwind 30477 info to be given comdat linkage. Define it to be '1' if comdat 30478 linkage is necessary. The default is '0'. 30479 30480 30481File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 30482 3048317.9.3 Specifying How Stack Checking is Done 30484-------------------------------------------- 30485 30486GCC will check that stack references are within the boundaries of the 30487stack, if the option '-fstack-check' is specified, in one of three ways: 30488 30489 1. If the value of the 'STACK_CHECK_BUILTIN' macro is nonzero, GCC 30490 will assume that you have arranged for full stack checking to be 30491 done at appropriate places in the configuration files. GCC will 30492 not do other special processing. 30493 30494 2. If 'STACK_CHECK_BUILTIN' is zero and the value of the 30495 'STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume that 30496 you have arranged for static stack checking (checking of the static 30497 stack frame of functions) to be done at appropriate places in the 30498 configuration files. GCC will only emit code to do dynamic stack 30499 checking (checking on dynamic stack allocations) using the third 30500 approach below. 30501 30502 3. If neither of the above are true, GCC will generate code to 30503 periodically "probe" the stack pointer using the values of the 30504 macros defined below. 30505 30506 If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is 30507defined, GCC will change its allocation strategy for large objects if 30508the option '-fstack-check' is specified: they will always be allocated 30509dynamically if their size exceeds 'STACK_CHECK_MAX_VAR_SIZE' bytes. 30510 30511 -- Macro: STACK_CHECK_BUILTIN 30512 A nonzero value if stack checking is done by the configuration 30513 files in a machine-dependent manner. You should define this macro 30514 if stack checking is required by the ABI of your machine or if you 30515 would like to do stack checking in some more efficient way than the 30516 generic approach. The default value of this macro is zero. 30517 30518 -- Macro: STACK_CHECK_STATIC_BUILTIN 30519 A nonzero value if static stack checking is done by the 30520 configuration files in a machine-dependent manner. You should 30521 define this macro if you would like to do static stack checking in 30522 some more efficient way than the generic approach. The default 30523 value of this macro is zero. 30524 30525 -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP 30526 An integer specifying the interval at which GCC must generate stack 30527 probe instructions, defined as 2 raised to this integer. You will 30528 normally define this macro so that the interval be no larger than 30529 the size of the "guard pages" at the end of a stack area. The 30530 default value of 12 (4096-byte interval) is suitable for most 30531 systems. 30532 30533 -- Macro: STACK_CHECK_MOVING_SP 30534 An integer which is nonzero if GCC should move the stack pointer 30535 page by page when doing probes. This can be necessary on systems 30536 where the stack pointer contains the bottom address of the memory 30537 area accessible to the executing thread at any point in time. In 30538 this situation an alternate signal stack is required in order to be 30539 able to recover from a stack overflow. The default value of this 30540 macro is zero. 30541 30542 -- Macro: STACK_CHECK_PROTECT 30543 The number of bytes of stack needed to recover from a stack 30544 overflow, for languages where such a recovery is supported. The 30545 default value of 75 words with the 'setjmp'/'longjmp'-based 30546 exception handling mechanism and 8192 bytes with other exception 30547 handling mechanisms should be adequate for most machines. 30548 30549 The following macros are relevant only if neither STACK_CHECK_BUILTIN 30550nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether 30551in the opposite case. 30552 30553 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 30554 The maximum size of a stack frame, in bytes. GCC will generate 30555 probe instructions in non-leaf functions to ensure at least this 30556 many bytes of stack are available. If a stack frame is larger than 30557 this size, stack checking will not be reliable and GCC will issue a 30558 warning. The default is chosen so that GCC only generates one 30559 instruction on most systems. You should normally not change the 30560 default value of this macro. 30561 30562 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 30563 GCC uses this value to generate the above warning message. It 30564 represents the amount of fixed frame used by a function, not 30565 including space for any callee-saved registers, temporaries and 30566 user variables. You need only specify an upper bound for this 30567 amount and will normally use the default of four words. 30568 30569 -- Macro: STACK_CHECK_MAX_VAR_SIZE 30570 The maximum size, in bytes, of an object that GCC will place in the 30571 fixed area of the stack frame when the user specifies 30572 '-fstack-check'. GCC computed the default from the values of the 30573 above macros and you will normally not need to override that 30574 default. 30575 30576 30577File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 30578 3057917.9.4 Registers That Address the Stack Frame 30580--------------------------------------------- 30581 30582This discusses registers that address the stack frame. 30583 30584 -- Macro: STACK_POINTER_REGNUM 30585 The register number of the stack pointer register, which must also 30586 be a fixed register according to 'FIXED_REGISTERS'. On most 30587 machines, the hardware determines which register this is. 30588 30589 -- Macro: FRAME_POINTER_REGNUM 30590 The register number of the frame pointer register, which is used to 30591 access automatic variables in the stack frame. On some machines, 30592 the hardware determines which register this is. On other machines, 30593 you can choose any register you wish for this purpose. 30594 30595 -- Macro: HARD_FRAME_POINTER_REGNUM 30596 On some machines the offset between the frame pointer and starting 30597 offset of the automatic variables is not known until after register 30598 allocation has been done (for example, because the saved registers 30599 are between these two locations). On those machines, define 30600 'FRAME_POINTER_REGNUM' the number of a special, fixed register to 30601 be used internally until the offset is known, and define 30602 'HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 30603 used for the frame pointer. 30604 30605 You should define this macro only in the very rare circumstances 30606 when it is not possible to calculate the offset between the frame 30607 pointer and the automatic variables until after register allocation 30608 has been completed. When this macro is defined, you must also 30609 indicate in your definition of 'ELIMINABLE_REGS' how to eliminate 30610 'FRAME_POINTER_REGNUM' into either 'HARD_FRAME_POINTER_REGNUM' or 30611 'STACK_POINTER_REGNUM'. 30612 30613 Do not define this macro if it would be the same as 30614 'FRAME_POINTER_REGNUM'. 30615 30616 -- Macro: ARG_POINTER_REGNUM 30617 The register number of the arg pointer register, which is used to 30618 access the function's argument list. On some machines, this is the 30619 same as the frame pointer register. On some machines, the hardware 30620 determines which register this is. On other machines, you can 30621 choose any register you wish for this purpose. If this is not the 30622 same register as the frame pointer register, then you must mark it 30623 as a fixed register according to 'FIXED_REGISTERS', or arrange to 30624 be able to eliminate it (*note Elimination::). 30625 30626 -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER 30627 Define this to a preprocessor constant that is nonzero if 30628 'hard_frame_pointer_rtx' and 'frame_pointer_rtx' should be the 30629 same. The default definition is '(HARD_FRAME_POINTER_REGNUM == 30630 FRAME_POINTER_REGNUM)'; you only need to define this macro if that 30631 definition is not suitable for use in preprocessor conditionals. 30632 30633 -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER 30634 Define this to a preprocessor constant that is nonzero if 30635 'hard_frame_pointer_rtx' and 'arg_pointer_rtx' should be the same. 30636 The default definition is '(HARD_FRAME_POINTER_REGNUM == 30637 ARG_POINTER_REGNUM)'; you only need to define this macro if that 30638 definition is not suitable for use in preprocessor conditionals. 30639 30640 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 30641 The register number of the return address pointer register, which 30642 is used to access the current function's return address from the 30643 stack. On some machines, the return address is not at a fixed 30644 offset from the frame pointer or stack pointer or argument pointer. 30645 This register can be defined to point to the return address on the 30646 stack, and then be converted by 'ELIMINABLE_REGS' into either the 30647 frame pointer or stack pointer. 30648 30649 Do not define this macro unless there is no other way to get the 30650 return address from the stack. 30651 30652 -- Macro: STATIC_CHAIN_REGNUM 30653 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 30654 Register numbers used for passing a function's static chain 30655 pointer. If register windows are used, the register number as seen 30656 by the called function is 'STATIC_CHAIN_INCOMING_REGNUM', while the 30657 register number as seen by the calling function is 30658 'STATIC_CHAIN_REGNUM'. If these registers are the same, 30659 'STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 30660 30661 The static chain register need not be a fixed register. 30662 30663 If the static chain is passed in memory, these macros should not be 30664 defined; instead, the 'TARGET_STATIC_CHAIN' hook should be used. 30665 30666 -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL_OR_TYPE, 30667 bool INCOMING_P) 30668 This hook replaces the use of 'STATIC_CHAIN_REGNUM' et al for 30669 targets that may use different static chain locations for different 30670 nested functions. This may be required if the target has function 30671 attributes that affect the calling conventions of the function and 30672 those calling conventions use different static chain locations. 30673 30674 The default version of this hook uses 'STATIC_CHAIN_REGNUM' et al. 30675 30676 If the static chain is passed in memory, this hook should be used 30677 to provide rtx giving 'mem' expressions that denote where they are 30678 stored. Often the 'mem' expression as seen by the caller will be 30679 at an offset from the stack pointer and the 'mem' expression as 30680 seen by the callee will be at an offset from the frame pointer. 30681 The variables 'stack_pointer_rtx', 'frame_pointer_rtx', and 30682 'arg_pointer_rtx' will have been initialized and should be used to 30683 refer to those items. 30684 30685 -- Macro: DWARF_FRAME_REGISTERS 30686 This macro specifies the maximum number of hard registers that can 30687 be saved in a call frame. This is used to size data structures 30688 used in DWARF2 exception handling. 30689 30690 Prior to GCC 3.0, this macro was needed in order to establish a 30691 stable exception handling ABI in the face of adding new hard 30692 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 30693 insulated from changes in the number of hard registers. 30694 Nevertheless, this macro can still be used to reduce the runtime 30695 memory requirements of the exception handling routines, which can 30696 be substantial if the ISA contains a lot of registers that are not 30697 call-saved. 30698 30699 If this macro is not defined, it defaults to 30700 'FIRST_PSEUDO_REGISTER'. 30701 30702 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 30703 30704 This macro is similar to 'DWARF_FRAME_REGISTERS', but is provided 30705 for backward compatibility in pre GCC 3.0 compiled code. 30706 30707 If this macro is not defined, it defaults to 30708 'DWARF_FRAME_REGISTERS'. 30709 30710 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 30711 30712 Define this macro if the target's representation for dwarf 30713 registers is different than the internal representation for unwind 30714 column. Given a dwarf register, this macro should return the 30715 internal unwind column number to use instead. 30716 30717 See the PowerPC's SPE target for an example. 30718 30719 -- Macro: DWARF_FRAME_REGNUM (REGNO) 30720 30721 Define this macro if the target's representation for dwarf 30722 registers used in .eh_frame or .debug_frame is different from that 30723 used in other debug info sections. Given a GCC hard register 30724 number, this macro should return the .eh_frame register number. 30725 The default is 'DBX_REGISTER_NUMBER (REGNO)'. 30726 30727 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 30728 30729 Define this macro to map register numbers held in the call frame 30730 info that GCC has collected using 'DWARF_FRAME_REGNUM' to those 30731 that should be output in .debug_frame ('FOR_EH' is zero) and 30732 .eh_frame ('FOR_EH' is nonzero). The default is to return 'REGNO'. 30733 30734 -- Macro: REG_VALUE_IN_UNWIND_CONTEXT 30735 30736 Define this macro if the target stores register values as 30737 '_Unwind_Word' type in unwind context. It should be defined if 30738 target register size is larger than the size of 'void *'. The 30739 default is to store register values as 'void *' type. 30740 30741 -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT 30742 30743 Define this macro to be 1 if the target always uses extended unwind 30744 context with version, args_size and by_value fields. If it is 30745 undefined, it will be defined to 1 when 30746 'REG_VALUE_IN_UNWIND_CONTEXT' is defined and 0 otherwise. 30747 30748 30749File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 30750 3075117.9.5 Eliminating Frame Pointer and Arg Pointer 30752------------------------------------------------ 30753 30754This is about eliminating the frame pointer and arg pointer. 30755 30756 -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void) 30757 This target hook should return 'true' if a function must have and 30758 use a frame pointer. This target hook is called in the reload 30759 pass. If its return value is 'true' the function will have a frame 30760 pointer. 30761 30762 This target hook can in principle examine the current function and 30763 decide according to the facts, but on most machines the constant 30764 'false' or the constant 'true' suffices. Use 'false' when the 30765 machine allows code to be generated with no frame pointer, and 30766 doing so saves some time or space. Use 'true' when there is no 30767 possible advantage to avoiding a frame pointer. 30768 30769 In certain cases, the compiler does not know how to produce valid 30770 code without a frame pointer. The compiler recognizes those cases 30771 and automatically gives the function a frame pointer regardless of 30772 what 'TARGET_FRAME_POINTER_REQUIRED' returns. You don't need to 30773 worry about them. 30774 30775 In a function that does not require a frame pointer, the frame 30776 pointer register can be allocated for ordinary usage, unless you 30777 mark it as a fixed register. See 'FIXED_REGISTERS' for more 30778 information. 30779 30780 Default return value is 'false'. 30781 30782 -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR) 30783 A C statement to store in the variable DEPTH-VAR the difference 30784 between the frame pointer and the stack pointer values immediately 30785 after the function prologue. The value would be computed from 30786 information such as the result of 'get_frame_size ()' and the 30787 tables of registers 'regs_ever_live' and 'call_used_regs'. 30788 30789 If 'ELIMINABLE_REGS' is defined, this macro will be not be used and 30790 need not be defined. Otherwise, it must be defined even if 30791 'TARGET_FRAME_POINTER_REQUIRED' always returns true; in that case, 30792 you may set DEPTH-VAR to anything. 30793 30794 -- Macro: ELIMINABLE_REGS 30795 If defined, this macro specifies a table of register pairs used to 30796 eliminate unneeded registers that point into the stack frame. If 30797 it is not defined, the only elimination attempted by the compiler 30798 is to replace references to the frame pointer with references to 30799 the stack pointer. 30800 30801 The definition of this macro is a list of structure 30802 initializations, each of which specifies an original and 30803 replacement register. 30804 30805 On some machines, the position of the argument pointer is not known 30806 until the compilation is completed. In such a case, a separate 30807 hard register must be used for the argument pointer. This register 30808 can be eliminated by replacing it with either the frame pointer or 30809 the argument pointer, depending on whether or not the frame pointer 30810 has been eliminated. 30811 30812 In this case, you might specify: 30813 #define ELIMINABLE_REGS \ 30814 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 30815 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 30816 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 30817 30818 Note that the elimination of the argument pointer with the stack 30819 pointer is specified first since that is the preferred elimination. 30820 30821 -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const 30822 int TO_REG) 30823 This target hook should returns 'true' if the compiler is allowed 30824 to try to replace register number FROM_REG with register number 30825 TO_REG. This target hook need only be defined if 'ELIMINABLE_REGS' 30826 is defined, and will usually be 'true', since most of the cases 30827 preventing register elimination are things that the compiler 30828 already knows about. 30829 30830 Default return value is 'true'. 30831 30832 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 30833 This macro is similar to 'INITIAL_FRAME_POINTER_OFFSET'. It 30834 specifies the initial difference between the specified pair of 30835 registers. This macro must be defined if 'ELIMINABLE_REGS' is 30836 defined. 30837 30838 30839File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 30840 3084117.9.6 Passing Function Arguments on the Stack 30842---------------------------------------------- 30843 30844The macros in this section control how arguments are passed on the 30845stack. See the following section for other macros that control passing 30846certain arguments in registers. 30847 30848 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE) 30849 This target hook returns 'true' if an argument declared in a 30850 prototype as an integral type smaller than 'int' should actually be 30851 passed as an 'int'. In addition to avoiding errors in certain 30852 cases of mismatch, it also makes for better code on certain 30853 machines. The default is to not promote prototypes. 30854 30855 -- Macro: PUSH_ARGS 30856 A C expression. If nonzero, push insns will be used to pass 30857 outgoing arguments. If the target machine does not have a push 30858 instruction, set it to zero. That directs GCC to use an alternate 30859 strategy: to allocate the entire argument block and then store the 30860 arguments into it. When 'PUSH_ARGS' is nonzero, 'PUSH_ROUNDING' 30861 must be defined too. 30862 30863 -- Macro: PUSH_ARGS_REVERSED 30864 A C expression. If nonzero, function arguments will be evaluated 30865 from last to first, rather than from first to last. If this macro 30866 is not defined, it defaults to 'PUSH_ARGS' on targets where the 30867 stack and args grow in opposite directions, and 0 otherwise. 30868 30869 -- Macro: PUSH_ROUNDING (NPUSHED) 30870 A C expression that is the number of bytes actually pushed onto the 30871 stack when an instruction attempts to push NPUSHED bytes. 30872 30873 On some machines, the definition 30874 30875 #define PUSH_ROUNDING(BYTES) (BYTES) 30876 30877 will suffice. But on other machines, instructions that appear to 30878 push one byte actually push two bytes in an attempt to maintain 30879 alignment. Then the definition should be 30880 30881 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 30882 30883 If the value of this macro has a type, it should be an unsigned 30884 type. 30885 30886 -- Macro: ACCUMULATE_OUTGOING_ARGS 30887 A C expression. If nonzero, the maximum amount of space required 30888 for outgoing arguments will be computed and placed into 30889 'crtl->outgoing_args_size'. No space will be pushed onto the stack 30890 for each call; instead, the function prologue should increase the 30891 stack frame size by this amount. 30892 30893 Setting both 'PUSH_ARGS' and 'ACCUMULATE_OUTGOING_ARGS' is not 30894 proper. 30895 30896 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 30897 Define this macro if functions should assume that stack space has 30898 been allocated for arguments even when their values are passed in 30899 registers. 30900 30901 The value of this macro is the size, in bytes, of the area reserved 30902 for arguments passed in registers for the function represented by 30903 FNDECL, which can be zero if GCC is calling a library function. 30904 The argument FNDECL can be the FUNCTION_DECL, or the type itself of 30905 the function. 30906 30907 This space can be allocated by the caller, or be a part of the 30908 machine-dependent stack frame: 'OUTGOING_REG_PARM_STACK_SPACE' says 30909 which. 30910 30911 -- Macro: INCOMING_REG_PARM_STACK_SPACE (FNDECL) 30912 Like 'REG_PARM_STACK_SPACE', but for incoming register arguments. 30913 Define this macro if space guaranteed when compiling a function 30914 body is different to space required when making a call, a situation 30915 that can arise with K&R style function definitions. 30916 30917 -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE) 30918 Define this to a nonzero value if it is the responsibility of the 30919 caller to allocate the area reserved for arguments passed in 30920 registers when calling a function of FNTYPE. FNTYPE may be NULL if 30921 the function called is a library function. 30922 30923 If 'ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 30924 whether the space for these arguments counts in the value of 30925 'crtl->outgoing_args_size'. 30926 30927 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 30928 Define this macro if 'REG_PARM_STACK_SPACE' is defined, but the 30929 stack parameters don't skip the area specified by it. 30930 30931 Normally, when a parameter is not passed in registers, it is placed 30932 on the stack beyond the 'REG_PARM_STACK_SPACE' area. Defining this 30933 macro suppresses this behavior and causes the parameter to be 30934 passed on the stack in its natural location. 30935 30936 -- Target Hook: int TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree 30937 FUNTYPE, int SIZE) 30938 This target hook returns the number of bytes of its own arguments 30939 that a function pops on returning, or 0 if the function pops no 30940 arguments and the caller must therefore pop them all after the 30941 function returns. 30942 30943 FUNDECL is a C variable whose value is a tree node that describes 30944 the function in question. Normally it is a node of type 30945 'FUNCTION_DECL' that describes the declaration of the function. 30946 From this you can obtain the 'DECL_ATTRIBUTES' of the function. 30947 30948 FUNTYPE is a C variable whose value is a tree node that describes 30949 the function in question. Normally it is a node of type 30950 'FUNCTION_TYPE' that describes the data type of the function. From 30951 this it is possible to obtain the data types of the value and 30952 arguments (if known). 30953 30954 When a call to a library function is being considered, FUNDECL will 30955 contain an identifier node for the library function. Thus, if you 30956 need to distinguish among various library functions, you can do so 30957 by their names. Note that "library function" in this context means 30958 a function used to perform arithmetic, whose name is known 30959 specially in the compiler and was not mentioned in the C code being 30960 compiled. 30961 30962 SIZE is the number of bytes of arguments passed on the stack. If a 30963 variable number of bytes is passed, it is zero, and argument 30964 popping will always be the responsibility of the calling function. 30965 30966 On the VAX, all functions always pop their arguments, so the 30967 definition of this macro is SIZE. On the 68000, using the standard 30968 calling convention, no functions pop their arguments, so the value 30969 of the macro is always 0 in this case. But an alternative calling 30970 convention is available in which functions that take a fixed number 30971 of arguments pop them but other functions (such as 'printf') pop 30972 nothing (the caller pops all). When this convention is in use, 30973 FUNTYPE is examined to determine whether a function takes a fixed 30974 number of arguments. 30975 30976 -- Macro: CALL_POPS_ARGS (CUM) 30977 A C expression that should indicate the number of bytes a call 30978 sequence pops off the stack. It is added to the value of 30979 'RETURN_POPS_ARGS' when compiling a function call. 30980 30981 CUM is the variable in which all arguments to the called function 30982 have been accumulated. 30983 30984 On certain architectures, such as the SH5, a call trampoline is 30985 used that pops certain registers off the stack, depending on the 30986 arguments that have been passed to the function. Since this is a 30987 property of the call site, not of the called function, 30988 'RETURN_POPS_ARGS' is not appropriate. 30989 30990 30991File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 30992 3099317.9.7 Passing Arguments in Registers 30994------------------------------------- 30995 30996This section describes the macros which let you control how various 30997types of arguments are passed in registers or how they are arranged in 30998the stack. 30999 31000 -- Target Hook: rtx TARGET_FUNCTION_ARG (cumulative_args_t CA, 31001 machine_mode MODE, const_tree TYPE, bool NAMED) 31002 Return an RTX indicating whether a function argument is passed in a 31003 register and if so, which register. 31004 31005 The arguments are CA, which summarizes all the previous arguments; 31006 MODE, the machine mode of the argument; TYPE, the data type of the 31007 argument as a tree node or 0 if that is not known (which happens 31008 for C support library functions); and NAMED, which is 'true' for an 31009 ordinary argument and 'false' for nameless arguments that 31010 correspond to '...' in the called function's prototype. TYPE can 31011 be an incomplete type if a syntax error has previously occurred. 31012 31013 The return value is usually either a 'reg' RTX for the hard 31014 register in which to pass the argument, or zero to pass the 31015 argument on the stack. 31016 31017 The return value can be a 'const_int' which means argument is 31018 passed in a target specific slot with specified number. Target 31019 hooks should be used to store or load argument in such case. See 31020 'TARGET_STORE_BOUNDS_FOR_ARG' and 'TARGET_LOAD_BOUNDS_FOR_ARG' for 31021 more information. 31022 31023 The value of the expression can also be a 'parallel' RTX. This is 31024 used when an argument is passed in multiple locations. The mode of 31025 the 'parallel' should be the mode of the entire argument. The 31026 'parallel' holds any number of 'expr_list' pairs; each one 31027 describes where part of the argument is passed. In each 31028 'expr_list' the first operand must be a 'reg' RTX for the hard 31029 register in which to pass this part of the argument, and the mode 31030 of the register RTX indicates how large this part of the argument 31031 is. The second operand of the 'expr_list' is a 'const_int' which 31032 gives the offset in bytes into the entire argument of where this 31033 part starts. As a special exception the first 'expr_list' in the 31034 'parallel' RTX may have a first operand of zero. This indicates 31035 that the entire argument is also stored on the stack. 31036 31037 The last time this hook is called, it is called with 'MODE == 31038 VOIDmode', and its result is passed to the 'call' or 'call_value' 31039 pattern as operands 2 and 3 respectively. 31040 31041 The usual way to make the ISO library 'stdarg.h' work on a machine 31042 where some arguments are usually passed in registers, is to cause 31043 nameless arguments to be passed on the stack instead. This is done 31044 by making 'TARGET_FUNCTION_ARG' return 0 whenever NAMED is 'false'. 31045 31046 You may use the hook 'targetm.calls.must_pass_in_stack' in the 31047 definition of this macro to determine if this argument is of a type 31048 that must be passed in the stack. If 'REG_PARM_STACK_SPACE' is not 31049 defined and 'TARGET_FUNCTION_ARG' returns nonzero for such an 31050 argument, the compiler will abort. If 'REG_PARM_STACK_SPACE' is 31051 defined, the argument will be computed in the stack and then loaded 31052 into a register. 31053 31054 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (machine_mode MODE, 31055 const_tree TYPE) 31056 This target hook should return 'true' if we should not pass TYPE 31057 solely in registers. The file 'expr.h' defines a definition that 31058 is usually appropriate, refer to 'expr.h' for additional 31059 documentation. 31060 31061 -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t CA, 31062 machine_mode MODE, const_tree TYPE, bool NAMED) 31063 Define this hook if the target machine has "register windows", so 31064 that the register in which a function sees an arguments is not 31065 necessarily the same as the one in which the caller passed the 31066 argument. 31067 31068 For such machines, 'TARGET_FUNCTION_ARG' computes the register in 31069 which the caller passes the value, and 31070 'TARGET_FUNCTION_INCOMING_ARG' should be defined in a similar 31071 fashion to tell the function being called where the arguments will 31072 arrive. 31073 31074 If 'TARGET_FUNCTION_INCOMING_ARG' is not defined, 31075 'TARGET_FUNCTION_ARG' serves both purposes. 31076 31077 -- Target Hook: bool TARGET_USE_PSEUDO_PIC_REG (void) 31078 This hook should return 1 in case pseudo register should be created 31079 for pic_offset_table_rtx during function expand. 31080 31081 -- Target Hook: void TARGET_INIT_PIC_REG (void) 31082 Perform a target dependent initialization of pic_offset_table_rtx. 31083 This hook is called at the start of register allocation. 31084 31085 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (cumulative_args_t CUM, 31086 machine_mode MODE, tree TYPE, bool NAMED) 31087 This target hook returns the number of bytes at the beginning of an 31088 argument that must be put in registers. The value must be zero for 31089 arguments that are passed entirely in registers or that are 31090 entirely pushed on the stack. 31091 31092 On some machines, certain arguments must be passed partially in 31093 registers and partially in memory. On these machines, typically 31094 the first few words of arguments are passed in registers, and the 31095 rest on the stack. If a multi-word argument (a 'double' or a 31096 structure) crosses that boundary, its first few words must be 31097 passed in registers and the rest must be pushed. This macro tells 31098 the compiler when this occurs, and how many bytes should go in 31099 registers. 31100 31101 'TARGET_FUNCTION_ARG' for these arguments should return the first 31102 register to be used by the caller for this argument; likewise 31103 'TARGET_FUNCTION_INCOMING_ARG', for the called function. 31104 31105 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM, 31106 machine_mode MODE, const_tree TYPE, bool NAMED) 31107 This target hook should return 'true' if an argument at the 31108 position indicated by CUM should be passed by reference. This 31109 predicate is queried after target independent reasons for being 31110 passed by reference, such as 'TREE_ADDRESSABLE (type)'. 31111 31112 If the hook returns true, a copy of that argument is made in memory 31113 and a pointer to the argument is passed instead of the argument 31114 itself. The pointer is passed in whatever way is appropriate for 31115 passing a pointer to that type. 31116 31117 -- Target Hook: bool TARGET_CALLEE_COPIES (cumulative_args_t CUM, 31118 machine_mode MODE, const_tree TYPE, bool NAMED) 31119 The function argument described by the parameters to this hook is 31120 known to be passed by reference. The hook should return true if 31121 the function argument should be copied by the callee instead of 31122 copied by the caller. 31123 31124 For any argument for which the hook returns true, if it can be 31125 determined that the argument is not modified, then a copy need not 31126 be generated. 31127 31128 The default version of this hook always returns false. 31129 31130 -- Macro: CUMULATIVE_ARGS 31131 A C type for declaring a variable that is used as the first 31132 argument of 'TARGET_FUNCTION_ARG' and other related values. For 31133 some target machines, the type 'int' suffices and can hold the 31134 number of bytes of argument so far. 31135 31136 There is no need to record in 'CUMULATIVE_ARGS' anything about the 31137 arguments that have been passed on the stack. The compiler has 31138 other variables to keep track of that. For target machines on 31139 which all arguments are passed on the stack, there is no need to 31140 store anything in 'CUMULATIVE_ARGS'; however, the data structure 31141 must exist and should not be empty, so use 'int'. 31142 31143 -- Macro: OVERRIDE_ABI_FORMAT (FNDECL) 31144 If defined, this macro is called before generating any code for a 31145 function, but after the CFUN descriptor for the function has been 31146 created. The back end may use this macro to update CFUN to reflect 31147 an ABI other than that which would normally be used by default. If 31148 the compiler is generating code for a compiler-generated function, 31149 FNDECL may be 'NULL'. 31150 31151 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 31152 N_NAMED_ARGS) 31153 A C statement (sans semicolon) for initializing the variable CUM 31154 for the state at the beginning of the argument list. The variable 31155 has type 'CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 31156 for the data type of the function which will receive the args, or 0 31157 if the args are to a compiler support library function. For direct 31158 calls that are not libcalls, FNDECL contain the declaration node of 31159 the function. FNDECL is also set when 'INIT_CUMULATIVE_ARGS' is 31160 used to find arguments for the function being compiled. 31161 N_NAMED_ARGS is set to the number of named arguments, including a 31162 structure return address if it is passed as a parameter, when 31163 making a call. When processing incoming arguments, N_NAMED_ARGS is 31164 set to -1. 31165 31166 When processing a call to a compiler support library function, 31167 LIBNAME identifies which one. It is a 'symbol_ref' rtx which 31168 contains the name of the function, as a string. LIBNAME is 0 when 31169 an ordinary C function call is being processed. Thus, each time 31170 this macro is called, either LIBNAME or FNTYPE is nonzero, but 31171 never both of them at once. 31172 31173 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 31174 Like 'INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, it 31175 gets a 'MODE' argument instead of FNTYPE, that would be 'NULL'. 31176 INDIRECT would always be zero, too. If this macro is not defined, 31177 'INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead. 31178 31179 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 31180 Like 'INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 31181 finding the arguments for the function being compiled. If this 31182 macro is undefined, 'INIT_CUMULATIVE_ARGS' is used instead. 31183 31184 The value passed for LIBNAME is always 0, since library routines 31185 with special calling conventions are never compiled with GCC. The 31186 argument LIBNAME exists for symmetry with 'INIT_CUMULATIVE_ARGS'. 31187 31188 -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t CA, 31189 machine_mode MODE, const_tree TYPE, bool NAMED) 31190 This hook updates the summarizer variable pointed to by CA to 31191 advance past an argument in the argument list. The values MODE, 31192 TYPE and NAMED describe that argument. Once this is done, the 31193 variable CUM is suitable for analyzing the _following_ argument 31194 with 'TARGET_FUNCTION_ARG', etc. 31195 31196 This hook need not do anything if the argument in question was 31197 passed on the stack. The compiler knows how to track the amount of 31198 stack space used for arguments without any special help. 31199 31200 -- Macro: FUNCTION_ARG_OFFSET (MODE, TYPE) 31201 If defined, a C expression that is the number of bytes to add to 31202 the offset of the argument passed in memory. This is needed for 31203 the SPU, which passes 'char' and 'short' arguments in the preferred 31204 slot that is in the middle of the quad word instead of starting at 31205 the top. 31206 31207 -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE) 31208 If defined, a C expression which determines whether, and in which 31209 direction, to pad out an argument with extra space. The value 31210 should be of type 'enum direction': either 'upward' to pad above 31211 the argument, 'downward' to pad below, or 'none' to inhibit 31212 padding. 31213 31214 The _amount_ of padding is not controlled by this macro, but by the 31215 target hook 'TARGET_FUNCTION_ARG_ROUND_BOUNDARY'. It is always 31216 just enough to reach the next multiple of that boundary. 31217 31218 This macro has a default definition which is right for most 31219 systems. For little-endian machines, the default is to pad upward. 31220 For big-endian machines, the default is to pad downward for an 31221 argument of constant size shorter than an 'int', and upward 31222 otherwise. 31223 31224 -- Macro: PAD_VARARGS_DOWN 31225 If defined, a C expression which determines whether the default 31226 implementation of va_arg will attempt to pad down before reading 31227 the next argument, if that argument is smaller than its aligned 31228 space as controlled by 'PARM_BOUNDARY'. If this macro is not 31229 defined, all such arguments are padded down if 'BYTES_BIG_ENDIAN' 31230 is true. 31231 31232 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 31233 Specify padding for the last element of a block move between 31234 registers and memory. FIRST is nonzero if this is the only 31235 element. Defining this macro allows better control of register 31236 function parameters on big-endian machines, without using 31237 'PARALLEL' rtl. In particular, 'MUST_PASS_IN_STACK' need not test 31238 padding and mode of types in registers, as there is no longer a 31239 "wrong" part of a register; For example, a three byte aggregate may 31240 be passed in the high part of a register if so required. 31241 31242 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY (machine_mode 31243 MODE, const_tree TYPE) 31244 This hook returns the alignment boundary, in bits, of an argument 31245 with the specified mode and type. The default hook returns 31246 'PARM_BOUNDARY' for all arguments. 31247 31248 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY 31249 (machine_mode MODE, const_tree TYPE) 31250 Normally, the size of an argument is rounded up to 'PARM_BOUNDARY', 31251 which is the default value for this hook. You can define this hook 31252 to return a different value if an argument size must be rounded to 31253 a larger value. 31254 31255 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 31256 A C expression that is nonzero if REGNO is the number of a hard 31257 register in which function arguments are sometimes passed. This 31258 does _not_ include implicit arguments such as the static chain and 31259 the structure-value address. On many machines, no registers can be 31260 used for this purpose since all function arguments are pushed on 31261 the stack. 31262 31263 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE) 31264 This hook should return true if parameter of type TYPE are passed 31265 as two scalar parameters. By default, GCC will attempt to pack 31266 complex arguments into the target's word size. Some ABIs require 31267 complex arguments to be split and treated as their individual 31268 components. For example, on AIX64, complex floats should be passed 31269 in a pair of floating point registers, even though a complex float 31270 would fit in one 64-bit floating point register. 31271 31272 The default value of this hook is 'NULL', which is treated as 31273 always false. 31274 31275 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 31276 This hook returns a type node for 'va_list' for the target. The 31277 default version of the hook returns 'void*'. 31278 31279 -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char **PNAME, 31280 tree *PTREE) 31281 This target hook is used in function 'c_common_nodes_and_builtins' 31282 to iterate through the target specific builtin types for va_list. 31283 The variable IDX is used as iterator. PNAME has to be a pointer to 31284 a 'const char *' and PTREE a pointer to a 'tree' typed variable. 31285 The arguments PNAME and PTREE are used to store the result of this 31286 macro and are set to the name of the va_list builtin type and its 31287 internal type. If the return value of this macro is zero, then 31288 there is no more element. Otherwise the IDX should be increased 31289 for the next call of this macro to iterate through all types. 31290 31291 -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL) 31292 This hook returns the va_list type of the calling convention 31293 specified by FNDECL. The default version of this hook returns 31294 'va_list_type_node'. 31295 31296 -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE) 31297 This hook returns the va_list type of the calling convention 31298 specified by the type of TYPE. If TYPE is not a valid va_list 31299 type, it returns 'NULL_TREE'. 31300 31301 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 31302 TYPE, gimple_seq *PRE_P, gimple_seq *POST_P) 31303 This hook performs target-specific gimplification of 'VA_ARG_EXPR'. 31304 The first two parameters correspond to the arguments to 'va_arg'; 31305 the latter two are as in 'gimplify.c:gimplify_expr'. 31306 31307 -- Target Hook: bool TARGET_VALID_POINTER_MODE (machine_mode MODE) 31308 Define this to return nonzero if the port can handle pointers with 31309 machine mode MODE. The default version of this hook returns true 31310 for both 'ptr_mode' and 'Pmode'. 31311 31312 -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (struct ao_ref *REF) 31313 Define this to return nonzero if the memory reference REF may alias 31314 with the system C library errno location. The default version of 31315 this hook assumes the system C library errno location is either a 31316 declaration of type int or accessed by dereferencing a pointer to 31317 int. 31318 31319 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (machine_mode MODE) 31320 Define this to return nonzero if the port is prepared to handle 31321 insns involving scalar mode MODE. For a scalar mode to be 31322 considered supported, all the basic arithmetic and comparisons must 31323 work. 31324 31325 The default version of this hook returns true for any mode required 31326 to handle the basic C types (as defined by the port). Included 31327 here are the double-word arithmetic supported by the code in 31328 'optabs.c'. 31329 31330 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE) 31331 Define this to return nonzero if the port is prepared to handle 31332 insns involving vector mode MODE. At the very least, it must have 31333 move patterns for this mode. 31334 31335 -- Target Hook: bool TARGET_ARRAY_MODE_SUPPORTED_P (machine_mode MODE, 31336 unsigned HOST_WIDE_INT NELEMS) 31337 Return true if GCC should try to use a scalar mode to store an 31338 array of NELEMS elements, given that each element has mode MODE. 31339 Returning true here overrides the usual 'MAX_FIXED_MODE' limit and 31340 allows GCC to use any defined integer mode. 31341 31342 One use of this hook is to support vector load and store operations 31343 that operate on several homogeneous vectors. For example, ARM NEON 31344 has operations like: 31345 31346 int8x8x3_t vld3_s8 (const int8_t *) 31347 31348 where the return type is defined as: 31349 31350 typedef struct int8x8x3_t 31351 { 31352 int8x8_t val[3]; 31353 } int8x8x3_t; 31354 31355 If this hook allows 'val' to have a scalar mode, then 'int8x8x3_t' 31356 can have the same mode. GCC can then store 'int8x8x3_t's in 31357 registers rather than forcing them onto the stack. 31358 31359 -- Target Hook: bool TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 31360 (machine_mode MODE) 31361 Define this to return nonzero if libgcc provides support for the 31362 floating-point mode MODE, which is known to pass 31363 'TARGET_SCALAR_MODE_SUPPORTED_P'. The default version of this hook 31364 returns true for all of 'SFmode', 'DFmode', 'XFmode' and 'TFmode', 31365 if such modes exist. 31366 31367 -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P 31368 (machine_mode MODE) 31369 Define this to return nonzero for machine modes for which the port 31370 has small register classes. If this target hook returns nonzero 31371 for a given MODE, the compiler will try to minimize the lifetime of 31372 registers in MODE. The hook may be called with 'VOIDmode' as 31373 argument. In this case, the hook is expected to return nonzero if 31374 it returns nonzero for any mode. 31375 31376 On some machines, it is risky to let hard registers live across 31377 arbitrary insns. Typically, these machines have instructions that 31378 require values to be in specific registers (like an accumulator), 31379 and reload will fail if the required hard register is used for 31380 another purpose across such an insn. 31381 31382 Passes before reload do not know which hard registers will be used 31383 in an instruction, but the machine modes of the registers set or 31384 used in the instruction are already known. And for some machines, 31385 register classes are small for, say, integer registers but not for 31386 floating point registers. For example, the AMD x86-64 architecture 31387 requires specific registers for the legacy x86 integer 31388 instructions, but there are many SSE registers for floating point 31389 operations. On such targets, a good strategy may be to return 31390 nonzero from this hook for 'INTEGRAL_MODE_P' machine modes but zero 31391 for the SSE register classes. 31392 31393 The default version of this hook returns false for any mode. It is 31394 always safe to redefine this hook to return with a nonzero value. 31395 But if you unnecessarily define it, you will reduce the amount of 31396 optimizations that can be performed in some cases. If you do not 31397 define this hook to return a nonzero value when it is required, the 31398 compiler will run out of spill registers and print a fatal error 31399 message. 31400 31401 31402File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 31403 3140417.9.8 How Scalar Function Values Are Returned 31405---------------------------------------------- 31406 31407This section discusses the macros that control returning scalars as 31408values--values that can fit in registers. 31409 31410 -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE, 31411 const_tree FN_DECL_OR_TYPE, bool OUTGOING) 31412 31413 Define this to return an RTX representing the place where a 31414 function returns or receives a value of data type RET_TYPE, a tree 31415 node representing a data type. FN_DECL_OR_TYPE is a tree node 31416 representing 'FUNCTION_DECL' or 'FUNCTION_TYPE' of a function being 31417 called. If OUTGOING is false, the hook should compute the register 31418 in which the caller will see the return value. Otherwise, the hook 31419 should return an RTX representing the place where a function 31420 returns a value. 31421 31422 On many machines, only 'TYPE_MODE (RET_TYPE)' is relevant. 31423 (Actually, on most machines, scalar values are returned in the same 31424 place regardless of mode.) The value of the expression is usually 31425 a 'reg' RTX for the hard register where the return value is stored. 31426 The value can also be a 'parallel' RTX, if the return value is in 31427 multiple places. See 'TARGET_FUNCTION_ARG' for an explanation of 31428 the 'parallel' form. Note that the callee will populate every 31429 location specified in the 'parallel', but if the first element of 31430 the 'parallel' contains the whole return value, callers will use 31431 that element as the canonical location and ignore the others. The 31432 m68k port uses this type of 'parallel' to return pointers in both 31433 '%a0' (the canonical location) and '%d0'. 31434 31435 If 'TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 31436 the same promotion rules specified in 'PROMOTE_MODE' if VALTYPE is 31437 a scalar type. 31438 31439 If the precise function being called is known, FUNC is a tree node 31440 ('FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 31441 makes it possible to use a different value-returning convention for 31442 specific functions when all their calls are known. 31443 31444 Some target machines have "register windows" so that the register 31445 in which a function returns its value is not the same as the one in 31446 which the caller sees the value. For such machines, you should 31447 return different RTX depending on OUTGOING. 31448 31449 'TARGET_FUNCTION_VALUE' is not used for return values with 31450 aggregate data types, because these are returned in another way. 31451 See 'TARGET_STRUCT_VALUE_RTX' and related macros, below. 31452 31453 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 31454 This macro has been deprecated. Use 'TARGET_FUNCTION_VALUE' for a 31455 new target instead. 31456 31457 -- Macro: LIBCALL_VALUE (MODE) 31458 A C expression to create an RTX representing the place where a 31459 library function returns a value of mode MODE. 31460 31461 Note that "library function" in this context means a compiler 31462 support routine, used to perform arithmetic, whose name is known 31463 specially by the compiler and was not mentioned in the C code being 31464 compiled. 31465 31466 -- Target Hook: rtx TARGET_LIBCALL_VALUE (machine_mode MODE, const_rtx 31467 FUN) 31468 Define this hook if the back-end needs to know the name of the 31469 libcall function in order to determine where the result should be 31470 returned. 31471 31472 The mode of the result is given by MODE and the name of the called 31473 library function is given by FUN. The hook should return an RTX 31474 representing the place where the library function result will be 31475 returned. 31476 31477 If this hook is not defined, then LIBCALL_VALUE will be used. 31478 31479 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 31480 A C expression that is nonzero if REGNO is the number of a hard 31481 register in which the values of called function may come back. 31482 31483 A register whose use for returning values is limited to serving as 31484 the second of a pair (for a value of type 'double', say) need not 31485 be recognized by this macro. So for most machines, this definition 31486 suffices: 31487 31488 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 31489 31490 If the machine has register windows, so that the caller and the 31491 called function use different registers for the return value, this 31492 macro should recognize only the caller's register numbers. 31493 31494 This macro has been deprecated. Use 31495 'TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead. 31496 31497 -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int 31498 REGNO) 31499 A target hook that return 'true' if REGNO is the number of a hard 31500 register in which the values of called function may come back. 31501 31502 A register whose use for returning values is limited to serving as 31503 the second of a pair (for a value of type 'double', say) need not 31504 be recognized by this target hook. 31505 31506 If the machine has register windows, so that the caller and the 31507 called function use different registers for the return value, this 31508 target hook should recognize only the caller's register numbers. 31509 31510 If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be 31511 used. 31512 31513 -- Macro: APPLY_RESULT_SIZE 31514 Define this macro if 'untyped_call' and 'untyped_return' need more 31515 space than is implied by 'FUNCTION_VALUE_REGNO_P' for saving and 31516 restoring an arbitrary return value. 31517 31518 -- Target Hook: bool TARGET_OMIT_STRUCT_RETURN_REG 31519 Normally, when a function returns a structure by memory, the 31520 address is passed as an invisible pointer argument, but the 31521 compiler also arranges to return the address from the function like 31522 it would a normal pointer return value. Define this to true if 31523 that behaviour is undesirable on your target. 31524 31525 -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE) 31526 This hook should return true if values of type TYPE are returned at 31527 the most significant end of a register (in other words, if they are 31528 padded at the least significant end). You can assume that TYPE is 31529 returned in a register; the caller is required to check this. 31530 31531 Note that the register provided by 'TARGET_FUNCTION_VALUE' must be 31532 able to hold the complete return value. For example, if a 1-, 2- 31533 or 3-byte structure is returned at the most significant end of a 31534 4-byte register, 'TARGET_FUNCTION_VALUE' should provide an 'SImode' 31535 rtx. 31536 31537 31538File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 31539 3154017.9.9 How Large Values Are Returned 31541------------------------------------ 31542 31543When a function value's mode is 'BLKmode' (and in some other cases), the 31544value is not returned according to 'TARGET_FUNCTION_VALUE' (*note Scalar 31545Return::). Instead, the caller passes the address of a block of memory 31546in which the value should be stored. This address is called the 31547"structure value address". 31548 31549 This section describes how to control returning structure values in 31550memory. 31551 31552 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE, 31553 const_tree FNTYPE) 31554 This target hook should return a nonzero value to say to return the 31555 function value in memory, just as large structures are always 31556 returned. Here TYPE will be the data type of the value, and FNTYPE 31557 will be the type of the function doing the returning, or 'NULL' for 31558 libcalls. 31559 31560 Note that values of mode 'BLKmode' must be explicitly handled by 31561 this function. Also, the option '-fpcc-struct-return' takes effect 31562 regardless of this macro. On most systems, it is possible to leave 31563 the hook undefined; this causes a default definition to be used, 31564 whose value is the constant 1 for 'BLKmode' values, and 0 31565 otherwise. 31566 31567 Do not use this hook to indicate that structures and unions should 31568 always be returned in memory. You should instead use 31569 'DEFAULT_PCC_STRUCT_RETURN' to indicate this. 31570 31571 -- Macro: DEFAULT_PCC_STRUCT_RETURN 31572 Define this macro to be 1 if all structure and union return values 31573 must be in memory. Since this results in slower code, this should 31574 be defined only if needed for compatibility with other compilers or 31575 with an ABI. If you define this macro to be 0, then the 31576 conventions used for structure and union return values are decided 31577 by the 'TARGET_RETURN_IN_MEMORY' target hook. 31578 31579 If not defined, this defaults to the value 1. 31580 31581 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 31582 This target hook should return the location of the structure value 31583 address (normally a 'mem' or 'reg'), or 0 if the address is passed 31584 as an "invisible" first argument. Note that FNDECL may be 'NULL', 31585 for libcalls. You do not need to define this target hook if the 31586 address is always passed as an "invisible" first argument. 31587 31588 On some architectures the place where the structure value address 31589 is found by the called function is not the same place that the 31590 caller put it. This can be due to register windows, or it could be 31591 because the function prologue moves it to a different place. 31592 INCOMING is '1' or '2' when the location is needed in the context 31593 of the called function, and '0' in the context of the caller. 31594 31595 If INCOMING is nonzero and the address is to be found on the stack, 31596 return a 'mem' which refers to the frame pointer. If INCOMING is 31597 '2', the result is being used to fetch the structure value address 31598 at the beginning of a function. If you need to emit adjusting 31599 code, you should do it at this point. 31600 31601 -- Macro: PCC_STATIC_STRUCT_RETURN 31602 Define this macro if the usual system convention on the target 31603 machine for returning structures and unions is for the called 31604 function to return the address of a static variable containing the 31605 value. 31606 31607 Do not define this if the usual system convention is for the caller 31608 to pass an address to the subroutine. 31609 31610 This macro has effect in '-fpcc-struct-return' mode, but it does 31611 nothing when you use '-freg-struct-return' mode. 31612 31613 -- Target Hook: machine_mode TARGET_GET_RAW_RESULT_MODE (int REGNO) 31614 This target hook returns the mode to be used when accessing raw 31615 return registers in '__builtin_return'. Define this macro if the 31616 value in REG_RAW_MODE is not correct. 31617 31618 -- Target Hook: machine_mode TARGET_GET_RAW_ARG_MODE (int REGNO) 31619 This target hook returns the mode to be used when accessing raw 31620 argument registers in '__builtin_apply_args'. Define this macro if 31621 the value in REG_RAW_MODE is not correct. 31622 31623 31624File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 31625 3162617.9.10 Caller-Saves Register Allocation 31627---------------------------------------- 31628 31629If you enable it, GCC can save registers around function calls. This 31630makes it possible to use call-clobbered registers to hold variables that 31631must live across calls. 31632 31633 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 31634 A C expression specifying which mode is required for saving NREGS 31635 of a pseudo-register in call-clobbered hard register REGNO. If 31636 REGNO is unsuitable for caller save, 'VOIDmode' should be returned. 31637 For most machines this macro need not be defined since GCC will 31638 select the smallest suitable mode. 31639 31640 31641File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 31642 3164317.9.11 Function Entry and Exit 31644------------------------------- 31645 31646This section describes the macros that output function entry 31647("prologue") and exit ("epilogue") code. 31648 31649 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE, 31650 HOST_WIDE_INT SIZE) 31651 If defined, a function that outputs the assembler code for entry to 31652 a function. The prologue is responsible for setting up the stack 31653 frame, initializing the frame pointer register, saving registers 31654 that must be saved, and allocating SIZE additional bytes of storage 31655 for the local variables. SIZE is an integer. FILE is a stdio 31656 stream to which the assembler code should be output. 31657 31658 The label for the beginning of the function need not be output by 31659 this macro. That has already been done when the macro is run. 31660 31661 To determine which registers to save, the macro can refer to the 31662 array 'regs_ever_live': element R is nonzero if hard register R is 31663 used anywhere within the function. This implies the function 31664 prologue should save register R, provided it is not one of the 31665 call-used registers. ('TARGET_ASM_FUNCTION_EPILOGUE' must likewise 31666 use 'regs_ever_live'.) 31667 31668 On machines that have "register windows", the function entry code 31669 does not save on the stack the registers that are in the windows, 31670 even if they are supposed to be preserved by function calls; 31671 instead it takes appropriate steps to "push" the register stack, if 31672 any non-call-used registers are used in the function. 31673 31674 On machines where functions may or may not have frame-pointers, the 31675 function entry code must vary accordingly; it must set up the frame 31676 pointer if one is wanted, and not otherwise. To determine whether 31677 a frame pointer is in wanted, the macro can refer to the variable 31678 'frame_pointer_needed'. The variable's value will be 1 at run time 31679 in a function that needs a frame pointer. *Note Elimination::. 31680 31681 The function entry code is responsible for allocating any stack 31682 space required for the function. This stack space consists of the 31683 regions listed below. In most cases, these regions are allocated 31684 in the order listed, with the last listed region closest to the top 31685 of the stack (the lowest address if 'STACK_GROWS_DOWNWARD' is 31686 defined, and the highest address if it is not defined). You can 31687 use a different order for a machine if doing so is more convenient 31688 or required for compatibility reasons. Except in cases where 31689 required by standard or by a debugger, there is no reason why the 31690 stack layout used by GCC need agree with that used by other 31691 compilers for a machine. 31692 31693 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 31694 If defined, a function that outputs assembler code at the end of a 31695 prologue. This should be used when the function prologue is being 31696 emitted as RTL, and you have some extra assembler that needs to be 31697 emitted. *Note prologue instruction pattern::. 31698 31699 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 31700 If defined, a function that outputs assembler code at the start of 31701 an epilogue. This should be used when the function epilogue is 31702 being emitted as RTL, and you have some extra assembler that needs 31703 to be emitted. *Note epilogue instruction pattern::. 31704 31705 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE, 31706 HOST_WIDE_INT SIZE) 31707 If defined, a function that outputs the assembler code for exit 31708 from a function. The epilogue is responsible for restoring the 31709 saved registers and stack pointer to their values when the function 31710 was called, and returning control to the caller. This macro takes 31711 the same arguments as the macro 'TARGET_ASM_FUNCTION_PROLOGUE', and 31712 the registers to restore are determined from 'regs_ever_live' and 31713 'CALL_USED_REGISTERS' in the same way. 31714 31715 On some machines, there is a single instruction that does all the 31716 work of returning from the function. On these machines, give that 31717 instruction the name 'return' and do not define the macro 31718 'TARGET_ASM_FUNCTION_EPILOGUE' at all. 31719 31720 Do not define a pattern named 'return' if you want the 31721 'TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 31722 switches to control whether return instructions or epilogues are 31723 used, define a 'return' pattern with a validity condition that 31724 tests the target switches appropriately. If the 'return' pattern's 31725 validity condition is false, epilogues will be used. 31726 31727 On machines where functions may or may not have frame-pointers, the 31728 function exit code must vary accordingly. Sometimes the code for 31729 these two cases is completely different. To determine whether a 31730 frame pointer is wanted, the macro can refer to the variable 31731 'frame_pointer_needed'. The variable's value will be 1 when 31732 compiling a function that needs a frame pointer. 31733 31734 Normally, 'TARGET_ASM_FUNCTION_PROLOGUE' and 31735 'TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 31736 The C variable 'current_function_is_leaf' is nonzero for such a 31737 function. *Note Leaf Functions::. 31738 31739 On some machines, some functions pop their arguments on exit while 31740 others leave that for the caller to do. For example, the 68020 31741 when given '-mrtd' pops arguments in functions that take a fixed 31742 number of arguments. 31743 31744 Your definition of the macro 'RETURN_POPS_ARGS' decides which 31745 functions pop their own arguments. 'TARGET_ASM_FUNCTION_EPILOGUE' 31746 needs to know what was decided. The number of bytes of the current 31747 function's arguments that this function should pop is available in 31748 'crtl->args.pops_args'. *Note Scalar Return::. 31749 31750 * A region of 'crtl->args.pretend_args_size' bytes of uninitialized 31751 space just underneath the first argument arriving on the stack. 31752 (This may not be at the very start of the allocated stack region if 31753 the calling sequence has pushed anything else since pushing the 31754 stack arguments. But usually, on such machines, nothing else has 31755 been pushed yet, because the function prologue itself does all the 31756 pushing.) This region is used on machines where an argument may be 31757 passed partly in registers and partly in memory, and, in some cases 31758 to support the features in '<stdarg.h>'. 31759 31760 * An area of memory used to save certain registers used by the 31761 function. The size of this area, which may also include space for 31762 such things as the return address and pointers to previous stack 31763 frames, is machine-specific and usually depends on which registers 31764 have been used in the function. Machines with register windows 31765 often do not require a save area. 31766 31767 * A region of at least SIZE bytes, possibly rounded up to an 31768 allocation boundary, to contain the local variables of the 31769 function. On some machines, this region and the save area may 31770 occur in the opposite order, with the save area closer to the top 31771 of the stack. 31772 31773 * Optionally, when 'ACCUMULATE_OUTGOING_ARGS' is defined, a region of 31774 'crtl->outgoing_args_size' bytes to be used for outgoing argument 31775 lists of the function. *Note Stack Arguments::. 31776 31777 -- Macro: EXIT_IGNORE_STACK 31778 Define this macro as a C expression that is nonzero if the return 31779 instruction or the function epilogue ignores the value of the stack 31780 pointer; in other words, if it is safe to delete an instruction to 31781 adjust the stack pointer before a return from the function. The 31782 default is 0. 31783 31784 Note that this macro's value is relevant only for functions for 31785 which frame pointers are maintained. It is never safe to delete a 31786 final stack adjustment in a function that has no frame pointer, and 31787 the compiler knows this regardless of 'EXIT_IGNORE_STACK'. 31788 31789 -- Macro: EPILOGUE_USES (REGNO) 31790 Define this macro as a C expression that is nonzero for registers 31791 that are used by the epilogue or the 'return' pattern. The stack 31792 and frame pointer registers are already assumed to be used as 31793 needed. 31794 31795 -- Macro: EH_USES (REGNO) 31796 Define this macro as a C expression that is nonzero for registers 31797 that are used by the exception handling mechanism, and so should be 31798 considered live on entry to an exception edge. 31799 31800 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 31801 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 31802 tree FUNCTION) 31803 A function that outputs the assembler code for a thunk function, 31804 used to implement C++ virtual function calls with multiple 31805 inheritance. The thunk acts as a wrapper around a virtual 31806 function, adjusting the implicit object parameter before handing 31807 control off to the real function. 31808 31809 First, emit code to add the integer DELTA to the location that 31810 contains the incoming first argument. Assume that this argument 31811 contains a pointer, and is the one used to pass the 'this' pointer 31812 in C++. This is the incoming argument _before_ the function 31813 prologue, e.g. '%o0' on a sparc. The addition must preserve the 31814 values of all other incoming arguments. 31815 31816 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 31817 be made after adding 'delta'. In particular, if P is the adjusted 31818 pointer, the following adjustment should be made: 31819 31820 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 31821 31822 After the additions, emit code to jump to FUNCTION, which is a 31823 'FUNCTION_DECL'. This is a direct pure jump, not a call, and does 31824 not touch the return address. Hence returning from FUNCTION will 31825 return to whoever called the current 'thunk'. 31826 31827 The effect must be as if FUNCTION had been called directly with the 31828 adjusted first argument. This macro is responsible for emitting 31829 all of the code for a thunk function; 31830 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' 31831 are not invoked. 31832 31833 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 31834 been extracted from it.) It might possibly be useful on some 31835 targets, but probably not. 31836 31837 If you do not define this macro, the target-independent code in the 31838 C++ front end will generate a less efficient heavyweight thunk that 31839 calls FUNCTION instead of jumping to it. The generic approach does 31840 not support varargs. 31841 31842 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree 31843 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 31844 const_tree FUNCTION) 31845 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would be 31846 able to output the assembler code for the thunk function specified 31847 by the arguments it is passed, and false otherwise. In the latter 31848 case, the generic approach will be used by the C++ front end, with 31849 the limitations previously exposed. 31850 31851 31852File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 31853 3185417.9.12 Generating Code for Profiling 31855------------------------------------- 31856 31857These macros will help you generate code for profiling. 31858 31859 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 31860 A C statement or compound statement to output to FILE some 31861 assembler code to call the profiling subroutine 'mcount'. 31862 31863 The details of how 'mcount' expects to be called are determined by 31864 your operating system environment, not by GCC. To figure them out, 31865 compile a small program for profiling using the system's installed 31866 C compiler and look at the assembler code that results. 31867 31868 Older implementations of 'mcount' expect the address of a counter 31869 variable to be loaded into some register. The name of this 31870 variable is 'LP' followed by the number LABELNO, so you would 31871 generate the name using 'LP%d' in a 'fprintf'. 31872 31873 -- Macro: PROFILE_HOOK 31874 A C statement or compound statement to output to FILE some assembly 31875 code to call the profiling subroutine 'mcount' even the target does 31876 not support profiling. 31877 31878 -- Macro: NO_PROFILE_COUNTERS 31879 Define this macro to be an expression with a nonzero value if the 31880 'mcount' subroutine on your system does not need a counter variable 31881 allocated for each function. This is true for almost all modern 31882 implementations. If you define this macro, you must not use the 31883 LABELNO argument to 'FUNCTION_PROFILER'. 31884 31885 -- Macro: PROFILE_BEFORE_PROLOGUE 31886 Define this macro if the code for function profiling should come 31887 before the function prologue. Normally, the profiling code comes 31888 after. 31889 31890 -- Target Hook: bool TARGET_KEEP_LEAF_WHEN_PROFILED (void) 31891 This target hook returns true if the target wants the leaf flag for 31892 the current function to stay true even if it calls mcount. This 31893 might make sense for targets using the leaf flag only to determine 31894 whether a stack frame needs to be generated or not and for which 31895 the call to mcount is generated before the function prologue. 31896 31897 31898File: gccint.info, Node: Tail Calls, Next: Stack Smashing Protection, Prev: Profiling, Up: Stack and Calling 31899 3190017.9.13 Permitting tail calls 31901----------------------------- 31902 31903 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 31904 EXP) 31905 True if it is OK to do sibling call optimization for the specified 31906 call expression EXP. DECL will be the called function, or 'NULL' 31907 if this is an indirect call. 31908 31909 It is not uncommon for limitations of calling conventions to 31910 prevent tail calls to functions outside the current unit of 31911 translation, or during PIC compilation. The hook is used to 31912 enforce these restrictions, as the 'sibcall' md pattern can not 31913 fail, or fall over to a "normal" call. The criteria for successful 31914 sibling call optimization may vary greatly between different 31915 architectures. 31916 31917 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS) 31918 Add any hard registers to REGS that are live on entry to the 31919 function. This hook only needs to be defined to provide registers 31920 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 31921 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 31922 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, FRAME_POINTER_REGNUM, 31923 EH_USES, FRAME_POINTER_REGNUM, ARG_POINTER_REGNUM, and the 31924 PIC_OFFSET_TABLE_REGNUM. 31925 31926 -- Target Hook: void TARGET_SET_UP_BY_PROLOGUE (struct 31927 hard_reg_set_container *) 31928 This hook should add additional registers that are computed by the 31929 prologue to the hard regset for shrink-wrapping optimization 31930 purposes. 31931 31932 -- Target Hook: bool TARGET_WARN_FUNC_RETURN (tree) 31933 True if a function's return statements should be checked for 31934 matching the function's return type. This includes checking for 31935 falling off the end of a non-void function. Return false if no 31936 such check should be made. 31937 31938 31939File: gccint.info, Node: Stack Smashing Protection, Next: Miscellaneous Register Hooks, Prev: Tail Calls, Up: Stack and Calling 31940 3194117.9.14 Stack smashing protection 31942--------------------------------- 31943 31944 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 31945 This hook returns a 'DECL' node for the external variable to use 31946 for the stack protection guard. This variable is initialized by 31947 the runtime to some random value and is used to initialize the 31948 guard value that is placed at the top of the local stack frame. 31949 The type of this variable must be 'ptr_type_node'. 31950 31951 The default version of this hook creates a variable called 31952 '__stack_chk_guard', which is normally defined in 'libgcc2.c'. 31953 31954 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 31955 This hook returns a 'CALL_EXPR' that alerts the runtime that the 31956 stack protect guard variable has been modified. This expression 31957 should involve a call to a 'noreturn' function. 31958 31959 The default version of this hook invokes a function called 31960 '__stack_chk_fail', taking no arguments. This function is normally 31961 defined in 'libgcc2.c'. 31962 31963 -- Common Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT, 31964 struct gcc_options *OPTS) 31965 Whether this target supports splitting the stack when the options 31966 described in OPTS have been passed. This is called after options 31967 have been parsed, so the target may reject splitting the stack in 31968 some configurations. The default version of this hook returns 31969 false. If REPORT is true, this function may issue a warning or 31970 error; if REPORT is false, it must simply return a value 31971 31972 31973File: gccint.info, Node: Miscellaneous Register Hooks, Prev: Stack Smashing Protection, Up: Stack and Calling 31974 3197517.9.15 Miscellaneous register hooks 31976------------------------------------ 31977 31978 -- Target Hook: bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS 31979 Set to true if each call that binds to a local definition 31980 explicitly clobbers or sets all non-fixed registers modified by 31981 performing the call. That is, by the call pattern itself, or by 31982 code that might be inserted by the linker (e.g. stubs, veneers, 31983 branch islands), but not including those modifiable by the callee. 31984 The affected registers may be mentioned explicitly in the call 31985 pattern, or included as clobbers in CALL_INSN_FUNCTION_USAGE. The 31986 default version of this hook is set to false. The purpose of this 31987 hook is to enable the fipa-ra optimization. 31988 31989 31990File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 31991 3199217.10 Implementing the Varargs Macros 31993===================================== 31994 31995GCC comes with an implementation of '<varargs.h>' and '<stdarg.h>' that 31996work without change on machines that pass arguments on the stack. Other 31997machines require their own implementations of varargs, and the two 31998machine independent header files must have conditionals to include it. 31999 32000 ISO '<stdarg.h>' differs from traditional '<varargs.h>' mainly in the 32001calling convention for 'va_start'. The traditional implementation takes 32002just one argument, which is the variable in which to store the argument 32003pointer. The ISO implementation of 'va_start' takes an additional 32004second argument. The user is supposed to write the last named argument 32005of the function here. 32006 32007 However, 'va_start' should not use this argument. The way to find the 32008end of the named arguments is with the built-in functions described 32009below. 32010 32011 -- Macro: __builtin_saveregs () 32012 Use this built-in function to save the argument registers in memory 32013 so that the varargs mechanism can access them. Both ISO and 32014 traditional versions of 'va_start' must use '__builtin_saveregs', 32015 unless you use 'TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 32016 32017 On some machines, '__builtin_saveregs' is open-coded under the 32018 control of the target hook 'TARGET_EXPAND_BUILTIN_SAVEREGS'. On 32019 other machines, it calls a routine written in assembler language, 32020 found in 'libgcc2.c'. 32021 32022 Code generated for the call to '__builtin_saveregs' appears at the 32023 beginning of the function, as opposed to where the call to 32024 '__builtin_saveregs' is written, regardless of what the code is. 32025 This is because the registers must be saved before the function 32026 starts to use them for its own purposes. 32027 32028 -- Macro: __builtin_next_arg (LASTARG) 32029 This builtin returns the address of the first anonymous stack 32030 argument, as type 'void *'. If 'ARGS_GROW_DOWNWARD', it returns 32031 the address of the location above the first anonymous stack 32032 argument. Use it in 'va_start' to initialize the pointer for 32033 fetching arguments from the stack. Also use it in 'va_start' to 32034 verify that the second parameter LASTARG is the last named argument 32035 of the current function. 32036 32037 -- Macro: __builtin_classify_type (OBJECT) 32038 Since each machine has its own conventions for which data types are 32039 passed in which kind of register, your implementation of 'va_arg' 32040 has to embody these conventions. The easiest way to categorize the 32041 specified data type is to use '__builtin_classify_type' together 32042 with 'sizeof' and '__alignof__'. 32043 32044 '__builtin_classify_type' ignores the value of OBJECT, considering 32045 only its data type. It returns an integer describing what kind of 32046 type that is--integer, floating, pointer, structure, and so on. 32047 32048 The file 'typeclass.h' defines an enumeration that you can use to 32049 interpret the values of '__builtin_classify_type'. 32050 32051 These machine description macros help implement varargs: 32052 32053 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 32054 If defined, this hook produces the machine-specific code for a call 32055 to '__builtin_saveregs'. This code will be moved to the very 32056 beginning of the function, before any parameter access are made. 32057 The return value of this function should be an RTX that contains 32058 the value to use as the return of '__builtin_saveregs'. 32059 32060 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t 32061 ARGS_SO_FAR, machine_mode MODE, tree TYPE, int 32062 *PRETEND_ARGS_SIZE, int SECOND_TIME) 32063 This target hook offers an alternative to using 32064 '__builtin_saveregs' and defining the hook 32065 'TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 32066 register arguments into the stack so that all the arguments appear 32067 to have been passed consecutively on the stack. Once this is done, 32068 you can use the standard implementation of varargs that works for 32069 machines that pass all their arguments on the stack. 32070 32071 The argument ARGS_SO_FAR points to the 'CUMULATIVE_ARGS' data 32072 structure, containing the values that are obtained after processing 32073 the named arguments. The arguments MODE and TYPE describe the last 32074 named argument--its machine mode and its data type as a tree node. 32075 32076 The target hook should do two things: first, push onto the stack 32077 all the argument registers _not_ used for the named arguments, and 32078 second, store the size of the data thus pushed into the 32079 'int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 32080 that you store here will serve as additional offset for setting up 32081 the stack frame. 32082 32083 Because you must generate code to push the anonymous arguments at 32084 compile time without knowing their data types, 32085 'TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 32086 have just a single category of argument register and use it 32087 uniformly for all data types. 32088 32089 If the argument SECOND_TIME is nonzero, it means that the arguments 32090 of the function are being analyzed for the second time. This 32091 happens for an inline function, which is not actually compiled 32092 until the end of the source file. The hook 32093 'TARGET_SETUP_INCOMING_VARARGS' should not generate any 32094 instructions in this case. 32095 32096 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t 32097 CA) 32098 Define this hook to return 'true' if the location where a function 32099 argument is passed depends on whether or not it is a named 32100 argument. 32101 32102 This hook controls how the NAMED argument to 'TARGET_FUNCTION_ARG' 32103 is set for varargs and stdarg functions. If this hook returns 32104 'true', the NAMED argument is always true for named arguments, and 32105 false for unnamed arguments. If it returns 'false', but 32106 'TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns 'true', then all 32107 arguments are treated as named. Otherwise, all named arguments 32108 except the last are treated as named. 32109 32110 You need not define this hook if it always returns 'false'. 32111 32112 -- Target Hook: void TARGET_CALL_ARGS (rtx, TREE) 32113 While generating RTL for a function call, this target hook is 32114 invoked once for each argument passed to the function, either a 32115 register returned by 'TARGET_FUNCTION_ARG' or a memory location. 32116 It is called just before the point where argument registers are 32117 stored. The type of the function to be called is also passed as 32118 the second argument; it is 'NULL_TREE' for libcalls. The 32119 'TARGET_END_CALL_ARGS' hook is invoked just after the code to copy 32120 the return reg has been emitted. This functionality can be used to 32121 perform special setup of call argument registers if a target needs 32122 it. For functions without arguments, the hook is called once with 32123 'pc_rtx' passed instead of an argument register. Most ports do not 32124 need to implement anything for this hook. 32125 32126 -- Target Hook: void TARGET_END_CALL_ARGS (void) 32127 This target hook is invoked while generating RTL for a function 32128 call, just after the point where the return reg is copied into a 32129 pseudo. It signals that all the call argument and return registers 32130 for the just emitted call are now no longer in use. Most ports do 32131 not need to implement anything for this hook. 32132 32133 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 32134 (cumulative_args_t CA) 32135 If you need to conditionally change ABIs so that one works with 32136 'TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 32137 'TARGET_SETUP_INCOMING_VARARGS' nor 'TARGET_STRICT_ARGUMENT_NAMING' 32138 was defined, then define this hook to return 'true' if 32139 'TARGET_SETUP_INCOMING_VARARGS' is used, 'false' otherwise. 32140 Otherwise, you should not define this hook. 32141 32142 -- Target Hook: rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx SLOT, rtx ARG, rtx 32143 SLOT_NO) 32144 This hook is used by expand pass to emit insn to load bounds of ARG 32145 passed in SLOT. Expand pass uses this hook in case bounds of ARG 32146 are not passed in register. If SLOT is a memory, then bounds are 32147 loaded as for regular pointer loaded from memory. If SLOT is not a 32148 memory then SLOT_NO is an integer constant holding number of the 32149 target dependent special slot which should be used to obtain 32150 bounds. Hook returns RTX holding loaded bounds. 32151 32152 -- Target Hook: void TARGET_STORE_BOUNDS_FOR_ARG (rtx ARG, rtx SLOT, 32153 rtx BOUNDS, rtx SLOT_NO) 32154 This hook is used by expand pass to emit insns to store BOUNDS of 32155 ARG passed in SLOT. Expand pass uses this hook in case BOUNDS of 32156 ARG are not passed in register. If SLOT is a memory, then BOUNDS 32157 are stored as for regular pointer stored in memory. If SLOT is not 32158 a memory then SLOT_NO is an integer constant holding number of the 32159 target dependent special slot which should be used to store BOUNDS. 32160 32161 -- Target Hook: rtx TARGET_LOAD_RETURNED_BOUNDS (rtx SLOT) 32162 This hook is used by expand pass to emit insn to load bounds 32163 returned by function call in SLOT. Hook returns RTX holding loaded 32164 bounds. 32165 32166 -- Target Hook: void TARGET_STORE_RETURNED_BOUNDS (rtx SLOT, rtx 32167 BOUNDS) 32168 This hook is used by expand pass to emit insn to store BOUNDS 32169 returned by function call into SLOT. 32170 32171 -- Target Hook: rtx TARGET_CHKP_FUNCTION_VALUE_BOUNDS (const_tree 32172 RET_TYPE, const_tree FN_DECL_OR_TYPE, bool OUTGOING) 32173 Define this to return an RTX representing the place where a 32174 function returns bounds for returned pointers. Arguments meaning 32175 is similar to 'TARGET_FUNCTION_VALUE'. 32176 32177 -- Target Hook: void TARGET_SETUP_INCOMING_VARARG_BOUNDS 32178 (cumulative_args_t ARGS_SO_FAR, enum machine_mode MODE, tree 32179 TYPE, int *PRETEND_ARGS_SIZE, int SECOND_TIME) 32180 Use it to store bounds for anonymous register arguments stored into 32181 the stack. Arguments meaning is similar to 32182 'TARGET_SETUP_INCOMING_VARARGS'. 32183 32184 32185File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 32186 3218717.11 Trampolines for Nested Functions 32188====================================== 32189 32190A "trampoline" is a small piece of code that is created at run time when 32191the address of a nested function is taken. It normally resides on the 32192stack, in the stack frame of the containing function. These macros tell 32193GCC how to generate code to allocate and initialize a trampoline. 32194 32195 The instructions in the trampoline must do two things: load a constant 32196address into the static chain register, and jump to the real address of 32197the nested function. On CISC machines such as the m68k, this requires 32198two instructions, a move immediate and a jump. Then the two addresses 32199exist in the trampoline as word-long immediate operands. On RISC 32200machines, it is often necessary to load each address into a register in 32201two parts. Then pieces of each address form separate immediate 32202operands. 32203 32204 The code generated to initialize the trampoline must store the variable 32205parts--the static chain value and the function address--into the 32206immediate operands of the instructions. On a CISC machine, this is 32207simply a matter of copying each address to a memory reference at the 32208proper offset from the start of the trampoline. On a RISC machine, it 32209may be necessary to take out pieces of the address and store them 32210separately. 32211 32212 -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F) 32213 This hook is called by 'assemble_trampoline_template' to output, on 32214 the stream F, assembler code for a block of data that contains the 32215 constant parts of a trampoline. This code should not include a 32216 label--the label is taken care of automatically. 32217 32218 If you do not define this hook, it means no template is needed for 32219 the target. Do not define this hook on systems where the block 32220 move code to copy the trampoline into place would be larger than 32221 the code to generate it on the spot. 32222 32223 -- Macro: TRAMPOLINE_SECTION 32224 Return the section into which the trampoline template is to be 32225 placed (*note Sections::). The default value is 32226 'readonly_data_section'. 32227 32228 -- Macro: TRAMPOLINE_SIZE 32229 A C expression for the size in bytes of the trampoline, as an 32230 integer. 32231 32232 -- Macro: TRAMPOLINE_ALIGNMENT 32233 Alignment required for trampolines, in bits. 32234 32235 If you don't define this macro, the value of 'FUNCTION_ALIGNMENT' 32236 is used for aligning trampolines. 32237 32238 -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL, 32239 rtx STATIC_CHAIN) 32240 This hook is called to initialize a trampoline. M_TRAMP is an RTX 32241 for the memory block for the trampoline; FNDECL is the 32242 'FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX for 32243 the static chain value that should be passed to the function when 32244 it is called. 32245 32246 If the target defines 'TARGET_ASM_TRAMPOLINE_TEMPLATE', then the 32247 first thing this hook should do is emit a block move into M_TRAMP 32248 from the memory block returned by 'assemble_trampoline_template'. 32249 Note that the block move need only cover the constant parts of the 32250 trampoline. If the target isolates the variable parts of the 32251 trampoline to the end, not all 'TRAMPOLINE_SIZE' bytes need be 32252 copied. 32253 32254 If the target requires any other actions, such as flushing caches 32255 or enabling stack execution, these actions should be performed 32256 after initializing the trampoline proper. 32257 32258 -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR) 32259 This hook should perform any machine-specific adjustment in the 32260 address of the trampoline. Its argument contains the address of 32261 the memory block that was passed to 'TARGET_TRAMPOLINE_INIT'. In 32262 case the address to be used for a function call should be different 32263 from the address at which the template was stored, the different 32264 address should be returned; otherwise ADDR should be returned 32265 unchanged. If this hook is not defined, ADDR will be used for 32266 function calls. 32267 32268 Implementing trampolines is difficult on many machines because they 32269have separate instruction and data caches. Writing into a stack 32270location fails to clear the memory in the instruction cache, so when the 32271program jumps to that location, it executes the old contents. 32272 32273 Here are two possible solutions. One is to clear the relevant parts of 32274the instruction cache whenever a trampoline is set up. The other is to 32275make all trampolines identical, by having them jump to a standard 32276subroutine. The former technique makes trampoline execution faster; the 32277latter makes initialization faster. 32278 32279 To clear the instruction cache when a trampoline is initialized, define 32280the following macro. 32281 32282 -- Macro: CLEAR_INSN_CACHE (BEG, END) 32283 If defined, expands to a C expression clearing the _instruction 32284 cache_ in the specified interval. The definition of this macro 32285 would typically be a series of 'asm' statements. Both BEG and END 32286 are both pointer expressions. 32287 32288 To use a standard subroutine, define the following macro. In addition, 32289you must make sure that the instructions in a trampoline fill an entire 32290cache line with identical instructions, or else ensure that the 32291beginning of the trampoline code is always aligned at the same point in 32292its cache line. Look in 'm68k.h' as a guide. 32293 32294 -- Macro: TRANSFER_FROM_TRAMPOLINE 32295 Define this macro if trampolines need a special subroutine to do 32296 their work. The macro should expand to a series of 'asm' 32297 statements which will be compiled with GCC. They go in a library 32298 function named '__transfer_from_trampoline'. 32299 32300 If you need to avoid executing the ordinary prologue code of a 32301 compiled C function when you jump to the subroutine, you can do so 32302 by placing a special label of your own in the assembler code. Use 32303 one 'asm' statement to generate an assembler label, and another to 32304 make the label global. Then trampolines can use that label to jump 32305 directly to your special assembler code. 32306 32307 32308File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 32309 3231017.12 Implicit Calls to Library Routines 32311======================================== 32312 32313Here is an explanation of implicit calls to library routines. 32314 32315 -- Macro: DECLARE_LIBRARY_RENAMES 32316 This macro, if defined, should expand to a piece of C code that 32317 will get expanded when compiling functions for libgcc.a. It can be 32318 used to provide alternate names for GCC's internal library 32319 functions if there are ABI-mandated names that the compiler should 32320 provide. 32321 32322 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 32323 This hook should declare additional library routines or rename 32324 existing ones, using the functions 'set_optab_libfunc' and 32325 'init_one_libfunc' defined in 'optabs.c'. 'init_optabs' calls this 32326 macro after initializing all the normal library routines. 32327 32328 The default is to do nothing. Most ports don't need to define this 32329 hook. 32330 32331 -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX 32332 If false (the default), internal library routines start with two 32333 underscores. If set to true, these routines start with '__gnu_' 32334 instead. E.g., '__muldi3' changes to '__gnu_muldi3'. This 32335 currently only affects functions defined in 'libgcc2.c'. If this 32336 is set to true, the 'tm.h' file must also '#define 32337 LIBGCC2_GNU_PREFIX'. 32338 32339 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 32340 This macro should return 'true' if the library routine that 32341 implements the floating point comparison operator COMPARISON in 32342 mode MODE will return a boolean, and FALSE if it will return a 32343 tristate. 32344 32345 GCC's own floating point libraries return tristates from the 32346 comparison operators, so the default returns false always. Most 32347 ports don't need to define this macro. 32348 32349 -- Macro: TARGET_LIB_INT_CMP_BIASED 32350 This macro should evaluate to 'true' if the integer comparison 32351 functions (like '__cmpdi2') return 0 to indicate that the first 32352 operand is smaller than the second, 1 to indicate that they are 32353 equal, and 2 to indicate that the first operand is greater than the 32354 second. If this macro evaluates to 'false' the comparison 32355 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 32356 target uses the routines in 'libgcc.a', you do not need to define 32357 this macro. 32358 32359 -- Macro: TARGET_HAS_NO_HW_DIVIDE 32360 This macro should be defined if the target has no hardware divide 32361 instructions. If this macro is defined, GCC will use an algorithm 32362 which make use of simple logical and arithmetic operations for 32363 64-bit division. If the macro is not defined, GCC will use an 32364 algorithm which make use of a 64-bit by 32-bit divide primitive. 32365 32366 -- Macro: TARGET_EDOM 32367 The value of 'EDOM' on the target machine, as a C integer constant 32368 expression. If you don't define this macro, GCC does not attempt 32369 to deposit the value of 'EDOM' into 'errno' directly. Look in 32370 '/usr/include/errno.h' to find the value of 'EDOM' on your system. 32371 32372 If you do not define 'TARGET_EDOM', then compiled code reports 32373 domain errors by calling the library function and letting it report 32374 the error. If mathematical functions on your system use 'matherr' 32375 when there is an error, then you should leave 'TARGET_EDOM' 32376 undefined so that 'matherr' is used normally. 32377 32378 -- Macro: GEN_ERRNO_RTX 32379 Define this macro as a C expression to create an rtl expression 32380 that refers to the global "variable" 'errno'. (On certain systems, 32381 'errno' may not actually be a variable.) If you don't define this 32382 macro, a reasonable default is used. 32383 32384 -- Target Hook: bool TARGET_LIBC_HAS_FUNCTION (enum function_class 32385 FN_CLASS) 32386 This hook determines whether a function from a class of functions 32387 FN_CLASS is present at the runtime. 32388 32389 -- Macro: NEXT_OBJC_RUNTIME 32390 Set this macro to 1 to use the "NeXT" Objective-C message sending 32391 conventions by default. This calling convention involves passing 32392 the object, the selector and the method arguments all at once to 32393 the method-lookup library function. This is the usual setting when 32394 targeting Darwin/Mac OS X systems, which have the NeXT runtime 32395 installed. 32396 32397 If the macro is set to 0, the "GNU" Objective-C message sending 32398 convention will be used by default. This convention passes just 32399 the object and the selector to the method-lookup function, which 32400 returns a pointer to the method. 32401 32402 In either case, it remains possible to select code-generation for 32403 the alternate scheme, by means of compiler command line switches. 32404 32405 32406File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 32407 3240817.13 Addressing Modes 32409====================== 32410 32411This is about addressing modes. 32412 32413 -- Macro: HAVE_PRE_INCREMENT 32414 -- Macro: HAVE_PRE_DECREMENT 32415 -- Macro: HAVE_POST_INCREMENT 32416 -- Macro: HAVE_POST_DECREMENT 32417 A C expression that is nonzero if the machine supports 32418 pre-increment, pre-decrement, post-increment, or post-decrement 32419 addressing respectively. 32420 32421 -- Macro: HAVE_PRE_MODIFY_DISP 32422 -- Macro: HAVE_POST_MODIFY_DISP 32423 A C expression that is nonzero if the machine supports pre- or 32424 post-address side-effect generation involving constants other than 32425 the size of the memory operand. 32426 32427 -- Macro: HAVE_PRE_MODIFY_REG 32428 -- Macro: HAVE_POST_MODIFY_REG 32429 A C expression that is nonzero if the machine supports pre- or 32430 post-address side-effect generation involving a register 32431 displacement. 32432 32433 -- Macro: CONSTANT_ADDRESS_P (X) 32434 A C expression that is 1 if the RTX X is a constant which is a 32435 valid address. On most machines the default definition of 32436 '(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable, 32437 but a few machines are more restrictive as to which constant 32438 addresses are supported. 32439 32440 -- Macro: CONSTANT_P (X) 32441 'CONSTANT_P', which is defined by target-independent code, accepts 32442 integer-values expressions whose values are not explicitly known, 32443 such as 'symbol_ref', 'label_ref', and 'high' expressions and 32444 'const' arithmetic expressions, in addition to 'const_int' and 32445 'const_double' expressions. 32446 32447 -- Macro: MAX_REGS_PER_ADDRESS 32448 A number, the maximum number of registers that can appear in a 32449 valid memory address. Note that it is up to you to specify a value 32450 equal to the maximum number that 'TARGET_LEGITIMATE_ADDRESS_P' 32451 would ever accept. 32452 32453 -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (machine_mode MODE, 32454 rtx X, bool STRICT) 32455 A function that returns whether X (an RTX) is a legitimate memory 32456 address on the target machine for a memory operand of mode MODE. 32457 32458 Legitimate addresses are defined in two variants: a strict variant 32459 and a non-strict one. The STRICT parameter chooses which variant 32460 is desired by the caller. 32461 32462 The strict variant is used in the reload pass. It must be defined 32463 so that any pseudo-register that has not been allocated a hard 32464 register is considered a memory reference. This is because in 32465 contexts where some kind of register is required, a pseudo-register 32466 with no hard register must be rejected. For non-hard registers, 32467 the strict variant should look up the 'reg_renumber' array; it 32468 should then proceed using the hard register number in the array, or 32469 treat the pseudo as a memory reference if the array holds '-1'. 32470 32471 The non-strict variant is used in other passes. It must be defined 32472 to accept all pseudo-registers in every context where some kind of 32473 register is required. 32474 32475 Normally, constant addresses which are the sum of a 'symbol_ref' 32476 and an integer are stored inside a 'const' RTX to mark them as 32477 constant. Therefore, there is no need to recognize such sums 32478 specifically as legitimate addresses. Normally you would simply 32479 recognize any 'const' as legitimate. 32480 32481 Usually 'PRINT_OPERAND_ADDRESS' is not prepared to handle constant 32482 sums that are not marked with 'const'. It assumes that a naked 32483 'plus' indicates indexing. If so, then you _must_ reject such 32484 naked constant sums as illegitimate addresses, so that none of them 32485 will be given to 'PRINT_OPERAND_ADDRESS'. 32486 32487 On some machines, whether a symbolic address is legitimate depends 32488 on the section that the address refers to. On these machines, 32489 define the target hook 'TARGET_ENCODE_SECTION_INFO' to store the 32490 information into the 'symbol_ref', and then check for it here. 32491 When you see a 'const', you will have to look inside it to find the 32492 'symbol_ref' in order to determine the section. *Note Assembler 32493 Format::. 32494 32495 Some ports are still using a deprecated legacy substitute for this 32496 hook, the 'GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this 32497 syntax: 32498 32499 #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 32500 32501 and should 'goto LABEL' if the address X is a valid address on the 32502 target machine for a memory operand of mode MODE. 32503 32504 Compiler source files that want to use the strict variant of this 32505 macro define the macro 'REG_OK_STRICT'. You should use an '#ifdef 32506 REG_OK_STRICT' conditional to define the strict variant in that 32507 case and the non-strict variant otherwise. 32508 32509 Using the hook is usually simpler because it limits the number of 32510 files that are recompiled when changes are made. 32511 32512 -- Macro: TARGET_MEM_CONSTRAINT 32513 A single character to be used instead of the default ''m'' 32514 character for general memory addresses. This defines the 32515 constraint letter which matches the memory addresses accepted by 32516 'TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to 32517 support new address formats in your back end without changing the 32518 semantics of the ''m'' constraint. This is necessary in order to 32519 preserve functionality of inline assembly constructs using the 32520 ''m'' constraint. 32521 32522 -- Macro: FIND_BASE_TERM (X) 32523 A C expression to determine the base term of address X, or to 32524 provide a simplified version of X from which 'alias.c' can easily 32525 find the base term. This macro is used in only two places: 32526 'find_base_value' and 'find_base_term' in 'alias.c'. 32527 32528 It is always safe for this macro to not be defined. It exists so 32529 that alias analysis can understand machine-dependent addresses. 32530 32531 The typical use of this macro is to handle addresses containing a 32532 label_ref or symbol_ref within an UNSPEC. 32533 32534 -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, 32535 machine_mode MODE) 32536 This hook is given an invalid memory address X for an operand of 32537 mode MODE and should try to return a valid memory address. 32538 32539 X will always be the result of a call to 'break_out_memory_refs', 32540 and OLDX will be the operand that was given to that function to 32541 produce X. 32542 32543 The code of the hook should not alter the substructure of X. If it 32544 transforms X into a more legitimate form, it should return the new 32545 X. 32546 32547 It is not necessary for this hook to come up with a legitimate 32548 address, with the exception of native TLS addresses (*note Emulated 32549 TLS::). The compiler has standard ways of doing so in all cases. 32550 In fact, if the target supports only emulated TLS, it is safe to 32551 omit this hook or make it return X if it cannot find a valid way to 32552 legitimize the address. But often a machine-dependent strategy can 32553 generate better code. 32554 32555 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 32556 WIN) 32557 A C compound statement that attempts to replace X, which is an 32558 address that needs reloading, with a valid memory address for an 32559 operand of mode MODE. WIN will be a C statement label elsewhere in 32560 the code. It is not necessary to define this macro, but it might 32561 be useful for performance reasons. 32562 32563 For example, on the i386, it is sometimes possible to use a single 32564 reload register instead of two by reloading a sum of two pseudo 32565 registers into a register. On the other hand, for number of RISC 32566 processors offsets are limited so that often an intermediate 32567 address needs to be generated in order to address a stack slot. By 32568 defining 'LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 32569 intermediate addresses generated for adjacent some stack slots can 32570 be made identical, and thus be shared. 32571 32572 _Note_: This macro should be used with caution. It is necessary to 32573 know something of how reload works in order to effectively use 32574 this, and it is quite easy to produce macros that build in too much 32575 knowledge of reload internals. 32576 32577 _Note_: This macro must be able to reload an address created by a 32578 previous invocation of this macro. If it fails to handle such 32579 addresses then the compiler may generate incorrect code or abort. 32580 32581 The macro definition should use 'push_reload' to indicate parts 32582 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 32583 suitable to be passed unaltered to 'push_reload'. 32584 32585 The code generated by this macro must not alter the substructure of 32586 X. If it transforms X into a more legitimate form, it should 32587 assign X (which will always be a C variable) a new value. This 32588 also applies to parts that you change indirectly by calling 32589 'push_reload'. 32590 32591 The macro definition may use 'strict_memory_address_p' to test if 32592 the address has become legitimate. 32593 32594 If you want to change only a part of X, one standard way of doing 32595 this is to use 'copy_rtx'. Note, however, that it unshares only a 32596 single level of rtl. Thus, if the part to be changed is not at the 32597 top level, you'll need to replace first the top level. It is not 32598 necessary for this macro to come up with a legitimate address; but 32599 often a machine-dependent strategy can generate better code. 32600 32601 -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR, 32602 addr_space_t ADDRSPACE) 32603 This hook returns 'true' if memory address ADDR in address space 32604 ADDRSPACE can have different meanings depending on the machine mode 32605 of the memory reference it is used for or if the address is valid 32606 for some modes but not others. 32607 32608 Autoincrement and autodecrement addresses typically have 32609 mode-dependent effects because the amount of the increment or 32610 decrement is the size of the operand being addressed. Some 32611 machines have other mode-dependent addresses. Many RISC machines 32612 have no mode-dependent addresses. 32613 32614 You may assume that ADDR is a valid address for the machine. 32615 32616 The default version of this hook returns 'false'. 32617 32618 -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (machine_mode MODE, 32619 rtx X) 32620 This hook returns true if X is a legitimate constant for a 32621 MODE-mode immediate operand on the target machine. You can assume 32622 that X satisfies 'CONSTANT_P', so you need not check this. 32623 32624 The default definition returns true. 32625 32626 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 32627 This hook is used to undo the possibly obfuscating effects of the 32628 'LEGITIMIZE_ADDRESS' and 'LEGITIMIZE_RELOAD_ADDRESS' target macros. 32629 Some backend implementations of these macros wrap symbol references 32630 inside an 'UNSPEC' rtx to represent PIC or similar addressing 32631 modes. This target hook allows GCC's optimizers to understand the 32632 semantics of these opaque 'UNSPEC's by converting them back into 32633 their original form. 32634 32635 -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X) 32636 This hook should return true if X should not be emitted into debug 32637 sections. 32638 32639 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (machine_mode MODE, 32640 rtx X) 32641 This hook should return true if X is of a form that cannot (or 32642 should not) be spilled to the constant pool. MODE is the mode of 32643 X. 32644 32645 The default version of this hook returns false. 32646 32647 The primary reason to define this hook is to prevent reload from 32648 deciding that a non-legitimate constant would be better reloaded 32649 from the constant pool instead of spilling and reloading a register 32650 holding the constant. This restriction is often true of addresses 32651 of TLS symbols for various targets. 32652 32653 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (machine_mode 32654 MODE, const_rtx X) 32655 This hook should return true if pool entries for constant X can be 32656 placed in an 'object_block' structure. MODE is the mode of X. 32657 32658 The default version returns false for all constants. 32659 32660 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL) 32661 This hook should return true if pool entries for DECL should be 32662 placed in an 'object_block' structure. 32663 32664 The default version returns true for all decls. 32665 32666 -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (unsigned FN, bool 32667 MD_FN, bool SQRT) 32668 This hook should return the DECL of a function that implements 32669 reciprocal of the builtin function with builtin function code FN, 32670 or 'NULL_TREE' if such a function is not available. MD_FN is true 32671 when FN is a code of a machine-dependent builtin function. When 32672 SQRT is true, additional optimizations that apply only to the 32673 reciprocal of a square root function are performed, and only 32674 reciprocals of 'sqrt' function are valid. 32675 32676 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 32677 This hook should return the DECL of a function F that given an 32678 address ADDR as an argument returns a mask M that can be used to 32679 extract from two vectors the relevant data that resides in ADDR in 32680 case ADDR is not properly aligned. 32681 32682 The autovectorizer, when vectorizing a load operation from an 32683 address ADDR that may be unaligned, will generate two vector loads 32684 from the two aligned addresses around ADDR. It then generates a 32685 'REALIGN_LOAD' operation to extract the relevant data from the two 32686 loaded vectors. The first two arguments to 'REALIGN_LOAD', V1 and 32687 V2, are the two vectors, each of size VS, and the third argument, 32688 OFF, defines how the data will be extracted from these two vectors: 32689 if OFF is 0, then the returned vector is V2; otherwise, the 32690 returned vector is composed from the last VS-OFF elements of V1 32691 concatenated to the first OFF elements of V2. 32692 32693 If this hook is defined, the autovectorizer will generate a call to 32694 F (using the DECL tree that this hook returns) and will use the 32695 return value of F as the argument OFF to 'REALIGN_LOAD'. 32696 Therefore, the mask M returned by F should comply with the 32697 semantics expected by 'REALIGN_LOAD' described above. If this hook 32698 is not defined, then ADDR will be used as the argument OFF to 32699 'REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR 32700 will be considered. 32701 32702 -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum 32703 vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN) 32704 Returns cost of different scalar or vector statements for 32705 vectorization cost model. For vector memory operations the cost 32706 may depend on type (VECTYPE) and misalignment value (MISALIGN). 32707 32708 -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE 32709 (const_tree TYPE, bool IS_PACKED) 32710 Return true if vector alignment is reachable (by peeling N 32711 iterations) for the given type. 32712 32713 -- Target Hook: bool TARGET_VECTORIZE_VEC_PERM_CONST_OK (machine_mode, 32714 const unsigned char *SEL) 32715 Return true if a vector created for 'vec_perm_const' is valid. 32716 32717 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (unsigned 32718 CODE, tree DEST_TYPE, tree SRC_TYPE) 32719 This hook should return the DECL of a function that implements 32720 conversion of the input vector of type SRC_TYPE to type DEST_TYPE. 32721 The value of CODE is one of the enumerators in 'enum tree_code' and 32722 specifies how the conversion is to be applied (truncation, 32723 rounding, etc.). 32724 32725 If this hook is defined, the autovectorizer will use the 32726 'TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing 32727 conversion. Otherwise, it will return 'NULL_TREE'. 32728 32729 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION (tree 32730 FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 32731 This hook should return the decl of a function that implements the 32732 vectorized variant of the builtin function with builtin function 32733 code CODE or 'NULL_TREE' if such a function is not available. The 32734 value of FNDECL is the builtin function declaration. The return 32735 type of the vectorized function shall be of vector type 32736 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 32737 32738 -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT 32739 (machine_mode MODE, const_tree TYPE, int MISALIGNMENT, bool 32740 IS_PACKED) 32741 This hook should return true if the target supports misaligned 32742 vector store/load of a specific factor denoted in the MISALIGNMENT 32743 parameter. The vector store/load should be of machine mode MODE 32744 and the elements in the vectors should be of type TYPE. IS_PACKED 32745 parameter is true if the memory access is defined in a packed 32746 struct. 32747 32748 -- Target Hook: machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE 32749 (machine_mode MODE) 32750 This hook should return the preferred mode for vectorizing scalar 32751 mode MODE. The default is equal to 'word_mode', because the 32752 vectorizer can do some transformations even in absence of 32753 specialized SIMD hardware. 32754 32755 -- Target Hook: unsigned int 32756 TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES (void) 32757 This hook should return a mask of sizes that should be iterated 32758 over after trying to autovectorize using the vector size derived 32759 from the mode returned by 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE'. 32760 The default is zero which means to not iterate over other vector 32761 sizes. 32762 32763 -- Target Hook: void * TARGET_VECTORIZE_INIT_COST (struct loop 32764 *LOOP_INFO) 32765 This hook should initialize target-specific data structures in 32766 preparation for modeling the costs of vectorizing a loop or basic 32767 block. The default allocates three unsigned integers for 32768 accumulating costs for the prologue, body, and epilogue of the loop 32769 or basic block. If LOOP_INFO is non-NULL, it identifies the loop 32770 being vectorized; otherwise a single block is being vectorized. 32771 32772 -- Target Hook: unsigned TARGET_VECTORIZE_ADD_STMT_COST (void *DATA, 32773 int COUNT, enum vect_cost_for_stmt KIND, struct _stmt_vec_info 32774 *STMT_INFO, int MISALIGN, enum vect_cost_model_location WHERE) 32775 This hook should update the target-specific DATA in response to 32776 adding COUNT copies of the given KIND of statement to a loop or 32777 basic block. The default adds the builtin vectorizer cost for the 32778 copies of the statement to the accumulator specified by WHERE, (the 32779 prologue, body, or epilogue) and returns the amount added. The 32780 return value should be viewed as a tentative cost that may later be 32781 revised. 32782 32783 -- Target Hook: void TARGET_VECTORIZE_FINISH_COST (void *DATA, unsigned 32784 *PROLOGUE_COST, unsigned *BODY_COST, unsigned *EPILOGUE_COST) 32785 This hook should complete calculations of the cost of vectorizing a 32786 loop or basic block based on DATA, and return the prologue, body, 32787 and epilogue costs as unsigned integers. The default returns the 32788 value of the three accumulators. 32789 32790 -- Target Hook: void TARGET_VECTORIZE_DESTROY_COST_DATA (void *DATA) 32791 This hook should release DATA and any related data structures 32792 allocated by TARGET_VECTORIZE_INIT_COST. The default releases the 32793 accumulator. 32794 32795 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_TM_LOAD (tree) 32796 This hook should return the built-in decl needed to load a vector 32797 of the given type within a transaction. 32798 32799 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_TM_STORE (tree) 32800 This hook should return the built-in decl needed to store a vector 32801 of the given type within a transaction. 32802 32803 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_GATHER (const_tree 32804 MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE) 32805 Target builtin that implements vector gather operation. 32806 MEM_VECTYPE is the vector type of the load and INDEX_TYPE is scalar 32807 type of the index, scaled by SCALE. The default is 'NULL_TREE' 32808 which means to not vectorize gather loads. 32809 32810 -- Target Hook: int TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN 32811 (struct cgraph_node *, struct cgraph_simd_clone *, TREE, INT) 32812 This hook should set VECSIZE_MANGLE, VECSIZE_INT, VECSIZE_FLOAT 32813 fields in SIMD_CLONE structure pointed by CLONE_INFO argument and 32814 also SIMDLEN field if it was previously 0. The hook should return 32815 0 if SIMD clones shouldn't be emitted, or number of VECSIZE_MANGLE 32816 variants that should be emitted. 32817 32818 -- Target Hook: void TARGET_SIMD_CLONE_ADJUST (struct cgraph_node *) 32819 This hook should add implicit 'attribute(target("..."))' attribute 32820 to SIMD clone NODE if needed. 32821 32822 -- Target Hook: int TARGET_SIMD_CLONE_USABLE (struct cgraph_node *) 32823 This hook should return -1 if SIMD clone NODE shouldn't be used in 32824 vectorized loops in current function, or non-negative number if it 32825 is usable. In that case, the smaller the number is, the more 32826 desirable it is to use it. 32827 32828 32829File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 32830 3283117.14 Anchored Addresses 32832======================== 32833 32834GCC usually addresses every static object as a separate entity. For 32835example, if we have: 32836 32837 static int a, b, c; 32838 int foo (void) { return a + b + c; } 32839 32840 the code for 'foo' will usually calculate three separate symbolic 32841addresses: those of 'a', 'b' and 'c'. On some targets, it would be 32842better to calculate just one symbolic address and access the three 32843variables relative to it. The equivalent pseudocode would be something 32844like: 32845 32846 int foo (void) 32847 { 32848 register int *xr = &x; 32849 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 32850 } 32851 32852 (which isn't valid C). We refer to shared addresses like 'x' as 32853"section anchors". Their use is controlled by '-fsection-anchors'. 32854 32855 The hooks below describe the target properties that GCC needs to know 32856in order to make effective use of section anchors. It won't use section 32857anchors at all unless either 'TARGET_MIN_ANCHOR_OFFSET' or 32858'TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 32859 32860 -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 32861 The minimum offset that should be applied to a section anchor. On 32862 most targets, it should be the smallest offset that can be applied 32863 to a base register while still giving a legitimate address for 32864 every mode. The default value is 0. 32865 32866 -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 32867 Like 'TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) offset 32868 that should be applied to section anchors. The default value is 0. 32869 32870 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 32871 Write the assembly code to define section anchor X, which is a 32872 'SYMBOL_REF' for which 'SYMBOL_REF_ANCHOR_P (X)' is true. The hook 32873 is called with the assembly output position set to the beginning of 32874 'SYMBOL_REF_BLOCK (X)'. 32875 32876 If 'ASM_OUTPUT_DEF' is available, the hook's default definition 32877 uses it to define the symbol as '. + SYMBOL_REF_BLOCK_OFFSET (X)'. 32878 If 'ASM_OUTPUT_DEF' is not available, the hook's default definition 32879 is 'NULL', which disables the use of section anchors altogether. 32880 32881 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X) 32882 Return true if GCC should attempt to use anchors to access 32883 'SYMBOL_REF' X. You can assume 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 32884 and '!SYMBOL_REF_ANCHOR_P (X)'. 32885 32886 The default version is correct for most targets, but you might need 32887 to intercept this hook to handle things like target-specific 32888 attributes or target-specific sections. 32889 32890 32891File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 32892 3289317.15 Condition Code Status 32894=========================== 32895 32896The macros in this section can be split in two families, according to 32897the two ways of representing condition codes in GCC. 32898 32899 The first representation is the so called '(cc0)' representation (*note 32900Jump Patterns::), where all instructions can have an implicit clobber of 32901the condition codes. The second is the condition code register 32902representation, which provides better schedulability for architectures 32903that do have a condition code register, but on which most instructions 32904do not affect it. The latter category includes most RISC machines. 32905 32906 The implicit clobbering poses a strong restriction on the placement of 32907the definition and use of the condition code. In the past the 32908definition and use were always adjacent. However, recent changes to 32909support trapping arithmatic may result in the definition and user being 32910in different blocks. Thus, there may be a 'NOTE_INSN_BASIC_BLOCK' 32911between them. Additionally, the definition may be the source of 32912exception handling edges. 32913 32914 These restrictions can prevent important optimizations on some 32915machines. For example, on the IBM RS/6000, there is a delay for taken 32916branches unless the condition code register is set three instructions 32917earlier than the conditional branch. The instruction scheduler cannot 32918perform this optimization if it is not permitted to separate the 32919definition and use of the condition code register. 32920 32921 For this reason, it is possible and suggested to use a register to 32922represent the condition code for new ports. If there is a specific 32923condition code register in the machine, use a hard register. If the 32924condition code or comparison result can be placed in any general 32925register, or if there are multiple condition registers, use a pseudo 32926register. Registers used to store the condition code value will usually 32927have a mode that is in class 'MODE_CC'. 32928 32929 Alternatively, you can use 'BImode' if the comparison operator is 32930specified already in the compare instruction. In this case, you are not 32931interested in most macros in this section. 32932 32933* Menu: 32934 32935* CC0 Condition Codes:: Old style representation of condition codes. 32936* MODE_CC Condition Codes:: Modern representation of condition codes. 32937 32938 32939File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code 32940 3294117.15.1 Representation of condition codes using '(cc0)' 32942------------------------------------------------------- 32943 32944The file 'conditions.h' defines a variable 'cc_status' to describe how 32945the condition code was computed (in case the interpretation of the 32946condition code depends on the instruction that it was set by). This 32947variable contains the RTL expressions on which the condition code is 32948currently based, and several standard flags. 32949 32950 Sometimes additional machine-specific flags must be defined in the 32951machine description header file. It can also add additional 32952machine-specific information by defining 'CC_STATUS_MDEP'. 32953 32954 -- Macro: CC_STATUS_MDEP 32955 C code for a data type which is used for declaring the 'mdep' 32956 component of 'cc_status'. It defaults to 'int'. 32957 32958 This macro is not used on machines that do not use 'cc0'. 32959 32960 -- Macro: CC_STATUS_MDEP_INIT 32961 A C expression to initialize the 'mdep' field to "empty". The 32962 default definition does nothing, since most machines don't use the 32963 field anyway. If you want to use the field, you should probably 32964 define this macro to initialize it. 32965 32966 This macro is not used on machines that do not use 'cc0'. 32967 32968 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 32969 A C compound statement to set the components of 'cc_status' 32970 appropriately for an insn INSN whose body is EXP. It is this 32971 macro's responsibility to recognize insns that set the condition 32972 code as a byproduct of other activity as well as those that 32973 explicitly set '(cc0)'. 32974 32975 This macro is not used on machines that do not use 'cc0'. 32976 32977 If there are insns that do not set the condition code but do alter 32978 other machine registers, this macro must check to see whether they 32979 invalidate the expressions that the condition code is recorded as 32980 reflecting. For example, on the 68000, insns that store in address 32981 registers do not set the condition code, which means that usually 32982 'NOTICE_UPDATE_CC' can leave 'cc_status' unaltered for such insns. 32983 But suppose that the previous insn set the condition code based on 32984 location 'a4@(102)' and the current insn stores a new value in 32985 'a4'. Although the condition code is not changed by this, it will 32986 no longer be true that it reflects the contents of 'a4@(102)'. 32987 Therefore, 'NOTICE_UPDATE_CC' must alter 'cc_status' in this case 32988 to say that nothing is known about the condition code value. 32989 32990 The definition of 'NOTICE_UPDATE_CC' must be prepared to deal with 32991 the results of peephole optimization: insns whose patterns are 32992 'parallel' RTXs containing various 'reg', 'mem' or constants which 32993 are just the operands. The RTL structure of these insns is not 32994 sufficient to indicate what the insns actually do. What 32995 'NOTICE_UPDATE_CC' should do when it sees one is just to run 32996 'CC_STATUS_INIT'. 32997 32998 A possible definition of 'NOTICE_UPDATE_CC' is to call a function 32999 that looks at an attribute (*note Insn Attributes::) named, for 33000 example, 'cc'. This avoids having detailed information about 33001 patterns in two places, the 'md' file and in 'NOTICE_UPDATE_CC'. 33002 33003 33004File: gccint.info, Node: MODE_CC Condition Codes, Prev: CC0 Condition Codes, Up: Condition Code 33005 3300617.15.2 Representation of condition codes using registers 33007--------------------------------------------------------- 33008 33009 -- Macro: SELECT_CC_MODE (OP, X, Y) 33010 On many machines, the condition code may be produced by other 33011 instructions than compares, for example the branch can use directly 33012 the condition code set by a subtract instruction. However, on some 33013 machines when the condition code is set this way some bits (such as 33014 the overflow bit) are not set in the same way as a test 33015 instruction, so that a different branch instruction must be used 33016 for some conditional branches. When this happens, use the machine 33017 mode of the condition code register to record different formats of 33018 the condition code register. Modes can also be used to record 33019 which compare instruction (e.g. a signed or an unsigned 33020 comparison) produced the condition codes. 33021 33022 If other modes than 'CCmode' are required, add them to 33023 'MACHINE-modes.def' and define 'SELECT_CC_MODE' to choose a mode 33024 given an operand of a compare. This is needed because the modes 33025 have to be chosen not only during RTL generation but also, for 33026 example, by instruction combination. The result of 33027 'SELECT_CC_MODE' should be consistent with the mode used in the 33028 patterns; for example to support the case of the add on the SPARC 33029 discussed above, we have the pattern 33030 33031 (define_insn "" 33032 [(set (reg:CC_NOOV 0) 33033 (compare:CC_NOOV 33034 (plus:SI (match_operand:SI 0 "register_operand" "%r") 33035 (match_operand:SI 1 "arith_operand" "rI")) 33036 (const_int 0)))] 33037 "" 33038 "...") 33039 33040 together with a 'SELECT_CC_MODE' that returns 'CC_NOOVmode' for 33041 comparisons whose argument is a 'plus': 33042 33043 #define SELECT_CC_MODE(OP,X,Y) \ 33044 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 33045 ? ((OP == LT || OP == LE || OP == GT || OP == GE) \ 33046 ? CCFPEmode : CCFPmode) \ 33047 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 33048 || GET_CODE (X) == NEG || GET_CODE (x) == ASHIFT) \ 33049 ? CC_NOOVmode : CCmode)) 33050 33051 Another reason to use modes is to retain information on which 33052 operands were used by the comparison; see 'REVERSIBLE_CC_MODE' 33053 later in this section. 33054 33055 You should define this macro if and only if you define extra CC 33056 modes in 'MACHINE-modes.def'. 33057 33058 -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx 33059 *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE) 33060 On some machines not all possible comparisons are defined, but you 33061 can convert an invalid comparison into a valid one. For example, 33062 the Alpha does not have a 'GT' comparison, but you can use an 'LT' 33063 comparison instead and swap the order of the operands. 33064 33065 On such machines, implement this hook to do any required 33066 conversions. CODE is the initial comparison code and OP0 and OP1 33067 are the left and right operands of the comparison, respectively. 33068 If OP0_PRESERVE_VALUE is 'true' the implementation is not allowed 33069 to change the value of OP0 since the value might be used in RTXs 33070 which aren't comparisons. E.g. the implementation is not allowed 33071 to swap operands in that case. 33072 33073 GCC will not assume that the comparison resulting from this macro 33074 is valid but will see if the resulting insn matches a pattern in 33075 the 'md' file. 33076 33077 You need not to implement this hook if it would never change the 33078 comparison code or operands. 33079 33080 -- Macro: REVERSIBLE_CC_MODE (MODE) 33081 A C expression whose value is one if it is always safe to reverse a 33082 comparison whose mode is MODE. If 'SELECT_CC_MODE' can ever return 33083 MODE for a floating-point inequality comparison, then 33084 'REVERSIBLE_CC_MODE (MODE)' must be zero. 33085 33086 You need not define this macro if it would always returns zero or 33087 if the floating-point format is anything other than 33088 'IEEE_FLOAT_FORMAT'. For example, here is the definition used on 33089 the SPARC, where floating-point inequality comparisons are given 33090 either 'CCFPEmode' or 'CCFPmode': 33091 33092 #define REVERSIBLE_CC_MODE(MODE) \ 33093 ((MODE) != CCFPEmode && (MODE) != CCFPmode) 33094 33095 -- Macro: REVERSE_CONDITION (CODE, MODE) 33096 A C expression whose value is reversed condition code of the CODE 33097 for comparison done in CC_MODE MODE. The macro is used only in 33098 case 'REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 33099 case machine has some non-standard way how to reverse certain 33100 conditionals. For instance in case all floating point conditions 33101 are non-trapping, compiler may freely convert unordered compares to 33102 ordered ones. Then definition may look like: 33103 33104 #define REVERSE_CONDITION(CODE, MODE) \ 33105 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 33106 : reverse_condition_maybe_unordered (CODE)) 33107 33108 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int 33109 *P1, unsigned int *P2) 33110 On targets which do not use '(cc0)', and which use a hard register 33111 rather than a pseudo-register to hold condition codes, the regular 33112 CSE passes are often not able to identify cases in which the hard 33113 register is set to a common value. Use this hook to enable a small 33114 pass which optimizes such cases. This hook should return true to 33115 enable this pass, and it should set the integers to which its 33116 arguments point to the hard register numbers used for condition 33117 codes. When there is only one such register, as is true on most 33118 systems, the integer pointed to by P2 should be set to 33119 'INVALID_REGNUM'. 33120 33121 The default version of this hook returns false. 33122 33123 -- Target Hook: machine_mode TARGET_CC_MODES_COMPATIBLE (machine_mode 33124 M1, machine_mode M2) 33125 On targets which use multiple condition code modes in class 33126 'MODE_CC', it is sometimes the case that a comparison can be 33127 validly done in more than one mode. On such a system, define this 33128 target hook to take two mode arguments and to return a mode in 33129 which both comparisons may be validly done. If there is no such 33130 mode, return 'VOIDmode'. 33131 33132 The default version of this hook checks whether the modes are the 33133 same. If they are, it returns that mode. If they are different, 33134 it returns 'VOIDmode'. 33135 33136 -- Target Hook: unsigned int TARGET_FLAGS_REGNUM 33137 If the target has a dedicated flags register, and it needs to use 33138 the post-reload comparison elimination pass, then this value should 33139 be set appropriately. 33140 33141 33142File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 33143 3314417.16 Describing Relative Costs of Operations 33145============================================= 33146 33147These macros let you describe the relative speed of various operations 33148on the target machine. 33149 33150 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 33151 A C expression for the cost of moving data of mode MODE from a 33152 register in class FROM to one in class TO. The classes are 33153 expressed using the enumeration values such as 'GENERAL_REGS'. A 33154 value of 2 is the default; other values are interpreted relative to 33155 that. 33156 33157 It is not required that the cost always equal 2 when FROM is the 33158 same as TO; on some machines it is expensive to move between 33159 registers if they are not general registers. 33160 33161 If reload sees an insn consisting of a single 'set' between two 33162 hard registers, and if 'REGISTER_MOVE_COST' applied to their 33163 classes returns a value of 2, reload does not check to ensure that 33164 the constraints of the insn are met. Setting a cost of other than 33165 2 will allow reload to verify that the constraints are met. You 33166 should do this if the 'movM' pattern's constraints do not allow 33167 such copying. 33168 33169 These macros are obsolete, new ports should use the target hook 33170 'TARGET_REGISTER_MOVE_COST' instead. 33171 33172 -- Target Hook: int TARGET_REGISTER_MOVE_COST (machine_mode MODE, 33173 reg_class_t FROM, reg_class_t TO) 33174 This target hook should return the cost of moving data of mode MODE 33175 from a register in class FROM to one in class TO. The classes are 33176 expressed using the enumeration values such as 'GENERAL_REGS'. A 33177 value of 2 is the default; other values are interpreted relative to 33178 that. 33179 33180 It is not required that the cost always equal 2 when FROM is the 33181 same as TO; on some machines it is expensive to move between 33182 registers if they are not general registers. 33183 33184 If reload sees an insn consisting of a single 'set' between two 33185 hard registers, and if 'TARGET_REGISTER_MOVE_COST' applied to their 33186 classes returns a value of 2, reload does not check to ensure that 33187 the constraints of the insn are met. Setting a cost of other than 33188 2 will allow reload to verify that the constraints are met. You 33189 should do this if the 'movM' pattern's constraints do not allow 33190 such copying. 33191 33192 The default version of this function returns 2. 33193 33194 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 33195 A C expression for the cost of moving data of mode MODE between a 33196 register of class CLASS and memory; IN is zero if the value is to 33197 be written to memory, nonzero if it is to be read in. This cost is 33198 relative to those in 'REGISTER_MOVE_COST'. If moving between 33199 registers and memory is more expensive than between two registers, 33200 you should define this macro to express the relative cost. 33201 33202 If you do not define this macro, GCC uses a default cost of 4 plus 33203 the cost of copying via a secondary reload register, if one is 33204 needed. If your machine requires a secondary reload register to 33205 copy between memory and a register of CLASS but the reload 33206 mechanism is more complex than copying via an intermediate, define 33207 this macro to reflect the actual cost of the move. 33208 33209 GCC defines the function 'memory_move_secondary_cost' if secondary 33210 reloads are needed. It computes the costs due to copying via a 33211 secondary register. If your machine copies from memory using a 33212 secondary register in the conventional way but the default base 33213 value of 4 is not correct for your machine, define this macro to 33214 add some other value to the result of that function. The arguments 33215 to that function are the same as to this macro. 33216 33217 These macros are obsolete, new ports should use the target hook 33218 'TARGET_MEMORY_MOVE_COST' instead. 33219 33220 -- Target Hook: int TARGET_MEMORY_MOVE_COST (machine_mode MODE, 33221 reg_class_t RCLASS, bool IN) 33222 This target hook should return the cost of moving data of mode MODE 33223 between a register of class RCLASS and memory; IN is 'false' if the 33224 value is to be written to memory, 'true' if it is to be read in. 33225 This cost is relative to those in 'TARGET_REGISTER_MOVE_COST'. If 33226 moving between registers and memory is more expensive than between 33227 two registers, you should add this target hook to express the 33228 relative cost. 33229 33230 If you do not add this target hook, GCC uses a default cost of 4 33231 plus the cost of copying via a secondary reload register, if one is 33232 needed. If your machine requires a secondary reload register to 33233 copy between memory and a register of RCLASS but the reload 33234 mechanism is more complex than copying via an intermediate, use 33235 this target hook to reflect the actual cost of the move. 33236 33237 GCC defines the function 'memory_move_secondary_cost' if secondary 33238 reloads are needed. It computes the costs due to copying via a 33239 secondary register. If your machine copies from memory using a 33240 secondary register in the conventional way but the default base 33241 value of 4 is not correct for your machine, use this target hook to 33242 add some other value to the result of that function. The arguments 33243 to that function are the same as to this target hook. 33244 33245 -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P) 33246 A C expression for the cost of a branch instruction. A value of 1 33247 is the default; other values are interpreted relative to that. 33248 Parameter SPEED_P is true when the branch in question should be 33249 optimized for speed. When it is false, 'BRANCH_COST' should return 33250 a value optimal for code size rather than performance. 33251 PREDICTABLE_P is true for well-predicted branches. On many 33252 architectures the 'BRANCH_COST' can be reduced then. 33253 33254 Here are additional macros which do not specify precise relative costs, 33255but only that certain actions are more expensive than GCC would 33256ordinarily expect. 33257 33258 -- Macro: SLOW_BYTE_ACCESS 33259 Define this macro as a C expression which is nonzero if accessing 33260 less than a word of memory (i.e. a 'char' or a 'short') is no 33261 faster than accessing a word of memory, i.e., if such access 33262 require more than one instruction or if there is no difference in 33263 cost between byte and (aligned) word loads. 33264 33265 When this macro is not defined, the compiler will access a field by 33266 finding the smallest containing object; when it is defined, a 33267 fullword load will be used if alignment permits. Unless bytes 33268 accesses are faster than word accesses, using word accesses is 33269 preferable since it may eliminate subsequent memory access if 33270 subsequent accesses occur to other fields in the same word of the 33271 structure, but to different bytes. 33272 33273 -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT) 33274 Define this macro to be the value 1 if memory accesses described by 33275 the MODE and ALIGNMENT parameters have a cost many times greater 33276 than aligned accesses, for example if they are emulated in a trap 33277 handler. 33278 33279 When this macro is nonzero, the compiler will act as if 33280 'STRICT_ALIGNMENT' were nonzero when generating code for block 33281 moves. This can cause significantly more instructions to be 33282 produced. Therefore, do not set this macro nonzero if unaligned 33283 accesses only add a cycle or two to the time for a memory access. 33284 33285 If the value of this macro is always zero, it need not be defined. 33286 If this macro is defined, it should produce a nonzero value when 33287 'STRICT_ALIGNMENT' is nonzero. 33288 33289 -- Macro: MOVE_RATIO (SPEED) 33290 The threshold of number of scalar memory-to-memory move insns, 33291 _below_ which a sequence of insns should be generated instead of a 33292 string move insn or a library call. Increasing the value will 33293 always make code faster, but eventually incurs high cost in 33294 increased code size. 33295 33296 Note that on machines where the corresponding move insn is a 33297 'define_expand' that emits a sequence of insns, this macro counts 33298 the number of such sequences. 33299 33300 The parameter SPEED is true if the code is currently being 33301 optimized for speed rather than size. 33302 33303 If you don't define this, a reasonable default is used. 33304 33305 -- Target Hook: bool TARGET_USE_BY_PIECES_INFRASTRUCTURE_P (unsigned 33306 HOST_WIDE_INT SIZE, unsigned int ALIGNMENT, enum 33307 by_pieces_operation OP, bool SPEED_P) 33308 GCC will attempt several strategies when asked to copy between two 33309 areas of memory, or to set, clear or store to memory, for example 33310 when copying a 'struct'. The 'by_pieces' infrastructure implements 33311 such memory operations as a sequence of load, store or move insns. 33312 Alternate strategies are to expand the 'movmem' or 'setmem' optabs, 33313 to emit a library call, or to emit unit-by-unit, loop-based 33314 operations. 33315 33316 This target hook should return true if, for a memory operation with 33317 a given SIZE and ALIGNMENT, using the 'by_pieces' infrastructure is 33318 expected to result in better code generation. Both SIZE and 33319 ALIGNMENT are measured in terms of storage units. 33320 33321 The parameter OP is one of: 'CLEAR_BY_PIECES', 'MOVE_BY_PIECES', 33322 'SET_BY_PIECES', 'STORE_BY_PIECES'. These describe the type of 33323 memory operation under consideration. 33324 33325 The parameter SPEED_P is true if the code is currently being 33326 optimized for speed rather than size. 33327 33328 Returning true for higher values of SIZE can improve code 33329 generation for speed if the target does not provide an 33330 implementation of the 'movmem' or 'setmem' standard names, if the 33331 'movmem' or 'setmem' implementation would be more expensive than a 33332 sequence of insns, or if the overhead of a library call would 33333 dominate that of the body of the memory operation. 33334 33335 Returning true for higher values of 'size' may also cause an 33336 increase in code size, for example where the number of insns 33337 emitted to perform a move would be greater than that of a library 33338 call. 33339 33340 -- Macro: MOVE_MAX_PIECES 33341 A C expression used by 'move_by_pieces' to determine the largest 33342 unit a load or store used to copy memory is. Defaults to 33343 'MOVE_MAX'. 33344 33345 -- Macro: CLEAR_RATIO (SPEED) 33346 The threshold of number of scalar move insns, _below_ which a 33347 sequence of insns should be generated to clear memory instead of a 33348 string clear insn or a library call. Increasing the value will 33349 always make code faster, but eventually incurs high cost in 33350 increased code size. 33351 33352 The parameter SPEED is true if the code is currently being 33353 optimized for speed rather than size. 33354 33355 If you don't define this, a reasonable default is used. 33356 33357 -- Macro: SET_RATIO (SPEED) 33358 The threshold of number of scalar move insns, _below_ which a 33359 sequence of insns should be generated to set memory to a constant 33360 value, instead of a block set insn or a library call. Increasing 33361 the value will always make code faster, but eventually incurs high 33362 cost in increased code size. 33363 33364 The parameter SPEED is true if the code is currently being 33365 optimized for speed rather than size. 33366 33367 If you don't define this, it defaults to the value of 'MOVE_RATIO'. 33368 33369 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 33370 A C expression used to determine whether a load postincrement is a 33371 good thing to use for a given mode. Defaults to the value of 33372 'HAVE_POST_INCREMENT'. 33373 33374 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 33375 A C expression used to determine whether a load postdecrement is a 33376 good thing to use for a given mode. Defaults to the value of 33377 'HAVE_POST_DECREMENT'. 33378 33379 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 33380 A C expression used to determine whether a load preincrement is a 33381 good thing to use for a given mode. Defaults to the value of 33382 'HAVE_PRE_INCREMENT'. 33383 33384 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 33385 A C expression used to determine whether a load predecrement is a 33386 good thing to use for a given mode. Defaults to the value of 33387 'HAVE_PRE_DECREMENT'. 33388 33389 -- Macro: USE_STORE_POST_INCREMENT (MODE) 33390 A C expression used to determine whether a store postincrement is a 33391 good thing to use for a given mode. Defaults to the value of 33392 'HAVE_POST_INCREMENT'. 33393 33394 -- Macro: USE_STORE_POST_DECREMENT (MODE) 33395 A C expression used to determine whether a store postdecrement is a 33396 good thing to use for a given mode. Defaults to the value of 33397 'HAVE_POST_DECREMENT'. 33398 33399 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 33400 This macro is used to determine whether a store preincrement is a 33401 good thing to use for a given mode. Defaults to the value of 33402 'HAVE_PRE_INCREMENT'. 33403 33404 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 33405 This macro is used to determine whether a store predecrement is a 33406 good thing to use for a given mode. Defaults to the value of 33407 'HAVE_PRE_DECREMENT'. 33408 33409 -- Macro: NO_FUNCTION_CSE 33410 Define this macro if it is as good or better to call a constant 33411 function address than to call an address kept in a register. 33412 33413 -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT 33414 Define this macro if a non-short-circuit operation produced by 33415 'fold_range_test ()' is optimal. This macro defaults to true if 33416 'BRANCH_COST' is greater than or equal to the value 2. 33417 33418 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int OUTER_CODE, 33419 int OPNO, int *TOTAL, bool SPEED) 33420 This target hook describes the relative costs of RTL expressions. 33421 33422 The cost may depend on the precise form of the expression, which is 33423 available for examination in X, and the fact that X appears as 33424 operand OPNO of an expression with rtx code OUTER_CODE. That is, 33425 the hook can assume that there is some rtx Y such that 'GET_CODE 33426 (Y) == OUTER_CODE' and such that either (a) 'XEXP (Y, OPNO) == X' 33427 or (b) 'XVEC (Y, OPNO)' contains X. 33428 33429 CODE is X's expression code--redundant, since it can be obtained 33430 with 'GET_CODE (X)'. 33431 33432 In implementing this hook, you can use the construct 'COSTS_N_INSNS 33433 (N)' to specify a cost equal to N fast instructions. 33434 33435 On entry to the hook, '*TOTAL' contains a default estimate for the 33436 cost of the expression. The hook should modify this value as 33437 necessary. Traditionally, the default costs are 'COSTS_N_INSNS 33438 (5)' for multiplications, 'COSTS_N_INSNS (7)' for division and 33439 modulus operations, and 'COSTS_N_INSNS (1)' for all other 33440 operations. 33441 33442 When optimizing for code size, i.e. when 'speed' is false, this 33443 target hook should be used to estimate the relative size cost of an 33444 expression, again relative to 'COSTS_N_INSNS'. 33445 33446 The hook returns true when all subexpressions of X have been 33447 processed, and false when 'rtx_cost' should recurse. 33448 33449 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, machine_mode 33450 MODE, addr_space_t AS, bool SPEED) 33451 This hook computes the cost of an addressing mode that contains 33452 ADDRESS. If not defined, the cost is computed from the ADDRESS 33453 expression and the 'TARGET_RTX_COST' hook. 33454 33455 For most CISC machines, the default cost is a good approximation of 33456 the true cost of the addressing mode. However, on RISC machines, 33457 all instructions normally have the same length and execution time. 33458 Hence all addresses will have equal costs. 33459 33460 In cases where more than one form of an address is known, the form 33461 with the lowest cost will be used. If multiple forms have the 33462 same, lowest, cost, the one that is the most complex will be used. 33463 33464 For example, suppose an address that is equal to the sum of a 33465 register and a constant is used twice in the same basic block. 33466 When this macro is not defined, the address will be computed in a 33467 register and memory references will be indirect through that 33468 register. On machines where the cost of the addressing mode 33469 containing the sum is no higher than that of a simple indirect 33470 reference, this will produce an additional instruction and possibly 33471 require an additional register. Proper specification of this macro 33472 eliminates this overhead for such machines. 33473 33474 This hook is never called with an invalid address. 33475 33476 On machines where an address involving more than one register is as 33477 cheap as an address computation involving only one register, 33478 defining 'TARGET_ADDRESS_COST' to reflect this can cause two 33479 registers to be live over a region of code where only one would 33480 have been if 'TARGET_ADDRESS_COST' were not defined in that manner. 33481 This effect should be considered in the definition of this macro. 33482 Equivalent costs should probably only be given to addresses with 33483 different numbers of registers on machines with lots of registers. 33484 33485 33486File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 33487 3348817.17 Adjusting the Instruction Scheduler 33489========================================= 33490 33491The instruction scheduler may need a fair amount of machine-specific 33492adjustment in order to produce good code. GCC provides several target 33493hooks for this purpose. It is usually enough to define just a few of 33494them: try the first ones in this list first. 33495 33496 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 33497 This hook returns the maximum number of instructions that can ever 33498 issue at the same time on the target machine. The default is one. 33499 Although the insn scheduler can define itself the possibility of 33500 issue an insn on the same cycle, the value can serve as an 33501 additional constraint to issue insns on the same simulated 33502 processor cycle (see hooks 'TARGET_SCHED_REORDER' and 33503 'TARGET_SCHED_REORDER2'). This value must be constant over the 33504 entire compilation. If you need it to vary depending on what the 33505 instructions are, you must use 'TARGET_SCHED_VARIABLE_ISSUE'. 33506 33507 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 33508 VERBOSE, rtx_insn *INSN, int MORE) 33509 This hook is executed by the scheduler after it has scheduled an 33510 insn from the ready list. It should return the number of insns 33511 which can still be issued in the current cycle. The default is 33512 'MORE - 1' for insns other than 'CLOBBER' and 'USE', which normally 33513 are not counted against the issue rate. You should define this 33514 hook if some insns take more machine resources than others, so that 33515 fewer insns can follow them in the same cycle. FILE is either a 33516 null pointer, or a stdio stream to write any debug output to. 33517 VERBOSE is the verbose level provided by '-fsched-verbose-N'. INSN 33518 is the instruction that was scheduled. 33519 33520 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx_insn *INSN, rtx LINK, 33521 rtx_insn *DEP_INSN, int COST) 33522 This function corrects the value of COST based on the relationship 33523 between INSN and DEP_INSN through the dependence LINK. It should 33524 return the new value. The default is to make no adjustment to 33525 COST. This can be used for example to specify to the scheduler 33526 using the traditional pipeline description that an output- or 33527 anti-dependence does not incur the same cost as a data-dependence. 33528 If the scheduler using the automaton based pipeline description, 33529 the cost of anti-dependence is zero and the cost of 33530 output-dependence is maximum of one and the difference of latency 33531 times of the first and the second insns. If these values are not 33532 acceptable, you could use the hook to modify them too. See also 33533 *note Processor pipeline description::. 33534 33535 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx_insn *INSN, int 33536 PRIORITY) 33537 This hook adjusts the integer scheduling priority PRIORITY of INSN. 33538 It should return the new priority. Increase the priority to 33539 execute INSN earlier, reduce the priority to execute INSN later. 33540 Do not define this hook if you do not need to adjust the scheduling 33541 priorities of insns. 33542 33543 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, 33544 rtx_insn **READY, int *N_READYP, int CLOCK) 33545 This hook is executed by the scheduler after it has scheduled the 33546 ready list, to allow the machine description to reorder it (for 33547 example to combine two small instructions together on 'VLIW' 33548 machines). FILE is either a null pointer, or a stdio stream to 33549 write any debug output to. VERBOSE is the verbose level provided 33550 by '-fsched-verbose-N'. READY is a pointer to the ready list of 33551 instructions that are ready to be scheduled. N_READYP is a pointer 33552 to the number of elements in the ready list. The scheduler reads 33553 the ready list in reverse order, starting with READY[*N_READYP - 1] 33554 and going to READY[0]. CLOCK is the timer tick of the scheduler. 33555 You may modify the ready list and the number of ready insns. The 33556 return value is the number of insns that can issue this cycle; 33557 normally this is just 'issue_rate'. See also 33558 'TARGET_SCHED_REORDER2'. 33559 33560 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 33561 rtx_insn **READY, int *N_READYP, int CLOCK) 33562 Like 'TARGET_SCHED_REORDER', but called at a different time. That 33563 function is called whenever the scheduler starts a new cycle. This 33564 one is called once per iteration over a cycle, immediately after 33565 'TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list and 33566 return the number of insns to be scheduled in the same cycle. 33567 Defining this hook can be useful if there are frequent situations 33568 where scheduling one insn causes other insns to become ready in the 33569 same cycle. These other insns can then be taken into account 33570 properly. 33571 33572 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_P (void) 33573 This hook is used to check whether target platform supports macro 33574 fusion. 33575 33576 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_PAIR_P (rtx_insn *PREV, 33577 rtx_insn *CURR) 33578 This hook is used to check whether two insns should be macro fused 33579 for a target microarchitecture. If this hook returns true for the 33580 given insn pair (PREV and CURR), the scheduler will put them into a 33581 sched group, and they will not be scheduled apart. The two insns 33582 will be either two SET insns or a compare and a conditional jump 33583 and this hook should validate any dependencies needed to fuse the 33584 two insns together. 33585 33586 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK 33587 (rtx_insn *HEAD, rtx_insn *TAIL) 33588 This hook is called after evaluation forward dependencies of insns 33589 in chain given by two parameter values (HEAD and TAIL 33590 correspondingly) but before insns scheduling of the insn chain. 33591 For example, it can be used for better insn classification if it 33592 requires analysis of dependencies. This hook can use backward and 33593 forward dependencies of the insn scheduler because they are already 33594 calculated. 33595 33596 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 33597 MAX_READY) 33598 This hook is executed by the scheduler at the beginning of each 33599 block of instructions that are to be scheduled. FILE is either a 33600 null pointer, or a stdio stream to write any debug output to. 33601 VERBOSE is the verbose level provided by '-fsched-verbose-N'. 33602 MAX_READY is the maximum number of insns in the current scheduling 33603 region that can be live at the same time. This can be used to 33604 allocate scratch space if it is needed, e.g. by 33605 'TARGET_SCHED_REORDER'. 33606 33607 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 33608 This hook is executed by the scheduler at the end of each block of 33609 instructions that are to be scheduled. It can be used to perform 33610 cleanup of any actions done by the other scheduling hooks. FILE is 33611 either a null pointer, or a stdio stream to write any debug output 33612 to. VERBOSE is the verbose level provided by '-fsched-verbose-N'. 33613 33614 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int VERBOSE, 33615 int OLD_MAX_UID) 33616 This hook is executed by the scheduler after function level 33617 initializations. FILE is either a null pointer, or a stdio stream 33618 to write any debug output to. VERBOSE is the verbose level 33619 provided by '-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 33620 uid when scheduling begins. 33621 33622 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 33623 VERBOSE) 33624 This is the cleanup hook corresponding to 33625 'TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 33626 stdio stream to write any debug output to. VERBOSE is the verbose 33627 level provided by '-fsched-verbose-N'. 33628 33629 -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 33630 The hook returns an RTL insn. The automaton state used in the 33631 pipeline hazard recognizer is changed as if the insn were scheduled 33632 when the new simulated processor cycle starts. Usage of the hook 33633 may simplify the automaton pipeline description for some VLIW 33634 processors. If the hook is defined, it is used only for the 33635 automaton based pipeline description. The default is not to change 33636 the state when the new simulated processor cycle starts. 33637 33638 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 33639 The hook can be used to initialize data used by the previous hook. 33640 33641 -- Target Hook: rtx_insn * TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 33642 The hook is analogous to 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 33643 to changed the state as if the insn were scheduled when the new 33644 simulated processor cycle finishes. 33645 33646 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 33647 The hook is analogous to 'TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 33648 used to initialize data used by the previous hook. 33649 33650 -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void) 33651 The hook to notify target that the current simulated cycle is about 33652 to finish. The hook is analogous to 33653 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in 33654 more complicated situations - e.g., when advancing state on a 33655 single insn is not enough. 33656 33657 -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void) 33658 The hook to notify target that new simulated cycle has just 33659 started. The hook is analogous to 33660 'TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in 33661 more complicated situations - e.g., when advancing state on a 33662 single insn is not enough. 33663 33664 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 33665 (void) 33666 This hook controls better choosing an insn from the ready insn 33667 queue for the DFA-based insn scheduler. Usually the scheduler 33668 chooses the first insn from the queue. If the hook returns a 33669 positive value, an additional scheduler code tries all permutations 33670 of 'TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD ()' subsequent 33671 ready insns to choose an insn whose issue will result in maximal 33672 number of issued insns on the same cycle. For the VLIW processor, 33673 the code could actually solve the problem of packing simple insns 33674 into the VLIW insn. Of course, if the rules of VLIW packing are 33675 described in the automaton. 33676 33677 This code also could be used for superscalar RISC processors. Let 33678 us consider a superscalar RISC processor with 3 pipelines. Some 33679 insns can be executed in pipelines A or B, some insns can be 33680 executed only in pipelines B or C, and one insn can be executed in 33681 pipeline B. The processor may issue the 1st insn into A and the 33682 2nd one into B. In this case, the 3rd insn will wait for freeing B 33683 until the next cycle. If the scheduler issues the 3rd insn the 33684 first, the processor could issue all 3 insns per cycle. 33685 33686 Actually this code demonstrates advantages of the automaton based 33687 pipeline hazard recognizer. We try quickly and easy many insn 33688 schedules to choose the best one. 33689 33690 The default is no multipass scheduling. 33691 33692 -- Target Hook: int 33693 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD 33694 (rtx_insn *INSN, int READY_INDEX) 33695 33696 This hook controls what insns from the ready insn queue will be 33697 considered for the multipass insn scheduling. If the hook returns 33698 zero for INSN, the insn will be considered in multipass scheduling. 33699 Positive return values will remove INSN from consideration on the 33700 current round of multipass scheduling. Negative return values will 33701 remove INSN from consideration for given number of cycles. 33702 Backends should be careful about returning non-zero for highest 33703 priority instruction at position 0 in the ready list. READY_INDEX 33704 is passed to allow backends make correct judgements. 33705 33706 The default is that any ready insns can be chosen to be issued. 33707 33708 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void 33709 *DATA, signed char *READY_TRY, int N_READY, bool 33710 FIRST_CYCLE_INSN_P) 33711 This hook prepares the target backend for a new round of multipass 33712 scheduling. 33713 33714 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void 33715 *DATA, signed char *READY_TRY, int N_READY, rtx_insn *INSN, 33716 const void *PREV_DATA) 33717 This hook is called when multipass scheduling evaluates instruction 33718 INSN. 33719 33720 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK 33721 (const void *DATA, signed char *READY_TRY, int N_READY) 33722 This is called when multipass scheduling backtracks from evaluation 33723 of an instruction. 33724 33725 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const void 33726 *DATA) 33727 This hook notifies the target about the result of the concluded 33728 current round of multipass scheduling. 33729 33730 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void 33731 *DATA) 33732 This hook initializes target-specific data used in multipass 33733 scheduling. 33734 33735 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void 33736 *DATA) 33737 This hook finalizes target-specific data used in multipass 33738 scheduling. 33739 33740 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int 33741 VERBOSE, rtx_insn *INSN, int LAST_CLOCK, int CLOCK, int 33742 *SORT_P) 33743 This hook is called by the insn scheduler before issuing INSN on 33744 cycle CLOCK. If the hook returns nonzero, INSN is not issued on 33745 this processor cycle. Instead, the processor cycle is advanced. 33746 If *SORT_P is zero, the insn ready queue is not sorted on the new 33747 cycle start as usually. DUMP and VERBOSE specify the file and 33748 verbosity level to use for debugging output. LAST_CLOCK and CLOCK 33749 are, respectively, the processor cycle on which the previous insn 33750 has been issued, and the current processor cycle. 33751 33752 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep 33753 *_DEP, int COST, int DISTANCE) 33754 This hook is used to define which dependences are considered costly 33755 by the target, so costly that it is not advisable to schedule the 33756 insns that are involved in the dependence too close to one another. 33757 The parameters to this hook are as follows: The first parameter 33758 _DEP is the dependence being evaluated. The second parameter COST 33759 is the cost of the dependence as estimated by the scheduler, and 33760 the third parameter DISTANCE is the distance in cycles between the 33761 two insns. The hook returns 'true' if considering the distance 33762 between the two insns the dependence between them is considered 33763 costly by the target, and 'false' otherwise. 33764 33765 Defining this hook can be useful in multiple-issue out-of-order 33766 machines, where (a) it's practically hopeless to predict the actual 33767 data/resource delays, however: (b) there's a better chance to 33768 predict the actual grouping that will be formed, and (c) correctly 33769 emulating the grouping can be very important. In such targets one 33770 may want to allow issuing dependent insns closer to one 33771 another--i.e., closer than the dependence distance; however, not in 33772 cases of "costly dependences", which this hooks allows to define. 33773 33774 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 33775 This hook is called by the insn scheduler after emitting a new 33776 instruction to the instruction stream. The hook notifies a target 33777 backend to extend its per instruction data structures. 33778 33779 -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void) 33780 Return a pointer to a store large enough to hold target scheduling 33781 context. 33782 33783 -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool 33784 CLEAN_P) 33785 Initialize store pointed to by TC to hold target scheduling 33786 context. It CLEAN_P is true then initialize TC as if scheduler is 33787 at the beginning of the block. Otherwise, copy the current context 33788 into TC. 33789 33790 -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC) 33791 Copy target scheduling context pointed to by TC to the current 33792 context. 33793 33794 -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC) 33795 Deallocate internal data in target scheduling context pointed to by 33796 TC. 33797 33798 -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC) 33799 Deallocate a store for target scheduling context pointed to by TC. 33800 33801 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx_insn *INSN, 33802 unsigned int DEP_STATUS, rtx *NEW_PAT) 33803 This hook is called by the insn scheduler when INSN has only 33804 speculative dependencies and therefore can be scheduled 33805 speculatively. The hook is used to check if the pattern of INSN 33806 has a speculative version and, in case of successful check, to 33807 generate that speculative pattern. The hook should return 1, if 33808 the instruction has a speculative form, or -1, if it doesn't. 33809 REQUEST describes the type of requested speculation. If the return 33810 value equals 1 then NEW_PAT is assigned the generated speculative 33811 pattern. 33812 33813 -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (unsigned int 33814 DEP_STATUS) 33815 This hook is called by the insn scheduler during generation of 33816 recovery code for INSN. It should return 'true', if the 33817 corresponding check instruction should branch to recovery code, or 33818 'false' otherwise. 33819 33820 -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx_insn *INSN, 33821 rtx_insn *LABEL, unsigned int DS) 33822 This hook is called by the insn scheduler to generate a pattern for 33823 recovery check instruction. If MUTATE_P is zero, then INSN is a 33824 speculative instruction for which the check should be generated. 33825 LABEL is either a label of a basic block, where recovery code 33826 should be emitted, or a null pointer, when requested check doesn't 33827 branch to recovery code (a simple check). If MUTATE_P is nonzero, 33828 then a pattern for a branchy check corresponding to a simple check 33829 denoted by INSN should be generated. In this case LABEL can't be 33830 null. 33831 33832 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct spec_info_def 33833 *SPEC_INFO) 33834 This hook is used by the insn scheduler to find out what features 33835 should be enabled/used. The structure *SPEC_INFO should be filled 33836 in by the target. The structure describes speculation types that 33837 can be used in the scheduler. 33838 33839 -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G) 33840 This hook is called by the swing modulo scheduler to calculate a 33841 resource-based lower bound which is based on the resources 33842 available in the machine and the resources required by each 33843 instruction. The target backend can use G to calculate such bound. 33844 A very simple lower bound will be used in case this hook is not 33845 implemented: the total number of instructions divided by the issue 33846 rate. 33847 33848 -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx_insn *INSN, int X) 33849 This hook is called by Haifa Scheduler. It returns true if 33850 dispatch scheduling is supported in hardware and the condition 33851 specified in the parameter is true. 33852 33853 -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx_insn *INSN, int X) 33854 This hook is called by Haifa Scheduler. It performs the operation 33855 specified in its second parameter. 33856 33857 -- Target Hook: bool TARGET_SCHED_EXPOSED_PIPELINE 33858 True if the processor has an exposed pipeline, which means that not 33859 just the order of instructions is important for correctness when 33860 scheduling, but also the latencies of operations. 33861 33862 -- Target Hook: int TARGET_SCHED_REASSOCIATION_WIDTH (unsigned int OPC, 33863 machine_mode MODE) 33864 This hook is called by tree reassociator to determine a level of 33865 parallelism required in output calculations chain. 33866 33867 -- Target Hook: void TARGET_SCHED_FUSION_PRIORITY (rtx_insn *INSN, int 33868 MAX_PRI, int *FUSION_PRI, int *PRI) 33869 This hook is called by scheduling fusion pass. It calculates 33870 fusion priorities for each instruction passed in by parameter. The 33871 priorities are returned via pointer parameters. 33872 33873 INSN is the instruction whose priorities need to be calculated. 33874 MAX_PRI is the maximum priority can be returned in any cases. 33875 FUSION_PRI is the pointer parameter through which INSN's fusion 33876 priority should be calculated and returned. PRI is the pointer 33877 parameter through which INSN's priority should be calculated and 33878 returned. 33879 33880 Same FUSION_PRI should be returned for instructions which should be 33881 scheduled together. Different PRI should be returned for 33882 instructions with same FUSION_PRI. FUSION_PRI is the major sort 33883 key, PRI is the minor sort key. All instructions will be scheduled 33884 according to the two priorities. All priorities calculated should 33885 be between 0 (exclusive) and MAX_PRI (inclusive). To avoid false 33886 dependencies, FUSION_PRI of instructions which need to be scheduled 33887 together should be smaller than FUSION_PRI of irrelevant 33888 instructions. 33889 33890 Given below example: 33891 33892 ldr r10, [r1, 4] 33893 add r4, r4, r10 33894 ldr r15, [r2, 8] 33895 sub r5, r5, r15 33896 ldr r11, [r1, 0] 33897 add r4, r4, r11 33898 ldr r16, [r2, 12] 33899 sub r5, r5, r16 33900 33901 On targets like ARM/AArch64, the two pairs of consecutive loads 33902 should be merged. Since peephole2 pass can't help in this case 33903 unless consecutive loads are actually next to each other in 33904 instruction flow. That's where this scheduling fusion pass works. 33905 This hook calculates priority for each instruction based on its 33906 fustion type, like: 33907 33908 ldr r10, [r1, 4] ; fusion_pri=99, pri=96 33909 add r4, r4, r10 ; fusion_pri=100, pri=100 33910 ldr r15, [r2, 8] ; fusion_pri=98, pri=92 33911 sub r5, r5, r15 ; fusion_pri=100, pri=100 33912 ldr r11, [r1, 0] ; fusion_pri=99, pri=100 33913 add r4, r4, r11 ; fusion_pri=100, pri=100 33914 ldr r16, [r2, 12] ; fusion_pri=98, pri=88 33915 sub r5, r5, r16 ; fusion_pri=100, pri=100 33916 33917 Scheduling fusion pass then sorts all ready to issue instructions 33918 according to the priorities. As a result, instructions of same 33919 fusion type will be pushed together in instruction flow, like: 33920 33921 ldr r11, [r1, 0] 33922 ldr r10, [r1, 4] 33923 ldr r15, [r2, 8] 33924 ldr r16, [r2, 12] 33925 add r4, r4, r10 33926 sub r5, r5, r15 33927 add r4, r4, r11 33928 sub r5, r5, r16 33929 33930 Now peephole2 pass can simply merge the two pairs of loads. 33931 33932 Since scheduling fusion pass relies on peephole2 to do real fusion 33933 work, it is only enabled by default when peephole2 is in effect. 33934 33935 This is firstly introduced on ARM/AArch64 targets, please refer to 33936 the hook implementation for how different fusion types are 33937 supported. 33938 33939 33940File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 33941 3394217.18 Dividing the Output into Sections (Texts, Data, ...) 33943========================================================== 33944 33945An object file is divided into sections containing different types of 33946data. In the most common case, there are three sections: the "text 33947section", which holds instructions and read-only data; the "data 33948section", which holds initialized writable data; and the "bss section", 33949which holds uninitialized data. Some systems have other kinds of 33950sections. 33951 33952 'varasm.c' provides several well-known sections, such as 33953'text_section', 'data_section' and 'bss_section'. The normal way of 33954controlling a 'FOO_section' variable is to define the associated 33955'FOO_SECTION_ASM_OP' macro, as described below. The macros are only 33956read once, when 'varasm.c' initializes itself, so their values must be 33957run-time constants. They may however depend on command-line flags. 33958 33959 _Note:_ Some run-time files, such 'crtstuff.c', also make use of the 33960'FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 33961 33962 Some assemblers require a different string to be written every time a 33963section is selected. If your assembler falls into this category, you 33964should define the 'TARGET_ASM_INIT_SECTIONS' hook and use 33965'get_unnamed_section' to set up the sections. 33966 33967 You must always create a 'text_section', either by defining 33968'TEXT_SECTION_ASM_OP' or by initializing 'text_section' in 33969'TARGET_ASM_INIT_SECTIONS'. The same is true of 'data_section' and 33970'DATA_SECTION_ASM_OP'. If you do not create a distinct 33971'readonly_data_section', the default is to reuse 'text_section'. 33972 33973 All the other 'varasm.c' sections are optional, and are null if the 33974target does not provide them. 33975 33976 -- Macro: TEXT_SECTION_ASM_OP 33977 A C expression whose value is a string, including spacing, 33978 containing the assembler operation that should precede instructions 33979 and read-only data. Normally '"\t.text"' is right. 33980 33981 -- Macro: HOT_TEXT_SECTION_NAME 33982 If defined, a C string constant for the name of the section 33983 containing most frequently executed functions of the program. If 33984 not defined, GCC will provide a default definition if the target 33985 supports named sections. 33986 33987 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 33988 If defined, a C string constant for the name of the section 33989 containing unlikely executed functions in the program. 33990 33991 -- Macro: DATA_SECTION_ASM_OP 33992 A C expression whose value is a string, including spacing, 33993 containing the assembler operation to identify the following data 33994 as writable initialized data. Normally '"\t.data"' is right. 33995 33996 -- Macro: SDATA_SECTION_ASM_OP 33997 If defined, a C expression whose value is a string, including 33998 spacing, containing the assembler operation to identify the 33999 following data as initialized, writable small data. 34000 34001 -- Macro: READONLY_DATA_SECTION_ASM_OP 34002 A C expression whose value is a string, including spacing, 34003 containing the assembler operation to identify the following data 34004 as read-only initialized data. 34005 34006 -- Macro: BSS_SECTION_ASM_OP 34007 If defined, a C expression whose value is a string, including 34008 spacing, containing the assembler operation to identify the 34009 following data as uninitialized global data. If not defined, and 34010 'ASM_OUTPUT_ALIGNED_BSS' not defined, uninitialized global data 34011 will be output in the data section if '-fno-common' is passed, 34012 otherwise 'ASM_OUTPUT_COMMON' will be used. 34013 34014 -- Macro: SBSS_SECTION_ASM_OP 34015 If defined, a C expression whose value is a string, including 34016 spacing, containing the assembler operation to identify the 34017 following data as uninitialized, writable small data. 34018 34019 -- Macro: TLS_COMMON_ASM_OP 34020 If defined, a C expression whose value is a string containing the 34021 assembler operation to identify the following data as thread-local 34022 common data. The default is '".tls_common"'. 34023 34024 -- Macro: TLS_SECTION_ASM_FLAG 34025 If defined, a C expression whose value is a character constant 34026 containing the flag used to mark a section as a TLS section. The 34027 default is ''T''. 34028 34029 -- Macro: INIT_SECTION_ASM_OP 34030 If defined, a C expression whose value is a string, including 34031 spacing, containing the assembler operation to identify the 34032 following data as initialization code. If not defined, GCC will 34033 assume such a section does not exist. This section has no 34034 corresponding 'init_section' variable; it is used entirely in 34035 runtime code. 34036 34037 -- Macro: FINI_SECTION_ASM_OP 34038 If defined, a C expression whose value is a string, including 34039 spacing, containing the assembler operation to identify the 34040 following data as finalization code. If not defined, GCC will 34041 assume such a section does not exist. This section has no 34042 corresponding 'fini_section' variable; it is used entirely in 34043 runtime code. 34044 34045 -- Macro: INIT_ARRAY_SECTION_ASM_OP 34046 If defined, a C expression whose value is a string, including 34047 spacing, containing the assembler operation to identify the 34048 following data as part of the '.init_array' (or equivalent) 34049 section. If not defined, GCC will assume such a section does not 34050 exist. Do not define both this macro and 'INIT_SECTION_ASM_OP'. 34051 34052 -- Macro: FINI_ARRAY_SECTION_ASM_OP 34053 If defined, a C expression whose value is a string, including 34054 spacing, containing the assembler operation to identify the 34055 following data as part of the '.fini_array' (or equivalent) 34056 section. If not defined, GCC will assume such a section does not 34057 exist. Do not define both this macro and 'FINI_SECTION_ASM_OP'. 34058 34059 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 34060 If defined, an ASM statement that switches to a different section 34061 via SECTION_OP, calls FUNCTION, and switches back to the text 34062 section. This is used in 'crtstuff.c' if 'INIT_SECTION_ASM_OP' or 34063 'FINI_SECTION_ASM_OP' to calls to initialization and finalization 34064 functions from the init and fini sections. By default, this macro 34065 uses a simple function call. Some ports need hand-crafted assembly 34066 code to avoid dependencies on registers initialized in the function 34067 prologue or to ensure that constant pools don't end up too far way 34068 in the text section. 34069 34070 -- Macro: TARGET_LIBGCC_SDATA_SECTION 34071 If defined, a string which names the section into which small 34072 variables defined in crtstuff and libgcc should go. This is useful 34073 when the target has options for optimizing access to small data, 34074 and you want the crtstuff and libgcc routines to be conservative in 34075 what they expect of your application yet liberal in what your 34076 application expects. For example, for targets with a '.sdata' 34077 section (like MIPS), you could compile crtstuff with '-G 0' so that 34078 it doesn't require small data support from your application, but 34079 use this macro to put small data into '.sdata' so that your 34080 application can access these variables whether it uses small data 34081 or not. 34082 34083 -- Macro: FORCE_CODE_SECTION_ALIGN 34084 If defined, an ASM statement that aligns a code section to some 34085 arbitrary boundary. This is used to force all fragments of the 34086 '.init' and '.fini' sections to have to same alignment and thus 34087 prevent the linker from having to add any padding. 34088 34089 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 34090 Define this macro to be an expression with a nonzero value if jump 34091 tables (for 'tablejump' insns) should be output in the text 34092 section, along with the assembler instructions. Otherwise, the 34093 readonly data section is used. 34094 34095 This macro is irrelevant if there is no separate readonly data 34096 section. 34097 34098 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 34099 Define this hook if you need to do something special to set up the 34100 'varasm.c' sections, or if your target has some special sections of 34101 its own that you need to create. 34102 34103 GCC calls this hook after processing the command line, but before 34104 writing any assembly code, and before calling any of the 34105 section-returning hooks described below. 34106 34107 -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void) 34108 Return a mask describing how relocations should be treated when 34109 selecting sections. Bit 1 should be set if global relocations 34110 should be placed in a read-write section; bit 0 should be set if 34111 local relocations should be placed in a read-write section. 34112 34113 The default version of this function returns 3 when '-fpic' is in 34114 effect, and 0 otherwise. The hook is typically redefined when the 34115 target cannot support (some kinds of) dynamic relocations in 34116 read-only sections even in executables. 34117 34118 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 34119 RELOC, unsigned HOST_WIDE_INT ALIGN) 34120 Return the section into which EXP should be placed. You can assume 34121 that EXP is either a 'VAR_DECL' node or a constant of some sort. 34122 RELOC indicates whether the initial value of EXP requires link-time 34123 relocations. Bit 0 is set when variable contains local relocations 34124 only, while bit 1 is set for global relocations. ALIGN is the 34125 constant alignment in bits. 34126 34127 The default version of this function takes care of putting 34128 read-only variables in 'readonly_data_section'. 34129 34130 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 34131 34132 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 34133 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 34134 called for 'FUNCTION_DECL's as well as for variables and constants. 34135 34136 In the case of a 'FUNCTION_DECL', RELOC will be zero if the 34137 function has been determined to be likely to be called, and nonzero 34138 if it is unlikely to be called. 34139 34140 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 34141 Build up a unique section name, expressed as a 'STRING_CST' node, 34142 and assign it to 'DECL_SECTION_NAME (DECL)'. As with 34143 'TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 34144 value of EXP requires link-time relocations. 34145 34146 The default version of this function appends the symbol name to the 34147 ELF section name that would normally be used for the symbol. For 34148 example, the function 'foo' would be placed in '.text.foo'. 34149 Whatever the actual target object format, this is often good 34150 enough. 34151 34152 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 34153 DECL) 34154 Return the readonly data section associated with 'DECL_SECTION_NAME 34155 (DECL)'. The default version of this function selects 34156 '.gnu.linkonce.r.name' if the function's section is 34157 '.gnu.linkonce.t.name', '.rodata.name' if function is in 34158 '.text.name', and the normal readonly-data section otherwise. 34159 34160 -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX 34161 Usually, the compiler uses the prefix '".rodata"' to construct 34162 section names for mergeable constant data. Define this macro to 34163 override the string if a different section name should be used. 34164 34165 -- Target Hook: section * TARGET_ASM_TM_CLONE_TABLE_SECTION (void) 34166 Return the section that should be used for transactional memory 34167 clone tables. 34168 34169 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (machine_mode 34170 MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 34171 Return the section into which a constant X, of mode MODE, should be 34172 placed. You can assume that X is some kind of constant in RTL. 34173 The argument MODE is redundant except in the case of a 'const_int' 34174 rtx. ALIGN is the constant alignment in bits. 34175 34176 The default version of this function takes care of putting symbolic 34177 constants in 'flag_pic' mode in 'data_section' and everything else 34178 in 'readonly_data_section'. 34179 34180 -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, tree 34181 ID) 34182 Define this hook if you need to postprocess the assembler name 34183 generated by target-independent code. The ID provided to this hook 34184 will be the computed name (e.g., the macro 'DECL_NAME' of the DECL 34185 in C, or the mangled name of the DECL in C++). The return value of 34186 the hook is an 'IDENTIFIER_NODE' for the appropriate mangled name 34187 on your target system. The default implementation of this hook 34188 just returns the ID provided. 34189 34190 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 34191 int NEW_DECL_P) 34192 Define this hook if references to a symbol or a constant must be 34193 treated differently depending on something about the variable or 34194 function named by the symbol (such as what section it is in). 34195 34196 The hook is executed immediately after rtl has been created for 34197 DECL, which may be a variable or function declaration or an entry 34198 in the constant pool. In either case, RTL is the rtl in question. 34199 Do _not_ use 'DECL_RTL (DECL)' in this hook; that field may not 34200 have been initialized yet. 34201 34202 In the case of a constant, it is safe to assume that the rtl is a 34203 'mem' whose address is a 'symbol_ref'. Most decls will also have 34204 this form, but that is not guaranteed. Global register variables, 34205 for instance, will have a 'reg' for their rtl. (Normally the right 34206 thing to do with such unusual rtl is leave it alone.) 34207 34208 The NEW_DECL_P argument will be true if this is the first time that 34209 'TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. It 34210 will be false for subsequent invocations, which will happen for 34211 duplicate declarations. Whether or not anything must be done for 34212 the duplicate declaration depends on whether the hook examines 34213 'DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 34214 called for a constant. 34215 34216 The usual thing for this hook to do is to record flags in the 34217 'symbol_ref', using 'SYMBOL_REF_FLAG' or 'SYMBOL_REF_FLAGS'. 34218 Historically, the name string was modified if it was necessary to 34219 encode more than one bit of information, but this practice is now 34220 discouraged; use 'SYMBOL_REF_FLAGS'. 34221 34222 The default definition of this hook, 'default_encode_section_info' 34223 in 'varasm.c', sets a number of commonly-useful bits in 34224 'SYMBOL_REF_FLAGS'. Check whether the default does what you need 34225 before overriding it. 34226 34227 -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char 34228 *NAME) 34229 Decode NAME and return the real name part, sans the characters that 34230 'TARGET_ENCODE_SECTION_INFO' may have added. 34231 34232 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP) 34233 Returns true if EXP should be placed into a "small data" section. 34234 The default version of this hook always returns false. 34235 34236 -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION 34237 Contains the value true if the target places read-only "small data" 34238 into a separate section. The default value is false. 34239 34240 -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void) 34241 It returns true if target wants profile code emitted before 34242 prologue. 34243 34244 The default version of this hook use the target macro 34245 'PROFILE_BEFORE_PROLOGUE'. 34246 34247 -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP) 34248 Returns true if EXP names an object for which name resolution rules 34249 must resolve to the current "module" (dynamic shared library or 34250 executable image). 34251 34252 The default version of this hook implements the name resolution 34253 rules for ELF, which has a looser model of global name binding than 34254 other currently supported object file formats. 34255 34256 -- Target Hook: bool TARGET_HAVE_TLS 34257 Contains the value true if the target supports thread-local 34258 storage. The default value is false. 34259 34260 34261File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 34262 3426317.19 Position Independent Code 34264=============================== 34265 34266This section describes macros that help implement generation of position 34267independent code. Simply defining these macros is not enough to 34268generate valid PIC; you must also add support to the hook 34269'TARGET_LEGITIMATE_ADDRESS_P' and to the macro 'PRINT_OPERAND_ADDRESS', 34270as well as 'LEGITIMIZE_ADDRESS'. You must modify the definition of 34271'movsi' to do something appropriate when the source operand contains a 34272symbolic address. You may also need to alter the handling of switch 34273statements so that they use relative addresses. 34274 34275 -- Macro: PIC_OFFSET_TABLE_REGNUM 34276 The register number of the register used to address a table of 34277 static data addresses in memory. In some cases this register is 34278 defined by a processor's "application binary interface" (ABI). 34279 When this macro is defined, RTL is generated for this register 34280 once, as with the stack pointer and frame pointer registers. If 34281 this macro is not defined, it is up to the machine-dependent files 34282 to allocate such a register (if necessary). Note that this 34283 register must be fixed when in use (e.g. when 'flag_pic' is true). 34284 34285 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 34286 A C expression that is nonzero if the register defined by 34287 'PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. If not defined, 34288 the default is zero. Do not define this macro if 34289 'PIC_OFFSET_TABLE_REGNUM' is not defined. 34290 34291 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 34292 A C expression that is nonzero if X is a legitimate immediate 34293 operand on the target machine when generating position independent 34294 code. You can assume that X satisfies 'CONSTANT_P', so you need 34295 not check this. You can also assume FLAG_PIC is true, so you need 34296 not check it either. You need not define this macro if all 34297 constants (including 'SYMBOL_REF') can be immediate operands when 34298 generating position independent code. 34299 34300 34301File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 34302 3430317.20 Defining the Output Assembler Language 34304============================================ 34305 34306This section describes macros whose principal purpose is to describe how 34307to write instructions in assembler language--rather than what the 34308instructions do. 34309 34310* Menu: 34311 34312* File Framework:: Structural information for the assembler file. 34313* Data Output:: Output of constants (numbers, strings, addresses). 34314* Uninitialized Data:: Output of uninitialized variables. 34315* Label Output:: Output and generation of labels. 34316* Initialization:: General principles of initialization 34317 and termination routines. 34318* Macros for Initialization:: 34319 Specific macros that control the handling of 34320 initialization and termination routines. 34321* Instruction Output:: Output of actual instructions. 34322* Dispatch Tables:: Output of jump tables. 34323* Exception Region Output:: Output of exception region code. 34324* Alignment Output:: Pseudo ops for alignment and skipping data. 34325 34326 34327File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 34328 3432917.20.1 The Overall Framework of an Assembler File 34330-------------------------------------------------- 34331 34332This describes the overall framework of an assembly file. 34333 34334 -- Target Hook: void TARGET_ASM_FILE_START (void) 34335 Output to 'asm_out_file' any text which the assembler expects to 34336 find at the beginning of a file. The default behavior is 34337 controlled by two flags, documented below. Unless your target's 34338 assembler is quite unusual, if you override the default, you should 34339 call 'default_file_start' at some point in your target hook. This 34340 lets other target files rely on these variables. 34341 34342 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 34343 If this flag is true, the text of the macro 'ASM_APP_OFF' will be 34344 printed as the very first line in the assembly file, unless 34345 '-fverbose-asm' is in effect. (If that macro has been defined to 34346 the empty string, this variable has no effect.) With the normal 34347 definition of 'ASM_APP_OFF', the effect is to notify the GNU 34348 assembler that it need not bother stripping comments or extra 34349 whitespace from its input. This allows it to work a bit faster. 34350 34351 The default is false. You should not set it to true unless you 34352 have verified that your port does not generate any extra whitespace 34353 or comments that will cause GAS to issue errors in NO_APP mode. 34354 34355 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 34356 If this flag is true, 'output_file_directive' will be called for 34357 the primary source file, immediately after printing 'ASM_APP_OFF' 34358 (if that is enabled). Most ELF assemblers expect this to be done. 34359 The default is false. 34360 34361 -- Target Hook: void TARGET_ASM_FILE_END (void) 34362 Output to 'asm_out_file' any text which the assembler expects to 34363 find at the end of a file. The default is to output nothing. 34364 34365 -- Function: void file_end_indicate_exec_stack () 34366 Some systems use a common convention, the '.note.GNU-stack' special 34367 section, to indicate whether or not an object file relies on the 34368 stack being executable. If your system uses this convention, you 34369 should define 'TARGET_ASM_FILE_END' to this function. If you need 34370 to do other things in that hook, have your hook function call this 34371 function. 34372 34373 -- Target Hook: void TARGET_ASM_LTO_START (void) 34374 Output to 'asm_out_file' any text which the assembler expects to 34375 find at the start of an LTO section. The default is to output 34376 nothing. 34377 34378 -- Target Hook: void TARGET_ASM_LTO_END (void) 34379 Output to 'asm_out_file' any text which the assembler expects to 34380 find at the end of an LTO section. The default is to output 34381 nothing. 34382 34383 -- Target Hook: void TARGET_ASM_CODE_END (void) 34384 Output to 'asm_out_file' any text which is needed before emitting 34385 unwind info and debug info at the end of a file. Some targets emit 34386 here PIC setup thunks that cannot be emitted at the end of file, 34387 because they couldn't have unwind info then. The default is to 34388 output nothing. 34389 34390 -- Macro: ASM_COMMENT_START 34391 A C string constant describing how to begin a comment in the target 34392 assembler language. The compiler assumes that the comment will end 34393 at the end of the line. 34394 34395 -- Macro: ASM_APP_ON 34396 A C string constant for text to be output before each 'asm' 34397 statement or group of consecutive ones. Normally this is '"#APP"', 34398 which is a comment that has no effect on most assemblers but tells 34399 the GNU assembler that it must check the lines that follow for all 34400 valid assembler constructs. 34401 34402 -- Macro: ASM_APP_OFF 34403 A C string constant for text to be output after each 'asm' 34404 statement or group of consecutive ones. Normally this is 34405 '"#NO_APP"', which tells the GNU assembler to resume making the 34406 time-saving assumptions that are valid for ordinary compiler 34407 output. 34408 34409 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 34410 A C statement to output COFF information or DWARF debugging 34411 information which indicates that filename NAME is the current 34412 source file to the stdio stream STREAM. 34413 34414 This macro need not be defined if the standard form of output for 34415 the file format in use is appropriate. 34416 34417 -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE, 34418 const char *NAME) 34419 Output COFF information or DWARF debugging information which 34420 indicates that filename NAME is the current source file to the 34421 stdio stream FILE. 34422 34423 This target hook need not be defined if the standard form of output 34424 for the file format in use is appropriate. 34425 34426 -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME) 34427 Output a string based on NAME, suitable for the '#ident' directive, 34428 or the equivalent directive or pragma in non-C-family languages. 34429 If this hook is not defined, nothing is output for the '#ident' 34430 directive. 34431 34432 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 34433 A C statement to output the string STRING to the stdio stream 34434 STREAM. If you do not call the function 'output_quoted_string' in 34435 your config files, GCC will only call it to output filenames to the 34436 assembler source. So you can use it to canonicalize the format of 34437 the filename using this macro. 34438 34439 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 34440 unsigned int FLAGS, tree DECL) 34441 Output assembly directives to switch to section NAME. The section 34442 should have attributes as specified by FLAGS, which is a bit mask 34443 of the 'SECTION_*' flags defined in 'output.h'. If DECL is 34444 non-NULL, it is the 'VAR_DECL' or 'FUNCTION_DECL' with which this 34445 section is associated. 34446 34447 -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum 34448 node_frequency FREQ, bool STARTUP, bool EXIT) 34449 Return preferred text (sub)section for function DECL. Main purpose 34450 of this function is to separate cold, normal and hot functions. 34451 STARTUP is true when function is known to be used only at startup 34452 (from static constructors or it is 'main()'). EXIT is true when 34453 function is known to be used only at exit (from static 34454 destructors). Return NULL if function should go to default text 34455 section. 34456 34457 -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE 34458 *FILE, tree DECL, bool NEW_IS_COLD) 34459 Used by the target to emit any assembler directives or additional 34460 labels needed when a function is partitioned between different 34461 sections. Output should be written to FILE. The function decl is 34462 available as DECL and the new section is 'cold' if NEW_IS_COLD is 34463 'true'. 34464 34465 -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 34466 This flag is true if the target supports 34467 'TARGET_ASM_NAMED_SECTION'. It must not be modified by 34468 command-line option processing. 34469 34470 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 34471 This flag is true if we can create zeroed data by switching to a 34472 BSS section and then using 'ASM_OUTPUT_SKIP' to allocate the space. 34473 This is true on most ELF targets. 34474 34475 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 34476 const char *NAME, int RELOC) 34477 Choose a set of section attributes for use by 34478 'TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 34479 section name, and whether or not the declaration's initializer may 34480 contain runtime relocations. DECL may be null, in which case 34481 read-write data should be assumed. 34482 34483 The default version of this function handles choosing code vs data, 34484 read-only vs read-write data, and 'flag_pic'. You should only need 34485 to override this if your target has special flags that might be set 34486 via '__attribute__'. 34487 34488 -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type 34489 TYPE, const char *TEXT) 34490 Provides the target with the ability to record the gcc command line 34491 switches that have been passed to the compiler, and options that 34492 are enabled. The TYPE argument specifies what is being recorded. 34493 It can take the following values: 34494 34495 'SWITCH_TYPE_PASSED' 34496 TEXT is a command line switch that has been set by the user. 34497 34498 'SWITCH_TYPE_ENABLED' 34499 TEXT is an option which has been enabled. This might be as a 34500 direct result of a command line switch, or because it is 34501 enabled by default or because it has been enabled as a side 34502 effect of a different command line switch. For example, the 34503 '-O2' switch enables various different individual optimization 34504 passes. 34505 34506 'SWITCH_TYPE_DESCRIPTIVE' 34507 TEXT is either NULL or some descriptive text which should be 34508 ignored. If TEXT is NULL then it is being used to warn the 34509 target hook that either recording is starting or ending. The 34510 first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL, 34511 the warning is for start up and the second time the warning is 34512 for wind down. This feature is to allow the target hook to 34513 make any necessary preparations before it starts to record 34514 switches and to perform any necessary tidying up after it has 34515 finished recording switches. 34516 34517 'SWITCH_TYPE_LINE_START' 34518 This option can be ignored by this target hook. 34519 34520 'SWITCH_TYPE_LINE_END' 34521 This option can be ignored by this target hook. 34522 34523 The hook's return value must be zero. Other return values may be 34524 supported in the future. 34525 34526 By default this hook is set to NULL, but an example implementation 34527 is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES, 34528 it records the switches as ASCII text inside a new, string 34529 mergeable section in the assembler output file. The name of the 34530 new section is provided by the 34531 'TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook. 34532 34533 -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION 34534 This is the name of the section that will be created by the example 34535 ELF implementation of the 'TARGET_ASM_RECORD_GCC_SWITCHES' target 34536 hook. 34537 34538 34539File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 34540 3454117.20.2 Output of Data 34542---------------------- 34543 34544 -- Target Hook: const char * TARGET_ASM_BYTE_OP 34545 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 34546 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 34547 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 34548 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 34549 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 34550 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 34551 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 34552 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 34553 These hooks specify assembly directives for creating certain kinds 34554 of integer object. The 'TARGET_ASM_BYTE_OP' directive creates a 34555 byte-sized object, the 'TARGET_ASM_ALIGNED_HI_OP' one creates an 34556 aligned two-byte object, and so on. Any of the hooks may be 34557 'NULL', indicating that no suitable directive is available. 34558 34559 The compiler will print these strings at the start of a new line, 34560 followed immediately by the object's initial value. In most cases, 34561 the string should contain a tab, a pseudo-op, and then another tab. 34562 34563 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 34564 ALIGNED_P) 34565 The 'assemble_integer' function uses this hook to output an integer 34566 object. X is the object's value, SIZE is its size in bytes and 34567 ALIGNED_P indicates whether it is aligned. The function should 34568 return 'true' if it was able to output the object. If it returns 34569 false, 'assemble_integer' will try to split the object into smaller 34570 parts. 34571 34572 The default implementation of this hook will use the 34573 'TARGET_ASM_BYTE_OP' family of strings, returning 'false' when the 34574 relevant string is 'NULL'. 34575 34576 -- Target Hook: void TARGET_ASM_DECL_END (void) 34577 Define this hook if the target assembler requires a special marker 34578 to terminate an initialized variable declaration. 34579 34580 -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE, 34581 rtx X) 34582 A target hook to recognize RTX patterns that 'output_addr_const' 34583 can't deal with, and output assembly code to FILE corresponding to 34584 the pattern X. This may be used to allow machine-dependent 34585 'UNSPEC's to appear within constants. 34586 34587 If target hook fails to recognize a pattern, it must return 34588 'false', so that a standard error message is printed. If it prints 34589 an error message itself, by calling, for example, 34590 'output_operand_lossage', it may just return 'true'. 34591 34592 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 34593 A C statement to output to the stdio stream STREAM an assembler 34594 instruction to assemble a string constant containing the LEN bytes 34595 at PTR. PTR will be a C expression of type 'char *' and LEN a C 34596 expression of type 'int'. 34597 34598 If the assembler has a '.ascii' pseudo-op as found in the Berkeley 34599 Unix assembler, do not define the macro 'ASM_OUTPUT_ASCII'. 34600 34601 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 34602 A C statement to output word N of a function descriptor for DECL. 34603 This must be defined if 'TARGET_VTABLE_USES_DESCRIPTORS' is 34604 defined, and is otherwise unused. 34605 34606 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 34607 You may define this macro as a C expression. You should define the 34608 expression to have a nonzero value if GCC should output the 34609 constant pool for a function before the code for the function, or a 34610 zero value if GCC should output the constant pool after the 34611 function. If you do not define this macro, the usual case, GCC 34612 will output the constant pool before the function. 34613 34614 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 34615 A C statement to output assembler commands to define the start of 34616 the constant pool for a function. FUNNAME is a string giving the 34617 name of the function. Should the return type of the function be 34618 required, it can be obtained via FUNDECL. SIZE is the size, in 34619 bytes, of the constant pool that will be written immediately after 34620 this call. 34621 34622 If no constant-pool prefix is required, the usual case, this macro 34623 need not be defined. 34624 34625 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO, 34626 JUMPTO) 34627 A C statement (with or without semicolon) to output a constant in 34628 the constant pool, if it needs special treatment. (This macro need 34629 not do anything for RTL expressions that can be output normally.) 34630 34631 The argument FILE is the standard I/O stream to output the 34632 assembler code on. X is the RTL expression for the constant to 34633 output, and MODE is the machine mode (in case X is a 'const_int'). 34634 ALIGN is the required alignment for the value X; you should output 34635 an assembler directive to force this much alignment. 34636 34637 The argument LABELNO is a number to use in an internal label for 34638 the address of this pool entry. The definition of this macro is 34639 responsible for outputting the label definition at the proper 34640 place. Here is how to do this: 34641 34642 (*targetm.asm_out.internal_label) (FILE, "LC", LABELNO); 34643 34644 When you output a pool entry specially, you should end with a 34645 'goto' to the label JUMPTO. This will prevent the same pool entry 34646 from being output a second time in the usual manner. 34647 34648 You need not define this macro if it would do nothing. 34649 34650 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 34651 A C statement to output assembler commands to at the end of the 34652 constant pool for a function. FUNNAME is a string giving the name 34653 of the function. Should the return type of the function be 34654 required, you can obtain it via FUNDECL. SIZE is the size, in 34655 bytes, of the constant pool that GCC wrote immediately before this 34656 call. 34657 34658 If no constant-pool epilogue is required, the usual case, you need 34659 not define this macro. 34660 34661 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR) 34662 Define this macro as a C expression which is nonzero if C is used 34663 as a logical line separator by the assembler. STR points to the 34664 position in the string where C was found; this can be used if a 34665 line separator uses multiple characters. 34666 34667 If you do not define this macro, the default is that only the 34668 character ';' is treated as a logical line separator. 34669 34670 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 34671 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 34672 These target hooks are C string constants, describing the syntax in 34673 the assembler for grouping arithmetic expressions. If not 34674 overridden, they default to normal parentheses, which is correct 34675 for most assemblers. 34676 34677 These macros are provided by 'real.h' for writing the definitions of 34678'ASM_OUTPUT_DOUBLE' and the like: 34679 34680 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 34681 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 34682 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 34683 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 34684 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 34685 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 34686 These translate X, of type 'REAL_VALUE_TYPE', to the target's 34687 floating point representation, and store its bit pattern in the 34688 variable L. For 'REAL_VALUE_TO_TARGET_SINGLE' and 34689 'REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 34690 'long int'. For the others, it should be an array of 'long int'. 34691 The number of elements in this array is determined by the size of 34692 the desired target floating point data type: 32 bits of it go in 34693 each 'long int' array element. Each array element holds 32 bits of 34694 the result, even if 'long int' is wider than 32 bits on the host 34695 machine. 34696 34697 The array element values are designed so that you can print them 34698 out using 'fprintf' in the order they should appear in the target 34699 machine's memory. 34700 34701 34702File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 34703 3470417.20.3 Output of Uninitialized Variables 34705----------------------------------------- 34706 34707Each of the macros in this section is used to do the whole job of 34708outputting a single uninitialized variable. 34709 34710 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 34711 A C statement (sans semicolon) to output to the stdio stream STREAM 34712 the assembler definition of a common-label named NAME whose size is 34713 SIZE bytes. The variable ROUNDED is the size rounded up to 34714 whatever alignment the caller wants. It is possible that SIZE may 34715 be zero, for instance if a struct with no other member than a 34716 zero-length array is defined. In this case, the backend must 34717 output a symbol definition that allocates at least one byte, both 34718 so that the address of the resulting object does not compare equal 34719 to any other, and because some object formats cannot even express 34720 the concept of a zero-sized common symbol, as that is how they 34721 represent an ordinary undefined external. 34722 34723 Use the expression 'assemble_name (STREAM, NAME)' to output the 34724 name itself; before and after that, output the additional assembler 34725 syntax for defining the name, and a newline. 34726 34727 This macro controls how the assembler definitions of uninitialized 34728 common global variables are output. 34729 34730 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 34731 Like 'ASM_OUTPUT_COMMON' except takes the required alignment as a 34732 separate, explicit argument. If you define this macro, it is used 34733 in place of 'ASM_OUTPUT_COMMON', and gives you more flexibility in 34734 handling the required alignment of the variable. The alignment is 34735 specified as the number of bits. 34736 34737 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 34738 ALIGNMENT) 34739 Like 'ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 34740 to be output, if there is one, or 'NULL_TREE' if there is no 34741 corresponding variable. If you define this macro, GCC will use it 34742 in place of both 'ASM_OUTPUT_COMMON' and 34743 'ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 34744 see the variable's decl in order to chose what to output. 34745 34746 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 34747 A C statement (sans semicolon) to output to the stdio stream STREAM 34748 the assembler definition of uninitialized global DECL named NAME 34749 whose size is SIZE bytes. The variable ALIGNMENT is the alignment 34750 specified as the number of bits. 34751 34752 Try to use function 'asm_output_aligned_bss' defined in file 34753 'varasm.c' when defining this macro. If unable, use the expression 34754 'assemble_name (STREAM, NAME)' to output the name itself; before 34755 and after that, output the additional assembler syntax for defining 34756 the name, and a newline. 34757 34758 There are two ways of handling global BSS. One is to define this 34759 macro. The other is to have 'TARGET_ASM_SELECT_SECTION' return a 34760 switchable BSS section (*note 34761 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 34762 both. 34763 34764 Some languages do not have 'common' data, and require a non-common 34765 form of global BSS in order to handle uninitialized globals 34766 efficiently. C++ is one example of this. However, if the target 34767 does not support global BSS, the front end may choose to make 34768 globals common in order to save space in the object file. 34769 34770 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 34771 A C statement (sans semicolon) to output to the stdio stream STREAM 34772 the assembler definition of a local-common-label named NAME whose 34773 size is SIZE bytes. The variable ROUNDED is the size rounded up to 34774 whatever alignment the caller wants. 34775 34776 Use the expression 'assemble_name (STREAM, NAME)' to output the 34777 name itself; before and after that, output the additional assembler 34778 syntax for defining the name, and a newline. 34779 34780 This macro controls how the assembler definitions of uninitialized 34781 static variables are output. 34782 34783 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 34784 Like 'ASM_OUTPUT_LOCAL' except takes the required alignment as a 34785 separate, explicit argument. If you define this macro, it is used 34786 in place of 'ASM_OUTPUT_LOCAL', and gives you more flexibility in 34787 handling the required alignment of the variable. The alignment is 34788 specified as the number of bits. 34789 34790 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 34791 ALIGNMENT) 34792 Like 'ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to 34793 be output, if there is one, or 'NULL_TREE' if there is no 34794 corresponding variable. If you define this macro, GCC will use it 34795 in place of both 'ASM_OUTPUT_DECL' and 'ASM_OUTPUT_ALIGNED_DECL'. 34796 Define this macro when you need to see the variable's decl in order 34797 to chose what to output. 34798 34799 34800File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 34801 3480217.20.4 Output and Generation of Labels 34803--------------------------------------- 34804 34805This is about outputting labels. 34806 34807 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 34808 A C statement (sans semicolon) to output to the stdio stream STREAM 34809 the assembler definition of a label named NAME. Use the expression 34810 'assemble_name (STREAM, NAME)' to output the name itself; before 34811 and after that, output the additional assembler syntax for defining 34812 the name, and a newline. A default definition of this macro is 34813 provided which is correct for most systems. 34814 34815 -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL) 34816 A C statement (sans semicolon) to output to the stdio stream STREAM 34817 the assembler definition of a label named NAME of a function. Use 34818 the expression 'assemble_name (STREAM, NAME)' to output the name 34819 itself; before and after that, output the additional assembler 34820 syntax for defining the name, and a newline. A default definition 34821 of this macro is provided which is correct for most systems. 34822 34823 If this macro is not defined, then the function name is defined in 34824 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 34825 34826 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 34827 Identical to 'ASM_OUTPUT_LABEL', except that NAME is known to refer 34828 to a compiler-generated label. The default definition uses 34829 'assemble_name_raw', which is like 'assemble_name' except that it 34830 is more efficient. 34831 34832 -- Macro: SIZE_ASM_OP 34833 A C string containing the appropriate assembler directive to 34834 specify the size of a symbol, without any arguments. On systems 34835 that use ELF, the default (in 'config/elfos.h') is '"\t.size\t"'; 34836 on other systems, the default is not to define this macro. 34837 34838 Define this macro only if it is correct to use the default 34839 definitions of 'ASM_OUTPUT_SIZE_DIRECTIVE' and 34840 'ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 34841 custom definitions of those macros, or if you do not need explicit 34842 symbol sizes at all, do not define this macro. 34843 34844 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 34845 A C statement (sans semicolon) to output to the stdio stream STREAM 34846 a directive telling the assembler that the size of the symbol NAME 34847 is SIZE. SIZE is a 'HOST_WIDE_INT'. If you define 'SIZE_ASM_OP', 34848 a default definition of this macro is provided. 34849 34850 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 34851 A C statement (sans semicolon) to output to the stdio stream STREAM 34852 a directive telling the assembler to calculate the size of the 34853 symbol NAME by subtracting its address from the current address. 34854 34855 If you define 'SIZE_ASM_OP', a default definition of this macro is 34856 provided. The default assumes that the assembler recognizes a 34857 special '.' symbol as referring to the current address, and can 34858 calculate the difference between this and another symbol. If your 34859 assembler does not recognize '.' or cannot do calculations with it, 34860 you will need to redefine 'ASM_OUTPUT_MEASURED_SIZE' to use some 34861 other technique. 34862 34863 -- Macro: NO_DOLLAR_IN_LABEL 34864 Define this macro if the assembler does not accept the character 34865 '$' in label names. By default constructors and destructors in G++ 34866 have '$' in the identifiers. If this macro is defined, '.' is used 34867 instead. 34868 34869 -- Macro: NO_DOT_IN_LABEL 34870 Define this macro if the assembler does not accept the character 34871 '.' in label names. By default constructors and destructors in G++ 34872 have names that use '.'. If this macro is defined, these names are 34873 rewritten to avoid '.'. 34874 34875 -- Macro: TYPE_ASM_OP 34876 A C string containing the appropriate assembler directive to 34877 specify the type of a symbol, without any arguments. On systems 34878 that use ELF, the default (in 'config/elfos.h') is '"\t.type\t"'; 34879 on other systems, the default is not to define this macro. 34880 34881 Define this macro only if it is correct to use the default 34882 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 34883 need your own custom definition of this macro, or if you do not 34884 need explicit symbol types at all, do not define this macro. 34885 34886 -- Macro: TYPE_OPERAND_FMT 34887 A C string which specifies (using 'printf' syntax) the format of 34888 the second operand to 'TYPE_ASM_OP'. On systems that use ELF, the 34889 default (in 'config/elfos.h') is '"@%s"'; on other systems, the 34890 default is not to define this macro. 34891 34892 Define this macro only if it is correct to use the default 34893 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 34894 need your own custom definition of this macro, or if you do not 34895 need explicit symbol types at all, do not define this macro. 34896 34897 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 34898 A C statement (sans semicolon) to output to the stdio stream STREAM 34899 a directive telling the assembler that the type of the symbol NAME 34900 is TYPE. TYPE is a C string; currently, that string is always 34901 either '"function"' or '"object"', but you should not count on 34902 this. 34903 34904 If you define 'TYPE_ASM_OP' and 'TYPE_OPERAND_FMT', a default 34905 definition of this macro is provided. 34906 34907 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 34908 A C statement (sans semicolon) to output to the stdio stream STREAM 34909 any text necessary for declaring the name NAME of a function which 34910 is being defined. This macro is responsible for outputting the 34911 label definition (perhaps using 'ASM_OUTPUT_FUNCTION_LABEL'). The 34912 argument DECL is the 'FUNCTION_DECL' tree node representing the 34913 function. 34914 34915 If this macro is not defined, then the function name is defined in 34916 the usual manner as a label (by means of 34917 'ASM_OUTPUT_FUNCTION_LABEL'). 34918 34919 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 34920 of this macro. 34921 34922 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 34923 A C statement (sans semicolon) to output to the stdio stream STREAM 34924 any text necessary for declaring the size of a function which is 34925 being defined. The argument NAME is the name of the function. The 34926 argument DECL is the 'FUNCTION_DECL' tree node representing the 34927 function. 34928 34929 If this macro is not defined, then the function size is not 34930 defined. 34931 34932 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 34933 this macro. 34934 34935 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 34936 A C statement (sans semicolon) to output to the stdio stream STREAM 34937 any text necessary for declaring the name NAME of an initialized 34938 variable which is being defined. This macro must output the label 34939 definition (perhaps using 'ASM_OUTPUT_LABEL'). The argument DECL 34940 is the 'VAR_DECL' tree node representing the variable. 34941 34942 If this macro is not defined, then the variable name is defined in 34943 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 34944 34945 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' and/or 34946 'ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 34947 34948 -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE, 34949 const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE) 34950 A target hook to output to the stdio stream FILE any text necessary 34951 for declaring the name NAME of a constant which is being defined. 34952 This target hook is responsible for outputting the label definition 34953 (perhaps using 'assemble_label'). The argument EXP is the value of 34954 the constant, and SIZE is the size of the constant in bytes. The 34955 NAME will be an internal label. 34956 34957 The default version of this target hook, define the NAME in the 34958 usual manner as a label (by means of 'assemble_label'). 34959 34960 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in this target 34961 hook. 34962 34963 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 34964 A C statement (sans semicolon) to output to the stdio stream STREAM 34965 any text necessary for claiming a register REGNO for a global 34966 variable DECL with name NAME. 34967 34968 If you don't define this macro, that is equivalent to defining it 34969 to do nothing. 34970 34971 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 34972 A C statement (sans semicolon) to finish up declaring a variable 34973 name once the compiler has processed its initializer fully and thus 34974 has had a chance to determine the size of an array when controlled 34975 by an initializer. This is used on systems where it's necessary to 34976 declare something about the size of the object. 34977 34978 If you don't define this macro, that is equivalent to defining it 34979 to do nothing. 34980 34981 You may wish to use 'ASM_OUTPUT_SIZE_DIRECTIVE' and/or 34982 'ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 34983 34984 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 34985 char *NAME) 34986 This target hook is a function to output to the stdio stream STREAM 34987 some commands that will make the label NAME global; that is, 34988 available for reference from other files. 34989 34990 The default implementation relies on a proper definition of 34991 'GLOBAL_ASM_OP'. 34992 34993 -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, tree 34994 DECL) 34995 This target hook is a function to output to the stdio stream STREAM 34996 some commands that will make the name associated with DECL global; 34997 that is, available for reference from other files. 34998 34999 The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL 35000 target hook. 35001 35002 -- Target Hook: void TARGET_ASM_ASSEMBLE_UNDEFINED_DECL (FILE *STREAM, 35003 const char *NAME, const_tree DECL) 35004 This target hook is a function to output to the stdio stream STREAM 35005 some commands that will declare the name associated with DECL which 35006 is not defined in the current translation unit. Most assemblers do 35007 not require anything to be output in this case. 35008 35009 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 35010 A C statement (sans semicolon) to output to the stdio stream STREAM 35011 some commands that will make the label NAME weak; that is, 35012 available for reference from other files but only used if no other 35013 definition is available. Use the expression 'assemble_name 35014 (STREAM, NAME)' to output the name itself; before and after that, 35015 output the additional assembler syntax for making that name weak, 35016 and a newline. 35017 35018 If you don't define this macro or 'ASM_WEAKEN_DECL', GCC will not 35019 support weak symbols and you should not define the 'SUPPORTS_WEAK' 35020 macro. 35021 35022 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 35023 Combines (and replaces) the function of 'ASM_WEAKEN_LABEL' and 35024 'ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 35025 or variable decl. If VALUE is not 'NULL', this C statement should 35026 output to the stdio stream STREAM assembler code which defines 35027 (equates) the weak symbol NAME to have the value VALUE. If VALUE 35028 is 'NULL', it should output commands to make NAME weak. 35029 35030 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 35031 Outputs a directive that enables NAME to be used to refer to symbol 35032 VALUE with weak-symbol semantics. 'decl' is the declaration of 35033 'name'. 35034 35035 -- Macro: SUPPORTS_WEAK 35036 A preprocessor constant expression which evaluates to true if the 35037 target supports weak symbols. 35038 35039 If you don't define this macro, 'defaults.h' provides a default 35040 definition. If either 'ASM_WEAKEN_LABEL' or 'ASM_WEAKEN_DECL' is 35041 defined, the default definition is '1'; otherwise, it is '0'. 35042 35043 -- Macro: TARGET_SUPPORTS_WEAK 35044 A C expression which evaluates to true if the target supports weak 35045 symbols. 35046 35047 If you don't define this macro, 'defaults.h' provides a default 35048 definition. The default definition is '(SUPPORTS_WEAK)'. Define 35049 this macro if you want to control weak symbol support with a 35050 compiler flag such as '-melf'. 35051 35052 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 35053 A C statement (sans semicolon) to mark DECL to be emitted as a 35054 public symbol such that extra copies in multiple translation units 35055 will be discarded by the linker. Define this macro if your object 35056 file format provides support for this concept, such as the 'COMDAT' 35057 section flags in the Microsoft Windows PE/COFF format, and this 35058 support requires changes to DECL, such as putting it in a separate 35059 section. 35060 35061 -- Macro: SUPPORTS_ONE_ONLY 35062 A C expression which evaluates to true if the target supports 35063 one-only semantics. 35064 35065 If you don't define this macro, 'varasm.c' provides a default 35066 definition. If 'MAKE_DECL_ONE_ONLY' is defined, the default 35067 definition is '1'; otherwise, it is '0'. Define this macro if you 35068 want to control one-only symbol support with a compiler flag, or if 35069 setting the 'DECL_ONE_ONLY' flag is enough to mark a declaration to 35070 be emitted as one-only. 35071 35072 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int 35073 VISIBILITY) 35074 This target hook is a function to output to ASM_OUT_FILE some 35075 commands that will make the symbol(s) associated with DECL have 35076 hidden, protected or internal visibility as specified by 35077 VISIBILITY. 35078 35079 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 35080 A C expression that evaluates to true if the target's linker 35081 expects that weak symbols do not appear in a static archive's table 35082 of contents. The default is '0'. 35083 35084 Leaving weak symbols out of an archive's table of contents means 35085 that, if a symbol will only have a definition in one translation 35086 unit and will have undefined references from other translation 35087 units, that symbol should not be weak. Defining this macro to be 35088 nonzero will thus have the effect that certain symbols that would 35089 normally be weak (explicit template instantiations, and vtables for 35090 polymorphic classes with noninline key methods) will instead be 35091 nonweak. 35092 35093 The C++ ABI requires this macro to be zero. Define this macro for 35094 targets where full C++ ABI compliance is impossible and where 35095 linker restrictions require weak symbols to be left out of a static 35096 archive's table of contents. 35097 35098 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 35099 A C statement (sans semicolon) to output to the stdio stream STREAM 35100 any text necessary for declaring the name of an external symbol 35101 named NAME which is referenced in this compilation but not defined. 35102 The value of DECL is the tree node for the declaration. 35103 35104 This macro need not be defined if it does not need to output 35105 anything. The GNU assembler and most Unix assemblers don't require 35106 anything. 35107 35108 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 35109 This target hook is a function to output to ASM_OUT_FILE an 35110 assembler pseudo-op to declare a library function name external. 35111 The name of the library function is given by SYMREF, which is a 35112 'symbol_ref'. 35113 35114 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char 35115 *SYMBOL) 35116 This target hook is a function to output to ASM_OUT_FILE an 35117 assembler directive to annotate SYMBOL as used. The Darwin target 35118 uses the .no_dead_code_strip directive. 35119 35120 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 35121 A C statement (sans semicolon) to output to the stdio stream STREAM 35122 a reference in assembler syntax to a label named NAME. This should 35123 add '_' to the front of the name, if that is customary on your 35124 operating system, as it is in most Berkeley Unix systems. This 35125 macro is used in 'assemble_name'. 35126 35127 -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME) 35128 Given a symbol NAME, perform same mangling as 'varasm.c''s 35129 'assemble_name', but in memory rather than to a file stream, 35130 returning result as an 'IDENTIFIER_NODE'. Required for correct LTO 35131 symtabs. The default implementation calls the 35132 'TARGET_STRIP_NAME_ENCODING' hook and then prepends the 35133 'USER_LABEL_PREFIX', if any. 35134 35135 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 35136 A C statement (sans semicolon) to output a reference to 35137 'SYMBOL_REF' SYM. If not defined, 'assemble_name' will be used to 35138 output the name of the symbol. This macro may be used to modify 35139 the way a symbol is referenced depending on information encoded by 35140 'TARGET_ENCODE_SECTION_INFO'. 35141 35142 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 35143 A C statement (sans semicolon) to output a reference to BUF, the 35144 result of 'ASM_GENERATE_INTERNAL_LABEL'. If not defined, 35145 'assemble_name' will be used to output the name of the symbol. 35146 This macro is not used by 'output_asm_label', or the '%l' specifier 35147 that calls it; the intention is that this macro should be set when 35148 it is necessary to output a label differently when its address is 35149 being taken. 35150 35151 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 35152 char *PREFIX, unsigned long LABELNO) 35153 A function to output to the stdio stream STREAM a label whose name 35154 is made from the string PREFIX and the number LABELNO. 35155 35156 It is absolutely essential that these labels be distinct from the 35157 labels used for user-level functions and variables. Otherwise, 35158 certain programs will have name conflicts with internal labels. 35159 35160 It is desirable to exclude internal labels from the symbol table of 35161 the object file. Most assemblers have a naming convention for 35162 labels that should be excluded; on many systems, the letter 'L' at 35163 the beginning of a label has this effect. You should find out what 35164 convention your system uses, and follow it. 35165 35166 The default version of this function utilizes 35167 'ASM_GENERATE_INTERNAL_LABEL'. 35168 35169 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 35170 A C statement to output to the stdio stream STREAM a debug info 35171 label whose name is made from the string PREFIX and the number NUM. 35172 This is useful for VLIW targets, where debug info labels may need 35173 to be treated differently than branch target labels. On some 35174 systems, branch target labels must be at the beginning of 35175 instruction bundles, but debug info labels can occur in the middle 35176 of instruction bundles. 35177 35178 If this macro is not defined, then 35179 '(*targetm.asm_out.internal_label)' will be used. 35180 35181 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 35182 A C statement to store into the string STRING a label whose name is 35183 made from the string PREFIX and the number NUM. 35184 35185 This string, when output subsequently by 'assemble_name', should 35186 produce the output that '(*targetm.asm_out.internal_label)' would 35187 produce with the same PREFIX and NUM. 35188 35189 If the string begins with '*', then 'assemble_name' will output the 35190 rest of the string unchanged. It is often convenient for 35191 'ASM_GENERATE_INTERNAL_LABEL' to use '*' in this way. If the 35192 string doesn't start with '*', then 'ASM_OUTPUT_LABELREF' gets to 35193 output the string, and may change it. (Of course, 35194 'ASM_OUTPUT_LABELREF' is also part of your machine description, so 35195 you should know what it does on your machine.) 35196 35197 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 35198 A C expression to assign to OUTVAR (which is a variable of type 35199 'char *') a newly allocated string made from the string NAME and 35200 the number NUMBER, with some suitable punctuation added. Use 35201 'alloca' to get space for the string. 35202 35203 The string will be used as an argument to 'ASM_OUTPUT_LABELREF' to 35204 produce an assembler label for an internal static variable whose 35205 name is NAME. Therefore, the string must be such as to result in 35206 valid assembler code. The argument NUMBER is different each time 35207 this macro is executed; it prevents conflicts between 35208 similarly-named internal static variables in different scopes. 35209 35210 Ideally this string should not be a valid C identifier, to prevent 35211 any conflict with the user's own symbols. Most assemblers allow 35212 periods or percent signs in assembler symbols; putting at least one 35213 of these between the name and the number will suffice. 35214 35215 If this macro is not defined, a default definition will be provided 35216 which is correct for most systems. 35217 35218 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 35219 A C statement to output to the stdio stream STREAM assembler code 35220 which defines (equates) the symbol NAME to have the value VALUE. 35221 35222 If 'SET_ASM_OP' is defined, a default definition is provided which 35223 is correct for most systems. 35224 35225 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 35226 DECL_OF_VALUE) 35227 A C statement to output to the stdio stream STREAM assembler code 35228 which defines (equates) the symbol whose tree node is DECL_OF_NAME 35229 to have the value of the tree node DECL_OF_VALUE. This macro will 35230 be used in preference to 'ASM_OUTPUT_DEF' if it is defined and if 35231 the tree nodes are available. 35232 35233 If 'SET_ASM_OP' is defined, a default definition is provided which 35234 is correct for most systems. 35235 35236 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 35237 A C statement that evaluates to true if the assembler code which 35238 defines (equates) the symbol whose tree node is DECL_OF_NAME to 35239 have the value of the tree node DECL_OF_VALUE should be emitted 35240 near the end of the current compilation unit. The default is to 35241 not defer output of defines. This macro affects defines output by 35242 'ASM_OUTPUT_DEF' and 'ASM_OUTPUT_DEF_FROM_DECLS'. 35243 35244 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 35245 A C statement to output to the stdio stream STREAM assembler code 35246 which defines (equates) the weak symbol NAME to have the value 35247 VALUE. If VALUE is 'NULL', it defines NAME as an undefined weak 35248 symbol. 35249 35250 Define this macro if the target only supports weak aliases; define 35251 'ASM_OUTPUT_DEF' instead if possible. 35252 35253 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 35254 SEL_NAME) 35255 Define this macro to override the default assembler names used for 35256 Objective-C methods. 35257 35258 The default name is a unique method number followed by the name of 35259 the class (e.g. '_1_Foo'). For methods in categories, the name of 35260 the category is also included in the assembler name (e.g. 35261 '_1_Foo_Bar'). 35262 35263 These names are safe on most systems, but make debugging difficult 35264 since the method's selector is not present in the name. Therefore, 35265 particular systems define other ways of computing names. 35266 35267 BUF is an expression of type 'char *' which gives you a buffer in 35268 which to store the name; its length is as long as CLASS_NAME, 35269 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 35270 35271 The argument IS_INST specifies whether the method is an instance 35272 method or a class method; CLASS_NAME is the name of the class; 35273 CAT_NAME is the name of the category (or 'NULL' if the method is 35274 not in a category); and SEL_NAME is the name of the selector. 35275 35276 On systems where the assembler can handle quoted names, you can use 35277 this macro to provide more human-readable names. 35278 35279 35280File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 35281 3528217.20.5 How Initialization Functions Are Handled 35283------------------------------------------------ 35284 35285The compiled code for certain languages includes "constructors" (also 35286called "initialization routines")--functions to initialize data in the 35287program when the program is started. These functions need to be called 35288before the program is "started"--that is to say, before 'main' is 35289called. 35290 35291 Compiling some languages generates "destructors" (also called 35292"termination routines") that should be called when the program 35293terminates. 35294 35295 To make the initialization and termination functions work, the compiler 35296must output something in the assembler code to cause those functions to 35297be called at the appropriate time. When you port the compiler to a new 35298system, you need to specify how to do this. 35299 35300 There are two major ways that GCC currently supports the execution of 35301initialization and termination functions. Each way has two variants. 35302Much of the structure is common to all four variations. 35303 35304 The linker must build two lists of these functions--a list of 35305initialization functions, called '__CTOR_LIST__', and a list of 35306termination functions, called '__DTOR_LIST__'. 35307 35308 Each list always begins with an ignored function pointer (which may 35309hold 0, -1, or a count of the function pointers after it, depending on 35310the environment). This is followed by a series of zero or more function 35311pointers to constructors (or destructors), followed by a function 35312pointer containing zero. 35313 35314 Depending on the operating system and its executable file format, 35315either 'crtstuff.c' or 'libgcc2.c' traverses these lists at startup time 35316and exit time. Constructors are called in reverse order of the list; 35317destructors in forward order. 35318 35319 The best way to handle static constructors works only for object file 35320formats which provide arbitrarily-named sections. A section is set 35321aside for a list of constructors, and another for a list of destructors. 35322Traditionally these are called '.ctors' and '.dtors'. Each object file 35323that defines an initialization function also puts a word in the 35324constructor section to point to that function. The linker accumulates 35325all these words into one contiguous '.ctors' section. Termination 35326functions are handled similarly. 35327 35328 This method will be chosen as the default by 'target-def.h' if 35329'TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 35330arbitrary sections, but does support special designated constructor and 35331destructor sections may define 'CTORS_SECTION_ASM_OP' and 35332'DTORS_SECTION_ASM_OP' to achieve the same effect. 35333 35334 When arbitrary sections are available, there are two variants, 35335depending upon how the code in 'crtstuff.c' is called. On systems that 35336support a ".init" section which is executed at program startup, parts of 35337'crtstuff.c' are compiled into that section. The program is linked by 35338the 'gcc' driver like this: 35339 35340 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 35341 35342 The prologue of a function ('__init') appears in the '.init' section of 35343'crti.o'; the epilogue appears in 'crtn.o'. Likewise for the function 35344'__fini' in the ".fini" section. Normally these files are provided by 35345the operating system or by the GNU C library, but are provided by GCC 35346for a few targets. 35347 35348 The objects 'crtbegin.o' and 'crtend.o' are (for most targets) compiled 35349from 'crtstuff.c'. They contain, among other things, code fragments 35350within the '.init' and '.fini' sections that branch to routines in the 35351'.text' section. The linker will pull all parts of a section together, 35352which results in a complete '__init' function that invokes the routines 35353we need at startup. 35354 35355 To use this variant, you must define the 'INIT_SECTION_ASM_OP' macro 35356properly. 35357 35358 If no init section is available, when GCC compiles any function called 35359'main' (or more accurately, any function designated as a program entry 35360point by the language front end calling 'expand_main_function'), it 35361inserts a procedure call to '__main' as the first executable code after 35362the function prologue. The '__main' function is defined in 'libgcc2.c' 35363and runs the global constructors. 35364 35365 In file formats that don't support arbitrary sections, there are again 35366two variants. In the simplest variant, the GNU linker (GNU 'ld') and an 35367'a.out' format must be used. In this case, 'TARGET_ASM_CONSTRUCTOR' is 35368defined to produce a '.stabs' entry of type 'N_SETT', referencing the 35369name '__CTOR_LIST__', and with the address of the void function 35370containing the initialization code as its value. The GNU linker 35371recognizes this as a request to add the value to a "set"; the values are 35372accumulated, and are eventually placed in the executable as a vector in 35373the format described above, with a leading (ignored) count and a 35374trailing zero element. 'TARGET_ASM_DESTRUCTOR' is handled similarly. 35375Since no init section is available, the absence of 'INIT_SECTION_ASM_OP' 35376causes the compilation of 'main' to call '__main' as above, starting the 35377initialization process. 35378 35379 The last variant uses neither arbitrary sections nor the GNU linker. 35380This is preferable when you want to do dynamic linking and when using 35381file formats which the GNU linker does not support, such as 'ECOFF'. In 35382this case, 'TARGET_HAVE_CTORS_DTORS' is false, initialization and 35383termination functions are recognized simply by their names. This 35384requires an extra program in the linkage step, called 'collect2'. This 35385program pretends to be the linker, for use with GCC; it does its job by 35386running the ordinary linker, but also arranges to include the vectors of 35387initialization and termination functions. These functions are called 35388via '__main' as described above. In order to use this method, 35389'use_collect2' must be defined in the target in 'config.gcc'. 35390 35391 The following section describes the specific macros that control and 35392customize the handling of initialization and termination functions. 35393 35394 35395File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 35396 3539717.20.6 Macros Controlling Initialization Routines 35398-------------------------------------------------- 35399 35400Here are the macros that control how the compiler handles initialization 35401and termination functions: 35402 35403 -- Macro: INIT_SECTION_ASM_OP 35404 If defined, a C string constant, including spacing, for the 35405 assembler operation to identify the following data as 35406 initialization code. If not defined, GCC will assume such a 35407 section does not exist. When you are using special sections for 35408 initialization and termination functions, this macro also controls 35409 how 'crtstuff.c' and 'libgcc2.c' arrange to run the initialization 35410 functions. 35411 35412 -- Macro: HAS_INIT_SECTION 35413 If defined, 'main' will not call '__main' as described above. This 35414 macro should be defined for systems that control start-up code on a 35415 symbol-by-symbol basis, such as OSF/1, and should not be defined 35416 explicitly for systems that support 'INIT_SECTION_ASM_OP'. 35417 35418 -- Macro: LD_INIT_SWITCH 35419 If defined, a C string constant for a switch that tells the linker 35420 that the following symbol is an initialization routine. 35421 35422 -- Macro: LD_FINI_SWITCH 35423 If defined, a C string constant for a switch that tells the linker 35424 that the following symbol is a finalization routine. 35425 35426 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 35427 If defined, a C statement that will write a function that can be 35428 automatically called when a shared library is loaded. The function 35429 should call FUNC, which takes no arguments. If not defined, and 35430 the object format requires an explicit initialization function, 35431 then a function called '_GLOBAL__DI' will be generated. 35432 35433 This function and the following one are used by collect2 when 35434 linking a shared library that needs constructors or destructors, or 35435 has DWARF2 exception tables embedded in the code. 35436 35437 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 35438 If defined, a C statement that will write a function that can be 35439 automatically called when a shared library is unloaded. The 35440 function should call FUNC, which takes no arguments. If not 35441 defined, and the object format requires an explicit finalization 35442 function, then a function called '_GLOBAL__DD' will be generated. 35443 35444 -- Macro: INVOKE__main 35445 If defined, 'main' will call '__main' despite the presence of 35446 'INIT_SECTION_ASM_OP'. This macro should be defined for systems 35447 where the init section is not actually run automatically, but is 35448 still useful for collecting the lists of constructors and 35449 destructors. 35450 35451 -- Macro: SUPPORTS_INIT_PRIORITY 35452 If nonzero, the C++ 'init_priority' attribute is supported and the 35453 compiler should emit instructions to control the order of 35454 initialization of objects. If zero, the compiler will issue an 35455 error message upon encountering an 'init_priority' attribute. 35456 35457 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 35458 This value is true if the target supports some "native" method of 35459 collecting constructors and destructors to be run at startup and 35460 exit. It is false if we must use 'collect2'. 35461 35462 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 35463 If defined, a function that outputs assembler code to arrange to 35464 call the function referenced by SYMBOL at initialization time. 35465 35466 Assume that SYMBOL is a 'SYMBOL_REF' for a function taking no 35467 arguments and with no return value. If the target supports 35468 initialization priorities, PRIORITY is a value between 0 and 35469 'MAX_INIT_PRIORITY'; otherwise it must be 'DEFAULT_INIT_PRIORITY'. 35470 35471 If this macro is not defined by the target, a suitable default will 35472 be chosen if (1) the target supports arbitrary section names, (2) 35473 the target defines 'CTORS_SECTION_ASM_OP', or (3) 'USE_COLLECT2' is 35474 not defined. 35475 35476 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 35477 This is like 'TARGET_ASM_CONSTRUCTOR' but used for termination 35478 functions rather than initialization functions. 35479 35480 If 'TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 35481generated for the generated object file will have static linkage. 35482 35483 If your system uses 'collect2' as the means of processing constructors, 35484then that program normally uses 'nm' to scan an object file for 35485constructor functions to be called. 35486 35487 On certain kinds of systems, you can define this macro to make 35488'collect2' work faster (and, in some cases, make it work at all): 35489 35490 -- Macro: OBJECT_FORMAT_COFF 35491 Define this macro if the system uses COFF (Common Object File 35492 Format) object files, so that 'collect2' can assume this format and 35493 scan object files directly for dynamic constructor/destructor 35494 functions. 35495 35496 This macro is effective only in a native compiler; 'collect2' as 35497 part of a cross compiler always uses 'nm' for the target machine. 35498 35499 -- Macro: REAL_NM_FILE_NAME 35500 Define this macro as a C string constant containing the file name 35501 to use to execute 'nm'. The default is to search the path normally 35502 for 'nm'. 35503 35504 -- Macro: NM_FLAGS 35505 'collect2' calls 'nm' to scan object files for static constructors 35506 and destructors and LTO info. By default, '-n' is passed. Define 35507 'NM_FLAGS' to a C string constant if other options are needed to 35508 get the same output format as GNU 'nm -n' produces. 35509 35510 If your system supports shared libraries and has a program to list the 35511dynamic dependencies of a given library or executable, you can define 35512these macros to enable support for running initialization and 35513termination functions in shared libraries: 35514 35515 -- Macro: LDD_SUFFIX 35516 Define this macro to a C string constant containing the name of the 35517 program which lists dynamic dependencies, like 'ldd' under SunOS 4. 35518 35519 -- Macro: PARSE_LDD_OUTPUT (PTR) 35520 Define this macro to be C code that extracts filenames from the 35521 output of the program denoted by 'LDD_SUFFIX'. PTR is a variable 35522 of type 'char *' that points to the beginning of a line of output 35523 from 'LDD_SUFFIX'. If the line lists a dynamic dependency, the 35524 code must advance PTR to the beginning of the filename on that 35525 line. Otherwise, it must set PTR to 'NULL'. 35526 35527 -- Macro: SHLIB_SUFFIX 35528 Define this macro to a C string constant containing the default 35529 shared library extension of the target (e.g., '".so"'). 'collect2' 35530 strips version information after this suffix when generating global 35531 constructor and destructor names. This define is only needed on 35532 targets that use 'collect2' to process constructors and 35533 destructors. 35534 35535 35536File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 35537 3553817.20.7 Output of Assembler Instructions 35539---------------------------------------- 35540 35541This describes assembler instruction output. 35542 35543 -- Macro: REGISTER_NAMES 35544 A C initializer containing the assembler's names for the machine 35545 registers, each one as a C string constant. This is what 35546 translates register numbers in the compiler into assembler 35547 language. 35548 35549 -- Macro: ADDITIONAL_REGISTER_NAMES 35550 If defined, a C initializer for an array of structures containing a 35551 name and a register number. This macro defines additional names 35552 for hard registers, thus allowing the 'asm' option in declarations 35553 to refer to registers using alternate names. 35554 35555 -- Macro: OVERLAPPING_REGISTER_NAMES 35556 If defined, a C initializer for an array of structures containing a 35557 name, a register number and a count of the number of consecutive 35558 machine registers the name overlaps. This macro defines additional 35559 names for hard registers, thus allowing the 'asm' option in 35560 declarations to refer to registers using alternate names. Unlike 35561 'ADDITIONAL_REGISTER_NAMES', this macro should be used when the 35562 register name implies multiple underlying registers. 35563 35564 This macro should be used when it is important that a clobber in an 35565 'asm' statement clobbers all the underlying values implied by the 35566 register name. For example, on ARM, clobbering the 35567 double-precision VFP register "d0" implies clobbering both 35568 single-precision registers "s0" and "s1". 35569 35570 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 35571 Define this macro if you are using an unusual assembler that 35572 requires different names for the machine instructions. 35573 35574 The definition is a C statement or statements which output an 35575 assembler instruction opcode to the stdio stream STREAM. The 35576 macro-operand PTR is a variable of type 'char *' which points to 35577 the opcode name in its "internal" form--the form that is written in 35578 the machine description. The definition should output the opcode 35579 name to STREAM, performing any translation you desire, and 35580 increment the variable PTR to point at the end of the opcode so 35581 that it will not be output twice. 35582 35583 In fact, your macro definition may process less than the entire 35584 opcode name, or more than the opcode name; but if you want to 35585 process text that includes '%'-sequences to substitute operands, 35586 you must take care of the substitution yourself. Just be sure to 35587 increment PTR over whatever text should not be output normally. 35588 35589 If you need to look at the operand values, they can be found as the 35590 elements of 'recog_data.operand'. 35591 35592 If the macro definition does nothing, the instruction is output in 35593 the usual way. 35594 35595 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 35596 If defined, a C statement to be executed just prior to the output 35597 of assembler code for INSN, to modify the extracted operands so 35598 they will be output differently. 35599 35600 Here the argument OPVEC is the vector containing the operands 35601 extracted from INSN, and NOPERANDS is the number of elements of the 35602 vector which contain meaningful data for this insn. The contents 35603 of this vector are what will be used to convert the insn template 35604 into assembler code, so you can change the assembler output by 35605 changing the contents of the vector. 35606 35607 This macro is useful when various assembler syntaxes share a single 35608 file of instruction patterns; by defining this macro differently, 35609 you can cause a large class of instructions to be output 35610 differently (such as with rearranged operands). Naturally, 35611 variations in assembler syntax affecting individual insn patterns 35612 ought to be handled by writing conditional output routines in those 35613 patterns. 35614 35615 If this macro is not defined, it is equivalent to a null statement. 35616 35617 -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, 35618 rtx_insn *INSN, rtx *OPVEC, int NOPERANDS) 35619 If defined, this target hook is a function which is executed just 35620 after the output of assembler code for INSN, to change the mode of 35621 the assembler if necessary. 35622 35623 Here the argument OPVEC is the vector containing the operands 35624 extracted from INSN, and NOPERANDS is the number of elements of the 35625 vector which contain meaningful data for this insn. The contents 35626 of this vector are what was used to convert the insn template into 35627 assembler code, so you can change the assembler mode by checking 35628 the contents of the vector. 35629 35630 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 35631 A C compound statement to output to stdio stream STREAM the 35632 assembler syntax for an instruction operand X. X is an RTL 35633 expression. 35634 35635 CODE is a value that can be used to specify one of several ways of 35636 printing the operand. It is used when identical operands must be 35637 printed differently depending on the context. CODE comes from the 35638 '%' specification that was used to request printing of the operand. 35639 If the specification was just '%DIGIT' then CODE is 0; if the 35640 specification was '%LTR DIGIT' then CODE is the ASCII code for LTR. 35641 35642 If X is a register, this macro should print the register's name. 35643 The names can be found in an array 'reg_names' whose type is 'char 35644 *[]'. 'reg_names' is initialized from 'REGISTER_NAMES'. 35645 35646 When the machine description has a specification '%PUNCT' (a '%' 35647 followed by a punctuation character), this macro is called with a 35648 null pointer for X and the punctuation character for CODE. 35649 35650 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 35651 A C expression which evaluates to true if CODE is a valid 35652 punctuation character for use in the 'PRINT_OPERAND' macro. If 35653 'PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 35654 punctuation characters (except for the standard one, '%') are used 35655 in this way. 35656 35657 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 35658 A C compound statement to output to stdio stream STREAM the 35659 assembler syntax for an instruction operand that is a memory 35660 reference whose address is X. X is an RTL expression. 35661 35662 On some machines, the syntax for a symbolic address depends on the 35663 section that the address refers to. On these machines, define the 35664 hook 'TARGET_ENCODE_SECTION_INFO' to store the information into the 35665 'symbol_ref', and then check for it here. *Note Assembler 35666 Format::. 35667 35668 -- Macro: DBR_OUTPUT_SEQEND (FILE) 35669 A C statement, to be executed after all slot-filler instructions 35670 have been output. If necessary, call 'dbr_sequence_length' to 35671 determine the number of slots filled in a sequence (zero if not 35672 currently outputting a sequence), to decide how many no-ops to 35673 output, or whatever. 35674 35675 Don't define this macro if it has nothing to do, but it is helpful 35676 in reading assembly output if the extent of the delay sequence is 35677 made explicit (e.g. with white space). 35678 35679 Note that output routines for instructions with delay slots must be 35680prepared to deal with not being output as part of a sequence (i.e. when 35681the scheduling pass is not run, or when no slot fillers could be found.) 35682The variable 'final_sequence' is null when not processing a sequence, 35683otherwise it contains the 'sequence' rtx being output. 35684 35685 -- Macro: REGISTER_PREFIX 35686 -- Macro: LOCAL_LABEL_PREFIX 35687 -- Macro: USER_LABEL_PREFIX 35688 -- Macro: IMMEDIATE_PREFIX 35689 If defined, C string expressions to be used for the '%R', '%L', 35690 '%U', and '%I' options of 'asm_fprintf' (see 'final.c'). These are 35691 useful when a single 'md' file must support multiple assembler 35692 formats. In that case, the various 'tm.h' files can define these 35693 macros differently. 35694 35695 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 35696 If defined this macro should expand to a series of 'case' 35697 statements which will be parsed inside the 'switch' statement of 35698 the 'asm_fprintf' function. This allows targets to define extra 35699 printf formats which may useful when generating their assembler 35700 statements. Note that uppercase letters are reserved for future 35701 generic extensions to asm_fprintf, and so are not available to 35702 target specific code. The output file is given by the parameter 35703 FILE. The varargs input pointer is ARGPTR and the rest of the 35704 format string, starting the character after the one that is being 35705 switched upon, is pointed to by FORMAT. 35706 35707 -- Macro: ASSEMBLER_DIALECT 35708 If your target supports multiple dialects of assembler language 35709 (such as different opcodes), define this macro as a C expression 35710 that gives the numeric index of the assembler language dialect to 35711 use, with zero as the first variant. 35712 35713 If this macro is defined, you may use constructs of the form 35714 '{option0|option1|option2...}' 35715 in the output templates of patterns (*note Output Template::) or in 35716 the first argument of 'asm_fprintf'. This construct outputs 35717 'option0', 'option1', 'option2', etc., if the value of 35718 'ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 35719 within these strings retain their usual meaning. If there are 35720 fewer alternatives within the braces than the value of 35721 'ASSEMBLER_DIALECT', the construct outputs nothing. If it's needed 35722 to print curly braces or '|' character in assembler output 35723 directly, '%{', '%}' and '%|' can be used. 35724 35725 If you do not define this macro, the characters '{', '|' and '}' do 35726 not have any special meaning when used in templates or operands to 35727 'asm_fprintf'. 35728 35729 Define the macros 'REGISTER_PREFIX', 'LOCAL_LABEL_PREFIX', 35730 'USER_LABEL_PREFIX' and 'IMMEDIATE_PREFIX' if you can express the 35731 variations in assembler language syntax with that mechanism. 35732 Define 'ASSEMBLER_DIALECT' and use the '{option0|option1}' syntax 35733 if the syntax variant are larger and involve such things as 35734 different opcodes or operand order. 35735 35736 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 35737 A C expression to output to STREAM some assembler code which will 35738 push hard register number REGNO onto the stack. The code need not 35739 be optimal, since this macro is used only when profiling. 35740 35741 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 35742 A C expression to output to STREAM some assembler code which will 35743 pop hard register number REGNO off of the stack. The code need not 35744 be optimal, since this macro is used only when profiling. 35745 35746 35747File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 35748 3574917.20.8 Output of Dispatch Tables 35750--------------------------------- 35751 35752This concerns dispatch tables. 35753 35754 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 35755 A C statement to output to the stdio stream STREAM an assembler 35756 pseudo-instruction to generate a difference between two labels. 35757 VALUE and REL are the numbers of two internal labels. The 35758 definitions of these labels are output using 35759 '(*targetm.asm_out.internal_label)', and they must be printed in 35760 the same way here. For example, 35761 35762 fprintf (STREAM, "\t.word L%d-L%d\n", 35763 VALUE, REL) 35764 35765 You must provide this macro on machines where the addresses in a 35766 dispatch table are relative to the table's own address. If 35767 defined, GCC will also use this macro on all machines when 35768 producing PIC. BODY is the body of the 'ADDR_DIFF_VEC'; it is 35769 provided so that the mode and flags can be read. 35770 35771 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 35772 This macro should be provided on machines where the addresses in a 35773 dispatch table are absolute. 35774 35775 The definition should be a C statement to output to the stdio 35776 stream STREAM an assembler pseudo-instruction to generate a 35777 reference to a label. VALUE is the number of an internal label 35778 whose definition is output using 35779 '(*targetm.asm_out.internal_label)'. For example, 35780 35781 fprintf (STREAM, "\t.word L%d\n", VALUE) 35782 35783 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 35784 Define this if the label before a jump-table needs to be output 35785 specially. The first three arguments are the same as for 35786 '(*targetm.asm_out.internal_label)'; the fourth argument is the 35787 jump-table which follows (a 'jump_table_data' containing an 35788 'addr_vec' or 'addr_diff_vec'). 35789 35790 This feature is used on system V to output a 'swbeg' statement for 35791 the table. 35792 35793 If this macro is not defined, these labels are output with 35794 '(*targetm.asm_out.internal_label)'. 35795 35796 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 35797 Define this if something special must be output at the end of a 35798 jump-table. The definition should be a C statement to be executed 35799 after the assembler code for the table is written. It should write 35800 the appropriate code to stdio stream STREAM. The argument TABLE is 35801 the jump-table insn, and NUM is the label-number of the preceding 35802 label. 35803 35804 If this macro is not defined, nothing special is output at the end 35805 of the jump-table. 35806 35807 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree 35808 DECL, int FOR_EH, int EMPTY) 35809 This target hook emits a label at the beginning of each FDE. It 35810 should be defined on targets where FDEs need special labels, and it 35811 should write the appropriate label, for the FDE associated with the 35812 function declaration DECL, to the stdio stream STREAM. The third 35813 argument, FOR_EH, is a boolean: true if this is for an exception 35814 table. The fourth argument, EMPTY, is a boolean: true if this is a 35815 placeholder label for an omitted FDE. 35816 35817 The default is that FDEs are not given nonlocal labels. 35818 35819 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM) 35820 This target hook emits a label at the beginning of the exception 35821 table. It should be defined on targets where it is desirable for 35822 the table to be broken up according to function. 35823 35824 The default is that no label is emitted. 35825 35826 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx 35827 PERSONALITY) 35828 If the target implements 'TARGET_ASM_UNWIND_EMIT', this hook may be 35829 used to emit a directive to install a personality hook into the 35830 unwind info. This hook should not be used if dwarf2 unwind info is 35831 used. 35832 35833 -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx_insn 35834 *INSN) 35835 This target hook emits assembly directives required to unwind the 35836 given instruction. This is only used when 35837 'TARGET_EXCEPT_UNWIND_INFO' returns 'UI_TARGET'. 35838 35839 -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN 35840 True if the 'TARGET_ASM_UNWIND_EMIT' hook should be called before 35841 the assembly for INSN has been emitted, false if the hook should be 35842 called afterward. 35843 35844 35845File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 35846 3584717.20.9 Assembler Commands for Exception Regions 35848------------------------------------------------ 35849 35850This describes commands marking the start and the end of an exception 35851region. 35852 35853 -- Macro: EH_FRAME_SECTION_NAME 35854 If defined, a C string constant for the name of the section 35855 containing exception handling frame unwind information. If not 35856 defined, GCC will provide a default definition if the target 35857 supports named sections. 'crtstuff.c' uses this macro to switch to 35858 the appropriate section. 35859 35860 You should define this symbol if your target supports DWARF 2 frame 35861 unwind information and the default definition does not work. 35862 35863 -- Macro: EH_FRAME_IN_DATA_SECTION 35864 If defined, DWARF 2 frame unwind information will be placed in the 35865 data section even though the target supports named sections. This 35866 might be necessary, for instance, if the system linker does garbage 35867 collection and sections cannot be marked as not to be collected. 35868 35869 Do not define this macro unless 'TARGET_ASM_NAMED_SECTION' is also 35870 defined. 35871 35872 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 35873 Define this macro to 1 if your target is such that no frame unwind 35874 information encoding used with non-PIC code will ever require a 35875 runtime relocation, but the linker may not support merging 35876 read-only and read-write sections into a single read-write section. 35877 35878 -- Macro: MASK_RETURN_ADDR 35879 An rtx used to mask the return address found via 'RETURN_ADDR_RTX', 35880 so that it does not contain any extraneous set bits in it. 35881 35882 -- Macro: DWARF2_UNWIND_INFO 35883 Define this macro to 0 if your target supports DWARF 2 frame unwind 35884 information, but it does not yet work with exception handling. 35885 Otherwise, if your target supports this information (if it defines 35886 'INCOMING_RETURN_ADDR_RTX' and 'OBJECT_FORMAT_ELF'), GCC will 35887 provide a default definition of 1. 35888 35889 -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO 35890 (struct gcc_options *OPTS) 35891 This hook defines the mechanism that will be used for exception 35892 handling by the target. If the target has ABI specified unwind 35893 tables, the hook should return 'UI_TARGET'. If the target is to 35894 use the 'setjmp'/'longjmp'-based exception handling scheme, the 35895 hook should return 'UI_SJLJ'. If the target supports DWARF 2 frame 35896 unwind information, the hook should return 'UI_DWARF2'. 35897 35898 A target may, if exceptions are disabled, choose to return 35899 'UI_NONE'. This may end up simplifying other parts of 35900 target-specific code. The default implementation of this hook 35901 never returns 'UI_NONE'. 35902 35903 Note that the value returned by this hook should be constant. It 35904 should not depend on anything except the command-line switches 35905 described by OPTS. In particular, the setting 'UI_SJLJ' must be 35906 fixed at compiler start-up as C pre-processor macros and builtin 35907 functions related to exception handling are set up depending on 35908 this setting. 35909 35910 The default implementation of the hook first honors the 35911 '--enable-sjlj-exceptions' configure option, then 35912 'DWARF2_UNWIND_INFO', and finally defaults to 'UI_SJLJ'. If 35913 'DWARF2_UNWIND_INFO' depends on command-line options, the target 35914 must define this hook so that OPTS is used correctly. 35915 35916 -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT 35917 This variable should be set to 'true' if the target ABI requires 35918 unwinding tables even when exceptions are not used. It must not be 35919 modified by command-line option processing. 35920 35921 -- Macro: DONT_USE_BUILTIN_SETJMP 35922 Define this macro to 1 if the 'setjmp'/'longjmp'-based scheme 35923 should use the 'setjmp'/'longjmp' functions from the C library 35924 instead of the '__builtin_setjmp'/'__builtin_longjmp' machinery. 35925 35926 -- Macro: JMP_BUF_SIZE 35927 This macro has no effect unless 'DONT_USE_BUILTIN_SETJMP' is also 35928 defined. Define this macro if the default size of 'jmp_buf' buffer 35929 for the 'setjmp'/'longjmp'-based exception handling mechanism is 35930 not large enough, or if it is much too large. The default size is 35931 'FIRST_PSEUDO_REGISTER * sizeof(void *)'. 35932 35933 -- Macro: DWARF_CIE_DATA_ALIGNMENT 35934 This macro need only be defined if the target might save registers 35935 in the function prologue at an offset to the stack pointer that is 35936 not aligned to 'UNITS_PER_WORD'. The definition should be the 35937 negative minimum alignment if 'STACK_GROWS_DOWNWARD' is defined, 35938 and the positive minimum alignment otherwise. *Note SDB and 35939 DWARF::. Only applicable if the target supports DWARF 2 frame 35940 unwind information. 35941 35942 -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 35943 Contains the value true if the target should add a zero word onto 35944 the end of a Dwarf-2 frame info section when used for exception 35945 handling. Default value is false if 'EH_FRAME_SECTION_NAME' is 35946 defined, and true otherwise. 35947 35948 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 35949 Given a register, this hook should return a parallel of registers 35950 to represent where to find the register pieces. Define this hook 35951 if the register and its mode are represented in Dwarf in 35952 non-contiguous locations, or if the register should be represented 35953 in more than one register in Dwarf. Otherwise, this hook should 35954 return 'NULL_RTX'. If not defined, the default is to return 35955 'NULL_RTX'. 35956 35957 -- Target Hook: machine_mode TARGET_DWARF_FRAME_REG_MODE (int REGNO) 35958 Given a register, this hook should return the mode which the 35959 corresponding Dwarf frame register should have. This is normally 35960 used to return a smaller mode than the raw mode to prevent call 35961 clobbered parts of a register altering the frame register size 35962 35963 -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS) 35964 If some registers are represented in Dwarf-2 unwind information in 35965 multiple pieces, define this hook to fill in information about the 35966 sizes of those pieces in the table used by the unwinder at runtime. 35967 It will be called by 'expand_builtin_init_dwarf_reg_sizes' after 35968 filling in a single size corresponding to each hard register; 35969 ADDRESS is the address of the table. 35970 35971 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 35972 This hook is used to output a reference from a frame unwinding 35973 table to the type_info object identified by SYM. It should return 35974 'true' if the reference was output. Returning 'false' will cause 35975 the reference to be output using the normal Dwarf2 routines. 35976 35977 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 35978 This flag should be set to 'true' on targets that use an ARM EABI 35979 based unwinding library, and 'false' on other targets. This 35980 effects the format of unwinding tables, and how the unwinder in 35981 entered after running a cleanup. The default is 'false'. 35982 35983 35984File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 35985 3598617.20.10 Assembler Commands for Alignment 35987----------------------------------------- 35988 35989This describes commands for alignment. 35990 35991 -- Macro: JUMP_ALIGN (LABEL) 35992 The alignment (log base 2) to put in front of LABEL, which is a 35993 common destination of jumps and has no fallthru incoming edge. 35994 35995 This macro need not be defined if you don't want any special 35996 alignment to be done at such a time. Most machine descriptions do 35997 not currently define the macro. 35998 35999 Unless it's necessary to inspect the LABEL parameter, it is better 36000 to set the variable ALIGN_JUMPS in the target's 36001 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 36002 user's selection in ALIGN_JUMPS in a 'JUMP_ALIGN' implementation. 36003 36004 -- Target Hook: int TARGET_ASM_JUMP_ALIGN_MAX_SKIP (rtx_insn *LABEL) 36005 The maximum number of bytes to skip before LABEL when applying 36006 'JUMP_ALIGN'. This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is 36007 defined. 36008 36009 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 36010 The alignment (log base 2) to put in front of LABEL, which follows 36011 a 'BARRIER'. 36012 36013 This macro need not be defined if you don't want any special 36014 alignment to be done at such a time. Most machine descriptions do 36015 not currently define the macro. 36016 36017 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP 36018 (rtx_insn *LABEL) 36019 The maximum number of bytes to skip before LABEL when applying 36020 'LABEL_ALIGN_AFTER_BARRIER'. This works only if 36021 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 36022 36023 -- Macro: LOOP_ALIGN (LABEL) 36024 The alignment (log base 2) to put in front of LABEL that heads a 36025 frequently executed basic block (usually the header of a loop). 36026 36027 This macro need not be defined if you don't want any special 36028 alignment to be done at such a time. Most machine descriptions do 36029 not currently define the macro. 36030 36031 Unless it's necessary to inspect the LABEL parameter, it is better 36032 to set the variable 'align_loops' in the target's 36033 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 36034 user's selection in 'align_loops' in a 'LOOP_ALIGN' implementation. 36035 36036 -- Target Hook: int TARGET_ASM_LOOP_ALIGN_MAX_SKIP (rtx_insn *LABEL) 36037 The maximum number of bytes to skip when applying 'LOOP_ALIGN' to 36038 LABEL. This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 36039 36040 -- Macro: LABEL_ALIGN (LABEL) 36041 The alignment (log base 2) to put in front of LABEL. If 36042 'LABEL_ALIGN_AFTER_BARRIER' / 'LOOP_ALIGN' specify a different 36043 alignment, the maximum of the specified values is used. 36044 36045 Unless it's necessary to inspect the LABEL parameter, it is better 36046 to set the variable 'align_labels' in the target's 36047 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 36048 user's selection in 'align_labels' in a 'LABEL_ALIGN' 36049 implementation. 36050 36051 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_MAX_SKIP (rtx_insn *LABEL) 36052 The maximum number of bytes to skip when applying 'LABEL_ALIGN' to 36053 LABEL. This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 36054 36055 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 36056 A C statement to output to the stdio stream STREAM an assembler 36057 instruction to advance the location counter by NBYTES bytes. Those 36058 bytes should be zero when loaded. NBYTES will be a C expression of 36059 type 'unsigned HOST_WIDE_INT'. 36060 36061 -- Macro: ASM_NO_SKIP_IN_TEXT 36062 Define this macro if 'ASM_OUTPUT_SKIP' should not be used in the 36063 text section because it fails to put zeros in the bytes that are 36064 skipped. This is true on many Unix systems, where the pseudo-op to 36065 skip bytes produces no-op instructions rather than zeros when used 36066 in the text section. 36067 36068 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 36069 A C statement to output to the stdio stream STREAM an assembler 36070 command to advance the location counter to a multiple of 2 to the 36071 POWER bytes. POWER will be a C expression of type 'int'. 36072 36073 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 36074 Like 'ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 36075 for padding, if necessary. 36076 36077 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 36078 A C statement to output to the stdio stream STREAM an assembler 36079 command to advance the location counter to a multiple of 2 to the 36080 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 36081 satisfy the alignment request. POWER and MAX_SKIP will be a C 36082 expression of type 'int'. 36083 36084 36085File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 36086 3608717.21 Controlling Debugging Information Format 36088============================================== 36089 36090This describes how to specify debugging information. 36091 36092* Menu: 36093 36094* All Debuggers:: Macros that affect all debugging formats uniformly. 36095* DBX Options:: Macros enabling specific options in DBX format. 36096* DBX Hooks:: Hook macros for varying DBX format. 36097* File Names and DBX:: Macros controlling output of file names in DBX format. 36098* SDB and DWARF:: Macros for SDB (COFF) and DWARF formats. 36099* VMS Debug:: Macros for VMS debug format. 36100 36101 36102File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 36103 3610417.21.1 Macros Affecting All Debugging Formats 36105---------------------------------------------- 36106 36107These macros affect all debugging formats. 36108 36109 -- Macro: DBX_REGISTER_NUMBER (REGNO) 36110 A C expression that returns the DBX register number for the 36111 compiler register number REGNO. In the default macro provided, the 36112 value of this expression will be REGNO itself. But sometimes there 36113 are some registers that the compiler knows about and DBX does not, 36114 or vice versa. In such cases, some register may need to have one 36115 number in the compiler and another for DBX. 36116 36117 If two registers have consecutive numbers inside GCC, and they can 36118 be used as a pair to hold a multiword value, then they _must_ have 36119 consecutive numbers after renumbering with 'DBX_REGISTER_NUMBER'. 36120 Otherwise, debuggers will be unable to access such a pair, because 36121 they expect register pairs to be consecutive in their own numbering 36122 scheme. 36123 36124 If you find yourself defining 'DBX_REGISTER_NUMBER' in way that 36125 does not preserve register pairs, then what you must do instead is 36126 redefine the actual register numbering scheme. 36127 36128 -- Macro: DEBUGGER_AUTO_OFFSET (X) 36129 A C expression that returns the integer offset value for an 36130 automatic variable having address X (an RTL expression). The 36131 default computation assumes that X is based on the frame-pointer 36132 and gives the offset from the frame-pointer. This is required for 36133 targets that produce debugging output for DBX or COFF-style 36134 debugging output for SDB and allow the frame-pointer to be 36135 eliminated when the '-g' options is used. 36136 36137 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 36138 A C expression that returns the integer offset value for an 36139 argument having address X (an RTL expression). The nominal offset 36140 is OFFSET. 36141 36142 -- Macro: PREFERRED_DEBUGGING_TYPE 36143 A C expression that returns the type of debugging output GCC should 36144 produce when the user specifies just '-g'. Define this if you have 36145 arranged for GCC to support more than one format of debugging 36146 output. Currently, the allowable values are 'DBX_DEBUG', 36147 'SDB_DEBUG', 'DWARF_DEBUG', 'DWARF2_DEBUG', 'XCOFF_DEBUG', 36148 'VMS_DEBUG', and 'VMS_AND_DWARF2_DEBUG'. 36149 36150 When the user specifies '-ggdb', GCC normally also uses the value 36151 of this macro to select the debugging output format, but with two 36152 exceptions. If 'DWARF2_DEBUGGING_INFO' is defined, GCC uses the 36153 value 'DWARF2_DEBUG'. Otherwise, if 'DBX_DEBUGGING_INFO' is 36154 defined, GCC uses 'DBX_DEBUG'. 36155 36156 The value of this macro only affects the default debugging output; 36157 the user can always get a specific type of output by using 36158 '-gstabs', '-gcoff', '-gdwarf-2', '-gxcoff', or '-gvms'. 36159 36160 36161File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 36162 3616317.21.2 Specific Options for DBX Output 36164--------------------------------------- 36165 36166These are specific options for DBX output. 36167 36168 -- Macro: DBX_DEBUGGING_INFO 36169 Define this macro if GCC should produce debugging output for DBX in 36170 response to the '-g' option. 36171 36172 -- Macro: XCOFF_DEBUGGING_INFO 36173 Define this macro if GCC should produce XCOFF format debugging 36174 output in response to the '-g' option. This is a variant of DBX 36175 format. 36176 36177 -- Macro: DEFAULT_GDB_EXTENSIONS 36178 Define this macro to control whether GCC should by default generate 36179 GDB's extended version of DBX debugging information (assuming 36180 DBX-format debugging information is enabled at all). If you don't 36181 define the macro, the default is 1: always generate the extended 36182 information if there is any occasion to. 36183 36184 -- Macro: DEBUG_SYMS_TEXT 36185 Define this macro if all '.stabs' commands should be output while 36186 in the text section. 36187 36188 -- Macro: ASM_STABS_OP 36189 A C string constant, including spacing, naming the assembler pseudo 36190 op to use instead of '"\t.stabs\t"' to define an ordinary debugging 36191 symbol. If you don't define this macro, '"\t.stabs\t"' is used. 36192 This macro applies only to DBX debugging information format. 36193 36194 -- Macro: ASM_STABD_OP 36195 A C string constant, including spacing, naming the assembler pseudo 36196 op to use instead of '"\t.stabd\t"' to define a debugging symbol 36197 whose value is the current location. If you don't define this 36198 macro, '"\t.stabd\t"' is used. This macro applies only to DBX 36199 debugging information format. 36200 36201 -- Macro: ASM_STABN_OP 36202 A C string constant, including spacing, naming the assembler pseudo 36203 op to use instead of '"\t.stabn\t"' to define a debugging symbol 36204 with no name. If you don't define this macro, '"\t.stabn\t"' is 36205 used. This macro applies only to DBX debugging information format. 36206 36207 -- Macro: DBX_NO_XREFS 36208 Define this macro if DBX on your system does not support the 36209 construct 'xsTAGNAME'. On some systems, this construct is used to 36210 describe a forward reference to a structure named TAGNAME. On 36211 other systems, this construct is not supported at all. 36212 36213 -- Macro: DBX_CONTIN_LENGTH 36214 A symbol name in DBX-format debugging information is normally 36215 continued (split into two separate '.stabs' directives) when it 36216 exceeds a certain length (by default, 80 characters). On some 36217 operating systems, DBX requires this splitting; on others, 36218 splitting must not be done. You can inhibit splitting by defining 36219 this macro with the value zero. You can override the default 36220 splitting-length by defining this macro as an expression for the 36221 length you desire. 36222 36223 -- Macro: DBX_CONTIN_CHAR 36224 Normally continuation is indicated by adding a '\' character to the 36225 end of a '.stabs' string when a continuation follows. To use a 36226 different character instead, define this macro as a character 36227 constant for the character you want to use. Do not define this 36228 macro if backslash is correct for your system. 36229 36230 -- Macro: DBX_STATIC_STAB_DATA_SECTION 36231 Define this macro if it is necessary to go to the data section 36232 before outputting the '.stabs' pseudo-op for a non-global static 36233 variable. 36234 36235 -- Macro: DBX_TYPE_DECL_STABS_CODE 36236 The value to use in the "code" field of the '.stabs' directive for 36237 a typedef. The default is 'N_LSYM'. 36238 36239 -- Macro: DBX_STATIC_CONST_VAR_CODE 36240 The value to use in the "code" field of the '.stabs' directive for 36241 a static variable located in the text section. DBX format does not 36242 provide any "right" way to do this. The default is 'N_FUN'. 36243 36244 -- Macro: DBX_REGPARM_STABS_CODE 36245 The value to use in the "code" field of the '.stabs' directive for 36246 a parameter passed in registers. DBX format does not provide any 36247 "right" way to do this. The default is 'N_RSYM'. 36248 36249 -- Macro: DBX_REGPARM_STABS_LETTER 36250 The letter to use in DBX symbol data to identify a symbol as a 36251 parameter passed in registers. DBX format does not customarily 36252 provide any way to do this. The default is ''P''. 36253 36254 -- Macro: DBX_FUNCTION_FIRST 36255 Define this macro if the DBX information for a function and its 36256 arguments should precede the assembler code for the function. 36257 Normally, in DBX format, the debugging information entirely follows 36258 the assembler code. 36259 36260 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 36261 Define this macro, with value 1, if the value of a symbol 36262 describing the scope of a block ('N_LBRAC' or 'N_RBRAC') should be 36263 relative to the start of the enclosing function. Normally, GCC 36264 uses an absolute address. 36265 36266 -- Macro: DBX_LINES_FUNCTION_RELATIVE 36267 Define this macro, with value 1, if the value of a symbol 36268 indicating the current line number ('N_SLINE') should be relative 36269 to the start of the enclosing function. Normally, GCC uses an 36270 absolute address. 36271 36272 -- Macro: DBX_USE_BINCL 36273 Define this macro if GCC should generate 'N_BINCL' and 'N_EINCL' 36274 stabs for included header files, as on Sun systems. This macro 36275 also directs GCC to output a type number as a pair of a file number 36276 and a type number within the file. Normally, GCC does not generate 36277 'N_BINCL' or 'N_EINCL' stabs, and it outputs a single number for a 36278 type number. 36279 36280 36281File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 36282 3628317.21.3 Open-Ended Hooks for DBX Format 36284--------------------------------------- 36285 36286These are hooks for DBX format. 36287 36288 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 36289 A C statement to output DBX debugging information before code for 36290 line number LINE of the current source file to the stdio stream 36291 STREAM. COUNTER is the number of time the macro was invoked, 36292 including the current invocation; it is intended to generate unique 36293 labels in the assembly output. 36294 36295 This macro should not be defined if the default output is correct, 36296 or if it can be made correct by defining 36297 'DBX_LINES_FUNCTION_RELATIVE'. 36298 36299 -- Macro: NO_DBX_FUNCTION_END 36300 Some stabs encapsulation formats (in particular ECOFF), cannot 36301 handle the '.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 36302 extension construct. On those machines, define this macro to turn 36303 this feature off without disturbing the rest of the gdb extensions. 36304 36305 -- Macro: NO_DBX_BNSYM_ENSYM 36306 Some assemblers cannot handle the '.stabd BNSYM/ENSYM,0,0' gdb dbx 36307 extension construct. On those machines, define this macro to turn 36308 this feature off without disturbing the rest of the gdb extensions. 36309 36310 36311File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info 36312 3631317.21.4 File Names in DBX Format 36314-------------------------------- 36315 36316This describes file names in DBX format. 36317 36318 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 36319 A C statement to output DBX debugging information to the stdio 36320 stream STREAM, which indicates that file NAME is the main source 36321 file--the file specified as the input file for compilation. This 36322 macro is called only once, at the beginning of compilation. 36323 36324 This macro need not be defined if the standard form of output for 36325 DBX debugging information is appropriate. 36326 36327 It may be necessary to refer to a label equal to the beginning of 36328 the text section. You can use 'assemble_name (stream, 36329 ltext_label_name)' to do so. If you do this, you must also set the 36330 variable USED_LTEXT_LABEL_NAME to 'true'. 36331 36332 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 36333 Define this macro, with value 1, if GCC should not emit an 36334 indication of the current directory for compilation and current 36335 source language at the beginning of the file. 36336 36337 -- Macro: NO_DBX_GCC_MARKER 36338 Define this macro, with value 1, if GCC should not emit an 36339 indication that this object file was compiled by GCC. The default 36340 is to emit an 'N_OPT' stab at the beginning of every source file, 36341 with 'gcc2_compiled.' for the string and value 0. 36342 36343 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 36344 A C statement to output DBX debugging information at the end of 36345 compilation of the main source file NAME. Output should be written 36346 to the stdio stream STREAM. 36347 36348 If you don't define this macro, nothing special is output at the 36349 end of compilation, which is correct for most machines. 36350 36351 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 36352 Define this macro _instead of_ defining 36353 'DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 36354 the end of compilation is an 'N_SO' stab with an empty string, 36355 whose value is the highest absolute text address in the file. 36356 36357 36358File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 36359 3636017.21.5 Macros for SDB and DWARF Output 36361--------------------------------------- 36362 36363Here are macros for SDB and DWARF output. 36364 36365 -- Macro: SDB_DEBUGGING_INFO 36366 Define this macro if GCC should produce COFF-style debugging output 36367 for SDB in response to the '-g' option. 36368 36369 -- Macro: DWARF2_DEBUGGING_INFO 36370 Define this macro if GCC should produce dwarf version 2 format 36371 debugging output in response to the '-g' option. 36372 36373 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree 36374 FUNCTION) 36375 Define this to enable the dwarf attribute 36376 'DW_AT_calling_convention' to be emitted for each function. 36377 Instead of an integer return the enum value for the 'DW_CC_' 36378 tag. 36379 36380 To support optional call frame debugging information, you must also 36381 define 'INCOMING_RETURN_ADDR_RTX' and either set 36382 'RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 36383 prologue, or call 'dwarf2out_def_cfa' and 'dwarf2out_reg_save' as 36384 appropriate from 'TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 36385 36386 -- Macro: DWARF2_FRAME_INFO 36387 Define this macro to a nonzero value if GCC should always output 36388 Dwarf 2 frame information. If 'TARGET_EXCEPT_UNWIND_INFO' (*note 36389 Exception Region Output::) returns 'UI_DWARF2', and exceptions are 36390 enabled, GCC will output this information not matter how you define 36391 'DWARF2_FRAME_INFO'. 36392 36393 -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void) 36394 This hook defines the mechanism that will be used for describing 36395 frame unwind information to the debugger. Normally the hook will 36396 return 'UI_DWARF2' if DWARF 2 debug information is enabled, and 36397 return 'UI_NONE' otherwise. 36398 36399 A target may return 'UI_DWARF2' even when DWARF 2 debug information 36400 is disabled in order to always output DWARF 2 frame information. 36401 36402 A target may return 'UI_TARGET' if it has ABI specified unwind 36403 tables. This will suppress generation of the normal debug frame 36404 unwind information. 36405 36406 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 36407 Define this macro to be a nonzero value if the assembler can 36408 generate Dwarf 2 line debug info sections. This will result in 36409 much more compact line number tables, and hence is desirable if it 36410 works. 36411 36412 -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS 36413 True if the '.debug_pubtypes' and '.debug_pubnames' sections should 36414 be emitted. These sections are not used on most platforms, and in 36415 particular GDB does not use them. 36416 36417 -- Target Hook: bool TARGET_FORCE_AT_COMP_DIR 36418 True if the 'DW_AT_comp_dir' attribute should be emitted for each 36419 compilation unit. This attribute is required for the darwin linker 36420 to emit debug information. 36421 36422 -- Target Hook: bool TARGET_DELAY_SCHED2 36423 True if sched2 is not to be run at its normal place. This usually 36424 means it will be run as part of machine-specific reorg. 36425 36426 -- Target Hook: bool TARGET_DELAY_VARTRACK 36427 True if vartrack is not to be run at its normal place. This 36428 usually means it will be run as part of machine-specific reorg. 36429 36430 -- Target Hook: bool TARGET_NO_REGISTER_ALLOCATION 36431 True if register allocation and the passes following it should not 36432 be run. Usually true only for virtual assembler targets. 36433 36434 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 36435 A C statement to issue assembly directives that create a difference 36436 LAB1 minus LAB2, using an integer of the given SIZE. 36437 36438 -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2) 36439 A C statement to issue assembly directives that create a difference 36440 between the two given labels in system defined units, e.g. 36441 instruction slots on IA64 VMS, using an integer of the given size. 36442 36443 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, SECTION) 36444 A C statement to issue assembly directives that create a 36445 section-relative reference to the given LABEL, using an integer of 36446 the given SIZE. The label is known to be defined in the given 36447 SECTION. 36448 36449 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 36450 A C statement to issue assembly directives that create a 36451 self-relative reference to the given LABEL, using an integer of the 36452 given SIZE. 36453 36454 -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL) 36455 A C statement to issue assembly directives that create a reference 36456 to the DWARF table identifier LABEL from the current section. This 36457 is used on some systems to avoid garbage collecting a DWARF table 36458 which is referenced by a function. 36459 36460 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 36461 SIZE, rtx X) 36462 If defined, this target hook is a function which outputs a 36463 DTP-relative reference to the given TLS symbol of the specified 36464 size. 36465 36466 -- Macro: PUT_SDB_... 36467 Define these macros to override the assembler syntax for the 36468 special SDB assembler directives. See 'sdbout.c' for a list of 36469 these macros and their arguments. If the standard syntax is used, 36470 you need not define them yourself. 36471 36472 -- Macro: SDB_DELIM 36473 Some assemblers do not support a semicolon as a delimiter, even 36474 between SDB assembler directives. In that case, define this macro 36475 to be the delimiter to use (usually '\n'). It is not necessary to 36476 define a new set of 'PUT_SDB_OP' macros if this is the only change 36477 required. 36478 36479 -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES 36480 Define this macro to allow references to unknown structure, union, 36481 or enumeration tags to be emitted. Standard COFF does not allow 36482 handling of unknown references, MIPS ECOFF has support for it. 36483 36484 -- Macro: SDB_ALLOW_FORWARD_REFERENCES 36485 Define this macro to allow references to structure, union, or 36486 enumeration tags that have not yet been seen to be handled. Some 36487 assemblers choke if forward tags are used, while some require it. 36488 36489 -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE) 36490 A C statement to output SDB debugging information before code for 36491 line number LINE of the current source file to the stdio stream 36492 STREAM. The default is to emit an '.ln' directive. 36493 36494 36495File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info 36496 3649717.21.6 Macros for VMS Debug Format 36498----------------------------------- 36499 36500Here are macros for VMS debug format. 36501 36502 -- Macro: VMS_DEBUGGING_INFO 36503 Define this macro if GCC should produce debugging output for VMS in 36504 response to the '-g' option. The default behavior for VMS is to 36505 generate minimal debug info for a traceback in the absence of '-g' 36506 unless explicitly overridden with '-g0'. This behavior is 36507 controlled by 'TARGET_OPTION_OPTIMIZATION' and 36508 'TARGET_OPTION_OVERRIDE'. 36509 36510 36511File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 36512 3651317.22 Cross Compilation and Floating Point 36514========================================== 36515 36516While all modern machines use twos-complement representation for 36517integers, there are a variety of representations for floating point 36518numbers. This means that in a cross-compiler the representation of 36519floating point numbers in the compiled program may be different from 36520that used in the machine doing the compilation. 36521 36522 Because different representation systems may offer different amounts of 36523range and precision, all floating point constants must be represented in 36524the target machine's format. Therefore, the cross compiler cannot 36525safely use the host machine's floating point arithmetic; it must emulate 36526the target's arithmetic. To ensure consistency, GCC always uses 36527emulation to work with floating point values, even when the host and 36528target floating point formats are identical. 36529 36530 The following macros are provided by 'real.h' for the compiler to use. 36531All parts of the compiler which generate or optimize floating-point 36532calculations must use these macros. They may evaluate their operands 36533more than once, so operands must not have side effects. 36534 36535 -- Macro: REAL_VALUE_TYPE 36536 The C data type to be used to hold a floating point value in the 36537 target machine's format. Typically this is a 'struct' containing 36538 an array of 'HOST_WIDE_INT', but all code should treat it as an 36539 opaque quantity. 36540 36541 -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 36542 Compares for equality the two values, X and Y. If the target 36543 floating point format supports negative zeroes and/or NaNs, 36544 'REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and 'REAL_VALUES_EQUAL 36545 (NaN, NaN)' is false. 36546 36547 -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 36548 Tests whether X is less than Y. 36549 36550 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 36551 Truncates X to a signed integer, rounding toward zero. 36552 36553 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 36554 (REAL_VALUE_TYPE X) 36555 Truncates X to an unsigned integer, rounding toward zero. If X is 36556 negative, returns zero. 36557 36558 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, 36559 machine_mode MODE) 36560 Converts STRING into a floating point number in the target 36561 machine's representation for mode MODE. This routine can handle 36562 both decimal and hexadecimal floating point constants, using the 36563 syntax defined by the C language for both. 36564 36565 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 36566 Returns 1 if X is negative (including negative zero), 0 otherwise. 36567 36568 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 36569 Determines whether X represents infinity (positive or negative). 36570 36571 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 36572 Determines whether X represents a "NaN" (not-a-number). 36573 36574 -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code 36575 CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 36576 Calculates an arithmetic operation on the two floating point values 36577 X and Y, storing the result in OUTPUT (which must be a variable). 36578 36579 The operation to be performed is specified by CODE. Only the 36580 following codes are supported: 'PLUS_EXPR', 'MINUS_EXPR', 36581 'MULT_EXPR', 'RDIV_EXPR', 'MAX_EXPR', 'MIN_EXPR'. 36582 36583 If 'REAL_ARITHMETIC' is asked to evaluate division by zero and the 36584 target's floating point format cannot represent infinity, it will 36585 call 'abort'. Callers should check for this situation first, using 36586 'MODE_HAS_INFINITIES'. *Note Storage Layout::. 36587 36588 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 36589 Returns the negative of the floating point value X. 36590 36591 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 36592 Returns the absolute value of X. 36593 36594 36595File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 36596 3659717.23 Mode Switching Instructions 36598================================= 36599 36600The following macros control mode switching optimizations: 36601 36602 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 36603 Define this macro if the port needs extra instructions inserted for 36604 mode switching in an optimizing compilation. 36605 36606 For an example, the SH4 can perform both single and double 36607 precision floating point operations, but to perform a single 36608 precision operation, the FPSCR PR bit has to be cleared, while for 36609 a double precision operation, this bit has to be set. Changing the 36610 PR bit requires a general purpose register as a scratch register, 36611 hence these FPSCR sets have to be inserted before reload, i.e. you 36612 can't put this into instruction emitting or 36613 'TARGET_MACHINE_DEPENDENT_REORG'. 36614 36615 You can have multiple entities that are mode-switched, and select 36616 at run time which entities actually need it. 36617 'OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY that 36618 needs mode-switching. If you define this macro, you also have to 36619 define 'NUM_MODES_FOR_MODE_SWITCHING', 'TARGET_MODE_NEEDED', 36620 'TARGET_MODE_PRIORITY' and 'TARGET_MODE_EMIT'. 36621 'TARGET_MODE_AFTER', 'TARGET_MODE_ENTRY', and 'TARGET_MODE_EXIT' 36622 are optional. 36623 36624 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 36625 If you define 'OPTIMIZE_MODE_SWITCHING', you have to define this as 36626 initializer for an array of integers. Each initializer element N 36627 refers to an entity that needs mode switching, and specifies the 36628 number of different modes that might need to be set for this 36629 entity. The position of the initializer in the 36630 initializer--starting counting at zero--determines the integer that 36631 is used to refer to the mode-switched entity in question. In 36632 macros that take mode arguments / yield a mode result, modes are 36633 represented as numbers 0 ... N - 1. N is used to specify that no 36634 mode switch is needed / supplied. 36635 36636 -- Target Hook: void TARGET_MODE_EMIT (int ENTITY, int MODE, int 36637 PREV_MODE, HARD_REG_SET REGS_LIVE) 36638 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE is 36639 the set of hard registers live at the point where the insn(s) are 36640 to be inserted. PREV_MOXDE indicates the mode to switch from. 36641 Sets of a lower numbered entity will be emitted before sets of a 36642 higher numbered entity to a mode of the same or lower priority. 36643 36644 -- Target Hook: int TARGET_MODE_NEEDED (int ENTITY, rtx_insn *INSN) 36645 ENTITY is an integer specifying a mode-switched entity. If 36646 'OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 36647 return an integer value not larger than the corresponding element 36648 in 'NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 36649 must be switched into prior to the execution of INSN. 36650 36651 -- Target Hook: int TARGET_MODE_AFTER (int ENTITY, int MODE, rtx_insn 36652 *INSN) 36653 ENTITY is an integer specifying a mode-switched entity. If this 36654 macro is defined, it is evaluated for every INSN during mode 36655 switching. It determines the mode that an insn results in (if 36656 different from the incoming mode). 36657 36658 -- Target Hook: int TARGET_MODE_ENTRY (int ENTITY) 36659 If this macro is defined, it is evaluated for every ENTITY that 36660 needs mode switching. It should evaluate to an integer, which is a 36661 mode that ENTITY is assumed to be switched to at function entry. 36662 If 'TARGET_MODE_ENTRY' is defined then 'TARGET_MODE_EXIT' must be 36663 defined. 36664 36665 -- Target Hook: int TARGET_MODE_EXIT (int ENTITY) 36666 If this macro is defined, it is evaluated for every ENTITY that 36667 needs mode switching. It should evaluate to an integer, which is a 36668 mode that ENTITY is assumed to be switched to at function exit. If 36669 'TARGET_MODE_EXIT' is defined then 'TARGET_MODE_ENTRY' must be 36670 defined. 36671 36672 -- Target Hook: int TARGET_MODE_PRIORITY (int ENTITY, int N) 36673 This macro specifies the order in which modes for ENTITY are 36674 processed. 0 is the highest priority, 36675 'NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 36676 of the macro should be an integer designating a mode for ENTITY. 36677 For any fixed ENTITY, 'mode_priority' (ENTITY, N) shall be a 36678 bijection in 0 ... 'num_modes_for_mode_switching[ENTITY] - 1'. 36679 36680 36681File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros 36682 3668317.24 Defining target-specific uses of '__attribute__' 36684====================================================== 36685 36686Target-specific attributes may be defined for functions, data and types. 36687These are described using the following target hooks; they also need to 36688be documented in 'extend.texi'. 36689 36690 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 36691 If defined, this target hook points to an array of 'struct 36692 attribute_spec' (defined in 'tree.h') specifying the machine 36693 specific attributes for this target and some of the restrictions on 36694 the entities to which these attributes are applied and the 36695 arguments they take. 36696 36697 -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree 36698 NAME) 36699 If defined, this target hook is a function which returns true if 36700 the machine-specific attribute named NAME expects an identifier 36701 given as its first argument to be passed on as a plain identifier, 36702 not subjected to name lookup. If this is not defined, the default 36703 is false for all machine-specific attributes. 36704 36705 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1, 36706 const_tree TYPE2) 36707 If defined, this target hook is a function which returns zero if 36708 the attributes on TYPE1 and TYPE2 are incompatible, one if they are 36709 compatible, and two if they are nearly compatible (which causes a 36710 warning to be generated). If this is not defined, machine-specific 36711 attributes are supposed always to be compatible. 36712 36713 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 36714 If defined, this target hook is a function which assigns default 36715 attributes to the newly defined TYPE. 36716 36717 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 36718 TYPE2) 36719 Define this target hook if the merging of type attributes needs 36720 special handling. If defined, the result is a list of the combined 36721 'TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 36722 'comptypes' has already been called and returned 1. This function 36723 may call 'merge_attributes' to handle machine-independent merging. 36724 36725 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 36726 NEWDECL) 36727 Define this target hook if the merging of decl attributes needs 36728 special handling. If defined, the result is a list of the combined 36729 'DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 36730 declaration of OLDDECL. Examples of when this is needed are when 36731 one attribute overrides another, or when an attribute is nullified 36732 by a subsequent definition. This function may call 36733 'merge_attributes' to handle machine-independent merging. 36734 36735 If the only target-specific handling you require is 'dllimport' for 36736 Microsoft Windows targets, you should define the macro 36737 'TARGET_DLLIMPORT_DECL_ATTRIBUTES' to '1'. The compiler will then 36738 define a function called 'merge_dllimport_decl_attributes' which 36739 can then be defined as the expansion of 36740 'TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 36741 'handle_dll_attribute' in the attribute table for your port to 36742 perform initial processing of the 'dllimport' and 'dllexport' 36743 attributes. This is done in 'i386/cygwin.h' and 'i386/i386.c', for 36744 example. 36745 36746 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree 36747 DECL) 36748 DECL is a variable or function with '__attribute__((dllimport))' 36749 specified. Use this hook if the target needs to add extra 36750 validation checks to 'handle_dll_attribute'. 36751 36752 -- Macro: TARGET_DECLSPEC 36753 Define this macro to a nonzero value if you want to treat 36754 '__declspec(X)' as equivalent to '__attribute((X))'. By default, 36755 this behavior is enabled only for targets that define 36756 'TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 36757 '__declspec' is via a built-in macro, but you should not rely on 36758 this implementation detail. 36759 36760 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 36761 *ATTR_PTR) 36762 Define this target hook if you want to be able to add attributes to 36763 a decl when it is being created. This is normally useful for back 36764 ends which wish to implement a pragma by using the attributes which 36765 correspond to the pragma's effect. The NODE argument is the decl 36766 which is being created. The ATTR_PTR argument is a pointer to the 36767 attribute list for this decl. The list itself should not be 36768 modified, since it may be shared with other decls, but attributes 36769 may be chained on the head of the list and '*ATTR_PTR' modified to 36770 point to the new attributes, or a copy of the list may be made if 36771 further changes are needed. 36772 36773 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree 36774 FNDECL) 36775 This target hook returns 'true' if it is OK to inline FNDECL into 36776 the current function, despite its having target-specific 36777 attributes, 'false' otherwise. By default, if a function has a 36778 target specific attribute attached to it, it will not be inlined. 36779 36780 -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, tree 36781 NAME, tree ARGS, int FLAGS) 36782 This hook is called to parse 'attribute(target("..."))', which 36783 allows setting target-specific options on individual functions. 36784 These function-specific options may differ from the options 36785 specified on the command line. The hook should return 'true' if 36786 the options are valid. 36787 36788 The hook should set the 'DECL_FUNCTION_SPECIFIC_TARGET' field in 36789 the function declaration to hold a pointer to a target-specific 36790 'struct cl_target_option' structure. 36791 36792 -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR, 36793 struct gcc_options *OPTS) 36794 This hook is called to save any additional target-specific 36795 information in the 'struct cl_target_option' structure for 36796 function-specific options from the 'struct gcc_options' structure. 36797 *Note Option file format::. 36798 36799 -- Target Hook: void TARGET_OPTION_RESTORE (struct gcc_options *OPTS, 36800 struct cl_target_option *PTR) 36801 This hook is called to restore any additional target-specific 36802 information in the 'struct cl_target_option' structure for 36803 function-specific options to the 'struct gcc_options' structure. 36804 36805 -- Target Hook: void TARGET_OPTION_POST_STREAM_IN (struct 36806 cl_target_option *PTR) 36807 This hook is called to update target-specific information in the 36808 'struct cl_target_option' structure after it is streamed in from 36809 LTO bytecode. 36810 36811 -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT, 36812 struct cl_target_option *PTR) 36813 This hook is called to print any additional target-specific 36814 information in the 'struct cl_target_option' structure for 36815 function-specific options. 36816 36817 -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree 36818 POP_TARGET) 36819 This target hook parses the options for '#pragma GCC target', which 36820 sets the target-specific options for functions that occur later in 36821 the input stream. The options accepted should be the same as those 36822 handled by the 'TARGET_OPTION_VALID_ATTRIBUTE_P' hook. 36823 36824 -- Target Hook: void TARGET_OPTION_OVERRIDE (void) 36825 Sometimes certain combinations of command options do not make sense 36826 on a particular target machine. You can override the hook 36827 'TARGET_OPTION_OVERRIDE' to take account of this. This hooks is 36828 called once just after all the command options have been parsed. 36829 36830 Don't use this hook to turn on various extra optimizations for 36831 '-O'. That is what 'TARGET_OPTION_OPTIMIZATION' is for. 36832 36833 If you need to do something whenever the optimization level is 36834 changed via the optimize attribute or pragma, see 36835 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' 36836 36837 -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree 36838 DECL2) 36839 This target hook returns 'true' if DECL1 and DECL2 are versions of 36840 the same function. DECL1 and DECL2 are function versions if and 36841 only if they have the same function signature and different target 36842 specific attributes, that is, they are compiled for different 36843 target machines. 36844 36845 -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE) 36846 This target hook returns 'false' if the CALLER function cannot 36847 inline CALLEE, based on target specific information. By default, 36848 inlining is not allowed if the callee function has function 36849 specific target options and the caller does not use the same 36850 options. 36851 36852 36853File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros 36854 3685517.25 Emulating TLS 36856=================== 36857 36858For targets whose psABI does not provide Thread Local Storage via 36859specific relocations and instruction sequences, an emulation layer is 36860used. A set of target hooks allows this emulation layer to be 36861configured for the requirements of a particular target. For instance 36862the psABI may in fact specify TLS support in terms of an emulation 36863layer. 36864 36865 The emulation layer works by creating a control object for every TLS 36866object. To access the TLS object, a lookup function is provided which, 36867when given the address of the control object, will return the address of 36868the current thread's instance of the TLS object. 36869 36870 -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS 36871 Contains the name of the helper function that uses a TLS control 36872 object to locate a TLS instance. The default causes libgcc's 36873 emulated TLS helper function to be used. 36874 36875 -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON 36876 Contains the name of the helper function that should be used at 36877 program startup to register TLS objects that are implicitly 36878 initialized to zero. If this is 'NULL', all TLS objects will have 36879 explicit initializers. The default causes libgcc's emulated TLS 36880 registration function to be used. 36881 36882 -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION 36883 Contains the name of the section in which TLS control variables 36884 should be placed. The default of 'NULL' allows these to be placed 36885 in any section. 36886 36887 -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION 36888 Contains the name of the section in which TLS initializers should 36889 be placed. The default of 'NULL' allows these to be placed in any 36890 section. 36891 36892 -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX 36893 Contains the prefix to be prepended to TLS control variable names. 36894 The default of 'NULL' uses a target-specific prefix. 36895 36896 -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX 36897 Contains the prefix to be prepended to TLS initializer objects. 36898 The default of 'NULL' uses a target-specific prefix. 36899 36900 -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME) 36901 Specifies a function that generates the FIELD_DECLs for a TLS 36902 control object type. TYPE is the RECORD_TYPE the fields are for 36903 and NAME should be filled with the structure tag, if the default of 36904 '__emutls_object' is unsuitable. The default creates a type 36905 suitable for libgcc's emulated TLS function. 36906 36907 -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree 36908 TMPL_ADDR) 36909 Specifies a function that generates the CONSTRUCTOR to initialize a 36910 TLS control object. VAR is the TLS control object, DECL is the TLS 36911 object and TMPL_ADDR is the address of the initializer. The 36912 default initializes libgcc's emulated TLS control object. 36913 36914 -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED 36915 Specifies whether the alignment of TLS control variable objects is 36916 fixed and should not be increased as some backends may do to 36917 optimize single objects. The default is false. 36918 36919 -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS 36920 Specifies whether a DWARF 'DW_OP_form_tls_address' location 36921 descriptor may be used to describe emulated TLS control objects. 36922 36923 36924File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros 36925 3692617.26 Defining coprocessor specifics for MIPS targets. 36927====================================================== 36928 36929The MIPS specification allows MIPS implementations to have as many as 4 36930coprocessors, each with as many as 32 private registers. GCC supports 36931accessing these registers and transferring values between the registers 36932and memory using asm-ized variables. For example: 36933 36934 register unsigned int cp0count asm ("c0r1"); 36935 unsigned int d; 36936 36937 d = cp0count + 3; 36938 36939 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 36940names may be added as described below, or the default names may be 36941overridden entirely in 'SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 36942 36943 Coprocessor registers are assumed to be epilogue-used; sets to them 36944will be preserved even if it does not appear that the register is used 36945again later in the function. 36946 36947 Another note: according to the MIPS spec, coprocessor 1 (if present) is 36948the FPU. One accesses COP1 registers through standard mips 36949floating-point support; they are not included in this mechanism. 36950 36951 36952File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 36953 3695417.27 Parameters for Precompiled Header Validity Checking 36955========================================================= 36956 36957 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ) 36958 This hook returns a pointer to the data needed by 36959 'TARGET_PCH_VALID_P' and sets '*SZ' to the size of the data in 36960 bytes. 36961 36962 -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA, 36963 size_t SZ) 36964 This hook checks whether the options used to create a PCH file are 36965 compatible with the current settings. It returns 'NULL' if so and 36966 a suitable error message if not. Error messages will be presented 36967 to the user and must be localized using '_(MSG)'. 36968 36969 DATA is the data that was returned by 'TARGET_GET_PCH_VALIDITY' 36970 when the PCH file was created and SZ is the size of that data in 36971 bytes. It's safe to assume that the data was created by the same 36972 version of the compiler, so no format checking is needed. 36973 36974 The default definition of 'default_pch_valid_p' should be suitable 36975 for most targets. 36976 36977 -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int 36978 PCH_FLAGS) 36979 If this hook is nonnull, the default implementation of 36980 'TARGET_PCH_VALID_P' will use it to check for compatible values of 36981 'target_flags'. PCH_FLAGS specifies the value that 'target_flags' 36982 had when the PCH file was created. The return value is the same as 36983 for 'TARGET_PCH_VALID_P'. 36984 36985 -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void) 36986 Called before writing out a PCH file. If the target has some 36987 garbage-collected data that needs to be in a particular state on 36988 PCH loads, it can use this hook to enforce that state. Very few 36989 targets need to do anything here. 36990 36991 36992File: gccint.info, Node: C++ ABI, Next: Named Address Spaces, Prev: PCH Target, Up: Target Macros 36993 3699417.28 C++ ABI parameters 36995======================== 36996 36997 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 36998 Define this hook to override the integer type used for guard 36999 variables. These are used to implement one-time construction of 37000 static objects. The default is long_long_integer_type_node. 37001 37002 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 37003 This hook determines how guard variables are used. It should 37004 return 'false' (the default) if the first byte should be used. A 37005 return value of 'true' indicates that only the least significant 37006 bit should be used. 37007 37008 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 37009 This hook returns the size of the cookie to use when allocating an 37010 array whose elements have the indicated TYPE. Assumes that it is 37011 already known that a cookie is needed. The default is 'max(sizeof 37012 (size_t), alignof(type))', as defined in section 2.7 of the 37013 IA64/Generic C++ ABI. 37014 37015 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 37016 This hook should return 'true' if the element size should be stored 37017 in array cookies. The default is to return 'false'. 37018 37019 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 37020 IMPORT_EXPORT) 37021 If defined by a backend this hook allows the decision made to 37022 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 37023 contain 1 if the class is going to be exported, -1 if it is going 37024 to be imported and 0 otherwise. This function should return the 37025 modified value and perform any other actions necessary to support 37026 the backend's targeted operating system. 37027 37028 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 37029 This hook should return 'true' if constructors and destructors 37030 return the address of the object created/destroyed. The default is 37031 to return 'false'. 37032 37033 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 37034 This hook returns true if the key method for a class (i.e., the 37035 method which, if defined in the current translation unit, causes 37036 the virtual table to be emitted) may be an inline function. Under 37037 the standard Itanium C++ ABI the key method may be an inline 37038 function so long as the function is not declared inline in the 37039 class definition. Under some variants of the ABI, an inline 37040 function can never be the key method. The default is to return 37041 'true'. 37042 37043 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 37044 DECL) 37045 DECL is a virtual table, virtual table table, typeinfo object, or 37046 other similar implicit class data object that will be emitted with 37047 external linkage in this translation unit. No ELF visibility has 37048 been explicitly specified. If the target needs to specify a 37049 visibility other than that of the containing class, use this hook 37050 to set 'DECL_VISIBILITY' and 'DECL_VISIBILITY_SPECIFIED'. 37051 37052 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 37053 This hook returns true (the default) if virtual tables and other 37054 similar implicit class data objects are always COMDAT if they have 37055 external linkage. If this hook returns false, then class data for 37056 classes whose virtual table will be emitted in only one translation 37057 unit will not be COMDAT. 37058 37059 -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void) 37060 This hook returns true (the default) if the RTTI information for 37061 the basic types which is defined in the C++ runtime should always 37062 be COMDAT, false if it should not be COMDAT. 37063 37064 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 37065 This hook returns true if '__aeabi_atexit' (as defined by the ARM 37066 EABI) should be used to register static destructors when 37067 '-fuse-cxa-atexit' is in effect. The default is to return false to 37068 use '__cxa_atexit'. 37069 37070 -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void) 37071 This hook returns true if the target 'atexit' function can be used 37072 in the same manner as '__cxa_atexit' to register C++ static 37073 destructors. This requires that 'atexit'-registered functions in 37074 shared libraries are run in the correct order when the libraries 37075 are unloaded. The default is to return false. 37076 37077 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 37078 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has just 37079 been defined. Use this hook to make adjustments to the class (eg, 37080 tweak visibility or perform any other required target 37081 modifications). 37082 37083 -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL) 37084 Return target-specific mangling context of DECL or 'NULL_TREE'. 37085 37086 37087File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: C++ ABI, Up: Target Macros 37088 3708917.29 Adding support for named address spaces 37090============================================= 37091 37092The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards 37093committee, 'Programming Languages - C - Extensions to support embedded 37094processors', specifies a syntax for embedded processors to specify 37095alternate address spaces. You can configure a GCC port to support 37096section 5.1 of the draft report to add support for address spaces other 37097than the default address space. These address spaces are new keywords 37098that are similar to the 'volatile' and 'const' type attributes. 37099 37100 Pointers to named address spaces can have a different size than 37101pointers to the generic address space. 37102 37103 For example, the SPU port uses the '__ea' address space to refer to 37104memory in the host processor, rather than memory local to the SPU 37105processor. Access to memory in the '__ea' address space involves 37106issuing DMA operations to move data between the host processor and the 37107local processor memory address space. Pointers in the '__ea' address 37108space are either 32 bits or 64 bits based on the '-mea32' or '-mea64' 37109switches (native SPU pointers are always 32 bits). 37110 37111 Internally, address spaces are represented as a small integer in the 37112range 0 to 15 with address space 0 being reserved for the generic 37113address space. 37114 37115 To register a named address space qualifier keyword with the C front 37116end, the target may call the 'c_register_addr_space' routine. For 37117example, the SPU port uses the following to declare '__ea' as the 37118keyword for named address space #1: 37119 #define ADDR_SPACE_EA 1 37120 c_register_addr_space ("__ea", ADDR_SPACE_EA); 37121 37122 -- Target Hook: machine_mode TARGET_ADDR_SPACE_POINTER_MODE 37123 (addr_space_t ADDRESS_SPACE) 37124 Define this to return the machine mode to use for pointers to 37125 ADDRESS_SPACE if the target supports named address spaces. The 37126 default version of this hook returns 'ptr_mode' for the generic 37127 address space only. 37128 37129 -- Target Hook: machine_mode TARGET_ADDR_SPACE_ADDRESS_MODE 37130 (addr_space_t ADDRESS_SPACE) 37131 Define this to return the machine mode to use for addresses in 37132 ADDRESS_SPACE if the target supports named address spaces. The 37133 default version of this hook returns 'Pmode' for the generic 37134 address space only. 37135 37136 -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE (machine_mode 37137 MODE, addr_space_t AS) 37138 Define this to return nonzero if the port can handle pointers with 37139 machine mode MODE to address space AS. This target hook is the 37140 same as the 'TARGET_VALID_POINTER_MODE' target hook, except that it 37141 includes explicit named address space support. The default version 37142 of this hook returns true for the modes returned by either the 37143 'TARGET_ADDR_SPACE_POINTER_MODE' or 37144 'TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given address 37145 space. 37146 37147 -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P 37148 (machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS) 37149 Define this to return true if EXP is a valid address for mode MODE 37150 in the named address space AS. The STRICT parameter says whether 37151 strict addressing is in effect after reload has finished. This 37152 target hook is the same as the 'TARGET_LEGITIMATE_ADDRESS_P' target 37153 hook, except that it includes explicit named address space support. 37154 37155 -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx 37156 OLDX, machine_mode MODE, addr_space_t AS) 37157 Define this to modify an invalid address X to be a valid address 37158 with mode MODE in the named address space AS. This target hook is 37159 the same as the 'TARGET_LEGITIMIZE_ADDRESS' target hook, except 37160 that it includes explicit named address space support. 37161 37162 -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET, 37163 addr_space_t SUPERSET) 37164 Define this to return whether the SUBSET named address space is 37165 contained within the SUPERSET named address space. Pointers to a 37166 named address space that is a subset of another named address space 37167 will be converted automatically without a cast if used together in 37168 arithmetic operations. Pointers to a superset address space can be 37169 converted to pointers to a subset address space via explicit casts. 37170 37171 -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE, 37172 tree TO_TYPE) 37173 Define this to convert the pointer expression represented by the 37174 RTL OP with type FROM_TYPE that points to a named address space to 37175 a new pointer expression with type TO_TYPE that points to a 37176 different named address space. When this hook it called, it is 37177 guaranteed that one of the two address spaces is a subset of the 37178 other, as determined by the 'TARGET_ADDR_SPACE_SUBSET_P' target 37179 hook. 37180 37181 37182File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros 37183 3718417.30 Miscellaneous Parameters 37185============================== 37186 37187Here are several miscellaneous parameters. 37188 37189 -- Macro: HAS_LONG_COND_BRANCH 37190 Define this boolean macro to indicate whether or not your 37191 architecture has conditional branches that can span all of memory. 37192 It is used in conjunction with an optimization that partitions hot 37193 and cold basic blocks into separate sections of the executable. If 37194 this macro is set to false, gcc will convert any conditional 37195 branches that attempt to cross between sections into unconditional 37196 branches or indirect jumps. 37197 37198 -- Macro: HAS_LONG_UNCOND_BRANCH 37199 Define this boolean macro to indicate whether or not your 37200 architecture has unconditional branches that can span all of 37201 memory. It is used in conjunction with an optimization that 37202 partitions hot and cold basic blocks into separate sections of the 37203 executable. If this macro is set to false, gcc will convert any 37204 unconditional branches that attempt to cross between sections into 37205 indirect jumps. 37206 37207 -- Macro: CASE_VECTOR_MODE 37208 An alias for a machine mode name. This is the machine mode that 37209 elements of a jump-table should have. 37210 37211 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 37212 Optional: return the preferred mode for an 'addr_diff_vec' when the 37213 minimum and maximum offset are known. If you define this, it 37214 enables extra code in branch shortening to deal with 37215 'addr_diff_vec'. To make this work, you also have to define 37216 'INSN_ALIGN' and make the alignment for 'addr_diff_vec' explicit. 37217 The BODY argument is provided so that the offset_unsigned and scale 37218 flags can be updated. 37219 37220 -- Macro: CASE_VECTOR_PC_RELATIVE 37221 Define this macro to be a C expression to indicate when jump-tables 37222 should contain relative addresses. You need not define this macro 37223 if jump-tables never contain relative addresses, or jump-tables 37224 should contain relative addresses only when '-fPIC' or '-fPIC' is 37225 in effect. 37226 37227 -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void) 37228 This function return the smallest number of different values for 37229 which it is best to use a jump-table instead of a tree of 37230 conditional branches. The default is four for machines with a 37231 'casesi' instruction and five otherwise. This is best for most 37232 machines. 37233 37234 -- Macro: WORD_REGISTER_OPERATIONS 37235 Define this macro if operations between registers with integral 37236 mode smaller than a word are always performed on the entire 37237 register. Most RISC machines have this property and most CISC 37238 machines do not. 37239 37240 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 37241 Define this macro to be a C expression indicating when insns that 37242 read memory in MEM_MODE, an integral mode narrower than a word, set 37243 the bits outside of MEM_MODE to be either the sign-extension or the 37244 zero-extension of the data read. Return 'SIGN_EXTEND' for values 37245 of MEM_MODE for which the insn sign-extends, 'ZERO_EXTEND' for 37246 which it zero-extends, and 'UNKNOWN' for other modes. 37247 37248 This macro is not called with MEM_MODE non-integral or with a width 37249 greater than or equal to 'BITS_PER_WORD', so you may return any 37250 value in this case. Do not define this macro if it would always 37251 return 'UNKNOWN'. On machines where this macro is defined, you 37252 will normally define it as the constant 'SIGN_EXTEND' or 37253 'ZERO_EXTEND'. 37254 37255 You may return a non-'UNKNOWN' value even if for some hard 37256 registers the sign extension is not performed, if for the 37257 'REGNO_REG_CLASS' of these hard registers 37258 'CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is 37259 MEM_MODE and the TO mode is any integral mode larger than this but 37260 not larger than 'word_mode'. 37261 37262 You must return 'UNKNOWN' if for some hard registers that allow 37263 this mode, 'CANNOT_CHANGE_MODE_CLASS' says that they cannot change 37264 to 'word_mode', but that they can change to another integral mode 37265 that is larger then MEM_MODE but still smaller than 'word_mode'. 37266 37267 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 37268 Define this macro if loading short immediate values into registers 37269 sign extends. 37270 37271 -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL 37272 (machine_mode MODE) 37273 When '-ffast-math' is in effect, GCC tries to optimize divisions by 37274 the same divisor, by turning them into multiplications by the 37275 reciprocal. This target hook specifies the minimum number of 37276 divisions that should be there for GCC to perform the optimization 37277 for a variable of mode MODE. The default implementation returns 3 37278 if the machine has an instruction for the division, and 2 if it 37279 does not. 37280 37281 -- Macro: MOVE_MAX 37282 The maximum number of bytes that a single instruction can move 37283 quickly between memory and registers or between two memory 37284 locations. 37285 37286 -- Macro: MAX_MOVE_MAX 37287 The maximum number of bytes that a single instruction can move 37288 quickly between memory and registers or between two memory 37289 locations. If this is undefined, the default is 'MOVE_MAX'. 37290 Otherwise, it is the constant value that is the largest value that 37291 'MOVE_MAX' can have at run-time. 37292 37293 -- Macro: SHIFT_COUNT_TRUNCATED 37294 A C expression that is nonzero if on this machine the number of 37295 bits actually used for the count of a shift operation is equal to 37296 the number of bits needed to represent the size of the object being 37297 shifted. When this macro is nonzero, the compiler will assume that 37298 it is safe to omit a sign-extend, zero-extend, and certain bitwise 37299 'and' instructions that truncates the count of a shift operation. 37300 On machines that have instructions that act on bit-fields at 37301 variable positions, which may include 'bit test' instructions, a 37302 nonzero 'SHIFT_COUNT_TRUNCATED' also enables deletion of 37303 truncations of the values that serve as arguments to bit-field 37304 instructions. 37305 37306 If both types of instructions truncate the count (for shifts) and 37307 position (for bit-field operations), or if no variable-position 37308 bit-field instructions exist, you should define this macro. 37309 37310 However, on some machines, such as the 80386 and the 680x0, 37311 truncation only applies to shift operations and not the (real or 37312 pretended) bit-field operations. Define 'SHIFT_COUNT_TRUNCATED' to 37313 be zero on such machines. Instead, add patterns to the 'md' file 37314 that include the implied truncation of the shift instructions. 37315 37316 You need not define this macro if it would always have the value of 37317 zero. 37318 37319 -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK 37320 (machine_mode MODE) 37321 This function describes how the standard shift patterns for MODE 37322 deal with shifts by negative amounts or by more than the width of 37323 the mode. *Note shift patterns::. 37324 37325 On many machines, the shift patterns will apply a mask M to the 37326 shift count, meaning that a fixed-width shift of X by Y is 37327 equivalent to an arbitrary-width shift of X by Y & M. If this is 37328 true for mode MODE, the function should return M, otherwise it 37329 should return 0. A return value of 0 indicates that no particular 37330 behavior is guaranteed. 37331 37332 Note that, unlike 'SHIFT_COUNT_TRUNCATED', this function does _not_ 37333 apply to general shift rtxes; it applies only to instructions that 37334 are generated by the named shift patterns. 37335 37336 The default implementation of this function returns 37337 'GET_MODE_BITSIZE (MODE) - 1' if 'SHIFT_COUNT_TRUNCATED' and 0 37338 otherwise. This definition is always safe, but if 37339 'SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 37340 nevertheless truncate the shift count, you may get better code by 37341 overriding it. 37342 37343 -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC) 37344 A C expression which is nonzero if on this machine it is safe to 37345 "convert" an integer of INPREC bits to one of OUTPREC bits (where 37346 OUTPREC is smaller than INPREC) by merely operating on it as if it 37347 had only OUTPREC bits. 37348 37349 On many machines, this expression can be 1. 37350 37351 When 'TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for 37352 modes for which 'MODES_TIEABLE_P' is 0, suboptimal code can result. 37353 If this is the case, making 'TRULY_NOOP_TRUNCATION' return 0 in 37354 such cases may improve things. 37355 37356 -- Target Hook: int TARGET_MODE_REP_EXTENDED (machine_mode MODE, 37357 machine_mode REP_MODE) 37358 The representation of an integral mode can be such that the values 37359 are always extended to a wider integral mode. Return 'SIGN_EXTEND' 37360 if values of MODE are represented in sign-extended form to 37361 REP_MODE. Return 'UNKNOWN' otherwise. (Currently, none of the 37362 targets use zero-extended representation this way so unlike 37363 'LOAD_EXTEND_OP', 'TARGET_MODE_REP_EXTENDED' is expected to return 37364 either 'SIGN_EXTEND' or 'UNKNOWN'. Also no target extends MODE to 37365 REP_MODE so that REP_MODE is not the next widest integral mode and 37366 currently we take advantage of this fact.) 37367 37368 Similarly to 'LOAD_EXTEND_OP' you may return a non-'UNKNOWN' value 37369 even if the extension is not performed on certain hard registers as 37370 long as for the 'REGNO_REG_CLASS' of these hard registers 37371 'CANNOT_CHANGE_MODE_CLASS' returns nonzero. 37372 37373 Note that 'TARGET_MODE_REP_EXTENDED' and 'LOAD_EXTEND_OP' describe 37374 two related properties. If you define 'TARGET_MODE_REP_EXTENDED 37375 (mode, word_mode)' you probably also want to define 'LOAD_EXTEND_OP 37376 (mode)' to return the same type of extension. 37377 37378 In order to enforce the representation of 'mode', 37379 'TRULY_NOOP_TRUNCATION' should return false when truncating to 37380 'mode'. 37381 37382 -- Macro: STORE_FLAG_VALUE 37383 A C expression describing the value returned by a comparison 37384 operator with an integral mode and stored by a store-flag 37385 instruction ('cstoreMODE4') when the condition is true. This 37386 description must apply to _all_ the 'cstoreMODE4' patterns and all 37387 the comparison operators whose results have a 'MODE_INT' mode. 37388 37389 A value of 1 or -1 means that the instruction implementing the 37390 comparison operator returns exactly 1 or -1 when the comparison is 37391 true and 0 when the comparison is false. Otherwise, the value 37392 indicates which bits of the result are guaranteed to be 1 when the 37393 comparison is true. This value is interpreted in the mode of the 37394 comparison operation, which is given by the mode of the first 37395 operand in the 'cstoreMODE4' pattern. Either the low bit or the 37396 sign bit of 'STORE_FLAG_VALUE' be on. Presently, only those bits 37397 are used by the compiler. 37398 37399 If 'STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 37400 generate code that depends only on the specified bits. It can also 37401 replace comparison operators with equivalent operations if they 37402 cause the required bits to be set, even if the remaining bits are 37403 undefined. For example, on a machine whose comparison operators 37404 return an 'SImode' value and where 'STORE_FLAG_VALUE' is defined as 37405 '0x80000000', saying that just the sign bit is relevant, the 37406 expression 37407 37408 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 37409 37410 can be converted to 37411 37412 (ashift:SI X (const_int N)) 37413 37414 where N is the appropriate shift count to move the bit being tested 37415 into the sign bit. 37416 37417 There is no way to describe a machine that always sets the 37418 low-order bit for a true value, but does not guarantee the value of 37419 any other bits, but we do not know of any machine that has such an 37420 instruction. If you are trying to port GCC to such a machine, 37421 include an instruction to perform a logical-and of the result with 37422 1 in the pattern for the comparison operators and let us know at 37423 <gcc@gcc.gnu.org>. 37424 37425 Often, a machine will have multiple instructions that obtain a 37426 value from a comparison (or the condition codes). Here are rules 37427 to guide the choice of value for 'STORE_FLAG_VALUE', and hence the 37428 instructions to be used: 37429 37430 * Use the shortest sequence that yields a valid definition for 37431 'STORE_FLAG_VALUE'. It is more efficient for the compiler to 37432 "normalize" the value (convert it to, e.g., 1 or 0) than for 37433 the comparison operators to do so because there may be 37434 opportunities to combine the normalization with other 37435 operations. 37436 37437 * For equal-length sequences, use a value of 1 or -1, with -1 37438 being slightly preferred on machines with expensive jumps and 37439 1 preferred on other machines. 37440 37441 * As a second choice, choose a value of '0x80000001' if 37442 instructions exist that set both the sign and low-order bits 37443 but do not define the others. 37444 37445 * Otherwise, use a value of '0x80000000'. 37446 37447 Many machines can produce both the value chosen for 37448 'STORE_FLAG_VALUE' and its negation in the same number of 37449 instructions. On those machines, you should also define a pattern 37450 for those cases, e.g., one matching 37451 37452 (set A (neg:M (ne:M B C))) 37453 37454 Some machines can also perform 'and' or 'plus' operations on 37455 condition code values with less instructions than the corresponding 37456 'cstoreMODE4' insn followed by 'and' or 'plus'. On those machines, 37457 define the appropriate patterns. Use the names 'incscc' and 37458 'decscc', respectively, for the patterns which perform 'plus' or 37459 'minus' operations on condition code values. See 'rs6000.md' for 37460 some examples. The GNU Superoptimizer can be used to find such 37461 instruction sequences on other machines. 37462 37463 If this macro is not defined, the default value, 1, is used. You 37464 need not define 'STORE_FLAG_VALUE' if the machine has no store-flag 37465 instructions, or if the value generated by these instructions is 1. 37466 37467 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 37468 A C expression that gives a nonzero 'REAL_VALUE_TYPE' value that is 37469 returned when comparison operators with floating-point results are 37470 true. Define this macro on machines that have comparison 37471 operations that return floating-point values. If there are no such 37472 operations, do not define this macro. 37473 37474 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 37475 A C expression that gives a rtx representing the nonzero true 37476 element for vector comparisons. The returned rtx should be valid 37477 for the inner mode of MODE which is guaranteed to be a vector mode. 37478 Define this macro on machines that have vector comparison 37479 operations that return a vector result. If there are no such 37480 operations, do not define this macro. Typically, this macro is 37481 defined as 'const1_rtx' or 'constm1_rtx'. This macro may return 37482 'NULL_RTX' to prevent the compiler optimizing such vector 37483 comparison operations for the given mode. 37484 37485 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 37486 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 37487 A C expression that indicates whether the architecture defines a 37488 value for 'clz' or 'ctz' with a zero operand. A result of '0' 37489 indicates the value is undefined. If the value is defined for only 37490 the RTL expression, the macro should evaluate to '1'; if the value 37491 applies also to the corresponding optab entry (which is normally 37492 the case if it expands directly into the corresponding RTL), then 37493 the macro should evaluate to '2'. In the cases where the value is 37494 defined, VALUE should be set to this value. 37495 37496 If this macro is not defined, the value of 'clz' or 'ctz' at zero 37497 is assumed to be undefined. 37498 37499 This macro must be defined if the target's expansion for 'ffs' 37500 relies on a particular value to get correct results. Otherwise it 37501 is not necessary, though it may be used to optimize some corner 37502 cases, and to provide a default expansion for the 'ffs' optab. 37503 37504 Note that regardless of this macro the "definedness" of 'clz' and 37505 'ctz' at zero do _not_ extend to the builtin functions visible to 37506 the user. Thus one may be free to adjust the value at will to 37507 match the target expansion of these operations without fear of 37508 breaking the API. 37509 37510 -- Macro: Pmode 37511 An alias for the machine mode for pointers. On most machines, 37512 define this to be the integer mode corresponding to the width of a 37513 hardware pointer; 'SImode' on 32-bit machine or 'DImode' on 64-bit 37514 machines. On some machines you must define this to be one of the 37515 partial integer modes, such as 'PSImode'. 37516 37517 The width of 'Pmode' must be at least as large as the value of 37518 'POINTER_SIZE'. If it is not equal, you must define the macro 37519 'POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 37520 'Pmode'. 37521 37522 -- Macro: FUNCTION_MODE 37523 An alias for the machine mode used for memory references to 37524 functions being called, in 'call' RTL expressions. On most CISC 37525 machines, where an instruction can begin at any byte address, this 37526 should be 'QImode'. On most RISC machines, where all instructions 37527 have fixed size and alignment, this should be a mode with the same 37528 size and alignment as the machine instruction words - typically 37529 'SImode' or 'HImode'. 37530 37531 -- Macro: STDC_0_IN_SYSTEM_HEADERS 37532 In normal operation, the preprocessor expands '__STDC__' to the 37533 constant 1, to signify that GCC conforms to ISO Standard C. On 37534 some hosts, like Solaris, the system compiler uses a different 37535 convention, where '__STDC__' is normally 0, but is 1 if the user 37536 specifies strict conformance to the C Standard. 37537 37538 Defining 'STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 37539 convention when processing system header files, but when processing 37540 user files '__STDC__' will always expand to 1. 37541 37542 -- C Target Hook: const char * TARGET_C_PREINCLUDE (void) 37543 Define this hook to return the name of a header file to be included 37544 at the start of all compilations, as if it had been included with 37545 '#include <FILE>'. If this hook returns 'NULL', or is not defined, 37546 or the header is not found, or if the user specifies 37547 '-ffreestanding' or '-nostdinc', no header is included. 37548 37549 This hook can be used together with a header provided by the system 37550 C library to implement ISO C requirements for certain macros to be 37551 predefined that describe properties of the whole implementation 37552 rather than just the compiler. 37553 37554 -- C Target Hook: bool TARGET_CXX_IMPLICIT_EXTERN_C (const char*) 37555 Define this hook to add target-specific C++ implicit extern C 37556 functions. If this function returns true for the name of a 37557 file-scope function, that function implicitly gets extern "C" 37558 linkage rather than whatever language linkage the declaration would 37559 normally have. An example of such function is WinMain on Win32 37560 targets. 37561 37562 -- Macro: NO_IMPLICIT_EXTERN_C 37563 Define this macro if the system header files support C++ as well as 37564 C. This macro inhibits the usual method of using system header 37565 files in C++, which is to pretend that the file's contents are 37566 enclosed in 'extern "C" {...}'. 37567 37568 -- Macro: REGISTER_TARGET_PRAGMAS () 37569 Define this macro if you want to implement any target-specific 37570 pragmas. If defined, it is a C expression which makes a series of 37571 calls to 'c_register_pragma' or 'c_register_pragma_with_expansion' 37572 for each pragma. The macro may also do any setup required for the 37573 pragmas. 37574 37575 The primary reason to define this macro is to provide compatibility 37576 with other compilers for the same target. In general, we 37577 discourage definition of target-specific pragmas for GCC. 37578 37579 If the pragma can be implemented by attributes then you should 37580 consider defining the target hook 'TARGET_INSERT_ATTRIBUTES' as 37581 well. 37582 37583 Preprocessor macros that appear on pragma lines are not expanded. 37584 All '#pragma' directives that do not match any registered pragma 37585 are silently ignored, unless the user specifies 37586 '-Wunknown-pragmas'. 37587 37588 -- Function: void c_register_pragma (const char *SPACE, const char 37589 *NAME, void (*CALLBACK) (struct cpp_reader *)) 37590 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 37591 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 37592 37593 Each call to 'c_register_pragma' or 37594 'c_register_pragma_with_expansion' establishes one pragma. The 37595 CALLBACK routine will be called when the preprocessor encounters a 37596 pragma of the form 37597 37598 #pragma [SPACE] NAME ... 37599 37600 SPACE is the case-sensitive namespace of the pragma, or 'NULL' to 37601 put the pragma in the global namespace. The callback routine 37602 receives PFILE as its first argument, which can be passed on to 37603 cpplib's functions if necessary. You can lex tokens after the NAME 37604 by calling 'pragma_lex'. Tokens that are not read by the callback 37605 will be silently ignored. The end of the line is indicated by a 37606 token of type 'CPP_EOF'. Macro expansion occurs on the arguments 37607 of pragmas registered with 'c_register_pragma_with_expansion' but 37608 not on the arguments of pragmas registered with 37609 'c_register_pragma'. 37610 37611 Note that the use of 'pragma_lex' is specific to the C and C++ 37612 compilers. It will not work in the Java or Fortran compilers, or 37613 any other language compilers for that matter. Thus if 'pragma_lex' 37614 is going to be called from target-specific code, it must only be 37615 done so when building the C and C++ compilers. This can be done by 37616 defining the variables 'c_target_objs' and 'cxx_target_objs' in the 37617 target entry in the 'config.gcc' file. These variables should name 37618 the target-specific, language-specific object file which contains 37619 the code that uses 'pragma_lex'. Note it will also be necessary to 37620 add a rule to the makefile fragment pointed to by 'tmake_file' that 37621 shows how to build this object file. 37622 37623 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 37624 Define this macro if macros should be expanded in the arguments of 37625 '#pragma pack'. 37626 37627 -- Macro: TARGET_DEFAULT_PACK_STRUCT 37628 If your target requires a structure packing default other than 0 37629 (meaning the machine default), define this macro to the necessary 37630 value (in bytes). This must be a value that would also be valid to 37631 use with '#pragma pack()' (that is, a small power of two). 37632 37633 -- Macro: DOLLARS_IN_IDENTIFIERS 37634 Define this macro to control use of the character '$' in identifier 37635 names for the C family of languages. 0 means '$' is not allowed by 37636 default; 1 means it is allowed. 1 is the default; there is no need 37637 to define this macro in that case. 37638 37639 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 37640 Define this macro as a C expression that is nonzero if it is safe 37641 for the delay slot scheduler to place instructions in the delay 37642 slot of INSN, even if they appear to use a resource set or 37643 clobbered in INSN. INSN is always a 'jump_insn' or an 'insn'; GCC 37644 knows that every 'call_insn' has this behavior. On machines where 37645 some 'insn' or 'jump_insn' is really a function call and hence has 37646 this behavior, you should define this macro. 37647 37648 You need not define this macro if it would always return zero. 37649 37650 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 37651 Define this macro as a C expression that is nonzero if it is safe 37652 for the delay slot scheduler to place instructions in the delay 37653 slot of INSN, even if they appear to set or clobber a resource 37654 referenced in INSN. INSN is always a 'jump_insn' or an 'insn'. On 37655 machines where some 'insn' or 'jump_insn' is really a function call 37656 and its operands are registers whose use is actually in the 37657 subroutine it calls, you should define this macro. Doing so allows 37658 the delay slot scheduler to move instructions which copy arguments 37659 into the argument registers into the delay slot of INSN. 37660 37661 You need not define this macro if it would always return zero. 37662 37663 -- Macro: MULTIPLE_SYMBOL_SPACES 37664 Define this macro as a C expression that is nonzero if, in some 37665 cases, global symbols from one translation unit may not be bound to 37666 undefined symbols in another translation unit without user 37667 intervention. For instance, under Microsoft Windows symbols must 37668 be explicitly imported from shared libraries (DLLs). 37669 37670 You need not define this macro if it would always evaluate to zero. 37671 37672 -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree INPUTS, 37673 tree CLOBBERS) 37674 This target hook should add to CLOBBERS 'STRING_CST' trees for any 37675 hard regs the port wishes to automatically clobber for an asm. It 37676 should return the result of the last 'tree_cons' used to add a 37677 clobber. The OUTPUTS, INPUTS and CLOBBER lists are the 37678 corresponding parameters to the asm and may be inspected to avoid 37679 clobbering a register that is an input or output of the asm. You 37680 can use 'tree_overlaps_hard_reg_set', declared in 'tree.h', to test 37681 for overlap with regards to asm-declared registers. 37682 37683 -- Macro: MATH_LIBRARY 37684 Define this macro as a C string constant for the linker argument to 37685 link in the system math library, minus the initial '"-l"', or '""' 37686 if the target does not have a separate math library. 37687 37688 You need only define this macro if the default of '"m"' is wrong. 37689 37690 -- Macro: LIBRARY_PATH_ENV 37691 Define this macro as a C string constant for the environment 37692 variable that specifies where the linker should look for libraries. 37693 37694 You need only define this macro if the default of '"LIBRARY_PATH"' 37695 is wrong. 37696 37697 -- Macro: TARGET_POSIX_IO 37698 Define this macro if the target supports the following POSIX file 37699 functions, access, mkdir and file locking with fcntl / F_SETLKW. 37700 Defining 'TARGET_POSIX_IO' will enable the test coverage code to 37701 use file locking when exiting a program, which avoids race 37702 conditions if the program has forked. It will also create 37703 directories at run-time for cross-profiling. 37704 37705 -- Macro: MAX_CONDITIONAL_EXECUTE 37706 37707 A C expression for the maximum number of instructions to execute 37708 via conditional execution instructions instead of a branch. A 37709 value of 'BRANCH_COST'+1 is the default if the machine does not use 37710 cc0, and 1 if it does use cc0. 37711 37712 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 37713 Used if the target needs to perform machine-dependent modifications 37714 on the conditionals used for turning basic blocks into 37715 conditionally executed code. CE_INFO points to a data structure, 37716 'struct ce_if_block', which contains information about the 37717 currently processed blocks. TRUE_EXPR and FALSE_EXPR are the tests 37718 that are used for converting the then-block and the else-block, 37719 respectively. Set either TRUE_EXPR or FALSE_EXPR to a null pointer 37720 if the tests cannot be converted. 37721 37722 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 37723 FALSE_EXPR) 37724 Like 'IFCVT_MODIFY_TESTS', but used when converting more 37725 complicated if-statements into conditions combined by 'and' and 37726 'or' operations. BB contains the basic block that contains the 37727 test that is currently being processed and about to be turned into 37728 a condition. 37729 37730 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 37731 A C expression to modify the PATTERN of an INSN that is to be 37732 converted to conditional execution format. CE_INFO points to a 37733 data structure, 'struct ce_if_block', which contains information 37734 about the currently processed blocks. 37735 37736 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 37737 A C expression to perform any final machine dependent modifications 37738 in converting code to conditional execution. The involved basic 37739 blocks can be found in the 'struct ce_if_block' structure that is 37740 pointed to by CE_INFO. 37741 37742 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 37743 A C expression to cancel any machine dependent modifications in 37744 converting code to conditional execution. The involved basic 37745 blocks can be found in the 'struct ce_if_block' structure that is 37746 pointed to by CE_INFO. 37747 37748 -- Macro: IFCVT_MACHDEP_INIT (CE_INFO) 37749 A C expression to initialize any machine specific data for 37750 if-conversion of the if-block in the 'struct ce_if_block' structure 37751 that is pointed to by CE_INFO. 37752 37753 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void) 37754 If non-null, this hook performs a target-specific pass over the 37755 instruction stream. The compiler will run it at all optimization 37756 levels, just before the point at which it normally does 37757 delayed-branch scheduling. 37758 37759 The exact purpose of the hook varies from target to target. Some 37760 use it to do transformations that are necessary for correctness, 37761 such as laying out in-function constant pools or avoiding hardware 37762 hazards. Others use it as an opportunity to do some 37763 machine-dependent optimizations. 37764 37765 You need not implement the hook if it has nothing to do. The 37766 default definition is null. 37767 37768 -- Target Hook: void TARGET_INIT_BUILTINS (void) 37769 Define this hook if you have any machine-specific built-in 37770 functions that need to be defined. It should be a function that 37771 performs the necessary setup. 37772 37773 Machine specific built-in functions can be useful to expand special 37774 machine instructions that would otherwise not normally be generated 37775 because they have no equivalent in the source language (for 37776 example, SIMD vector instructions or prefetch instructions). 37777 37778 To create a built-in function, call the function 37779 'lang_hooks.builtin_function' which is defined by the language 37780 front end. You can use any type nodes set up by 37781 'build_common_tree_nodes'; only language front ends that use those 37782 two functions will call 'TARGET_INIT_BUILTINS'. 37783 37784 -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool 37785 INITIALIZE_P) 37786 Define this hook if you have any machine-specific built-in 37787 functions that need to be defined. It should be a function that 37788 returns the builtin function declaration for the builtin function 37789 code CODE. If there is no such builtin and it cannot be 37790 initialized at this time if INITIALIZE_P is true the function 37791 should return 'NULL_TREE'. If CODE is out of range the function 37792 should return 'error_mark_node'. 37793 37794 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 37795 SUBTARGET, machine_mode MODE, int IGNORE) 37796 37797 Expand a call to a machine specific built-in function that was set 37798 up by 'TARGET_INIT_BUILTINS'. EXP is the expression for the 37799 function call; the result should go to TARGET if that is 37800 convenient, and have mode MODE if that is convenient. SUBTARGET 37801 may be used as the target for computing one of EXP's operands. 37802 IGNORE is nonzero if the value is to be ignored. This function 37803 should return the result of the call to the built-in function. 37804 37805 -- Target Hook: tree TARGET_BUILTIN_CHKP_FUNCTION (unsigned FCODE) 37806 This hook allows target to redefine built-in functions used by 37807 Pointer Bounds Checker for code instrumentation. Hook should 37808 return fndecl of function implementing generic builtin whose code 37809 is passed in FCODE. Currently following built-in functions are 37810 obtained using this hook: 37811 -- Built-in Function: __bounds_type __chkp_bndmk (const void *LB, 37812 size_t SIZE) 37813 Function code - BUILT_IN_CHKP_BNDMK. This built-in function is 37814 used by Pointer Bounds Checker to create bound values. LB 37815 holds low bound of the resulting bounds. SIZE holds size of 37816 created bounds. 37817 37818 -- Built-in Function: void __chkp_bndstx (const void *PTR, 37819 __bounds_type B, const void **LOC) 37820 Function code - 'BUILT_IN_CHKP_BNDSTX'. This built-in 37821 function is used by Pointer Bounds Checker to store bounds B 37822 for pointer PTR when PTR is stored by address LOC. 37823 37824 -- Built-in Function: __bounds_type __chkp_bndldx (const void 37825 **LOC, const void *PTR) 37826 Function code - 'BUILT_IN_CHKP_BNDLDX'. This built-in 37827 function is used by Pointer Bounds Checker to get bounds of 37828 pointer PTR loaded by address LOC. 37829 37830 -- Built-in Function: void __chkp_bndcl (const void *PTR, 37831 __bounds_type B) 37832 Function code - 'BUILT_IN_CHKP_BNDCL'. This built-in function 37833 is used by Pointer Bounds Checker to perform check for pointer 37834 PTR against lower bound of bounds B. 37835 37836 -- Built-in Function: void __chkp_bndcu (const void *PTR, 37837 __bounds_type B) 37838 Function code - 'BUILT_IN_CHKP_BNDCU'. This built-in function 37839 is used by Pointer Bounds Checker to perform check for pointer 37840 PTR against upper bound of bounds B. 37841 37842 -- Built-in Function: __bounds_type __chkp_bndret (void *PTR) 37843 Function code - 'BUILT_IN_CHKP_BNDRET'. This built-in 37844 function is used by Pointer Bounds Checker to obtain bounds 37845 returned by a call statement. PTR passed to built-in is 37846 'SSA_NAME' returned by the call. 37847 37848 -- Built-in Function: __bounds_type __chkp_intersect 37849 (__bounds_type B1, __bounds_type B2) 37850 Function code - 'BUILT_IN_CHKP_INTERSECT'. This built-in 37851 function returns intersection of bounds B1 and B2. 37852 37853 -- Built-in Function: __bounds_type __chkp_narrow (const void 37854 *PTR, __bounds_type B, size_t S) 37855 Function code - 'BUILT_IN_CHKP_NARROW'. This built-in 37856 function returns intersection of bounds B and [PTR, PTR + S - 37857 '1']. 37858 37859 -- Built-in Function: size_t __chkp_sizeof (const void *PTR) 37860 Function code - 'BUILT_IN_CHKP_SIZEOF'. This built-in 37861 function returns size of object referenced by PTR. PTR is 37862 always 'ADDR_EXPR' of 'VAR_DECL'. This built-in is used by 37863 Pointer Bounds Checker when bounds of object cannot be 37864 computed statically (e.g. object has incomplete type). 37865 37866 -- Built-in Function: const void *__chkp_extract_lower 37867 (__bounds_type B) 37868 Function code - 'BUILT_IN_CHKP_EXTRACT_LOWER'. This built-in 37869 function returns lower bound of bounds B. 37870 37871 -- Built-in Function: const void *__chkp_extract_upper 37872 (__bounds_type B) 37873 Function code - 'BUILT_IN_CHKP_EXTRACT_UPPER'. This built-in 37874 function returns upper bound of bounds B. 37875 -- Target Hook: tree TARGET_CHKP_BOUND_TYPE (void) 37876 Return type to be used for bounds 37877 -- Target Hook: enum machine_mode TARGET_CHKP_BOUND_MODE (void) 37878 Return mode to be used for bounds. 37879 -- Target Hook: tree TARGET_CHKP_MAKE_BOUNDS_CONSTANT (HOST_WIDE_INT 37880 LB, HOST_WIDE_INT UB) 37881 Return constant used to statically initialize constant bounds with 37882 specified lower bound LB and upper bounds UB. 37883 -- Target Hook: int TARGET_CHKP_INITIALIZE_BOUNDS (tree VAR, tree LB, 37884 tree UB, tree *STMTS) 37885 Generate a list of statements STMTS to initialize pointer bounds 37886 variable VAR with bounds LB and UB. Return the number of generated 37887 statements. 37888 37889 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int 37890 LOC, tree FNDECL, void *ARGLIST) 37891 Select a replacement for a machine specific built-in function that 37892 was set up by 'TARGET_INIT_BUILTINS'. This is done _before_ 37893 regular type checking, and so allows the target to implement a 37894 crude form of function overloading. FNDECL is the declaration of 37895 the built-in function. ARGLIST is the list of arguments passed to 37896 the built-in function. The result is a complete expression that 37897 implements the operation, usually another 'CALL_EXPR'. ARGLIST 37898 really has type 'VEC(tree,gc)*' 37899 37900 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, tree 37901 *ARGP, bool IGNORE) 37902 Fold a call to a machine specific built-in function that was set up 37903 by 'TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 37904 built-in function. N_ARGS is the number of arguments passed to the 37905 function; the arguments themselves are pointed to by ARGP. The 37906 result is another tree, valid for both GIMPLE and GENERIC, 37907 containing a simplified expression for the call's result. If 37908 IGNORE is true the value will be ignored. 37909 37910 -- Target Hook: bool TARGET_GIMPLE_FOLD_BUILTIN (gimple_stmt_iterator 37911 *GSI) 37912 Fold a call to a machine specific built-in function that was set up 37913 by 'TARGET_INIT_BUILTINS'. GSI points to the gimple statement 37914 holding the function call. Returns true if any change was made to 37915 the GIMPLE stream. 37916 37917 -- Target Hook: int TARGET_COMPARE_VERSION_PRIORITY (tree DECL1, tree 37918 DECL2) 37919 This hook is used to compare the target attributes in two functions 37920 to determine which function's features get higher priority. This 37921 is used during function multi-versioning to figure out the order in 37922 which two versions must be dispatched. A function version with a 37923 higher priority is checked for dispatching earlier. DECL1 and 37924 DECL2 are the two function decls that will be compared. 37925 37926 -- Target Hook: tree TARGET_GET_FUNCTION_VERSIONS_DISPATCHER (void 37927 *DECL) 37928 This hook is used to get the dispatcher function for a set of 37929 function versions. The dispatcher function is called to invoke the 37930 right function version at run-time. DECL is one version from a set 37931 of semantically identical versions. 37932 37933 -- Target Hook: tree TARGET_GENERATE_VERSION_DISPATCHER_BODY (void 37934 *ARG) 37935 This hook is used to generate the dispatcher logic to invoke the 37936 right function version at run-time for a given set of function 37937 versions. ARG points to the callgraph node of the dispatcher 37938 function whose body must be generated. 37939 37940 -- Target Hook: bool TARGET_CAN_USE_DOLOOP_P (const widest_int 37941 &ITERATIONS, const widest_int &ITERATIONS_MAX, unsigned int 37942 LOOP_DEPTH, bool ENTERED_AT_TOP) 37943 Return true if it is possible to use low-overhead loops 37944 ('doloop_end' and 'doloop_begin') for a particular loop. 37945 ITERATIONS gives the exact number of iterations, or 0 if not known. 37946 ITERATIONS_MAX gives the maximum number of iterations, or 0 if not 37947 known. LOOP_DEPTH is the nesting depth of the loop, with 1 for 37948 innermost loops, 2 for loops that contain innermost loops, and so 37949 on. ENTERED_AT_TOP is true if the loop is only entered from the 37950 top. 37951 37952 This hook is only used if 'doloop_end' is available. The default 37953 implementation returns true. You can use 37954 'can_use_doloop_if_innermost' if the loop must be the innermost, 37955 and if there are no other restrictions. 37956 37957 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const 37958 rtx_insn *INSN) 37959 37960 Take an instruction in INSN and return NULL if it is valid within a 37961 low-overhead loop, otherwise return a string explaining why doloop 37962 could not be applied. 37963 37964 Many targets use special registers for low-overhead looping. For 37965 any instruction that clobbers these this function should return a 37966 string indicating the reason why the doloop could not be applied. 37967 By default, the RTL loop optimizer does not use a present doloop 37968 pattern for loops containing function calls or branch on table 37969 instructions. 37970 37971 -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx_insn *INSN) 37972 Take an instruction in INSN and return 'false' if the instruction 37973 is not appropriate as a combination of two or more instructions. 37974 The default is to accept all instructions. 37975 37976 -- Target Hook: bool TARGET_CAN_FOLLOW_JUMP (const rtx_insn *FOLLOWER, 37977 const rtx_insn *FOLLOWEE) 37978 FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if 37979 FOLLOWER may be modified to follow FOLLOWEE; false, if it can't. 37980 For example, on some targets, certain kinds of branches can't be 37981 made to follow through a hot/cold partitioning. 37982 37983 -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE) 37984 This target hook returns 'true' if X is considered to be 37985 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 37986 PA doesn't consider PLUS to be commutative inside a MEM. 37987 OUTER_CODE is the rtx code of the enclosing rtl, if known, 37988 otherwise it is UNKNOWN. 37989 37990 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 37991 37992 When the initial value of a hard register has been copied in a 37993 pseudo register, it is often not necessary to actually allocate 37994 another register to this pseudo register, because the original hard 37995 register or a stack slot it has been saved into can be used. 37996 'TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 37997 allocation once for each hard register that had its initial value 37998 copied by using 'get_func_hard_reg_initial_val' or 37999 'get_hard_reg_initial_val'. Possible values are 'NULL_RTX', if you 38000 don't want to do any special allocation, a 'REG' rtx--that would 38001 typically be the hard register itself, if it is known not to be 38002 clobbered--or a 'MEM'. If you are returning a 'MEM', this is only 38003 a hint for the allocator; it might decide to use another register 38004 anyways. You may use 'current_function_is_leaf' or 'REG_N_SETS' in 38005 the hook to determine if the hard register in question will not be 38006 clobbered. The default value of this hook is 'NULL', which 38007 disables any special allocation. 38008 38009 -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned 38010 FLAGS) 38011 This target hook returns nonzero if X, an 'unspec' or 38012 'unspec_volatile' operation, might cause a trap. Targets can use 38013 this hook to enhance precision of analysis for 'unspec' and 38014 'unspec_volatile' operations. You may call 'may_trap_p_1' to 38015 analyze inner elements of X in which case FLAGS should be passed 38016 along. 38017 38018 -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) 38019 The compiler invokes this hook whenever it changes its current 38020 function context ('cfun'). You can define this function if the 38021 back end needs to perform any initialization or reset actions on a 38022 per-function basis. For example, it may be used to implement 38023 function attributes that affect register usage or code generation 38024 patterns. The argument DECL is the declaration for the new 38025 function context, and may be null to indicate that the compiler has 38026 left a function context and is returning to processing at the top 38027 level. The default hook function does nothing. 38028 38029 GCC sets 'cfun' to a dummy function context during initialization 38030 of some parts of the back end. The hook function is not invoked in 38031 this situation; you need not worry about the hook being invoked 38032 recursively, or when the back end is in a partially-initialized 38033 state. 'cfun' might be 'NULL' to indicate processing at top level, 38034 outside of any function scope. 38035 38036 -- Macro: TARGET_OBJECT_SUFFIX 38037 Define this macro to be a C string representing the suffix for 38038 object files on your target machine. If you do not define this 38039 macro, GCC will use '.o' as the suffix for object files. 38040 38041 -- Macro: TARGET_EXECUTABLE_SUFFIX 38042 Define this macro to be a C string representing the suffix to be 38043 automatically added to executable files on your target machine. If 38044 you do not define this macro, GCC will use the null string as the 38045 suffix for executable files. 38046 38047 -- Macro: COLLECT_EXPORT_LIST 38048 If defined, 'collect2' will scan the individual object files 38049 specified on its command line and create an export list for the 38050 linker. Define this macro for systems like AIX, where the linker 38051 discards object files that are not referenced from 'main' and uses 38052 export lists. 38053 38054 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) 38055 Define this macro to a C expression representing a variant of the 38056 method call MDECL, if Java Native Interface (JNI) methods must be 38057 invoked differently from other methods on your target. For 38058 example, on 32-bit Microsoft Windows, JNI methods must be invoked 38059 using the 'stdcall' calling convention and this macro is then 38060 defined as this expression: 38061 38062 build_type_attribute_variant (MDECL, 38063 build_tree_list 38064 (get_identifier ("stdcall"), 38065 NULL)) 38066 38067 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 38068 This target hook returns 'true' past the point in which new jump 38069 instructions could be created. On machines that require a register 38070 for every jump such as the SHmedia ISA of SH5, this point would 38071 typically be reload, so this target hook should be defined to a 38072 function such as: 38073 38074 static bool 38075 cannot_modify_jumps_past_reload_p () 38076 { 38077 return (reload_completed || reload_in_progress); 38078 } 38079 38080 -- Target Hook: reg_class_t TARGET_BRANCH_TARGET_REGISTER_CLASS (void) 38081 This target hook returns a register class for which branch target 38082 register optimizations should be applied. All registers in this 38083 class should be usable interchangeably. After reload, registers in 38084 this class will be re-allocated and loads will be hoisted out of 38085 loops and be subjected to inter-block scheduling. 38086 38087 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool 38088 AFTER_PROLOGUE_EPILOGUE_GEN) 38089 Branch target register optimization will by default exclude 38090 callee-saved registers that are not already live during the current 38091 function; if this target hook returns true, they will be included. 38092 The target code must than make sure that all target registers in 38093 the class returned by 'TARGET_BRANCH_TARGET_REGISTER_CLASS' that 38094 might need saving are saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates 38095 if prologues and epilogues have already been generated. Note, even 38096 if you only return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, 38097 you still are likely to have to make special provisions in 38098 'INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved 38099 target registers. 38100 38101 -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void) 38102 This target hook returns true if the target supports conditional 38103 execution. This target hook is required only when the target has 38104 several different modes and they have different conditional 38105 execution capability, such as ARM. 38106 38107 -- Target Hook: rtx TARGET_GEN_CCMP_FIRST (rtx *PREP_SEQ, rtx *GEN_SEQ, 38108 int CODE, tree OP0, tree OP1) 38109 This function prepares to emit a comparison insn for the first 38110 compare in a sequence of conditional comparisions. It returns a 38111 appropriate 'CC' for passing to 'gen_ccmp_next' or 'cbranch_optab'. 38112 The insns to prepare the compare are saved in PREP_SEQ and the 38113 compare insns are saved in GEN_SEQ. They will be emitted when all 38114 the compares in the the conditional comparision are generated 38115 without error. CODE is the 'rtx_code' of the compare for OP0 and 38116 OP1. 38117 38118 -- Target Hook: rtx TARGET_GEN_CCMP_NEXT (rtx *PREP_SEQ, rtx *GEN_SEQ, 38119 rtx PREV, int CMP_CODE, tree OP0, tree OP1, int BIT_CODE) 38120 This function prepare to emit a conditional comparison within a 38121 sequence of conditional comparisons. It returns a appropriate 'CC' 38122 for passing to 'gen_ccmp_next' or 'cbranch_optab'. The insns to 38123 prepare the compare are saved in PREP_SEQ and the compare insns are 38124 saved in GEN_SEQ. They will be emitted when all the compares in 38125 the conditional comparision are generated without error. The PREV 38126 expression is the result of a prior call to 'gen_ccmp_first' or 38127 'gen_ccmp_next'. It may return 'NULL' if the combination of PREV 38128 and this comparison is not supported, otherwise the result must be 38129 appropriate for passing to 'gen_ccmp_next' or 'cbranch_optab'. 38130 CODE is the 'rtx_code' of the compare for OP0 and OP1. BIT_CODE is 38131 'AND' or 'IOR', which is the op on the two compares. 38132 38133 -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL, 38134 struct loop *LOOP) 38135 This target hook returns a new value for the number of times LOOP 38136 should be unrolled. The parameter NUNROLL is the number of times 38137 the loop is to be unrolled. The parameter LOOP is a pointer to the 38138 loop, which is going to be checked for unrolling. This target hook 38139 is required only when the target has special constraints like 38140 maximum number of memory accesses. 38141 38142 -- Macro: POWI_MAX_MULTS 38143 If defined, this macro is interpreted as a signed integer C 38144 expression that specifies the maximum number of floating point 38145 multiplications that should be emitted when expanding 38146 exponentiation by an integer constant inline. When this value is 38147 defined, exponentiation requiring more than this number of 38148 multiplications is implemented by calling the system library's 38149 'pow', 'powf' or 'powl' routines. The default value places no 38150 upper bound on the multiplication count. 38151 38152 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 38153 *IPREFIX, int STDINC) 38154 This target hook should register any extra include files for the 38155 target. The parameter STDINC indicates if normal include files are 38156 present. The parameter SYSROOT is the system root directory. The 38157 parameter IPREFIX is the prefix for the gcc directory. 38158 38159 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 38160 char *IPREFIX, int STDINC) 38161 This target hook should register any extra include files for the 38162 target before any standard headers. The parameter STDINC indicates 38163 if normal include files are present. The parameter SYSROOT is the 38164 system root directory. The parameter IPREFIX is the prefix for the 38165 gcc directory. 38166 38167 -- Macro: void TARGET_OPTF (char *PATH) 38168 This target hook should register special include paths for the 38169 target. The parameter PATH is the include to register. On Darwin 38170 systems, this is used for Framework includes, which have semantics 38171 that are different from '-I'. 38172 38173 -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 38174 This target macro returns 'true' if it is safe to use a local alias 38175 for a virtual function FNDECL when constructing thunks, 'false' 38176 otherwise. By default, the macro returns 'true' for all functions, 38177 if a target supports aliases (i.e. defines 'ASM_OUTPUT_DEF'), 38178 'false' otherwise, 38179 38180 -- Macro: TARGET_FORMAT_TYPES 38181 If defined, this macro is the name of a global variable containing 38182 target-specific format checking information for the '-Wformat' 38183 option. The default is to have no target-specific format checks. 38184 38185 -- Macro: TARGET_N_FORMAT_TYPES 38186 If defined, this macro is the number of entries in 38187 'TARGET_FORMAT_TYPES'. 38188 38189 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES 38190 If defined, this macro is the name of a global variable containing 38191 target-specific format overrides for the '-Wformat' option. The 38192 default is to have no target-specific format overrides. If 38193 defined, 'TARGET_FORMAT_TYPES' must be defined, too. 38194 38195 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT 38196 If defined, this macro specifies the number of entries in 38197 'TARGET_OVERRIDES_FORMAT_ATTRIBUTES'. 38198 38199 -- Macro: TARGET_OVERRIDES_FORMAT_INIT 38200 If defined, this macro specifies the optional initialization 38201 routine for target specific customizations of the system printf and 38202 scanf formatter settings. 38203 38204 -- Target Hook: bool TARGET_RELAXED_ORDERING 38205 If set to 'true', means that the target's memory model does not 38206 guarantee that loads which do not depend on one another will access 38207 main memory in the order of the instruction stream; if ordering is 38208 important, an explicit memory barrier must be used. This is true 38209 of many recent processors which implement a policy of "relaxed," 38210 "weak," or "release" memory consistency, such as Alpha, PowerPC, 38211 and ia64. The default is 'false'. 38212 38213 -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 38214 (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL) 38215 If defined, this macro returns the diagnostic message when it is 38216 illegal to pass argument VAL to function FUNCDECL with prototype 38217 TYPELIST. 38218 38219 -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree 38220 FROMTYPE, const_tree TOTYPE) 38221 If defined, this macro returns the diagnostic message when it is 38222 invalid to convert from FROMTYPE to TOTYPE, or 'NULL' if validity 38223 should be determined by the front end. 38224 38225 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, 38226 const_tree TYPE) 38227 If defined, this macro returns the diagnostic message when it is 38228 invalid to apply operation OP (where unary plus is denoted by 38229 'CONVERT_EXPR') to an operand of type TYPE, or 'NULL' if validity 38230 should be determined by the front end. 38231 38232 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, 38233 const_tree TYPE1, const_tree TYPE2) 38234 If defined, this macro returns the diagnostic message when it is 38235 invalid to apply operation OP to operands of types TYPE1 and TYPE2, 38236 or 'NULL' if validity should be determined by the front end. 38237 38238 -- Target Hook: const char * TARGET_INVALID_PARAMETER_TYPE (const_tree 38239 TYPE) 38240 If defined, this macro returns the diagnostic message when it is 38241 invalid for functions to include parameters of type TYPE, or 'NULL' 38242 if validity should be determined by the front end. This is 38243 currently used only by the C and C++ front ends. 38244 38245 -- Target Hook: const char * TARGET_INVALID_RETURN_TYPE (const_tree 38246 TYPE) 38247 If defined, this macro returns the diagnostic message when it is 38248 invalid for functions to have return type TYPE, or 'NULL' if 38249 validity should be determined by the front end. This is currently 38250 used only by the C and C++ front ends. 38251 38252 -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE) 38253 If defined, this target hook returns the type to which values of 38254 TYPE should be promoted when they appear in expressions, analogous 38255 to the integer promotions, or 'NULL_TREE' to use the front end's 38256 normal promotion rules. This hook is useful when there are 38257 target-specific types with special promotion rules. This is 38258 currently used only by the C and C++ front ends. 38259 38260 -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR) 38261 If defined, this hook returns the result of converting EXPR to 38262 TYPE. It should return the converted expression, or 'NULL_TREE' to 38263 apply the front end's normal conversion rules. This hook is useful 38264 when there are target-specific types with special conversion rules. 38265 This is currently used only by the C and C++ front ends. 38266 38267 -- Macro: TARGET_USE_JCR_SECTION 38268 This macro determines whether to use the JCR section to register 38269 Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1 38270 if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true, else 38271 0. 38272 38273 -- Macro: OBJC_JBLEN 38274 This macro determines the size of the objective C jump buffer for 38275 the NeXT runtime. By default, OBJC_JBLEN is defined to an 38276 innocuous value. 38277 38278 -- Macro: LIBGCC2_UNWIND_ATTRIBUTE 38279 Define this macro if any target-specific attributes need to be 38280 attached to the functions in 'libgcc' that provide low-level 38281 support for call stack unwinding. It is used in declarations in 38282 'unwind-generic.h' and the associated definitions of those 38283 functions. 38284 38285 -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void) 38286 Define this macro to update the current function stack boundary if 38287 necessary. 38288 38289 -- Target Hook: rtx TARGET_GET_DRAP_RTX (void) 38290 This hook should return an rtx for Dynamic Realign Argument Pointer 38291 (DRAP) if a different argument pointer register is needed to access 38292 the function's argument list due to stack realignment. Return 38293 'NULL' if no DRAP is needed. 38294 38295 -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void) 38296 When optimization is disabled, this hook indicates whether or not 38297 arguments should be allocated to stack slots. Normally, GCC 38298 allocates stacks slots for arguments when not optimizing in order 38299 to make debugging easier. However, when a function is declared 38300 with '__attribute__((naked))', there is no stack frame, and the 38301 compiler cannot safely move arguments from the registers in which 38302 they are passed to the stack. Therefore, this hook should return 38303 true in general, but false for naked functions. The default 38304 implementation always returns true. 38305 38306 -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR 38307 On some architectures it can take multiple instructions to 38308 synthesize a constant. If there is another constant already in a 38309 register that is close enough in value then it is preferable that 38310 the new constant is computed from this register using immediate 38311 addition or subtraction. We accomplish this through CSE. Besides 38312 the value of the constant we also add a lower and an upper constant 38313 anchor to the available expressions. These are then queried when 38314 encountering new constants. The anchors are computed by rounding 38315 the constant up and down to a multiple of the value of 38316 'TARGET_CONST_ANCHOR'. 'TARGET_CONST_ANCHOR' should be the maximum 38317 positive value accepted by immediate-add plus one. We currently 38318 assume that the value of 'TARGET_CONST_ANCHOR' is a power of 2. 38319 For example, on MIPS, where add-immediate takes a 16-bit signed 38320 value, 'TARGET_CONST_ANCHOR' is set to '0x8000'. The default value 38321 is zero, which disables this optimization. 38322 38323 -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void) 38324 Return the offset bitwise ored into shifted address to get 38325 corresponding Address Sanitizer shadow memory address. NULL if 38326 Address Sanitizer is not supported by the target. 38327 38328 -- Target Hook: unsigned HOST_WIDE_INT TARGET_MEMMODEL_CHECK (unsigned 38329 HOST_WIDE_INT VAL) 38330 Validate target specific memory model mask bits. When NULL no 38331 target specific memory model bits are allowed. 38332 38333 -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 38334 This value should be set if the result written by 38335 'atomic_test_and_set' is not exactly 1, i.e. the 'bool' 'true'. 38336 38337 -- Target Hook: bool TARGET_HAS_IFUNC_P (void) 38338 It returns true if the target supports GNU indirect functions. The 38339 support includes the assembler, linker and dynamic linker. The 38340 default value of this hook is based on target's libc. 38341 38342 -- Target Hook: unsigned int TARGET_ATOMIC_ALIGN_FOR_MODE (machine_mode 38343 MODE) 38344 If defined, this function returns an appropriate alignment in bits 38345 for an atomic object of machine_mode MODE. If 0 is returned then 38346 the default alignment for the specified mode is used. 38347 38348 -- Target Hook: void TARGET_ATOMIC_ASSIGN_EXPAND_FENV (tree *HOLD, tree 38349 *CLEAR, tree *UPDATE) 38350 ISO C11 requires atomic compound assignments that may raise 38351 floating-point exceptions to raise exceptions corresponding to the 38352 arithmetic operation whose result was successfully stored in a 38353 compare-and-exchange sequence. This requires code equivalent to 38354 calls to 'feholdexcept', 'feclearexcept' and 'feupdateenv' to be 38355 generated at appropriate points in the compare-and-exchange 38356 sequence. This hook should set '*HOLD' to an expression equivalent 38357 to the call to 'feholdexcept', '*CLEAR' to an expression equivalent 38358 to the call to 'feclearexcept' and '*UPDATE' to an expression 38359 equivalent to the call to 'feupdateenv'. The three expressions are 38360 'NULL_TREE' on entry to the hook and may be left as 'NULL_TREE' if 38361 no code is required in a particular place. The default 38362 implementation leaves all three expressions as 'NULL_TREE'. The 38363 '__atomic_feraiseexcept' function from 'libatomic' may be of use as 38364 part of the code generated in '*UPDATE'. 38365 38366 -- Target Hook: void TARGET_RECORD_OFFLOAD_SYMBOL (tree) 38367 Used when offloaded functions are seen in the compilation unit and 38368 no named sections are available. It is called once for each symbol 38369 that must be recorded in the offload function and variable table. 38370 38371 -- Target Hook: char * TARGET_OFFLOAD_OPTIONS (void) 38372 Used when writing out the list of options into an LTO file. It 38373 should translate any relevant target-specific options (such as the 38374 ABI in use) into one of the '-foffload' options that exist as a 38375 common interface to express such options. It should return a 38376 string containing these options, separated by spaces, which the 38377 caller will free. 38378 38379 -- Macro: TARGET_SUPPORTS_WIDE_INT 38380 38381 On older ports, large integers are stored in 'CONST_DOUBLE' rtl 38382 objects. Newer ports define 'TARGET_SUPPORTS_WIDE_INT' to be 38383 nonzero to indicate that large integers are stored in 38384 'CONST_WIDE_INT' rtl objects. The 'CONST_WIDE_INT' allows very 38385 large integer constants to be represented. 'CONST_DOUBLE' is 38386 limited to twice the size of the host's 'HOST_WIDE_INT' 38387 representation. 38388 38389 Converting a port mostly requires looking for the places where 38390 'CONST_DOUBLE's are used with 'VOIDmode' and replacing that code 38391 with code that accesses 'CONST_WIDE_INT's. '"grep -i 38392 const_double"' at the port level gets you to 95% of the changes 38393 that need to be made. There are a few places that require a deeper 38394 look. 38395 38396 * There is no equivalent to 'hval' and 'lval' for 38397 'CONST_WIDE_INT's. This would be difficult to express in the 38398 md language since there are a variable number of elements. 38399 38400 Most ports only check that 'hval' is either 0 or -1 to see if 38401 the value is small. As mentioned above, this will no longer 38402 be necessary since small constants are always 'CONST_INT'. Of 38403 course there are still a few exceptions, the alpha's 38404 constraint used by the zap instruction certainly requires 38405 careful examination by C code. However, all the current code 38406 does is pass the hval and lval to C code, so evolving the c 38407 code to look at the 'CONST_WIDE_INT' is not really a large 38408 change. 38409 38410 * Because there is no standard template that ports use to 38411 materialize constants, there is likely to be some futzing that 38412 is unique to each port in this code. 38413 38414 * The rtx costs may have to be adjusted to properly account for 38415 larger constants that are represented as 'CONST_WIDE_INT'. 38416 38417 All and all it does not take long to convert ports that the 38418 maintainer is familiar with. 38419 38420 38421File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 38422 3842318 Host Configuration 38424********************* 38425 38426Most details about the machine and system on which the compiler is 38427actually running are detected by the 'configure' script. Some things 38428are impossible for 'configure' to detect; these are described in two 38429ways, either by macros defined in a file named 'xm-MACHINE.h' or by hook 38430functions in the file specified by the OUT_HOST_HOOK_OBJ variable in 38431'config.gcc'. (The intention is that very few hosts will need a header 38432file but nearly every fully supported host will need to override some 38433hooks.) 38434 38435 If you need to define only a few macros, and they have simple 38436definitions, consider using the 'xm_defines' variable in your 38437'config.gcc' entry instead of creating a host configuration header. 38438*Note System Config::. 38439 38440* Menu: 38441 38442* Host Common:: Things every host probably needs implemented. 38443* Filesystem:: Your host can't have the letter 'a' in filenames? 38444* Host Misc:: Rare configuration options for hosts. 38445 38446 38447File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 38448 3844918.1 Host Common 38450================ 38451 38452Some things are just not portable, even between similar operating 38453systems, and are too difficult for autoconf to detect. They get 38454implemented using hook functions in the file specified by the 38455HOST_HOOK_OBJ variable in 'config.gcc'. 38456 38457 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 38458 This host hook is used to set up handling for extra signals. The 38459 most common thing to do in this hook is to detect stack overflow. 38460 38461 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 38462 FD) 38463 This host hook returns the address of some space that is likely to 38464 be free in some subsequent invocation of the compiler. We intend 38465 to load the PCH data at this address such that the data need not be 38466 relocated. The area should be able to hold SIZE bytes. If the 38467 host uses 'mmap', FD is an open file descriptor that can be used 38468 for probing. 38469 38470 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, size_t 38471 SIZE, int FD, size_t OFFSET) 38472 This host hook is called when a PCH file is about to be loaded. We 38473 want to load SIZE bytes from FD at OFFSET into memory at ADDRESS. 38474 The given address will be the result of a previous invocation of 38475 'HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we couldn't allocate 38476 SIZE bytes at ADDRESS. Return 0 if the memory is allocated but the 38477 data is not loaded. Return 1 if the hook has performed everything. 38478 38479 If the implementation uses reserved address space, free any 38480 reserved space beyond SIZE, regardless of the return value. If no 38481 PCH will be loaded, this hook may be called with SIZE zero, in 38482 which case all reserved address space should be freed. 38483 38484 Do not try to handle values of ADDRESS that could not have been 38485 returned by this executable; just return -1. Such values usually 38486 indicate an out-of-date PCH file (built by some other GCC 38487 executable), and such a PCH file won't work. 38488 38489 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 38490 This host hook returns the alignment required for allocating 38491 virtual memory. Usually this is the same as getpagesize, but on 38492 some hosts the alignment for reserving memory differs from the 38493 pagesize for committing memory. 38494 38495 38496File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 38497 3849818.2 Host Filesystem 38499==================== 38500 38501GCC needs to know a number of things about the semantics of the host 38502machine's filesystem. Filesystems with Unix and MS-DOS semantics are 38503automatically detected. For other systems, you can define the following 38504macros in 'xm-MACHINE.h'. 38505 38506'HAVE_DOS_BASED_FILE_SYSTEM' 38507 This macro is automatically defined by 'system.h' if the host file 38508 system obeys the semantics defined by MS-DOS instead of Unix. DOS 38509 file systems are case insensitive, file specifications may begin 38510 with a drive letter, and both forward slash and backslash ('/' and 38511 '\') are directory separators. 38512 38513'DIR_SEPARATOR' 38514'DIR_SEPARATOR_2' 38515 If defined, these macros expand to character constants specifying 38516 separators for directory names within a file specification. 38517 'system.h' will automatically give them appropriate values on Unix 38518 and MS-DOS file systems. If your file system is neither of these, 38519 define one or both appropriately in 'xm-MACHINE.h'. 38520 38521 However, operating systems like VMS, where constructing a pathname 38522 is more complicated than just stringing together directory names 38523 separated by a special character, should not define either of these 38524 macros. 38525 38526'PATH_SEPARATOR' 38527 If defined, this macro should expand to a character constant 38528 specifying the separator for elements of search paths. The default 38529 value is a colon (':'). DOS-based systems usually, but not always, 38530 use semicolon (';'). 38531 38532'VMS' 38533 Define this macro if the host system is VMS. 38534 38535'HOST_OBJECT_SUFFIX' 38536 Define this macro to be a C string representing the suffix for 38537 object files on your host machine. If you do not define this 38538 macro, GCC will use '.o' as the suffix for object files. 38539 38540'HOST_EXECUTABLE_SUFFIX' 38541 Define this macro to be a C string representing the suffix for 38542 executable files on your host machine. If you do not define this 38543 macro, GCC will use the null string as the suffix for executable 38544 files. 38545 38546'HOST_BIT_BUCKET' 38547 A pathname defined by the host operating system, which can be 38548 opened as a file and written to, but all the information written is 38549 discarded. This is commonly known as a "bit bucket" or "null 38550 device". If you do not define this macro, GCC will use '/dev/null' 38551 as the bit bucket. If the host does not support a bit bucket, 38552 define this macro to an invalid filename. 38553 38554'UPDATE_PATH_HOST_CANONICALIZE (PATH)' 38555 If defined, a C statement (sans semicolon) that performs 38556 host-dependent canonicalization when a path used in a compilation 38557 driver or preprocessor is canonicalized. PATH is a malloc-ed path 38558 to be canonicalized. If the C statement does canonicalize PATH 38559 into a different buffer, the old path should be freed and the new 38560 buffer should have been allocated with malloc. 38561 38562'DUMPFILE_FORMAT' 38563 Define this macro to be a C string representing the format to use 38564 for constructing the index part of debugging dump file names. The 38565 resultant string must fit in fifteen bytes. The full filename will 38566 be the concatenation of: the prefix of the assembler file name, the 38567 string resulting from applying this format to an index number, and 38568 a string unique to each dump file kind, e.g. 'rtl'. 38569 38570 If you do not define this macro, GCC will use '.%02d.'. You should 38571 define this macro if using the default will create an invalid file 38572 name. 38573 38574'DELETE_IF_ORDINARY' 38575 Define this macro to be a C statement (sans semicolon) that 38576 performs host-dependent removal of ordinary temp files in the 38577 compilation driver. 38578 38579 If you do not define this macro, GCC will use the default version. 38580 You should define this macro if the default version does not 38581 reliably remove the temp file as, for example, on VMS which allows 38582 multiple versions of a file. 38583 38584'HOST_LACKS_INODE_NUMBERS' 38585 Define this macro if the host filesystem does not report meaningful 38586 inode numbers in struct stat. 38587 38588 38589File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 38590 3859118.3 Host Misc 38592============== 38593 38594'FATAL_EXIT_CODE' 38595 A C expression for the status code to be returned when the compiler 38596 exits after serious errors. The default is the system-provided 38597 macro 'EXIT_FAILURE', or '1' if the system doesn't define that 38598 macro. Define this macro only if these defaults are incorrect. 38599 38600'SUCCESS_EXIT_CODE' 38601 A C expression for the status code to be returned when the compiler 38602 exits without serious errors. (Warnings are not serious errors.) 38603 The default is the system-provided macro 'EXIT_SUCCESS', or '0' if 38604 the system doesn't define that macro. Define this macro only if 38605 these defaults are incorrect. 38606 38607'USE_C_ALLOCA' 38608 Define this macro if GCC should use the C implementation of 38609 'alloca' provided by 'libiberty.a'. This only affects how some 38610 parts of the compiler itself allocate memory. It does not change 38611 code generation. 38612 38613 When GCC is built with a compiler other than itself, the C 'alloca' 38614 is always used. This is because most other implementations have 38615 serious bugs. You should define this macro only on a system where 38616 no stack-based 'alloca' can possibly work. For instance, if a 38617 system has a small limit on the size of the stack, GCC's builtin 38618 'alloca' will not work reliably. 38619 38620'COLLECT2_HOST_INITIALIZATION' 38621 If defined, a C statement (sans semicolon) that performs 38622 host-dependent initialization when 'collect2' is being initialized. 38623 38624'GCC_DRIVER_HOST_INITIALIZATION' 38625 If defined, a C statement (sans semicolon) that performs 38626 host-dependent initialization when a compilation driver is being 38627 initialized. 38628 38629'HOST_LONG_LONG_FORMAT' 38630 If defined, the string used to indicate an argument of type 'long 38631 long' to functions like 'printf'. The default value is '"ll"'. 38632 38633'HOST_LONG_FORMAT' 38634 If defined, the string used to indicate an argument of type 'long' 38635 to functions like 'printf'. The default value is '"l"'. 38636 38637'HOST_PTR_PRINTF' 38638 If defined, the string used to indicate an argument of type 'void 38639 *' to functions like 'printf'. The default value is '"%p"'. 38640 38641 In addition, if 'configure' generates an incorrect definition of any of 38642the macros in 'auto-host.h', you can override that definition in a host 38643configuration header. If you need to do this, first see if it is 38644possible to fix 'configure'. 38645 38646 38647File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 38648 3864919 Makefile Fragments 38650********************* 38651 38652When you configure GCC using the 'configure' script, it will construct 38653the file 'Makefile' from the template file 'Makefile.in'. When it does 38654this, it can incorporate makefile fragments from the 'config' directory. 38655These are used to set Makefile parameters that are not amenable to being 38656calculated by autoconf. The list of fragments to incorporate is set by 38657'config.gcc' (and occasionally 'config.build' and 'config.host'); *Note 38658System Config::. 38659 38660 Fragments are named either 't-TARGET' or 'x-HOST', depending on whether 38661they are relevant to configuring GCC to produce code for a particular 38662target, or to configuring GCC to run on a particular host. Here TARGET 38663and HOST are mnemonics which usually have some relationship to the 38664canonical system name, but no formal connection. 38665 38666 If these files do not exist, it means nothing needs to be added for a 38667given target or host. Most targets need a few 't-TARGET' fragments, but 38668needing 'x-HOST' fragments is rare. 38669 38670* Menu: 38671 38672* Target Fragment:: Writing 't-TARGET' files. 38673* Host Fragment:: Writing 'x-HOST' files. 38674 38675 38676File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 38677 3867819.1 Target Makefile Fragments 38679============================== 38680 38681Target makefile fragments can set these Makefile variables. 38682 38683'LIBGCC2_CFLAGS' 38684 Compiler flags to use when compiling 'libgcc2.c'. 38685 38686'LIB2FUNCS_EXTRA' 38687 A list of source file names to be compiled or assembled and 38688 inserted into 'libgcc.a'. 38689 38690'CRTSTUFF_T_CFLAGS' 38691 Special flags used when compiling 'crtstuff.c'. *Note 38692 Initialization::. 38693 38694'CRTSTUFF_T_CFLAGS_S' 38695 Special flags used when compiling 'crtstuff.c' for shared linking. 38696 Used if you use 'crtbeginS.o' and 'crtendS.o' in 'EXTRA-PARTS'. 38697 *Note Initialization::. 38698 38699'MULTILIB_OPTIONS' 38700 For some targets, invoking GCC in different ways produces objects 38701 that can not be linked together. For example, for some targets GCC 38702 produces both big and little endian code. For these targets, you 38703 must arrange for multiple versions of 'libgcc.a' to be compiled, 38704 one for each set of incompatible options. When GCC invokes the 38705 linker, it arranges to link in the right version of 'libgcc.a', 38706 based on the command line options used. 38707 38708 The 'MULTILIB_OPTIONS' macro lists the set of options for which 38709 special versions of 'libgcc.a' must be built. Write options that 38710 are mutually incompatible side by side, separated by a slash. 38711 Write options that may be used together separated by a space. The 38712 build procedure will build all combinations of compatible options. 38713 38714 For example, if you set 'MULTILIB_OPTIONS' to 'm68000/m68020 38715 msoft-float', 'Makefile' will build special versions of 'libgcc.a' 38716 using the following sets of options: '-m68000', '-m68020', 38717 '-msoft-float', '-m68000 -msoft-float', and '-m68020 -msoft-float'. 38718 38719'MULTILIB_DIRNAMES' 38720 If 'MULTILIB_OPTIONS' is used, this variable specifies the 38721 directory names that should be used to hold the various libraries. 38722 Write one element in 'MULTILIB_DIRNAMES' for each element in 38723 'MULTILIB_OPTIONS'. If 'MULTILIB_DIRNAMES' is not used, the 38724 default value will be 'MULTILIB_OPTIONS', with all slashes treated 38725 as spaces. 38726 38727 'MULTILIB_DIRNAMES' describes the multilib directories using GCC 38728 conventions and is applied to directories that are part of the GCC 38729 installation. When multilib-enabled, the compiler will add a 38730 subdirectory of the form PREFIX/MULTILIB before each directory in 38731 the search path for libraries and crt files. 38732 38733 For example, if 'MULTILIB_OPTIONS' is set to 'm68000/m68020 38734 msoft-float', then the default value of 'MULTILIB_DIRNAMES' is 38735 'm68000 m68020 msoft-float'. You may specify a different value if 38736 you desire a different set of directory names. 38737 38738'MULTILIB_MATCHES' 38739 Sometimes the same option may be written in two different ways. If 38740 an option is listed in 'MULTILIB_OPTIONS', GCC needs to know about 38741 any synonyms. In that case, set 'MULTILIB_MATCHES' to a list of 38742 items of the form 'option=option' to describe all relevant 38743 synonyms. For example, 'm68000=mc68000 m68020=mc68020'. 38744 38745'MULTILIB_EXCEPTIONS' 38746 Sometimes when there are multiple sets of 'MULTILIB_OPTIONS' being 38747 specified, there are combinations that should not be built. In 38748 that case, set 'MULTILIB_EXCEPTIONS' to be all of the switch 38749 exceptions in shell case syntax that should not be built. 38750 38751 For example the ARM processor cannot execute both hardware floating 38752 point instructions and the reduced size THUMB instructions at the 38753 same time, so there is no need to build libraries with both of 38754 these options enabled. Therefore 'MULTILIB_EXCEPTIONS' is set to: 38755 *mthumb/*mhard-float* 38756 38757'MULTILIB_REQUIRED' 38758 Sometimes when there are only a few combinations are required, it 38759 would be a big effort to come up with a 'MULTILIB_EXCEPTIONS' list 38760 to cover all undesired ones. In such a case, just listing all the 38761 required combinations in 'MULTILIB_REQUIRED' would be more 38762 straightforward. 38763 38764 The way to specify the entries in 'MULTILIB_REQUIRED' is same with 38765 the way used for 'MULTILIB_EXCEPTIONS', only this time what are 38766 required will be specified. Suppose there are multiple sets of 38767 'MULTILIB_OPTIONS' and only two combinations are required, one for 38768 ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU, 38769 the 'MULTILIB_REQUIRED' can be set to: 38770 MULTILIB_REQUIRED = mthumb/march=armv7-m 38771 MULTILIB_REQUIRED += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16 38772 38773 The 'MULTILIB_REQUIRED' can be used together with 38774 'MULTILIB_EXCEPTIONS'. The option combinations generated from 38775 'MULTILIB_OPTIONS' will be filtered by 'MULTILIB_EXCEPTIONS' and 38776 then by 'MULTILIB_REQUIRED'. 38777 38778'MULTILIB_REUSE' 38779 Sometimes it is desirable to reuse one existing multilib for 38780 different sets of options. Such kind of reuse can minimize the 38781 number of multilib variants. And for some targets it is better to 38782 reuse an existing multilib than to fall back to default multilib 38783 when there is no corresponding multilib. This can be done by 38784 adding reuse rules to 'MULTILIB_REUSE'. 38785 38786 A reuse rule is comprised of two parts connected by equality sign. 38787 The left part is option set used to build multilib and the right 38788 part is option set that will reuse this multilib. The order of 38789 options in the left part matters and should be same with those 38790 specified in 'MULTILIB_REQUIRED' or aligned with order in 38791 'MULTILIB_OPTIONS'. There is no such limitation for options in 38792 right part as we don't build multilib from them. But the equality 38793 sign in both parts should be replaced with period. 38794 38795 The 'MULTILIB_REUSE' is different from 'MULTILIB_MATCHES' in that 38796 it sets up relations between two option sets rather than two 38797 options. Here is an example to demo how we reuse libraries built 38798 in Thumb mode for applications built in ARM mode: 38799 MULTILIB_REUSE = mthumb/march.armv7-r=marm/march.armv7-r 38800 38801 Before the advent of 'MULTILIB_REUSE', GCC select multilib by 38802 comparing command line options with options used to build multilib. 38803 The 'MULTILIB_REUSE' is complementary to that way. Only when the 38804 original comparison matches nothing it will work to see if it is OK 38805 to reuse some existing multilib. 38806 38807'MULTILIB_EXTRA_OPTS' 38808 Sometimes it is desirable that when building multiple versions of 38809 'libgcc.a' certain options should always be passed on to the 38810 compiler. In that case, set 'MULTILIB_EXTRA_OPTS' to be the list 38811 of options to be used for all builds. If you set this, you should 38812 probably set 'CRTSTUFF_T_CFLAGS' to a dash followed by it. 38813 38814'MULTILIB_OSDIRNAMES' 38815 If 'MULTILIB_OPTIONS' is used, this variable specifies a list of 38816 subdirectory names, that are used to modify the search path 38817 depending on the chosen multilib. Unlike 'MULTILIB_DIRNAMES', 38818 'MULTILIB_OSDIRNAMES' describes the multilib directories using 38819 operating systems conventions, and is applied to the directories 38820 such as 'lib' or those in the 'LIBRARY_PATH' environment variable. 38821 The format is either the same as of 'MULTILIB_DIRNAMES', or a set 38822 of mappings. When it is the same as 'MULTILIB_DIRNAMES', it 38823 describes the multilib directories using operating system 38824 conventions, rather than GCC conventions. When it is a set of 38825 mappings of the form GCCDIR=OSDIR, the left side gives the GCC 38826 convention and the right gives the equivalent OS defined location. 38827 If the OSDIR part begins with a '!', GCC will not search in the 38828 non-multilib directory and use exclusively the multilib directory. 38829 Otherwise, the compiler will examine the search path for libraries 38830 and crt files twice; the first time it will add MULTILIB to each 38831 directory in the search path, the second it will not. 38832 38833 For configurations that support both multilib and multiarch, 38834 'MULTILIB_OSDIRNAMES' also encodes the multiarch name, thus 38835 subsuming 'MULTIARCH_DIRNAME'. The multiarch name is appended to 38836 each directory name, separated by a colon (e.g. 38837 '../lib32:i386-linux-gnu'). 38838 38839 Each multiarch subdirectory will be searched before the 38840 corresponding OS multilib directory, for example 38841 '/lib/i386-linux-gnu' before '/lib/../lib32'. The multiarch name 38842 will also be used to modify the system header search path, as 38843 explained for 'MULTIARCH_DIRNAME'. 38844 38845'MULTIARCH_DIRNAME' 38846 This variable specifies the multiarch name for configurations that 38847 are multiarch-enabled but not multilibbed configurations. 38848 38849 The multiarch name is used to augment the search path for 38850 libraries, crt files and system header files with additional 38851 locations. The compiler will add a multiarch subdirectory of the 38852 form PREFIX/MULTIARCH before each directory in the library and crt 38853 search path. It will also add two directories 38854 'LOCAL_INCLUDE_DIR'/MULTIARCH and 38855 'NATIVE_SYSTEM_HEADER_DIR'/MULTIARCH) to the system header search 38856 path, respectively before 'LOCAL_INCLUDE_DIR' and 38857 'NATIVE_SYSTEM_HEADER_DIR'. 38858 38859 'MULTIARCH_DIRNAME' is not used for configurations that support 38860 both multilib and multiarch. In that case, multiarch names are 38861 encoded in 'MULTILIB_OSDIRNAMES' instead. 38862 38863 More documentation about multiarch can be found at 38864 <http://wiki.debian.org/Multiarch>. 38865 38866'SPECS' 38867 Unfortunately, setting 'MULTILIB_EXTRA_OPTS' is not enough, since 38868 it does not affect the build of target libraries, at least not the 38869 build of the default multilib. One possible work-around is to use 38870 'DRIVER_SELF_SPECS' to bring options from the 'specs' file as if 38871 they had been passed in the compiler driver command line. However, 38872 you don't want to be adding these options after the toolchain is 38873 installed, so you can instead tweak the 'specs' file that will be 38874 used during the toolchain build, while you still install the 38875 original, built-in 'specs'. The trick is to set 'SPECS' to some 38876 other filename (say 'specs.install'), that will then be created out 38877 of the built-in specs, and introduce a 'Makefile' rule to generate 38878 the 'specs' file that's going to be used at build time out of your 38879 'specs.install'. 38880 38881'T_CFLAGS' 38882 These are extra flags to pass to the C compiler. They are used 38883 both when building GCC, and when compiling things with the 38884 just-built GCC. This variable is deprecated and should not be 38885 used. 38886 38887 38888File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 38889 3889019.2 Host Makefile Fragments 38891============================ 38892 38893The use of 'x-HOST' fragments is discouraged. You should only use it 38894for makefile dependencies. 38895 38896 38897File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 38898 3889920 'collect2' 38900************* 38901 38902GCC uses a utility called 'collect2' on nearly all systems to arrange to 38903call various initialization functions at start time. 38904 38905 The program 'collect2' works by linking the program once and looking 38906through the linker output file for symbols with particular names 38907indicating they are constructor functions. If it finds any, it creates 38908a new temporary '.c' file containing a table of them, compiles it, and 38909links the program a second time including that file. 38910 38911 The actual calls to the constructors are carried out by a subroutine 38912called '__main', which is called (automatically) at the beginning of the 38913body of 'main' (provided 'main' was compiled with GNU CC). Calling 38914'__main' is necessary, even when compiling C code, to allow linking C 38915and C++ object code together. (If you use '-nostdlib', you get an 38916unresolved reference to '__main', since it's defined in the standard GCC 38917library. Include '-lgcc' at the end of your compiler command line to 38918resolve this reference.) 38919 38920 The program 'collect2' is installed as 'ld' in the directory where the 38921passes of the compiler are installed. When 'collect2' needs to find the 38922_real_ 'ld', it tries the following file names: 38923 38924 * a hard coded linker file name, if GCC was configured with the 38925 '--with-ld' option. 38926 38927 * 'real-ld' in the directories listed in the compiler's search 38928 directories. 38929 38930 * 'real-ld' in the directories listed in the environment variable 38931 'PATH'. 38932 38933 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 38934 if specified. 38935 38936 * 'ld' in the compiler's search directories, except that 'collect2' 38937 will not execute itself recursively. 38938 38939 * 'ld' in 'PATH'. 38940 38941 "The compiler's search directories" means all the directories where 38942'gcc' searches for passes of the compiler. This includes directories 38943that you specify with '-B'. 38944 38945 Cross-compilers search a little differently: 38946 38947 * 'real-ld' in the compiler's search directories. 38948 38949 * 'TARGET-real-ld' in 'PATH'. 38950 38951 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 38952 if specified. 38953 38954 * 'ld' in the compiler's search directories. 38955 38956 * 'TARGET-ld' in 'PATH'. 38957 38958 'collect2' explicitly avoids running 'ld' using the file name under 38959which 'collect2' itself was invoked. In fact, it remembers up a list of 38960such names--in case one copy of 'collect2' finds another copy (or 38961version) of 'collect2' installed as 'ld' in a second place in the search 38962path. 38963 38964 'collect2' searches for the utilities 'nm' and 'strip' using the same 38965algorithm as above for 'ld'. 38966 38967 38968File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 38969 3897021 Standard Header File Directories 38971*********************************** 38972 38973'GCC_INCLUDE_DIR' means the same thing for native and cross. It is 38974where GCC stores its private include files, and also where GCC stores 38975the fixed include files. A cross compiled GCC runs 'fixincludes' on the 38976header files in '$(tooldir)/include'. (If the cross compilation header 38977files need to be fixed, they must be installed before GCC is built. If 38978the cross compilation header files are already suitable for GCC, nothing 38979special need be done). 38980 38981 'GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 38982is where 'g++' looks first for header files. The C++ library installs 38983only target independent header files in that directory. 38984 38985 'LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 38986install anything there. It is normally '/usr/local/include'. This is 38987where local additions to a packaged system should place header files. 38988 38989 'CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 38990install anything there. 38991 38992 'TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 38993the place for other packages to install header files that GCC will use. 38994For a cross-compiler, this is the equivalent of '/usr/include'. When 38995you build a cross-compiler, 'fixincludes' processes any header files in 38996this directory. 38997 38998 38999File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top 39000 3900122 Memory Management and Type Information 39002***************************************** 39003 39004GCC uses some fairly sophisticated memory management techniques, which 39005involve determining information about GCC's data structures from GCC's 39006source code and using this information to perform garbage collection and 39007implement precompiled headers. 39008 39009 A full C++ parser would be too complicated for this task, so a limited 39010subset of C++ is interpreted and special markers are used to determine 39011what parts of the source to look at. All 'struct', 'union' and 39012'template' structure declarations that define data structures that are 39013allocated under control of the garbage collector must be marked. All 39014global variables that hold pointers to garbage-collected memory must 39015also be marked. Finally, all global variables that need to be saved and 39016restored by a precompiled header must be marked. (The precompiled 39017header mechanism can only save static variables if they're scalar. 39018Complex data structures must be allocated in garbage-collected memory to 39019be saved in a precompiled header.) 39020 39021 The full format of a marker is 39022 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 39023but in most cases no options are needed. The outer double parentheses 39024are still necessary, though: 'GTY(())'. Markers can appear: 39025 39026 * In a structure definition, before the open brace; 39027 * In a global variable declaration, after the keyword 'static' or 39028 'extern'; and 39029 * In a structure field definition, before the name of the field. 39030 39031 Here are some examples of marking simple data structures and globals. 39032 39033 struct GTY(()) TAG 39034 { 39035 FIELDS... 39036 }; 39037 39038 typedef struct GTY(()) TAG 39039 { 39040 FIELDS... 39041 } *TYPENAME; 39042 39043 static GTY(()) struct TAG *LIST; /* points to GC memory */ 39044 static GTY(()) int COUNTER; /* save counter in a PCH */ 39045 39046 The parser understands simple typedefs such as 'typedef struct TAG 39047*NAME;' and 'typedef int NAME;'. These don't need to be marked. 39048 39049 Since 'gengtype''s understanding of C++ is limited, there are several 39050constructs and declarations that are not supported inside 39051classes/structures marked for automatic GC code generation. The 39052following C++ constructs produce a 'gengtype' error on 39053structures/classes marked for automatic GC code generation: 39054 39055 * Type definitions inside classes/structures are not supported. 39056 * Enumerations inside classes/structures are not supported. 39057 39058 If you have a class or structure using any of the above constructs, you 39059need to mark that class as 'GTY ((user))' and provide your own marking 39060routines (see section *note User GC:: for details). 39061 39062 It is always valid to include function definitions inside classes. 39063Those are always ignored by 'gengtype', as it only cares about data 39064members. 39065 39066* Menu: 39067 39068* GTY Options:: What goes inside a 'GTY(())'. 39069* Inheritance and GTY:: Adding GTY to a class hierarchy. 39070* User GC:: Adding user-provided GC marking routines. 39071* GGC Roots:: Making global variables GGC roots. 39072* Files:: How the generated files work. 39073* Invoking the garbage collector:: How to invoke the garbage collector. 39074* Troubleshooting:: When something does not work as expected. 39075 39076 39077File: gccint.info, Node: GTY Options, Next: Inheritance and GTY, Up: Type Information 39078 3907922.1 The Inside of a 'GTY(())' 39080============================== 39081 39082Sometimes the C code is not enough to fully describe the type structure. 39083Extra information can be provided with 'GTY' options and additional 39084markers. Some options take a parameter, which may be either a string or 39085a type name, depending on the parameter. If an option takes no 39086parameter, it is acceptable either to omit the parameter entirely, or to 39087provide an empty string as a parameter. For example, 'GTY ((skip))' and 39088'GTY ((skip ("")))' are equivalent. 39089 39090 When the parameter is a string, often it is a fragment of C code. Four 39091special escapes may be used in these strings, to refer to pieces of the 39092data structure being marked: 39093 39094'%h' 39095 The current structure. 39096'%1' 39097 The structure that immediately contains the current structure. 39098'%0' 39099 The outermost structure that contains the current structure. 39100'%a' 39101 A partial expression of the form '[i1][i2]...' that indexes the 39102 array item currently being marked. 39103 39104 For instance, suppose that you have a structure of the form 39105 struct A { 39106 ... 39107 }; 39108 struct B { 39109 struct A foo[12]; 39110 }; 39111and 'b' is a variable of type 'struct B'. When marking 'b.foo[11]', 39112'%h' would expand to 'b.foo[11]', '%0' and '%1' would both expand to 39113'b', and '%a' would expand to '[11]'. 39114 39115 As in ordinary C, adjacent strings will be concatenated; this is 39116helpful when you have a complicated expression. 39117 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 39118 " ? TYPE_NEXT_VARIANT (&%h.generic)" 39119 " : TREE_CHAIN (&%h.generic)"))) 39120 39121 The available options are: 39122 39123'length ("EXPRESSION")' 39124 39125 There are two places the type machinery will need to be explicitly 39126 told the length of an array of non-atomic objects. The first case 39127 is when a structure ends in a variable-length array, like this: 39128 struct GTY(()) rtvec_def { 39129 int num_elem; /* number of elements */ 39130 rtx GTY ((length ("%h.num_elem"))) elem[1]; 39131 }; 39132 39133 In this case, the 'length' option is used to override the specified 39134 array length (which should usually be '1'). The parameter of the 39135 option is a fragment of C code that calculates the length. 39136 39137 The second case is when a structure or a global variable contains a 39138 pointer to an array, like this: 39139 struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter; 39140 In this case, 'iter' has been allocated by writing something like 39141 x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse); 39142 and the 'collapse' provides the length of the field. 39143 39144 This second use of 'length' also works on global variables, like: 39145 static GTY((length("reg_known_value_size"))) rtx *reg_known_value; 39146 39147 Note that the 'length' option is only meant for use with arrays of 39148 non-atomic objects, that is, objects that contain pointers pointing 39149 to other GTY-managed objects. For other GC-allocated arrays and 39150 strings you should use 'atomic'. 39151 39152'skip' 39153 39154 If 'skip' is applied to a field, the type machinery will ignore it. 39155 This is somewhat dangerous; the only safe use is in a union when 39156 one field really isn't ever used. 39157 39158 Use this to mark types that need to be marked by user gc routines, 39159 but are not refered to in a template argument. So if you have some 39160 user gc type T1 and a non user gc type T2 you can give T2 the 39161 for_user option so that the marking functions for T1 can call non 39162 mangled functions to mark T2. 39163 39164'desc ("EXPRESSION")' 39165'tag ("CONSTANT")' 39166'default' 39167 39168 The type machinery needs to be told which field of a 'union' is 39169 currently active. This is done by giving each field a constant 39170 'tag' value, and then specifying a discriminator using 'desc'. The 39171 value of the expression given by 'desc' is compared against each 39172 'tag' value, each of which should be different. If no 'tag' is 39173 matched, the field marked with 'default' is used if there is one, 39174 otherwise no field in the union will be marked. 39175 39176 In the 'desc' option, the "current structure" is the union that it 39177 discriminates. Use '%1' to mean the structure containing it. 39178 There are no escapes available to the 'tag' option, since it is a 39179 constant. 39180 39181 For example, 39182 struct GTY(()) tree_binding 39183 { 39184 struct tree_common common; 39185 union tree_binding_u { 39186 tree GTY ((tag ("0"))) scope; 39187 struct cp_binding_level * GTY ((tag ("1"))) level; 39188 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 39189 tree value; 39190 }; 39191 39192 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 39193 'struct tree_binding *' is presumed to be 0 or 1. If 1, the type 39194 mechanism will treat the field 'level' as being present and if 0, 39195 will treat the field 'scope' as being present. 39196 39197 The 'desc' and 'tag' options can also be used for inheritance to 39198 denote which subclass an instance is. See *note Inheritance and 39199 GTY:: for more information. 39200 39201'cache' 39202 39203 When the 'cache' option is applied to a global variable 39204 gt_clear_cache is called on that variable between the mark and 39205 sweep phases of garbage collection. The gt_clear_cache function is 39206 free to mark blocks as used, or to clear pointers in the variable. 39207 39208'deletable' 39209 39210 'deletable', when applied to a global variable, indicates that when 39211 garbage collection runs, there's no need to mark anything pointed 39212 to by this variable, it can just be set to 'NULL' instead. This is 39213 used to keep a list of free structures around for re-use. 39214 39215'mark_hook ("HOOK-ROUTINE-NAME")' 39216 39217 If provided for a structure or union type, the given 39218 HOOK-ROUTINE-NAME (between double-quotes) is the name of a routine 39219 called when the garbage collector has just marked the data as 39220 reachable. This routine should not change the data, or call any 39221 ggc routine. Its only argument is a pointer to the just marked 39222 (const) structure or union. 39223 39224'maybe_undef' 39225 39226 When applied to a field, 'maybe_undef' indicates that it's OK if 39227 the structure that this fields points to is never defined, so long 39228 as this field is always 'NULL'. This is used to avoid requiring 39229 backends to define certain optional structures. It doesn't work 39230 with language frontends. 39231 39232'nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 39233 39234 The type machinery expects all pointers to point to the start of an 39235 object. Sometimes for abstraction purposes it's convenient to have 39236 a pointer which points inside an object. So long as it's possible 39237 to convert the original object to and from the pointer, such 39238 pointers can still be used. TYPE is the type of the original 39239 object, the TO EXPRESSION returns the pointer given the original 39240 object, and the FROM EXPRESSION returns the original object given 39241 the pointer. The pointer will be available using the '%h' escape. 39242 39243'chain_next ("EXPRESSION")' 39244'chain_prev ("EXPRESSION")' 39245'chain_circular ("EXPRESSION")' 39246 39247 It's helpful for the type machinery to know if objects are often 39248 chained together in long lists; this lets it generate code that 39249 uses less stack space by iterating along the list instead of 39250 recursing down it. 'chain_next' is an expression for the next item 39251 in the list, 'chain_prev' is an expression for the previous item. 39252 For singly linked lists, use only 'chain_next'; for doubly linked 39253 lists, use both. The machinery requires that taking the next item 39254 of the previous item gives the original item. 'chain_circular' is 39255 similar to 'chain_next', but can be used for circular single linked 39256 lists. 39257 39258'reorder ("FUNCTION NAME")' 39259 39260 Some data structures depend on the relative ordering of pointers. 39261 If the precompiled header machinery needs to change that ordering, 39262 it will call the function referenced by the 'reorder' option, 39263 before changing the pointers in the object that's pointed to by the 39264 field the option applies to. The function must take four 39265 arguments, with the signature 39266 'void *, void *, gt_pointer_operator, void *'. The first parameter 39267 is a pointer to the structure that contains the object being 39268 updated, or the object itself if there is no containing structure. 39269 The second parameter is a cookie that should be ignored. The third 39270 parameter is a routine that, given a pointer, will update it to its 39271 correct new value. The fourth parameter is a cookie that must be 39272 passed to the second parameter. 39273 39274 PCH cannot handle data structures that depend on the absolute 39275 values of pointers. 'reorder' functions can be expensive. When 39276 possible, it is better to depend on properties of the data, like an 39277 ID number or the hash of a string instead. 39278 39279'atomic' 39280 39281 The 'atomic' option can only be used with pointers. It informs the 39282 GC machinery that the memory that the pointer points to does not 39283 contain any pointers, and hence it should be treated by the GC and 39284 PCH machinery as an "atomic" block of memory that does not need to 39285 be examined when scanning memory for pointers. In particular, the 39286 machinery will not scan that memory for pointers to mark them as 39287 reachable (when marking pointers for GC) or to relocate them (when 39288 writing a PCH file). 39289 39290 The 'atomic' option differs from the 'skip' option. 'atomic' keeps 39291 the memory under Garbage Collection, but makes the GC ignore the 39292 contents of the memory. 'skip' is more drastic in that it causes 39293 the pointer and the memory to be completely ignored by the Garbage 39294 Collector. So, memory marked as 'atomic' is automatically freed 39295 when no longer reachable, while memory marked as 'skip' is not. 39296 39297 The 'atomic' option must be used with great care, because all sorts 39298 of problem can occur if used incorrectly, that is, if the memory 39299 the pointer points to does actually contain a pointer. 39300 39301 Here is an example of how to use it: 39302 struct GTY(()) my_struct { 39303 int number_of_elements; 39304 unsigned int * GTY ((atomic)) elements; 39305 }; 39306 In this case, 'elements' is a pointer under GC, and the memory it 39307 points to needs to be allocated using the Garbage Collector, and 39308 will be freed automatically by the Garbage Collector when it is no 39309 longer referenced. But the memory that the pointer points to is an 39310 array of 'unsigned int' elements, and the GC must not try to scan 39311 it to find pointers to mark or relocate, which is why it is marked 39312 with the 'atomic' option. 39313 39314 Note that, currently, global variables can not be marked with 39315 'atomic'; only fields of a struct can. This is a known limitation. 39316 It would be useful to be able to mark global pointers with 'atomic' 39317 to make the PCH machinery aware of them so that they are saved and 39318 restored correctly to PCH files. 39319 39320'special ("NAME")' 39321 39322 The 'special' option is used to mark types that have to be dealt 39323 with by special case machinery. The parameter is the name of the 39324 special case. See 'gengtype.c' for further details. Avoid adding 39325 new special cases unless there is no other alternative. 39326 39327'user' 39328 39329 The 'user' option indicates that the code to mark structure fields 39330 is completely handled by user-provided routines. See section *note 39331 User GC:: for details on what functions need to be provided. 39332 39333 39334File: gccint.info, Node: Inheritance and GTY, Next: User GC, Prev: GTY Options, Up: Type Information 39335 3933622.2 Support for inheritance 39337============================ 39338 39339gengtype has some support for simple class hierarchies. You can use 39340this to have gengtype autogenerate marking routines, provided: 39341 39342 * There must be a concrete base class, with a discriminator 39343 expression that can be used to identify which subclass an instance 39344 is. 39345 * Only single inheritance is used. 39346 * None of the classes within the hierarchy are templates. 39347 39348 If your class hierarchy does not fit in this pattern, you must use 39349*note User GC:: instead. 39350 39351 The base class and its discriminator must be identified using the 39352"desc" option. Each concrete subclass must use the "tag" option to 39353identify which value of the discriminator it corresponds to. 39354 39355 Every class in the hierarchy must have a 'GTY(())' marker, as gengtype 39356will only attempt to parse classes that have such a marker (1). 39357 39358 class GTY((desc("%h.kind"), tag("0"))) example_base 39359 { 39360 public: 39361 int kind; 39362 tree a; 39363 }; 39364 39365 class GTY((tag("1")) some_subclass : public example_base 39366 { 39367 public: 39368 tree b; 39369 }; 39370 39371 class GTY((tag("2")) some_other_subclass : public example_base 39372 { 39373 public: 39374 tree c; 39375 }; 39376 39377 The generated marking routines for the above will contain a "switch" on 39378"kind", visiting all appropriate fields. For example, if kind is 2, it 39379will cast to "some_other_subclass" and visit fields a, b, and c. 39380 39381 ---------- Footnotes ---------- 39382 39383 (1) Classes lacking such a marker will not be identified as being 39384part of the hierarchy, and so the marking routines will not handle them, 39385leading to a assertion failure within the marking routines due to an 39386unknown tag value (assuming that assertions are enabled). 39387 39388 39389File: gccint.info, Node: User GC, Next: GGC Roots, Prev: Inheritance and GTY, Up: Type Information 39390 3939122.3 Support for user-provided GC marking routines 39392================================================== 39393 39394The garbage collector supports types for which no automatic marking code 39395is generated. For these types, the user is required to provide three 39396functions: one to act as a marker for garbage collection, and two 39397functions to act as marker and pointer walker for pre-compiled headers. 39398 39399 Given a structure 'struct GTY((user)) my_struct', the following 39400functions should be defined to mark 'my_struct': 39401 39402 void gt_ggc_mx (my_struct *p) 39403 { 39404 /* This marks field 'fld'. */ 39405 gt_ggc_mx (p->fld); 39406 } 39407 39408 void gt_pch_nx (my_struct *p) 39409 { 39410 /* This marks field 'fld'. */ 39411 gt_pch_nx (tp->fld); 39412 } 39413 39414 void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie) 39415 { 39416 /* For every field 'fld', call the given pointer operator. */ 39417 op (&(tp->fld), cookie); 39418 } 39419 39420 In general, each marker 'M' should call 'M' for every pointer field in 39421the structure. Fields that are not allocated in GC or are not pointers 39422must be ignored. 39423 39424 For embedded lists (e.g., structures with a 'next' or 'prev' pointer), 39425the marker must follow the chain and mark every element in it. 39426 39427 Note that the rules for the pointer walker 'gt_pch_nx (my_struct *, 39428gt_pointer_operator, void *)' are slightly different. In this case, the 39429operation 'op' must be applied to the _address_ of every pointer field. 39430 3943122.3.1 User-provided marking routines for template types 39432-------------------------------------------------------- 39433 39434When a template type 'TP' is marked with 'GTY', all instances of that 39435type are considered user-provided types. This means that the individual 39436instances of 'TP' do not need to be marked with 'GTY'. The user needs 39437to provide template functions to mark all the fields of the type. 39438 39439 The following code snippets represent all the functions that need to be 39440provided. Note that type 'TP' may reference to more than one type. In 39441these snippets, there is only one type 'T', but there could be more. 39442 39443 template<typename T> 39444 void gt_ggc_mx (TP<T> *tp) 39445 { 39446 extern void gt_ggc_mx (T&); 39447 39448 /* This marks field 'fld' of type 'T'. */ 39449 gt_ggc_mx (tp->fld); 39450 } 39451 39452 template<typename T> 39453 void gt_pch_nx (TP<T> *tp) 39454 { 39455 extern void gt_pch_nx (T&); 39456 39457 /* This marks field 'fld' of type 'T'. */ 39458 gt_pch_nx (tp->fld); 39459 } 39460 39461 template<typename T> 39462 void gt_pch_nx (TP<T *> *tp, gt_pointer_operator op, void *cookie) 39463 { 39464 /* For every field 'fld' of 'tp' with type 'T *', call the given 39465 pointer operator. */ 39466 op (&(tp->fld), cookie); 39467 } 39468 39469 template<typename T> 39470 void gt_pch_nx (TP<T> *tp, gt_pointer_operator, void *cookie) 39471 { 39472 extern void gt_pch_nx (T *, gt_pointer_operator, void *); 39473 39474 /* For every field 'fld' of 'tp' with type 'T', call the pointer 39475 walker for all the fields of T. */ 39476 gt_pch_nx (&(tp->fld), op, cookie); 39477 } 39478 39479 Support for user-defined types is currently limited. The following 39480restrictions apply: 39481 39482 1. Type 'TP' and all the argument types 'T' must be marked with 'GTY'. 39483 39484 2. Type 'TP' can only have type names in its argument list. 39485 39486 3. The pointer walker functions are different for 'TP<T>' and 'TP<T 39487 *>'. In the case of 'TP<T>', references to 'T' must be handled by 39488 calling 'gt_pch_nx' (which will, in turn, walk all the pointers 39489 inside fields of 'T'). In the case of 'TP<T *>', references to 'T 39490 *' must be handled by calling the 'op' function on the address of 39491 the pointer (see the code snippets above). 39492 39493 39494File: gccint.info, Node: GGC Roots, Next: Files, Prev: User GC, Up: Type Information 39495 3949622.4 Marking Roots for the Garbage Collector 39497============================================ 39498 39499In addition to keeping track of types, the type machinery also locates 39500the global variables ("roots") that the garbage collector starts at. 39501Roots must be declared using one of the following syntaxes: 39502 39503 * 'extern GTY(([OPTIONS])) TYPE NAME;' 39504 * 'static GTY(([OPTIONS])) TYPE NAME;' 39505The syntax 39506 * 'GTY(([OPTIONS])) TYPE NAME;' 39507is _not_ accepted. There should be an 'extern' declaration of such a 39508variable in a header somewhere--mark that, not the definition. Or, if 39509the variable is only used in one file, make it 'static'. 39510 39511 39512File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information 39513 3951422.5 Source Files Containing Type Information 39515============================================= 39516 39517Whenever you add 'GTY' markers to a source file that previously had 39518none, or create a new source file containing 'GTY' markers, there are 39519three things you need to do: 39520 39521 1. You need to add the file to the list of source files the type 39522 machinery scans. There are four cases: 39523 39524 a. For a back-end file, this is usually done automatically; if 39525 not, you should add it to 'target_gtfiles' in the appropriate 39526 port's entries in 'config.gcc'. 39527 39528 b. For files shared by all front ends, add the filename to the 39529 'GTFILES' variable in 'Makefile.in'. 39530 39531 c. For files that are part of one front end, add the filename to 39532 the 'gtfiles' variable defined in the appropriate 39533 'config-lang.in'. Headers should appear before non-headers in 39534 this list. 39535 39536 d. For files that are part of some but not all front ends, add 39537 the filename to the 'gtfiles' variable of _all_ the front ends 39538 that use it. 39539 39540 2. If the file was a header file, you'll need to check that it's 39541 included in the right place to be visible to the generated files. 39542 For a back-end header file, this should be done automatically. For 39543 a front-end header file, it needs to be included by the same file 39544 that includes 'gtype-LANG.h'. For other header files, it needs to 39545 be included in 'gtype-desc.c', which is a generated file, so add it 39546 to 'ifiles' in 'open_base_file' in 'gengtype.c'. 39547 39548 For source files that aren't header files, the machinery will 39549 generate a header file that should be included in the source file 39550 you just changed. The file will be called 'gt-PATH.h' where PATH 39551 is the pathname relative to the 'gcc' directory with slashes 39552 replaced by -, so for example the header file to be included in 39553 'cp/parser.c' is called 'gt-cp-parser.c'. The generated header 39554 file should be included after everything else in the source file. 39555 Don't forget to mention this file as a dependency in the 39556 'Makefile'! 39557 39558 For language frontends, there is another file that needs to be included 39559somewhere. It will be called 'gtype-LANG.h', where LANG is the name of 39560the subdirectory the language is contained in. 39561 39562 Plugins can add additional root tables. Run the 'gengtype' utility in 39563plugin mode as 'gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C' 39564with your plugin files PLUGIN*.C using 'GTY' to generate the PLUGINOUT.H 39565file. The GCC build tree is needed to be present in that mode. 39566 39567 39568File: gccint.info, Node: Invoking the garbage collector, Next: Troubleshooting, Prev: Files, Up: Type Information 39569 3957022.6 How to invoke the garbage collector 39571======================================== 39572 39573The GCC garbage collector GGC is only invoked explicitly. In contrast 39574with many other garbage collectors, it is not implicitly invoked by 39575allocation routines when a lot of memory has been consumed. So the only 39576way to have GGC reclaim storage is to call the 'ggc_collect' function 39577explicitly. This call is an expensive operation, as it may have to scan 39578the entire heap. Beware that local variables (on the GCC call stack) 39579are not followed by such an invocation (as many other garbage collectors 39580do): you should reference all your data from static or external 'GTY'-ed 39581variables, and it is advised to call 'ggc_collect' with a shallow call 39582stack. The GGC is an exact mark and sweep garbage collector (so it does 39583not scan the call stack for pointers). In practice GCC passes don't 39584often call 'ggc_collect' themselves, because it is called by the pass 39585manager between passes. 39586 39587 At the time of the 'ggc_collect' call all pointers in the GC-marked 39588structures must be valid or 'NULL'. In practice this means that there 39589should not be uninitialized pointer fields in the structures even if 39590your code never reads or writes those fields at a particular instance. 39591One way to ensure this is to use cleared versions of allocators unless 39592all the fields are initialized manually immediately after allocation. 39593 39594 39595File: gccint.info, Node: Troubleshooting, Prev: Invoking the garbage collector, Up: Type Information 39596 3959722.7 Troubleshooting the garbage collector 39598========================================== 39599 39600With the current garbage collector implementation, most issues should 39601show up as GCC compilation errors. Some of the most commonly 39602encountered issues are described below. 39603 39604 * Gengtype does not produce allocators for a 'GTY'-marked type. 39605 Gengtype checks if there is at least one possible path from GC 39606 roots to at least one instance of each type before outputting 39607 allocators. If there is no such path, the 'GTY' markers will be 39608 ignored and no allocators will be output. Solve this by making 39609 sure that there exists at least one such path. If creating it is 39610 unfeasible or raises a "code smell", consider if you really must 39611 use GC for allocating such type. 39612 39613 * Link-time errors about undefined 'gt_ggc_r_foo_bar' and 39614 similarly-named symbols. Check if your 'foo_bar' source file has 39615 '#include "gt-foo_bar.h"' as its very last line. 39616 39617 39618File: gccint.info, Node: Plugins, Next: LTO, Prev: Type Information, Up: Top 39619 3962023 Plugins 39621********** 39622 39623GCC plugins are loadable modules that provide extra features to the 39624compiler. Like GCC itself they can be distributed in source and binary 39625forms. 39626 39627 GCC plugins provide developers with a rich subset of the GCC API to 39628allow them to extend GCC as they see fit. Whether it is writing an 39629additional optimization pass, transforming code, or analyzing 39630information, plugins can be quite useful. 39631 39632* Menu: 39633 39634* Plugins loading:: How can we load plugins. 39635* Plugin API:: The APIs for plugins. 39636* Plugins pass:: How a plugin interact with the pass manager. 39637* Plugins GC:: How a plugin Interact with GCC Garbage Collector. 39638* Plugins description:: Giving information about a plugin itself. 39639* Plugins attr:: Registering custom attributes or pragmas. 39640* Plugins recording:: Recording information about pass execution. 39641* Plugins gate:: Controlling which passes are being run. 39642* Plugins tracking:: Keeping track of available passes. 39643* Plugins building:: How can we build a plugin. 39644 39645 39646File: gccint.info, Node: Plugins loading, Next: Plugin API, Up: Plugins 39647 3964823.1 Loading Plugins 39649==================== 39650 39651Plugins are supported on platforms that support '-ldl -rdynamic'. They 39652are loaded by the compiler using 'dlopen' and invoked at pre-determined 39653locations in the compilation process. 39654 39655 Plugins are loaded with 39656 39657 '-fplugin=/path/to/NAME.so' '-fplugin-arg-NAME-KEY1[=VALUE1]' 39658 39659 The plugin arguments are parsed by GCC and passed to respective plugins 39660as key-value pairs. Multiple plugins can be invoked by specifying 39661multiple '-fplugin' arguments. 39662 39663 A plugin can be simply given by its short name (no dots or slashes). 39664When simply passing '-fplugin=NAME', the plugin is loaded from the 39665'plugin' directory, so '-fplugin=NAME' is the same as '-fplugin=`gcc 39666-print-file-name=plugin`/NAME.so', using backquote shell syntax to query 39667the 'plugin' directory. 39668 39669 39670File: gccint.info, Node: Plugin API, Next: Plugins pass, Prev: Plugins loading, Up: Plugins 39671 3967223.2 Plugin API 39673=============== 39674 39675Plugins are activated by the compiler at specific events as defined in 39676'gcc-plugin.h'. For each event of interest, the plugin should call 39677'register_callback' specifying the name of the event and address of the 39678callback function that will handle that event. 39679 39680 The header 'gcc-plugin.h' must be the first gcc header to be included. 39681 3968223.2.1 Plugin license check 39683--------------------------- 39684 39685Every plugin should define the global symbol 'plugin_is_GPL_compatible' 39686to assert that it has been licensed under a GPL-compatible license. If 39687this symbol does not exist, the compiler will emit a fatal error and 39688exit with the error message: 39689 39690 fatal error: plugin NAME is not licensed under a GPL-compatible license 39691 NAME: undefined symbol: plugin_is_GPL_compatible 39692 compilation terminated 39693 39694 The declared type of the symbol should be int, to match a forward 39695declaration in 'gcc-plugin.h' that suppresses C++ mangling. It does not 39696need to be in any allocated section, though. The compiler merely 39697asserts that the symbol exists in the global scope. Something like this 39698is enough: 39699 39700 int plugin_is_GPL_compatible; 39701 3970223.2.2 Plugin initialization 39703---------------------------- 39704 39705Every plugin should export a function called 'plugin_init' that is 39706called right after the plugin is loaded. This function is responsible 39707for registering all the callbacks required by the plugin and do any 39708other required initialization. 39709 39710 This function is called from 'compile_file' right before invoking the 39711parser. The arguments to 'plugin_init' are: 39712 39713 * 'plugin_info': Plugin invocation information. 39714 * 'version': GCC version. 39715 39716 The 'plugin_info' struct is defined as follows: 39717 39718 struct plugin_name_args 39719 { 39720 char *base_name; /* Short name of the plugin 39721 (filename without .so suffix). */ 39722 const char *full_name; /* Path to the plugin as specified with 39723 -fplugin=. */ 39724 int argc; /* Number of arguments specified with 39725 -fplugin-arg-.... */ 39726 struct plugin_argument *argv; /* Array of ARGC key-value pairs. */ 39727 const char *version; /* Version string provided by plugin. */ 39728 const char *help; /* Help string provided by plugin. */ 39729 } 39730 39731 If initialization fails, 'plugin_init' must return a non-zero value. 39732Otherwise, it should return 0. 39733 39734 The version of the GCC compiler loading the plugin is described by the 39735following structure: 39736 39737 struct plugin_gcc_version 39738 { 39739 const char *basever; 39740 const char *datestamp; 39741 const char *devphase; 39742 const char *revision; 39743 const char *configuration_arguments; 39744 }; 39745 39746 The function 'plugin_default_version_check' takes two pointers to such 39747structure and compare them field by field. It can be used by the 39748plugin's 'plugin_init' function. 39749 39750 The version of GCC used to compile the plugin can be found in the 39751symbol 'gcc_version' defined in the header 'plugin-version.h'. The 39752recommended version check to perform looks like 39753 39754 #include "plugin-version.h" 39755 ... 39756 39757 int 39758 plugin_init (struct plugin_name_args *plugin_info, 39759 struct plugin_gcc_version *version) 39760 { 39761 if (!plugin_default_version_check (version, &gcc_version)) 39762 return 1; 39763 39764 } 39765 39766 but you can also check the individual fields if you want a less strict 39767check. 39768 3976923.2.3 Plugin callbacks 39770----------------------- 39771 39772Callback functions have the following prototype: 39773 39774 /* The prototype for a plugin callback function. 39775 gcc_data - event-specific data provided by GCC 39776 user_data - plugin-specific data provided by the plug-in. */ 39777 typedef void (*plugin_callback_func)(void *gcc_data, void *user_data); 39778 39779 Callbacks can be invoked at the following pre-determined events: 39780 39781 enum plugin_event 39782 { 39783 PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */ 39784 PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */ 39785 PLUGIN_FINISH_DECL, /* After finishing parsing a declaration. */ 39786 PLUGIN_FINISH_UNIT, /* Useful for summary processing. */ 39787 PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */ 39788 PLUGIN_FINISH, /* Called before GCC exits. */ 39789 PLUGIN_INFO, /* Information about the plugin. */ 39790 PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */ 39791 PLUGIN_GGC_MARKING, /* Extend the GGC marking. */ 39792 PLUGIN_GGC_END, /* Called at end of GGC. */ 39793 PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */ 39794 PLUGIN_ATTRIBUTES, /* Called during attribute registration */ 39795 PLUGIN_START_UNIT, /* Called before processing a translation unit. */ 39796 PLUGIN_PRAGMAS, /* Called during pragma registration. */ 39797 /* Called before first pass from all_passes. */ 39798 PLUGIN_ALL_PASSES_START, 39799 /* Called after last pass from all_passes. */ 39800 PLUGIN_ALL_PASSES_END, 39801 /* Called before first ipa pass. */ 39802 PLUGIN_ALL_IPA_PASSES_START, 39803 /* Called after last ipa pass. */ 39804 PLUGIN_ALL_IPA_PASSES_END, 39805 /* Allows to override pass gate decision for current_pass. */ 39806 PLUGIN_OVERRIDE_GATE, 39807 /* Called before executing a pass. */ 39808 PLUGIN_PASS_EXECUTION, 39809 /* Called before executing subpasses of a GIMPLE_PASS in 39810 execute_ipa_pass_list. */ 39811 PLUGIN_EARLY_GIMPLE_PASSES_START, 39812 /* Called after executing subpasses of a GIMPLE_PASS in 39813 execute_ipa_pass_list. */ 39814 PLUGIN_EARLY_GIMPLE_PASSES_END, 39815 /* Called when a pass is first instantiated. */ 39816 PLUGIN_NEW_PASS, 39817 /* Called when a file is #include-d or given via the #line directive. 39818 This could happen many times. The event data is the included file path, 39819 as a const char* pointer. */ 39820 PLUGIN_INCLUDE_FILE, 39821 39822 PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback 39823 array. */ 39824 }; 39825 39826 In addition, plugins can also look up the enumerator of a named event, 39827and / or generate new events dynamically, by calling the function 39828'get_named_event_id'. 39829 39830 To register a callback, the plugin calls 'register_callback' with the 39831arguments: 39832 39833 * 'char *name': Plugin name. 39834 * 'int event': The event code. 39835 * 'plugin_callback_func callback': The function that handles 'event'. 39836 * 'void *user_data': Pointer to plugin-specific data. 39837 39838 For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, and 39839PLUGIN_REGISTER_GGC_ROOTS pseudo-events the 'callback' should be null, 39840and the 'user_data' is specific. 39841 39842 When the PLUGIN_PRAGMAS event is triggered (with a null pointer as data 39843from GCC), plugins may register their own pragmas. Notice that pragmas 39844are not available from 'lto1', so plugins used with '-flto' option to 39845GCC during link-time optimization cannot use pragmas and do not even see 39846functions like 'c_register_pragma' or 'pragma_lex'. 39847 39848 The PLUGIN_INCLUDE_FILE event, with a 'const char*' file path as GCC 39849data, is triggered for processing of '#include' or '#line' directives. 39850 39851 The PLUGIN_FINISH event is the last time that plugins can call GCC 39852functions, notably emit diagnostics with 'warning', 'error' etc. 39853 39854 39855File: gccint.info, Node: Plugins pass, Next: Plugins GC, Prev: Plugin API, Up: Plugins 39856 3985723.3 Interacting with the pass manager 39858====================================== 39859 39860There needs to be a way to add/reorder/remove passes dynamically. This 39861is useful for both analysis plugins (plugging in after a certain pass 39862such as CFG or an IPA pass) and optimization plugins. 39863 39864 Basic support for inserting new passes or replacing existing passes is 39865provided. A plugin registers a new pass with GCC by calling 39866'register_callback' with the 'PLUGIN_PASS_MANAGER_SETUP' event and a 39867pointer to a 'struct register_pass_info' object defined as follows 39868 39869 enum pass_positioning_ops 39870 { 39871 PASS_POS_INSERT_AFTER, // Insert after the reference pass. 39872 PASS_POS_INSERT_BEFORE, // Insert before the reference pass. 39873 PASS_POS_REPLACE // Replace the reference pass. 39874 }; 39875 39876 struct register_pass_info 39877 { 39878 struct opt_pass *pass; /* New pass provided by the plugin. */ 39879 const char *reference_pass_name; /* Name of the reference pass for hooking 39880 up the new pass. */ 39881 int ref_pass_instance_number; /* Insert the pass at the specified 39882 instance number of the reference pass. */ 39883 /* Do it for every instance if it is 0. */ 39884 enum pass_positioning_ops pos_op; /* how to insert the new pass. */ 39885 }; 39886 39887 39888 /* Sample plugin code that registers a new pass. */ 39889 int 39890 plugin_init (struct plugin_name_args *plugin_info, 39891 struct plugin_gcc_version *version) 39892 { 39893 struct register_pass_info pass_info; 39894 39895 ... 39896 39897 /* Code to fill in the pass_info object with new pass information. */ 39898 39899 ... 39900 39901 /* Register the new pass. */ 39902 register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info); 39903 39904 ... 39905 } 39906 39907 39908File: gccint.info, Node: Plugins GC, Next: Plugins description, Prev: Plugins pass, Up: Plugins 39909 3991023.4 Interacting with the GCC Garbage Collector 39911=============================================== 39912 39913Some plugins may want to be informed when GGC (the GCC Garbage 39914Collector) is running. They can register callbacks for the 39915'PLUGIN_GGC_START' and 'PLUGIN_GGC_END' events (for which the callback 39916is called with a null 'gcc_data') to be notified of the start or end of 39917the GCC garbage collection. 39918 39919 Some plugins may need to have GGC mark additional data. This can be 39920done by registering a callback (called with a null 'gcc_data') for the 39921'PLUGIN_GGC_MARKING' event. Such callbacks can call the 'ggc_set_mark' 39922routine, preferably through the 'ggc_mark' macro (and conversely, these 39923routines should usually not be used in plugins outside of the 39924'PLUGIN_GGC_MARKING' event). Plugins that wish to hold weak references 39925to gc data may also use this event to drop weak references when the 39926object is about to be collected. The 'ggc_marked_p' function can be 39927used to tell if an object is marked, or is about to be collected. The 39928'gt_clear_cache' overloads which some types define may also be of use in 39929managing weak references. 39930 39931 Some plugins may need to add extra GGC root tables, e.g. to handle 39932their own 'GTY'-ed data. This can be done with the 39933'PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the 39934extra root table (of type 'struct ggc_root_tab*') as 'user_data'. 39935Running the 'gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility 39936generates these extra root tables. 39937 39938 You should understand the details of memory management inside GCC 39939before using 'PLUGIN_GGC_MARKING' or 'PLUGIN_REGISTER_GGC_ROOTS'. 39940 39941 39942File: gccint.info, Node: Plugins description, Next: Plugins attr, Prev: Plugins GC, Up: Plugins 39943 3994423.5 Giving information about a plugin 39945====================================== 39946 39947A plugin should give some information to the user about itself. This 39948uses the following structure: 39949 39950 struct plugin_info 39951 { 39952 const char *version; 39953 const char *help; 39954 }; 39955 39956 Such a structure is passed as the 'user_data' by the plugin's init 39957routine using 'register_callback' with the 'PLUGIN_INFO' pseudo-event 39958and a null callback. 39959 39960 39961File: gccint.info, Node: Plugins attr, Next: Plugins recording, Prev: Plugins description, Up: Plugins 39962 3996323.6 Registering custom attributes or pragmas 39964============================================= 39965 39966For analysis (or other) purposes it is useful to be able to add custom 39967attributes or pragmas. 39968 39969 The 'PLUGIN_ATTRIBUTES' callback is called during attribute 39970registration. Use the 'register_attribute' function to register custom 39971attributes. 39972 39973 /* Attribute handler callback */ 39974 static tree 39975 handle_user_attribute (tree *node, tree name, tree args, 39976 int flags, bool *no_add_attrs) 39977 { 39978 return NULL_TREE; 39979 } 39980 39981 /* Attribute definition */ 39982 static struct attribute_spec user_attr = 39983 { "user", 1, 1, false, false, false, handle_user_attribute, false }; 39984 39985 /* Plugin callback called during attribute registration. 39986 Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL) 39987 */ 39988 static void 39989 register_attributes (void *event_data, void *data) 39990 { 39991 warning (0, G_("Callback to register attributes")); 39992 register_attribute (&user_attr); 39993 } 39994 39995 39996 The PLUGIN_PRAGMAS callback is called once during pragmas registration. 39997Use the 'c_register_pragma', 'c_register_pragma_with_data', 39998'c_register_pragma_with_expansion', 39999'c_register_pragma_with_expansion_and_data' functions to register custom 40000pragmas and their handlers (which often want to call 'pragma_lex') from 40001'c-family/c-pragma.h'. 40002 40003 /* Plugin callback called during pragmas registration. Registered with 40004 register_callback (plugin_name, PLUGIN_PRAGMAS, 40005 register_my_pragma, NULL); 40006 */ 40007 static void 40008 register_my_pragma (void *event_data, void *data) 40009 { 40010 warning (0, G_("Callback to register pragmas")); 40011 c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello); 40012 } 40013 40014 It is suggested to pass '"GCCPLUGIN"' (or a short name identifying your 40015plugin) as the "space" argument of your pragma. 40016 40017 Pragmas registered with 'c_register_pragma_with_expansion' or 40018'c_register_pragma_with_expansion_and_data' support preprocessor 40019expansions. For example: 40020 40021 #define NUMBER 10 40022 #pragma GCCPLUGIN foothreshold (NUMBER) 40023 40024 40025File: gccint.info, Node: Plugins recording, Next: Plugins gate, Prev: Plugins attr, Up: Plugins 40026 4002723.7 Recording information about pass execution 40028=============================================== 40029 40030The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass 40031(the same as current_pass) as 'gcc_data' to the callback. You can also 40032inspect cfun to find out about which function this pass is executed for. 40033Note that this event will only be invoked if the gate check (if 40034applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use 40035other hooks, like 'PLUGIN_ALL_PASSES_START', 'PLUGIN_ALL_PASSES_END', 40036'PLUGIN_ALL_IPA_PASSES_START', 'PLUGIN_ALL_IPA_PASSES_END', 40037'PLUGIN_EARLY_GIMPLE_PASSES_START', and/or 40038'PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your 40039plugin(s) in order to get context for the pass execution. 40040 40041 40042File: gccint.info, Node: Plugins gate, Next: Plugins tracking, Prev: Plugins recording, Up: Plugins 40043 4004423.8 Controlling which passes are being run 40045=========================================== 40046 40047After the original gate function for a pass is called, its result - the 40048gate status - is stored as an integer. Then the event 40049'PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in 40050the 'gcc_data' parameter to the callback function. A nonzero value of 40051the gate status means that the pass is to be executed. You can both 40052read and write the gate status via the passed pointer. 40053 40054 40055File: gccint.info, Node: Plugins tracking, Next: Plugins building, Prev: Plugins gate, Up: Plugins 40056 4005723.9 Keeping track of available passes 40058====================================== 40059 40060When your plugin is loaded, you can inspect the various pass lists to 40061determine what passes are available. However, other plugins might add 40062new passes. Also, future changes to GCC might cause generic passes to 40063be added after plugin loading. When a pass is first added to one of the 40064pass lists, the event 'PLUGIN_NEW_PASS' is invoked, with the callback 40065parameter 'gcc_data' pointing to the new pass. 40066 40067 40068File: gccint.info, Node: Plugins building, Prev: Plugins tracking, Up: Plugins 40069 4007023.10 Building GCC plugins 40071========================== 40072 40073If plugins are enabled, GCC installs the headers needed to build a 40074plugin (somewhere in the installation tree, e.g. under '/usr/local'). 40075In particular a 'plugin/include' directory is installed, containing all 40076the header files needed to build plugins. 40077 40078 On most systems, you can query this 'plugin' directory by invoking 'gcc 40079-print-file-name=plugin' (replace if needed 'gcc' with the appropriate 40080program path). 40081 40082 Inside plugins, this 'plugin' directory name can be queried by calling 40083'default_plugin_dir_name ()'. 40084 40085 Plugins may know, when they are compiled, the GCC version for which 40086'plugin-version.h' is provided. The constant macros 40087'GCCPLUGIN_VERSION_MAJOR', 'GCCPLUGIN_VERSION_MINOR', 40088'GCCPLUGIN_VERSION_PATCHLEVEL', 'GCCPLUGIN_VERSION' are integer numbers, 40089so a plugin could ensure it is built for GCC 4.7 with 40090 #if GCCPLUGIN_VERSION != 4007 40091 #error this GCC plugin is for GCC 4.7 40092 #endif 40093 40094 The following GNU Makefile excerpt shows how to build a simple plugin: 40095 40096 HOST_GCC=g++ 40097 TARGET_GCC=gcc 40098 PLUGIN_SOURCE_FILES= plugin1.c plugin2.cc 40099 GCCPLUGINS_DIR:= $(shell $(TARGET_GCC) -print-file-name=plugin) 40100 CXXFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -fno-rtti -O2 40101 40102 plugin.so: $(PLUGIN_SOURCE_FILES) 40103 $(HOST_GCC) -shared $(CXXFLAGS) $^ -o $@ 40104 40105 A single source file plugin may be built with 'g++ -I`gcc 40106-print-file-name=plugin`/include -fPIC -shared -fno-rtti -O2 plugin.c -o 40107plugin.so', using backquote shell syntax to query the 'plugin' 40108directory. 40109 40110 When a plugin needs to use 'gengtype', be sure that both 'gengtype' and 40111'gtype.state' have the same version as the GCC for which the plugin is 40112built. 40113 40114 40115File: gccint.info, Node: LTO, Next: Match and Simplify, Prev: Plugins, Up: Top 40116 4011724 Link Time Optimization 40118************************* 40119 40120Link Time Optimization (LTO) gives GCC the capability of dumping its 40121internal representation (GIMPLE) to disk, so that all the different 40122compilation units that make up a single executable can be optimized as a 40123single module. This expands the scope of inter-procedural optimizations 40124to encompass the whole program (or, rather, everything that is visible 40125at link time). 40126 40127* Menu: 40128 40129* LTO Overview:: Overview of LTO. 40130* LTO object file layout:: LTO file sections in ELF. 40131* IPA:: Using summary information in IPA passes. 40132* WHOPR:: Whole program assumptions, 40133 linker plugin and symbol visibilities. 40134* Internal flags:: Internal flags controlling 'lto1'. 40135 40136 40137File: gccint.info, Node: LTO Overview, Next: LTO object file layout, Up: LTO 40138 4013924.1 Design Overview 40140==================== 40141 40142Link time optimization is implemented as a GCC front end for a bytecode 40143representation of GIMPLE that is emitted in special sections of '.o' 40144files. Currently, LTO support is enabled in most ELF-based systems, as 40145well as darwin, cygwin and mingw systems. 40146 40147 Since GIMPLE bytecode is saved alongside final object code, object 40148files generated with LTO support are larger than regular object files. 40149This "fat" object format makes it easy to integrate LTO into existing 40150build systems, as one can, for instance, produce archives of the files. 40151Additionally, one might be able to ship one set of fat objects which 40152could be used both for development and the production of optimized 40153builds. A, perhaps surprising, side effect of this feature is that any 40154mistake in the toolchain leads to LTO information not being used (e.g. 40155an older 'libtool' calling 'ld' directly). This is both an advantage, 40156as the system is more robust, and a disadvantage, as the user is not 40157informed that the optimization has been disabled. 40158 40159 The current implementation only produces "fat" objects, effectively 40160doubling compilation time and increasing file sizes up to 5x the 40161original size. This hides the problem that some tools, such as 'ar' and 40162'nm', need to understand symbol tables of LTO sections. These tools 40163were extended to use the plugin infrastructure, and with these problems 40164solved, GCC will also support "slim" objects consisting of the 40165intermediate code alone. 40166 40167 At the highest level, LTO splits the compiler in two. The first half 40168(the "writer") produces a streaming representation of all the internal 40169data structures needed to optimize and generate code. This includes 40170declarations, types, the callgraph and the GIMPLE representation of 40171function bodies. 40172 40173 When '-flto' is given during compilation of a source file, the pass 40174manager executes all the passes in 'all_lto_gen_passes'. Currently, 40175this phase is composed of two IPA passes: 40176 40177 * 'pass_ipa_lto_gimple_out' This pass executes the function 40178 'lto_output' in 'lto-streamer-out.c', which traverses the call 40179 graph encoding every reachable declaration, type and function. 40180 This generates a memory representation of all the file sections 40181 described below. 40182 40183 * 'pass_ipa_lto_finish_out' This pass executes the function 40184 'produce_asm_for_decls' in 'lto-streamer-out.c', which takes the 40185 memory image built in the previous pass and encodes it in the 40186 corresponding ELF file sections. 40187 40188 The second half of LTO support is the "reader". This is implemented as 40189the GCC front end 'lto1' in 'lto/lto.c'. When 'collect2' detects a link 40190set of '.o'/'.a' files with LTO information and the '-flto' is enabled, 40191it invokes 'lto1' which reads the set of files and aggregates them into 40192a single translation unit for optimization. The main entry point for 40193the reader is 'lto/lto.c':'lto_main'. 40194 4019524.1.1 LTO modes of operation 40196----------------------------- 40197 40198One of the main goals of the GCC link-time infrastructure was to allow 40199effective compilation of large programs. For this reason GCC implements 40200two link-time compilation modes. 40201 40202 1. _LTO mode_, in which the whole program is read into the compiler at 40203 link-time and optimized in a similar way as if it were a single 40204 source-level compilation unit. 40205 40206 2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs 40207 and/or a distributed compilation environment to quickly link large 40208 applications. WHOPR stands for WHOle Program optimizeR (not to be 40209 confused with the semantics of '-fwhole-program'). It partitions 40210 the aggregated callgraph from many different '.o' files and 40211 distributes the compilation of the sub-graphs to different CPUs. 40212 40213 Note that distributed compilation is not implemented yet, but since 40214 the parallelism is facilitated via generating a 'Makefile', it 40215 would be easy to implement. 40216 40217 WHOPR splits LTO into three main stages: 40218 1. Local generation (LGEN) This stage executes in parallel. Every 40219 file in the program is compiled into the intermediate language and 40220 packaged together with the local call-graph and summary 40221 information. This stage is the same for both the LTO and WHOPR 40222 compilation mode. 40223 40224 2. Whole Program Analysis (WPA) WPA is performed sequentially. The 40225 global call-graph is generated, and a global analysis procedure 40226 makes transformation decisions. The global call-graph is 40227 partitioned to facilitate parallel optimization during phase 3. 40228 The results of the WPA stage are stored into new object files which 40229 contain the partitions of program expressed in the intermediate 40230 language and the optimization decisions. 40231 40232 3. Local transformations (LTRANS) This stage executes in parallel. 40233 All the decisions made during phase 2 are implemented locally in 40234 each partitioned object file, and the final object code is 40235 generated. Optimizations which cannot be decided efficiently 40236 during the phase 2 may be performed on the local call-graph 40237 partitions. 40238 40239 WHOPR can be seen as an extension of the usual LTO mode of compilation. 40240In LTO, WPA and LTRANS are executed within a single execution of the 40241compiler, after the whole program has been read into memory. 40242 40243 When compiling in WHOPR mode, the callgraph is partitioned during the 40244WPA stage. The whole program is split into a given number of partitions 40245of roughly the same size. The compiler tries to minimize the number of 40246references which cross partition boundaries. The main advantage of 40247WHOPR is to allow the parallel execution of LTRANS stages, which are the 40248most time-consuming part of the compilation process. Additionally, it 40249avoids the need to load the whole program into memory. 40250 40251 40252File: gccint.info, Node: LTO object file layout, Next: IPA, Prev: LTO Overview, Up: LTO 40253 4025424.2 LTO file sections 40255====================== 40256 40257LTO information is stored in several ELF sections inside object files. 40258Data structures and enum codes for sections are defined in 40259'lto-streamer.h'. 40260 40261 These sections are emitted from 'lto-streamer-out.c' and mapped in all 40262at once from 'lto/lto.c':'lto_file_read'. The individual functions 40263dealing with the reading/writing of each section are described below. 40264 40265 * Command line options ('.gnu.lto_.opts') 40266 40267 This section contains the command line options used to generate the 40268 object files. This is used at link time to determine the 40269 optimization level and other settings when they are not explicitly 40270 specified at the linker command line. 40271 40272 Currently, GCC does not support combining LTO object files compiled 40273 with different set of the command line options into a single 40274 binary. At link time, the options given on the command line and 40275 the options saved on all the files in a link-time set are applied 40276 globally. No attempt is made at validating the combination of 40277 flags (other than the usual validation done by option processing). 40278 This is implemented in 'lto/lto.c':'lto_read_all_file_options'. 40279 40280 * Symbol table ('.gnu.lto_.symtab') 40281 40282 This table replaces the ELF symbol table for functions and 40283 variables represented in the LTO IL. Symbols used and exported by 40284 the optimized assembly code of "fat" objects might not match the 40285 ones used and exported by the intermediate code. This table is 40286 necessary because the intermediate code is less optimized and thus 40287 requires a separate symbol table. 40288 40289 Additionally, the binary code in the "fat" object will lack a call 40290 to a function, since the call was optimized out at compilation time 40291 after the intermediate language was streamed out. In some special 40292 cases, the same optimization may not happen during link-time 40293 optimization. This would lead to an undefined symbol if only one 40294 symbol table was used. 40295 40296 The symbol table is emitted in 40297 'lto-streamer-out.c':'produce_symtab'. 40298 40299 * Global declarations and types ('.gnu.lto_.decls') 40300 40301 This section contains an intermediate language dump of all 40302 declarations and types required to represent the callgraph, static 40303 variables and top-level debug info. 40304 40305 The contents of this section are emitted in 40306 'lto-streamer-out.c':'produce_asm_for_decls'. Types and symbols 40307 are emitted in a topological order that preserves the sharing of 40308 pointers when the file is read back in 40309 ('lto.c':'read_cgraph_and_symbols'). 40310 40311 * The callgraph ('.gnu.lto_.cgraph') 40312 40313 This section contains the basic data structure used by the GCC 40314 inter-procedural optimization infrastructure. This section stores 40315 an annotated multi-graph which represents the functions and call 40316 sites as well as the variables, aliases and top-level 'asm' 40317 statements. 40318 40319 This section is emitted in 'lto-streamer-out.c':'output_cgraph' and 40320 read in 'lto-cgraph.c':'input_cgraph'. 40321 40322 * IPA references ('.gnu.lto_.refs') 40323 40324 This section contains references between function and static 40325 variables. It is emitted by 'lto-cgraph.c':'output_refs' and read 40326 by 'lto-cgraph.c':'input_refs'. 40327 40328 * Function bodies ('.gnu.lto_.function_body.<name>') 40329 40330 This section contains function bodies in the intermediate language 40331 representation. Every function body is in a separate section to 40332 allow copying of the section independently to different object 40333 files or reading the function on demand. 40334 40335 Functions are emitted in 'lto-streamer-out.c':'output_function' and 40336 read in 'lto-streamer-in.c':'input_function'. 40337 40338 * Static variable initializers ('.gnu.lto_.vars') 40339 40340 This section contains all the symbols in the global variable pool. 40341 It is emitted by 'lto-cgraph.c':'output_varpool' and read in 40342 'lto-cgraph.c':'input_cgraph'. 40343 40344 * Summaries and optimization summaries used by IPA passes 40345 ('.gnu.lto_.<xxx>', where '<xxx>' is one of 'jmpfuncs', 'pureconst' 40346 or 'reference') 40347 40348 These sections are used by IPA passes that need to emit summary 40349 information during LTO generation to be read and aggregated at link 40350 time. Each pass is responsible for implementing two pass manager 40351 hooks: one for writing the summary and another for reading it in. 40352 The format of these sections is entirely up to each individual 40353 pass. The only requirement is that the writer and reader hooks 40354 agree on the format. 40355 40356 40357File: gccint.info, Node: IPA, Next: WHOPR, Prev: LTO object file layout, Up: LTO 40358 4035924.3 Using summary information in IPA passes 40360============================================ 40361 40362Programs are represented internally as a _callgraph_ (a multi-graph 40363where nodes are functions and edges are call sites) and a _varpool_ (a 40364list of static and external variables in the program). 40365 40366 The inter-procedural optimization is organized as a sequence of 40367individual passes, which operate on the callgraph and the varpool. To 40368make the implementation of WHOPR possible, every inter-procedural 40369optimization pass is split into several stages that are executed at 40370different times during WHOPR compilation: 40371 40372 * LGEN time 40373 1. _Generate summary_ ('generate_summary' in 'struct 40374 ipa_opt_pass_d'). This stage analyzes every function body and 40375 variable initializer is examined and stores relevant 40376 information into a pass-specific data structure. 40377 40378 2. _Write summary_ ('write_summary' in 'struct ipa_opt_pass_d'). 40379 This stage writes all the pass-specific information generated 40380 by 'generate_summary'. Summaries go into their own 40381 'LTO_section_*' sections that have to be declared in 40382 'lto-streamer.h':'enum lto_section_type'. A new section is 40383 created by calling 'create_output_block' and data can be 40384 written using the 'lto_output_*' routines. 40385 40386 * WPA time 40387 1. _Read summary_ ('read_summary' in 'struct ipa_opt_pass_d'). 40388 This stage reads all the pass-specific information in exactly 40389 the same order that it was written by 'write_summary'. 40390 40391 2. _Execute_ ('execute' in 'struct opt_pass'). This performs 40392 inter-procedural propagation. This must be done without 40393 actual access to the individual function bodies or variable 40394 initializers. Typically, this results in a transitive closure 40395 operation over the summary information of all the nodes in the 40396 callgraph. 40397 40398 3. _Write optimization summary_ ('write_optimization_summary' in 40399 'struct ipa_opt_pass_d'). This writes the result of the 40400 inter-procedural propagation into the object file. This can 40401 use the same data structures and helper routines used in 40402 'write_summary'. 40403 40404 * LTRANS time 40405 1. _Read optimization summary_ ('read_optimization_summary' in 40406 'struct ipa_opt_pass_d'). The counterpart to 40407 'write_optimization_summary'. This reads the interprocedural 40408 optimization decisions in exactly the same format emitted by 40409 'write_optimization_summary'. 40410 40411 2. _Transform_ ('function_transform' and 'variable_transform' in 40412 'struct ipa_opt_pass_d'). The actual function bodies and 40413 variable initializers are updated based on the information 40414 passed down from the _Execute_ stage. 40415 40416 The implementation of the inter-procedural passes are shared between 40417LTO, WHOPR and classic non-LTO compilation. 40418 40419 * During the traditional file-by-file mode every pass executes its 40420 own _Generate summary_, _Execute_, and _Transform_ stages within 40421 the single execution context of the compiler. 40422 40423 * In LTO compilation mode, every pass uses _Generate summary_ and 40424 _Write summary_ stages at compilation time, while the _Read 40425 summary_, _Execute_, and _Transform_ stages are executed at link 40426 time. 40427 40428 * In WHOPR mode all stages are used. 40429 40430 To simplify development, the GCC pass manager differentiates between 40431normal inter-procedural passes and small inter-procedural passes. A 40432_small inter-procedural pass_ ('SIMPLE_IPA_PASS') is a pass that does 40433everything at once and thus it can not be executed during WPA in WHOPR 40434mode. It defines only the _Execute_ stage and during this stage it 40435accesses and modifies the function bodies. Such passes are useful for 40436optimization at LGEN or LTRANS time and are used, for example, to 40437implement early optimization before writing object files. The simple 40438inter-procedural passes can also be used for easier prototyping and 40439development of a new inter-procedural pass. 40440 4044124.3.1 Virtual clones 40442--------------------- 40443 40444One of the main challenges of introducing the WHOPR compilation mode was 40445addressing the interactions between optimization passes. In LTO 40446compilation mode, the passes are executed in a sequence, each of which 40447consists of analysis (or _Generate summary_), propagation (or _Execute_) 40448and _Transform_ stages. Once the work of one pass is finished, the next 40449pass sees the updated program representation and can execute. This 40450makes the individual passes dependent on each other. 40451 40452 In WHOPR mode all passes first execute their _Generate summary_ stage. 40453Then summary writing marks the end of the LGEN stage. At WPA time, the 40454summaries are read back into memory and all passes run the _Execute_ 40455stage. Optimization summaries are streamed and sent to LTRANS, where 40456all the passes execute the _Transform_ stage. 40457 40458 Most optimization passes split naturally into analysis, propagation and 40459transformation stages. But some do not. The main problem arises when 40460one pass performs changes and the following pass gets confused by seeing 40461different callgraphs between the _Transform_ stage and the _Generate 40462summary_ or _Execute_ stage. This means that the passes are required to 40463communicate their decisions with each other. 40464 40465 To facilitate this communication, the GCC callgraph infrastructure 40466implements _virtual clones_, a method of representing the changes 40467performed by the optimization passes in the callgraph without needing to 40468update function bodies. 40469 40470 A _virtual clone_ in the callgraph is a function that has no associated 40471body, just a description of how to create its body based on a different 40472function (which itself may be a virtual clone). 40473 40474 The description of function modifications includes adjustments to the 40475function's signature (which allows, for example, removing or adding 40476function arguments), substitutions to perform on the function body, and, 40477for inlined functions, a pointer to the function that it will be inlined 40478into. 40479 40480 It is also possible to redirect any edge of the callgraph from a 40481function to its virtual clone. This implies updating of the call site 40482to adjust for the new function signature. 40483 40484 Most of the transformations performed by inter-procedural optimizations 40485can be represented via virtual clones. For instance, a constant 40486propagation pass can produce a virtual clone of the function which 40487replaces one of its arguments by a constant. The inliner can represent 40488its decisions by producing a clone of a function whose body will be 40489later integrated into a given function. 40490 40491 Using _virtual clones_, the program can be easily updated during the 40492_Execute_ stage, solving most of pass interactions problems that would 40493otherwise occur during _Transform_. 40494 40495 Virtual clones are later materialized in the LTRANS stage and turned 40496into real functions. Passes executed after the virtual clone were 40497introduced also perform their _Transform_ stage on new functions, so for 40498a pass there is no significant difference between operating on a real 40499function or a virtual clone introduced before its _Execute_ stage. 40500 40501 Optimization passes then work on virtual clones introduced before their 40502_Execute_ stage as if they were real functions. The only difference is 40503that clones are not visible during the _Generate Summary_ stage. 40504 40505 To keep function summaries updated, the callgraph interface allows an 40506optimizer to register a callback that is called every time a new clone 40507is introduced as well as when the actual function or variable is 40508generated or when a function or variable is removed. These hooks are 40509registered in the _Generate summary_ stage and allow the pass to keep 40510its information intact until the _Execute_ stage. The same hooks can 40511also be registered during the _Execute_ stage to keep the optimization 40512summaries updated for the _Transform_ stage. 40513 4051424.3.2 IPA references 40515--------------------- 40516 40517GCC represents IPA references in the callgraph. For a function or 40518variable 'A', the _IPA reference_ is a list of all locations where the 40519address of 'A' is taken and, when 'A' is a variable, a list of all 40520direct stores and reads to/from 'A'. References represent an oriented 40521multi-graph on the union of nodes of the callgraph and the varpool. See 40522'ipa-reference.c':'ipa_reference_write_optimization_summary' and 40523'ipa-reference.c':'ipa_reference_read_optimization_summary' for details. 40524 4052524.3.3 Jump functions 40526--------------------- 40527 40528Suppose that an optimization pass sees a function 'A' and it knows the 40529values of (some of) its arguments. The _jump function_ describes the 40530value of a parameter of a given function call in function 'A' based on 40531this knowledge. 40532 40533 Jump functions are used by several optimizations, such as the 40534inter-procedural constant propagation pass and the devirtualization 40535pass. The inliner also uses jump functions to perform inlining of 40536callbacks. 40537 40538 40539File: gccint.info, Node: WHOPR, Next: Internal flags, Prev: IPA, Up: LTO 40540 4054124.4 Whole program assumptions, linker plugin and symbol visibilities 40542===================================================================== 40543 40544Link-time optimization gives relatively minor benefits when used alone. 40545The problem is that propagation of inter-procedural information does not 40546work well across functions and variables that are called or referenced 40547by other compilation units (such as from a dynamically linked library). 40548We say that such functions and variables are _externally visible_. 40549 40550 To make the situation even more difficult, many applications organize 40551themselves as a set of shared libraries, and the default ELF visibility 40552rules allow one to overwrite any externally visible symbol with a 40553different symbol at runtime. This basically disables any optimizations 40554across such functions and variables, because the compiler cannot be sure 40555that the function body it is seeing is the same function body that will 40556be used at runtime. Any function or variable not declared 'static' in 40557the sources degrades the quality of inter-procedural optimization. 40558 40559 To avoid this problem the compiler must assume that it sees the whole 40560program when doing link-time optimization. Strictly speaking, the whole 40561program is rarely visible even at link-time. Standard system libraries 40562are usually linked dynamically or not provided with the link-time 40563information. In GCC, the whole program option ('-fwhole-program') 40564asserts that every function and variable defined in the current 40565compilation unit is static, except for function 'main' (note: at link 40566time, the current unit is the union of all objects compiled with LTO). 40567Since some functions and variables need to be referenced externally, for 40568example by another DSO or from an assembler file, GCC also provides the 40569function and variable attribute 'externally_visible' which can be used 40570to disable the effect of '-fwhole-program' on a specific symbol. 40571 40572 The whole program mode assumptions are slightly more complex in C++, 40573where inline functions in headers are put into _COMDAT_ sections. 40574COMDAT function and variables can be defined by multiple object files 40575and their bodies are unified at link-time and dynamic link-time. COMDAT 40576functions are changed to local only when their address is not taken and 40577thus un-sharing them with a library is not harmful. COMDAT variables 40578always remain externally visible, however for readonly variables it is 40579assumed that their initializers cannot be overwritten by a different 40580value. 40581 40582 GCC provides the function and variable attribute 'visibility' that can 40583be used to specify the visibility of externally visible symbols (or 40584alternatively an '-fdefault-visibility' command line option). ELF 40585defines the 'default', 'protected', 'hidden' and 'internal' 40586visibilities. 40587 40588 The most commonly used is visibility is 'hidden'. It specifies that 40589the symbol cannot be referenced from outside of the current shared 40590library. Unfortunately, this information cannot be used directly by the 40591link-time optimization in the compiler since the whole shared library 40592also might contain non-LTO objects and those are not visible to the 40593compiler. 40594 40595 GCC solves this problem using linker plugins. A _linker plugin_ is an 40596interface to the linker that allows an external program to claim the 40597ownership of a given object file. The linker then performs the linking 40598procedure by querying the plugin about the symbol table of the claimed 40599objects and once the linking decisions are complete, the plugin is 40600allowed to provide the final object file before the actual linking is 40601made. The linker plugin obtains the symbol resolution information which 40602specifies which symbols provided by the claimed objects are bound from 40603the rest of a binary being linked. 40604 40605 Currently, the linker plugin works only in combination with the Gold 40606linker, but a GNU ld implementation is under development. 40607 40608 GCC is designed to be independent of the rest of the toolchain and aims 40609to support linkers without plugin support. For this reason it does not 40610use the linker plugin by default. Instead, the object files are 40611examined by 'collect2' before being passed to the linker and objects 40612found to have LTO sections are passed to 'lto1' first. This mode does 40613not work for library archives. The decision on what object files from 40614the archive are needed depends on the actual linking and thus GCC would 40615have to implement the linker itself. The resolution information is 40616missing too and thus GCC needs to make an educated guess based on 40617'-fwhole-program'. Without the linker plugin GCC also assumes that 40618symbols are declared 'hidden' and not referred by non-LTO code by 40619default. 40620 40621 40622File: gccint.info, Node: Internal flags, Prev: WHOPR, Up: LTO 40623 4062424.5 Internal flags controlling 'lto1' 40625====================================== 40626 40627The following flags are passed into 'lto1' and are not meant to be used 40628directly from the command line. 40629 40630 * -fwpa This option runs the serial part of the link-time optimizer 40631 performing the inter-procedural propagation (WPA mode). The 40632 compiler reads in summary information from all inputs and performs 40633 an analysis based on summary information only. It generates object 40634 files for subsequent runs of the link-time optimizer where 40635 individual object files are optimized using both summary 40636 information from the WPA mode and the actual function bodies. It 40637 then drives the LTRANS phase. 40638 40639 * -fltrans This option runs the link-time optimizer in the 40640 local-transformation (LTRANS) mode, which reads in output from a 40641 previous run of the LTO in WPA mode. In the LTRANS mode, LTO 40642 optimizes an object and produces the final assembly. 40643 40644 * -fltrans-output-list=FILE This option specifies a file to which the 40645 names of LTRANS output files are written. This option is only 40646 meaningful in conjunction with '-fwpa'. 40647 40648 * -fresolution=FILE This option specifies the linker resolution file. 40649 This option is only meaningful in conjunction with '-fwpa' and as 40650 option to pass through to the LTO linker plugin. 40651 40652 40653File: gccint.info, Node: Match and Simplify, Next: Funding, Prev: LTO, Up: Top 40654 4065525 Match and Simplify 40656********************* 40657 40658The GIMPLE and GENERIC pattern matching project match-and-simplify tries 40659to address several issues. 40660 40661 1. unify expression simplifications currently spread and duplicated 40662 over separate files like fold-const.c, gimple-fold.c and builtins.c 40663 2. allow for a cheap way to implement building and simplifying 40664 non-trivial GIMPLE expressions, avoiding the need to go through 40665 building and simplifying GENERIC via fold_buildN and then 40666 gimplifying via force_gimple_operand 40667 40668 To address these the project introduces a simple domain specific 40669language to write expression simplifications from which code targeting 40670GIMPLE and GENERIC is auto-generated. The GENERIC variant follows the 40671fold_buildN API while for the GIMPLE variant and to address 2) new APIs 40672are introduced. 40673 40674* Menu: 40675 40676* GIMPLE API:: 40677* The Language:: 40678 40679 40680File: gccint.info, Node: GIMPLE API, Next: The Language, Up: Match and Simplify 40681 4068225.1 GIMPLE API 40683=============== 40684 40685 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 40686 gimple_seq *, tree (*)(tree)) 40687 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 40688 tree, gimple_seq *, tree (*)(tree)) 40689 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 40690 tree, tree, gimple_seq *, tree (*)(tree)) 40691 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 40692 tree, gimple_seq *, tree (*)(tree)) 40693 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 40694 tree, tree, gimple_seq *, tree (*)(tree)) 40695 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 40696 tree, tree, gimple_seq *, tree (*)(tree)) 40697 The main GIMPLE API entry to the expression simplifications 40698 mimicing that of the GENERIC fold_{unary,binary,ternary} functions. 40699 40700 thus providing n-ary overloads for operation or function. The 40701additional arguments are a gimple_seq where built statements are 40702inserted on (if 'NULL' then simplifications requiring new statements are 40703not performed) and a valueization hook that can be used to tie 40704simplifications to a SSA lattice. 40705 40706 In addition to those APIs 'fold_stmt' is overloaded with a valueization 40707hook: 40708 40709 -- bool: fold_stmt (gimple_stmt_iterator *, tree (*)(tree)); 40710 40711 Ontop of these a 'fold_buildN'-like API for GIMPLE is introduced: 40712 40713 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 40714 tree_code, tree, tree, tree (*valueize) (tree) = NULL); 40715 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 40716 tree_code, tree, tree, tree, tree (*valueize) (tree) = NULL); 40717 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 40718 tree_code, tree, tree, tree, tree, tree (*valueize) (tree) = 40719 NULL); 40720 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 40721 built_in_function, tree, tree, tree (*valueize) (tree) = 40722 NULL); 40723 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 40724 built_in_function, tree, tree, tree, tree (*valueize) (tree) = 40725 NULL); 40726 -- GIMPLE function: tree gimple_convert (gimple_seq *, location_t, 40727 tree, tree); 40728 40729 which is supposed to replace 'force_gimple_operand (fold_buildN (...), 40730...)' and calls to 'fold_convert'. Overloads without the 'location_t' 40731argument exist. Built statements are inserted on the provided sequence 40732and simplification is performed using the optional valueization hook. 40733 40734 40735File: gccint.info, Node: The Language, Prev: GIMPLE API, Up: Match and Simplify 40736 4073725.2 The Language 40738================= 40739 40740The language to write expression simplifications in resembles other 40741domain-specific languages GCC uses. Thus it is lispy. Lets start with 40742an example from the match.pd file: 40743 40744 (simplify 40745 (bit_and @0 integer_all_onesp) 40746 @0) 40747 40748 This example contains all required parts of an expression 40749simplification. A simplification is wrapped inside a '(simplify ...)' 40750expression. That contains at least two operands - an expression that is 40751matched with the GIMPLE or GENERIC IL and a replacement expression that 40752is returned if the match was successful. 40753 40754 Expressions have an operator ID, 'bit_and' in this case. Expressions 40755can be lower-case tree codes with '_expr' stripped off or builtin 40756function code names in all-caps, like 'BUILT_IN_SQRT'. 40757 40758 '@n' denotes a so-called capture. It captures the operand and lets you 40759refer to it in other places of the match-and-simplify. In the above 40760example it is refered to in the replacement expression. Captures are 40761'@' followed by a number or an identifier. 40762 40763 (simplify 40764 (bit_xor @0 @0) 40765 { build_zero_cst (type); }) 40766 40767 In this example '@0' is mentioned twice which constrains the matched 40768expression to have two equal operands. This example also introduces 40769operands written in C code. These can be used in the expression 40770replacements and are supposed to evaluate to a tree node which has to be 40771a valid GIMPLE operand (so you cannot generate expressions in C code). 40772 40773 (simplify 40774 (trunc_mod integer_zerop@0 @1) 40775 (if (!integer_zerop (@1))) 40776 @0) 40777 40778 Here '@0' captures the first operand of the trunc_mod expression which 40779is also predicated with 'integer_zerop'. Expression operands may be 40780either expressions, predicates or captures. Captures can be 40781unconstrained or capture expresions or predicates. 40782 40783 This example introduces an optional operand of simplify, the 40784if-expression. This condition is evaluated after the expression matched 40785in the IL and is required to evaluate to true to enable the replacement 40786expression. The expression operand of the 'if' is a standard C 40787expression which may contain references to captures. 40788 40789 A 'if' expression can be used to specify a common condition for 40790multiple simplify patterns, avoiding the need to repeat that multiple 40791times: 40792 40793 (if (!TYPE_SATURATING (type) 40794 && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) 40795 (simplify 40796 (minus (plus @0 @1) @0) 40797 @1) 40798 (simplify 40799 (minus (minus @0 @1) @0) 40800 (negate @1))) 40801 40802 Ifs can be nested. 40803 40804 Captures can also be used for capturing results of sub-expressions. 40805 40806 #if GIMPLE 40807 (simplify 40808 (pointer_plus (addr@2 @0) INTEGER_CST_P@1) 40809 (if (is_gimple_min_invariant (@2))) 40810 { 40811 HOST_WIDE_INT off; 40812 tree base = get_addr_base_and_unit_offset (@0, &off); 40813 off += tree_to_uhwi (@1); 40814 /* Now with that we should be able to simply write 40815 (addr (mem_ref (addr @base) (plus @off @1))) */ 40816 build1 (ADDR_EXPR, type, 40817 build2 (MEM_REF, TREE_TYPE (TREE_TYPE (@2)), 40818 build_fold_addr_expr (base), 40819 build_int_cst (ptr_type_node, off))); 40820 }) 40821 #endif 40822 40823 In the above example, '@2' captures the result of the expression '(addr 40824@0)'. For outermost expression only its type can be captured, and the 40825keyword 'type' is reserved for this purpose. The above example also 40826gives a way to conditionalize patterns to only apply to 'GIMPLE' or 40827'GENERIC' by means of using the pre-defined preprocessor macros 'GIMPLE' 40828and 'GENERIC' and using preprocessor directives. 40829 40830 (simplify 40831 (bit_and:c integral_op_p@0 (bit_ior:c (bit_not @0) @1)) 40832 (bit_and @1 @0)) 40833 40834 Here we introduce flags on match expressions. There is currently a 40835single flag, 'c', which denotes that the expression should be also 40836matched commutated. Thus the above match expression is really the 40837following four match expressions: 40838 40839 (bit_and integral_op_p@0 (bit_ior (bit_not @0) @1)) (bit_and (bit_ior 40840(bit_not @0) @1) integral_op_p@0) (bit_and integral_op_p@0 (bit_ior @1 40841(bit_not @0))) (bit_and (bit_ior @1 (bit_not @0)) integral_op_p@0) 40842 40843 Usual canonicalizations you know from GENERIC expressions are applied 40844before matching, so for example constant operands always come second in 40845commutative expressions. 40846 40847 More features exist to avoid too much repetition. 40848 40849 (for op (plus pointer_plus minus bit_ior bit_xor) 40850 (simplify 40851 (op @0 integer_zerop) 40852 @0)) 40853 40854 A 'for' expression can be used to repeat a pattern for each operator 40855specified, substituting 'op'. 'for' can be nested and a 'for' can have 40856multiple operators to iterate. 40857 40858 (for opa (plus minus) 40859 opb (minus plus) 40860 (for opc (plus minus) 40861 (simplify... 40862 40863 In this example the pattern will be repeated four times with 'opa, opb, 40864opc' being 'plus, minus, plus', 'plus, minus, minus', 'minus, plus, 40865plus', 'minus, plus, minus'. 40866 40867 To avoid repeating operator lists in 'for' you can name them via 40868 40869 (define_operator_list pmm plus minus mult) 40870 40871 and use them in 'for' operator lists where they get expanded. 40872 40873 (for opa (pmm trunc_div) 40874 (simplify... 40875 40876 So this example iterates over 'plus', 'minus', 'mult' and 'trunc_div'. 40877 40878 Using operator lists can also remove the need to explicitely write a 40879'for'. All operator list uses that appear in a 'simplify' or 'match' 40880pattern in operator positions will implicitely be added to a new 'for'. 40881For example 40882 40883 (define_operator_list SQRT BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 40884 (define_operator_list POW BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 40885 (simplify 40886 (SQRT (POW @0 @1)) 40887 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); }))) 40888 40889 is the same as 40890 40891 (for SQRT (BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 40892 POW (BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 40893 (simplify 40894 (SQRT (POW @0 @1)) 40895 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); })))) 40896 40897 Another building block are 'with' expressions in the result expression 40898which nest the generated code in a new C block followed by its argument: 40899 40900 (simplify 40901 (convert (mult @0 @1)) 40902 (with { tree utype = unsigned_type_for (type); } 40903 (convert (mult (convert:utype @0) (convert:utype @1))))) 40904 40905 This allows code nested in the 'with' to refer to the declared 40906variables. In the above case we use the feature to specify the type of 40907a generated expression with the ':type' syntax where 'type' needs to be 40908an identifier that refers to the desired type. Usually the types of the 40909generated result expressions are determined from the context, but 40910sometimes like in the above case it is required that you specify them 40911explicitely. 40912 40913 As intermediate conversions are often optional there is a way to avoid 40914the need to repeat patterns both with and without such conversions. 40915Namely you can mark a conversion as being optional with a '?': 40916 40917 (simplify 40918 (eq (convert@0 @1) (convert? @2)) 40919 (eq @1 (convert @2))) 40920 40921 which will match both '(eq (convert @1) (convert @2))' and '(eq 40922(convert @1) @2)'. The optional converts are supposed to be all either 40923present or not, thus '(eq (convert? @1) (convert? @2))' will result in 40924two patterns only. If you want to match all four combinations you have 40925access to two additional conditional converts as in '(eq (convert1? @1) 40926(convert2? @2))'. 40927 40928 Predicates available from the GCC middle-end need to be made available 40929explicitely via 'define_predicates': 40930 40931 (define_predicates 40932 integer_onep integer_zerop integer_all_onesp) 40933 40934 You can also define predicates using the pattern matching language and 40935the 'match' form: 40936 40937 (match negate_expr_p 40938 INTEGER_CST 40939 (if (TYPE_OVERFLOW_WRAPS (type) 40940 || may_negate_without_overflow_p (t)))) 40941 (match negate_expr_p 40942 (negate @0)) 40943 40944 This shows that for 'match' expressions there is 't' available which 40945captures the outermost expression (something not possible in the 40946'simplify' context). As you can see 'match' has an identifier as first 40947operand which is how you refer to the predicate in patterns. Multiple 40948'match' for the same identifier add additional cases where the predicate 40949matches. 40950 40951 Predicates can also match an expression in which case you need to 40952provide a template specifying the identifier and where to get its 40953operands from: 40954 40955 (match (logical_inverted_value @0) 40956 (eq @0 integer_zerop)) 40957 (match (logical_inverted_value @0) 40958 (bit_not truth_valued_p@0)) 40959 40960 You can use the above predicate like 40961 40962 (simplify 40963 (bit_and @0 (logical_inverted_value @0)) 40964 { build_zero_cst (type); }) 40965 40966 Which will match a bitwise and of an operand with its logical inverted 40967value. 40968 40969 40970File: gccint.info, Node: Funding, Next: GNU Project, Prev: Match and Simplify, Up: Top 40971 40972Funding Free Software 40973********************* 40974 40975If you want to have more free software a few years from now, it makes 40976sense for you to help encourage people to contribute funds for its 40977development. The most effective approach known is to encourage 40978commercial redistributors to donate. 40979 40980 Users of free software systems can boost the pace of development by 40981encouraging for-a-fee distributors to donate part of their selling price 40982to free software developers--the Free Software Foundation, and others. 40983 40984 The way to convince distributors to do this is to demand it and expect 40985it from them. So when you compare distributors, judge them partly by 40986how much they give to free software development. Show distributors they 40987must compete to be the one who gives the most. 40988 40989 To make this approach work, you must insist on numbers that you can 40990compare, such as, "We will donate ten dollars to the Frobnitz project 40991for each disk sold." Don't be satisfied with a vague promise, such as 40992"A portion of the profits are donated," since it doesn't give a basis 40993for comparison. 40994 40995 Even a precise fraction "of the profits from this disk" is not very 40996meaningful, since creative accounting and unrelated business decisions 40997can greatly alter what fraction of the sales price counts as profit. If 40998the price you pay is $50, ten percent of the profit is probably less 40999than a dollar; it might be a few cents, or nothing at all. 41000 41001 Some redistributors do development work themselves. This is useful 41002too; but to keep everyone honest, you need to inquire how much they do, 41003and what kind. Some kinds of development make much more long-term 41004difference than others. For example, maintaining a separate version of 41005a program contributes very little; maintaining the standard version of a 41006program for the whole community contributes much. Easy new ports 41007contribute little, since someone else would surely do them; difficult 41008ports such as adding a new CPU to the GNU Compiler Collection contribute 41009more; major new features or packages contribute the most. 41010 41011 By establishing the idea that supporting further development is "the 41012proper thing to do" when distributing free software for a fee, we can 41013assure a steady flow of resources into making more free software. 41014 41015 Copyright (C) 1994 Free Software Foundation, Inc. 41016 Verbatim copying and redistribution of this section is permitted 41017 without royalty; alteration is not permitted. 41018 41019 41020File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 41021 41022The GNU Project and GNU/Linux 41023***************************** 41024 41025The GNU Project was launched in 1984 to develop a complete Unix-like 41026operating system which is free software: the GNU system. (GNU is a 41027recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 41028Variants of the GNU operating system, which use the kernel Linux, are 41029now widely used; though these systems are often referred to as "Linux", 41030they are more accurately called GNU/Linux systems. 41031 41032 For more information, see: 41033 <http://www.gnu.org/> 41034 <http://www.gnu.org/gnu/linux-and-gnu.html> 41035 41036 41037File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 41038 41039GNU General Public License 41040************************** 41041 41042 Version 3, 29 June 2007 41043 41044 Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> 41045 41046 Everyone is permitted to copy and distribute verbatim copies of this 41047 license document, but changing it is not allowed. 41048 41049Preamble 41050======== 41051 41052The GNU General Public License is a free, copyleft license for software 41053and other kinds of works. 41054 41055 The licenses for most software and other practical works are designed 41056to take away your freedom to share and change the works. By contrast, 41057the GNU General Public License is intended to guarantee your freedom to 41058share and change all versions of a program-to make sure it remains free 41059software for all its users. We, the Free Software Foundation, use the 41060GNU General Public License for most of our software; it applies also to 41061any other work released this way by its authors. You can apply it to 41062your programs, too. 41063 41064 When we speak of free software, we are referring to freedom, not price. 41065Our General Public Licenses are designed to make sure that you have the 41066freedom to distribute copies of free software (and charge for them if 41067you wish), that you receive source code or can get it if you want it, 41068that you can change the software or use pieces of it in new free 41069programs, and that you know you can do these things. 41070 41071 To protect your rights, we need to prevent others from denying you 41072these rights or asking you to surrender the rights. Therefore, you have 41073certain responsibilities if you distribute copies of the software, or if 41074you modify it: responsibilities to respect the freedom of others. 41075 41076 For example, if you distribute copies of such a program, whether gratis 41077or for a fee, you must pass on to the recipients the same freedoms that 41078you received. You must make sure that they, too, receive or can get the 41079source code. And you must show them these terms so they know their 41080rights. 41081 41082 Developers that use the GNU GPL protect your rights with two steps: (1) 41083assert copyright on the software, and (2) offer you this License giving 41084you legal permission to copy, distribute and/or modify it. 41085 41086 For the developers' and authors' protection, the GPL clearly explains 41087that there is no warranty for this free software. For both users' and 41088authors' sake, the GPL requires that modified versions be marked as 41089changed, so that their problems will not be attributed erroneously to 41090authors of previous versions. 41091 41092 Some devices are designed to deny users access to install or run 41093modified versions of the software inside them, although the manufacturer 41094can do so. This is fundamentally incompatible with the aim of 41095protecting users' freedom to change the software. The systematic 41096pattern of such abuse occurs in the area of products for individuals to 41097use, which is precisely where it is most unacceptable. Therefore, we 41098have designed this version of the GPL to prohibit the practice for those 41099products. If such problems arise substantially in other domains, we 41100stand ready to extend this provision to those domains in future versions 41101of the GPL, as needed to protect the freedom of users. 41102 41103 Finally, every program is threatened constantly by software patents. 41104States should not allow patents to restrict development and use of 41105software on general-purpose computers, but in those that do, we wish to 41106avoid the special danger that patents applied to a free program could 41107make it effectively proprietary. To prevent this, the GPL assures that 41108patents cannot be used to render the program non-free. 41109 41110 The precise terms and conditions for copying, distribution and 41111modification follow. 41112 41113TERMS AND CONDITIONS 41114==================== 41115 41116 0. Definitions. 41117 41118 "This License" refers to version 3 of the GNU General Public 41119 License. 41120 41121 "Copyright" also means copyright-like laws that apply to other 41122 kinds of works, such as semiconductor masks. 41123 41124 "The Program" refers to any copyrightable work licensed under this 41125 License. Each licensee is addressed as "you". "Licensees" and 41126 "recipients" may be individuals or organizations. 41127 41128 To "modify" a work means to copy from or adapt all or part of the 41129 work in a fashion requiring copyright permission, other than the 41130 making of an exact copy. The resulting work is called a "modified 41131 version" of the earlier work or a work "based on" the earlier work. 41132 41133 A "covered work" means either the unmodified Program or a work 41134 based on the Program. 41135 41136 To "propagate" a work means to do anything with it that, without 41137 permission, would make you directly or secondarily liable for 41138 infringement under applicable copyright law, except executing it on 41139 a computer or modifying a private copy. Propagation includes 41140 copying, distribution (with or without modification), making 41141 available to the public, and in some countries other activities as 41142 well. 41143 41144 To "convey" a work means any kind of propagation that enables other 41145 parties to make or receive copies. Mere interaction with a user 41146 through a computer network, with no transfer of a copy, is not 41147 conveying. 41148 41149 An interactive user interface displays "Appropriate Legal Notices" 41150 to the extent that it includes a convenient and prominently visible 41151 feature that (1) displays an appropriate copyright notice, and (2) 41152 tells the user that there is no warranty for the work (except to 41153 the extent that warranties are provided), that licensees may convey 41154 the work under this License, and how to view a copy of this 41155 License. If the interface presents a list of user commands or 41156 options, such as a menu, a prominent item in the list meets this 41157 criterion. 41158 41159 1. Source Code. 41160 41161 The "source code" for a work means the preferred form of the work 41162 for making modifications to it. "Object code" means any non-source 41163 form of a work. 41164 41165 A "Standard Interface" means an interface that either is an 41166 official standard defined by a recognized standards body, or, in 41167 the case of interfaces specified for a particular programming 41168 language, one that is widely used among developers working in that 41169 language. 41170 41171 The "System Libraries" of an executable work include anything, 41172 other than the work as a whole, that (a) is included in the normal 41173 form of packaging a Major Component, but which is not part of that 41174 Major Component, and (b) serves only to enable use of the work with 41175 that Major Component, or to implement a Standard Interface for 41176 which an implementation is available to the public in source code 41177 form. A "Major Component", in this context, means a major 41178 essential component (kernel, window system, and so on) of the 41179 specific operating system (if any) on which the executable work 41180 runs, or a compiler used to produce the work, or an object code 41181 interpreter used to run it. 41182 41183 The "Corresponding Source" for a work in object code form means all 41184 the source code needed to generate, install, and (for an executable 41185 work) run the object code and to modify the work, including scripts 41186 to control those activities. However, it does not include the 41187 work's System Libraries, or general-purpose tools or generally 41188 available free programs which are used unmodified in performing 41189 those activities but which are not part of the work. For example, 41190 Corresponding Source includes interface definition files associated 41191 with source files for the work, and the source code for shared 41192 libraries and dynamically linked subprograms that the work is 41193 specifically designed to require, such as by intimate data 41194 communication or control flow between those subprograms and other 41195 parts of the work. 41196 41197 The Corresponding Source need not include anything that users can 41198 regenerate automatically from other parts of the Corresponding 41199 Source. 41200 41201 The Corresponding Source for a work in source code form is that 41202 same work. 41203 41204 2. Basic Permissions. 41205 41206 All rights granted under this License are granted for the term of 41207 copyright on the Program, and are irrevocable provided the stated 41208 conditions are met. This License explicitly affirms your unlimited 41209 permission to run the unmodified Program. The output from running 41210 a covered work is covered by this License only if the output, given 41211 its content, constitutes a covered work. This License acknowledges 41212 your rights of fair use or other equivalent, as provided by 41213 copyright law. 41214 41215 You may make, run and propagate covered works that you do not 41216 convey, without conditions so long as your license otherwise 41217 remains in force. You may convey covered works to others for the 41218 sole purpose of having them make modifications exclusively for you, 41219 or provide you with facilities for running those works, provided 41220 that you comply with the terms of this License in conveying all 41221 material for which you do not control copyright. Those thus making 41222 or running the covered works for you must do so exclusively on your 41223 behalf, under your direction and control, on terms that prohibit 41224 them from making any copies of your copyrighted material outside 41225 their relationship with you. 41226 41227 Conveying under any other circumstances is permitted solely under 41228 the conditions stated below. Sublicensing is not allowed; section 41229 10 makes it unnecessary. 41230 41231 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 41232 41233 No covered work shall be deemed part of an effective technological 41234 measure under any applicable law fulfilling obligations under 41235 article 11 of the WIPO copyright treaty adopted on 20 December 41236 1996, or similar laws prohibiting or restricting circumvention of 41237 such measures. 41238 41239 When you convey a covered work, you waive any legal power to forbid 41240 circumvention of technological measures to the extent such 41241 circumvention is effected by exercising rights under this License 41242 with respect to the covered work, and you disclaim any intention to 41243 limit operation or modification of the work as a means of 41244 enforcing, against the work's users, your or third parties' legal 41245 rights to forbid circumvention of technological measures. 41246 41247 4. Conveying Verbatim Copies. 41248 41249 You may convey verbatim copies of the Program's source code as you 41250 receive it, in any medium, provided that you conspicuously and 41251 appropriately publish on each copy an appropriate copyright notice; 41252 keep intact all notices stating that this License and any 41253 non-permissive terms added in accord with section 7 apply to the 41254 code; keep intact all notices of the absence of any warranty; and 41255 give all recipients a copy of this License along with the Program. 41256 41257 You may charge any price or no price for each copy that you convey, 41258 and you may offer support or warranty protection for a fee. 41259 41260 5. Conveying Modified Source Versions. 41261 41262 You may convey a work based on the Program, or the modifications to 41263 produce it from the Program, in the form of source code under the 41264 terms of section 4, provided that you also meet all of these 41265 conditions: 41266 41267 a. The work must carry prominent notices stating that you 41268 modified it, and giving a relevant date. 41269 41270 b. The work must carry prominent notices stating that it is 41271 released under this License and any conditions added under 41272 section 7. This requirement modifies the requirement in 41273 section 4 to "keep intact all notices". 41274 41275 c. You must license the entire work, as a whole, under this 41276 License to anyone who comes into possession of a copy. This 41277 License will therefore apply, along with any applicable 41278 section 7 additional terms, to the whole of the work, and all 41279 its parts, regardless of how they are packaged. This License 41280 gives no permission to license the work in any other way, but 41281 it does not invalidate such permission if you have separately 41282 received it. 41283 41284 d. If the work has interactive user interfaces, each must display 41285 Appropriate Legal Notices; however, if the Program has 41286 interactive interfaces that do not display Appropriate Legal 41287 Notices, your work need not make them do so. 41288 41289 A compilation of a covered work with other separate and independent 41290 works, which are not by their nature extensions of the covered 41291 work, and which are not combined with it such as to form a larger 41292 program, in or on a volume of a storage or distribution medium, is 41293 called an "aggregate" if the compilation and its resulting 41294 copyright are not used to limit the access or legal rights of the 41295 compilation's users beyond what the individual works permit. 41296 Inclusion of a covered work in an aggregate does not cause this 41297 License to apply to the other parts of the aggregate. 41298 41299 6. Conveying Non-Source Forms. 41300 41301 You may convey a covered work in object code form under the terms 41302 of sections 4 and 5, provided that you also convey the 41303 machine-readable Corresponding Source under the terms of this 41304 License, in one of these ways: 41305 41306 a. Convey the object code in, or embodied in, a physical product 41307 (including a physical distribution medium), accompanied by the 41308 Corresponding Source fixed on a durable physical medium 41309 customarily used for software interchange. 41310 41311 b. Convey the object code in, or embodied in, a physical product 41312 (including a physical distribution medium), accompanied by a 41313 written offer, valid for at least three years and valid for as 41314 long as you offer spare parts or customer support for that 41315 product model, to give anyone who possesses the object code 41316 either (1) a copy of the Corresponding Source for all the 41317 software in the product that is covered by this License, on a 41318 durable physical medium customarily used for software 41319 interchange, for a price no more than your reasonable cost of 41320 physically performing this conveying of source, or (2) access 41321 to copy the Corresponding Source from a network server at no 41322 charge. 41323 41324 c. Convey individual copies of the object code with a copy of the 41325 written offer to provide the Corresponding Source. This 41326 alternative is allowed only occasionally and noncommercially, 41327 and only if you received the object code with such an offer, 41328 in accord with subsection 6b. 41329 41330 d. Convey the object code by offering access from a designated 41331 place (gratis or for a charge), and offer equivalent access to 41332 the Corresponding Source in the same way through the same 41333 place at no further charge. You need not require recipients 41334 to copy the Corresponding Source along with the object code. 41335 If the place to copy the object code is a network server, the 41336 Corresponding Source may be on a different server (operated by 41337 you or a third party) that supports equivalent copying 41338 facilities, provided you maintain clear directions next to the 41339 object code saying where to find the Corresponding Source. 41340 Regardless of what server hosts the Corresponding Source, you 41341 remain obligated to ensure that it is available for as long as 41342 needed to satisfy these requirements. 41343 41344 e. Convey the object code using peer-to-peer transmission, 41345 provided you inform other peers where the object code and 41346 Corresponding Source of the work are being offered to the 41347 general public at no charge under subsection 6d. 41348 41349 A separable portion of the object code, whose source code is 41350 excluded from the Corresponding Source as a System Library, need 41351 not be included in conveying the object code work. 41352 41353 A "User Product" is either (1) a "consumer product", which means 41354 any tangible personal property which is normally used for personal, 41355 family, or household purposes, or (2) anything designed or sold for 41356 incorporation into a dwelling. In determining whether a product is 41357 a consumer product, doubtful cases shall be resolved in favor of 41358 coverage. For a particular product received by a particular user, 41359 "normally used" refers to a typical or common use of that class of 41360 product, regardless of the status of the particular user or of the 41361 way in which the particular user actually uses, or expects or is 41362 expected to use, the product. A product is a consumer product 41363 regardless of whether the product has substantial commercial, 41364 industrial or non-consumer uses, unless such uses represent the 41365 only significant mode of use of the product. 41366 41367 "Installation Information" for a User Product means any methods, 41368 procedures, authorization keys, or other information required to 41369 install and execute modified versions of a covered work in that 41370 User Product from a modified version of its Corresponding Source. 41371 The information must suffice to ensure that the continued 41372 functioning of the modified object code is in no case prevented or 41373 interfered with solely because modification has been made. 41374 41375 If you convey an object code work under this section in, or with, 41376 or specifically for use in, a User Product, and the conveying 41377 occurs as part of a transaction in which the right of possession 41378 and use of the User Product is transferred to the recipient in 41379 perpetuity or for a fixed term (regardless of how the transaction 41380 is characterized), the Corresponding Source conveyed under this 41381 section must be accompanied by the Installation Information. But 41382 this requirement does not apply if neither you nor any third party 41383 retains the ability to install modified object code on the User 41384 Product (for example, the work has been installed in ROM). 41385 41386 The requirement to provide Installation Information does not 41387 include a requirement to continue to provide support service, 41388 warranty, or updates for a work that has been modified or installed 41389 by the recipient, or for the User Product in which it has been 41390 modified or installed. Access to a network may be denied when the 41391 modification itself materially and adversely affects the operation 41392 of the network or violates the rules and protocols for 41393 communication across the network. 41394 41395 Corresponding Source conveyed, and Installation Information 41396 provided, in accord with this section must be in a format that is 41397 publicly documented (and with an implementation available to the 41398 public in source code form), and must require no special password 41399 or key for unpacking, reading or copying. 41400 41401 7. Additional Terms. 41402 41403 "Additional permissions" are terms that supplement the terms of 41404 this License by making exceptions from one or more of its 41405 conditions. Additional permissions that are applicable to the 41406 entire Program shall be treated as though they were included in 41407 this License, to the extent that they are valid under applicable 41408 law. If additional permissions apply only to part of the Program, 41409 that part may be used separately under those permissions, but the 41410 entire Program remains governed by this License without regard to 41411 the additional permissions. 41412 41413 When you convey a copy of a covered work, you may at your option 41414 remove any additional permissions from that copy, or from any part 41415 of it. (Additional permissions may be written to require their own 41416 removal in certain cases when you modify the work.) You may place 41417 additional permissions on material, added by you to a covered work, 41418 for which you have or can give appropriate copyright permission. 41419 41420 Notwithstanding any other provision of this License, for material 41421 you add to a covered work, you may (if authorized by the copyright 41422 holders of that material) supplement the terms of this License with 41423 terms: 41424 41425 a. Disclaiming warranty or limiting liability differently from 41426 the terms of sections 15 and 16 of this License; or 41427 41428 b. Requiring preservation of specified reasonable legal notices 41429 or author attributions in that material or in the Appropriate 41430 Legal Notices displayed by works containing it; or 41431 41432 c. Prohibiting misrepresentation of the origin of that material, 41433 or requiring that modified versions of such material be marked 41434 in reasonable ways as different from the original version; or 41435 41436 d. Limiting the use for publicity purposes of names of licensors 41437 or authors of the material; or 41438 41439 e. Declining to grant rights under trademark law for use of some 41440 trade names, trademarks, or service marks; or 41441 41442 f. Requiring indemnification of licensors and authors of that 41443 material by anyone who conveys the material (or modified 41444 versions of it) with contractual assumptions of liability to 41445 the recipient, for any liability that these contractual 41446 assumptions directly impose on those licensors and authors. 41447 41448 All other non-permissive additional terms are considered "further 41449 restrictions" within the meaning of section 10. If the Program as 41450 you received it, or any part of it, contains a notice stating that 41451 it is governed by this License along with a term that is a further 41452 restriction, you may remove that term. If a license document 41453 contains a further restriction but permits relicensing or conveying 41454 under this License, you may add to a covered work material governed 41455 by the terms of that license document, provided that the further 41456 restriction does not survive such relicensing or conveying. 41457 41458 If you add terms to a covered work in accord with this section, you 41459 must place, in the relevant source files, a statement of the 41460 additional terms that apply to those files, or a notice indicating 41461 where to find the applicable terms. 41462 41463 Additional terms, permissive or non-permissive, may be stated in 41464 the form of a separately written license, or stated as exceptions; 41465 the above requirements apply either way. 41466 41467 8. Termination. 41468 41469 You may not propagate or modify a covered work except as expressly 41470 provided under this License. Any attempt otherwise to propagate or 41471 modify it is void, and will automatically terminate your rights 41472 under this License (including any patent licenses granted under the 41473 third paragraph of section 11). 41474 41475 However, if you cease all violation of this License, then your 41476 license from a particular copyright holder is reinstated (a) 41477 provisionally, unless and until the copyright holder explicitly and 41478 finally terminates your license, and (b) permanently, if the 41479 copyright holder fails to notify you of the violation by some 41480 reasonable means prior to 60 days after the cessation. 41481 41482 Moreover, your license from a particular copyright holder is 41483 reinstated permanently if the copyright holder notifies you of the 41484 violation by some reasonable means, this is the first time you have 41485 received notice of violation of this License (for any work) from 41486 that copyright holder, and you cure the violation prior to 30 days 41487 after your receipt of the notice. 41488 41489 Termination of your rights under this section does not terminate 41490 the licenses of parties who have received copies or rights from you 41491 under this License. If your rights have been terminated and not 41492 permanently reinstated, you do not qualify to receive new licenses 41493 for the same material under section 10. 41494 41495 9. Acceptance Not Required for Having Copies. 41496 41497 You are not required to accept this License in order to receive or 41498 run a copy of the Program. Ancillary propagation of a covered work 41499 occurring solely as a consequence of using peer-to-peer 41500 transmission to receive a copy likewise does not require 41501 acceptance. However, nothing other than this License grants you 41502 permission to propagate or modify any covered work. These actions 41503 infringe copyright if you do not accept this License. Therefore, 41504 by modifying or propagating a covered work, you indicate your 41505 acceptance of this License to do so. 41506 41507 10. Automatic Licensing of Downstream Recipients. 41508 41509 Each time you convey a covered work, the recipient automatically 41510 receives a license from the original licensors, to run, modify and 41511 propagate that work, subject to this License. You are not 41512 responsible for enforcing compliance by third parties with this 41513 License. 41514 41515 An "entity transaction" is a transaction transferring control of an 41516 organization, or substantially all assets of one, or subdividing an 41517 organization, or merging organizations. If propagation of a 41518 covered work results from an entity transaction, each party to that 41519 transaction who receives a copy of the work also receives whatever 41520 licenses to the work the party's predecessor in interest had or 41521 could give under the previous paragraph, plus a right to possession 41522 of the Corresponding Source of the work from the predecessor in 41523 interest, if the predecessor has it or can get it with reasonable 41524 efforts. 41525 41526 You may not impose any further restrictions on the exercise of the 41527 rights granted or affirmed under this License. For example, you 41528 may not impose a license fee, royalty, or other charge for exercise 41529 of rights granted under this License, and you may not initiate 41530 litigation (including a cross-claim or counterclaim in a lawsuit) 41531 alleging that any patent claim is infringed by making, using, 41532 selling, offering for sale, or importing the Program or any portion 41533 of it. 41534 41535 11. Patents. 41536 41537 A "contributor" is a copyright holder who authorizes use under this 41538 License of the Program or a work on which the Program is based. 41539 The work thus licensed is called the contributor's "contributor 41540 version". 41541 41542 A contributor's "essential patent claims" are all patent claims 41543 owned or controlled by the contributor, whether already acquired or 41544 hereafter acquired, that would be infringed by some manner, 41545 permitted by this License, of making, using, or selling its 41546 contributor version, but do not include claims that would be 41547 infringed only as a consequence of further modification of the 41548 contributor version. For purposes of this definition, "control" 41549 includes the right to grant patent sublicenses in a manner 41550 consistent with the requirements of this License. 41551 41552 Each contributor grants you a non-exclusive, worldwide, 41553 royalty-free patent license under the contributor's essential 41554 patent claims, to make, use, sell, offer for sale, import and 41555 otherwise run, modify and propagate the contents of its contributor 41556 version. 41557 41558 In the following three paragraphs, a "patent license" is any 41559 express agreement or commitment, however denominated, not to 41560 enforce a patent (such as an express permission to practice a 41561 patent or covenant not to sue for patent infringement). To "grant" 41562 such a patent license to a party means to make such an agreement or 41563 commitment not to enforce a patent against the party. 41564 41565 If you convey a covered work, knowingly relying on a patent 41566 license, and the Corresponding Source of the work is not available 41567 for anyone to copy, free of charge and under the terms of this 41568 License, through a publicly available network server or other 41569 readily accessible means, then you must either (1) cause the 41570 Corresponding Source to be so available, or (2) arrange to deprive 41571 yourself of the benefit of the patent license for this particular 41572 work, or (3) arrange, in a manner consistent with the requirements 41573 of this License, to extend the patent license to downstream 41574 recipients. "Knowingly relying" means you have actual knowledge 41575 that, but for the patent license, your conveying the covered work 41576 in a country, or your recipient's use of the covered work in a 41577 country, would infringe one or more identifiable patents in that 41578 country that you have reason to believe are valid. 41579 41580 If, pursuant to or in connection with a single transaction or 41581 arrangement, you convey, or propagate by procuring conveyance of, a 41582 covered work, and grant a patent license to some of the parties 41583 receiving the covered work authorizing them to use, propagate, 41584 modify or convey a specific copy of the covered work, then the 41585 patent license you grant is automatically extended to all 41586 recipients of the covered work and works based on it. 41587 41588 A patent license is "discriminatory" if it does not include within 41589 the scope of its coverage, prohibits the exercise of, or is 41590 conditioned on the non-exercise of one or more of the rights that 41591 are specifically granted under this License. You may not convey a 41592 covered work if you are a party to an arrangement with a third 41593 party that is in the business of distributing software, under which 41594 you make payment to the third party based on the extent of your 41595 activity of conveying the work, and under which the third party 41596 grants, to any of the parties who would receive the covered work 41597 from you, a discriminatory patent license (a) in connection with 41598 copies of the covered work conveyed by you (or copies made from 41599 those copies), or (b) primarily for and in connection with specific 41600 products or compilations that contain the covered work, unless you 41601 entered into that arrangement, or that patent license was granted, 41602 prior to 28 March 2007. 41603 41604 Nothing in this License shall be construed as excluding or limiting 41605 any implied license or other defenses to infringement that may 41606 otherwise be available to you under applicable patent law. 41607 41608 12. No Surrender of Others' Freedom. 41609 41610 If conditions are imposed on you (whether by court order, agreement 41611 or otherwise) that contradict the conditions of this License, they 41612 do not excuse you from the conditions of this License. If you 41613 cannot convey a covered work so as to satisfy simultaneously your 41614 obligations under this License and any other pertinent obligations, 41615 then as a consequence you may not convey it at all. For example, 41616 if you agree to terms that obligate you to collect a royalty for 41617 further conveying from those to whom you convey the Program, the 41618 only way you could satisfy both those terms and this License would 41619 be to refrain entirely from conveying the Program. 41620 41621 13. Use with the GNU Affero General Public License. 41622 41623 Notwithstanding any other provision of this License, you have 41624 permission to link or combine any covered work with a work licensed 41625 under version 3 of the GNU Affero General Public License into a 41626 single combined work, and to convey the resulting work. The terms 41627 of this License will continue to apply to the part which is the 41628 covered work, but the special requirements of the GNU Affero 41629 General Public License, section 13, concerning interaction through 41630 a network will apply to the combination as such. 41631 41632 14. Revised Versions of this License. 41633 41634 The Free Software Foundation may publish revised and/or new 41635 versions of the GNU General Public License from time to time. Such 41636 new versions will be similar in spirit to the present version, but 41637 may differ in detail to address new problems or concerns. 41638 41639 Each version is given a distinguishing version number. If the 41640 Program specifies that a certain numbered version of the GNU 41641 General Public License "or any later version" applies to it, you 41642 have the option of following the terms and conditions either of 41643 that numbered version or of any later version published by the Free 41644 Software Foundation. If the Program does not specify a version 41645 number of the GNU General Public License, you may choose any 41646 version ever published by the Free Software Foundation. 41647 41648 If the Program specifies that a proxy can decide which future 41649 versions of the GNU General Public License can be used, that 41650 proxy's public statement of acceptance of a version permanently 41651 authorizes you to choose that version for the Program. 41652 41653 Later license versions may give you additional or different 41654 permissions. However, no additional obligations are imposed on any 41655 author or copyright holder as a result of your choosing to follow a 41656 later version. 41657 41658 15. Disclaimer of Warranty. 41659 41660 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 41661 APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE 41662 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" 41663 WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 41664 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 41665 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE 41666 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. 41667 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL 41668 NECESSARY SERVICING, REPAIR OR CORRECTION. 41669 41670 16. Limitation of Liability. 41671 41672 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 41673 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES 41674 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR 41675 DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 41676 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE 41677 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA 41678 BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 41679 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 41680 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF 41681 THE POSSIBILITY OF SUCH DAMAGES. 41682 41683 17. Interpretation of Sections 15 and 16. 41684 41685 If the disclaimer of warranty and limitation of liability provided 41686 above cannot be given local legal effect according to their terms, 41687 reviewing courts shall apply local law that most closely 41688 approximates an absolute waiver of all civil liability in 41689 connection with the Program, unless a warranty or assumption of 41690 liability accompanies a copy of the Program in return for a fee. 41691 41692END OF TERMS AND CONDITIONS 41693=========================== 41694 41695How to Apply These Terms to Your New Programs 41696============================================= 41697 41698If you develop a new program, and you want it to be of the greatest 41699possible use to the public, the best way to achieve this is to make it 41700free software which everyone can redistribute and change under these 41701terms. 41702 41703 To do so, attach the following notices to the program. It is safest to 41704attach them to the start of each source file to most effectively state 41705the exclusion of warranty; and each file should have at least the 41706"copyright" line and a pointer to where the full notice is found. 41707 41708 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 41709 Copyright (C) YEAR NAME OF AUTHOR 41710 41711 This program is free software: you can redistribute it and/or modify 41712 it under the terms of the GNU General Public License as published by 41713 the Free Software Foundation, either version 3 of the License, or (at 41714 your option) any later version. 41715 41716 This program is distributed in the hope that it will be useful, but 41717 WITHOUT ANY WARRANTY; without even the implied warranty of 41718 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 41719 General Public License for more details. 41720 41721 You should have received a copy of the GNU General Public License 41722 along with this program. If not, see <http://www.gnu.org/licenses/>. 41723 41724 Also add information on how to contact you by electronic and paper 41725mail. 41726 41727 If the program does terminal interaction, make it output a short notice 41728like this when it starts in an interactive mode: 41729 41730 PROGRAM Copyright (C) YEAR NAME OF AUTHOR 41731 This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'. 41732 This is free software, and you are welcome to redistribute it 41733 under certain conditions; type 'show c' for details. 41734 41735 The hypothetical commands 'show w' and 'show c' should show the 41736appropriate parts of the General Public License. Of course, your 41737program's commands might be different; for a GUI interface, you would 41738use an "about box". 41739 41740 You should also get your employer (if you work as a programmer) or 41741school, if any, to sign a "copyright disclaimer" for the program, if 41742necessary. For more information on this, and how to apply and follow 41743the GNU GPL, see <http://www.gnu.org/licenses/>. 41744 41745 The GNU General Public License does not permit incorporating your 41746program into proprietary programs. If your program is a subroutine 41747library, you may consider it more useful to permit linking proprietary 41748applications with the library. If this is what you want to do, use the 41749GNU Lesser General Public License instead of this License. But first, 41750please read <http://www.gnu.org/philosophy/why-not-lgpl.html>. 41751 41752 41753File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 41754 41755GNU Free Documentation License 41756****************************** 41757 41758 Version 1.3, 3 November 2008 41759 41760 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. 41761 <http://fsf.org/> 41762 41763 Everyone is permitted to copy and distribute verbatim copies 41764 of this license document, but changing it is not allowed. 41765 41766 0. PREAMBLE 41767 41768 The purpose of this License is to make a manual, textbook, or other 41769 functional and useful document "free" in the sense of freedom: to 41770 assure everyone the effective freedom to copy and redistribute it, 41771 with or without modifying it, either commercially or 41772 noncommercially. Secondarily, this License preserves for the 41773 author and publisher a way to get credit for their work, while not 41774 being considered responsible for modifications made by others. 41775 41776 This License is a kind of "copyleft", which means that derivative 41777 works of the document must themselves be free in the same sense. 41778 It complements the GNU General Public License, which is a copyleft 41779 license designed for free software. 41780 41781 We have designed this License in order to use it for manuals for 41782 free software, because free software needs free documentation: a 41783 free program should come with manuals providing the same freedoms 41784 that the software does. But this License is not limited to 41785 software manuals; it can be used for any textual work, regardless 41786 of subject matter or whether it is published as a printed book. We 41787 recommend this License principally for works whose purpose is 41788 instruction or reference. 41789 41790 1. APPLICABILITY AND DEFINITIONS 41791 41792 This License applies to any manual or other work, in any medium, 41793 that contains a notice placed by the copyright holder saying it can 41794 be distributed under the terms of this License. Such a notice 41795 grants a world-wide, royalty-free license, unlimited in duration, 41796 to use that work under the conditions stated herein. The 41797 "Document", below, refers to any such manual or work. Any member 41798 of the public is a licensee, and is addressed as "you". You accept 41799 the license if you copy, modify or distribute the work in a way 41800 requiring permission under copyright law. 41801 41802 A "Modified Version" of the Document means any work containing the 41803 Document or a portion of it, either copied verbatim, or with 41804 modifications and/or translated into another language. 41805 41806 A "Secondary Section" is a named appendix or a front-matter section 41807 of the Document that deals exclusively with the relationship of the 41808 publishers or authors of the Document to the Document's overall 41809 subject (or to related matters) and contains nothing that could 41810 fall directly within that overall subject. (Thus, if the Document 41811 is in part a textbook of mathematics, a Secondary Section may not 41812 explain any mathematics.) The relationship could be a matter of 41813 historical connection with the subject or with related matters, or 41814 of legal, commercial, philosophical, ethical or political position 41815 regarding them. 41816 41817 The "Invariant Sections" are certain Secondary Sections whose 41818 titles are designated, as being those of Invariant Sections, in the 41819 notice that says that the Document is released under this License. 41820 If a section does not fit the above definition of Secondary then it 41821 is not allowed to be designated as Invariant. The Document may 41822 contain zero Invariant Sections. If the Document does not identify 41823 any Invariant Sections then there are none. 41824 41825 The "Cover Texts" are certain short passages of text that are 41826 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 41827 that says that the Document is released under this License. A 41828 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 41829 be at most 25 words. 41830 41831 A "Transparent" copy of the Document means a machine-readable copy, 41832 represented in a format whose specification is available to the 41833 general public, that is suitable for revising the document 41834 straightforwardly with generic text editors or (for images composed 41835 of pixels) generic paint programs or (for drawings) some widely 41836 available drawing editor, and that is suitable for input to text 41837 formatters or for automatic translation to a variety of formats 41838 suitable for input to text formatters. A copy made in an otherwise 41839 Transparent file format whose markup, or absence of markup, has 41840 been arranged to thwart or discourage subsequent modification by 41841 readers is not Transparent. An image format is not Transparent if 41842 used for any substantial amount of text. A copy that is not 41843 "Transparent" is called "Opaque". 41844 41845 Examples of suitable formats for Transparent copies include plain 41846 ASCII without markup, Texinfo input format, LaTeX input format, 41847 SGML or XML using a publicly available DTD, and standard-conforming 41848 simple HTML, PostScript or PDF designed for human modification. 41849 Examples of transparent image formats include PNG, XCF and JPG. 41850 Opaque formats include proprietary formats that can be read and 41851 edited only by proprietary word processors, SGML or XML for which 41852 the DTD and/or processing tools are not generally available, and 41853 the machine-generated HTML, PostScript or PDF produced by some word 41854 processors for output purposes only. 41855 41856 The "Title Page" means, for a printed book, the title page itself, 41857 plus such following pages as are needed to hold, legibly, the 41858 material this License requires to appear in the title page. For 41859 works in formats which do not have any title page as such, "Title 41860 Page" means the text near the most prominent appearance of the 41861 work's title, preceding the beginning of the body of the text. 41862 41863 The "publisher" means any person or entity that distributes copies 41864 of the Document to the public. 41865 41866 A section "Entitled XYZ" means a named subunit of the Document 41867 whose title either is precisely XYZ or contains XYZ in parentheses 41868 following text that translates XYZ in another language. (Here XYZ 41869 stands for a specific section name mentioned below, such as 41870 "Acknowledgements", "Dedications", "Endorsements", or "History".) 41871 To "Preserve the Title" of such a section when you modify the 41872 Document means that it remains a section "Entitled XYZ" according 41873 to this definition. 41874 41875 The Document may include Warranty Disclaimers next to the notice 41876 which states that this License applies to the Document. These 41877 Warranty Disclaimers are considered to be included by reference in 41878 this License, but only as regards disclaiming warranties: any other 41879 implication that these Warranty Disclaimers may have is void and 41880 has no effect on the meaning of this License. 41881 41882 2. VERBATIM COPYING 41883 41884 You may copy and distribute the Document in any medium, either 41885 commercially or noncommercially, provided that this License, the 41886 copyright notices, and the license notice saying this License 41887 applies to the Document are reproduced in all copies, and that you 41888 add no other conditions whatsoever to those of this License. You 41889 may not use technical measures to obstruct or control the reading 41890 or further copying of the copies you make or distribute. However, 41891 you may accept compensation in exchange for copies. If you 41892 distribute a large enough number of copies you must also follow the 41893 conditions in section 3. 41894 41895 You may also lend copies, under the same conditions stated above, 41896 and you may publicly display copies. 41897 41898 3. COPYING IN QUANTITY 41899 41900 If you publish printed copies (or copies in media that commonly 41901 have printed covers) of the Document, numbering more than 100, and 41902 the Document's license notice requires Cover Texts, you must 41903 enclose the copies in covers that carry, clearly and legibly, all 41904 these Cover Texts: Front-Cover Texts on the front cover, and 41905 Back-Cover Texts on the back cover. Both covers must also clearly 41906 and legibly identify you as the publisher of these copies. The 41907 front cover must present the full title with all words of the title 41908 equally prominent and visible. You may add other material on the 41909 covers in addition. Copying with changes limited to the covers, as 41910 long as they preserve the title of the Document and satisfy these 41911 conditions, can be treated as verbatim copying in other respects. 41912 41913 If the required texts for either cover are too voluminous to fit 41914 legibly, you should put the first ones listed (as many as fit 41915 reasonably) on the actual cover, and continue the rest onto 41916 adjacent pages. 41917 41918 If you publish or distribute Opaque copies of the Document 41919 numbering more than 100, you must either include a machine-readable 41920 Transparent copy along with each Opaque copy, or state in or with 41921 each Opaque copy a computer-network location from which the general 41922 network-using public has access to download using public-standard 41923 network protocols a complete Transparent copy of the Document, free 41924 of added material. If you use the latter option, you must take 41925 reasonably prudent steps, when you begin distribution of Opaque 41926 copies in quantity, to ensure that this Transparent copy will 41927 remain thus accessible at the stated location until at least one 41928 year after the last time you distribute an Opaque copy (directly or 41929 through your agents or retailers) of that edition to the public. 41930 41931 It is requested, but not required, that you contact the authors of 41932 the Document well before redistributing any large number of copies, 41933 to give them a chance to provide you with an updated version of the 41934 Document. 41935 41936 4. MODIFICATIONS 41937 41938 You may copy and distribute a Modified Version of the Document 41939 under the conditions of sections 2 and 3 above, provided that you 41940 release the Modified Version under precisely this License, with the 41941 Modified Version filling the role of the Document, thus licensing 41942 distribution and modification of the Modified Version to whoever 41943 possesses a copy of it. In addition, you must do these things in 41944 the Modified Version: 41945 41946 A. Use in the Title Page (and on the covers, if any) a title 41947 distinct from that of the Document, and from those of previous 41948 versions (which should, if there were any, be listed in the 41949 History section of the Document). You may use the same title 41950 as a previous version if the original publisher of that 41951 version gives permission. 41952 41953 B. List on the Title Page, as authors, one or more persons or 41954 entities responsible for authorship of the modifications in 41955 the Modified Version, together with at least five of the 41956 principal authors of the Document (all of its principal 41957 authors, if it has fewer than five), unless they release you 41958 from this requirement. 41959 41960 C. State on the Title page the name of the publisher of the 41961 Modified Version, as the publisher. 41962 41963 D. Preserve all the copyright notices of the Document. 41964 41965 E. Add an appropriate copyright notice for your modifications 41966 adjacent to the other copyright notices. 41967 41968 F. Include, immediately after the copyright notices, a license 41969 notice giving the public permission to use the Modified 41970 Version under the terms of this License, in the form shown in 41971 the Addendum below. 41972 41973 G. Preserve in that license notice the full lists of Invariant 41974 Sections and required Cover Texts given in the Document's 41975 license notice. 41976 41977 H. Include an unaltered copy of this License. 41978 41979 I. Preserve the section Entitled "History", Preserve its Title, 41980 and add to it an item stating at least the title, year, new 41981 authors, and publisher of the Modified Version as given on the 41982 Title Page. If there is no section Entitled "History" in the 41983 Document, create one stating the title, year, authors, and 41984 publisher of the Document as given on its Title Page, then add 41985 an item describing the Modified Version as stated in the 41986 previous sentence. 41987 41988 J. Preserve the network location, if any, given in the Document 41989 for public access to a Transparent copy of the Document, and 41990 likewise the network locations given in the Document for 41991 previous versions it was based on. These may be placed in the 41992 "History" section. You may omit a network location for a work 41993 that was published at least four years before the Document 41994 itself, or if the original publisher of the version it refers 41995 to gives permission. 41996 41997 K. For any section Entitled "Acknowledgements" or "Dedications", 41998 Preserve the Title of the section, and preserve in the section 41999 all the substance and tone of each of the contributor 42000 acknowledgements and/or dedications given therein. 42001 42002 L. Preserve all the Invariant Sections of the Document, unaltered 42003 in their text and in their titles. Section numbers or the 42004 equivalent are not considered part of the section titles. 42005 42006 M. Delete any section Entitled "Endorsements". Such a section 42007 may not be included in the Modified Version. 42008 42009 N. Do not retitle any existing section to be Entitled 42010 "Endorsements" or to conflict in title with any Invariant 42011 Section. 42012 42013 O. Preserve any Warranty Disclaimers. 42014 42015 If the Modified Version includes new front-matter sections or 42016 appendices that qualify as Secondary Sections and contain no 42017 material copied from the Document, you may at your option designate 42018 some or all of these sections as invariant. To do this, add their 42019 titles to the list of Invariant Sections in the Modified Version's 42020 license notice. These titles must be distinct from any other 42021 section titles. 42022 42023 You may add a section Entitled "Endorsements", provided it contains 42024 nothing but endorsements of your Modified Version by various 42025 parties--for example, statements of peer review or that the text 42026 has been approved by an organization as the authoritative 42027 definition of a standard. 42028 42029 You may add a passage of up to five words as a Front-Cover Text, 42030 and a passage of up to 25 words as a Back-Cover Text, to the end of 42031 the list of Cover Texts in the Modified Version. Only one passage 42032 of Front-Cover Text and one of Back-Cover Text may be added by (or 42033 through arrangements made by) any one entity. If the Document 42034 already includes a cover text for the same cover, previously added 42035 by you or by arrangement made by the same entity you are acting on 42036 behalf of, you may not add another; but you may replace the old 42037 one, on explicit permission from the previous publisher that added 42038 the old one. 42039 42040 The author(s) and publisher(s) of the Document do not by this 42041 License give permission to use their names for publicity for or to 42042 assert or imply endorsement of any Modified Version. 42043 42044 5. COMBINING DOCUMENTS 42045 42046 You may combine the Document with other documents released under 42047 this License, under the terms defined in section 4 above for 42048 modified versions, provided that you include in the combination all 42049 of the Invariant Sections of all of the original documents, 42050 unmodified, and list them all as Invariant Sections of your 42051 combined work in its license notice, and that you preserve all 42052 their Warranty Disclaimers. 42053 42054 The combined work need only contain one copy of this License, and 42055 multiple identical Invariant Sections may be replaced with a single 42056 copy. If there are multiple Invariant Sections with the same name 42057 but different contents, make the title of each such section unique 42058 by adding at the end of it, in parentheses, the name of the 42059 original author or publisher of that section if known, or else a 42060 unique number. Make the same adjustment to the section titles in 42061 the list of Invariant Sections in the license notice of the 42062 combined work. 42063 42064 In the combination, you must combine any sections Entitled 42065 "History" in the various original documents, forming one section 42066 Entitled "History"; likewise combine any sections Entitled 42067 "Acknowledgements", and any sections Entitled "Dedications". You 42068 must delete all sections Entitled "Endorsements." 42069 42070 6. COLLECTIONS OF DOCUMENTS 42071 42072 You may make a collection consisting of the Document and other 42073 documents released under this License, and replace the individual 42074 copies of this License in the various documents with a single copy 42075 that is included in the collection, provided that you follow the 42076 rules of this License for verbatim copying of each of the documents 42077 in all other respects. 42078 42079 You may extract a single document from such a collection, and 42080 distribute it individually under this License, provided you insert 42081 a copy of this License into the extracted document, and follow this 42082 License in all other respects regarding verbatim copying of that 42083 document. 42084 42085 7. AGGREGATION WITH INDEPENDENT WORKS 42086 42087 A compilation of the Document or its derivatives with other 42088 separate and independent documents or works, in or on a volume of a 42089 storage or distribution medium, is called an "aggregate" if the 42090 copyright resulting from the compilation is not used to limit the 42091 legal rights of the compilation's users beyond what the individual 42092 works permit. When the Document is included in an aggregate, this 42093 License does not apply to the other works in the aggregate which 42094 are not themselves derivative works of the Document. 42095 42096 If the Cover Text requirement of section 3 is applicable to these 42097 copies of the Document, then if the Document is less than one half 42098 of the entire aggregate, the Document's Cover Texts may be placed 42099 on covers that bracket the Document within the aggregate, or the 42100 electronic equivalent of covers if the Document is in electronic 42101 form. Otherwise they must appear on printed covers that bracket 42102 the whole aggregate. 42103 42104 8. TRANSLATION 42105 42106 Translation is considered a kind of modification, so you may 42107 distribute translations of the Document under the terms of section 42108 4. Replacing Invariant Sections with translations requires special 42109 permission from their copyright holders, but you may include 42110 translations of some or all Invariant Sections in addition to the 42111 original versions of these Invariant Sections. You may include a 42112 translation of this License, and all the license notices in the 42113 Document, and any Warranty Disclaimers, provided that you also 42114 include the original English version of this License and the 42115 original versions of those notices and disclaimers. In case of a 42116 disagreement between the translation and the original version of 42117 this License or a notice or disclaimer, the original version will 42118 prevail. 42119 42120 If a section in the Document is Entitled "Acknowledgements", 42121 "Dedications", or "History", the requirement (section 4) to 42122 Preserve its Title (section 1) will typically require changing the 42123 actual title. 42124 42125 9. TERMINATION 42126 42127 You may not copy, modify, sublicense, or distribute the Document 42128 except as expressly provided under this License. Any attempt 42129 otherwise to copy, modify, sublicense, or distribute it is void, 42130 and will automatically terminate your rights under this License. 42131 42132 However, if you cease all violation of this License, then your 42133 license from a particular copyright holder is reinstated (a) 42134 provisionally, unless and until the copyright holder explicitly and 42135 finally terminates your license, and (b) permanently, if the 42136 copyright holder fails to notify you of the violation by some 42137 reasonable means prior to 60 days after the cessation. 42138 42139 Moreover, your license from a particular copyright holder is 42140 reinstated permanently if the copyright holder notifies you of the 42141 violation by some reasonable means, this is the first time you have 42142 received notice of violation of this License (for any work) from 42143 that copyright holder, and you cure the violation prior to 30 days 42144 after your receipt of the notice. 42145 42146 Termination of your rights under this section does not terminate 42147 the licenses of parties who have received copies or rights from you 42148 under this License. If your rights have been terminated and not 42149 permanently reinstated, receipt of a copy of some or all of the 42150 same material does not give you any rights to use it. 42151 42152 10. FUTURE REVISIONS OF THIS LICENSE 42153 42154 The Free Software Foundation may publish new, revised versions of 42155 the GNU Free Documentation License from time to time. Such new 42156 versions will be similar in spirit to the present version, but may 42157 differ in detail to address new problems or concerns. See 42158 <http://www.gnu.org/copyleft/>. 42159 42160 Each version of the License is given a distinguishing version 42161 number. If the Document specifies that a particular numbered 42162 version of this License "or any later version" applies to it, you 42163 have the option of following the terms and conditions either of 42164 that specified version or of any later version that has been 42165 published (not as a draft) by the Free Software Foundation. If the 42166 Document does not specify a version number of this License, you may 42167 choose any version ever published (not as a draft) by the Free 42168 Software Foundation. If the Document specifies that a proxy can 42169 decide which future versions of this License can be used, that 42170 proxy's public statement of acceptance of a version permanently 42171 authorizes you to choose that version for the Document. 42172 42173 11. RELICENSING 42174 42175 "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 42176 World Wide Web server that publishes copyrightable works and also 42177 provides prominent facilities for anybody to edit those works. A 42178 public wiki that anybody can edit is an example of such a server. 42179 A "Massive Multiauthor Collaboration" (or "MMC") contained in the 42180 site means any set of copyrightable works thus published on the MMC 42181 site. 42182 42183 "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 42184 license published by Creative Commons Corporation, a not-for-profit 42185 corporation with a principal place of business in San Francisco, 42186 California, as well as future copyleft versions of that license 42187 published by that same organization. 42188 42189 "Incorporate" means to publish or republish a Document, in whole or 42190 in part, as part of another Document. 42191 42192 An MMC is "eligible for relicensing" if it is licensed under this 42193 License, and if all works that were first published under this 42194 License somewhere other than this MMC, and subsequently 42195 incorporated in whole or in part into the MMC, (1) had no cover 42196 texts or invariant sections, and (2) were thus incorporated prior 42197 to November 1, 2008. 42198 42199 The operator of an MMC Site may republish an MMC contained in the 42200 site under CC-BY-SA on the same site at any time before August 1, 42201 2009, provided the MMC is eligible for relicensing. 42202 42203ADDENDUM: How to use this License for your documents 42204==================================================== 42205 42206To use this License in a document you have written, include a copy of 42207the License in the document and put the following copyright and license 42208notices just after the title page: 42209 42210 Copyright (C) YEAR YOUR NAME. 42211 Permission is granted to copy, distribute and/or modify this document 42212 under the terms of the GNU Free Documentation License, Version 1.3 42213 or any later version published by the Free Software Foundation; 42214 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 42215 Texts. A copy of the license is included in the section entitled ``GNU 42216 Free Documentation License''. 42217 42218 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 42219replace the "with...Texts." line with this: 42220 42221 with the Invariant Sections being LIST THEIR TITLES, with 42222 the Front-Cover Texts being LIST, and with the Back-Cover Texts 42223 being LIST. 42224 42225 If you have Invariant Sections without Cover Texts, or some other 42226combination of the three, merge those two alternatives to suit the 42227situation. 42228 42229 If your document contains nontrivial examples of program code, we 42230recommend releasing these examples in parallel under your choice of free 42231software license, such as the GNU General Public License, to permit 42232their use in free software. 42233 42234 42235File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 42236 42237Contributors to GCC 42238******************* 42239 42240The GCC project would like to thank its many contributors. Without them 42241the project would not have been nearly as successful as it has been. 42242Any omissions in this list are accidental. Feel free to contact 42243<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or 42244some of your contributions are not listed. Please keep this list in 42245alphabetical order. 42246 42247 * Analog Devices helped implement the support for complex data types 42248 and iterators. 42249 42250 * John David Anglin for threading-related fixes and improvements to 42251 libstdc++-v3, and the HP-UX port. 42252 42253 * James van Artsdalen wrote the code that makes efficient use of the 42254 Intel 80387 register stack. 42255 42256 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 42257 Series port. 42258 42259 * Alasdair Baird for various bug fixes. 42260 42261 * Giovanni Bajo for analyzing lots of complicated C++ problem 42262 reports. 42263 42264 * Peter Barada for his work to improve code generation for new 42265 ColdFire cores. 42266 42267 * Gerald Baumgartner added the signature extension to the C++ front 42268 end. 42269 42270 * Godmar Back for his Java improvements and encouragement. 42271 42272 * Scott Bambrough for help porting the Java compiler. 42273 42274 * Wolfgang Bangerth for processing tons of bug reports. 42275 42276 * Jon Beniston for his Microsoft Windows port of Java and port to 42277 Lattice Mico32. 42278 42279 * Daniel Berlin for better DWARF2 support, faster/better 42280 optimizations, improved alias analysis, plus migrating GCC to 42281 Bugzilla. 42282 42283 * Geoff Berry for his Java object serialization work and various 42284 patches. 42285 42286 * David Binderman tests weekly snapshots of GCC trunk against Fedora 42287 Rawhide for several architectures. 42288 42289 * Laurynas Biveinis for memory management work and DJGPP port fixes. 42290 42291 * Uros Bizjak for the implementation of x87 math built-in functions 42292 and for various middle end and i386 back end improvements and bug 42293 fixes. 42294 42295 * Eric Blake for helping to make GCJ and libgcj conform to the 42296 specifications. 42297 42298 * Janne Blomqvist for contributions to GNU Fortran. 42299 42300 * Segher Boessenkool for various fixes. 42301 42302 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 42303 other Java work. 42304 42305 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 42306 miscellaneous clean-ups. 42307 42308 * Steven Bosscher for integrating the GNU Fortran front end into GCC 42309 and for contributing to the tree-ssa branch. 42310 42311 * Eric Botcazou for fixing middle- and backend bugs left and right. 42312 42313 * Per Bothner for his direction via the steering committee and 42314 various improvements to the infrastructure for supporting new 42315 languages. Chill front end implementation. Initial 42316 implementations of cpplib, fix-header, config.guess, libio, and 42317 past C++ library (libg++) maintainer. Dreaming up, designing and 42318 implementing much of GCJ. 42319 42320 * Devon Bowen helped port GCC to the Tahoe. 42321 42322 * Don Bowman for mips-vxworks contributions. 42323 42324 * Dave Brolley for work on cpplib and Chill. 42325 42326 * Paul Brook for work on the ARM architecture and maintaining GNU 42327 Fortran. 42328 42329 * Robert Brown implemented the support for Encore 32000 systems. 42330 42331 * Christian Bruel for improvements to local store elimination. 42332 42333 * Herman A.J. ten Brugge for various fixes. 42334 42335 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 42336 FAQ. 42337 42338 * Joe Buck for his direction via the steering committee from its 42339 creation to 2013. 42340 42341 * Craig Burley for leadership of the G77 Fortran effort. 42342 42343 * Stephan Buys for contributing Doxygen notes for libstdc++. 42344 42345 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 42346 to the C++ strings, streambufs and formatted I/O, hard detective 42347 work on the frustrating localization issues, and keeping up with 42348 the problem reports. 42349 42350 * John Carr for his alias work, SPARC hacking, infrastructure 42351 improvements, previous contributions to the steering committee, 42352 loop optimizations, etc. 42353 42354 * Stephane Carrez for 68HC11 and 68HC12 ports. 42355 42356 * Steve Chamberlain for support for the Renesas SH and H8 processors 42357 and the PicoJava processor, and for GCJ config fixes. 42358 42359 * Glenn Chambers for help with the GCJ FAQ. 42360 42361 * John-Marc Chandonia for various libgcj patches. 42362 42363 * Denis Chertykov for contributing and maintaining the AVR port, the 42364 first GCC port for an 8-bit architecture. 42365 42366 * Scott Christley for his Objective-C contributions. 42367 42368 * Eric Christopher for his Java porting help and clean-ups. 42369 42370 * Branko Cibej for more warning contributions. 42371 42372 * The GNU Classpath project for all of their merged runtime code. 42373 42374 * Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work, 42375 '--help', and other random hacking. 42376 42377 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 42378 42379 * R. Kelley Cook for making GCC buildable from a read-only directory 42380 as well as other miscellaneous build process and documentation 42381 clean-ups. 42382 42383 * Ralf Corsepius for SH testing and minor bug fixing. 42384 42385 * Stan Cox for care and feeding of the x86 port and lots of behind 42386 the scenes hacking. 42387 42388 * Alex Crain provided changes for the 3b1. 42389 42390 * Ian Dall for major improvements to the NS32k port. 42391 42392 * Paul Dale for his work to add uClinux platform support to the m68k 42393 backend. 42394 42395 * Dario Dariol contributed the four varieties of sample programs that 42396 print a copy of their source. 42397 42398 * Russell Davidson for fstream and stringstream fixes in libstdc++. 42399 42400 * Bud Davis for work on the G77 and GNU Fortran compilers. 42401 42402 * Mo DeJong for GCJ and libgcj bug fixes. 42403 42404 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 42405 various bug fixes, and the M32C, MeP, MSP430, and RL78 ports. 42406 42407 * Arnaud Desitter for helping to debug GNU Fortran. 42408 42409 * Gabriel Dos Reis for contributions to G++, contributions and 42410 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 42411 including 'valarray<>', 'complex<>', maintaining the numerics 42412 library (including that pesky '<limits>' :-) and keeping up-to-date 42413 anything to do with numbers. 42414 42415 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 42416 ISO C99 support, CFG dumping support, etc., plus support of the C++ 42417 runtime libraries including for all kinds of C interface issues, 42418 contributing and maintaining 'complex<>', sanity checking and 42419 disbursement, configuration architecture, libio maintenance, and 42420 early math work. 42421 42422 * Franc,ois Dumont for his work on libstdc++-v3, especially 42423 maintaining and improving 'debug-mode' and associative and 42424 unordered containers. 42425 42426 * Zdenek Dvorak for a new loop unroller and various fixes. 42427 42428 * Michael Eager for his work on the Xilinx MicroBlaze port. 42429 42430 * Richard Earnshaw for his ongoing work with the ARM. 42431 42432 * David Edelsohn for his direction via the steering committee, 42433 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 42434 loop changes, doing the entire AIX port of libstdc++ with his bare 42435 hands, and for ensuring GCC properly keeps working on AIX. 42436 42437 * Kevin Ediger for the floating point formatting of num_put::do_put 42438 in libstdc++. 42439 42440 * Phil Edwards for libstdc++ work including configuration hackery, 42441 documentation maintainer, chief breaker of the web pages, the 42442 occasional iostream bug fix, and work on shared library symbol 42443 versioning. 42444 42445 * Paul Eggert for random hacking all over GCC. 42446 42447 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 42448 configuration support for locales and fstream-related fixes. 42449 42450 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 42451 iostreams. 42452 42453 * Christian Ehrhardt for dealing with bug reports. 42454 42455 * Ben Elliston for his work to move the Objective-C runtime into its 42456 own subdirectory and for his work on autoconf. 42457 42458 * Revital Eres for work on the PowerPC 750CL port. 42459 42460 * Marc Espie for OpenBSD support. 42461 42462 * Doug Evans for much of the global optimization framework, arc, 42463 m32r, and SPARC work. 42464 42465 * Christopher Faylor for his work on the Cygwin port and for caring 42466 and feeding the gcc.gnu.org box and saving its users tons of spam. 42467 42468 * Fred Fish for BeOS support and Ada fixes. 42469 42470 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 42471 42472 * Peter Gerwinski for various bug fixes and the Pascal front end. 42473 42474 * Kaveh R. Ghazi for his direction via the steering committee, 42475 amazing work to make '-W -Wall -W* -Werror' useful, and testing GCC 42476 on a plethora of platforms. Kaveh extends his gratitude to the 42477 CAIP Center at Rutgers University for providing him with computing 42478 resources to work on Free Software from the late 1980s to 2010. 42479 42480 * John Gilmore for a donation to the FSF earmarked improving GNU 42481 Java. 42482 42483 * Judy Goldberg for c++ contributions. 42484 42485 * Torbjorn Granlund for various fixes and the c-torture testsuite, 42486 multiply- and divide-by-constant optimization, improved long long 42487 support, improved leaf function register allocation, and his 42488 direction via the steering committee. 42489 42490 * Jonny Grant for improvements to 'collect2's' '--help' 42491 documentation. 42492 42493 * Anthony Green for his '-Os' contributions, the moxie port, and Java 42494 front end work. 42495 42496 * Stu Grossman for gdb hacking, allowing GCJ developers to debug Java 42497 code. 42498 42499 * Michael K. Gschwind contributed the port to the PDP-11. 42500 42501 * Richard Biener for his ongoing middle-end contributions and bug 42502 fixes and for release management. 42503 42504 * Ron Guilmette implemented the 'protoize' and 'unprotoize' tools, 42505 the support for Dwarf symbolic debugging information, and much of 42506 the support for System V Release 4. He has also worked heavily on 42507 the Intel 386 and 860 support. 42508 42509 * Sumanth Gundapaneni for contributing the CR16 port. 42510 42511 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 42512 GCSE. 42513 42514 * Bruno Haible for improvements in the runtime overhead for EH, new 42515 warnings and assorted bug fixes. 42516 42517 * Andrew Haley for his amazing Java compiler and library efforts. 42518 42519 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 42520 series 300. 42521 42522 * Michael Hayes for various thankless work he's done trying to get 42523 the c30/c40 ports functional. Lots of loop and unroll improvements 42524 and fixes. 42525 42526 * Dara Hazeghi for wading through myriads of target-specific bug 42527 reports. 42528 42529 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 42530 42531 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 42532 work, loop opts, and generally fixing lots of old problems we've 42533 ignored for years, flow rewrite and lots of further stuff, 42534 including reviewing tons of patches. 42535 42536 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 42537 various fixes. 42538 42539 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 42540 contributed the support for the Sony NEWS machine. 42541 42542 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 42543 various fixes. 42544 42545 * Katherine Holcomb for work on GNU Fortran. 42546 42547 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 42548 of testing and bug fixing, particularly of GCC configury code. 42549 42550 * Steve Holmgren for MachTen patches. 42551 42552 * Mat Hostetter for work on the TILE-Gx and TILEPro ports. 42553 42554 * Jan Hubicka for his x86 port improvements. 42555 42556 * Falk Hueffner for working on C and optimization bug reports. 42557 42558 * Bernardo Innocenti for his m68k work, including merging of ColdFire 42559 improvements and uClinux support. 42560 42561 * Christian Iseli for various bug fixes. 42562 42563 * Kamil Iskra for general m68k hacking. 42564 42565 * Lee Iverson for random fixes and MIPS testing. 42566 42567 * Balaji V. Iyer for Cilk+ development and merging. 42568 42569 * Andreas Jaeger for testing and benchmarking of GCC and various bug 42570 fixes. 42571 42572 * Martin Jambor for his work on inter-procedural optimizations, the 42573 switch conversion pass, and scalar replacement of aggregates. 42574 42575 * Jakub Jelinek for his SPARC work and sibling call optimizations as 42576 well as lots of bug fixes and test cases, and for improving the 42577 Java build system. 42578 42579 * Janis Johnson for ia64 testing and fixes, her quality improvement 42580 sidetracks, and web page maintenance. 42581 42582 * Kean Johnston for SCO OpenServer support and various fixes. 42583 42584 * Tim Josling for the sample language treelang based originally on 42585 Richard Kenner's "toy" language. 42586 42587 * Nicolai Josuttis for additional libstdc++ documentation. 42588 42589 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 42590 target. 42591 42592 * Steven G. Kargl for work on GNU Fortran. 42593 42594 * David Kashtan of SRI adapted GCC to VMS. 42595 42596 * Ryszard Kabatek for many, many libstdc++ bug fixes and 42597 optimizations of strings, especially member functions, and for 42598 auto_ptr fixes. 42599 42600 * Geoffrey Keating for his ongoing work to make the PPC work for 42601 GNU/Linux and his automatic regression tester. 42602 42603 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 42604 work in just about every part of libstdc++. 42605 42606 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 42607 MIL-STD-1750A. 42608 42609 * Richard Kenner of the New York University Ultracomputer Research 42610 Laboratory wrote the machine descriptions for the AMD 29000, the 42611 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 42612 support for instruction attributes. He also made changes to better 42613 support RISC processors including changes to common subexpression 42614 elimination, strength reduction, function calling sequence 42615 handling, and condition code support, in addition to generalizing 42616 the code for frame pointer elimination and delay slot scheduling. 42617 Richard Kenner was also the head maintainer of GCC for several 42618 years. 42619 42620 * Mumit Khan for various contributions to the Cygwin and Mingw32 42621 ports and maintaining binary releases for Microsoft Windows hosts, 42622 and for massive libstdc++ porting work to Cygwin/Mingw32. 42623 42624 * Robin Kirkham for cpu32 support. 42625 42626 * Mark Klein for PA improvements. 42627 42628 * Thomas Koenig for various bug fixes. 42629 42630 * Bruce Korb for the new and improved fixincludes code. 42631 42632 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 42633 effort. 42634 42635 * Maxim Kuvyrkov for contributions to the instruction scheduler, the 42636 Android and m68k/Coldfire ports, and optimizations. 42637 42638 * Charles LaBrec contributed the support for the Integrated Solutions 42639 68020 system. 42640 42641 * Asher Langton and Mike Kumbera for contributing Cray pointer 42642 support to GNU Fortran, and for other GNU Fortran improvements. 42643 42644 * Jeff Law for his direction via the steering committee, coordinating 42645 the entire egcs project and GCC 2.95, rolling out snapshots and 42646 releases, handling merges from GCC2, reviewing tons of patches that 42647 might have fallen through the cracks else, and random but extensive 42648 hacking. 42649 42650 * Walter Lee for work on the TILE-Gx and TILEPro ports. 42651 42652 * Marc Lehmann for his direction via the steering committee and 42653 helping with analysis and improvements of x86 performance. 42654 42655 * Victor Leikehman for work on GNU Fortran. 42656 42657 * Ted Lemon wrote parts of the RTL reader and printer. 42658 42659 * Kriang Lerdsuwanakij for C++ improvements including template as 42660 template parameter support, and many C++ fixes. 42661 42662 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 42663 and random work on the Java front end. 42664 42665 * Alain Lichnewsky ported GCC to the MIPS CPU. 42666 42667 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 42668 and patches. 42669 42670 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 42671 42672 * Chen Liqin for various S+core related fixes/improvement, and for 42673 maintaining the S+core port. 42674 42675 * Weiwen Liu for testing and various bug fixes. 42676 42677 * Manuel Lo'pez-Iba'n~ez for improving '-Wconversion' and many other 42678 diagnostics fixes and improvements. 42679 42680 * Dave Love for his ongoing work with the Fortran front end and 42681 runtime libraries. 42682 42683 * Martin von Lo"wis for internal consistency checking infrastructure, 42684 various C++ improvements including namespace support, and tons of 42685 assistance with libstdc++/compiler merges. 42686 42687 * H.J. Lu for his previous contributions to the steering committee, 42688 many x86 bug reports, prototype patches, and keeping the GNU/Linux 42689 ports working. 42690 42691 * Greg McGary for random fixes and (someday) bounded pointers. 42692 42693 * Andrew MacLeod for his ongoing work in building a real EH system, 42694 various code generation improvements, work on the global optimizer, 42695 etc. 42696 42697 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 42698 hacking improvements to compile-time performance, overall knowledge 42699 and direction in the area of instruction scheduling, and design and 42700 implementation of the automaton based instruction scheduler. 42701 42702 * Bob Manson for his behind the scenes work on dejagnu. 42703 42704 * John Marino for contributing the DragonFly BSD port. 42705 42706 * Philip Martin for lots of libstdc++ string and vector iterator 42707 fixes and improvements, and string clean up and testsuites. 42708 42709 * Michael Matz for his work on dominance tree discovery, the x86-64 42710 port, link-time optimization framework and general optimization 42711 improvements. 42712 42713 * All of the Mauve project contributors, for Java test code. 42714 42715 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 42716 42717 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 42718 42719 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 42720 powerpc, haifa, ECOFF debug support, and other assorted hacking. 42721 42722 * Jason Merrill for his direction via the steering committee and 42723 leading the G++ effort. 42724 42725 * Martin Michlmayr for testing GCC on several architectures using the 42726 entire Debian archive. 42727 42728 * David Miller for his direction via the steering committee, lots of 42729 SPARC work, improvements in jump.c and interfacing with the Linux 42730 kernel developers. 42731 42732 * Gary Miller ported GCC to Charles River Data Systems machines. 42733 42734 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 42735 the entire libstdc++ testsuite namespace-compatible. 42736 42737 * Mark Mitchell for his direction via the steering committee, 42738 mountains of C++ work, load/store hoisting out of loops, alias 42739 analysis improvements, ISO C 'restrict' support, and serving as 42740 release manager from 2000 to 2011. 42741 42742 * Alan Modra for various GNU/Linux bits and testing. 42743 42744 * Toon Moene for his direction via the steering committee, Fortran 42745 maintenance, and his ongoing work to make us make Fortran run fast. 42746 42747 * Jason Molenda for major help in the care and feeding of all the 42748 services on the gcc.gnu.org (formerly egcs.cygnus.com) 42749 machine--mail, web services, ftp services, etc etc. Doing all this 42750 work on scrap paper and the backs of envelopes would have been... 42751 difficult. 42752 42753 * Catherine Moore for fixing various ugly problems we have sent her 42754 way, including the haifa bug which was killing the Alpha & PowerPC 42755 Linux kernels. 42756 42757 * Mike Moreton for his various Java patches. 42758 42759 * David Mosberger-Tang for various Alpha improvements, and for the 42760 initial IA-64 port. 42761 42762 * Stephen Moshier contributed the floating point emulator that 42763 assists in cross-compilation and permits support for floating point 42764 numbers wider than 64 bits and for ISO C99 support. 42765 42766 * Bill Moyer for his behind the scenes work on various issues. 42767 42768 * Philippe De Muyter for his work on the m68k port. 42769 42770 * Joseph S. Myers for his work on the PDP-11 port, format checking 42771 and ISO C99 support, and continuous emphasis on (and contributions 42772 to) documentation. 42773 42774 * Nathan Myers for his work on libstdc++-v3: architecture and 42775 authorship through the first three snapshots, including 42776 implementation of locale infrastructure, string, shadow C headers, 42777 and the initial project documentation (DESIGN, CHECKLIST, and so 42778 forth). Later, more work on MT-safe string and shadow headers. 42779 42780 * Felix Natter for documentation on porting libstdc++. 42781 42782 * Nathanael Nerode for cleaning up the configuration/build process. 42783 42784 * NeXT, Inc. donated the front end that supports the Objective-C 42785 language. 42786 42787 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the 42788 search engine setup, various documentation fixes and other small 42789 fixes. 42790 42791 * Geoff Noer for his work on getting cygwin native builds working. 42792 42793 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 42794 tracking web pages, GIMPLE tuples, and assorted fixes. 42795 42796 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 42797 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and related 42798 infrastructure improvements. 42799 42800 * Alexandre Oliva for various build infrastructure improvements, 42801 scripts and amazing testing work, including keeping libtool issues 42802 sane and happy. 42803 42804 * Stefan Olsson for work on mt_alloc. 42805 42806 * Melissa O'Neill for various NeXT fixes. 42807 42808 * Rainer Orth for random MIPS work, including improvements to GCC's 42809 o32 ABI support, improvements to dejagnu's MIPS support, Java 42810 configuration clean-ups and porting work, and maintaining the IRIX, 42811 Solaris 2, and Tru64 UNIX ports. 42812 42813 * Hartmut Penner for work on the s390 port. 42814 42815 * Paul Petersen wrote the machine description for the Alliant FX/8. 42816 42817 * Alexandre Petit-Bianco for implementing much of the Java compiler 42818 and continued Java maintainership. 42819 42820 * Matthias Pfaller for major improvements to the NS32k port. 42821 42822 * Gerald Pfeifer for his direction via the steering committee, 42823 pointing out lots of problems we need to solve, maintenance of the 42824 web pages, and taking care of documentation maintenance in general. 42825 42826 * Andrew Pinski for processing bug reports by the dozen. 42827 42828 * Ovidiu Predescu for his work on the Objective-C front end and 42829 runtime libraries. 42830 42831 * Jerry Quinn for major performance improvements in C++ formatted 42832 I/O. 42833 42834 * Ken Raeburn for various improvements to checker, MIPS ports and 42835 various cleanups in the compiler. 42836 42837 * Rolf W. Rasmussen for hacking on AWT. 42838 42839 * David Reese of Sun Microsystems contributed to the Solaris on 42840 PowerPC port. 42841 42842 * Volker Reichelt for keeping up with the problem reports. 42843 42844 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 42845 hacking and developing and maintaining the Epiphany port. 42846 42847 * Loren J. Rittle for improvements to libstdc++-v3 including the 42848 FreeBSD port, threading fixes, thread-related configury changes, 42849 critical threading documentation, and solutions to really tricky 42850 I/O problems, as well as keeping GCC properly working on FreeBSD 42851 and continuous testing. 42852 42853 * Craig Rodrigues for processing tons of bug reports. 42854 42855 * Ola Ro"nnerup for work on mt_alloc. 42856 42857 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 42858 42859 * David Ronis inspired and encouraged Craig to rewrite the G77 42860 documentation in texinfo format by contributing a first pass at a 42861 translation of the old 'g77-0.5.16/f/DOC' file. 42862 42863 * Ken Rose for fixes to GCC's delay slot filling code. 42864 42865 * Ira Rosen for her contributions to the auto-vectorizer. 42866 42867 * Paul Rubin wrote most of the preprocessor. 42868 42869 * Pe'tur Runo'lfsson for major performance improvements in C++ 42870 formatted I/O and large file support in C++ filebuf. 42871 42872 * Chip Salzenberg for libstdc++ patches and improvements to locales, 42873 traits, Makefiles, libio, libtool hackery, and "long long" support. 42874 42875 * Juha Sarlin for improvements to the H8 code generator. 42876 42877 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 42878 300. 42879 42880 * Roger Sayle for improvements to constant folding and GCC's RTL 42881 optimizers as well as for fixing numerous bugs. 42882 42883 * Bradley Schatz for his work on the GCJ FAQ. 42884 42885 * Peter Schauer wrote the code to allow debugging to work on the 42886 Alpha. 42887 42888 * William Schelter did most of the work on the Intel 80386 support. 42889 42890 * Tobias Schlu"ter for work on GNU Fortran. 42891 42892 * Bernd Schmidt for various code generation improvements and major 42893 work in the reload pass, serving as release manager for GCC 2.95.3, 42894 and work on the Blackfin and C6X ports. 42895 42896 * Peter Schmid for constant testing of libstdc++--especially 42897 application testing, going above and beyond what was requested for 42898 the release criteria--and libstdc++ header file tweaks. 42899 42900 * Jason Schroeder for jcf-dump patches. 42901 42902 * Andreas Schwab for his work on the m68k port. 42903 42904 * Lars Segerlund for work on GNU Fortran. 42905 42906 * Dodji Seketeli for numerous C++ bug fixes and debug info 42907 improvements. 42908 42909 * Tim Shen for major work on '<regex>'. 42910 42911 * Joel Sherrill for his direction via the steering committee, RTEMS 42912 contributions and RTEMS testing. 42913 42914 * Nathan Sidwell for many C++ fixes/improvements. 42915 42916 * Jeffrey Siegal for helping RMS with the original design of GCC, 42917 some code which handles the parse tree and RTL data structures, 42918 constant folding and help with the original VAX & m68k ports. 42919 42920 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 42921 from the LWG (thereby keeping GCC in line with updates from the 42922 ISO). 42923 42924 * Franz Sirl for his ongoing work with making the PPC port stable for 42925 GNU/Linux. 42926 42927 * Andrey Slepuhin for assorted AIX hacking. 42928 42929 * Trevor Smigiel for contributing the SPU port. 42930 42931 * Christopher Smith did the port for Convex machines. 42932 42933 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 42934 Retired from GCC maintainership August 2010, having mentored two 42935 new maintainers into the role. 42936 42937 * Randy Smith finished the Sun FPA support. 42938 42939 * Ed Smith-Rowland for his continuous work on libstdc++-v3, special 42940 functions, '<random>', and various improvements to C++11 features. 42941 42942 * Scott Snyder for queue, iterator, istream, and string fixes and 42943 libstdc++ testsuite entries. Also for providing the patch to G77 42944 to add rudimentary support for 'INTEGER*1', 'INTEGER*2', and 42945 'LOGICAL*1'. 42946 42947 * Zdenek Sojka for running automated regression testing of GCC and 42948 reporting numerous bugs. 42949 42950 * Jayant Sonar for contributing the CR16 port. 42951 42952 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 42953 42954 * Richard Stallman, for writing the original GCC and launching the 42955 GNU project. 42956 42957 * Jan Stein of the Chalmers Computer Society provided support for 42958 Genix, as well as part of the 32000 machine description. 42959 42960 * Nigel Stephens for various mips16 related fixes/improvements. 42961 42962 * Jonathan Stone wrote the machine description for the Pyramid 42963 computer. 42964 42965 * Graham Stott for various infrastructure improvements. 42966 42967 * John Stracke for his Java HTTP protocol fixes. 42968 42969 * Mike Stump for his Elxsi port, G++ contributions over the years and 42970 more recently his vxworks contributions 42971 42972 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 42973 42974 * Shigeya Suzuki for this fixes for the bsdi platforms. 42975 42976 * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64 42977 support, general configury hacking, fixincludes, etc. 42978 42979 * Holger Teutsch provided the support for the Clipper CPU. 42980 42981 * Gary Thomas for his ongoing work to make the PPC work for 42982 GNU/Linux. 42983 42984 * Philipp Thomas for random bug fixes throughout the compiler 42985 42986 * Jason Thorpe for thread support in libstdc++ on NetBSD. 42987 42988 * Kresten Krab Thorup wrote the run time support for the Objective-C 42989 language and the fantastic Java bytecode interpreter. 42990 42991 * Michael Tiemann for random bug fixes, the first instruction 42992 scheduler, initial C++ support, function integration, NS32k, SPARC 42993 and M88k machine description work, delay slot scheduling. 42994 42995 * Andreas Tobler for his work porting libgcj to Darwin. 42996 42997 * Teemu Torma for thread safe exception handling support. 42998 42999 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 43000 definitions, and of the VAX machine description. 43001 43002 * Daniel Towner and Hariharan Sandanagobalane contributed and 43003 maintain the picoChip port. 43004 43005 * Tom Tromey for internationalization support and for his many Java 43006 contributions and libgcj maintainership. 43007 43008 * Lassi Tuura for improvements to config.guess to determine HP 43009 processor types. 43010 43011 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 43012 43013 * Andy Vaught for the design and initial implementation of the GNU 43014 Fortran front end. 43015 43016 * Brent Verner for work with the libstdc++ cshadow files and their 43017 associated configure steps. 43018 43019 * Todd Vierling for contributions for NetBSD ports. 43020 43021 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 43022 guidance. 43023 43024 * Dean Wakerley for converting the install documentation from HTML to 43025 texinfo in time for GCC 3.0. 43026 43027 * Krister Walfridsson for random bug fixes. 43028 43029 * Feng Wang for contributions to GNU Fortran. 43030 43031 * Stephen M. Webb for time and effort on making libstdc++ shadow 43032 files work with the tricky Solaris 8+ headers, and for pushing the 43033 build-time header tree. Also, for starting and driving the 43034 '<regex>' effort. 43035 43036 * John Wehle for various improvements for the x86 code generator, 43037 related infrastructure improvements to help x86 code generation, 43038 value range propagation and other work, WE32k port. 43039 43040 * Ulrich Weigand for work on the s390 port. 43041 43042 * Zack Weinberg for major work on cpplib and various other bug fixes. 43043 43044 * Matt Welsh for help with Linux Threads support in GCJ. 43045 43046 * Urban Widmark for help fixing java.io. 43047 43048 * Mark Wielaard for new Java library code and his work integrating 43049 with Classpath. 43050 43051 * Dale Wiles helped port GCC to the Tahoe. 43052 43053 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 43054 43055 * Jim Wilson for his direction via the steering committee, tackling 43056 hard problems in various places that nobody else wanted to work on, 43057 strength reduction and other loop optimizations. 43058 43059 * Paul Woegerer and Tal Agmon for the CRX port. 43060 43061 * Carlo Wood for various fixes. 43062 43063 * Tom Wood for work on the m88k port. 43064 43065 * Chung-Ju Wu for his work on the Andes NDS32 port. 43066 43067 * Canqun Yang for work on GNU Fortran. 43068 43069 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 43070 description for the Tron architecture (specifically, the Gmicro). 43071 43072 * Kevin Zachmann helped port GCC to the Tahoe. 43073 43074 * Ayal Zaks for Swing Modulo Scheduling (SMS). 43075 43076 * Xiaoqiang Zhang for work on GNU Fortran. 43077 43078 * Gilles Zunino for help porting Java to Irix. 43079 43080 The following people are recognized for their contributions to GNAT, 43081the Ada front end of GCC: 43082 * Bernard Banner 43083 43084 * Romain Berrendonner 43085 43086 * Geert Bosch 43087 43088 * Emmanuel Briot 43089 43090 * Joel Brobecker 43091 43092 * Ben Brosgol 43093 43094 * Vincent Celier 43095 43096 * Arnaud Charlet 43097 43098 * Chien Chieng 43099 43100 * Cyrille Comar 43101 43102 * Cyrille Crozes 43103 43104 * Robert Dewar 43105 43106 * Gary Dismukes 43107 43108 * Robert Duff 43109 43110 * Ed Falis 43111 43112 * Ramon Fernandez 43113 43114 * Sam Figueroa 43115 43116 * Vasiliy Fofanov 43117 43118 * Michael Friess 43119 43120 * Franco Gasperoni 43121 43122 * Ted Giering 43123 43124 * Matthew Gingell 43125 43126 * Laurent Guerby 43127 43128 * Jerome Guitton 43129 43130 * Olivier Hainque 43131 43132 * Jerome Hugues 43133 43134 * Hristian Kirtchev 43135 43136 * Jerome Lambourg 43137 43138 * Bruno Leclerc 43139 43140 * Albert Lee 43141 43142 * Sean McNeil 43143 43144 * Javier Miranda 43145 43146 * Laurent Nana 43147 43148 * Pascal Obry 43149 43150 * Dong-Ik Oh 43151 43152 * Laurent Pautet 43153 43154 * Brett Porter 43155 43156 * Thomas Quinot 43157 43158 * Nicolas Roche 43159 43160 * Pat Rogers 43161 43162 * Jose Ruiz 43163 43164 * Douglas Rupp 43165 43166 * Sergey Rybin 43167 43168 * Gail Schenker 43169 43170 * Ed Schonberg 43171 43172 * Nicolas Setton 43173 43174 * Samuel Tardieu 43175 43176 The following people are recognized for their contributions of new 43177features, bug reports, testing and integration of classpath/libgcj for 43178GCC version 4.1: 43179 * Lillian Angel for 'JTree' implementation and lots Free Swing 43180 additions and bug fixes. 43181 43182 * Wolfgang Baer for 'GapContent' bug fixes. 43183 43184 * Anthony Balkissoon for 'JList', Free Swing 1.5 updates and mouse 43185 event fixes, lots of Free Swing work including 'JTable' editing. 43186 43187 * Stuart Ballard for RMI constant fixes. 43188 43189 * Goffredo Baroncelli for 'HTTPURLConnection' fixes. 43190 43191 * Gary Benson for 'MessageFormat' fixes. 43192 43193 * Daniel Bonniot for 'Serialization' fixes. 43194 43195 * Chris Burdess for lots of gnu.xml and http protocol fixes, 'StAX' 43196 and 'DOM xml:id' support. 43197 43198 * Ka-Hing Cheung for 'TreePath' and 'TreeSelection' fixes. 43199 43200 * Archie Cobbs for build fixes, VM interface updates, 43201 'URLClassLoader' updates. 43202 43203 * Kelley Cook for build fixes. 43204 43205 * Martin Cordova for Suggestions for better 'SocketTimeoutException'. 43206 43207 * David Daney for 'BitSet' bug fixes, 'HttpURLConnection' rewrite and 43208 improvements. 43209 43210 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 43211 2D support. Lots of imageio framework additions, lots of AWT and 43212 Free Swing bug fixes. 43213 43214 * Jeroen Frijters for 'ClassLoader' and nio cleanups, serialization 43215 fixes, better 'Proxy' support, bug fixes and IKVM integration. 43216 43217 * Santiago Gala for 'AccessControlContext' fixes. 43218 43219 * Nicolas Geoffray for 'VMClassLoader' and 'AccessController' 43220 improvements. 43221 43222 * David Gilbert for 'basic' and 'metal' icon and plaf support and 43223 lots of documenting, Lots of Free Swing and metal theme additions. 43224 'MetalIconFactory' implementation. 43225 43226 * Anthony Green for 'MIDI' framework, 'ALSA' and 'DSSI' providers. 43227 43228 * Andrew Haley for 'Serialization' and 'URLClassLoader' fixes, gcj 43229 build speedups. 43230 43231 * Kim Ho for 'JFileChooser' implementation. 43232 43233 * Andrew John Hughes for 'Locale' and net fixes, URI RFC2986 updates, 43234 'Serialization' fixes, 'Properties' XML support and generic branch 43235 work, VMIntegration guide update. 43236 43237 * Bastiaan Huisman for 'TimeZone' bug fixing. 43238 43239 * Andreas Jaeger for mprec updates. 43240 43241 * Paul Jenner for better '-Werror' support. 43242 43243 * Ito Kazumitsu for 'NetworkInterface' implementation and updates. 43244 43245 * Roman Kennke for 'BoxLayout', 'GrayFilter' and 'SplitPane', plus 43246 bug fixes all over. Lots of Free Swing work including styled text. 43247 43248 * Simon Kitching for 'String' cleanups and optimization suggestions. 43249 43250 * Michael Koch for configuration fixes, 'Locale' updates, bug and 43251 build fixes. 43252 43253 * Guilhem Lavaux for configuration, thread and channel fixes and 43254 Kaffe integration. JCL native 'Pointer' updates. Logger bug 43255 fixes. 43256 43257 * David Lichteblau for JCL support library global/local reference 43258 cleanups. 43259 43260 * Aaron Luchko for JDWP updates and documentation fixes. 43261 43262 * Ziga Mahkovec for 'Graphics2D' upgraded to Cairo 0.5 and new regex 43263 features. 43264 43265 * Sven de Marothy for BMP imageio support, CSS and 'TextLayout' 43266 fixes. 'GtkImage' rewrite, 2D, awt, free swing and date/time fixes 43267 and implementing the Qt4 peers. 43268 43269 * Casey Marshall for crypto algorithm fixes, 'FileChannel' lock, 43270 'SystemLogger' and 'FileHandler' rotate implementations, NIO 43271 'FileChannel.map' support, security and policy updates. 43272 43273 * Bryce McKinlay for RMI work. 43274 43275 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 43276 testing and documenting. 43277 43278 * Kalle Olavi Niemitalo for build fixes. 43279 43280 * Rainer Orth for build fixes. 43281 43282 * Andrew Overholt for 'File' locking fixes. 43283 43284 * Ingo Proetel for 'Image', 'Logger' and 'URLClassLoader' updates. 43285 43286 * Olga Rodimina for 'MenuSelectionManager' implementation. 43287 43288 * Jan Roehrich for 'BasicTreeUI' and 'JTree' fixes. 43289 43290 * Julian Scheid for documentation updates and gjdoc support. 43291 43292 * Christian Schlichtherle for zip fixes and cleanups. 43293 43294 * Robert Schuster for documentation updates and beans fixes, 43295 'TreeNode' enumerations and 'ActionCommand' and various fixes, XML 43296 and URL, AWT and Free Swing bug fixes. 43297 43298 * Keith Seitz for lots of JDWP work. 43299 43300 * Christian Thalinger for 64-bit cleanups, Configuration and VM 43301 interface fixes and 'CACAO' integration, 'fdlibm' updates. 43302 43303 * Gael Thomas for 'VMClassLoader' boot packages support suggestions. 43304 43305 * Andreas Tobler for Darwin and Solaris testing and fixing, 'Qt4' 43306 support for Darwin/OS X, 'Graphics2D' support, 'gtk+' updates. 43307 43308 * Dalibor Topic for better 'DEBUG' support, build cleanups and Kaffe 43309 integration. 'Qt4' build infrastructure, 'SHA1PRNG' and 43310 'GdkPixbugDecoder' updates. 43311 43312 * Tom Tromey for Eclipse integration, generics work, lots of bug 43313 fixes and gcj integration including coordinating The Big Merge. 43314 43315 * Mark Wielaard for bug fixes, packaging and release management, 43316 'Clipboard' implementation, system call interrupts and network 43317 timeouts and 'GdkPixpufDecoder' fixes. 43318 43319 In addition to the above, all of which also contributed time and energy 43320in testing GCC, we would like to thank the following for their 43321contributions to testing: 43322 43323 * Michael Abd-El-Malek 43324 43325 * Thomas Arend 43326 43327 * Bonzo Armstrong 43328 43329 * Steven Ashe 43330 43331 * Chris Baldwin 43332 43333 * David Billinghurst 43334 43335 * Jim Blandy 43336 43337 * Stephane Bortzmeyer 43338 43339 * Horst von Brand 43340 43341 * Frank Braun 43342 43343 * Rodney Brown 43344 43345 * Sidney Cadot 43346 43347 * Bradford Castalia 43348 43349 * Robert Clark 43350 43351 * Jonathan Corbet 43352 43353 * Ralph Doncaster 43354 43355 * Richard Emberson 43356 43357 * Levente Farkas 43358 43359 * Graham Fawcett 43360 43361 * Mark Fernyhough 43362 43363 * Robert A. French 43364 43365 * Jo"rgen Freyh 43366 43367 * Mark K. Gardner 43368 43369 * Charles-Antoine Gauthier 43370 43371 * Yung Shing Gene 43372 43373 * David Gilbert 43374 43375 * Simon Gornall 43376 43377 * Fred Gray 43378 43379 * John Griffin 43380 43381 * Patrik Hagglund 43382 43383 * Phil Hargett 43384 43385 * Amancio Hasty 43386 43387 * Takafumi Hayashi 43388 43389 * Bryan W. Headley 43390 43391 * Kevin B. Hendricks 43392 43393 * Joep Jansen 43394 43395 * Christian Joensson 43396 43397 * Michel Kern 43398 43399 * David Kidd 43400 43401 * Tobias Kuipers 43402 43403 * Anand Krishnaswamy 43404 43405 * A. O. V. Le Blanc 43406 43407 * llewelly 43408 43409 * Damon Love 43410 43411 * Brad Lucier 43412 43413 * Matthias Klose 43414 43415 * Martin Knoblauch 43416 43417 * Rick Lutowski 43418 43419 * Jesse Macnish 43420 43421 * Stefan Morrell 43422 43423 * Anon A. Mous 43424 43425 * Matthias Mueller 43426 43427 * Pekka Nikander 43428 43429 * Rick Niles 43430 43431 * Jon Olson 43432 43433 * Magnus Persson 43434 43435 * Chris Pollard 43436 43437 * Richard Polton 43438 43439 * Derk Reefman 43440 43441 * David Rees 43442 43443 * Paul Reilly 43444 43445 * Tom Reilly 43446 43447 * Torsten Rueger 43448 43449 * Danny Sadinoff 43450 43451 * Marc Schifer 43452 43453 * Erik Schnetter 43454 43455 * Wayne K. Schroll 43456 43457 * David Schuler 43458 43459 * Vin Shelton 43460 43461 * Tim Souder 43462 43463 * Adam Sulmicki 43464 43465 * Bill Thorson 43466 43467 * George Talbot 43468 43469 * Pedro A. M. Vazquez 43470 43471 * Gregory Warnes 43472 43473 * Ian Watson 43474 43475 * David E. Young 43476 43477 * And many others 43478 43479 And finally we'd like to thank everyone who uses the compiler, provides 43480feedback and generally reminds us why we're doing this work in the first 43481place. 43482 43483 43484File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 43485 43486Option Index 43487************ 43488 43489GCC's command line options are indexed here without any initial '-' or 43490'--'. Where an option has both positive and negative forms (such as 43491'-fOPTION' and '-fno-OPTION'), relevant entries in the manual are 43492indexed under the most appropriate form; it may sometimes be useful to 43493look up both forms. 43494 43495�[index�] 43496* Menu: 43497 43498* fltrans: Internal flags. (line 18) 43499* fltrans-output-list: Internal flags. (line 23) 43500* fresolution: Internal flags. (line 27) 43501* fwpa: Internal flags. (line 9) 43502* msoft-float: Soft float library routines. 43503 (line 6) 43504 43505 43506File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 43507 43508Concept Index 43509************* 43510 43511�[index�] 43512* Menu: 43513 43514* ! in constraint: Multi-Alternative. (line 47) 43515* # in constraint: Modifiers. (line 78) 43516* # in template: Output Template. (line 66) 43517* #pragma: Misc. (line 387) 43518* $ in constraint: Multi-Alternative. (line 56) 43519* % in constraint: Modifiers. (line 52) 43520* % in GTY option: GTY Options. (line 18) 43521* % in template: Output Template. (line 6) 43522* & in constraint: Modifiers. (line 25) 43523* (gimple_stmt_iterator: GIMPLE API. (line 30) 43524* (nil): RTL Objects. (line 73) 43525* * in constraint: Modifiers. (line 83) 43526* * in template: Output Statement. (line 29) 43527* *gimple_build_asm_vec: GIMPLE_ASM. (line 6) 43528* *gimple_build_assign: GIMPLE_ASSIGN. (line 6) 43529* *gimple_build_assign <1>: GIMPLE_ASSIGN. (line 18) 43530* *gimple_build_assign <2>: GIMPLE_ASSIGN. (line 29) 43531* *gimple_build_assign <3>: GIMPLE_ASSIGN. (line 35) 43532* *gimple_build_bind: GIMPLE_BIND. (line 6) 43533* *gimple_build_call: GIMPLE_CALL. (line 6) 43534* *gimple_build_call_from_tree: GIMPLE_CALL. (line 15) 43535* *gimple_build_call_vec: GIMPLE_CALL. (line 23) 43536* *gimple_build_catch: GIMPLE_CATCH. (line 6) 43537* *gimple_build_cond: GIMPLE_COND. (line 6) 43538* *gimple_build_cond_from_tree: GIMPLE_COND. (line 14) 43539* *gimple_build_debug_bind: GIMPLE_DEBUG. (line 6) 43540* *gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 6) 43541* *gimple_build_goto: GIMPLE_GOTO. (line 6) 43542* *gimple_build_label: GIMPLE_LABEL. (line 6) 43543* *gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD. 43544 (line 6) 43545* *gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE. 43546 (line 6) 43547* *gimple_build_omp_continue: GIMPLE_OMP_CONTINUE. 43548 (line 6) 43549* *gimple_build_omp_critical: GIMPLE_OMP_CRITICAL. 43550 (line 6) 43551* *gimple_build_omp_for: GIMPLE_OMP_FOR. (line 6) 43552* *gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL. 43553 (line 6) 43554* *gimple_build_omp_sections: GIMPLE_OMP_SECTIONS. 43555 (line 6) 43556* *gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 6) 43557* *gimple_build_resx: GIMPLE_RESX. (line 6) 43558* *gimple_build_return: GIMPLE_RETURN. (line 6) 43559* *gimple_build_switch: GIMPLE_SWITCH. (line 6) 43560* *gimple_build_try: GIMPLE_TRY. (line 6) 43561* + in constraint: Modifiers. (line 12) 43562* -fsection-anchors: Special Accessors. (line 117) 43563* -fsection-anchors <1>: Anchored Addresses. (line 6) 43564* /c in RTL dump: Flags. (line 221) 43565* /f in RTL dump: Flags. (line 229) 43566* /i in RTL dump: Flags. (line 274) 43567* /j in RTL dump: Flags. (line 286) 43568* /s in RTL dump: Flags. (line 245) 43569* /u in RTL dump: Flags. (line 296) 43570* /v in RTL dump: Flags. (line 328) 43571* 0 in constraint: Simple Constraints. (line 128) 43572* < in constraint: Simple Constraints. (line 47) 43573* = in constraint: Modifiers. (line 8) 43574* > in constraint: Simple Constraints. (line 59) 43575* ? in constraint: Multi-Alternative. (line 41) 43576* \: Output Template. (line 46) 43577* ^ in constraint: Multi-Alternative. (line 52) 43578* __absvdi2: Integer library routines. 43579 (line 106) 43580* __absvsi2: Integer library routines. 43581 (line 105) 43582* __addda3: Fixed-point fractional library routines. 43583 (line 52) 43584* __adddf3: Soft float library routines. 43585 (line 22) 43586* __adddq3: Fixed-point fractional library routines. 43587 (line 39) 43588* __addha3: Fixed-point fractional library routines. 43589 (line 49) 43590* __addhq3: Fixed-point fractional library routines. 43591 (line 37) 43592* __addqq3: Fixed-point fractional library routines. 43593 (line 35) 43594* __addsa3: Fixed-point fractional library routines. 43595 (line 51) 43596* __addsf3: Soft float library routines. 43597 (line 21) 43598* __addsq3: Fixed-point fractional library routines. 43599 (line 38) 43600* __addta3: Fixed-point fractional library routines. 43601 (line 53) 43602* __addtf3: Soft float library routines. 43603 (line 23) 43604* __adduda3: Fixed-point fractional library routines. 43605 (line 59) 43606* __addudq3: Fixed-point fractional library routines. 43607 (line 47) 43608* __adduha3: Fixed-point fractional library routines. 43609 (line 55) 43610* __adduhq3: Fixed-point fractional library routines. 43611 (line 43) 43612* __adduqq3: Fixed-point fractional library routines. 43613 (line 41) 43614* __addusa3: Fixed-point fractional library routines. 43615 (line 57) 43616* __addusq3: Fixed-point fractional library routines. 43617 (line 45) 43618* __adduta3: Fixed-point fractional library routines. 43619 (line 61) 43620* __addvdi3: Integer library routines. 43621 (line 110) 43622* __addvsi3: Integer library routines. 43623 (line 109) 43624* __addxf3: Soft float library routines. 43625 (line 25) 43626* __ashlda3: Fixed-point fractional library routines. 43627 (line 358) 43628* __ashldi3: Integer library routines. 43629 (line 13) 43630* __ashldq3: Fixed-point fractional library routines. 43631 (line 346) 43632* __ashlha3: Fixed-point fractional library routines. 43633 (line 356) 43634* __ashlhq3: Fixed-point fractional library routines. 43635 (line 344) 43636* __ashlqq3: Fixed-point fractional library routines. 43637 (line 343) 43638* __ashlsa3: Fixed-point fractional library routines. 43639 (line 357) 43640* __ashlsi3: Integer library routines. 43641 (line 12) 43642* __ashlsq3: Fixed-point fractional library routines. 43643 (line 345) 43644* __ashlta3: Fixed-point fractional library routines. 43645 (line 359) 43646* __ashlti3: Integer library routines. 43647 (line 14) 43648* __ashluda3: Fixed-point fractional library routines. 43649 (line 365) 43650* __ashludq3: Fixed-point fractional library routines. 43651 (line 354) 43652* __ashluha3: Fixed-point fractional library routines. 43653 (line 361) 43654* __ashluhq3: Fixed-point fractional library routines. 43655 (line 350) 43656* __ashluqq3: Fixed-point fractional library routines. 43657 (line 348) 43658* __ashlusa3: Fixed-point fractional library routines. 43659 (line 363) 43660* __ashlusq3: Fixed-point fractional library routines. 43661 (line 352) 43662* __ashluta3: Fixed-point fractional library routines. 43663 (line 367) 43664* __ashrda3: Fixed-point fractional library routines. 43665 (line 378) 43666* __ashrdi3: Integer library routines. 43667 (line 18) 43668* __ashrdq3: Fixed-point fractional library routines. 43669 (line 374) 43670* __ashrha3: Fixed-point fractional library routines. 43671 (line 376) 43672* __ashrhq3: Fixed-point fractional library routines. 43673 (line 372) 43674* __ashrqq3: Fixed-point fractional library routines. 43675 (line 371) 43676* __ashrsa3: Fixed-point fractional library routines. 43677 (line 377) 43678* __ashrsi3: Integer library routines. 43679 (line 17) 43680* __ashrsq3: Fixed-point fractional library routines. 43681 (line 373) 43682* __ashrta3: Fixed-point fractional library routines. 43683 (line 379) 43684* __ashrti3: Integer library routines. 43685 (line 19) 43686* __bid_adddd3: Decimal float library routines. 43687 (line 23) 43688* __bid_addsd3: Decimal float library routines. 43689 (line 19) 43690* __bid_addtd3: Decimal float library routines. 43691 (line 27) 43692* __bid_divdd3: Decimal float library routines. 43693 (line 66) 43694* __bid_divsd3: Decimal float library routines. 43695 (line 62) 43696* __bid_divtd3: Decimal float library routines. 43697 (line 70) 43698* __bid_eqdd2: Decimal float library routines. 43699 (line 258) 43700* __bid_eqsd2: Decimal float library routines. 43701 (line 256) 43702* __bid_eqtd2: Decimal float library routines. 43703 (line 260) 43704* __bid_extendddtd2: Decimal float library routines. 43705 (line 91) 43706* __bid_extendddtf: Decimal float library routines. 43707 (line 139) 43708* __bid_extendddxf: Decimal float library routines. 43709 (line 133) 43710* __bid_extenddfdd: Decimal float library routines. 43711 (line 146) 43712* __bid_extenddftd: Decimal float library routines. 43713 (line 106) 43714* __bid_extendsddd2: Decimal float library routines. 43715 (line 87) 43716* __bid_extendsddf: Decimal float library routines. 43717 (line 127) 43718* __bid_extendsdtd2: Decimal float library routines. 43719 (line 89) 43720* __bid_extendsdtf: Decimal float library routines. 43721 (line 137) 43722* __bid_extendsdxf: Decimal float library routines. 43723 (line 131) 43724* __bid_extendsfdd: Decimal float library routines. 43725 (line 102) 43726* __bid_extendsfsd: Decimal float library routines. 43727 (line 144) 43728* __bid_extendsftd: Decimal float library routines. 43729 (line 104) 43730* __bid_extendtftd: Decimal float library routines. 43731 (line 148) 43732* __bid_extendxftd: Decimal float library routines. 43733 (line 108) 43734* __bid_fixdddi: Decimal float library routines. 43735 (line 169) 43736* __bid_fixddsi: Decimal float library routines. 43737 (line 161) 43738* __bid_fixsddi: Decimal float library routines. 43739 (line 167) 43740* __bid_fixsdsi: Decimal float library routines. 43741 (line 159) 43742* __bid_fixtddi: Decimal float library routines. 43743 (line 171) 43744* __bid_fixtdsi: Decimal float library routines. 43745 (line 163) 43746* __bid_fixunsdddi: Decimal float library routines. 43747 (line 186) 43748* __bid_fixunsddsi: Decimal float library routines. 43749 (line 177) 43750* __bid_fixunssddi: Decimal float library routines. 43751 (line 184) 43752* __bid_fixunssdsi: Decimal float library routines. 43753 (line 175) 43754* __bid_fixunstddi: Decimal float library routines. 43755 (line 188) 43756* __bid_fixunstdsi: Decimal float library routines. 43757 (line 179) 43758* __bid_floatdidd: Decimal float library routines. 43759 (line 204) 43760* __bid_floatdisd: Decimal float library routines. 43761 (line 202) 43762* __bid_floatditd: Decimal float library routines. 43763 (line 206) 43764* __bid_floatsidd: Decimal float library routines. 43765 (line 195) 43766* __bid_floatsisd: Decimal float library routines. 43767 (line 193) 43768* __bid_floatsitd: Decimal float library routines. 43769 (line 197) 43770* __bid_floatunsdidd: Decimal float library routines. 43771 (line 222) 43772* __bid_floatunsdisd: Decimal float library routines. 43773 (line 220) 43774* __bid_floatunsditd: Decimal float library routines. 43775 (line 224) 43776* __bid_floatunssidd: Decimal float library routines. 43777 (line 213) 43778* __bid_floatunssisd: Decimal float library routines. 43779 (line 211) 43780* __bid_floatunssitd: Decimal float library routines. 43781 (line 215) 43782* __bid_gedd2: Decimal float library routines. 43783 (line 276) 43784* __bid_gesd2: Decimal float library routines. 43785 (line 274) 43786* __bid_getd2: Decimal float library routines. 43787 (line 278) 43788* __bid_gtdd2: Decimal float library routines. 43789 (line 303) 43790* __bid_gtsd2: Decimal float library routines. 43791 (line 301) 43792* __bid_gttd2: Decimal float library routines. 43793 (line 305) 43794* __bid_ledd2: Decimal float library routines. 43795 (line 294) 43796* __bid_lesd2: Decimal float library routines. 43797 (line 292) 43798* __bid_letd2: Decimal float library routines. 43799 (line 296) 43800* __bid_ltdd2: Decimal float library routines. 43801 (line 285) 43802* __bid_ltsd2: Decimal float library routines. 43803 (line 283) 43804* __bid_lttd2: Decimal float library routines. 43805 (line 287) 43806* __bid_muldd3: Decimal float library routines. 43807 (line 52) 43808* __bid_mulsd3: Decimal float library routines. 43809 (line 48) 43810* __bid_multd3: Decimal float library routines. 43811 (line 56) 43812* __bid_nedd2: Decimal float library routines. 43813 (line 267) 43814* __bid_negdd2: Decimal float library routines. 43815 (line 77) 43816* __bid_negsd2: Decimal float library routines. 43817 (line 75) 43818* __bid_negtd2: Decimal float library routines. 43819 (line 79) 43820* __bid_nesd2: Decimal float library routines. 43821 (line 265) 43822* __bid_netd2: Decimal float library routines. 43823 (line 269) 43824* __bid_subdd3: Decimal float library routines. 43825 (line 37) 43826* __bid_subsd3: Decimal float library routines. 43827 (line 33) 43828* __bid_subtd3: Decimal float library routines. 43829 (line 41) 43830* __bid_truncdddf: Decimal float library routines. 43831 (line 152) 43832* __bid_truncddsd2: Decimal float library routines. 43833 (line 93) 43834* __bid_truncddsf: Decimal float library routines. 43835 (line 123) 43836* __bid_truncdfsd: Decimal float library routines. 43837 (line 110) 43838* __bid_truncsdsf: Decimal float library routines. 43839 (line 150) 43840* __bid_trunctddd2: Decimal float library routines. 43841 (line 97) 43842* __bid_trunctddf: Decimal float library routines. 43843 (line 129) 43844* __bid_trunctdsd2: Decimal float library routines. 43845 (line 95) 43846* __bid_trunctdsf: Decimal float library routines. 43847 (line 125) 43848* __bid_trunctdtf: Decimal float library routines. 43849 (line 154) 43850* __bid_trunctdxf: Decimal float library routines. 43851 (line 135) 43852* __bid_trunctfdd: Decimal float library routines. 43853 (line 118) 43854* __bid_trunctfsd: Decimal float library routines. 43855 (line 114) 43856* __bid_truncxfdd: Decimal float library routines. 43857 (line 116) 43858* __bid_truncxfsd: Decimal float library routines. 43859 (line 112) 43860* __bid_unorddd2: Decimal float library routines. 43861 (line 234) 43862* __bid_unordsd2: Decimal float library routines. 43863 (line 232) 43864* __bid_unordtd2: Decimal float library routines. 43865 (line 236) 43866* __bswapdi2: Integer library routines. 43867 (line 161) 43868* __bswapsi2: Integer library routines. 43869 (line 160) 43870* __builtin_classify_type: Varargs. (line 48) 43871* __builtin_next_arg: Varargs. (line 39) 43872* __builtin_saveregs: Varargs. (line 22) 43873* __chkp_bndcl: Misc. (line 649) 43874* __chkp_bndcu: Misc. (line 655) 43875* __chkp_bndldx: Misc. (line 643) 43876* __chkp_bndmk: Misc. (line 630) 43877* __chkp_bndret: Misc. (line 661) 43878* __chkp_bndstx: Misc. (line 637) 43879* __chkp_intersect: Misc. (line 667) 43880* __chkp_narrow: Misc. (line 672) 43881* __chkp_sizeof: Misc. (line 678) 43882* __clear_cache: Miscellaneous routines. 43883 (line 9) 43884* __clzdi2: Integer library routines. 43885 (line 130) 43886* __clzsi2: Integer library routines. 43887 (line 129) 43888* __clzti2: Integer library routines. 43889 (line 131) 43890* __cmpda2: Fixed-point fractional library routines. 43891 (line 458) 43892* __cmpdf2: Soft float library routines. 43893 (line 163) 43894* __cmpdi2: Integer library routines. 43895 (line 86) 43896* __cmpdq2: Fixed-point fractional library routines. 43897 (line 447) 43898* __cmpha2: Fixed-point fractional library routines. 43899 (line 456) 43900* __cmphq2: Fixed-point fractional library routines. 43901 (line 445) 43902* __cmpqq2: Fixed-point fractional library routines. 43903 (line 444) 43904* __cmpsa2: Fixed-point fractional library routines. 43905 (line 457) 43906* __cmpsf2: Soft float library routines. 43907 (line 162) 43908* __cmpsq2: Fixed-point fractional library routines. 43909 (line 446) 43910* __cmpta2: Fixed-point fractional library routines. 43911 (line 459) 43912* __cmptf2: Soft float library routines. 43913 (line 164) 43914* __cmpti2: Integer library routines. 43915 (line 87) 43916* __cmpuda2: Fixed-point fractional library routines. 43917 (line 464) 43918* __cmpudq2: Fixed-point fractional library routines. 43919 (line 454) 43920* __cmpuha2: Fixed-point fractional library routines. 43921 (line 461) 43922* __cmpuhq2: Fixed-point fractional library routines. 43923 (line 451) 43924* __cmpuqq2: Fixed-point fractional library routines. 43925 (line 449) 43926* __cmpusa2: Fixed-point fractional library routines. 43927 (line 463) 43928* __cmpusq2: Fixed-point fractional library routines. 43929 (line 452) 43930* __cmputa2: Fixed-point fractional library routines. 43931 (line 466) 43932* __CTOR_LIST__: Initialization. (line 25) 43933* __ctzdi2: Integer library routines. 43934 (line 137) 43935* __ctzsi2: Integer library routines. 43936 (line 136) 43937* __ctzti2: Integer library routines. 43938 (line 138) 43939* __divda3: Fixed-point fractional library routines. 43940 (line 234) 43941* __divdc3: Soft float library routines. 43942 (line 250) 43943* __divdf3: Soft float library routines. 43944 (line 47) 43945* __divdi3: Integer library routines. 43946 (line 24) 43947* __divdq3: Fixed-point fractional library routines. 43948 (line 229) 43949* __divha3: Fixed-point fractional library routines. 43950 (line 231) 43951* __divhq3: Fixed-point fractional library routines. 43952 (line 227) 43953* __divqq3: Fixed-point fractional library routines. 43954 (line 225) 43955* __divsa3: Fixed-point fractional library routines. 43956 (line 233) 43957* __divsc3: Soft float library routines. 43958 (line 248) 43959* __divsf3: Soft float library routines. 43960 (line 46) 43961* __divsi3: Integer library routines. 43962 (line 23) 43963* __divsq3: Fixed-point fractional library routines. 43964 (line 228) 43965* __divta3: Fixed-point fractional library routines. 43966 (line 235) 43967* __divtc3: Soft float library routines. 43968 (line 252) 43969* __divtf3: Soft float library routines. 43970 (line 48) 43971* __divti3: Integer library routines. 43972 (line 25) 43973* __divxc3: Soft float library routines. 43974 (line 254) 43975* __divxf3: Soft float library routines. 43976 (line 50) 43977* __dpd_adddd3: Decimal float library routines. 43978 (line 21) 43979* __dpd_addsd3: Decimal float library routines. 43980 (line 17) 43981* __dpd_addtd3: Decimal float library routines. 43982 (line 25) 43983* __dpd_divdd3: Decimal float library routines. 43984 (line 64) 43985* __dpd_divsd3: Decimal float library routines. 43986 (line 60) 43987* __dpd_divtd3: Decimal float library routines. 43988 (line 68) 43989* __dpd_eqdd2: Decimal float library routines. 43990 (line 257) 43991* __dpd_eqsd2: Decimal float library routines. 43992 (line 255) 43993* __dpd_eqtd2: Decimal float library routines. 43994 (line 259) 43995* __dpd_extendddtd2: Decimal float library routines. 43996 (line 90) 43997* __dpd_extendddtf: Decimal float library routines. 43998 (line 138) 43999* __dpd_extendddxf: Decimal float library routines. 44000 (line 132) 44001* __dpd_extenddfdd: Decimal float library routines. 44002 (line 145) 44003* __dpd_extenddftd: Decimal float library routines. 44004 (line 105) 44005* __dpd_extendsddd2: Decimal float library routines. 44006 (line 86) 44007* __dpd_extendsddf: Decimal float library routines. 44008 (line 126) 44009* __dpd_extendsdtd2: Decimal float library routines. 44010 (line 88) 44011* __dpd_extendsdtf: Decimal float library routines. 44012 (line 136) 44013* __dpd_extendsdxf: Decimal float library routines. 44014 (line 130) 44015* __dpd_extendsfdd: Decimal float library routines. 44016 (line 101) 44017* __dpd_extendsfsd: Decimal float library routines. 44018 (line 143) 44019* __dpd_extendsftd: Decimal float library routines. 44020 (line 103) 44021* __dpd_extendtftd: Decimal float library routines. 44022 (line 147) 44023* __dpd_extendxftd: Decimal float library routines. 44024 (line 107) 44025* __dpd_fixdddi: Decimal float library routines. 44026 (line 168) 44027* __dpd_fixddsi: Decimal float library routines. 44028 (line 160) 44029* __dpd_fixsddi: Decimal float library routines. 44030 (line 166) 44031* __dpd_fixsdsi: Decimal float library routines. 44032 (line 158) 44033* __dpd_fixtddi: Decimal float library routines. 44034 (line 170) 44035* __dpd_fixtdsi: Decimal float library routines. 44036 (line 162) 44037* __dpd_fixunsdddi: Decimal float library routines. 44038 (line 185) 44039* __dpd_fixunsddsi: Decimal float library routines. 44040 (line 176) 44041* __dpd_fixunssddi: Decimal float library routines. 44042 (line 183) 44043* __dpd_fixunssdsi: Decimal float library routines. 44044 (line 174) 44045* __dpd_fixunstddi: Decimal float library routines. 44046 (line 187) 44047* __dpd_fixunstdsi: Decimal float library routines. 44048 (line 178) 44049* __dpd_floatdidd: Decimal float library routines. 44050 (line 203) 44051* __dpd_floatdisd: Decimal float library routines. 44052 (line 201) 44053* __dpd_floatditd: Decimal float library routines. 44054 (line 205) 44055* __dpd_floatsidd: Decimal float library routines. 44056 (line 194) 44057* __dpd_floatsisd: Decimal float library routines. 44058 (line 192) 44059* __dpd_floatsitd: Decimal float library routines. 44060 (line 196) 44061* __dpd_floatunsdidd: Decimal float library routines. 44062 (line 221) 44063* __dpd_floatunsdisd: Decimal float library routines. 44064 (line 219) 44065* __dpd_floatunsditd: Decimal float library routines. 44066 (line 223) 44067* __dpd_floatunssidd: Decimal float library routines. 44068 (line 212) 44069* __dpd_floatunssisd: Decimal float library routines. 44070 (line 210) 44071* __dpd_floatunssitd: Decimal float library routines. 44072 (line 214) 44073* __dpd_gedd2: Decimal float library routines. 44074 (line 275) 44075* __dpd_gesd2: Decimal float library routines. 44076 (line 273) 44077* __dpd_getd2: Decimal float library routines. 44078 (line 277) 44079* __dpd_gtdd2: Decimal float library routines. 44080 (line 302) 44081* __dpd_gtsd2: Decimal float library routines. 44082 (line 300) 44083* __dpd_gttd2: Decimal float library routines. 44084 (line 304) 44085* __dpd_ledd2: Decimal float library routines. 44086 (line 293) 44087* __dpd_lesd2: Decimal float library routines. 44088 (line 291) 44089* __dpd_letd2: Decimal float library routines. 44090 (line 295) 44091* __dpd_ltdd2: Decimal float library routines. 44092 (line 284) 44093* __dpd_ltsd2: Decimal float library routines. 44094 (line 282) 44095* __dpd_lttd2: Decimal float library routines. 44096 (line 286) 44097* __dpd_muldd3: Decimal float library routines. 44098 (line 50) 44099* __dpd_mulsd3: Decimal float library routines. 44100 (line 46) 44101* __dpd_multd3: Decimal float library routines. 44102 (line 54) 44103* __dpd_nedd2: Decimal float library routines. 44104 (line 266) 44105* __dpd_negdd2: Decimal float library routines. 44106 (line 76) 44107* __dpd_negsd2: Decimal float library routines. 44108 (line 74) 44109* __dpd_negtd2: Decimal float library routines. 44110 (line 78) 44111* __dpd_nesd2: Decimal float library routines. 44112 (line 264) 44113* __dpd_netd2: Decimal float library routines. 44114 (line 268) 44115* __dpd_subdd3: Decimal float library routines. 44116 (line 35) 44117* __dpd_subsd3: Decimal float library routines. 44118 (line 31) 44119* __dpd_subtd3: Decimal float library routines. 44120 (line 39) 44121* __dpd_truncdddf: Decimal float library routines. 44122 (line 151) 44123* __dpd_truncddsd2: Decimal float library routines. 44124 (line 92) 44125* __dpd_truncddsf: Decimal float library routines. 44126 (line 122) 44127* __dpd_truncdfsd: Decimal float library routines. 44128 (line 109) 44129* __dpd_truncsdsf: Decimal float library routines. 44130 (line 149) 44131* __dpd_trunctddd2: Decimal float library routines. 44132 (line 96) 44133* __dpd_trunctddf: Decimal float library routines. 44134 (line 128) 44135* __dpd_trunctdsd2: Decimal float library routines. 44136 (line 94) 44137* __dpd_trunctdsf: Decimal float library routines. 44138 (line 124) 44139* __dpd_trunctdtf: Decimal float library routines. 44140 (line 153) 44141* __dpd_trunctdxf: Decimal float library routines. 44142 (line 134) 44143* __dpd_trunctfdd: Decimal float library routines. 44144 (line 117) 44145* __dpd_trunctfsd: Decimal float library routines. 44146 (line 113) 44147* __dpd_truncxfdd: Decimal float library routines. 44148 (line 115) 44149* __dpd_truncxfsd: Decimal float library routines. 44150 (line 111) 44151* __dpd_unorddd2: Decimal float library routines. 44152 (line 233) 44153* __dpd_unordsd2: Decimal float library routines. 44154 (line 231) 44155* __dpd_unordtd2: Decimal float library routines. 44156 (line 235) 44157* __DTOR_LIST__: Initialization. (line 25) 44158* __eqdf2: Soft float library routines. 44159 (line 193) 44160* __eqsf2: Soft float library routines. 44161 (line 192) 44162* __eqtf2: Soft float library routines. 44163 (line 194) 44164* __extenddftf2: Soft float library routines. 44165 (line 67) 44166* __extenddfxf2: Soft float library routines. 44167 (line 68) 44168* __extendsfdf2: Soft float library routines. 44169 (line 64) 44170* __extendsftf2: Soft float library routines. 44171 (line 65) 44172* __extendsfxf2: Soft float library routines. 44173 (line 66) 44174* __ffsdi2: Integer library routines. 44175 (line 143) 44176* __ffsti2: Integer library routines. 44177 (line 144) 44178* __fixdfdi: Soft float library routines. 44179 (line 87) 44180* __fixdfsi: Soft float library routines. 44181 (line 80) 44182* __fixdfti: Soft float library routines. 44183 (line 93) 44184* __fixsfdi: Soft float library routines. 44185 (line 86) 44186* __fixsfsi: Soft float library routines. 44187 (line 79) 44188* __fixsfti: Soft float library routines. 44189 (line 92) 44190* __fixtfdi: Soft float library routines. 44191 (line 88) 44192* __fixtfsi: Soft float library routines. 44193 (line 81) 44194* __fixtfti: Soft float library routines. 44195 (line 94) 44196* __fixunsdfdi: Soft float library routines. 44197 (line 107) 44198* __fixunsdfsi: Soft float library routines. 44199 (line 100) 44200* __fixunsdfti: Soft float library routines. 44201 (line 114) 44202* __fixunssfdi: Soft float library routines. 44203 (line 106) 44204* __fixunssfsi: Soft float library routines. 44205 (line 99) 44206* __fixunssfti: Soft float library routines. 44207 (line 113) 44208* __fixunstfdi: Soft float library routines. 44209 (line 108) 44210* __fixunstfsi: Soft float library routines. 44211 (line 101) 44212* __fixunstfti: Soft float library routines. 44213 (line 115) 44214* __fixunsxfdi: Soft float library routines. 44215 (line 109) 44216* __fixunsxfsi: Soft float library routines. 44217 (line 102) 44218* __fixunsxfti: Soft float library routines. 44219 (line 116) 44220* __fixxfdi: Soft float library routines. 44221 (line 89) 44222* __fixxfsi: Soft float library routines. 44223 (line 82) 44224* __fixxfti: Soft float library routines. 44225 (line 95) 44226* __floatdidf: Soft float library routines. 44227 (line 127) 44228* __floatdisf: Soft float library routines. 44229 (line 126) 44230* __floatditf: Soft float library routines. 44231 (line 128) 44232* __floatdixf: Soft float library routines. 44233 (line 129) 44234* __floatsidf: Soft float library routines. 44235 (line 121) 44236* __floatsisf: Soft float library routines. 44237 (line 120) 44238* __floatsitf: Soft float library routines. 44239 (line 122) 44240* __floatsixf: Soft float library routines. 44241 (line 123) 44242* __floattidf: Soft float library routines. 44243 (line 133) 44244* __floattisf: Soft float library routines. 44245 (line 132) 44246* __floattitf: Soft float library routines. 44247 (line 134) 44248* __floattixf: Soft float library routines. 44249 (line 135) 44250* __floatundidf: Soft float library routines. 44251 (line 145) 44252* __floatundisf: Soft float library routines. 44253 (line 144) 44254* __floatunditf: Soft float library routines. 44255 (line 146) 44256* __floatundixf: Soft float library routines. 44257 (line 147) 44258* __floatunsidf: Soft float library routines. 44259 (line 139) 44260* __floatunsisf: Soft float library routines. 44261 (line 138) 44262* __floatunsitf: Soft float library routines. 44263 (line 140) 44264* __floatunsixf: Soft float library routines. 44265 (line 141) 44266* __floatuntidf: Soft float library routines. 44267 (line 151) 44268* __floatuntisf: Soft float library routines. 44269 (line 150) 44270* __floatuntitf: Soft float library routines. 44271 (line 152) 44272* __floatuntixf: Soft float library routines. 44273 (line 153) 44274* __fractdadf: Fixed-point fractional library routines. 44275 (line 643) 44276* __fractdadi: Fixed-point fractional library routines. 44277 (line 640) 44278* __fractdadq: Fixed-point fractional library routines. 44279 (line 623) 44280* __fractdaha2: Fixed-point fractional library routines. 44281 (line 624) 44282* __fractdahi: Fixed-point fractional library routines. 44283 (line 638) 44284* __fractdahq: Fixed-point fractional library routines. 44285 (line 621) 44286* __fractdaqi: Fixed-point fractional library routines. 44287 (line 637) 44288* __fractdaqq: Fixed-point fractional library routines. 44289 (line 620) 44290* __fractdasa2: Fixed-point fractional library routines. 44291 (line 625) 44292* __fractdasf: Fixed-point fractional library routines. 44293 (line 642) 44294* __fractdasi: Fixed-point fractional library routines. 44295 (line 639) 44296* __fractdasq: Fixed-point fractional library routines. 44297 (line 622) 44298* __fractdata2: Fixed-point fractional library routines. 44299 (line 626) 44300* __fractdati: Fixed-point fractional library routines. 44301 (line 641) 44302* __fractdauda: Fixed-point fractional library routines. 44303 (line 634) 44304* __fractdaudq: Fixed-point fractional library routines. 44305 (line 630) 44306* __fractdauha: Fixed-point fractional library routines. 44307 (line 632) 44308* __fractdauhq: Fixed-point fractional library routines. 44309 (line 628) 44310* __fractdauqq: Fixed-point fractional library routines. 44311 (line 627) 44312* __fractdausa: Fixed-point fractional library routines. 44313 (line 633) 44314* __fractdausq: Fixed-point fractional library routines. 44315 (line 629) 44316* __fractdauta: Fixed-point fractional library routines. 44317 (line 635) 44318* __fractdfda: Fixed-point fractional library routines. 44319 (line 1032) 44320* __fractdfdq: Fixed-point fractional library routines. 44321 (line 1029) 44322* __fractdfha: Fixed-point fractional library routines. 44323 (line 1030) 44324* __fractdfhq: Fixed-point fractional library routines. 44325 (line 1027) 44326* __fractdfqq: Fixed-point fractional library routines. 44327 (line 1026) 44328* __fractdfsa: Fixed-point fractional library routines. 44329 (line 1031) 44330* __fractdfsq: Fixed-point fractional library routines. 44331 (line 1028) 44332* __fractdfta: Fixed-point fractional library routines. 44333 (line 1033) 44334* __fractdfuda: Fixed-point fractional library routines. 44335 (line 1040) 44336* __fractdfudq: Fixed-point fractional library routines. 44337 (line 1037) 44338* __fractdfuha: Fixed-point fractional library routines. 44339 (line 1038) 44340* __fractdfuhq: Fixed-point fractional library routines. 44341 (line 1035) 44342* __fractdfuqq: Fixed-point fractional library routines. 44343 (line 1034) 44344* __fractdfusa: Fixed-point fractional library routines. 44345 (line 1039) 44346* __fractdfusq: Fixed-point fractional library routines. 44347 (line 1036) 44348* __fractdfuta: Fixed-point fractional library routines. 44349 (line 1041) 44350* __fractdida: Fixed-point fractional library routines. 44351 (line 982) 44352* __fractdidq: Fixed-point fractional library routines. 44353 (line 979) 44354* __fractdiha: Fixed-point fractional library routines. 44355 (line 980) 44356* __fractdihq: Fixed-point fractional library routines. 44357 (line 977) 44358* __fractdiqq: Fixed-point fractional library routines. 44359 (line 976) 44360* __fractdisa: Fixed-point fractional library routines. 44361 (line 981) 44362* __fractdisq: Fixed-point fractional library routines. 44363 (line 978) 44364* __fractdita: Fixed-point fractional library routines. 44365 (line 983) 44366* __fractdiuda: Fixed-point fractional library routines. 44367 (line 990) 44368* __fractdiudq: Fixed-point fractional library routines. 44369 (line 987) 44370* __fractdiuha: Fixed-point fractional library routines. 44371 (line 988) 44372* __fractdiuhq: Fixed-point fractional library routines. 44373 (line 985) 44374* __fractdiuqq: Fixed-point fractional library routines. 44375 (line 984) 44376* __fractdiusa: Fixed-point fractional library routines. 44377 (line 989) 44378* __fractdiusq: Fixed-point fractional library routines. 44379 (line 986) 44380* __fractdiuta: Fixed-point fractional library routines. 44381 (line 991) 44382* __fractdqda: Fixed-point fractional library routines. 44383 (line 551) 44384* __fractdqdf: Fixed-point fractional library routines. 44385 (line 573) 44386* __fractdqdi: Fixed-point fractional library routines. 44387 (line 570) 44388* __fractdqha: Fixed-point fractional library routines. 44389 (line 549) 44390* __fractdqhi: Fixed-point fractional library routines. 44391 (line 568) 44392* __fractdqhq2: Fixed-point fractional library routines. 44393 (line 547) 44394* __fractdqqi: Fixed-point fractional library routines. 44395 (line 567) 44396* __fractdqqq2: Fixed-point fractional library routines. 44397 (line 546) 44398* __fractdqsa: Fixed-point fractional library routines. 44399 (line 550) 44400* __fractdqsf: Fixed-point fractional library routines. 44401 (line 572) 44402* __fractdqsi: Fixed-point fractional library routines. 44403 (line 569) 44404* __fractdqsq2: Fixed-point fractional library routines. 44405 (line 548) 44406* __fractdqta: Fixed-point fractional library routines. 44407 (line 552) 44408* __fractdqti: Fixed-point fractional library routines. 44409 (line 571) 44410* __fractdquda: Fixed-point fractional library routines. 44411 (line 563) 44412* __fractdqudq: Fixed-point fractional library routines. 44413 (line 558) 44414* __fractdquha: Fixed-point fractional library routines. 44415 (line 560) 44416* __fractdquhq: Fixed-point fractional library routines. 44417 (line 555) 44418* __fractdquqq: Fixed-point fractional library routines. 44419 (line 553) 44420* __fractdqusa: Fixed-point fractional library routines. 44421 (line 562) 44422* __fractdqusq: Fixed-point fractional library routines. 44423 (line 556) 44424* __fractdquta: Fixed-point fractional library routines. 44425 (line 565) 44426* __fracthada2: Fixed-point fractional library routines. 44427 (line 579) 44428* __fracthadf: Fixed-point fractional library routines. 44429 (line 597) 44430* __fracthadi: Fixed-point fractional library routines. 44431 (line 594) 44432* __fracthadq: Fixed-point fractional library routines. 44433 (line 577) 44434* __fracthahi: Fixed-point fractional library routines. 44435 (line 592) 44436* __fracthahq: Fixed-point fractional library routines. 44437 (line 575) 44438* __fracthaqi: Fixed-point fractional library routines. 44439 (line 591) 44440* __fracthaqq: Fixed-point fractional library routines. 44441 (line 574) 44442* __fracthasa2: Fixed-point fractional library routines. 44443 (line 578) 44444* __fracthasf: Fixed-point fractional library routines. 44445 (line 596) 44446* __fracthasi: Fixed-point fractional library routines. 44447 (line 593) 44448* __fracthasq: Fixed-point fractional library routines. 44449 (line 576) 44450* __fracthata2: Fixed-point fractional library routines. 44451 (line 580) 44452* __fracthati: Fixed-point fractional library routines. 44453 (line 595) 44454* __fracthauda: Fixed-point fractional library routines. 44455 (line 588) 44456* __fracthaudq: Fixed-point fractional library routines. 44457 (line 584) 44458* __fracthauha: Fixed-point fractional library routines. 44459 (line 586) 44460* __fracthauhq: Fixed-point fractional library routines. 44461 (line 582) 44462* __fracthauqq: Fixed-point fractional library routines. 44463 (line 581) 44464* __fracthausa: Fixed-point fractional library routines. 44465 (line 587) 44466* __fracthausq: Fixed-point fractional library routines. 44467 (line 583) 44468* __fracthauta: Fixed-point fractional library routines. 44469 (line 589) 44470* __fracthida: Fixed-point fractional library routines. 44471 (line 950) 44472* __fracthidq: Fixed-point fractional library routines. 44473 (line 947) 44474* __fracthiha: Fixed-point fractional library routines. 44475 (line 948) 44476* __fracthihq: Fixed-point fractional library routines. 44477 (line 945) 44478* __fracthiqq: Fixed-point fractional library routines. 44479 (line 944) 44480* __fracthisa: Fixed-point fractional library routines. 44481 (line 949) 44482* __fracthisq: Fixed-point fractional library routines. 44483 (line 946) 44484* __fracthita: Fixed-point fractional library routines. 44485 (line 951) 44486* __fracthiuda: Fixed-point fractional library routines. 44487 (line 958) 44488* __fracthiudq: Fixed-point fractional library routines. 44489 (line 955) 44490* __fracthiuha: Fixed-point fractional library routines. 44491 (line 956) 44492* __fracthiuhq: Fixed-point fractional library routines. 44493 (line 953) 44494* __fracthiuqq: Fixed-point fractional library routines. 44495 (line 952) 44496* __fracthiusa: Fixed-point fractional library routines. 44497 (line 957) 44498* __fracthiusq: Fixed-point fractional library routines. 44499 (line 954) 44500* __fracthiuta: Fixed-point fractional library routines. 44501 (line 959) 44502* __fracthqda: Fixed-point fractional library routines. 44503 (line 505) 44504* __fracthqdf: Fixed-point fractional library routines. 44505 (line 521) 44506* __fracthqdi: Fixed-point fractional library routines. 44507 (line 518) 44508* __fracthqdq2: Fixed-point fractional library routines. 44509 (line 502) 44510* __fracthqha: Fixed-point fractional library routines. 44511 (line 503) 44512* __fracthqhi: Fixed-point fractional library routines. 44513 (line 516) 44514* __fracthqqi: Fixed-point fractional library routines. 44515 (line 515) 44516* __fracthqqq2: Fixed-point fractional library routines. 44517 (line 500) 44518* __fracthqsa: Fixed-point fractional library routines. 44519 (line 504) 44520* __fracthqsf: Fixed-point fractional library routines. 44521 (line 520) 44522* __fracthqsi: Fixed-point fractional library routines. 44523 (line 517) 44524* __fracthqsq2: Fixed-point fractional library routines. 44525 (line 501) 44526* __fracthqta: Fixed-point fractional library routines. 44527 (line 506) 44528* __fracthqti: Fixed-point fractional library routines. 44529 (line 519) 44530* __fracthquda: Fixed-point fractional library routines. 44531 (line 513) 44532* __fracthqudq: Fixed-point fractional library routines. 44533 (line 510) 44534* __fracthquha: Fixed-point fractional library routines. 44535 (line 511) 44536* __fracthquhq: Fixed-point fractional library routines. 44537 (line 508) 44538* __fracthquqq: Fixed-point fractional library routines. 44539 (line 507) 44540* __fracthqusa: Fixed-point fractional library routines. 44541 (line 512) 44542* __fracthqusq: Fixed-point fractional library routines. 44543 (line 509) 44544* __fracthquta: Fixed-point fractional library routines. 44545 (line 514) 44546* __fractqida: Fixed-point fractional library routines. 44547 (line 932) 44548* __fractqidq: Fixed-point fractional library routines. 44549 (line 929) 44550* __fractqiha: Fixed-point fractional library routines. 44551 (line 930) 44552* __fractqihq: Fixed-point fractional library routines. 44553 (line 927) 44554* __fractqiqq: Fixed-point fractional library routines. 44555 (line 926) 44556* __fractqisa: Fixed-point fractional library routines. 44557 (line 931) 44558* __fractqisq: Fixed-point fractional library routines. 44559 (line 928) 44560* __fractqita: Fixed-point fractional library routines. 44561 (line 933) 44562* __fractqiuda: Fixed-point fractional library routines. 44563 (line 941) 44564* __fractqiudq: Fixed-point fractional library routines. 44565 (line 937) 44566* __fractqiuha: Fixed-point fractional library routines. 44567 (line 939) 44568* __fractqiuhq: Fixed-point fractional library routines. 44569 (line 935) 44570* __fractqiuqq: Fixed-point fractional library routines. 44571 (line 934) 44572* __fractqiusa: Fixed-point fractional library routines. 44573 (line 940) 44574* __fractqiusq: Fixed-point fractional library routines. 44575 (line 936) 44576* __fractqiuta: Fixed-point fractional library routines. 44577 (line 942) 44578* __fractqqda: Fixed-point fractional library routines. 44579 (line 481) 44580* __fractqqdf: Fixed-point fractional library routines. 44581 (line 499) 44582* __fractqqdi: Fixed-point fractional library routines. 44583 (line 496) 44584* __fractqqdq2: Fixed-point fractional library routines. 44585 (line 478) 44586* __fractqqha: Fixed-point fractional library routines. 44587 (line 479) 44588* __fractqqhi: Fixed-point fractional library routines. 44589 (line 494) 44590* __fractqqhq2: Fixed-point fractional library routines. 44591 (line 476) 44592* __fractqqqi: Fixed-point fractional library routines. 44593 (line 493) 44594* __fractqqsa: Fixed-point fractional library routines. 44595 (line 480) 44596* __fractqqsf: Fixed-point fractional library routines. 44597 (line 498) 44598* __fractqqsi: Fixed-point fractional library routines. 44599 (line 495) 44600* __fractqqsq2: Fixed-point fractional library routines. 44601 (line 477) 44602* __fractqqta: Fixed-point fractional library routines. 44603 (line 482) 44604* __fractqqti: Fixed-point fractional library routines. 44605 (line 497) 44606* __fractqquda: Fixed-point fractional library routines. 44607 (line 490) 44608* __fractqqudq: Fixed-point fractional library routines. 44609 (line 486) 44610* __fractqquha: Fixed-point fractional library routines. 44611 (line 488) 44612* __fractqquhq: Fixed-point fractional library routines. 44613 (line 484) 44614* __fractqquqq: Fixed-point fractional library routines. 44615 (line 483) 44616* __fractqqusa: Fixed-point fractional library routines. 44617 (line 489) 44618* __fractqqusq: Fixed-point fractional library routines. 44619 (line 485) 44620* __fractqquta: Fixed-point fractional library routines. 44621 (line 491) 44622* __fractsada2: Fixed-point fractional library routines. 44623 (line 603) 44624* __fractsadf: Fixed-point fractional library routines. 44625 (line 619) 44626* __fractsadi: Fixed-point fractional library routines. 44627 (line 616) 44628* __fractsadq: Fixed-point fractional library routines. 44629 (line 601) 44630* __fractsaha2: Fixed-point fractional library routines. 44631 (line 602) 44632* __fractsahi: Fixed-point fractional library routines. 44633 (line 614) 44634* __fractsahq: Fixed-point fractional library routines. 44635 (line 599) 44636* __fractsaqi: Fixed-point fractional library routines. 44637 (line 613) 44638* __fractsaqq: Fixed-point fractional library routines. 44639 (line 598) 44640* __fractsasf: Fixed-point fractional library routines. 44641 (line 618) 44642* __fractsasi: Fixed-point fractional library routines. 44643 (line 615) 44644* __fractsasq: Fixed-point fractional library routines. 44645 (line 600) 44646* __fractsata2: Fixed-point fractional library routines. 44647 (line 604) 44648* __fractsati: Fixed-point fractional library routines. 44649 (line 617) 44650* __fractsauda: Fixed-point fractional library routines. 44651 (line 611) 44652* __fractsaudq: Fixed-point fractional library routines. 44653 (line 608) 44654* __fractsauha: Fixed-point fractional library routines. 44655 (line 609) 44656* __fractsauhq: Fixed-point fractional library routines. 44657 (line 606) 44658* __fractsauqq: Fixed-point fractional library routines. 44659 (line 605) 44660* __fractsausa: Fixed-point fractional library routines. 44661 (line 610) 44662* __fractsausq: Fixed-point fractional library routines. 44663 (line 607) 44664* __fractsauta: Fixed-point fractional library routines. 44665 (line 612) 44666* __fractsfda: Fixed-point fractional library routines. 44667 (line 1016) 44668* __fractsfdq: Fixed-point fractional library routines. 44669 (line 1013) 44670* __fractsfha: Fixed-point fractional library routines. 44671 (line 1014) 44672* __fractsfhq: Fixed-point fractional library routines. 44673 (line 1011) 44674* __fractsfqq: Fixed-point fractional library routines. 44675 (line 1010) 44676* __fractsfsa: Fixed-point fractional library routines. 44677 (line 1015) 44678* __fractsfsq: Fixed-point fractional library routines. 44679 (line 1012) 44680* __fractsfta: Fixed-point fractional library routines. 44681 (line 1017) 44682* __fractsfuda: Fixed-point fractional library routines. 44683 (line 1024) 44684* __fractsfudq: Fixed-point fractional library routines. 44685 (line 1021) 44686* __fractsfuha: Fixed-point fractional library routines. 44687 (line 1022) 44688* __fractsfuhq: Fixed-point fractional library routines. 44689 (line 1019) 44690* __fractsfuqq: Fixed-point fractional library routines. 44691 (line 1018) 44692* __fractsfusa: Fixed-point fractional library routines. 44693 (line 1023) 44694* __fractsfusq: Fixed-point fractional library routines. 44695 (line 1020) 44696* __fractsfuta: Fixed-point fractional library routines. 44697 (line 1025) 44698* __fractsida: Fixed-point fractional library routines. 44699 (line 966) 44700* __fractsidq: Fixed-point fractional library routines. 44701 (line 963) 44702* __fractsiha: Fixed-point fractional library routines. 44703 (line 964) 44704* __fractsihq: Fixed-point fractional library routines. 44705 (line 961) 44706* __fractsiqq: Fixed-point fractional library routines. 44707 (line 960) 44708* __fractsisa: Fixed-point fractional library routines. 44709 (line 965) 44710* __fractsisq: Fixed-point fractional library routines. 44711 (line 962) 44712* __fractsita: Fixed-point fractional library routines. 44713 (line 967) 44714* __fractsiuda: Fixed-point fractional library routines. 44715 (line 974) 44716* __fractsiudq: Fixed-point fractional library routines. 44717 (line 971) 44718* __fractsiuha: Fixed-point fractional library routines. 44719 (line 972) 44720* __fractsiuhq: Fixed-point fractional library routines. 44721 (line 969) 44722* __fractsiuqq: Fixed-point fractional library routines. 44723 (line 968) 44724* __fractsiusa: Fixed-point fractional library routines. 44725 (line 973) 44726* __fractsiusq: Fixed-point fractional library routines. 44727 (line 970) 44728* __fractsiuta: Fixed-point fractional library routines. 44729 (line 975) 44730* __fractsqda: Fixed-point fractional library routines. 44731 (line 527) 44732* __fractsqdf: Fixed-point fractional library routines. 44733 (line 545) 44734* __fractsqdi: Fixed-point fractional library routines. 44735 (line 542) 44736* __fractsqdq2: Fixed-point fractional library routines. 44737 (line 524) 44738* __fractsqha: Fixed-point fractional library routines. 44739 (line 525) 44740* __fractsqhi: Fixed-point fractional library routines. 44741 (line 540) 44742* __fractsqhq2: Fixed-point fractional library routines. 44743 (line 523) 44744* __fractsqqi: Fixed-point fractional library routines. 44745 (line 539) 44746* __fractsqqq2: Fixed-point fractional library routines. 44747 (line 522) 44748* __fractsqsa: Fixed-point fractional library routines. 44749 (line 526) 44750* __fractsqsf: Fixed-point fractional library routines. 44751 (line 544) 44752* __fractsqsi: Fixed-point fractional library routines. 44753 (line 541) 44754* __fractsqta: Fixed-point fractional library routines. 44755 (line 528) 44756* __fractsqti: Fixed-point fractional library routines. 44757 (line 543) 44758* __fractsquda: Fixed-point fractional library routines. 44759 (line 536) 44760* __fractsqudq: Fixed-point fractional library routines. 44761 (line 532) 44762* __fractsquha: Fixed-point fractional library routines. 44763 (line 534) 44764* __fractsquhq: Fixed-point fractional library routines. 44765 (line 530) 44766* __fractsquqq: Fixed-point fractional library routines. 44767 (line 529) 44768* __fractsqusa: Fixed-point fractional library routines. 44769 (line 535) 44770* __fractsqusq: Fixed-point fractional library routines. 44771 (line 531) 44772* __fractsquta: Fixed-point fractional library routines. 44773 (line 537) 44774* __fracttada2: Fixed-point fractional library routines. 44775 (line 650) 44776* __fracttadf: Fixed-point fractional library routines. 44777 (line 671) 44778* __fracttadi: Fixed-point fractional library routines. 44779 (line 668) 44780* __fracttadq: Fixed-point fractional library routines. 44781 (line 647) 44782* __fracttaha2: Fixed-point fractional library routines. 44783 (line 648) 44784* __fracttahi: Fixed-point fractional library routines. 44785 (line 666) 44786* __fracttahq: Fixed-point fractional library routines. 44787 (line 645) 44788* __fracttaqi: Fixed-point fractional library routines. 44789 (line 665) 44790* __fracttaqq: Fixed-point fractional library routines. 44791 (line 644) 44792* __fracttasa2: Fixed-point fractional library routines. 44793 (line 649) 44794* __fracttasf: Fixed-point fractional library routines. 44795 (line 670) 44796* __fracttasi: Fixed-point fractional library routines. 44797 (line 667) 44798* __fracttasq: Fixed-point fractional library routines. 44799 (line 646) 44800* __fracttati: Fixed-point fractional library routines. 44801 (line 669) 44802* __fracttauda: Fixed-point fractional library routines. 44803 (line 661) 44804* __fracttaudq: Fixed-point fractional library routines. 44805 (line 656) 44806* __fracttauha: Fixed-point fractional library routines. 44807 (line 658) 44808* __fracttauhq: Fixed-point fractional library routines. 44809 (line 653) 44810* __fracttauqq: Fixed-point fractional library routines. 44811 (line 651) 44812* __fracttausa: Fixed-point fractional library routines. 44813 (line 660) 44814* __fracttausq: Fixed-point fractional library routines. 44815 (line 654) 44816* __fracttauta: Fixed-point fractional library routines. 44817 (line 663) 44818* __fracttida: Fixed-point fractional library routines. 44819 (line 998) 44820* __fracttidq: Fixed-point fractional library routines. 44821 (line 995) 44822* __fracttiha: Fixed-point fractional library routines. 44823 (line 996) 44824* __fracttihq: Fixed-point fractional library routines. 44825 (line 993) 44826* __fracttiqq: Fixed-point fractional library routines. 44827 (line 992) 44828* __fracttisa: Fixed-point fractional library routines. 44829 (line 997) 44830* __fracttisq: Fixed-point fractional library routines. 44831 (line 994) 44832* __fracttita: Fixed-point fractional library routines. 44833 (line 999) 44834* __fracttiuda: Fixed-point fractional library routines. 44835 (line 1007) 44836* __fracttiudq: Fixed-point fractional library routines. 44837 (line 1003) 44838* __fracttiuha: Fixed-point fractional library routines. 44839 (line 1005) 44840* __fracttiuhq: Fixed-point fractional library routines. 44841 (line 1001) 44842* __fracttiuqq: Fixed-point fractional library routines. 44843 (line 1000) 44844* __fracttiusa: Fixed-point fractional library routines. 44845 (line 1006) 44846* __fracttiusq: Fixed-point fractional library routines. 44847 (line 1002) 44848* __fracttiuta: Fixed-point fractional library routines. 44849 (line 1008) 44850* __fractudada: Fixed-point fractional library routines. 44851 (line 865) 44852* __fractudadf: Fixed-point fractional library routines. 44853 (line 888) 44854* __fractudadi: Fixed-point fractional library routines. 44855 (line 885) 44856* __fractudadq: Fixed-point fractional library routines. 44857 (line 861) 44858* __fractudaha: Fixed-point fractional library routines. 44859 (line 863) 44860* __fractudahi: Fixed-point fractional library routines. 44861 (line 883) 44862* __fractudahq: Fixed-point fractional library routines. 44863 (line 859) 44864* __fractudaqi: Fixed-point fractional library routines. 44865 (line 882) 44866* __fractudaqq: Fixed-point fractional library routines. 44867 (line 858) 44868* __fractudasa: Fixed-point fractional library routines. 44869 (line 864) 44870* __fractudasf: Fixed-point fractional library routines. 44871 (line 887) 44872* __fractudasi: Fixed-point fractional library routines. 44873 (line 884) 44874* __fractudasq: Fixed-point fractional library routines. 44875 (line 860) 44876* __fractudata: Fixed-point fractional library routines. 44877 (line 866) 44878* __fractudati: Fixed-point fractional library routines. 44879 (line 886) 44880* __fractudaudq: Fixed-point fractional library routines. 44881 (line 874) 44882* __fractudauha2: Fixed-point fractional library routines. 44883 (line 876) 44884* __fractudauhq: Fixed-point fractional library routines. 44885 (line 870) 44886* __fractudauqq: Fixed-point fractional library routines. 44887 (line 868) 44888* __fractudausa2: Fixed-point fractional library routines. 44889 (line 878) 44890* __fractudausq: Fixed-point fractional library routines. 44891 (line 872) 44892* __fractudauta2: Fixed-point fractional library routines. 44893 (line 880) 44894* __fractudqda: Fixed-point fractional library routines. 44895 (line 772) 44896* __fractudqdf: Fixed-point fractional library routines. 44897 (line 798) 44898* __fractudqdi: Fixed-point fractional library routines. 44899 (line 794) 44900* __fractudqdq: Fixed-point fractional library routines. 44901 (line 767) 44902* __fractudqha: Fixed-point fractional library routines. 44903 (line 769) 44904* __fractudqhi: Fixed-point fractional library routines. 44905 (line 792) 44906* __fractudqhq: Fixed-point fractional library routines. 44907 (line 764) 44908* __fractudqqi: Fixed-point fractional library routines. 44909 (line 790) 44910* __fractudqqq: Fixed-point fractional library routines. 44911 (line 762) 44912* __fractudqsa: Fixed-point fractional library routines. 44913 (line 771) 44914* __fractudqsf: Fixed-point fractional library routines. 44915 (line 797) 44916* __fractudqsi: Fixed-point fractional library routines. 44917 (line 793) 44918* __fractudqsq: Fixed-point fractional library routines. 44919 (line 765) 44920* __fractudqta: Fixed-point fractional library routines. 44921 (line 774) 44922* __fractudqti: Fixed-point fractional library routines. 44923 (line 795) 44924* __fractudquda: Fixed-point fractional library routines. 44925 (line 786) 44926* __fractudquha: Fixed-point fractional library routines. 44927 (line 782) 44928* __fractudquhq2: Fixed-point fractional library routines. 44929 (line 778) 44930* __fractudquqq2: Fixed-point fractional library routines. 44931 (line 776) 44932* __fractudqusa: Fixed-point fractional library routines. 44933 (line 784) 44934* __fractudqusq2: Fixed-point fractional library routines. 44935 (line 780) 44936* __fractudquta: Fixed-point fractional library routines. 44937 (line 788) 44938* __fractuhada: Fixed-point fractional library routines. 44939 (line 806) 44940* __fractuhadf: Fixed-point fractional library routines. 44941 (line 829) 44942* __fractuhadi: Fixed-point fractional library routines. 44943 (line 826) 44944* __fractuhadq: Fixed-point fractional library routines. 44945 (line 802) 44946* __fractuhaha: Fixed-point fractional library routines. 44947 (line 804) 44948* __fractuhahi: Fixed-point fractional library routines. 44949 (line 824) 44950* __fractuhahq: Fixed-point fractional library routines. 44951 (line 800) 44952* __fractuhaqi: Fixed-point fractional library routines. 44953 (line 823) 44954* __fractuhaqq: Fixed-point fractional library routines. 44955 (line 799) 44956* __fractuhasa: Fixed-point fractional library routines. 44957 (line 805) 44958* __fractuhasf: Fixed-point fractional library routines. 44959 (line 828) 44960* __fractuhasi: Fixed-point fractional library routines. 44961 (line 825) 44962* __fractuhasq: Fixed-point fractional library routines. 44963 (line 801) 44964* __fractuhata: Fixed-point fractional library routines. 44965 (line 807) 44966* __fractuhati: Fixed-point fractional library routines. 44967 (line 827) 44968* __fractuhauda2: Fixed-point fractional library routines. 44969 (line 819) 44970* __fractuhaudq: Fixed-point fractional library routines. 44971 (line 815) 44972* __fractuhauhq: Fixed-point fractional library routines. 44973 (line 811) 44974* __fractuhauqq: Fixed-point fractional library routines. 44975 (line 809) 44976* __fractuhausa2: Fixed-point fractional library routines. 44977 (line 817) 44978* __fractuhausq: Fixed-point fractional library routines. 44979 (line 813) 44980* __fractuhauta2: Fixed-point fractional library routines. 44981 (line 821) 44982* __fractuhqda: Fixed-point fractional library routines. 44983 (line 709) 44984* __fractuhqdf: Fixed-point fractional library routines. 44985 (line 730) 44986* __fractuhqdi: Fixed-point fractional library routines. 44987 (line 727) 44988* __fractuhqdq: Fixed-point fractional library routines. 44989 (line 706) 44990* __fractuhqha: Fixed-point fractional library routines. 44991 (line 707) 44992* __fractuhqhi: Fixed-point fractional library routines. 44993 (line 725) 44994* __fractuhqhq: Fixed-point fractional library routines. 44995 (line 704) 44996* __fractuhqqi: Fixed-point fractional library routines. 44997 (line 724) 44998* __fractuhqqq: Fixed-point fractional library routines. 44999 (line 703) 45000* __fractuhqsa: Fixed-point fractional library routines. 45001 (line 708) 45002* __fractuhqsf: Fixed-point fractional library routines. 45003 (line 729) 45004* __fractuhqsi: Fixed-point fractional library routines. 45005 (line 726) 45006* __fractuhqsq: Fixed-point fractional library routines. 45007 (line 705) 45008* __fractuhqta: Fixed-point fractional library routines. 45009 (line 710) 45010* __fractuhqti: Fixed-point fractional library routines. 45011 (line 728) 45012* __fractuhquda: Fixed-point fractional library routines. 45013 (line 720) 45014* __fractuhqudq2: Fixed-point fractional library routines. 45015 (line 715) 45016* __fractuhquha: Fixed-point fractional library routines. 45017 (line 717) 45018* __fractuhquqq2: Fixed-point fractional library routines. 45019 (line 711) 45020* __fractuhqusa: Fixed-point fractional library routines. 45021 (line 719) 45022* __fractuhqusq2: Fixed-point fractional library routines. 45023 (line 713) 45024* __fractuhquta: Fixed-point fractional library routines. 45025 (line 722) 45026* __fractunsdadi: Fixed-point fractional library routines. 45027 (line 1562) 45028* __fractunsdahi: Fixed-point fractional library routines. 45029 (line 1560) 45030* __fractunsdaqi: Fixed-point fractional library routines. 45031 (line 1559) 45032* __fractunsdasi: Fixed-point fractional library routines. 45033 (line 1561) 45034* __fractunsdati: Fixed-point fractional library routines. 45035 (line 1563) 45036* __fractunsdida: Fixed-point fractional library routines. 45037 (line 1714) 45038* __fractunsdidq: Fixed-point fractional library routines. 45039 (line 1711) 45040* __fractunsdiha: Fixed-point fractional library routines. 45041 (line 1712) 45042* __fractunsdihq: Fixed-point fractional library routines. 45043 (line 1709) 45044* __fractunsdiqq: Fixed-point fractional library routines. 45045 (line 1708) 45046* __fractunsdisa: Fixed-point fractional library routines. 45047 (line 1713) 45048* __fractunsdisq: Fixed-point fractional library routines. 45049 (line 1710) 45050* __fractunsdita: Fixed-point fractional library routines. 45051 (line 1715) 45052* __fractunsdiuda: Fixed-point fractional library routines. 45053 (line 1726) 45054* __fractunsdiudq: Fixed-point fractional library routines. 45055 (line 1721) 45056* __fractunsdiuha: Fixed-point fractional library routines. 45057 (line 1723) 45058* __fractunsdiuhq: Fixed-point fractional library routines. 45059 (line 1718) 45060* __fractunsdiuqq: Fixed-point fractional library routines. 45061 (line 1716) 45062* __fractunsdiusa: Fixed-point fractional library routines. 45063 (line 1725) 45064* __fractunsdiusq: Fixed-point fractional library routines. 45065 (line 1719) 45066* __fractunsdiuta: Fixed-point fractional library routines. 45067 (line 1728) 45068* __fractunsdqdi: Fixed-point fractional library routines. 45069 (line 1546) 45070* __fractunsdqhi: Fixed-point fractional library routines. 45071 (line 1544) 45072* __fractunsdqqi: Fixed-point fractional library routines. 45073 (line 1543) 45074* __fractunsdqsi: Fixed-point fractional library routines. 45075 (line 1545) 45076* __fractunsdqti: Fixed-point fractional library routines. 45077 (line 1547) 45078* __fractunshadi: Fixed-point fractional library routines. 45079 (line 1552) 45080* __fractunshahi: Fixed-point fractional library routines. 45081 (line 1550) 45082* __fractunshaqi: Fixed-point fractional library routines. 45083 (line 1549) 45084* __fractunshasi: Fixed-point fractional library routines. 45085 (line 1551) 45086* __fractunshati: Fixed-point fractional library routines. 45087 (line 1553) 45088* __fractunshida: Fixed-point fractional library routines. 45089 (line 1670) 45090* __fractunshidq: Fixed-point fractional library routines. 45091 (line 1667) 45092* __fractunshiha: Fixed-point fractional library routines. 45093 (line 1668) 45094* __fractunshihq: Fixed-point fractional library routines. 45095 (line 1665) 45096* __fractunshiqq: Fixed-point fractional library routines. 45097 (line 1664) 45098* __fractunshisa: Fixed-point fractional library routines. 45099 (line 1669) 45100* __fractunshisq: Fixed-point fractional library routines. 45101 (line 1666) 45102* __fractunshita: Fixed-point fractional library routines. 45103 (line 1671) 45104* __fractunshiuda: Fixed-point fractional library routines. 45105 (line 1682) 45106* __fractunshiudq: Fixed-point fractional library routines. 45107 (line 1677) 45108* __fractunshiuha: Fixed-point fractional library routines. 45109 (line 1679) 45110* __fractunshiuhq: Fixed-point fractional library routines. 45111 (line 1674) 45112* __fractunshiuqq: Fixed-point fractional library routines. 45113 (line 1672) 45114* __fractunshiusa: Fixed-point fractional library routines. 45115 (line 1681) 45116* __fractunshiusq: Fixed-point fractional library routines. 45117 (line 1675) 45118* __fractunshiuta: Fixed-point fractional library routines. 45119 (line 1684) 45120* __fractunshqdi: Fixed-point fractional library routines. 45121 (line 1536) 45122* __fractunshqhi: Fixed-point fractional library routines. 45123 (line 1534) 45124* __fractunshqqi: Fixed-point fractional library routines. 45125 (line 1533) 45126* __fractunshqsi: Fixed-point fractional library routines. 45127 (line 1535) 45128* __fractunshqti: Fixed-point fractional library routines. 45129 (line 1537) 45130* __fractunsqida: Fixed-point fractional library routines. 45131 (line 1648) 45132* __fractunsqidq: Fixed-point fractional library routines. 45133 (line 1645) 45134* __fractunsqiha: Fixed-point fractional library routines. 45135 (line 1646) 45136* __fractunsqihq: Fixed-point fractional library routines. 45137 (line 1643) 45138* __fractunsqiqq: Fixed-point fractional library routines. 45139 (line 1642) 45140* __fractunsqisa: Fixed-point fractional library routines. 45141 (line 1647) 45142* __fractunsqisq: Fixed-point fractional library routines. 45143 (line 1644) 45144* __fractunsqita: Fixed-point fractional library routines. 45145 (line 1649) 45146* __fractunsqiuda: Fixed-point fractional library routines. 45147 (line 1660) 45148* __fractunsqiudq: Fixed-point fractional library routines. 45149 (line 1655) 45150* __fractunsqiuha: Fixed-point fractional library routines. 45151 (line 1657) 45152* __fractunsqiuhq: Fixed-point fractional library routines. 45153 (line 1652) 45154* __fractunsqiuqq: Fixed-point fractional library routines. 45155 (line 1650) 45156* __fractunsqiusa: Fixed-point fractional library routines. 45157 (line 1659) 45158* __fractunsqiusq: Fixed-point fractional library routines. 45159 (line 1653) 45160* __fractunsqiuta: Fixed-point fractional library routines. 45161 (line 1662) 45162* __fractunsqqdi: Fixed-point fractional library routines. 45163 (line 1531) 45164* __fractunsqqhi: Fixed-point fractional library routines. 45165 (line 1529) 45166* __fractunsqqqi: Fixed-point fractional library routines. 45167 (line 1528) 45168* __fractunsqqsi: Fixed-point fractional library routines. 45169 (line 1530) 45170* __fractunsqqti: Fixed-point fractional library routines. 45171 (line 1532) 45172* __fractunssadi: Fixed-point fractional library routines. 45173 (line 1557) 45174* __fractunssahi: Fixed-point fractional library routines. 45175 (line 1555) 45176* __fractunssaqi: Fixed-point fractional library routines. 45177 (line 1554) 45178* __fractunssasi: Fixed-point fractional library routines. 45179 (line 1556) 45180* __fractunssati: Fixed-point fractional library routines. 45181 (line 1558) 45182* __fractunssida: Fixed-point fractional library routines. 45183 (line 1692) 45184* __fractunssidq: Fixed-point fractional library routines. 45185 (line 1689) 45186* __fractunssiha: Fixed-point fractional library routines. 45187 (line 1690) 45188* __fractunssihq: Fixed-point fractional library routines. 45189 (line 1687) 45190* __fractunssiqq: Fixed-point fractional library routines. 45191 (line 1686) 45192* __fractunssisa: Fixed-point fractional library routines. 45193 (line 1691) 45194* __fractunssisq: Fixed-point fractional library routines. 45195 (line 1688) 45196* __fractunssita: Fixed-point fractional library routines. 45197 (line 1693) 45198* __fractunssiuda: Fixed-point fractional library routines. 45199 (line 1704) 45200* __fractunssiudq: Fixed-point fractional library routines. 45201 (line 1699) 45202* __fractunssiuha: Fixed-point fractional library routines. 45203 (line 1701) 45204* __fractunssiuhq: Fixed-point fractional library routines. 45205 (line 1696) 45206* __fractunssiuqq: Fixed-point fractional library routines. 45207 (line 1694) 45208* __fractunssiusa: Fixed-point fractional library routines. 45209 (line 1703) 45210* __fractunssiusq: Fixed-point fractional library routines. 45211 (line 1697) 45212* __fractunssiuta: Fixed-point fractional library routines. 45213 (line 1706) 45214* __fractunssqdi: Fixed-point fractional library routines. 45215 (line 1541) 45216* __fractunssqhi: Fixed-point fractional library routines. 45217 (line 1539) 45218* __fractunssqqi: Fixed-point fractional library routines. 45219 (line 1538) 45220* __fractunssqsi: Fixed-point fractional library routines. 45221 (line 1540) 45222* __fractunssqti: Fixed-point fractional library routines. 45223 (line 1542) 45224* __fractunstadi: Fixed-point fractional library routines. 45225 (line 1567) 45226* __fractunstahi: Fixed-point fractional library routines. 45227 (line 1565) 45228* __fractunstaqi: Fixed-point fractional library routines. 45229 (line 1564) 45230* __fractunstasi: Fixed-point fractional library routines. 45231 (line 1566) 45232* __fractunstati: Fixed-point fractional library routines. 45233 (line 1568) 45234* __fractunstida: Fixed-point fractional library routines. 45235 (line 1737) 45236* __fractunstidq: Fixed-point fractional library routines. 45237 (line 1733) 45238* __fractunstiha: Fixed-point fractional library routines. 45239 (line 1735) 45240* __fractunstihq: Fixed-point fractional library routines. 45241 (line 1731) 45242* __fractunstiqq: Fixed-point fractional library routines. 45243 (line 1730) 45244* __fractunstisa: Fixed-point fractional library routines. 45245 (line 1736) 45246* __fractunstisq: Fixed-point fractional library routines. 45247 (line 1732) 45248* __fractunstita: Fixed-point fractional library routines. 45249 (line 1738) 45250* __fractunstiuda: Fixed-point fractional library routines. 45251 (line 1752) 45252* __fractunstiudq: Fixed-point fractional library routines. 45253 (line 1746) 45254* __fractunstiuha: Fixed-point fractional library routines. 45255 (line 1748) 45256* __fractunstiuhq: Fixed-point fractional library routines. 45257 (line 1742) 45258* __fractunstiuqq: Fixed-point fractional library routines. 45259 (line 1740) 45260* __fractunstiusa: Fixed-point fractional library routines. 45261 (line 1750) 45262* __fractunstiusq: Fixed-point fractional library routines. 45263 (line 1744) 45264* __fractunstiuta: Fixed-point fractional library routines. 45265 (line 1754) 45266* __fractunsudadi: Fixed-point fractional library routines. 45267 (line 1628) 45268* __fractunsudahi: Fixed-point fractional library routines. 45269 (line 1624) 45270* __fractunsudaqi: Fixed-point fractional library routines. 45271 (line 1622) 45272* __fractunsudasi: Fixed-point fractional library routines. 45273 (line 1626) 45274* __fractunsudati: Fixed-point fractional library routines. 45275 (line 1630) 45276* __fractunsudqdi: Fixed-point fractional library routines. 45277 (line 1602) 45278* __fractunsudqhi: Fixed-point fractional library routines. 45279 (line 1598) 45280* __fractunsudqqi: Fixed-point fractional library routines. 45281 (line 1596) 45282* __fractunsudqsi: Fixed-point fractional library routines. 45283 (line 1600) 45284* __fractunsudqti: Fixed-point fractional library routines. 45285 (line 1604) 45286* __fractunsuhadi: Fixed-point fractional library routines. 45287 (line 1612) 45288* __fractunsuhahi: Fixed-point fractional library routines. 45289 (line 1608) 45290* __fractunsuhaqi: Fixed-point fractional library routines. 45291 (line 1606) 45292* __fractunsuhasi: Fixed-point fractional library routines. 45293 (line 1610) 45294* __fractunsuhati: Fixed-point fractional library routines. 45295 (line 1614) 45296* __fractunsuhqdi: Fixed-point fractional library routines. 45297 (line 1583) 45298* __fractunsuhqhi: Fixed-point fractional library routines. 45299 (line 1581) 45300* __fractunsuhqqi: Fixed-point fractional library routines. 45301 (line 1580) 45302* __fractunsuhqsi: Fixed-point fractional library routines. 45303 (line 1582) 45304* __fractunsuhqti: Fixed-point fractional library routines. 45305 (line 1584) 45306* __fractunsuqqdi: Fixed-point fractional library routines. 45307 (line 1576) 45308* __fractunsuqqhi: Fixed-point fractional library routines. 45309 (line 1572) 45310* __fractunsuqqqi: Fixed-point fractional library routines. 45311 (line 1570) 45312* __fractunsuqqsi: Fixed-point fractional library routines. 45313 (line 1574) 45314* __fractunsuqqti: Fixed-point fractional library routines. 45315 (line 1578) 45316* __fractunsusadi: Fixed-point fractional library routines. 45317 (line 1619) 45318* __fractunsusahi: Fixed-point fractional library routines. 45319 (line 1617) 45320* __fractunsusaqi: Fixed-point fractional library routines. 45321 (line 1616) 45322* __fractunsusasi: Fixed-point fractional library routines. 45323 (line 1618) 45324* __fractunsusati: Fixed-point fractional library routines. 45325 (line 1620) 45326* __fractunsusqdi: Fixed-point fractional library routines. 45327 (line 1592) 45328* __fractunsusqhi: Fixed-point fractional library routines. 45329 (line 1588) 45330* __fractunsusqqi: Fixed-point fractional library routines. 45331 (line 1586) 45332* __fractunsusqsi: Fixed-point fractional library routines. 45333 (line 1590) 45334* __fractunsusqti: Fixed-point fractional library routines. 45335 (line 1594) 45336* __fractunsutadi: Fixed-point fractional library routines. 45337 (line 1638) 45338* __fractunsutahi: Fixed-point fractional library routines. 45339 (line 1634) 45340* __fractunsutaqi: Fixed-point fractional library routines. 45341 (line 1632) 45342* __fractunsutasi: Fixed-point fractional library routines. 45343 (line 1636) 45344* __fractunsutati: Fixed-point fractional library routines. 45345 (line 1640) 45346* __fractuqqda: Fixed-point fractional library routines. 45347 (line 679) 45348* __fractuqqdf: Fixed-point fractional library routines. 45349 (line 702) 45350* __fractuqqdi: Fixed-point fractional library routines. 45351 (line 699) 45352* __fractuqqdq: Fixed-point fractional library routines. 45353 (line 675) 45354* __fractuqqha: Fixed-point fractional library routines. 45355 (line 677) 45356* __fractuqqhi: Fixed-point fractional library routines. 45357 (line 697) 45358* __fractuqqhq: Fixed-point fractional library routines. 45359 (line 673) 45360* __fractuqqqi: Fixed-point fractional library routines. 45361 (line 696) 45362* __fractuqqqq: Fixed-point fractional library routines. 45363 (line 672) 45364* __fractuqqsa: Fixed-point fractional library routines. 45365 (line 678) 45366* __fractuqqsf: Fixed-point fractional library routines. 45367 (line 701) 45368* __fractuqqsi: Fixed-point fractional library routines. 45369 (line 698) 45370* __fractuqqsq: Fixed-point fractional library routines. 45371 (line 674) 45372* __fractuqqta: Fixed-point fractional library routines. 45373 (line 680) 45374* __fractuqqti: Fixed-point fractional library routines. 45375 (line 700) 45376* __fractuqquda: Fixed-point fractional library routines. 45377 (line 692) 45378* __fractuqqudq2: Fixed-point fractional library routines. 45379 (line 686) 45380* __fractuqquha: Fixed-point fractional library routines. 45381 (line 688) 45382* __fractuqquhq2: Fixed-point fractional library routines. 45383 (line 682) 45384* __fractuqqusa: Fixed-point fractional library routines. 45385 (line 690) 45386* __fractuqqusq2: Fixed-point fractional library routines. 45387 (line 684) 45388* __fractuqquta: Fixed-point fractional library routines. 45389 (line 694) 45390* __fractusada: Fixed-point fractional library routines. 45391 (line 836) 45392* __fractusadf: Fixed-point fractional library routines. 45393 (line 857) 45394* __fractusadi: Fixed-point fractional library routines. 45395 (line 854) 45396* __fractusadq: Fixed-point fractional library routines. 45397 (line 833) 45398* __fractusaha: Fixed-point fractional library routines. 45399 (line 834) 45400* __fractusahi: Fixed-point fractional library routines. 45401 (line 852) 45402* __fractusahq: Fixed-point fractional library routines. 45403 (line 831) 45404* __fractusaqi: Fixed-point fractional library routines. 45405 (line 851) 45406* __fractusaqq: Fixed-point fractional library routines. 45407 (line 830) 45408* __fractusasa: Fixed-point fractional library routines. 45409 (line 835) 45410* __fractusasf: Fixed-point fractional library routines. 45411 (line 856) 45412* __fractusasi: Fixed-point fractional library routines. 45413 (line 853) 45414* __fractusasq: Fixed-point fractional library routines. 45415 (line 832) 45416* __fractusata: Fixed-point fractional library routines. 45417 (line 837) 45418* __fractusati: Fixed-point fractional library routines. 45419 (line 855) 45420* __fractusauda2: Fixed-point fractional library routines. 45421 (line 847) 45422* __fractusaudq: Fixed-point fractional library routines. 45423 (line 843) 45424* __fractusauha2: Fixed-point fractional library routines. 45425 (line 845) 45426* __fractusauhq: Fixed-point fractional library routines. 45427 (line 840) 45428* __fractusauqq: Fixed-point fractional library routines. 45429 (line 838) 45430* __fractusausq: Fixed-point fractional library routines. 45431 (line 841) 45432* __fractusauta2: Fixed-point fractional library routines. 45433 (line 849) 45434* __fractusqda: Fixed-point fractional library routines. 45435 (line 738) 45436* __fractusqdf: Fixed-point fractional library routines. 45437 (line 761) 45438* __fractusqdi: Fixed-point fractional library routines. 45439 (line 758) 45440* __fractusqdq: Fixed-point fractional library routines. 45441 (line 734) 45442* __fractusqha: Fixed-point fractional library routines. 45443 (line 736) 45444* __fractusqhi: Fixed-point fractional library routines. 45445 (line 756) 45446* __fractusqhq: Fixed-point fractional library routines. 45447 (line 732) 45448* __fractusqqi: Fixed-point fractional library routines. 45449 (line 755) 45450* __fractusqqq: Fixed-point fractional library routines. 45451 (line 731) 45452* __fractusqsa: Fixed-point fractional library routines. 45453 (line 737) 45454* __fractusqsf: Fixed-point fractional library routines. 45455 (line 760) 45456* __fractusqsi: Fixed-point fractional library routines. 45457 (line 757) 45458* __fractusqsq: Fixed-point fractional library routines. 45459 (line 733) 45460* __fractusqta: Fixed-point fractional library routines. 45461 (line 739) 45462* __fractusqti: Fixed-point fractional library routines. 45463 (line 759) 45464* __fractusquda: Fixed-point fractional library routines. 45465 (line 751) 45466* __fractusqudq2: Fixed-point fractional library routines. 45467 (line 745) 45468* __fractusquha: Fixed-point fractional library routines. 45469 (line 747) 45470* __fractusquhq2: Fixed-point fractional library routines. 45471 (line 743) 45472* __fractusquqq2: Fixed-point fractional library routines. 45473 (line 741) 45474* __fractusqusa: Fixed-point fractional library routines. 45475 (line 749) 45476* __fractusquta: Fixed-point fractional library routines. 45477 (line 753) 45478* __fractutada: Fixed-point fractional library routines. 45479 (line 899) 45480* __fractutadf: Fixed-point fractional library routines. 45481 (line 925) 45482* __fractutadi: Fixed-point fractional library routines. 45483 (line 921) 45484* __fractutadq: Fixed-point fractional library routines. 45485 (line 894) 45486* __fractutaha: Fixed-point fractional library routines. 45487 (line 896) 45488* __fractutahi: Fixed-point fractional library routines. 45489 (line 919) 45490* __fractutahq: Fixed-point fractional library routines. 45491 (line 891) 45492* __fractutaqi: Fixed-point fractional library routines. 45493 (line 917) 45494* __fractutaqq: Fixed-point fractional library routines. 45495 (line 889) 45496* __fractutasa: Fixed-point fractional library routines. 45497 (line 898) 45498* __fractutasf: Fixed-point fractional library routines. 45499 (line 924) 45500* __fractutasi: Fixed-point fractional library routines. 45501 (line 920) 45502* __fractutasq: Fixed-point fractional library routines. 45503 (line 892) 45504* __fractutata: Fixed-point fractional library routines. 45505 (line 901) 45506* __fractutati: Fixed-point fractional library routines. 45507 (line 922) 45508* __fractutauda2: Fixed-point fractional library routines. 45509 (line 915) 45510* __fractutaudq: Fixed-point fractional library routines. 45511 (line 909) 45512* __fractutauha2: Fixed-point fractional library routines. 45513 (line 911) 45514* __fractutauhq: Fixed-point fractional library routines. 45515 (line 905) 45516* __fractutauqq: Fixed-point fractional library routines. 45517 (line 903) 45518* __fractutausa2: Fixed-point fractional library routines. 45519 (line 913) 45520* __fractutausq: Fixed-point fractional library routines. 45521 (line 907) 45522* __gedf2: Soft float library routines. 45523 (line 205) 45524* __gesf2: Soft float library routines. 45525 (line 204) 45526* __getf2: Soft float library routines. 45527 (line 206) 45528* __gtdf2: Soft float library routines. 45529 (line 223) 45530* __gtsf2: Soft float library routines. 45531 (line 222) 45532* __gttf2: Soft float library routines. 45533 (line 224) 45534* __ledf2: Soft float library routines. 45535 (line 217) 45536* __lesf2: Soft float library routines. 45537 (line 216) 45538* __letf2: Soft float library routines. 45539 (line 218) 45540* __lshrdi3: Integer library routines. 45541 (line 30) 45542* __lshrsi3: Integer library routines. 45543 (line 29) 45544* __lshrti3: Integer library routines. 45545 (line 31) 45546* __lshruda3: Fixed-point fractional library routines. 45547 (line 396) 45548* __lshrudq3: Fixed-point fractional library routines. 45549 (line 390) 45550* __lshruha3: Fixed-point fractional library routines. 45551 (line 392) 45552* __lshruhq3: Fixed-point fractional library routines. 45553 (line 386) 45554* __lshruqq3: Fixed-point fractional library routines. 45555 (line 384) 45556* __lshrusa3: Fixed-point fractional library routines. 45557 (line 394) 45558* __lshrusq3: Fixed-point fractional library routines. 45559 (line 388) 45560* __lshruta3: Fixed-point fractional library routines. 45561 (line 398) 45562* __ltdf2: Soft float library routines. 45563 (line 211) 45564* __ltsf2: Soft float library routines. 45565 (line 210) 45566* __lttf2: Soft float library routines. 45567 (line 212) 45568* __main: Collect2. (line 15) 45569* __moddi3: Integer library routines. 45570 (line 36) 45571* __modsi3: Integer library routines. 45572 (line 35) 45573* __modti3: Integer library routines. 45574 (line 37) 45575* __morestack_current_segment: Miscellaneous routines. 45576 (line 45) 45577* __morestack_initial_sp: Miscellaneous routines. 45578 (line 46) 45579* __morestack_segments: Miscellaneous routines. 45580 (line 44) 45581* __mulda3: Fixed-point fractional library routines. 45582 (line 178) 45583* __muldc3: Soft float library routines. 45584 (line 239) 45585* __muldf3: Soft float library routines. 45586 (line 39) 45587* __muldi3: Integer library routines. 45588 (line 42) 45589* __muldq3: Fixed-point fractional library routines. 45590 (line 165) 45591* __mulha3: Fixed-point fractional library routines. 45592 (line 175) 45593* __mulhq3: Fixed-point fractional library routines. 45594 (line 163) 45595* __mulqq3: Fixed-point fractional library routines. 45596 (line 161) 45597* __mulsa3: Fixed-point fractional library routines. 45598 (line 177) 45599* __mulsc3: Soft float library routines. 45600 (line 237) 45601* __mulsf3: Soft float library routines. 45602 (line 38) 45603* __mulsi3: Integer library routines. 45604 (line 41) 45605* __mulsq3: Fixed-point fractional library routines. 45606 (line 164) 45607* __multa3: Fixed-point fractional library routines. 45608 (line 179) 45609* __multc3: Soft float library routines. 45610 (line 241) 45611* __multf3: Soft float library routines. 45612 (line 40) 45613* __multi3: Integer library routines. 45614 (line 43) 45615* __muluda3: Fixed-point fractional library routines. 45616 (line 185) 45617* __muludq3: Fixed-point fractional library routines. 45618 (line 173) 45619* __muluha3: Fixed-point fractional library routines. 45620 (line 181) 45621* __muluhq3: Fixed-point fractional library routines. 45622 (line 169) 45623* __muluqq3: Fixed-point fractional library routines. 45624 (line 167) 45625* __mulusa3: Fixed-point fractional library routines. 45626 (line 183) 45627* __mulusq3: Fixed-point fractional library routines. 45628 (line 171) 45629* __muluta3: Fixed-point fractional library routines. 45630 (line 187) 45631* __mulvdi3: Integer library routines. 45632 (line 114) 45633* __mulvsi3: Integer library routines. 45634 (line 113) 45635* __mulxc3: Soft float library routines. 45636 (line 243) 45637* __mulxf3: Soft float library routines. 45638 (line 42) 45639* __nedf2: Soft float library routines. 45640 (line 199) 45641* __negda2: Fixed-point fractional library routines. 45642 (line 306) 45643* __negdf2: Soft float library routines. 45644 (line 55) 45645* __negdi2: Integer library routines. 45646 (line 46) 45647* __negdq2: Fixed-point fractional library routines. 45648 (line 296) 45649* __negha2: Fixed-point fractional library routines. 45650 (line 304) 45651* __neghq2: Fixed-point fractional library routines. 45652 (line 294) 45653* __negqq2: Fixed-point fractional library routines. 45654 (line 293) 45655* __negsa2: Fixed-point fractional library routines. 45656 (line 305) 45657* __negsf2: Soft float library routines. 45658 (line 54) 45659* __negsq2: Fixed-point fractional library routines. 45660 (line 295) 45661* __negta2: Fixed-point fractional library routines. 45662 (line 307) 45663* __negtf2: Soft float library routines. 45664 (line 56) 45665* __negti2: Integer library routines. 45666 (line 47) 45667* __neguda2: Fixed-point fractional library routines. 45668 (line 311) 45669* __negudq2: Fixed-point fractional library routines. 45670 (line 302) 45671* __neguha2: Fixed-point fractional library routines. 45672 (line 308) 45673* __neguhq2: Fixed-point fractional library routines. 45674 (line 299) 45675* __neguqq2: Fixed-point fractional library routines. 45676 (line 297) 45677* __negusa2: Fixed-point fractional library routines. 45678 (line 310) 45679* __negusq2: Fixed-point fractional library routines. 45680 (line 300) 45681* __neguta2: Fixed-point fractional library routines. 45682 (line 313) 45683* __negvdi2: Integer library routines. 45684 (line 118) 45685* __negvsi2: Integer library routines. 45686 (line 117) 45687* __negxf2: Soft float library routines. 45688 (line 57) 45689* __nesf2: Soft float library routines. 45690 (line 198) 45691* __netf2: Soft float library routines. 45692 (line 200) 45693* __paritydi2: Integer library routines. 45694 (line 150) 45695* __paritysi2: Integer library routines. 45696 (line 149) 45697* __parityti2: Integer library routines. 45698 (line 151) 45699* __popcountdi2: Integer library routines. 45700 (line 156) 45701* __popcountsi2: Integer library routines. 45702 (line 155) 45703* __popcountti2: Integer library routines. 45704 (line 157) 45705* __powidf2: Soft float library routines. 45706 (line 232) 45707* __powisf2: Soft float library routines. 45708 (line 231) 45709* __powitf2: Soft float library routines. 45710 (line 233) 45711* __powixf2: Soft float library routines. 45712 (line 234) 45713* __satfractdadq: Fixed-point fractional library routines. 45714 (line 1160) 45715* __satfractdaha2: Fixed-point fractional library routines. 45716 (line 1161) 45717* __satfractdahq: Fixed-point fractional library routines. 45718 (line 1158) 45719* __satfractdaqq: Fixed-point fractional library routines. 45720 (line 1157) 45721* __satfractdasa2: Fixed-point fractional library routines. 45722 (line 1162) 45723* __satfractdasq: Fixed-point fractional library routines. 45724 (line 1159) 45725* __satfractdata2: Fixed-point fractional library routines. 45726 (line 1163) 45727* __satfractdauda: Fixed-point fractional library routines. 45728 (line 1173) 45729* __satfractdaudq: Fixed-point fractional library routines. 45730 (line 1168) 45731* __satfractdauha: Fixed-point fractional library routines. 45732 (line 1170) 45733* __satfractdauhq: Fixed-point fractional library routines. 45734 (line 1166) 45735* __satfractdauqq: Fixed-point fractional library routines. 45736 (line 1164) 45737* __satfractdausa: Fixed-point fractional library routines. 45738 (line 1172) 45739* __satfractdausq: Fixed-point fractional library routines. 45740 (line 1167) 45741* __satfractdauta: Fixed-point fractional library routines. 45742 (line 1174) 45743* __satfractdfda: Fixed-point fractional library routines. 45744 (line 1513) 45745* __satfractdfdq: Fixed-point fractional library routines. 45746 (line 1510) 45747* __satfractdfha: Fixed-point fractional library routines. 45748 (line 1511) 45749* __satfractdfhq: Fixed-point fractional library routines. 45750 (line 1508) 45751* __satfractdfqq: Fixed-point fractional library routines. 45752 (line 1507) 45753* __satfractdfsa: Fixed-point fractional library routines. 45754 (line 1512) 45755* __satfractdfsq: Fixed-point fractional library routines. 45756 (line 1509) 45757* __satfractdfta: Fixed-point fractional library routines. 45758 (line 1514) 45759* __satfractdfuda: Fixed-point fractional library routines. 45760 (line 1522) 45761* __satfractdfudq: Fixed-point fractional library routines. 45762 (line 1518) 45763* __satfractdfuha: Fixed-point fractional library routines. 45764 (line 1520) 45765* __satfractdfuhq: Fixed-point fractional library routines. 45766 (line 1516) 45767* __satfractdfuqq: Fixed-point fractional library routines. 45768 (line 1515) 45769* __satfractdfusa: Fixed-point fractional library routines. 45770 (line 1521) 45771* __satfractdfusq: Fixed-point fractional library routines. 45772 (line 1517) 45773* __satfractdfuta: Fixed-point fractional library routines. 45774 (line 1523) 45775* __satfractdida: Fixed-point fractional library routines. 45776 (line 1463) 45777* __satfractdidq: Fixed-point fractional library routines. 45778 (line 1460) 45779* __satfractdiha: Fixed-point fractional library routines. 45780 (line 1461) 45781* __satfractdihq: Fixed-point fractional library routines. 45782 (line 1458) 45783* __satfractdiqq: Fixed-point fractional library routines. 45784 (line 1457) 45785* __satfractdisa: Fixed-point fractional library routines. 45786 (line 1462) 45787* __satfractdisq: Fixed-point fractional library routines. 45788 (line 1459) 45789* __satfractdita: Fixed-point fractional library routines. 45790 (line 1464) 45791* __satfractdiuda: Fixed-point fractional library routines. 45792 (line 1471) 45793* __satfractdiudq: Fixed-point fractional library routines. 45794 (line 1468) 45795* __satfractdiuha: Fixed-point fractional library routines. 45796 (line 1469) 45797* __satfractdiuhq: Fixed-point fractional library routines. 45798 (line 1466) 45799* __satfractdiuqq: Fixed-point fractional library routines. 45800 (line 1465) 45801* __satfractdiusa: Fixed-point fractional library routines. 45802 (line 1470) 45803* __satfractdiusq: Fixed-point fractional library routines. 45804 (line 1467) 45805* __satfractdiuta: Fixed-point fractional library routines. 45806 (line 1472) 45807* __satfractdqda: Fixed-point fractional library routines. 45808 (line 1105) 45809* __satfractdqha: Fixed-point fractional library routines. 45810 (line 1103) 45811* __satfractdqhq2: Fixed-point fractional library routines. 45812 (line 1101) 45813* __satfractdqqq2: Fixed-point fractional library routines. 45814 (line 1100) 45815* __satfractdqsa: Fixed-point fractional library routines. 45816 (line 1104) 45817* __satfractdqsq2: Fixed-point fractional library routines. 45818 (line 1102) 45819* __satfractdqta: Fixed-point fractional library routines. 45820 (line 1106) 45821* __satfractdquda: Fixed-point fractional library routines. 45822 (line 1117) 45823* __satfractdqudq: Fixed-point fractional library routines. 45824 (line 1112) 45825* __satfractdquha: Fixed-point fractional library routines. 45826 (line 1114) 45827* __satfractdquhq: Fixed-point fractional library routines. 45828 (line 1109) 45829* __satfractdquqq: Fixed-point fractional library routines. 45830 (line 1107) 45831* __satfractdqusa: Fixed-point fractional library routines. 45832 (line 1116) 45833* __satfractdqusq: Fixed-point fractional library routines. 45834 (line 1110) 45835* __satfractdquta: Fixed-point fractional library routines. 45836 (line 1119) 45837* __satfracthada2: Fixed-point fractional library routines. 45838 (line 1126) 45839* __satfracthadq: Fixed-point fractional library routines. 45840 (line 1124) 45841* __satfracthahq: Fixed-point fractional library routines. 45842 (line 1122) 45843* __satfracthaqq: Fixed-point fractional library routines. 45844 (line 1121) 45845* __satfracthasa2: Fixed-point fractional library routines. 45846 (line 1125) 45847* __satfracthasq: Fixed-point fractional library routines. 45848 (line 1123) 45849* __satfracthata2: Fixed-point fractional library routines. 45850 (line 1127) 45851* __satfracthauda: Fixed-point fractional library routines. 45852 (line 1138) 45853* __satfracthaudq: Fixed-point fractional library routines. 45854 (line 1133) 45855* __satfracthauha: Fixed-point fractional library routines. 45856 (line 1135) 45857* __satfracthauhq: Fixed-point fractional library routines. 45858 (line 1130) 45859* __satfracthauqq: Fixed-point fractional library routines. 45860 (line 1128) 45861* __satfracthausa: Fixed-point fractional library routines. 45862 (line 1137) 45863* __satfracthausq: Fixed-point fractional library routines. 45864 (line 1131) 45865* __satfracthauta: Fixed-point fractional library routines. 45866 (line 1140) 45867* __satfracthida: Fixed-point fractional library routines. 45868 (line 1431) 45869* __satfracthidq: Fixed-point fractional library routines. 45870 (line 1428) 45871* __satfracthiha: Fixed-point fractional library routines. 45872 (line 1429) 45873* __satfracthihq: Fixed-point fractional library routines. 45874 (line 1426) 45875* __satfracthiqq: Fixed-point fractional library routines. 45876 (line 1425) 45877* __satfracthisa: Fixed-point fractional library routines. 45878 (line 1430) 45879* __satfracthisq: Fixed-point fractional library routines. 45880 (line 1427) 45881* __satfracthita: Fixed-point fractional library routines. 45882 (line 1432) 45883* __satfracthiuda: Fixed-point fractional library routines. 45884 (line 1439) 45885* __satfracthiudq: Fixed-point fractional library routines. 45886 (line 1436) 45887* __satfracthiuha: Fixed-point fractional library routines. 45888 (line 1437) 45889* __satfracthiuhq: Fixed-point fractional library routines. 45890 (line 1434) 45891* __satfracthiuqq: Fixed-point fractional library routines. 45892 (line 1433) 45893* __satfracthiusa: Fixed-point fractional library routines. 45894 (line 1438) 45895* __satfracthiusq: Fixed-point fractional library routines. 45896 (line 1435) 45897* __satfracthiuta: Fixed-point fractional library routines. 45898 (line 1440) 45899* __satfracthqda: Fixed-point fractional library routines. 45900 (line 1071) 45901* __satfracthqdq2: Fixed-point fractional library routines. 45902 (line 1068) 45903* __satfracthqha: Fixed-point fractional library routines. 45904 (line 1069) 45905* __satfracthqqq2: Fixed-point fractional library routines. 45906 (line 1066) 45907* __satfracthqsa: Fixed-point fractional library routines. 45908 (line 1070) 45909* __satfracthqsq2: Fixed-point fractional library routines. 45910 (line 1067) 45911* __satfracthqta: Fixed-point fractional library routines. 45912 (line 1072) 45913* __satfracthquda: Fixed-point fractional library routines. 45914 (line 1079) 45915* __satfracthqudq: Fixed-point fractional library routines. 45916 (line 1076) 45917* __satfracthquha: Fixed-point fractional library routines. 45918 (line 1077) 45919* __satfracthquhq: Fixed-point fractional library routines. 45920 (line 1074) 45921* __satfracthquqq: Fixed-point fractional library routines. 45922 (line 1073) 45923* __satfracthqusa: Fixed-point fractional library routines. 45924 (line 1078) 45925* __satfracthqusq: Fixed-point fractional library routines. 45926 (line 1075) 45927* __satfracthquta: Fixed-point fractional library routines. 45928 (line 1080) 45929* __satfractqida: Fixed-point fractional library routines. 45930 (line 1409) 45931* __satfractqidq: Fixed-point fractional library routines. 45932 (line 1406) 45933* __satfractqiha: Fixed-point fractional library routines. 45934 (line 1407) 45935* __satfractqihq: Fixed-point fractional library routines. 45936 (line 1404) 45937* __satfractqiqq: Fixed-point fractional library routines. 45938 (line 1403) 45939* __satfractqisa: Fixed-point fractional library routines. 45940 (line 1408) 45941* __satfractqisq: Fixed-point fractional library routines. 45942 (line 1405) 45943* __satfractqita: Fixed-point fractional library routines. 45944 (line 1410) 45945* __satfractqiuda: Fixed-point fractional library routines. 45946 (line 1421) 45947* __satfractqiudq: Fixed-point fractional library routines. 45948 (line 1416) 45949* __satfractqiuha: Fixed-point fractional library routines. 45950 (line 1418) 45951* __satfractqiuhq: Fixed-point fractional library routines. 45952 (line 1413) 45953* __satfractqiuqq: Fixed-point fractional library routines. 45954 (line 1411) 45955* __satfractqiusa: Fixed-point fractional library routines. 45956 (line 1420) 45957* __satfractqiusq: Fixed-point fractional library routines. 45958 (line 1414) 45959* __satfractqiuta: Fixed-point fractional library routines. 45960 (line 1423) 45961* __satfractqqda: Fixed-point fractional library routines. 45962 (line 1050) 45963* __satfractqqdq2: Fixed-point fractional library routines. 45964 (line 1047) 45965* __satfractqqha: Fixed-point fractional library routines. 45966 (line 1048) 45967* __satfractqqhq2: Fixed-point fractional library routines. 45968 (line 1045) 45969* __satfractqqsa: Fixed-point fractional library routines. 45970 (line 1049) 45971* __satfractqqsq2: Fixed-point fractional library routines. 45972 (line 1046) 45973* __satfractqqta: Fixed-point fractional library routines. 45974 (line 1051) 45975* __satfractqquda: Fixed-point fractional library routines. 45976 (line 1062) 45977* __satfractqqudq: Fixed-point fractional library routines. 45978 (line 1057) 45979* __satfractqquha: Fixed-point fractional library routines. 45980 (line 1059) 45981* __satfractqquhq: Fixed-point fractional library routines. 45982 (line 1054) 45983* __satfractqquqq: Fixed-point fractional library routines. 45984 (line 1052) 45985* __satfractqqusa: Fixed-point fractional library routines. 45986 (line 1061) 45987* __satfractqqusq: Fixed-point fractional library routines. 45988 (line 1055) 45989* __satfractqquta: Fixed-point fractional library routines. 45990 (line 1064) 45991* __satfractsada2: Fixed-point fractional library routines. 45992 (line 1147) 45993* __satfractsadq: Fixed-point fractional library routines. 45994 (line 1145) 45995* __satfractsaha2: Fixed-point fractional library routines. 45996 (line 1146) 45997* __satfractsahq: Fixed-point fractional library routines. 45998 (line 1143) 45999* __satfractsaqq: Fixed-point fractional library routines. 46000 (line 1142) 46001* __satfractsasq: Fixed-point fractional library routines. 46002 (line 1144) 46003* __satfractsata2: Fixed-point fractional library routines. 46004 (line 1148) 46005* __satfractsauda: Fixed-point fractional library routines. 46006 (line 1155) 46007* __satfractsaudq: Fixed-point fractional library routines. 46008 (line 1152) 46009* __satfractsauha: Fixed-point fractional library routines. 46010 (line 1153) 46011* __satfractsauhq: Fixed-point fractional library routines. 46012 (line 1150) 46013* __satfractsauqq: Fixed-point fractional library routines. 46014 (line 1149) 46015* __satfractsausa: Fixed-point fractional library routines. 46016 (line 1154) 46017* __satfractsausq: Fixed-point fractional library routines. 46018 (line 1151) 46019* __satfractsauta: Fixed-point fractional library routines. 46020 (line 1156) 46021* __satfractsfda: Fixed-point fractional library routines. 46022 (line 1497) 46023* __satfractsfdq: Fixed-point fractional library routines. 46024 (line 1494) 46025* __satfractsfha: Fixed-point fractional library routines. 46026 (line 1495) 46027* __satfractsfhq: Fixed-point fractional library routines. 46028 (line 1492) 46029* __satfractsfqq: Fixed-point fractional library routines. 46030 (line 1491) 46031* __satfractsfsa: Fixed-point fractional library routines. 46032 (line 1496) 46033* __satfractsfsq: Fixed-point fractional library routines. 46034 (line 1493) 46035* __satfractsfta: Fixed-point fractional library routines. 46036 (line 1498) 46037* __satfractsfuda: Fixed-point fractional library routines. 46038 (line 1505) 46039* __satfractsfudq: Fixed-point fractional library routines. 46040 (line 1502) 46041* __satfractsfuha: Fixed-point fractional library routines. 46042 (line 1503) 46043* __satfractsfuhq: Fixed-point fractional library routines. 46044 (line 1500) 46045* __satfractsfuqq: Fixed-point fractional library routines. 46046 (line 1499) 46047* __satfractsfusa: Fixed-point fractional library routines. 46048 (line 1504) 46049* __satfractsfusq: Fixed-point fractional library routines. 46050 (line 1501) 46051* __satfractsfuta: Fixed-point fractional library routines. 46052 (line 1506) 46053* __satfractsida: Fixed-point fractional library routines. 46054 (line 1447) 46055* __satfractsidq: Fixed-point fractional library routines. 46056 (line 1444) 46057* __satfractsiha: Fixed-point fractional library routines. 46058 (line 1445) 46059* __satfractsihq: Fixed-point fractional library routines. 46060 (line 1442) 46061* __satfractsiqq: Fixed-point fractional library routines. 46062 (line 1441) 46063* __satfractsisa: Fixed-point fractional library routines. 46064 (line 1446) 46065* __satfractsisq: Fixed-point fractional library routines. 46066 (line 1443) 46067* __satfractsita: Fixed-point fractional library routines. 46068 (line 1448) 46069* __satfractsiuda: Fixed-point fractional library routines. 46070 (line 1455) 46071* __satfractsiudq: Fixed-point fractional library routines. 46072 (line 1452) 46073* __satfractsiuha: Fixed-point fractional library routines. 46074 (line 1453) 46075* __satfractsiuhq: Fixed-point fractional library routines. 46076 (line 1450) 46077* __satfractsiuqq: Fixed-point fractional library routines. 46078 (line 1449) 46079* __satfractsiusa: Fixed-point fractional library routines. 46080 (line 1454) 46081* __satfractsiusq: Fixed-point fractional library routines. 46082 (line 1451) 46083* __satfractsiuta: Fixed-point fractional library routines. 46084 (line 1456) 46085* __satfractsqda: Fixed-point fractional library routines. 46086 (line 1086) 46087* __satfractsqdq2: Fixed-point fractional library routines. 46088 (line 1083) 46089* __satfractsqha: Fixed-point fractional library routines. 46090 (line 1084) 46091* __satfractsqhq2: Fixed-point fractional library routines. 46092 (line 1082) 46093* __satfractsqqq2: Fixed-point fractional library routines. 46094 (line 1081) 46095* __satfractsqsa: Fixed-point fractional library routines. 46096 (line 1085) 46097* __satfractsqta: Fixed-point fractional library routines. 46098 (line 1087) 46099* __satfractsquda: Fixed-point fractional library routines. 46100 (line 1097) 46101* __satfractsqudq: Fixed-point fractional library routines. 46102 (line 1092) 46103* __satfractsquha: Fixed-point fractional library routines. 46104 (line 1094) 46105* __satfractsquhq: Fixed-point fractional library routines. 46106 (line 1090) 46107* __satfractsquqq: Fixed-point fractional library routines. 46108 (line 1088) 46109* __satfractsqusa: Fixed-point fractional library routines. 46110 (line 1096) 46111* __satfractsqusq: Fixed-point fractional library routines. 46112 (line 1091) 46113* __satfractsquta: Fixed-point fractional library routines. 46114 (line 1098) 46115* __satfracttada2: Fixed-point fractional library routines. 46116 (line 1182) 46117* __satfracttadq: Fixed-point fractional library routines. 46118 (line 1179) 46119* __satfracttaha2: Fixed-point fractional library routines. 46120 (line 1180) 46121* __satfracttahq: Fixed-point fractional library routines. 46122 (line 1177) 46123* __satfracttaqq: Fixed-point fractional library routines. 46124 (line 1176) 46125* __satfracttasa2: Fixed-point fractional library routines. 46126 (line 1181) 46127* __satfracttasq: Fixed-point fractional library routines. 46128 (line 1178) 46129* __satfracttauda: Fixed-point fractional library routines. 46130 (line 1193) 46131* __satfracttaudq: Fixed-point fractional library routines. 46132 (line 1188) 46133* __satfracttauha: Fixed-point fractional library routines. 46134 (line 1190) 46135* __satfracttauhq: Fixed-point fractional library routines. 46136 (line 1185) 46137* __satfracttauqq: Fixed-point fractional library routines. 46138 (line 1183) 46139* __satfracttausa: Fixed-point fractional library routines. 46140 (line 1192) 46141* __satfracttausq: Fixed-point fractional library routines. 46142 (line 1186) 46143* __satfracttauta: Fixed-point fractional library routines. 46144 (line 1195) 46145* __satfracttida: Fixed-point fractional library routines. 46146 (line 1479) 46147* __satfracttidq: Fixed-point fractional library routines. 46148 (line 1476) 46149* __satfracttiha: Fixed-point fractional library routines. 46150 (line 1477) 46151* __satfracttihq: Fixed-point fractional library routines. 46152 (line 1474) 46153* __satfracttiqq: Fixed-point fractional library routines. 46154 (line 1473) 46155* __satfracttisa: Fixed-point fractional library routines. 46156 (line 1478) 46157* __satfracttisq: Fixed-point fractional library routines. 46158 (line 1475) 46159* __satfracttita: Fixed-point fractional library routines. 46160 (line 1480) 46161* __satfracttiuda: Fixed-point fractional library routines. 46162 (line 1488) 46163* __satfracttiudq: Fixed-point fractional library routines. 46164 (line 1484) 46165* __satfracttiuha: Fixed-point fractional library routines. 46166 (line 1486) 46167* __satfracttiuhq: Fixed-point fractional library routines. 46168 (line 1482) 46169* __satfracttiuqq: Fixed-point fractional library routines. 46170 (line 1481) 46171* __satfracttiusa: Fixed-point fractional library routines. 46172 (line 1487) 46173* __satfracttiusq: Fixed-point fractional library routines. 46174 (line 1483) 46175* __satfracttiuta: Fixed-point fractional library routines. 46176 (line 1489) 46177* __satfractudada: Fixed-point fractional library routines. 46178 (line 1358) 46179* __satfractudadq: Fixed-point fractional library routines. 46180 (line 1353) 46181* __satfractudaha: Fixed-point fractional library routines. 46182 (line 1355) 46183* __satfractudahq: Fixed-point fractional library routines. 46184 (line 1351) 46185* __satfractudaqq: Fixed-point fractional library routines. 46186 (line 1349) 46187* __satfractudasa: Fixed-point fractional library routines. 46188 (line 1357) 46189* __satfractudasq: Fixed-point fractional library routines. 46190 (line 1352) 46191* __satfractudata: Fixed-point fractional library routines. 46192 (line 1359) 46193* __satfractudaudq: Fixed-point fractional library routines. 46194 (line 1367) 46195* __satfractudauha2: Fixed-point fractional library routines. 46196 (line 1369) 46197* __satfractudauhq: Fixed-point fractional library routines. 46198 (line 1363) 46199* __satfractudauqq: Fixed-point fractional library routines. 46200 (line 1361) 46201* __satfractudausa2: Fixed-point fractional library routines. 46202 (line 1371) 46203* __satfractudausq: Fixed-point fractional library routines. 46204 (line 1365) 46205* __satfractudauta2: Fixed-point fractional library routines. 46206 (line 1373) 46207* __satfractudqda: Fixed-point fractional library routines. 46208 (line 1282) 46209* __satfractudqdq: Fixed-point fractional library routines. 46210 (line 1277) 46211* __satfractudqha: Fixed-point fractional library routines. 46212 (line 1279) 46213* __satfractudqhq: Fixed-point fractional library routines. 46214 (line 1274) 46215* __satfractudqqq: Fixed-point fractional library routines. 46216 (line 1272) 46217* __satfractudqsa: Fixed-point fractional library routines. 46218 (line 1281) 46219* __satfractudqsq: Fixed-point fractional library routines. 46220 (line 1275) 46221* __satfractudqta: Fixed-point fractional library routines. 46222 (line 1284) 46223* __satfractudquda: Fixed-point fractional library routines. 46224 (line 1296) 46225* __satfractudquha: Fixed-point fractional library routines. 46226 (line 1292) 46227* __satfractudquhq2: Fixed-point fractional library routines. 46228 (line 1288) 46229* __satfractudquqq2: Fixed-point fractional library routines. 46230 (line 1286) 46231* __satfractudqusa: Fixed-point fractional library routines. 46232 (line 1294) 46233* __satfractudqusq2: Fixed-point fractional library routines. 46234 (line 1290) 46235* __satfractudquta: Fixed-point fractional library routines. 46236 (line 1298) 46237* __satfractuhada: Fixed-point fractional library routines. 46238 (line 1310) 46239* __satfractuhadq: Fixed-point fractional library routines. 46240 (line 1305) 46241* __satfractuhaha: Fixed-point fractional library routines. 46242 (line 1307) 46243* __satfractuhahq: Fixed-point fractional library routines. 46244 (line 1302) 46245* __satfractuhaqq: Fixed-point fractional library routines. 46246 (line 1300) 46247* __satfractuhasa: Fixed-point fractional library routines. 46248 (line 1309) 46249* __satfractuhasq: Fixed-point fractional library routines. 46250 (line 1303) 46251* __satfractuhata: Fixed-point fractional library routines. 46252 (line 1312) 46253* __satfractuhauda2: Fixed-point fractional library routines. 46254 (line 1324) 46255* __satfractuhaudq: Fixed-point fractional library routines. 46256 (line 1320) 46257* __satfractuhauhq: Fixed-point fractional library routines. 46258 (line 1316) 46259* __satfractuhauqq: Fixed-point fractional library routines. 46260 (line 1314) 46261* __satfractuhausa2: Fixed-point fractional library routines. 46262 (line 1322) 46263* __satfractuhausq: Fixed-point fractional library routines. 46264 (line 1318) 46265* __satfractuhauta2: Fixed-point fractional library routines. 46266 (line 1326) 46267* __satfractuhqda: Fixed-point fractional library routines. 46268 (line 1231) 46269* __satfractuhqdq: Fixed-point fractional library routines. 46270 (line 1228) 46271* __satfractuhqha: Fixed-point fractional library routines. 46272 (line 1229) 46273* __satfractuhqhq: Fixed-point fractional library routines. 46274 (line 1226) 46275* __satfractuhqqq: Fixed-point fractional library routines. 46276 (line 1225) 46277* __satfractuhqsa: Fixed-point fractional library routines. 46278 (line 1230) 46279* __satfractuhqsq: Fixed-point fractional library routines. 46280 (line 1227) 46281* __satfractuhqta: Fixed-point fractional library routines. 46282 (line 1232) 46283* __satfractuhquda: Fixed-point fractional library routines. 46284 (line 1242) 46285* __satfractuhqudq2: Fixed-point fractional library routines. 46286 (line 1237) 46287* __satfractuhquha: Fixed-point fractional library routines. 46288 (line 1239) 46289* __satfractuhquqq2: Fixed-point fractional library routines. 46290 (line 1233) 46291* __satfractuhqusa: Fixed-point fractional library routines. 46292 (line 1241) 46293* __satfractuhqusq2: Fixed-point fractional library routines. 46294 (line 1235) 46295* __satfractuhquta: Fixed-point fractional library routines. 46296 (line 1244) 46297* __satfractunsdida: Fixed-point fractional library routines. 46298 (line 1841) 46299* __satfractunsdidq: Fixed-point fractional library routines. 46300 (line 1837) 46301* __satfractunsdiha: Fixed-point fractional library routines. 46302 (line 1839) 46303* __satfractunsdihq: Fixed-point fractional library routines. 46304 (line 1835) 46305* __satfractunsdiqq: Fixed-point fractional library routines. 46306 (line 1834) 46307* __satfractunsdisa: Fixed-point fractional library routines. 46308 (line 1840) 46309* __satfractunsdisq: Fixed-point fractional library routines. 46310 (line 1836) 46311* __satfractunsdita: Fixed-point fractional library routines. 46312 (line 1842) 46313* __satfractunsdiuda: Fixed-point fractional library routines. 46314 (line 1856) 46315* __satfractunsdiudq: Fixed-point fractional library routines. 46316 (line 1850) 46317* __satfractunsdiuha: Fixed-point fractional library routines. 46318 (line 1852) 46319* __satfractunsdiuhq: Fixed-point fractional library routines. 46320 (line 1846) 46321* __satfractunsdiuqq: Fixed-point fractional library routines. 46322 (line 1844) 46323* __satfractunsdiusa: Fixed-point fractional library routines. 46324 (line 1854) 46325* __satfractunsdiusq: Fixed-point fractional library routines. 46326 (line 1848) 46327* __satfractunsdiuta: Fixed-point fractional library routines. 46328 (line 1858) 46329* __satfractunshida: Fixed-point fractional library routines. 46330 (line 1793) 46331* __satfractunshidq: Fixed-point fractional library routines. 46332 (line 1789) 46333* __satfractunshiha: Fixed-point fractional library routines. 46334 (line 1791) 46335* __satfractunshihq: Fixed-point fractional library routines. 46336 (line 1787) 46337* __satfractunshiqq: Fixed-point fractional library routines. 46338 (line 1786) 46339* __satfractunshisa: Fixed-point fractional library routines. 46340 (line 1792) 46341* __satfractunshisq: Fixed-point fractional library routines. 46342 (line 1788) 46343* __satfractunshita: Fixed-point fractional library routines. 46344 (line 1794) 46345* __satfractunshiuda: Fixed-point fractional library routines. 46346 (line 1808) 46347* __satfractunshiudq: Fixed-point fractional library routines. 46348 (line 1802) 46349* __satfractunshiuha: Fixed-point fractional library routines. 46350 (line 1804) 46351* __satfractunshiuhq: Fixed-point fractional library routines. 46352 (line 1798) 46353* __satfractunshiuqq: Fixed-point fractional library routines. 46354 (line 1796) 46355* __satfractunshiusa: Fixed-point fractional library routines. 46356 (line 1806) 46357* __satfractunshiusq: Fixed-point fractional library routines. 46358 (line 1800) 46359* __satfractunshiuta: Fixed-point fractional library routines. 46360 (line 1810) 46361* __satfractunsqida: Fixed-point fractional library routines. 46362 (line 1767) 46363* __satfractunsqidq: Fixed-point fractional library routines. 46364 (line 1763) 46365* __satfractunsqiha: Fixed-point fractional library routines. 46366 (line 1765) 46367* __satfractunsqihq: Fixed-point fractional library routines. 46368 (line 1761) 46369* __satfractunsqiqq: Fixed-point fractional library routines. 46370 (line 1760) 46371* __satfractunsqisa: Fixed-point fractional library routines. 46372 (line 1766) 46373* __satfractunsqisq: Fixed-point fractional library routines. 46374 (line 1762) 46375* __satfractunsqita: Fixed-point fractional library routines. 46376 (line 1768) 46377* __satfractunsqiuda: Fixed-point fractional library routines. 46378 (line 1782) 46379* __satfractunsqiudq: Fixed-point fractional library routines. 46380 (line 1776) 46381* __satfractunsqiuha: Fixed-point fractional library routines. 46382 (line 1778) 46383* __satfractunsqiuhq: Fixed-point fractional library routines. 46384 (line 1772) 46385* __satfractunsqiuqq: Fixed-point fractional library routines. 46386 (line 1770) 46387* __satfractunsqiusa: Fixed-point fractional library routines. 46388 (line 1780) 46389* __satfractunsqiusq: Fixed-point fractional library routines. 46390 (line 1774) 46391* __satfractunsqiuta: Fixed-point fractional library routines. 46392 (line 1784) 46393* __satfractunssida: Fixed-point fractional library routines. 46394 (line 1818) 46395* __satfractunssidq: Fixed-point fractional library routines. 46396 (line 1815) 46397* __satfractunssiha: Fixed-point fractional library routines. 46398 (line 1816) 46399* __satfractunssihq: Fixed-point fractional library routines. 46400 (line 1813) 46401* __satfractunssiqq: Fixed-point fractional library routines. 46402 (line 1812) 46403* __satfractunssisa: Fixed-point fractional library routines. 46404 (line 1817) 46405* __satfractunssisq: Fixed-point fractional library routines. 46406 (line 1814) 46407* __satfractunssita: Fixed-point fractional library routines. 46408 (line 1819) 46409* __satfractunssiuda: Fixed-point fractional library routines. 46410 (line 1830) 46411* __satfractunssiudq: Fixed-point fractional library routines. 46412 (line 1825) 46413* __satfractunssiuha: Fixed-point fractional library routines. 46414 (line 1827) 46415* __satfractunssiuhq: Fixed-point fractional library routines. 46416 (line 1822) 46417* __satfractunssiuqq: Fixed-point fractional library routines. 46418 (line 1820) 46419* __satfractunssiusa: Fixed-point fractional library routines. 46420 (line 1829) 46421* __satfractunssiusq: Fixed-point fractional library routines. 46422 (line 1823) 46423* __satfractunssiuta: Fixed-point fractional library routines. 46424 (line 1832) 46425* __satfractunstida: Fixed-point fractional library routines. 46426 (line 1870) 46427* __satfractunstidq: Fixed-point fractional library routines. 46428 (line 1865) 46429* __satfractunstiha: Fixed-point fractional library routines. 46430 (line 1867) 46431* __satfractunstihq: Fixed-point fractional library routines. 46432 (line 1862) 46433* __satfractunstiqq: Fixed-point fractional library routines. 46434 (line 1860) 46435* __satfractunstisa: Fixed-point fractional library routines. 46436 (line 1869) 46437* __satfractunstisq: Fixed-point fractional library routines. 46438 (line 1863) 46439* __satfractunstita: Fixed-point fractional library routines. 46440 (line 1872) 46441* __satfractunstiuda: Fixed-point fractional library routines. 46442 (line 1886) 46443* __satfractunstiudq: Fixed-point fractional library routines. 46444 (line 1880) 46445* __satfractunstiuha: Fixed-point fractional library routines. 46446 (line 1882) 46447* __satfractunstiuhq: Fixed-point fractional library routines. 46448 (line 1876) 46449* __satfractunstiuqq: Fixed-point fractional library routines. 46450 (line 1874) 46451* __satfractunstiusa: Fixed-point fractional library routines. 46452 (line 1884) 46453* __satfractunstiusq: Fixed-point fractional library routines. 46454 (line 1878) 46455* __satfractunstiuta: Fixed-point fractional library routines. 46456 (line 1888) 46457* __satfractuqqda: Fixed-point fractional library routines. 46458 (line 1207) 46459* __satfractuqqdq: Fixed-point fractional library routines. 46460 (line 1202) 46461* __satfractuqqha: Fixed-point fractional library routines. 46462 (line 1204) 46463* __satfractuqqhq: Fixed-point fractional library routines. 46464 (line 1199) 46465* __satfractuqqqq: Fixed-point fractional library routines. 46466 (line 1197) 46467* __satfractuqqsa: Fixed-point fractional library routines. 46468 (line 1206) 46469* __satfractuqqsq: Fixed-point fractional library routines. 46470 (line 1200) 46471* __satfractuqqta: Fixed-point fractional library routines. 46472 (line 1209) 46473* __satfractuqquda: Fixed-point fractional library routines. 46474 (line 1221) 46475* __satfractuqqudq2: Fixed-point fractional library routines. 46476 (line 1215) 46477* __satfractuqquha: Fixed-point fractional library routines. 46478 (line 1217) 46479* __satfractuqquhq2: Fixed-point fractional library routines. 46480 (line 1211) 46481* __satfractuqqusa: Fixed-point fractional library routines. 46482 (line 1219) 46483* __satfractuqqusq2: Fixed-point fractional library routines. 46484 (line 1213) 46485* __satfractuqquta: Fixed-point fractional library routines. 46486 (line 1223) 46487* __satfractusada: Fixed-point fractional library routines. 46488 (line 1334) 46489* __satfractusadq: Fixed-point fractional library routines. 46490 (line 1331) 46491* __satfractusaha: Fixed-point fractional library routines. 46492 (line 1332) 46493* __satfractusahq: Fixed-point fractional library routines. 46494 (line 1329) 46495* __satfractusaqq: Fixed-point fractional library routines. 46496 (line 1328) 46497* __satfractusasa: Fixed-point fractional library routines. 46498 (line 1333) 46499* __satfractusasq: Fixed-point fractional library routines. 46500 (line 1330) 46501* __satfractusata: Fixed-point fractional library routines. 46502 (line 1335) 46503* __satfractusauda2: Fixed-point fractional library routines. 46504 (line 1345) 46505* __satfractusaudq: Fixed-point fractional library routines. 46506 (line 1341) 46507* __satfractusauha2: Fixed-point fractional library routines. 46508 (line 1343) 46509* __satfractusauhq: Fixed-point fractional library routines. 46510 (line 1338) 46511* __satfractusauqq: Fixed-point fractional library routines. 46512 (line 1336) 46513* __satfractusausq: Fixed-point fractional library routines. 46514 (line 1339) 46515* __satfractusauta2: Fixed-point fractional library routines. 46516 (line 1347) 46517* __satfractusqda: Fixed-point fractional library routines. 46518 (line 1255) 46519* __satfractusqdq: Fixed-point fractional library routines. 46520 (line 1250) 46521* __satfractusqha: Fixed-point fractional library routines. 46522 (line 1252) 46523* __satfractusqhq: Fixed-point fractional library routines. 46524 (line 1248) 46525* __satfractusqqq: Fixed-point fractional library routines. 46526 (line 1246) 46527* __satfractusqsa: Fixed-point fractional library routines. 46528 (line 1254) 46529* __satfractusqsq: Fixed-point fractional library routines. 46530 (line 1249) 46531* __satfractusqta: Fixed-point fractional library routines. 46532 (line 1256) 46533* __satfractusquda: Fixed-point fractional library routines. 46534 (line 1268) 46535* __satfractusqudq2: Fixed-point fractional library routines. 46536 (line 1262) 46537* __satfractusquha: Fixed-point fractional library routines. 46538 (line 1264) 46539* __satfractusquhq2: Fixed-point fractional library routines. 46540 (line 1260) 46541* __satfractusquqq2: Fixed-point fractional library routines. 46542 (line 1258) 46543* __satfractusqusa: Fixed-point fractional library routines. 46544 (line 1266) 46545* __satfractusquta: Fixed-point fractional library routines. 46546 (line 1270) 46547* __satfractutada: Fixed-point fractional library routines. 46548 (line 1385) 46549* __satfractutadq: Fixed-point fractional library routines. 46550 (line 1380) 46551* __satfractutaha: Fixed-point fractional library routines. 46552 (line 1382) 46553* __satfractutahq: Fixed-point fractional library routines. 46554 (line 1377) 46555* __satfractutaqq: Fixed-point fractional library routines. 46556 (line 1375) 46557* __satfractutasa: Fixed-point fractional library routines. 46558 (line 1384) 46559* __satfractutasq: Fixed-point fractional library routines. 46560 (line 1378) 46561* __satfractutata: Fixed-point fractional library routines. 46562 (line 1387) 46563* __satfractutauda2: Fixed-point fractional library routines. 46564 (line 1401) 46565* __satfractutaudq: Fixed-point fractional library routines. 46566 (line 1395) 46567* __satfractutauha2: Fixed-point fractional library routines. 46568 (line 1397) 46569* __satfractutauhq: Fixed-point fractional library routines. 46570 (line 1391) 46571* __satfractutauqq: Fixed-point fractional library routines. 46572 (line 1389) 46573* __satfractutausa2: Fixed-point fractional library routines. 46574 (line 1399) 46575* __satfractutausq: Fixed-point fractional library routines. 46576 (line 1393) 46577* __splitstack_find: Miscellaneous routines. 46578 (line 15) 46579* __ssaddda3: Fixed-point fractional library routines. 46580 (line 74) 46581* __ssadddq3: Fixed-point fractional library routines. 46582 (line 69) 46583* __ssaddha3: Fixed-point fractional library routines. 46584 (line 71) 46585* __ssaddhq3: Fixed-point fractional library routines. 46586 (line 67) 46587* __ssaddqq3: Fixed-point fractional library routines. 46588 (line 65) 46589* __ssaddsa3: Fixed-point fractional library routines. 46590 (line 73) 46591* __ssaddsq3: Fixed-point fractional library routines. 46592 (line 68) 46593* __ssaddta3: Fixed-point fractional library routines. 46594 (line 75) 46595* __ssashlda3: Fixed-point fractional library routines. 46596 (line 409) 46597* __ssashldq3: Fixed-point fractional library routines. 46598 (line 405) 46599* __ssashlha3: Fixed-point fractional library routines. 46600 (line 407) 46601* __ssashlhq3: Fixed-point fractional library routines. 46602 (line 403) 46603* __ssashlsa3: Fixed-point fractional library routines. 46604 (line 408) 46605* __ssashlsq3: Fixed-point fractional library routines. 46606 (line 404) 46607* __ssashlta3: Fixed-point fractional library routines. 46608 (line 410) 46609* __ssdivda3: Fixed-point fractional library routines. 46610 (line 268) 46611* __ssdivdq3: Fixed-point fractional library routines. 46612 (line 263) 46613* __ssdivha3: Fixed-point fractional library routines. 46614 (line 265) 46615* __ssdivhq3: Fixed-point fractional library routines. 46616 (line 261) 46617* __ssdivqq3: Fixed-point fractional library routines. 46618 (line 259) 46619* __ssdivsa3: Fixed-point fractional library routines. 46620 (line 267) 46621* __ssdivsq3: Fixed-point fractional library routines. 46622 (line 262) 46623* __ssdivta3: Fixed-point fractional library routines. 46624 (line 269) 46625* __ssmulda3: Fixed-point fractional library routines. 46626 (line 200) 46627* __ssmuldq3: Fixed-point fractional library routines. 46628 (line 195) 46629* __ssmulha3: Fixed-point fractional library routines. 46630 (line 197) 46631* __ssmulhq3: Fixed-point fractional library routines. 46632 (line 193) 46633* __ssmulqq3: Fixed-point fractional library routines. 46634 (line 191) 46635* __ssmulsa3: Fixed-point fractional library routines. 46636 (line 199) 46637* __ssmulsq3: Fixed-point fractional library routines. 46638 (line 194) 46639* __ssmulta3: Fixed-point fractional library routines. 46640 (line 201) 46641* __ssnegda2: Fixed-point fractional library routines. 46642 (line 323) 46643* __ssnegdq2: Fixed-point fractional library routines. 46644 (line 320) 46645* __ssnegha2: Fixed-point fractional library routines. 46646 (line 321) 46647* __ssneghq2: Fixed-point fractional library routines. 46648 (line 318) 46649* __ssnegqq2: Fixed-point fractional library routines. 46650 (line 317) 46651* __ssnegsa2: Fixed-point fractional library routines. 46652 (line 322) 46653* __ssnegsq2: Fixed-point fractional library routines. 46654 (line 319) 46655* __ssnegta2: Fixed-point fractional library routines. 46656 (line 324) 46657* __sssubda3: Fixed-point fractional library routines. 46658 (line 136) 46659* __sssubdq3: Fixed-point fractional library routines. 46660 (line 131) 46661* __sssubha3: Fixed-point fractional library routines. 46662 (line 133) 46663* __sssubhq3: Fixed-point fractional library routines. 46664 (line 129) 46665* __sssubqq3: Fixed-point fractional library routines. 46666 (line 127) 46667* __sssubsa3: Fixed-point fractional library routines. 46668 (line 135) 46669* __sssubsq3: Fixed-point fractional library routines. 46670 (line 130) 46671* __sssubta3: Fixed-point fractional library routines. 46672 (line 137) 46673* __subda3: Fixed-point fractional library routines. 46674 (line 114) 46675* __subdf3: Soft float library routines. 46676 (line 30) 46677* __subdq3: Fixed-point fractional library routines. 46678 (line 101) 46679* __subha3: Fixed-point fractional library routines. 46680 (line 111) 46681* __subhq3: Fixed-point fractional library routines. 46682 (line 99) 46683* __subqq3: Fixed-point fractional library routines. 46684 (line 97) 46685* __subsa3: Fixed-point fractional library routines. 46686 (line 113) 46687* __subsf3: Soft float library routines. 46688 (line 29) 46689* __subsq3: Fixed-point fractional library routines. 46690 (line 100) 46691* __subta3: Fixed-point fractional library routines. 46692 (line 115) 46693* __subtf3: Soft float library routines. 46694 (line 31) 46695* __subuda3: Fixed-point fractional library routines. 46696 (line 121) 46697* __subudq3: Fixed-point fractional library routines. 46698 (line 109) 46699* __subuha3: Fixed-point fractional library routines. 46700 (line 117) 46701* __subuhq3: Fixed-point fractional library routines. 46702 (line 105) 46703* __subuqq3: Fixed-point fractional library routines. 46704 (line 103) 46705* __subusa3: Fixed-point fractional library routines. 46706 (line 119) 46707* __subusq3: Fixed-point fractional library routines. 46708 (line 107) 46709* __subuta3: Fixed-point fractional library routines. 46710 (line 123) 46711* __subvdi3: Integer library routines. 46712 (line 122) 46713* __subvsi3: Integer library routines. 46714 (line 121) 46715* __subxf3: Soft float library routines. 46716 (line 33) 46717* __truncdfsf2: Soft float library routines. 46718 (line 75) 46719* __trunctfdf2: Soft float library routines. 46720 (line 72) 46721* __trunctfsf2: Soft float library routines. 46722 (line 74) 46723* __truncxfdf2: Soft float library routines. 46724 (line 71) 46725* __truncxfsf2: Soft float library routines. 46726 (line 73) 46727* __ucmpdi2: Integer library routines. 46728 (line 92) 46729* __ucmpti2: Integer library routines. 46730 (line 93) 46731* __udivdi3: Integer library routines. 46732 (line 52) 46733* __udivmoddi4: Integer library routines. 46734 (line 59) 46735* __udivmodti4: Integer library routines. 46736 (line 61) 46737* __udivsi3: Integer library routines. 46738 (line 50) 46739* __udivti3: Integer library routines. 46740 (line 54) 46741* __udivuda3: Fixed-point fractional library routines. 46742 (line 252) 46743* __udivudq3: Fixed-point fractional library routines. 46744 (line 246) 46745* __udivuha3: Fixed-point fractional library routines. 46746 (line 248) 46747* __udivuhq3: Fixed-point fractional library routines. 46748 (line 242) 46749* __udivuqq3: Fixed-point fractional library routines. 46750 (line 240) 46751* __udivusa3: Fixed-point fractional library routines. 46752 (line 250) 46753* __udivusq3: Fixed-point fractional library routines. 46754 (line 244) 46755* __udivuta3: Fixed-point fractional library routines. 46756 (line 254) 46757* __umoddi3: Integer library routines. 46758 (line 69) 46759* __umodsi3: Integer library routines. 46760 (line 67) 46761* __umodti3: Integer library routines. 46762 (line 71) 46763* __unorddf2: Soft float library routines. 46764 (line 172) 46765* __unordsf2: Soft float library routines. 46766 (line 171) 46767* __unordtf2: Soft float library routines. 46768 (line 173) 46769* __usadduda3: Fixed-point fractional library routines. 46770 (line 91) 46771* __usaddudq3: Fixed-point fractional library routines. 46772 (line 85) 46773* __usadduha3: Fixed-point fractional library routines. 46774 (line 87) 46775* __usadduhq3: Fixed-point fractional library routines. 46776 (line 81) 46777* __usadduqq3: Fixed-point fractional library routines. 46778 (line 79) 46779* __usaddusa3: Fixed-point fractional library routines. 46780 (line 89) 46781* __usaddusq3: Fixed-point fractional library routines. 46782 (line 83) 46783* __usadduta3: Fixed-point fractional library routines. 46784 (line 93) 46785* __usashluda3: Fixed-point fractional library routines. 46786 (line 427) 46787* __usashludq3: Fixed-point fractional library routines. 46788 (line 421) 46789* __usashluha3: Fixed-point fractional library routines. 46790 (line 423) 46791* __usashluhq3: Fixed-point fractional library routines. 46792 (line 417) 46793* __usashluqq3: Fixed-point fractional library routines. 46794 (line 415) 46795* __usashlusa3: Fixed-point fractional library routines. 46796 (line 425) 46797* __usashlusq3: Fixed-point fractional library routines. 46798 (line 419) 46799* __usashluta3: Fixed-point fractional library routines. 46800 (line 429) 46801* __usdivuda3: Fixed-point fractional library routines. 46802 (line 286) 46803* __usdivudq3: Fixed-point fractional library routines. 46804 (line 280) 46805* __usdivuha3: Fixed-point fractional library routines. 46806 (line 282) 46807* __usdivuhq3: Fixed-point fractional library routines. 46808 (line 276) 46809* __usdivuqq3: Fixed-point fractional library routines. 46810 (line 274) 46811* __usdivusa3: Fixed-point fractional library routines. 46812 (line 284) 46813* __usdivusq3: Fixed-point fractional library routines. 46814 (line 278) 46815* __usdivuta3: Fixed-point fractional library routines. 46816 (line 288) 46817* __usmuluda3: Fixed-point fractional library routines. 46818 (line 218) 46819* __usmuludq3: Fixed-point fractional library routines. 46820 (line 212) 46821* __usmuluha3: Fixed-point fractional library routines. 46822 (line 214) 46823* __usmuluhq3: Fixed-point fractional library routines. 46824 (line 208) 46825* __usmuluqq3: Fixed-point fractional library routines. 46826 (line 206) 46827* __usmulusa3: Fixed-point fractional library routines. 46828 (line 216) 46829* __usmulusq3: Fixed-point fractional library routines. 46830 (line 210) 46831* __usmuluta3: Fixed-point fractional library routines. 46832 (line 220) 46833* __usneguda2: Fixed-point fractional library routines. 46834 (line 337) 46835* __usnegudq2: Fixed-point fractional library routines. 46836 (line 332) 46837* __usneguha2: Fixed-point fractional library routines. 46838 (line 334) 46839* __usneguhq2: Fixed-point fractional library routines. 46840 (line 329) 46841* __usneguqq2: Fixed-point fractional library routines. 46842 (line 327) 46843* __usnegusa2: Fixed-point fractional library routines. 46844 (line 336) 46845* __usnegusq2: Fixed-point fractional library routines. 46846 (line 330) 46847* __usneguta2: Fixed-point fractional library routines. 46848 (line 339) 46849* __ussubuda3: Fixed-point fractional library routines. 46850 (line 154) 46851* __ussubudq3: Fixed-point fractional library routines. 46852 (line 148) 46853* __ussubuha3: Fixed-point fractional library routines. 46854 (line 150) 46855* __ussubuhq3: Fixed-point fractional library routines. 46856 (line 144) 46857* __ussubuqq3: Fixed-point fractional library routines. 46858 (line 142) 46859* __ussubusa3: Fixed-point fractional library routines. 46860 (line 152) 46861* __ussubusq3: Fixed-point fractional library routines. 46862 (line 146) 46863* __ussubuta3: Fixed-point fractional library routines. 46864 (line 156) 46865* abort: Portability. (line 20) 46866* abs: Arithmetic. (line 200) 46867* abs and attributes: Expressions. (line 83) 46868* absence_set: Processor pipeline description. 46869 (line 223) 46870* absM2 instruction pattern: Standard Names. (line 582) 46871* absolute value: Arithmetic. (line 200) 46872* ABS_EXPR: Unary and Binary Expressions. 46873 (line 6) 46874* access to operands: Accessors. (line 6) 46875* access to special operands: Special Accessors. (line 6) 46876* accessors: Accessors. (line 6) 46877* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 48) 46878* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 133) 46879* ACCUM_TYPE_SIZE: Type Layout. (line 87) 46880* ADA_LONG_TYPE_SIZE: Type Layout. (line 25) 46881* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code. 46882 (line 6) 46883* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 14) 46884* addM3 instruction pattern: Standard Names. (line 260) 46885* addMODEcc instruction pattern: Standard Names. (line 1112) 46886* addptrM3 instruction pattern: Standard Names. (line 290) 46887* address constraints: Simple Constraints. (line 162) 46888* addressing modes: Addressing Modes. (line 6) 46889* address_operand: Machine-Independent Predicates. 46890 (line 62) 46891* address_operand <1>: Simple Constraints. (line 166) 46892* addr_diff_vec: Side Effects. (line 314) 46893* addr_diff_vec, length of: Insn Lengths. (line 26) 46894* ADDR_EXPR: Storage References. (line 6) 46895* addr_vec: Side Effects. (line 309) 46896* addr_vec, length of: Insn Lengths. (line 26) 46897* addvM4 instruction pattern: Standard Names. (line 276) 46898* ADJUST_FIELD_ALIGN: Storage Layout. (line 195) 46899* ADJUST_INSN_LENGTH: Insn Lengths. (line 41) 46900* ADJUST_REG_ALLOC_ORDER: Allocation Order. (line 22) 46901* aggregates as return values: Aggregate Return. (line 6) 46902* alias: Alias analysis. (line 6) 46903* allocate_stack instruction pattern: Standard Names. (line 1426) 46904* ALL_REGS: Register Classes. (line 17) 46905* alternate entry points: Insns. (line 146) 46906* anchored addresses: Anchored Addresses. (line 6) 46907* and: Arithmetic. (line 158) 46908* and and attributes: Expressions. (line 50) 46909* and, canonicalization of: Insn Canonicalizations. 46910 (line 51) 46911* andM3 instruction pattern: Standard Names. (line 266) 46912* ANNOTATE_EXPR: Unary and Binary Expressions. 46913 (line 6) 46914* annotations: Annotations. (line 6) 46915* APPLY_RESULT_SIZE: Scalar Return. (line 112) 46916* ARGS_GROW_DOWNWARD: Frame Layout. (line 34) 46917* argument passing: Interface. (line 36) 46918* arguments in registers: Register Arguments. (line 6) 46919* arguments on stack: Stack Arguments. (line 6) 46920* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 194) 46921* ARG_POINTER_REGNUM: Frame Registers. (line 40) 46922* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 46923* arg_pointer_rtx: Frame Registers. (line 104) 46924* arithmetic library: Soft float library routines. 46925 (line 6) 46926* arithmetic shift: Arithmetic. (line 173) 46927* arithmetic shift with signed saturation: Arithmetic. (line 173) 46928* arithmetic shift with unsigned saturation: Arithmetic. (line 173) 46929* arithmetic, in RTL: Arithmetic. (line 6) 46930* ARITHMETIC_TYPE_P: Types for C++. (line 59) 46931* array: Types. (line 6) 46932* ARRAY_RANGE_REF: Storage References. (line 6) 46933* ARRAY_REF: Storage References. (line 6) 46934* ARRAY_TYPE: Types. (line 6) 46935* ashift: Arithmetic. (line 173) 46936* ashift and attributes: Expressions. (line 83) 46937* ashiftrt: Arithmetic. (line 190) 46938* ashiftrt and attributes: Expressions. (line 83) 46939* ashlM3 instruction pattern: Standard Names. (line 553) 46940* ashrM3 instruction pattern: Standard Names. (line 563) 46941* ASM_APP_OFF: File Framework. (line 76) 46942* ASM_APP_ON: File Framework. (line 69) 46943* ASM_COMMENT_START: File Framework. (line 64) 46944* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 108) 46945* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 123) 46946* ASM_DECLARE_OBJECT_NAME: Label Output. (line 136) 46947* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 164) 46948* ASM_FINAL_SPEC: Driver. (line 81) 46949* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 172) 46950* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 398) 46951* asm_fprintf: Instruction Output. (line 150) 46952* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 160) 46953* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 382) 46954* asm_input: Side Effects. (line 296) 46955* asm_input and /v: Flags. (line 76) 46956* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 80) 46957* asm_noperands: Insns. (line 304) 46958* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 78) 46959* asm_operands and /v: Flags. (line 76) 46960* asm_operands, RTL sharing: Sharing. (line 45) 46961* asm_operands, usage: Assembler. (line 6) 46962* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 8) 46963* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 25) 46964* ASM_OUTPUT_ALIGN: Alignment Output. (line 85) 46965* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 45) 46966* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 29) 46967* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 36) 46968* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 89) 46969* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 82) 46970* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 90) 46971* ASM_OUTPUT_ASCII: Data Output. (line 54) 46972* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 50) 46973* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 37) 46974* ASM_OUTPUT_COMMON: Uninitialized Data. (line 9) 46975* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 370) 46976* ASM_OUTPUT_DEF: Label Output. (line 419) 46977* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 426) 46978* ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 77) 46979* ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 86) 46980* ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 92) 46981* ASM_OUTPUT_DWARF_TABLE_REF: SDB and DWARF. (line 97) 46982* ASM_OUTPUT_DWARF_VMS_DELTA: SDB and DWARF. (line 81) 46983* ASM_OUTPUT_EXTERNAL: Label Output. (line 299) 46984* ASM_OUTPUT_FDESC: Data Output. (line 63) 46985* ASM_OUTPUT_FUNCTION_LABEL: Label Output. (line 16) 46986* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 27) 46987* ASM_OUTPUT_LABEL: Label Output. (line 8) 46988* ASM_OUTPUT_LABELREF: Label Output. (line 321) 46989* ASM_OUTPUT_LABEL_REF: Label Output. (line 343) 46990* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 69) 46991* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 94) 46992* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 51) 46993* ASM_OUTPUT_OPCODE: Instruction Output. (line 35) 46994* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 112) 46995* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 76) 46996* ASM_OUTPUT_REG_POP: Instruction Output. (line 206) 46997* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 201) 46998* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 45) 46999* ASM_OUTPUT_SKIP: Alignment Output. (line 72) 47000* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 83) 47001* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 87) 47002* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 336) 47003* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 98) 47004* ASM_OUTPUT_WEAKREF: Label Output. (line 231) 47005* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 445) 47006* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 66) 47007* ASM_SPEC: Driver. (line 73) 47008* ASM_STABD_OP: DBX Options. (line 34) 47009* ASM_STABN_OP: DBX Options. (line 41) 47010* ASM_STABS_OP: DBX Options. (line 28) 47011* ASM_WEAKEN_DECL: Label Output. (line 223) 47012* ASM_WEAKEN_LABEL: Label Output. (line 210) 47013* assembler format: File Framework. (line 6) 47014* assembler instructions in RTL: Assembler. (line 6) 47015* ASSEMBLER_DIALECT: Instruction Output. (line 172) 47016* assemble_name: Label Output. (line 8) 47017* assemble_name_raw: Label Output. (line 27) 47018* assigning attribute values to insns: Tagging Insns. (line 6) 47019* ASSUME_EXTENDED_UNWIND_CONTEXT: Frame Registers. (line 165) 47020* asterisk in template: Output Statement. (line 29) 47021* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 88) 47022* atan2M3 instruction pattern: Standard Names. (line 665) 47023* atomic: GTY Options. (line 204) 47024* atomic_addMODE instruction pattern: Standard Names. (line 1828) 47025* atomic_add_fetchMODE instruction pattern: Standard Names. (line 1857) 47026* atomic_andMODE instruction pattern: Standard Names. (line 1828) 47027* atomic_and_fetchMODE instruction pattern: Standard Names. (line 1857) 47028* atomic_compare_and_swapMODE instruction pattern: Standard Names. 47029 (line 1764) 47030* atomic_exchangeMODE instruction pattern: Standard Names. (line 1816) 47031* atomic_fetch_addMODE instruction pattern: Standard Names. (line 1842) 47032* atomic_fetch_andMODE instruction pattern: Standard Names. (line 1842) 47033* atomic_fetch_nandMODE instruction pattern: Standard Names. (line 1842) 47034* atomic_fetch_orMODE instruction pattern: Standard Names. (line 1842) 47035* atomic_fetch_subMODE instruction pattern: Standard Names. (line 1842) 47036* atomic_fetch_xorMODE instruction pattern: Standard Names. (line 1842) 47037* atomic_loadMODE instruction pattern: Standard Names. (line 1795) 47038* atomic_nandMODE instruction pattern: Standard Names. (line 1828) 47039* atomic_nand_fetchMODE instruction pattern: Standard Names. (line 1857) 47040* atomic_orMODE instruction pattern: Standard Names. (line 1828) 47041* atomic_or_fetchMODE instruction pattern: Standard Names. (line 1857) 47042* atomic_storeMODE instruction pattern: Standard Names. (line 1805) 47043* atomic_subMODE instruction pattern: Standard Names. (line 1828) 47044* atomic_sub_fetchMODE instruction pattern: Standard Names. (line 1857) 47045* atomic_test_and_set instruction pattern: Standard Names. (line 1874) 47046* atomic_xorMODE instruction pattern: Standard Names. (line 1828) 47047* atomic_xor_fetchMODE instruction pattern: Standard Names. (line 1857) 47048* attr: Expressions. (line 163) 47049* attr <1>: Tagging Insns. (line 54) 47050* attribute expressions: Expressions. (line 6) 47051* attribute specifications: Attr Example. (line 6) 47052* attribute specifications example: Attr Example. (line 6) 47053* attributes: Attributes. (line 6) 47054* attributes, defining: Defining Attributes. 47055 (line 6) 47056* attributes, target-specific: Target Attributes. (line 6) 47057* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 177) 47058* attr_flag: Expressions. (line 138) 47059* autoincrement addressing, availability: Portability. (line 20) 47060* autoincrement/decrement addressing: Simple Constraints. (line 30) 47061* automata_option: Processor pipeline description. 47062 (line 304) 47063* automaton based pipeline description: Processor pipeline description. 47064 (line 6) 47065* automaton based pipeline description <1>: Processor pipeline description. 47066 (line 49) 47067* automaton based scheduler: Processor pipeline description. 47068 (line 6) 47069* AVOID_CCMODE_COPIES: Values in Registers. 47070 (line 150) 47071* backslash: Output Template. (line 46) 47072* barrier: Insns. (line 176) 47073* barrier and /f: Flags. (line 107) 47074* barrier and /v: Flags. (line 44) 47075* BASE_REG_CLASS: Register Classes. (line 111) 47076* basic block: Basic Blocks. (line 6) 47077* Basic Statements: Basic Statements. (line 6) 47078* basic-block.h: Control Flow. (line 6) 47079* basic_block: Basic Blocks. (line 6) 47080* BASIC_BLOCK: Basic Blocks. (line 14) 47081* BB_HEAD, BB_END: Maintaining the CFG. 47082 (line 76) 47083* bb_seq: GIMPLE sequences. (line 72) 47084* BIGGEST_ALIGNMENT: Storage Layout. (line 162) 47085* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 188) 47086* BImode: Machine Modes. (line 22) 47087* BIND_EXPR: Unary and Binary Expressions. 47088 (line 6) 47089* BINFO_TYPE: Classes. (line 6) 47090* bit-fields: Bit-Fields. (line 6) 47091* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 398) 47092* BITS_BIG_ENDIAN: Storage Layout. (line 11) 47093* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 47094* BITS_PER_UNIT: Machine Modes. (line 354) 47095* BITS_PER_WORD: Storage Layout. (line 50) 47096* bitwise complement: Arithmetic. (line 154) 47097* bitwise exclusive-or: Arithmetic. (line 168) 47098* bitwise inclusive-or: Arithmetic. (line 163) 47099* bitwise logical-and: Arithmetic. (line 158) 47100* BIT_AND_EXPR: Unary and Binary Expressions. 47101 (line 6) 47102* BIT_IOR_EXPR: Unary and Binary Expressions. 47103 (line 6) 47104* BIT_NOT_EXPR: Unary and Binary Expressions. 47105 (line 6) 47106* BIT_XOR_EXPR: Unary and Binary Expressions. 47107 (line 6) 47108* BLKmode: Machine Modes. (line 185) 47109* BLKmode, and function return values: Calls. (line 23) 47110* blockage instruction pattern: Standard Names. (line 1627) 47111* Blocks: Blocks. (line 6) 47112* BLOCK_FOR_INSN, gimple_bb: Maintaining the CFG. 47113 (line 28) 47114* BLOCK_REG_PADDING: Register Arguments. (line 242) 47115* BND32mode: Machine Modes. (line 209) 47116* BND64mode: Machine Modes. (line 209) 47117* bool: Misc. (line 992) 47118* BOOLEAN_TYPE: Types. (line 6) 47119* BOOL_TYPE_SIZE: Type Layout. (line 43) 47120* branch prediction: Profile information. 47121 (line 24) 47122* BRANCH_COST: Costs. (line 104) 47123* break_out_memory_refs: Addressing Modes. (line 134) 47124* BREAK_STMT: Statements for C++. (line 6) 47125* BSS_SECTION_ASM_OP: Sections. (line 67) 47126* bswap: Arithmetic. (line 246) 47127* bswapM2 instruction pattern: Standard Names. (line 571) 47128* btruncM2 instruction pattern: Standard Names. (line 683) 47129* build0: Macros and Functions. 47130 (line 16) 47131* build1: Macros and Functions. 47132 (line 17) 47133* build2: Macros and Functions. 47134 (line 18) 47135* build3: Macros and Functions. 47136 (line 19) 47137* build4: Macros and Functions. 47138 (line 20) 47139* build5: Macros and Functions. 47140 (line 21) 47141* build6: Macros and Functions. 47142 (line 22) 47143* builtin_longjmp instruction pattern: Standard Names. (line 1524) 47144* builtin_setjmp_receiver instruction pattern: Standard Names. 47145 (line 1514) 47146* builtin_setjmp_setup instruction pattern: Standard Names. (line 1503) 47147* BYTES_BIG_ENDIAN: Storage Layout. (line 23) 47148* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 219) 47149* byte_mode: Machine Modes. (line 367) 47150* C statements for assembler output: Output Statement. (line 6) 47151* cache: GTY Options. (line 125) 47152* call: Flags. (line 221) 47153* call <1>: Side Effects. (line 92) 47154* call instruction pattern: Standard Names. (line 1169) 47155* call usage: Calls. (line 10) 47156* call, in call_insn: Flags. (line 33) 47157* call, in mem: Flags. (line 81) 47158* call-clobbered register: Register Basics. (line 35) 47159* call-clobbered register <1>: Register Basics. (line 46) 47160* call-clobbered register <2>: Register Basics. (line 53) 47161* call-saved register: Register Basics. (line 35) 47162* call-saved register <1>: Register Basics. (line 46) 47163* call-saved register <2>: Register Basics. (line 53) 47164* call-used register: Register Basics. (line 35) 47165* call-used register <1>: Register Basics. (line 46) 47166* call-used register <2>: Register Basics. (line 53) 47167* calling conventions: Stack and Calling. (line 6) 47168* calling functions in RTL: Calls. (line 6) 47169* CALL_EXPR: Unary and Binary Expressions. 47170 (line 6) 47171* call_insn: Insns. (line 95) 47172* call_insn and /c: Flags. (line 33) 47173* call_insn and /f: Flags. (line 107) 47174* call_insn and /i: Flags. (line 24) 47175* call_insn and /j: Flags. (line 161) 47176* call_insn and /s: Flags. (line 49) 47177* call_insn and /s <1>: Flags. (line 148) 47178* call_insn and /u: Flags. (line 19) 47179* call_insn and /u <1>: Flags. (line 39) 47180* call_insn and /u or /i: Flags. (line 29) 47181* call_insn and /v: Flags. (line 44) 47182* CALL_INSN_FUNCTION_USAGE: Insns. (line 101) 47183* call_pop instruction pattern: Standard Names. (line 1197) 47184* CALL_POPS_ARGS: Stack Arguments. (line 138) 47185* CALL_REALLY_USED_REGISTERS: Register Basics. (line 45) 47186* CALL_USED_REGISTERS: Register Basics. (line 34) 47187* call_used_regs: Register Basics. (line 59) 47188* call_value instruction pattern: Standard Names. (line 1189) 47189* call_value_pop instruction pattern: Standard Names. (line 1197) 47190* canadian: Configure Terms. (line 6) 47191* CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 533) 47192* CANNOT_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory. 47193 (line 276) 47194* canonicalization of instructions: Insn Canonicalizations. 47195 (line 6) 47196* canonicalize_funcptr_for_compare instruction pattern: Standard Names. 47197 (line 1358) 47198* can_create_pseudo_p: Standard Names. (line 75) 47199* can_fallthru: Basic Blocks. (line 67) 47200* caret: Multi-Alternative. (line 52) 47201* casesi instruction pattern: Standard Names. (line 1290) 47202* CASE_VECTOR_MODE: Misc. (line 26) 47203* CASE_VECTOR_PC_RELATIVE: Misc. (line 39) 47204* CASE_VECTOR_SHORTEN_MODE: Misc. (line 30) 47205* cbranchMODE4 instruction pattern: Standard Names. (line 1158) 47206* cc0: Regs and Memory. (line 303) 47207* cc0 <1>: CC0 Condition Codes. 47208 (line 6) 47209* cc0, RTL sharing: Sharing. (line 27) 47210* cc0_rtx: Regs and Memory. (line 329) 47211* CC1PLUS_SPEC: Driver. (line 63) 47212* CC1_SPEC: Driver. (line 55) 47213* CCmode: Machine Modes. (line 178) 47214* CCmode <1>: MODE_CC Condition Codes. 47215 (line 6) 47216* cc_status: CC0 Condition Codes. 47217 (line 6) 47218* CC_STATUS_MDEP: CC0 Condition Codes. 47219 (line 16) 47220* CC_STATUS_MDEP_INIT: CC0 Condition Codes. 47221 (line 22) 47222* CDImode: Machine Modes. (line 204) 47223* ceilM2 instruction pattern: Standard Names. (line 699) 47224* CEIL_DIV_EXPR: Unary and Binary Expressions. 47225 (line 6) 47226* CEIL_MOD_EXPR: Unary and Binary Expressions. 47227 (line 6) 47228* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 226) 47229* CFG verification: Maintaining the CFG. 47230 (line 117) 47231* CFG, Control Flow Graph: Control Flow. (line 6) 47232* cfghooks.h: Maintaining the CFG. 47233 (line 6) 47234* cgraph_finalize_function: Parsing pass. (line 51) 47235* chain_circular: GTY Options. (line 167) 47236* chain_next: GTY Options. (line 167) 47237* chain_prev: GTY Options. (line 167) 47238* change_address: Standard Names. (line 47) 47239* CHAR_TYPE_SIZE: Type Layout. (line 38) 47240* check_stack instruction pattern: Standard Names. (line 1444) 47241* CHImode: Machine Modes. (line 204) 47242* CILK_PLUS: Cilk Plus Transformation. 47243 (line 6) 47244* class definitions, register: Register Classes. (line 6) 47245* class preference constraints: Class Preferences. (line 6) 47246* class, scope: Classes. (line 6) 47247* classes of RTX codes: RTL Classes. (line 6) 47248* CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 47249* CLASSTYPE_HAS_MUTABLE: Classes. (line 85) 47250* CLASSTYPE_NON_POD_P: Classes. (line 90) 47251* CLASS_MAX_NREGS: Register Classes. (line 521) 47252* CLASS_TYPE_P: Types for C++. (line 63) 47253* Cleanups: Cleanups. (line 6) 47254* CLEANUP_DECL: Statements for C++. (line 6) 47255* CLEANUP_EXPR: Statements for C++. (line 6) 47256* CLEANUP_POINT_EXPR: Unary and Binary Expressions. 47257 (line 6) 47258* CLEANUP_STMT: Statements for C++. (line 6) 47259* clear_cache instruction pattern: Standard Names. (line 1934) 47260* CLEAR_INSN_CACHE: Trampolines. (line 98) 47261* CLEAR_RATIO: Costs. (line 204) 47262* clobber: Side Effects. (line 106) 47263* clrsb: Arithmetic. (line 215) 47264* clrsbM2 instruction pattern: Standard Names. (line 764) 47265* clz: Arithmetic. (line 222) 47266* clzM2 instruction pattern: Standard Names. (line 771) 47267* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 304) 47268* cmpmemM instruction pattern: Standard Names. (line 912) 47269* cmpstrM instruction pattern: Standard Names. (line 891) 47270* cmpstrnM instruction pattern: Standard Names. (line 878) 47271* code generation RTL sequences: Expander Definitions. 47272 (line 6) 47273* code iterators in .md files: Code Iterators. (line 6) 47274* codes, RTL expression: RTL Objects. (line 47) 47275* code_label: Insns. (line 125) 47276* CODE_LABEL: Basic Blocks. (line 50) 47277* code_label and /i: Flags. (line 59) 47278* code_label and /v: Flags. (line 44) 47279* CODE_LABEL_NUMBER: Insns. (line 125) 47280* COImode: Machine Modes. (line 204) 47281* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 47282* COLLECT_EXPORT_LIST: Misc. (line 866) 47283* COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 47284 (line 43) 47285* COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 47286 (line 32) 47287* commit_edge_insertions: Maintaining the CFG. 47288 (line 105) 47289* compare: Arithmetic. (line 46) 47290* compare, canonicalization of: Insn Canonicalizations. 47291 (line 36) 47292* comparison_operator: Machine-Independent Predicates. 47293 (line 110) 47294* compiler passes and files: Passes. (line 6) 47295* complement, bitwise: Arithmetic. (line 154) 47296* COMPLEX_CST: Constant expressions. 47297 (line 6) 47298* COMPLEX_EXPR: Unary and Binary Expressions. 47299 (line 6) 47300* COMPLEX_TYPE: Types. (line 6) 47301* COMPONENT_REF: Storage References. (line 6) 47302* Compound Expressions: Compound Expressions. 47303 (line 6) 47304* Compound Lvalues: Compound Lvalues. (line 6) 47305* COMPOUND_EXPR: Unary and Binary Expressions. 47306 (line 6) 47307* COMPOUND_LITERAL_EXPR: Unary and Binary Expressions. 47308 (line 6) 47309* COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions. 47310 (line 377) 47311* COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions. 47312 (line 377) 47313* computed jump: Edges. (line 127) 47314* computing the length of an insn: Insn Lengths. (line 6) 47315* concat: Regs and Memory. (line 381) 47316* concatn: Regs and Memory. (line 387) 47317* cond: Comparisons. (line 90) 47318* cond and attributes: Expressions. (line 37) 47319* condition code register: Regs and Memory. (line 303) 47320* condition code status: Condition Code. (line 6) 47321* condition codes: Comparisons. (line 20) 47322* conditional execution: Conditional Execution. 47323 (line 6) 47324* Conditional Expressions: Conditional Expressions. 47325 (line 6) 47326* conditions, in patterns: Patterns. (line 43) 47327* cond_exec: Side Effects. (line 254) 47328* COND_EXPR: Unary and Binary Expressions. 47329 (line 6) 47330* configuration file: Filesystem. (line 6) 47331* configuration file <1>: Host Misc. (line 6) 47332* configure terms: Configure Terms. (line 6) 47333* CONJ_EXPR: Unary and Binary Expressions. 47334 (line 6) 47335* const: Constants. (line 140) 47336* const0_rtx: Constants. (line 21) 47337* CONST0_RTX: Constants. (line 160) 47338* const1_rtx: Constants. (line 21) 47339* CONST1_RTX: Constants. (line 160) 47340* const2_rtx: Constants. (line 21) 47341* CONST2_RTX: Constants. (line 160) 47342* constant attributes: Constant Attributes. 47343 (line 6) 47344* constant definitions: Constant Definitions. 47345 (line 6) 47346* constants in constraints: Simple Constraints. (line 68) 47347* CONSTANT_ADDRESS_P: Addressing Modes. (line 28) 47348* CONSTANT_ALIGNMENT: Storage Layout. (line 241) 47349* CONSTANT_P: Addressing Modes. (line 35) 47350* CONSTANT_POOL_ADDRESS_P: Flags. (line 10) 47351* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 68) 47352* constm1_rtx: Constants. (line 21) 47353* constraint modifier characters: Modifiers. (line 6) 47354* constraint, matching: Simple Constraints. (line 140) 47355* constraints: Constraints. (line 6) 47356* constraints, defining: Define Constraints. (line 6) 47357* constraints, machine specific: Machine Constraints. 47358 (line 6) 47359* constraints, testing: C Constraint Interface. 47360 (line 6) 47361* constraint_num: C Constraint Interface. 47362 (line 30) 47363* constraint_satisfied_p: C Constraint Interface. 47364 (line 42) 47365* CONSTRUCTOR: Unary and Binary Expressions. 47366 (line 6) 47367* constructors, automatic calls: Collect2. (line 15) 47368* constructors, output of: Initialization. (line 6) 47369* CONST_DECL: Declarations. (line 6) 47370* const_double: Constants. (line 37) 47371* const_double, RTL sharing: Sharing. (line 29) 47372* CONST_DOUBLE_LOW: Constants. (line 54) 47373* const_double_operand: Machine-Independent Predicates. 47374 (line 20) 47375* const_fixed: Constants. (line 93) 47376* const_int: Constants. (line 8) 47377* const_int and attribute tests: Expressions. (line 47) 47378* const_int and attributes: Expressions. (line 10) 47379* const_int, RTL sharing: Sharing. (line 23) 47380* const_int_operand: Machine-Independent Predicates. 47381 (line 15) 47382* const_string: Constants. (line 112) 47383* const_string and attributes: Expressions. (line 20) 47384* const_true_rtx: Constants. (line 31) 47385* const_vector: Constants. (line 100) 47386* const_vector, RTL sharing: Sharing. (line 32) 47387* CONST_WIDE_INT: Constants. (line 67) 47388* CONST_WIDE_INT_ELT: Constants. (line 89) 47389* CONST_WIDE_INT_NUNITS: Constants. (line 84) 47390* CONST_WIDE_INT_VEC: Constants. (line 80) 47391* container: Containers. (line 6) 47392* CONTINUE_STMT: Statements for C++. (line 6) 47393* contributors: Contributors. (line 6) 47394* controlling register usage: Register Basics. (line 73) 47395* controlling the compilation driver: Driver. (line 6) 47396* conventions, run-time: Interface. (line 6) 47397* conversions: Conversions. (line 6) 47398* CONVERT_EXPR: Unary and Binary Expressions. 47399 (line 6) 47400* copysignM3 instruction pattern: Standard Names. (line 745) 47401* copy_rtx: Addressing Modes. (line 189) 47402* copy_rtx_if_shared: Sharing. (line 64) 47403* cosM2 instruction pattern: Standard Names. (line 611) 47404* costs of instructions: Costs. (line 6) 47405* CPLUSPLUS_CPP_SPEC: Driver. (line 50) 47406* CPP_SPEC: Driver. (line 43) 47407* CP_INTEGRAL_TYPE: Types for C++. (line 55) 47408* cp_namespace_decls: Namespaces. (line 49) 47409* CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33) 47410* CP_TYPE_CONST_P: Types for C++. (line 24) 47411* cp_type_quals: Types for C++. (line 6) 47412* cp_type_quals <1>: Types for C++. (line 16) 47413* CP_TYPE_RESTRICT_P: Types for C++. (line 30) 47414* CP_TYPE_VOLATILE_P: Types for C++. (line 27) 47415* CQImode: Machine Modes. (line 204) 47416* cross compilation and floating point: Floating Point. (line 6) 47417* crtl->args.pops_args: Function Entry. (line 104) 47418* crtl->args.pretend_args_size: Function Entry. (line 110) 47419* crtl->outgoing_args_size: Stack Arguments. (line 48) 47420* CRTSTUFF_T_CFLAGS: Target Fragment. (line 15) 47421* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 19) 47422* CRT_CALL_STATIC_FUNCTION: Sections. (line 120) 47423* CSImode: Machine Modes. (line 204) 47424* cstoreMODE4 instruction pattern: Standard Names. (line 1119) 47425* CTImode: Machine Modes. (line 204) 47426* ctrapMM4 instruction pattern: Standard Names. (line 1596) 47427* ctz: Arithmetic. (line 230) 47428* ctzM2 instruction pattern: Standard Names. (line 780) 47429* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 305) 47430* CUMULATIVE_ARGS: Register Arguments. (line 140) 47431* current_function_is_leaf: Leaf Functions. (line 50) 47432* current_function_uses_only_leaf_regs: Leaf Functions. (line 50) 47433* current_insn_predicate: Conditional Execution. 47434 (line 27) 47435* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 136) 47436* c_register_pragma: Misc. (line 407) 47437* c_register_pragma_with_expansion: Misc. (line 409) 47438* DAmode: Machine Modes. (line 154) 47439* data bypass: Processor pipeline description. 47440 (line 105) 47441* data bypass <1>: Processor pipeline description. 47442 (line 196) 47443* data dependence delays: Processor pipeline description. 47444 (line 6) 47445* Data Dependency Analysis: Dependency analysis. 47446 (line 6) 47447* data structures: Per-Function Data. (line 6) 47448* DATA_ABI_ALIGNMENT: Storage Layout. (line 233) 47449* DATA_ALIGNMENT: Storage Layout. (line 220) 47450* DATA_SECTION_ASM_OP: Sections. (line 52) 47451* DBR_OUTPUT_SEQEND: Instruction Output. (line 133) 47452* dbr_sequence_length: Instruction Output. (line 133) 47453* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 100) 47454* DBX_CONTIN_CHAR: DBX Options. (line 63) 47455* DBX_CONTIN_LENGTH: DBX Options. (line 53) 47456* DBX_DEBUGGING_INFO: DBX Options. (line 8) 47457* DBX_FUNCTION_FIRST: DBX Options. (line 94) 47458* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 106) 47459* DBX_NO_XREFS: DBX Options. (line 47) 47460* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 8) 47461* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 33) 47462* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 47463 (line 41) 47464* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 8) 47465* DBX_REGISTER_NUMBER: All Debuggers. (line 8) 47466* DBX_REGPARM_STABS_CODE: DBX Options. (line 84) 47467* DBX_REGPARM_STABS_LETTER: DBX Options. (line 89) 47468* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 79) 47469* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 70) 47470* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 75) 47471* DBX_USE_BINCL: DBX Options. (line 112) 47472* DCmode: Machine Modes. (line 199) 47473* DDmode: Machine Modes. (line 93) 47474* De Morgan's law: Insn Canonicalizations. 47475 (line 51) 47476* dead_or_set_p: define_peephole. (line 65) 47477* DEBUGGER_ARG_OFFSET: All Debuggers. (line 36) 47478* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 27) 47479* debug_expr: Debug Information. (line 22) 47480* DEBUG_EXPR_DECL: Declarations. (line 6) 47481* debug_insn: Insns. (line 236) 47482* DEBUG_SYMS_TEXT: DBX Options. (line 24) 47483* decimal float library: Decimal float library routines. 47484 (line 6) 47485* declaration: Declarations. (line 6) 47486* declarations, RTL: RTL Declarations. (line 6) 47487* DECLARE_LIBRARY_RENAMES: Library Calls. (line 8) 47488* DECL_ALIGN: Declarations. (line 6) 47489* DECL_ANTICIPATED: Functions for C++. (line 42) 47490* DECL_ARGUMENTS: Function Basics. (line 36) 47491* DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158) 47492* DECL_ARTIFICIAL: Working with declarations. 47493 (line 24) 47494* DECL_ARTIFICIAL <1>: Function Basics. (line 6) 47495* DECL_ARTIFICIAL <2>: Function Properties. 47496 (line 47) 47497* DECL_ASSEMBLER_NAME: Function Basics. (line 6) 47498* DECL_ASSEMBLER_NAME <1>: Function Basics. (line 19) 47499* DECL_ATTRIBUTES: Attributes. (line 21) 47500* DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88) 47501* DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84) 47502* DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98) 47503* DECL_CONSTRUCTOR_P: Functions for C++. (line 77) 47504* DECL_CONST_MEMFUNC_P: Functions for C++. (line 71) 47505* DECL_CONTEXT: Namespaces. (line 31) 47506* DECL_CONV_FN_P: Functions for C++. (line 105) 47507* DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92) 47508* DECL_DESTRUCTOR_P: Functions for C++. (line 95) 47509* DECL_EXTERNAL: Declarations. (line 6) 47510* DECL_EXTERNAL <1>: Function Properties. 47511 (line 25) 47512* DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46) 47513* DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61) 47514* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6) 47515* DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties. 47516 (line 61) 47517* DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6) 47518* DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Properties. 47519 (line 55) 47520* DECL_GLOBAL_CTOR_P: Functions for C++. (line 108) 47521* DECL_GLOBAL_DTOR_P: Functions for C++. (line 112) 47522* DECL_INITIAL: Declarations. (line 6) 47523* DECL_INITIAL <1>: Function Basics. (line 51) 47524* DECL_LINKONCE_P: Functions for C++. (line 50) 47525* DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38) 47526* DECL_MAIN_P: Functions for C++. (line 34) 47527* DECL_NAME: Working with declarations. 47528 (line 7) 47529* DECL_NAME <1>: Function Basics. (line 6) 47530* DECL_NAME <2>: Function Basics. (line 9) 47531* DECL_NAME <3>: Namespaces. (line 20) 47532* DECL_NAMESPACE_ALIAS: Namespaces. (line 35) 47533* DECL_NAMESPACE_STD_P: Namespaces. (line 45) 47534* DECL_NONCONVERTING_P: Functions for C++. (line 80) 47535* DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68) 47536* DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138) 47537* DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102) 47538* DECL_PURE_P: Function Properties. 47539 (line 40) 47540* DECL_RESULT: Function Basics. (line 41) 47541* DECL_SAVED_TREE: Function Basics. (line 44) 47542* DECL_SIZE: Declarations. (line 6) 47543* DECL_STATIC_FUNCTION_P: Functions for C++. (line 65) 47544* DECL_STMT: Statements for C++. (line 6) 47545* DECL_STMT_DECL: Statements for C++. (line 6) 47546* DECL_THUNK_P: Functions for C++. (line 116) 47547* DECL_VIRTUAL_P: Function Properties. 47548 (line 44) 47549* DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74) 47550* decrement_and_branch_until_zero instruction pattern: Standard Names. 47551 (line 1327) 47552* default: GTY Options. (line 88) 47553* default_file_start: File Framework. (line 8) 47554* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 17) 47555* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34) 47556* DEFAULT_SIGNED_CHAR: Type Layout. (line 123) 47557* define_address_constraint: Define Constraints. (line 99) 47558* define_asm_attributes: Tagging Insns. (line 73) 47559* define_attr: Defining Attributes. 47560 (line 6) 47561* define_automaton: Processor pipeline description. 47562 (line 53) 47563* define_bypass: Processor pipeline description. 47564 (line 196) 47565* define_code_attr: Code Iterators. (line 6) 47566* define_code_iterator: Code Iterators. (line 6) 47567* define_cond_exec: Conditional Execution. 47568 (line 13) 47569* define_constants: Constant Definitions. 47570 (line 6) 47571* define_constraint: Define Constraints. (line 45) 47572* define_cpu_unit: Processor pipeline description. 47573 (line 68) 47574* define_c_enum: Constant Definitions. 47575 (line 49) 47576* define_delay: Delay Slots. (line 25) 47577* define_enum: Constant Definitions. 47578 (line 118) 47579* define_enum_attr: Defining Attributes. 47580 (line 83) 47581* define_enum_attr <1>: Constant Definitions. 47582 (line 136) 47583* define_expand: Expander Definitions. 47584 (line 11) 47585* define_insn: Patterns. (line 6) 47586* define_insn example: Example. (line 6) 47587* define_insn_and_split: Insn Splitting. (line 170) 47588* define_insn_reservation: Processor pipeline description. 47589 (line 105) 47590* define_int_attr: Int Iterators. (line 6) 47591* define_int_iterator: Int Iterators. (line 6) 47592* define_memory_constraint: Define Constraints. (line 80) 47593* define_mode_attr: Substitutions. (line 6) 47594* define_mode_iterator: Defining Mode Iterators. 47595 (line 6) 47596* define_peephole: define_peephole. (line 6) 47597* define_peephole2: define_peephole2. (line 6) 47598* define_predicate: Defining Predicates. 47599 (line 6) 47600* define_query_cpu_unit: Processor pipeline description. 47601 (line 90) 47602* define_register_constraint: Define Constraints. (line 26) 47603* define_reservation: Processor pipeline description. 47604 (line 185) 47605* define_special_predicate: Defining Predicates. 47606 (line 6) 47607* define_split: Insn Splitting. (line 32) 47608* define_subst: Define Subst. (line 6) 47609* define_subst <1>: Define Subst Example. 47610 (line 6) 47611* define_subst <2>: Define Subst Pattern Matching. 47612 (line 6) 47613* define_subst <3>: Define Subst Output Template. 47614 (line 6) 47615* define_subst <4>: Define Subst. (line 14) 47616* define_subst <5>: Subst Iterators. (line 6) 47617* define_subst_attr: Subst Iterators. (line 6) 47618* define_subst_attr <1>: Subst Iterators. (line 26) 47619* defining attributes and their values: Defining Attributes. 47620 (line 6) 47621* defining constraints: Define Constraints. (line 6) 47622* defining jump instruction patterns: Jump Patterns. (line 6) 47623* defining looping instruction patterns: Looping Patterns. (line 6) 47624* defining peephole optimizers: Peephole Definitions. 47625 (line 6) 47626* defining predicates: Defining Predicates. 47627 (line 6) 47628* defining RTL sequences for code generation: Expander Definitions. 47629 (line 6) 47630* delay slots, defining: Delay Slots. (line 6) 47631* deletable: GTY Options. (line 132) 47632* DELETE_IF_ORDINARY: Filesystem. (line 79) 47633* Dependent Patterns: Dependent Patterns. (line 6) 47634* desc: GTY Options. (line 88) 47635* destructors, output of: Initialization. (line 6) 47636* deterministic finite state automaton: Processor pipeline description. 47637 (line 6) 47638* deterministic finite state automaton <1>: Processor pipeline description. 47639 (line 304) 47640* DFmode: Machine Modes. (line 76) 47641* digits in constraint: Simple Constraints. (line 128) 47642* DImode: Machine Modes. (line 45) 47643* directory options .md: Including Patterns. (line 47) 47644* DIR_SEPARATOR: Filesystem. (line 18) 47645* DIR_SEPARATOR_2: Filesystem. (line 19) 47646* disabling certain registers: Register Basics. (line 73) 47647* dispatch table: Dispatch Tables. (line 8) 47648* div: Arithmetic. (line 116) 47649* div and attributes: Expressions. (line 83) 47650* division: Arithmetic. (line 116) 47651* division <1>: Arithmetic. (line 130) 47652* division <2>: Arithmetic. (line 136) 47653* divM3 instruction pattern: Standard Names. (line 266) 47654* divmodM4 instruction pattern: Standard Names. (line 533) 47655* dollar sign: Multi-Alternative. (line 56) 47656* DOLLARS_IN_IDENTIFIERS: Misc. (line 452) 47657* doloop_begin instruction pattern: Standard Names. (line 1349) 47658* doloop_end instruction pattern: Standard Names. (line 1337) 47659* DONE: Expander Definitions. 47660 (line 77) 47661* DONT_USE_BUILTIN_SETJMP: Exception Region Output. 47662 (line 77) 47663* DOUBLE_TYPE_SIZE: Type Layout. (line 52) 47664* DO_BODY: Statements for C++. (line 6) 47665* DO_COND: Statements for C++. (line 6) 47666* DO_STMT: Statements for C++. (line 6) 47667* DQmode: Machine Modes. (line 118) 47668* driver: Driver. (line 6) 47669* DRIVER_SELF_SPECS: Driver. (line 8) 47670* dump examples: Dump examples. (line 6) 47671* dump setup: Dump setup. (line 6) 47672* dump types: Dump types. (line 6) 47673* dump verbosity: Dump output verbosity. 47674 (line 6) 47675* DUMPFILE_FORMAT: Filesystem. (line 67) 47676* dump_basic_block: Dump types. (line 29) 47677* dump_generic_expr: Dump types. (line 31) 47678* dump_gimple_stmt: Dump types. (line 33) 47679* dump_printf: Dump types. (line 6) 47680* DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 49) 47681* DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 12) 47682* DWARF2_FRAME_INFO: SDB and DWARF. (line 29) 47683* DWARF2_FRAME_REG_OUT: Frame Registers. (line 151) 47684* DWARF2_UNWIND_INFO: Exception Region Output. 47685 (line 38) 47686* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 152) 47687* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 47688 (line 89) 47689* DWARF_FRAME_REGISTERS: Frame Registers. (line 109) 47690* DWARF_FRAME_REGNUM: Frame Registers. (line 143) 47691* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 134) 47692* DWARF_ZERO_REG: Frame Layout. (line 163) 47693* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 90) 47694* E in constraint: Simple Constraints. (line 87) 47695* earlyclobber operand: Modifiers. (line 25) 47696* edge: Edges. (line 6) 47697* edge in the flow graph: Edges. (line 6) 47698* edge iterators: Edges. (line 15) 47699* edge splitting: Maintaining the CFG. 47700 (line 105) 47701* EDGE_ABNORMAL: Edges. (line 127) 47702* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171) 47703* EDGE_ABNORMAL, EDGE_EH: Edges. (line 95) 47704* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 121) 47705* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 85) 47706* EDOM, implicit usage: Library Calls. (line 59) 47707* EH_FRAME_IN_DATA_SECTION: Exception Region Output. 47708 (line 19) 47709* EH_FRAME_SECTION_NAME: Exception Region Output. 47710 (line 9) 47711* eh_return instruction pattern: Standard Names. (line 1530) 47712* EH_RETURN_DATA_REGNO: Exception Handling. (line 6) 47713* EH_RETURN_HANDLER_RTX: Exception Handling. (line 38) 47714* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 21) 47715* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 47716 (line 28) 47717* EH_USES: Function Entry. (line 155) 47718* ei_edge: Edges. (line 43) 47719* ei_end_p: Edges. (line 27) 47720* ei_last: Edges. (line 23) 47721* ei_next: Edges. (line 35) 47722* ei_one_before_end_p: Edges. (line 31) 47723* ei_prev: Edges. (line 39) 47724* ei_safe_safe: Edges. (line 47) 47725* ei_start: Edges. (line 19) 47726* ELIMINABLE_REGS: Elimination. (line 46) 47727* ELSE_CLAUSE: Statements for C++. (line 6) 47728* Embedded C: Fixed-point fractional library routines. 47729 (line 6) 47730* Empty Statements: Empty Statements. (line 6) 47731* EMPTY_CLASS_EXPR: Statements for C++. (line 6) 47732* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 311) 47733* Emulated TLS: Emulated TLS. (line 6) 47734* enabled: Disable Insn Alternatives. 47735 (line 6) 47736* ENDFILE_SPEC: Driver. (line 155) 47737* endianness: Portability. (line 20) 47738* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 10) 47739* enum reg_class: Register Classes. (line 70) 47740* ENUMERAL_TYPE: Types. (line 6) 47741* enumerations: Constant Definitions. 47742 (line 49) 47743* epilogue: Function Entry. (line 6) 47744* epilogue instruction pattern: Standard Names. (line 1568) 47745* EPILOGUE_USES: Function Entry. (line 149) 47746* eq: Comparisons. (line 52) 47747* eq and attributes: Expressions. (line 83) 47748* equal: Comparisons. (line 52) 47749* eq_attr: Expressions. (line 104) 47750* EQ_EXPR: Unary and Binary Expressions. 47751 (line 6) 47752* errno, implicit usage: Library Calls. (line 71) 47753* EXACT_DIV_EXPR: Unary and Binary Expressions. 47754 (line 6) 47755* examining SSA_NAMEs: SSA. (line 214) 47756* exception handling: Edges. (line 95) 47757* exception handling <1>: Exception Handling. (line 6) 47758* exception_receiver instruction pattern: Standard Names. (line 1495) 47759* exclamation point: Multi-Alternative. (line 47) 47760* exclusion_set: Processor pipeline description. 47761 (line 223) 47762* exclusive-or, bitwise: Arithmetic. (line 168) 47763* EXIT_EXPR: Unary and Binary Expressions. 47764 (line 6) 47765* EXIT_IGNORE_STACK: Function Entry. (line 137) 47766* expander definitions: Expander Definitions. 47767 (line 6) 47768* expM2 instruction pattern: Standard Names. (line 640) 47769* expression: Expression trees. (line 6) 47770* expression codes: RTL Objects. (line 47) 47771* EXPR_FILENAME: Working with declarations. 47772 (line 14) 47773* EXPR_LINENO: Working with declarations. 47774 (line 20) 47775* expr_list: Insns. (line 540) 47776* EXPR_STMT: Statements for C++. (line 6) 47777* EXPR_STMT_EXPR: Statements for C++. (line 6) 47778* extendMN2 instruction pattern: Standard Names. (line 970) 47779* extensible constraints: Simple Constraints. (line 171) 47780* EXTRA_SPECS: Driver. (line 182) 47781* extv instruction pattern: Standard Names. (line 1061) 47782* extvM instruction pattern: Standard Names. (line 1006) 47783* extvmisalignM instruction pattern: Standard Names. (line 1016) 47784* extzv instruction pattern: Standard Names. (line 1079) 47785* extzvM instruction pattern: Standard Names. (line 1030) 47786* extzvmisalignM instruction pattern: Standard Names. (line 1033) 47787* F in constraint: Simple Constraints. (line 92) 47788* FAIL: Expander Definitions. 47789 (line 83) 47790* fall-thru: Edges. (line 68) 47791* FATAL_EXIT_CODE: Host Misc. (line 6) 47792* FDL, GNU Free Documentation License: GNU Free Documentation License. 47793 (line 6) 47794* features, optional, in system conventions: Run-time Target. 47795 (line 59) 47796* ffs: Arithmetic. (line 210) 47797* ffsM2 instruction pattern: Standard Names. (line 754) 47798* FIELD_DECL: Declarations. (line 6) 47799* files and passes of the compiler: Passes. (line 6) 47800* files, generated: Files. (line 6) 47801* file_end_indicate_exec_stack: File Framework. (line 39) 47802* final_absence_set: Processor pipeline description. 47803 (line 223) 47804* FINAL_PRESCAN_INSN: Instruction Output. (line 60) 47805* final_presence_set: Processor pipeline description. 47806 (line 223) 47807* final_sequence: Instruction Output. (line 144) 47808* FIND_BASE_TERM: Addressing Modes. (line 117) 47809* finite state automaton minimization: Processor pipeline description. 47810 (line 304) 47811* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 113) 47812* FINI_SECTION_ASM_OP: Sections. (line 98) 47813* FIRST_PARM_OFFSET: Frame Layout. (line 65) 47814* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 47815* FIRST_PSEUDO_REGISTER: Register Basics. (line 8) 47816* FIRST_STACK_REG: Stack Registers. (line 26) 47817* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 47818* fix: Conversions. (line 66) 47819* fixed register: Register Basics. (line 15) 47820* fixed-point fractional library: Fixed-point fractional library routines. 47821 (line 6) 47822* FIXED_CONVERT_EXPR: Unary and Binary Expressions. 47823 (line 6) 47824* FIXED_CST: Constant expressions. 47825 (line 6) 47826* FIXED_POINT_TYPE: Types. (line 6) 47827* FIXED_REGISTERS: Register Basics. (line 14) 47828* fixed_regs: Register Basics. (line 59) 47829* fixMN2 instruction pattern: Standard Names. (line 937) 47830* fixunsMN2 instruction pattern: Standard Names. (line 946) 47831* fixuns_truncMN2 instruction pattern: Standard Names. (line 961) 47832* fix_truncMN2 instruction pattern: Standard Names. (line 957) 47833* FIX_TRUNC_EXPR: Unary and Binary Expressions. 47834 (line 6) 47835* flags in RTL expression: Flags. (line 6) 47836* float: Conversions. (line 58) 47837* floating point and cross compilation: Floating Point. (line 6) 47838* floatMN2 instruction pattern: Standard Names. (line 929) 47839* floatunsMN2 instruction pattern: Standard Names. (line 933) 47840* FLOAT_EXPR: Unary and Binary Expressions. 47841 (line 6) 47842* float_extend: Conversions. (line 33) 47843* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 32) 47844* FLOAT_STORE_FLAG_VALUE: Misc. (line 286) 47845* float_truncate: Conversions. (line 53) 47846* FLOAT_TYPE_SIZE: Type Layout. (line 48) 47847* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 41) 47848* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 47849 (line 224) 47850* floorM2 instruction pattern: Standard Names. (line 675) 47851* FLOOR_DIV_EXPR: Unary and Binary Expressions. 47852 (line 6) 47853* FLOOR_MOD_EXPR: Unary and Binary Expressions. 47854 (line 6) 47855* flow-insensitive alias analysis: Alias analysis. (line 6) 47856* flow-sensitive alias analysis: Alias analysis. (line 6) 47857* fma: Arithmetic. (line 112) 47858* fmaM4 instruction pattern: Standard Names. (line 300) 47859* fmodM3 instruction pattern: Standard Names. (line 593) 47860* fmsM4 instruction pattern: Standard Names. (line 307) 47861* fnmaM4 instruction pattern: Standard Names. (line 313) 47862* fnmsM4 instruction pattern: Standard Names. (line 319) 47863* FORCE_CODE_SECTION_ALIGN: Sections. (line 144) 47864* force_reg: Standard Names. (line 36) 47865* FOR_BODY: Statements for C++. (line 6) 47866* FOR_COND: Statements for C++. (line 6) 47867* FOR_EXPR: Statements for C++. (line 6) 47868* FOR_INIT_STMT: Statements for C++. (line 6) 47869* FOR_STMT: Statements for C++. (line 6) 47870* for_user: GTY Options. (line 82) 47871* fractional types: Fixed-point fractional library routines. 47872 (line 6) 47873* fractMN2 instruction pattern: Standard Names. (line 979) 47874* fractunsMN2 instruction pattern: Standard Names. (line 994) 47875* fract_convert: Conversions. (line 82) 47876* FRACT_TYPE_SIZE: Type Layout. (line 67) 47877* frame layout: Frame Layout. (line 6) 47878* FRAME_ADDR_RTX: Frame Layout. (line 114) 47879* FRAME_GROWS_DOWNWARD: Frame Layout. (line 30) 47880* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 47881 (line 69) 47882* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 212) 47883* frame_pointer_needed: Function Entry. (line 34) 47884* FRAME_POINTER_REGNUM: Frame Registers. (line 13) 47885* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 47886 (line 74) 47887* frame_pointer_rtx: Frame Registers. (line 104) 47888* frame_related: Flags. (line 229) 47889* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 47890 (line 107) 47891* frame_related, in mem: Flags. (line 85) 47892* frame_related, in reg: Flags. (line 94) 47893* frame_related, in symbol_ref: Flags. (line 165) 47894* frequency, count, BB_FREQ_BASE: Profile information. 47895 (line 30) 47896* ftruncM2 instruction pattern: Standard Names. (line 952) 47897* function: Functions. (line 6) 47898* function <1>: Functions for C++. (line 6) 47899* function call conventions: Interface. (line 6) 47900* function entry and exit: Function Entry. (line 6) 47901* function entry point, alternate function entry point: Edges. 47902 (line 180) 47903* function properties: Function Properties. 47904 (line 6) 47905* function-call insns: Calls. (line 6) 47906* functions, leaf: Leaf Functions. (line 6) 47907* FUNCTION_ARG_OFFSET: Register Arguments. (line 210) 47908* FUNCTION_ARG_PADDING: Register Arguments. (line 217) 47909* FUNCTION_ARG_REGNO_P: Register Arguments. (line 265) 47910* FUNCTION_BOUNDARY: Storage Layout. (line 159) 47911* FUNCTION_DECL: Functions. (line 6) 47912* FUNCTION_DECL <1>: Functions for C++. (line 6) 47913* FUNCTION_MODE: Misc. (line 341) 47914* FUNCTION_PROFILER: Profiling. (line 8) 47915* FUNCTION_TYPE: Types. (line 6) 47916* FUNCTION_VALUE: Scalar Return. (line 52) 47917* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 78) 47918* fundamental type: Types. (line 6) 47919* G in constraint: Simple Constraints. (line 96) 47920* g in constraint: Simple Constraints. (line 118) 47921* garbage collector, invocation: Invoking the garbage collector. 47922 (line 6) 47923* garbage collector, troubleshooting: Troubleshooting. (line 6) 47924* GCC and portability: Portability. (line 6) 47925* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 47926* gcov_type: Profile information. 47927 (line 41) 47928* ge: Comparisons. (line 72) 47929* ge and attributes: Expressions. (line 83) 47930* gencodes: RTL passes. (line 18) 47931* general_operand: Machine-Independent Predicates. 47932 (line 104) 47933* GENERAL_REGS: Register Classes. (line 22) 47934* generated files: Files. (line 6) 47935* generating assembler output: Output Statement. (line 6) 47936* generating insns: RTL Template. (line 6) 47937* GENERIC: Parsing pass. (line 6) 47938* GENERIC <1>: GENERIC. (line 6) 47939* generic predicates: Machine-Independent Predicates. 47940 (line 6) 47941* genflags: RTL passes. (line 18) 47942* GEN_ERRNO_RTX: Library Calls. (line 71) 47943* get_attr: Expressions. (line 99) 47944* get_attr_length: Insn Lengths. (line 52) 47945* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 344) 47946* GET_CODE: RTL Objects. (line 47) 47947* get_frame_size: Elimination. (line 34) 47948* get_insns: Insns. (line 34) 47949* get_last_insn: Insns. (line 34) 47950* GET_MODE: Machine Modes. (line 291) 47951* GET_MODE_ALIGNMENT: Machine Modes. (line 331) 47952* GET_MODE_BITSIZE: Machine Modes. (line 315) 47953* GET_MODE_CLASS: Machine Modes. (line 305) 47954* GET_MODE_FBIT: Machine Modes. (line 322) 47955* GET_MODE_IBIT: Machine Modes. (line 318) 47956* GET_MODE_MASK: Machine Modes. (line 326) 47957* GET_MODE_NAME: Machine Modes. (line 302) 47958* GET_MODE_NUNITS: Machine Modes. (line 340) 47959* GET_MODE_SIZE: Machine Modes. (line 312) 47960* GET_MODE_UNIT_SIZE: Machine Modes. (line 334) 47961* GET_MODE_WIDER_MODE: Machine Modes. (line 308) 47962* GET_RTX_CLASS: RTL Classes. (line 6) 47963* GET_RTX_FORMAT: RTL Classes. (line 131) 47964* GET_RTX_LENGTH: RTL Classes. (line 128) 47965* get_thread_pointerMODE instruction pattern: Standard Names. 47966 (line 1905) 47967* geu: Comparisons. (line 72) 47968* geu and attributes: Expressions. (line 83) 47969* GE_EXPR: Unary and Binary Expressions. 47970 (line 6) 47971* GGC: Type Information. (line 6) 47972* ggc_collect: Invoking the garbage collector. 47973 (line 6) 47974* GIMPLE: Parsing pass. (line 13) 47975* GIMPLE <1>: Gimplification pass. 47976 (line 6) 47977* GIMPLE <2>: GIMPLE. (line 6) 47978* GIMPLE API: GIMPLE API. (line 6) 47979* GIMPLE class hierarchy: Class hierarchy of GIMPLE statements. 47980 (line 6) 47981* GIMPLE Exception Handling: GIMPLE Exception Handling. 47982 (line 6) 47983* GIMPLE instruction set: GIMPLE instruction set. 47984 (line 6) 47985* GIMPLE sequences: GIMPLE sequences. (line 6) 47986* GIMPLE statement iterators: Basic Blocks. (line 78) 47987* GIMPLE statement iterators <1>: Maintaining the CFG. 47988 (line 33) 47989* gimple_addresses_taken: Manipulating GIMPLE statements. 47990 (line 89) 47991* GIMPLE_ASM: GIMPLE_ASM. (line 6) 47992* gimple_asm_clobber_op: GIMPLE_ASM. (line 39) 47993* gimple_asm_input_op: GIMPLE_ASM. (line 23) 47994* gimple_asm_nclobbers: GIMPLE_ASM. (line 20) 47995* gimple_asm_ninputs: GIMPLE_ASM. (line 14) 47996* gimple_asm_noutputs: GIMPLE_ASM. (line 17) 47997* gimple_asm_output_op: GIMPLE_ASM. (line 31) 47998* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 43) 47999* gimple_asm_set_input_op: GIMPLE_ASM. (line 27) 48000* gimple_asm_set_output_op: GIMPLE_ASM. (line 35) 48001* gimple_asm_set_volatile: GIMPLE_ASM. (line 54) 48002* gimple_asm_string: GIMPLE_ASM. (line 47) 48003* gimple_asm_volatile_p: GIMPLE_ASM. (line 51) 48004* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6) 48005* gimple_assign_cast_p: Logical Operators. (line 158) 48006* gimple_assign_cast_p <1>: GIMPLE_ASSIGN. (line 104) 48007* gimple_assign_lhs: GIMPLE_ASSIGN. (line 62) 48008* gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 65) 48009* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 68) 48010* gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 71) 48011* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 75) 48012* gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 78) 48013* gimple_assign_rhs3: GIMPLE_ASSIGN. (line 82) 48014* gimple_assign_rhs3_ptr: GIMPLE_ASSIGN. (line 85) 48015* gimple_assign_rhs_class: GIMPLE_ASSIGN. (line 56) 48016* gimple_assign_rhs_code: GIMPLE_ASSIGN. (line 52) 48017* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 89) 48018* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 92) 48019* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 96) 48020* gimple_assign_set_rhs3: GIMPLE_ASSIGN. (line 100) 48021* gimple_bb: Manipulating GIMPLE statements. 48022 (line 17) 48023* GIMPLE_BIND: GIMPLE_BIND. (line 6) 48024* gimple_bind_add_seq: GIMPLE_BIND. (line 34) 48025* gimple_bind_add_stmt: GIMPLE_BIND. (line 31) 48026* gimple_bind_append_vars: GIMPLE_BIND. (line 18) 48027* gimple_bind_block: GIMPLE_BIND. (line 39) 48028* gimple_bind_body: GIMPLE_BIND. (line 22) 48029* gimple_bind_set_block: GIMPLE_BIND. (line 44) 48030* gimple_bind_set_body: GIMPLE_BIND. (line 26) 48031* gimple_bind_set_vars: GIMPLE_BIND. (line 14) 48032* gimple_bind_vars: GIMPLE_BIND. (line 11) 48033* gimple_block: Manipulating GIMPLE statements. 48034 (line 20) 48035* gimple_build: GIMPLE API. (line 34) 48036* gimple_build <1>: GIMPLE API. (line 36) 48037* gimple_build <2>: GIMPLE API. (line 38) 48038* gimple_build <3>: GIMPLE API. (line 41) 48039* gimple_build <4>: GIMPLE API. (line 44) 48040* gimple_build_nop: GIMPLE_NOP. (line 6) 48041* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 6) 48042* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 6) 48043* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 6) 48044* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 6) 48045* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS. 48046 (line 13) 48047* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR. 48048 (line 6) 48049* GIMPLE_CALL: GIMPLE_CALL. (line 6) 48050* gimple_call_arg: GIMPLE_CALL. (line 65) 48051* gimple_call_arg_ptr: GIMPLE_CALL. (line 69) 48052* gimple_call_chain: GIMPLE_CALL. (line 56) 48053* gimple_call_copy_skip_args: GIMPLE_CALL. (line 90) 48054* gimple_call_fn: GIMPLE_CALL. (line 37) 48055* gimple_call_fndecl: GIMPLE_CALL. (line 45) 48056* gimple_call_lhs: GIMPLE_CALL. (line 28) 48057* gimple_call_lhs_ptr: GIMPLE_CALL. (line 31) 48058* gimple_call_noreturn_p: GIMPLE_CALL. (line 87) 48059* gimple_call_num_args: GIMPLE_CALL. (line 62) 48060* gimple_call_return_type: GIMPLE_CALL. (line 53) 48061* gimple_call_set_arg: GIMPLE_CALL. (line 74) 48062* gimple_call_set_chain: GIMPLE_CALL. (line 59) 48063* gimple_call_set_fn: GIMPLE_CALL. (line 41) 48064* gimple_call_set_fndecl: GIMPLE_CALL. (line 50) 48065* gimple_call_set_lhs: GIMPLE_CALL. (line 34) 48066* gimple_call_set_tail: GIMPLE_CALL. (line 79) 48067* gimple_call_tail_p: GIMPLE_CALL. (line 84) 48068* GIMPLE_CATCH: GIMPLE_CATCH. (line 6) 48069* gimple_catch_handler: GIMPLE_CATCH. (line 19) 48070* gimple_catch_set_handler: GIMPLE_CATCH. (line 26) 48071* gimple_catch_set_types: GIMPLE_CATCH. (line 23) 48072* gimple_catch_types: GIMPLE_CATCH. (line 12) 48073* gimple_catch_types_ptr: GIMPLE_CATCH. (line 15) 48074* gimple_code: Manipulating GIMPLE statements. 48075 (line 14) 48076* GIMPLE_COND: GIMPLE_COND. (line 6) 48077* gimple_cond_code: GIMPLE_COND. (line 20) 48078* gimple_cond_false_label: GIMPLE_COND. (line 59) 48079* gimple_cond_lhs: GIMPLE_COND. (line 29) 48080* gimple_cond_make_false: GIMPLE_COND. (line 63) 48081* gimple_cond_make_true: GIMPLE_COND. (line 66) 48082* gimple_cond_rhs: GIMPLE_COND. (line 37) 48083* gimple_cond_set_code: GIMPLE_COND. (line 24) 48084* gimple_cond_set_false_label: GIMPLE_COND. (line 54) 48085* gimple_cond_set_lhs: GIMPLE_COND. (line 33) 48086* gimple_cond_set_rhs: GIMPLE_COND. (line 41) 48087* gimple_cond_set_true_label: GIMPLE_COND. (line 49) 48088* gimple_cond_true_label: GIMPLE_COND. (line 45) 48089* gimple_convert: GIMPLE API. (line 47) 48090* gimple_copy: Manipulating GIMPLE statements. 48091 (line 146) 48092* GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6) 48093* GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6) 48094* gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 46) 48095* gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 50) 48096* gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 43) 48097* gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 68) 48098* gimple_debug_bind_p: Logical Operators. (line 162) 48099* gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 64) 48100* gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 59) 48101* gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 55) 48102* gimple_def_ops: Manipulating GIMPLE statements. 48103 (line 93) 48104* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6) 48105* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 18) 48106* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 27) 48107* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 22) 48108* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 11) 48109* gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 14) 48110* gimple_eh_must_not_throw_fndecl: GIMPLE_EH_FILTER. (line 32) 48111* gimple_eh_must_not_throw_set_fndecl: GIMPLE_EH_FILTER. (line 36) 48112* gimple_expr_code: Manipulating GIMPLE statements. 48113 (line 30) 48114* gimple_expr_type: Manipulating GIMPLE statements. 48115 (line 23) 48116* GIMPLE_GOTO: GIMPLE_GOTO. (line 6) 48117* gimple_goto_dest: GIMPLE_GOTO. (line 9) 48118* gimple_goto_set_dest: GIMPLE_GOTO. (line 12) 48119* gimple_has_mem_ops: Manipulating GIMPLE statements. 48120 (line 71) 48121* gimple_has_ops: Manipulating GIMPLE statements. 48122 (line 68) 48123* gimple_has_volatile_ops: Manipulating GIMPLE statements. 48124 (line 133) 48125* GIMPLE_LABEL: GIMPLE_LABEL. (line 6) 48126* gimple_label_label: GIMPLE_LABEL. (line 10) 48127* gimple_label_set_label: GIMPLE_LABEL. (line 13) 48128* gimple_loaded_syms: Manipulating GIMPLE statements. 48129 (line 121) 48130* gimple_locus: Manipulating GIMPLE statements. 48131 (line 41) 48132* gimple_locus_empty_p: Manipulating GIMPLE statements. 48133 (line 47) 48134* gimple_modified_p: Manipulating GIMPLE statements. 48135 (line 129) 48136* GIMPLE_NOP: GIMPLE_NOP. (line 6) 48137* gimple_nop_p: GIMPLE_NOP. (line 9) 48138* gimple_no_warning_p: Manipulating GIMPLE statements. 48139 (line 50) 48140* gimple_num_ops: Logical Operators. (line 76) 48141* gimple_num_ops <1>: Manipulating GIMPLE statements. 48142 (line 74) 48143* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD. 48144 (line 6) 48145* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD. 48146 (line 16) 48147* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD. 48148 (line 24) 48149* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD. 48150 (line 12) 48151* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD. 48152 (line 20) 48153* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE. 48154 (line 6) 48155* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE. 48156 (line 11) 48157* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE. 48158 (line 15) 48159* gimple_omp_body: GIMPLE_OMP_PARALLEL. 48160 (line 23) 48161* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE. 48162 (line 6) 48163* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE. 48164 (line 12) 48165* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE. 48166 (line 17) 48167* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE. 48168 (line 26) 48169* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE. 48170 (line 31) 48171* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE. 48172 (line 21) 48173* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE. 48174 (line 35) 48175* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL. 48176 (line 6) 48177* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL. 48178 (line 12) 48179* gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL. 48180 (line 16) 48181* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL. 48182 (line 21) 48183* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6) 48184* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 17) 48185* gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 20) 48186* gimple_omp_for_cond: GIMPLE_OMP_FOR. (line 80) 48187* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 48) 48188* gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 51) 48189* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 58) 48190* gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 61) 48191* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 28) 48192* gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 31) 48193* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 38) 48194* gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 41) 48195* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 67) 48196* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 23) 48197* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 76) 48198* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 54) 48199* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 64) 48200* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 34) 48201* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 44) 48202* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 71) 48203* GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6) 48204* GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6) 48205* GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL. 48206 (line 6) 48207* gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL. 48208 (line 42) 48209* gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL. 48210 (line 47) 48211* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL. 48212 (line 30) 48213* gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL. 48214 (line 33) 48215* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL. 48216 (line 15) 48217* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL. 48218 (line 56) 48219* gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL. 48220 (line 61) 48221* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL. 48222 (line 52) 48223* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL. 48224 (line 37) 48225* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL. 48226 (line 19) 48227* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL. 48228 (line 65) 48229* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6) 48230* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 13) 48231* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 10) 48232* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6) 48233* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS. 48234 (line 6) 48235* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS. 48236 (line 29) 48237* gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS. 48238 (line 32) 48239* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS. 48240 (line 16) 48241* gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS. 48242 (line 20) 48243* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS. 48244 (line 35) 48245* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS. 48246 (line 24) 48247* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 11) 48248* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 15) 48249* gimple_omp_set_body: GIMPLE_OMP_PARALLEL. 48250 (line 26) 48251* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6) 48252* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 13) 48253* gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 16) 48254* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 19) 48255* gimple_op: Logical Operators. (line 79) 48256* gimple_op <1>: Manipulating GIMPLE statements. 48257 (line 80) 48258* gimple_ops: Logical Operators. (line 82) 48259* gimple_ops <1>: Manipulating GIMPLE statements. 48260 (line 77) 48261* gimple_op_ptr: Manipulating GIMPLE statements. 48262 (line 83) 48263* GIMPLE_PHI: GIMPLE_PHI. (line 6) 48264* gimple_phi_arg: GIMPLE_PHI. (line 24) 48265* gimple_phi_arg <1>: SSA. (line 62) 48266* gimple_phi_arg_def: SSA. (line 68) 48267* gimple_phi_arg_edge: SSA. (line 65) 48268* gimple_phi_capacity: GIMPLE_PHI. (line 6) 48269* gimple_phi_num_args: GIMPLE_PHI. (line 10) 48270* gimple_phi_num_args <1>: SSA. (line 58) 48271* gimple_phi_result: GIMPLE_PHI. (line 15) 48272* gimple_phi_result <1>: SSA. (line 55) 48273* gimple_phi_result_ptr: GIMPLE_PHI. (line 18) 48274* gimple_phi_set_arg: GIMPLE_PHI. (line 28) 48275* gimple_phi_set_result: GIMPLE_PHI. (line 21) 48276* gimple_plf: Manipulating GIMPLE statements. 48277 (line 64) 48278* GIMPLE_RESX: GIMPLE_RESX. (line 6) 48279* gimple_resx_region: GIMPLE_RESX. (line 12) 48280* gimple_resx_set_region: GIMPLE_RESX. (line 15) 48281* GIMPLE_RETURN: GIMPLE_RETURN. (line 6) 48282* gimple_return_retval: GIMPLE_RETURN. (line 9) 48283* gimple_return_set_retval: GIMPLE_RETURN. (line 12) 48284* gimple_seq_add_seq: GIMPLE sequences. (line 30) 48285* gimple_seq_add_stmt: GIMPLE sequences. (line 24) 48286* gimple_seq_alloc: GIMPLE sequences. (line 61) 48287* gimple_seq_copy: GIMPLE sequences. (line 65) 48288* gimple_seq_deep_copy: GIMPLE sequences. (line 36) 48289* gimple_seq_empty_p: GIMPLE sequences. (line 69) 48290* gimple_seq_first: GIMPLE sequences. (line 43) 48291* gimple_seq_init: GIMPLE sequences. (line 58) 48292* gimple_seq_last: GIMPLE sequences. (line 46) 48293* gimple_seq_reverse: GIMPLE sequences. (line 39) 48294* gimple_seq_set_first: GIMPLE sequences. (line 53) 48295* gimple_seq_set_last: GIMPLE sequences. (line 49) 48296* gimple_seq_singleton_p: GIMPLE sequences. (line 78) 48297* gimple_set_block: Manipulating GIMPLE statements. 48298 (line 38) 48299* gimple_set_def_ops: Manipulating GIMPLE statements. 48300 (line 96) 48301* gimple_set_has_volatile_ops: Manipulating GIMPLE statements. 48302 (line 136) 48303* gimple_set_locus: Manipulating GIMPLE statements. 48304 (line 44) 48305* gimple_set_op: Manipulating GIMPLE statements. 48306 (line 86) 48307* gimple_set_plf: Manipulating GIMPLE statements. 48308 (line 60) 48309* gimple_set_use_ops: Manipulating GIMPLE statements. 48310 (line 103) 48311* gimple_set_vdef_ops: Manipulating GIMPLE statements. 48312 (line 117) 48313* gimple_set_visited: Manipulating GIMPLE statements. 48314 (line 53) 48315* gimple_set_vuse_ops: Manipulating GIMPLE statements. 48316 (line 110) 48317* gimple_simplify: GIMPLE API. (line 6) 48318* gimple_simplify <1>: GIMPLE API. (line 8) 48319* gimple_simplify <2>: GIMPLE API. (line 10) 48320* gimple_simplify <3>: GIMPLE API. (line 12) 48321* gimple_simplify <4>: GIMPLE API. (line 14) 48322* gimple_simplify <5>: GIMPLE API. (line 16) 48323* gimple_statement_base: Tuple representation. 48324 (line 14) 48325* gimple_statement_with_ops: Tuple representation. 48326 (line 96) 48327* gimple_stored_syms: Manipulating GIMPLE statements. 48328 (line 125) 48329* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6) 48330* gimple_switch_default_label: GIMPLE_SWITCH. (line 41) 48331* gimple_switch_index: GIMPLE_SWITCH. (line 24) 48332* gimple_switch_label: GIMPLE_SWITCH. (line 31) 48333* gimple_switch_num_labels: GIMPLE_SWITCH. (line 14) 48334* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 45) 48335* gimple_switch_set_index: GIMPLE_SWITCH. (line 27) 48336* gimple_switch_set_label: GIMPLE_SWITCH. (line 36) 48337* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 19) 48338* GIMPLE_TRY: GIMPLE_TRY. (line 6) 48339* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 19) 48340* gimple_try_cleanup: GIMPLE_TRY. (line 26) 48341* gimple_try_eval: GIMPLE_TRY. (line 22) 48342* gimple_try_kind: GIMPLE_TRY. (line 15) 48343* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 30) 48344* gimple_try_set_cleanup: GIMPLE_TRY. (line 38) 48345* gimple_try_set_eval: GIMPLE_TRY. (line 34) 48346* gimple_use_ops: Manipulating GIMPLE statements. 48347 (line 100) 48348* gimple_vdef_ops: Manipulating GIMPLE statements. 48349 (line 114) 48350* gimple_visited_p: Manipulating GIMPLE statements. 48351 (line 57) 48352* gimple_vuse_ops: Manipulating GIMPLE statements. 48353 (line 107) 48354* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 48355 (line 10) 48356* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 48357 (line 17) 48358* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 48359 (line 13) 48360* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 48361 (line 20) 48362* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR. 48363 (line 6) 48364* gimplification: Parsing pass. (line 13) 48365* gimplification <1>: Gimplification pass. 48366 (line 6) 48367* gimplifier: Parsing pass. (line 13) 48368* gimplify_assign: GIMPLE_ASSIGN. (line 41) 48369* gimplify_expr: Gimplification pass. 48370 (line 18) 48371* gimplify_function_tree: Gimplification pass. 48372 (line 18) 48373* GLOBAL_INIT_PRIORITY: Functions for C++. (line 141) 48374* global_regs: Register Basics. (line 59) 48375* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 90) 48376* greater than: Comparisons. (line 60) 48377* greater than <1>: Comparisons. (line 64) 48378* greater than <2>: Comparisons. (line 72) 48379* gsi_after_labels: Sequence iterators. (line 74) 48380* gsi_bb: Sequence iterators. (line 82) 48381* gsi_commit_edge_inserts: Sequence iterators. (line 193) 48382* gsi_commit_edge_inserts <1>: Maintaining the CFG. 48383 (line 105) 48384* gsi_commit_one_edge_insert: Sequence iterators. (line 188) 48385* gsi_end_p: Sequence iterators. (line 59) 48386* gsi_end_p <1>: Maintaining the CFG. 48387 (line 48) 48388* gsi_for_stmt: Sequence iterators. (line 156) 48389* gsi_insert_after: Sequence iterators. (line 145) 48390* gsi_insert_after <1>: Maintaining the CFG. 48391 (line 60) 48392* gsi_insert_before: Sequence iterators. (line 134) 48393* gsi_insert_before <1>: Maintaining the CFG. 48394 (line 66) 48395* gsi_insert_on_edge: Sequence iterators. (line 173) 48396* gsi_insert_on_edge <1>: Maintaining the CFG. 48397 (line 105) 48398* gsi_insert_on_edge_immediate: Sequence iterators. (line 183) 48399* gsi_insert_seq_after: Sequence iterators. (line 152) 48400* gsi_insert_seq_before: Sequence iterators. (line 141) 48401* gsi_insert_seq_on_edge: Sequence iterators. (line 177) 48402* gsi_last: Sequence iterators. (line 49) 48403* gsi_last <1>: Maintaining the CFG. 48404 (line 44) 48405* gsi_last_bb: Sequence iterators. (line 55) 48406* gsi_link_after: Sequence iterators. (line 113) 48407* gsi_link_before: Sequence iterators. (line 103) 48408* gsi_link_seq_after: Sequence iterators. (line 108) 48409* gsi_link_seq_before: Sequence iterators. (line 97) 48410* gsi_move_after: Sequence iterators. (line 159) 48411* gsi_move_before: Sequence iterators. (line 164) 48412* gsi_move_to_bb_end: Sequence iterators. (line 169) 48413* gsi_next: Sequence iterators. (line 65) 48414* gsi_next <1>: Maintaining the CFG. 48415 (line 52) 48416* gsi_one_before_end_p: Sequence iterators. (line 62) 48417* gsi_prev: Sequence iterators. (line 68) 48418* gsi_prev <1>: Maintaining the CFG. 48419 (line 56) 48420* gsi_remove: Sequence iterators. (line 88) 48421* gsi_remove <1>: Maintaining the CFG. 48422 (line 72) 48423* gsi_replace: Sequence iterators. (line 128) 48424* gsi_seq: Sequence iterators. (line 85) 48425* gsi_split_seq_after: Sequence iterators. (line 118) 48426* gsi_split_seq_before: Sequence iterators. (line 123) 48427* gsi_start: Sequence iterators. (line 39) 48428* gsi_start <1>: Maintaining the CFG. 48429 (line 40) 48430* gsi_start_bb: Sequence iterators. (line 45) 48431* gsi_stmt: Sequence iterators. (line 71) 48432* gsi_stmt_ptr: Sequence iterators. (line 79) 48433* gt: Comparisons. (line 60) 48434* gt and attributes: Expressions. (line 83) 48435* gtu: Comparisons. (line 64) 48436* gtu and attributes: Expressions. (line 83) 48437* GTY: Type Information. (line 6) 48438* GT_EXPR: Unary and Binary Expressions. 48439 (line 6) 48440* H in constraint: Simple Constraints. (line 96) 48441* HAmode: Machine Modes. (line 146) 48442* HANDLER: Statements for C++. (line 6) 48443* HANDLER_BODY: Statements for C++. (line 6) 48444* HANDLER_PARMS: Statements for C++. (line 6) 48445* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 442) 48446* hard registers: Regs and Memory. (line 9) 48447* HARD_FRAME_POINTER_IS_ARG_POINTER: Frame Registers. (line 57) 48448* HARD_FRAME_POINTER_IS_FRAME_POINTER: Frame Registers. (line 50) 48449* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 19) 48450* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 10) 48451* HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 52) 48452* HARD_REGNO_MODE_OK: Values in Registers. 48453 (line 57) 48454* HARD_REGNO_NREGS: Values in Registers. 48455 (line 10) 48456* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 48457 (line 24) 48458* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 48459 (line 42) 48460* HARD_REGNO_RENAME_OK: Values in Registers. 48461 (line 117) 48462* HAS_INIT_SECTION: Macros for Initialization. 48463 (line 18) 48464* HAS_LONG_COND_BRANCH: Misc. (line 8) 48465* HAS_LONG_UNCOND_BRANCH: Misc. (line 17) 48466* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 48467* HAVE_POST_DECREMENT: Addressing Modes. (line 11) 48468* HAVE_POST_INCREMENT: Addressing Modes. (line 10) 48469* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 17) 48470* HAVE_POST_MODIFY_REG: Addressing Modes. (line 23) 48471* HAVE_PRE_DECREMENT: Addressing Modes. (line 9) 48472* HAVE_PRE_INCREMENT: Addressing Modes. (line 8) 48473* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 16) 48474* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 22) 48475* HCmode: Machine Modes. (line 199) 48476* HFmode: Machine Modes. (line 61) 48477* high: Constants. (line 150) 48478* HImode: Machine Modes. (line 29) 48479* HImode, in insn: Insns. (line 268) 48480* HONOR_REG_ALLOC_ORDER: Allocation Order. (line 36) 48481* host configuration: Host Config. (line 6) 48482* host functions: Host Common. (line 6) 48483* host hooks: Host Common. (line 6) 48484* host makefile fragment: Host Fragment. (line 6) 48485* HOST_BIT_BUCKET: Filesystem. (line 51) 48486* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 48487* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 11) 48488* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 43) 48489* HOST_HOOKS_GT_PCH_GET_ADDRESS: Host Common. (line 15) 48490* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 24) 48491* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 48492* HOST_LONG_FORMAT: Host Misc. (line 45) 48493* HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 48494* HOST_OBJECT_SUFFIX: Filesystem. (line 40) 48495* HOST_PTR_PRINTF: Host Misc. (line 49) 48496* HOT_TEXT_SECTION_NAME: Sections. (line 42) 48497* HQmode: Machine Modes. (line 110) 48498* i in constraint: Simple Constraints. (line 68) 48499* I in constraint: Simple Constraints. (line 79) 48500* identifier: Identifiers. (line 6) 48501* IDENTIFIER_LENGTH: Identifiers. (line 22) 48502* IDENTIFIER_NODE: Identifiers. (line 6) 48503* IDENTIFIER_OPNAME_P: Identifiers. (line 27) 48504* IDENTIFIER_POINTER: Identifiers. (line 17) 48505* IDENTIFIER_TYPENAME_P: Identifiers. (line 33) 48506* IEEE 754-2008: Decimal float library routines. 48507 (line 6) 48508* IFCVT_MACHDEP_INIT: Misc. (line 567) 48509* IFCVT_MODIFY_CANCEL: Misc. (line 561) 48510* IFCVT_MODIFY_FINAL: Misc. (line 555) 48511* IFCVT_MODIFY_INSN: Misc. (line 549) 48512* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 541) 48513* IFCVT_MODIFY_TESTS: Misc. (line 531) 48514* IF_COND: Statements for C++. (line 6) 48515* IF_STMT: Statements for C++. (line 6) 48516* if_then_else: Comparisons. (line 80) 48517* if_then_else and attributes: Expressions. (line 32) 48518* if_then_else usage: Side Effects. (line 56) 48519* IMAGPART_EXPR: Unary and Binary Expressions. 48520 (line 6) 48521* Immediate Uses: SSA Operands. (line 258) 48522* immediate_operand: Machine-Independent Predicates. 48523 (line 10) 48524* IMMEDIATE_PREFIX: Instruction Output. (line 153) 48525* include: Including Patterns. (line 6) 48526* INCLUDE_DEFAULTS: Driver. (line 327) 48527* inclusive-or, bitwise: Arithmetic. (line 163) 48528* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 183) 48529* INCOMING_REGNO: Register Basics. (line 86) 48530* INCOMING_REG_PARM_STACK_SPACE: Stack Arguments. (line 73) 48531* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 139) 48532* INCOMING_STACK_BOUNDARY: Storage Layout. (line 154) 48533* INDEX_REG_CLASS: Register Classes. (line 140) 48534* indirect_jump instruction pattern: Standard Names. (line 1286) 48535* indirect_operand: Machine-Independent Predicates. 48536 (line 70) 48537* INDIRECT_REF: Storage References. (line 6) 48538* initialization routines: Initialization. (line 6) 48539* INITIAL_ELIMINATION_OFFSET: Elimination. (line 84) 48540* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 81) 48541* INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 34) 48542* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 106) 48543* INIT_CUMULATIVE_ARGS: Register Arguments. (line 161) 48544* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 189) 48545* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 183) 48546* INIT_ENVIRONMENT: Driver. (line 305) 48547* INIT_EXPANDERS: Per-Function Data. (line 36) 48548* INIT_EXPR: Unary and Binary Expressions. 48549 (line 6) 48550* init_machine_status: Per-Function Data. (line 42) 48551* init_one_libfunc: Library Calls. (line 15) 48552* INIT_SECTION_ASM_OP: Sections. (line 90) 48553* INIT_SECTION_ASM_OP <1>: Macros for Initialization. 48554 (line 9) 48555* inlining: Target Attributes. (line 95) 48556* insert_insn_on_edge: Maintaining the CFG. 48557 (line 105) 48558* insn: Insns. (line 63) 48559* insn and /f: Flags. (line 107) 48560* insn and /j: Flags. (line 157) 48561* insn and /s: Flags. (line 49) 48562* insn and /s <1>: Flags. (line 148) 48563* insn and /u: Flags. (line 39) 48564* insn and /v: Flags. (line 44) 48565* insn attributes: Insn Attributes. (line 6) 48566* insn canonicalization: Insn Canonicalizations. 48567 (line 6) 48568* insn includes: Including Patterns. (line 6) 48569* insn lengths, computing: Insn Lengths. (line 6) 48570* insn notes, notes: Basic Blocks. (line 52) 48571* insn splitting: Insn Splitting. (line 6) 48572* insn-attr.h: Defining Attributes. 48573 (line 34) 48574* insns: Insns. (line 6) 48575* insns, generating: RTL Template. (line 6) 48576* insns, recognizing: RTL Template. (line 6) 48577* INSN_ANNULLED_BRANCH_P: Flags. (line 39) 48578* INSN_CODE: Insns. (line 295) 48579* INSN_DELETED_P: Flags. (line 44) 48580* INSN_FROM_TARGET_P: Flags. (line 49) 48581* insn_list: Insns. (line 540) 48582* INSN_REFERENCES_ARE_DELAYED: Misc. (line 469) 48583* INSN_SETS_ARE_DELAYED: Misc. (line 458) 48584* INSN_UID: Insns. (line 23) 48585* INSN_VAR_LOCATION: Insns. (line 236) 48586* instruction attributes: Insn Attributes. (line 6) 48587* instruction latency time: Processor pipeline description. 48588 (line 6) 48589* instruction latency time <1>: Processor pipeline description. 48590 (line 105) 48591* instruction latency time <2>: Processor pipeline description. 48592 (line 196) 48593* instruction patterns: Patterns. (line 6) 48594* instruction splitting: Insn Splitting. (line 6) 48595* insv instruction pattern: Standard Names. (line 1085) 48596* insvM instruction pattern: Standard Names. (line 1037) 48597* insvmisalignM instruction pattern: Standard Names. (line 1047) 48598* int iterators in .md files: Int Iterators. (line 6) 48599* INT16_TYPE: Type Layout. (line 216) 48600* INT32_TYPE: Type Layout. (line 217) 48601* INT64_TYPE: Type Layout. (line 218) 48602* INT8_TYPE: Type Layout. (line 215) 48603* INTEGER_CST: Constant expressions. 48604 (line 6) 48605* INTEGER_TYPE: Types. (line 6) 48606* Interdependence of Patterns: Dependent Patterns. (line 6) 48607* interfacing to GCC output: Interface. (line 6) 48608* interlock delays: Processor pipeline description. 48609 (line 6) 48610* intermediate representation lowering: Parsing pass. (line 13) 48611* INTMAX_TYPE: Type Layout. (line 192) 48612* INTPTR_TYPE: Type Layout. (line 239) 48613* introduction: Top. (line 6) 48614* INT_FAST16_TYPE: Type Layout. (line 232) 48615* INT_FAST32_TYPE: Type Layout. (line 233) 48616* INT_FAST64_TYPE: Type Layout. (line 234) 48617* INT_FAST8_TYPE: Type Layout. (line 231) 48618* INT_LEAST16_TYPE: Type Layout. (line 224) 48619* INT_LEAST32_TYPE: Type Layout. (line 225) 48620* INT_LEAST64_TYPE: Type Layout. (line 226) 48621* INT_LEAST8_TYPE: Type Layout. (line 223) 48622* INT_TYPE_SIZE: Type Layout. (line 11) 48623* INVOKE__main: Macros for Initialization. 48624 (line 50) 48625* in_struct: Flags. (line 245) 48626* in_struct, in code_label and note: Flags. (line 59) 48627* in_struct, in insn and jump_insn and call_insn: Flags. (line 49) 48628* in_struct, in insn, call_insn, jump_insn and jump_table_data: Flags. 48629 (line 148) 48630* in_struct, in subreg: Flags. (line 187) 48631* ior: Arithmetic. (line 163) 48632* ior and attributes: Expressions. (line 50) 48633* ior, canonicalization of: Insn Canonicalizations. 48634 (line 51) 48635* iorM3 instruction pattern: Standard Names. (line 266) 48636* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 44) 48637* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 123) 48638* is_gimple_addressable: Logical Operators. (line 113) 48639* is_gimple_asm_val: Logical Operators. (line 117) 48640* is_gimple_assign: Logical Operators. (line 149) 48641* is_gimple_call: Logical Operators. (line 152) 48642* is_gimple_call_addr: Logical Operators. (line 120) 48643* is_gimple_constant: Logical Operators. (line 128) 48644* is_gimple_debug: Logical Operators. (line 155) 48645* is_gimple_ip_invariant: Logical Operators. (line 137) 48646* is_gimple_ip_invariant_address: Logical Operators. (line 142) 48647* is_gimple_mem_ref_addr: Logical Operators. (line 124) 48648* is_gimple_min_invariant: Logical Operators. (line 131) 48649* is_gimple_omp: Logical Operators. (line 166) 48650* is_gimple_val: Logical Operators. (line 107) 48651* iterators in .md files: Iterators. (line 6) 48652* IV analysis on GIMPLE: Scalar evolutions. (line 6) 48653* IV analysis on RTL: loop-iv. (line 6) 48654* JMP_BUF_SIZE: Exception Region Output. 48655 (line 82) 48656* jump: Flags. (line 286) 48657* jump instruction pattern: Standard Names. (line 1164) 48658* jump instruction patterns: Jump Patterns. (line 6) 48659* jump instructions and set: Side Effects. (line 56) 48660* jump, in call_insn: Flags. (line 161) 48661* jump, in insn: Flags. (line 157) 48662* jump, in mem: Flags. (line 70) 48663* Jumps: Jumps. (line 6) 48664* JUMP_ALIGN: Alignment Output. (line 8) 48665* jump_insn: Insns. (line 73) 48666* jump_insn and /f: Flags. (line 107) 48667* jump_insn and /s: Flags. (line 49) 48668* jump_insn and /s <1>: Flags. (line 148) 48669* jump_insn and /u: Flags. (line 39) 48670* jump_insn and /v: Flags. (line 44) 48671* JUMP_LABEL: Insns. (line 80) 48672* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 150) 48673* jump_table_data: Insns. (line 166) 48674* jump_table_data and /s: Flags. (line 148) 48675* jump_table_data and /v: Flags. (line 44) 48676* LABEL_ALIGN: Alignment Output. (line 57) 48677* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 26) 48678* LABEL_ALTERNATE_NAME: Edges. (line 180) 48679* LABEL_ALT_ENTRY_P: Insns. (line 146) 48680* LABEL_DECL: Declarations. (line 6) 48681* LABEL_KIND: Insns. (line 146) 48682* LABEL_NUSES: Insns. (line 142) 48683* LABEL_PRESERVE_P: Flags. (line 59) 48684* label_ref: Constants. (line 127) 48685* label_ref and /v: Flags. (line 65) 48686* label_ref, RTL sharing: Sharing. (line 35) 48687* LABEL_REF_NONLOCAL_P: Flags. (line 65) 48688* language-dependent trees: Language-dependent trees. 48689 (line 6) 48690* language-independent intermediate representation: Parsing pass. 48691 (line 13) 48692* lang_hooks.gimplify_expr: Gimplification pass. 48693 (line 18) 48694* lang_hooks.parse_file: Parsing pass. (line 6) 48695* large return values: Aggregate Return. (line 6) 48696* LAST_STACK_REG: Stack Registers. (line 30) 48697* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 48698* lceilMN2: Standard Names. (line 740) 48699* LCSSA: LCSSA. (line 6) 48700* LDD_SUFFIX: Macros for Initialization. 48701 (line 121) 48702* LD_FINI_SWITCH: Macros for Initialization. 48703 (line 28) 48704* LD_INIT_SWITCH: Macros for Initialization. 48705 (line 24) 48706* le: Comparisons. (line 76) 48707* le and attributes: Expressions. (line 83) 48708* leaf functions: Leaf Functions. (line 6) 48709* leaf_function_p: Standard Names. (line 1248) 48710* LEAF_REGISTERS: Leaf Functions. (line 23) 48711* LEAF_REG_REMAP: Leaf Functions. (line 37) 48712* left rotate: Arithmetic. (line 195) 48713* left shift: Arithmetic. (line 173) 48714* LEGITIMATE_PIC_OPERAND_P: PIC. (line 31) 48715* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 150) 48716* length: GTY Options. (line 47) 48717* less than: Comparisons. (line 68) 48718* less than or equal: Comparisons. (line 76) 48719* leu: Comparisons. (line 76) 48720* leu and attributes: Expressions. (line 83) 48721* LE_EXPR: Unary and Binary Expressions. 48722 (line 6) 48723* lfloorMN2: Standard Names. (line 735) 48724* LIB2FUNCS_EXTRA: Target Fragment. (line 11) 48725* LIBCALL_VALUE: Scalar Return. (line 56) 48726* libgcc.a: Library Calls. (line 6) 48727* LIBGCC2_CFLAGS: Target Fragment. (line 8) 48728* LIBGCC2_GNU_PREFIX: Type Layout. (line 102) 48729* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 1097) 48730* LIBGCC_SPEC: Driver. (line 115) 48731* library subroutine names: Library Calls. (line 6) 48732* LIBRARY_PATH_ENV: Misc. (line 509) 48733* LIB_SPEC: Driver. (line 107) 48734* LIMIT_RELOAD_CLASS: Register Classes. (line 296) 48735* LINK_COMMAND_SPEC: Driver. (line 236) 48736* LINK_EH_SPEC: Driver. (line 142) 48737* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 232) 48738* LINK_LIBGCC_SPECIAL_1: Driver. (line 227) 48739* LINK_SPEC: Driver. (line 100) 48740* list: Containers. (line 6) 48741* Liveness representation: Liveness information. 48742 (line 6) 48743* load address instruction: Simple Constraints. (line 162) 48744* LOAD_EXTEND_OP: Misc. (line 59) 48745* load_multiple instruction pattern: Standard Names. (line 136) 48746* Local Register Allocator (LRA): RTL passes. (line 187) 48747* LOCAL_ALIGNMENT: Storage Layout. (line 254) 48748* LOCAL_CLASS_P: Classes. (line 73) 48749* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 291) 48750* LOCAL_INCLUDE_DIR: Driver. (line 312) 48751* LOCAL_LABEL_PREFIX: Instruction Output. (line 151) 48752* LOCAL_REGNO: Register Basics. (line 100) 48753* Logical Operators: Logical Operators. (line 6) 48754* logical-and, bitwise: Arithmetic. (line 158) 48755* LOGICAL_OP_NON_SHORT_CIRCUIT: Costs. (line 272) 48756* logM2 instruction pattern: Standard Names. (line 648) 48757* LOG_LINKS: Insns. (line 314) 48758* longjmp and automatic variables: Interface. (line 52) 48759* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 92) 48760* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 57) 48761* LONG_FRACT_TYPE_SIZE: Type Layout. (line 72) 48762* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 97) 48763* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 77) 48764* LONG_LONG_TYPE_SIZE: Type Layout. (line 32) 48765* LONG_TYPE_SIZE: Type Layout. (line 21) 48766* Loop analysis: Loop representation. 48767 (line 6) 48768* Loop manipulation: Loop manipulation. (line 6) 48769* Loop querying: Loop querying. (line 6) 48770* Loop representation: Loop representation. 48771 (line 6) 48772* Loop-closed SSA form: LCSSA. (line 6) 48773* looping instruction patterns: Looping Patterns. (line 6) 48774* LOOP_ALIGN: Alignment Output. (line 40) 48775* LOOP_EXPR: Unary and Binary Expressions. 48776 (line 6) 48777* lowering, language-dependent intermediate representation: Parsing pass. 48778 (line 13) 48779* lo_sum: Arithmetic. (line 25) 48780* lrintMN2: Standard Names. (line 725) 48781* lroundMN2: Standard Names. (line 730) 48782* lshiftrt: Arithmetic. (line 190) 48783* lshiftrt and attributes: Expressions. (line 83) 48784* LSHIFT_EXPR: Unary and Binary Expressions. 48785 (line 6) 48786* lshrM3 instruction pattern: Standard Names. (line 563) 48787* lt: Comparisons. (line 68) 48788* lt and attributes: Expressions. (line 83) 48789* LTGT_EXPR: Unary and Binary Expressions. 48790 (line 6) 48791* lto: LTO. (line 6) 48792* ltrans: LTO. (line 6) 48793* ltu: Comparisons. (line 68) 48794* LT_EXPR: Unary and Binary Expressions. 48795 (line 6) 48796* m in constraint: Simple Constraints. (line 17) 48797* machine attributes: Target Attributes. (line 6) 48798* machine description macros: Target Macros. (line 6) 48799* machine descriptions: Machine Desc. (line 6) 48800* machine mode conversions: Conversions. (line 6) 48801* machine modes: Machine Modes. (line 6) 48802* machine specific constraints: Machine Constraints. 48803 (line 6) 48804* machine-independent predicates: Machine-Independent Predicates. 48805 (line 6) 48806* machine_mode: Machine Modes. (line 6) 48807* macros, target description: Target Macros. (line 6) 48808* maddMN4 instruction pattern: Standard Names. (line 486) 48809* makefile fragment: Fragments. (line 6) 48810* makefile targets: Makefile. (line 6) 48811* MAKE_DECL_ONE_ONLY: Label Output. (line 253) 48812* make_safe_from: Expander Definitions. 48813 (line 151) 48814* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 173) 48815* Manipulating GIMPLE statements: Manipulating GIMPLE statements. 48816 (line 6) 48817* marking roots: GGC Roots. (line 6) 48818* mark_hook: GTY Options. (line 139) 48819* MASK_RETURN_ADDR: Exception Region Output. 48820 (line 34) 48821* Match and Simplify: Match and Simplify. (line 6) 48822* matching constraint: Simple Constraints. (line 140) 48823* matching operands: Output Template. (line 49) 48824* match_dup: RTL Template. (line 73) 48825* match_dup <1>: define_peephole2. (line 28) 48826* match_dup and attributes: Insn Lengths. (line 16) 48827* match_operand: RTL Template. (line 16) 48828* match_operand and attributes: Expressions. (line 55) 48829* match_operator: RTL Template. (line 95) 48830* match_op_dup: RTL Template. (line 163) 48831* match_parallel: RTL Template. (line 172) 48832* match_par_dup: RTL Template. (line 219) 48833* match_scratch: RTL Template. (line 58) 48834* match_scratch <1>: define_peephole2. (line 28) 48835* match_test and attributes: Expressions. (line 64) 48836* math library: Soft float library routines. 48837 (line 6) 48838* math, in RTL: Arithmetic. (line 6) 48839* matherr: Library Calls. (line 59) 48840* MATH_LIBRARY: Misc. (line 502) 48841* maxM3 instruction pattern: Standard Names. (line 325) 48842* MAX_BITSIZE_MODE_ANY_INT: Machine Modes. (line 358) 48843* MAX_BITSIZE_MODE_ANY_MODE: Machine Modes. (line 364) 48844* MAX_BITS_PER_WORD: Storage Layout. (line 54) 48845* MAX_CONDITIONAL_EXECUTE: Misc. (line 524) 48846* MAX_FIXED_MODE_SIZE: Storage Layout. (line 436) 48847* MAX_MOVE_MAX: Misc. (line 105) 48848* MAX_OFILE_ALIGNMENT: Storage Layout. (line 208) 48849* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42) 48850* MAX_STACK_ALIGNMENT: Storage Layout. (line 202) 48851* maybe_undef: GTY Options. (line 148) 48852* may_trap_p, tree_could_trap_p: Edges. (line 114) 48853* mcount: Profiling. (line 12) 48854* MD_EXEC_PREFIX: Driver. (line 267) 48855* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 93) 48856* MD_HANDLE_UNWABI: Exception Handling. (line 112) 48857* MD_STARTFILE_PREFIX: Driver. (line 295) 48858* MD_STARTFILE_PREFIX_1: Driver. (line 300) 48859* mem: Regs and Memory. (line 370) 48860* mem and /c: Flags. (line 81) 48861* mem and /f: Flags. (line 85) 48862* mem and /j: Flags. (line 70) 48863* mem and /u: Flags. (line 134) 48864* mem and /v: Flags. (line 76) 48865* mem, RTL sharing: Sharing. (line 40) 48866* memory model: Memory model. (line 6) 48867* memory reference, nonoffsettable: Simple Constraints. (line 254) 48868* memory references in constraints: Simple Constraints. (line 17) 48869* memory_barrier instruction pattern: Standard Names. (line 1634) 48870* MEMORY_MOVE_COST: Costs. (line 53) 48871* memory_operand: Machine-Independent Predicates. 48872 (line 57) 48873* MEM_ADDR_SPACE: Special Accessors. (line 48) 48874* MEM_ALIAS_SET: Special Accessors. (line 9) 48875* MEM_ALIGN: Special Accessors. (line 45) 48876* MEM_EXPR: Special Accessors. (line 19) 48877* MEM_KEEP_ALIAS_SET_P: Flags. (line 70) 48878* MEM_NOTRAP_P: Flags. (line 81) 48879* MEM_OFFSET: Special Accessors. (line 31) 48880* MEM_OFFSET_KNOWN_P: Special Accessors. (line 27) 48881* MEM_POINTER: Flags. (line 85) 48882* MEM_READONLY_P: Flags. (line 134) 48883* MEM_REF: Storage References. (line 6) 48884* mem_signal_fenceMODE instruction pattern: Standard Names. (line 1893) 48885* MEM_SIZE: Special Accessors. (line 39) 48886* MEM_SIZE_KNOWN_P: Special Accessors. (line 35) 48887* mem_thread_fenceMODE instruction pattern: Standard Names. (line 1885) 48888* MEM_VOLATILE_P: Flags. (line 76) 48889* METHOD_TYPE: Types. (line 6) 48890* MINIMUM_ALIGNMENT: Storage Layout. (line 304) 48891* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 181) 48892* minM3 instruction pattern: Standard Names. (line 325) 48893* minus: Arithmetic. (line 38) 48894* minus and attributes: Expressions. (line 83) 48895* minus, canonicalization of: Insn Canonicalizations. 48896 (line 27) 48897* MINUS_EXPR: Unary and Binary Expressions. 48898 (line 6) 48899* MIN_UNITS_PER_WORD: Storage Layout. (line 64) 48900* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 48901* miscellaneous register hooks: Miscellaneous Register Hooks. 48902 (line 6) 48903* mnemonic attribute: Mnemonic Attribute. (line 6) 48904* mod: Arithmetic. (line 136) 48905* mod and attributes: Expressions. (line 83) 48906* mode classes: Machine Modes. (line 225) 48907* mode iterators in .md files: Mode Iterators. (line 6) 48908* mode switching: Mode Switching. (line 6) 48909* MODES_TIEABLE_P: Values in Registers. 48910 (line 127) 48911* MODE_ACCUM: Machine Modes. (line 255) 48912* MODE_BASE_REG_CLASS: Register Classes. (line 116) 48913* MODE_BASE_REG_REG_CLASS: Register Classes. (line 122) 48914* MODE_CC: Machine Modes. (line 274) 48915* MODE_CC <1>: MODE_CC Condition Codes. 48916 (line 6) 48917* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 129) 48918* MODE_COMPLEX_FLOAT: Machine Modes. (line 266) 48919* MODE_COMPLEX_INT: Machine Modes. (line 263) 48920* MODE_DECIMAL_FLOAT: Machine Modes. (line 243) 48921* MODE_FLOAT: Machine Modes. (line 239) 48922* MODE_FRACT: Machine Modes. (line 247) 48923* MODE_FUNCTION: Machine Modes. (line 270) 48924* MODE_INT: Machine Modes. (line 231) 48925* MODE_PARTIAL_INT: Machine Modes. (line 235) 48926* MODE_POINTER_BOUNDS: Machine Modes. (line 279) 48927* MODE_RANDOM: Machine Modes. (line 284) 48928* MODE_UACCUM: Machine Modes. (line 259) 48929* MODE_UFRACT: Machine Modes. (line 251) 48930* modifiers in constraints: Modifiers. (line 6) 48931* MODIFY_EXPR: Unary and Binary Expressions. 48932 (line 6) 48933* MODIFY_JNI_METHOD_CALL: Misc. (line 873) 48934* modM3 instruction pattern: Standard Names. (line 266) 48935* modulo scheduling: RTL passes. (line 123) 48936* MOVE_MAX: Misc. (line 100) 48937* MOVE_MAX_PIECES: Costs. (line 199) 48938* MOVE_RATIO: Costs. (line 148) 48939* movM instruction pattern: Standard Names. (line 11) 48940* movmemM instruction pattern: Standard Names. (line 805) 48941* movmisalignM instruction pattern: Standard Names. (line 125) 48942* movMODEcc instruction pattern: Standard Names. (line 1099) 48943* movstr instruction pattern: Standard Names. (line 840) 48944* movstrictM instruction pattern: Standard Names. (line 119) 48945* msubMN4 instruction pattern: Standard Names. (line 509) 48946* mulhisi3 instruction pattern: Standard Names. (line 462) 48947* mulM3 instruction pattern: Standard Names. (line 266) 48948* mulqihi3 instruction pattern: Standard Names. (line 466) 48949* mulsidi3 instruction pattern: Standard Names. (line 466) 48950* mult: Arithmetic. (line 93) 48951* mult and attributes: Expressions. (line 83) 48952* mult, canonicalization of: Insn Canonicalizations. 48953 (line 27) 48954* mult, canonicalization of <1>: Insn Canonicalizations. 48955 (line 91) 48956* MULTIARCH_DIRNAME: Target Fragment. (line 170) 48957* MULTILIB_DEFAULTS: Driver. (line 252) 48958* MULTILIB_DIRNAMES: Target Fragment. (line 44) 48959* MULTILIB_EXCEPTIONS: Target Fragment. (line 70) 48960* MULTILIB_EXTRA_OPTS: Target Fragment. (line 132) 48961* MULTILIB_MATCHES: Target Fragment. (line 63) 48962* MULTILIB_OPTIONS: Target Fragment. (line 24) 48963* MULTILIB_OSDIRNAMES: Target Fragment. (line 139) 48964* MULTILIB_REQUIRED: Target Fragment. (line 82) 48965* MULTILIB_REUSE: Target Fragment. (line 103) 48966* multiple alternative constraints: Multi-Alternative. (line 6) 48967* MULTIPLE_SYMBOL_SPACES: Misc. (line 482) 48968* multiplication: Arithmetic. (line 93) 48969* multiplication with signed saturation: Arithmetic. (line 93) 48970* multiplication with unsigned saturation: Arithmetic. (line 93) 48971* MULT_EXPR: Unary and Binary Expressions. 48972 (line 6) 48973* MULT_HIGHPART_EXPR: Unary and Binary Expressions. 48974 (line 6) 48975* mulvM4 instruction pattern: Standard Names. (line 282) 48976* n in constraint: Simple Constraints. (line 73) 48977* name: Identifiers. (line 6) 48978* named address spaces: Named Address Spaces. 48979 (line 6) 48980* named patterns and conditions: Patterns. (line 49) 48981* names, pattern: Standard Names. (line 6) 48982* namespace, scope: Namespaces. (line 6) 48983* NAMESPACE_DECL: Declarations. (line 6) 48984* NAMESPACE_DECL <1>: Namespaces. (line 6) 48985* NATIVE_SYSTEM_HEADER_COMPONENT: Driver. (line 322) 48986* ne: Comparisons. (line 56) 48987* ne and attributes: Expressions. (line 83) 48988* nearbyintM2 instruction pattern: Standard Names. (line 707) 48989* neg: Arithmetic. (line 82) 48990* neg and attributes: Expressions. (line 83) 48991* neg, canonicalization of: Insn Canonicalizations. 48992 (line 27) 48993* NEGATE_EXPR: Unary and Binary Expressions. 48994 (line 6) 48995* negation: Arithmetic. (line 82) 48996* negation with signed saturation: Arithmetic. (line 82) 48997* negation with unsigned saturation: Arithmetic. (line 82) 48998* negM2 instruction pattern: Standard Names. (line 575) 48999* negvM3 instruction pattern: Standard Names. (line 578) 49000* nested functions, trampolines for: Trampolines. (line 6) 49001* nested_ptr: GTY Options. (line 156) 49002* next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks. (line 25) 49003* NEXT_INSN: Insns. (line 30) 49004* NEXT_OBJC_RUNTIME: Library Calls. (line 82) 49005* NE_EXPR: Unary and Binary Expressions. 49006 (line 6) 49007* nil: RTL Objects. (line 73) 49008* NM_FLAGS: Macros for Initialization. 49009 (line 110) 49010* nondeterministic finite state automaton: Processor pipeline description. 49011 (line 304) 49012* nonimmediate_operand: Machine-Independent Predicates. 49013 (line 100) 49014* nonlocal goto handler: Edges. (line 171) 49015* nonlocal_goto instruction pattern: Standard Names. (line 1468) 49016* nonlocal_goto_receiver instruction pattern: Standard Names. 49017 (line 1485) 49018* nonmemory_operand: Machine-Independent Predicates. 49019 (line 96) 49020* nonoffsettable memory reference: Simple Constraints. (line 254) 49021* NON_LVALUE_EXPR: Unary and Binary Expressions. 49022 (line 6) 49023* nop instruction pattern: Standard Names. (line 1281) 49024* NOP_EXPR: Unary and Binary Expressions. 49025 (line 6) 49026* normal predicates: Predicates. (line 31) 49027* not: Arithmetic. (line 154) 49028* not and attributes: Expressions. (line 50) 49029* not equal: Comparisons. (line 56) 49030* not, canonicalization of: Insn Canonicalizations. 49031 (line 27) 49032* note: Insns. (line 183) 49033* note and /i: Flags. (line 59) 49034* note and /v: Flags. (line 44) 49035* NOTE_INSN_BASIC_BLOCK: Basic Blocks. (line 50) 49036* NOTE_INSN_BASIC_BLOCK <1>: Basic Blocks. (line 52) 49037* NOTE_INSN_BLOCK_BEG: Insns. (line 208) 49038* NOTE_INSN_BLOCK_END: Insns. (line 208) 49039* NOTE_INSN_DELETED: Insns. (line 198) 49040* NOTE_INSN_DELETED_LABEL: Insns. (line 203) 49041* NOTE_INSN_EH_REGION_BEG: Insns. (line 214) 49042* NOTE_INSN_EH_REGION_END: Insns. (line 214) 49043* NOTE_INSN_FUNCTION_BEG: Insns. (line 221) 49044* NOTE_INSN_VAR_LOCATION: Insns. (line 225) 49045* NOTE_LINE_NUMBER: Insns. (line 183) 49046* NOTE_SOURCE_FILE: Insns. (line 183) 49047* NOTE_VAR_LOCATION: Insns. (line 225) 49048* NOTICE_UPDATE_CC: CC0 Condition Codes. 49049 (line 30) 49050* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 25) 49051* NO_DBX_FUNCTION_END: DBX Hooks. (line 19) 49052* NO_DBX_GCC_MARKER: File Names and DBX. (line 27) 49053* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 22) 49054* NO_DOLLAR_IN_LABEL: Label Output. (line 64) 49055* NO_DOT_IN_LABEL: Label Output. (line 70) 49056* NO_FUNCTION_CSE: Costs. (line 268) 49057* NO_IMPLICIT_EXTERN_C: Misc. (line 381) 49058* NO_PROFILE_COUNTERS: Profiling. (line 27) 49059* NO_REGS: Register Classes. (line 17) 49060* Number of iterations analysis: Number of iterations. 49061 (line 6) 49062* NUM_MACHINE_MODES: Machine Modes. (line 297) 49063* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 49064* N_REG_CLASSES: Register Classes. (line 81) 49065* o in constraint: Simple Constraints. (line 23) 49066* OACC_CACHE: OpenACC. (line 6) 49067* OACC_DATA: OpenACC. (line 6) 49068* OACC_DECLARE: OpenACC. (line 6) 49069* OACC_ENTER_DATA: OpenACC. (line 6) 49070* OACC_EXIT_DATA: OpenACC. (line 6) 49071* OACC_HOST_DATA: OpenACC. (line 6) 49072* OACC_KERNELS: OpenACC. (line 6) 49073* OACC_LOOP: OpenACC. (line 6) 49074* OACC_PARALLEL: OpenACC. (line 6) 49075* OACC_UPDATE: OpenACC. (line 6) 49076* OBJC_GEN_METHOD_LABEL: Label Output. (line 454) 49077* OBJC_JBLEN: Misc. (line 1092) 49078* OBJECT_FORMAT_COFF: Macros for Initialization. 49079 (line 96) 49080* offsettable address: Simple Constraints. (line 23) 49081* OFFSET_TYPE: Types. (line 6) 49082* OImode: Machine Modes. (line 51) 49083* Omega a solver for linear programming problems: Omega. (line 6) 49084* OMP_ATOMIC: OpenMP. (line 6) 49085* OMP_CLAUSE: OpenMP. (line 6) 49086* OMP_CONTINUE: OpenMP. (line 6) 49087* OMP_CRITICAL: OpenMP. (line 6) 49088* OMP_FOR: OpenMP. (line 6) 49089* OMP_MASTER: OpenMP. (line 6) 49090* OMP_ORDERED: OpenMP. (line 6) 49091* OMP_PARALLEL: OpenMP. (line 6) 49092* OMP_RETURN: OpenMP. (line 6) 49093* OMP_SECTION: OpenMP. (line 6) 49094* OMP_SECTIONS: OpenMP. (line 6) 49095* OMP_SINGLE: OpenMP. (line 6) 49096* one_cmplM2 instruction pattern: Standard Names. (line 802) 49097* operand access: Accessors. (line 6) 49098* Operand Access Routines: SSA Operands. (line 116) 49099* operand constraints: Constraints. (line 6) 49100* Operand Iterators: SSA Operands. (line 116) 49101* operand predicates: Predicates. (line 6) 49102* operand substitution: Output Template. (line 6) 49103* Operands: Operands. (line 6) 49104* operands: SSA Operands. (line 6) 49105* operands <1>: Patterns. (line 55) 49106* operator predicates: Predicates. (line 6) 49107* optc-gen.awk: Options. (line 6) 49108* OPTGROUP_ALL: Optimization groups. 49109 (line 25) 49110* OPTGROUP_INLINE: Optimization groups. 49111 (line 15) 49112* OPTGROUP_IPA: Optimization groups. 49113 (line 9) 49114* OPTGROUP_LOOP: Optimization groups. 49115 (line 12) 49116* OPTGROUP_OTHER: Optimization groups. 49117 (line 21) 49118* OPTGROUP_VEC: Optimization groups. 49119 (line 18) 49120* optimization dumps: Optimization info. (line 6) 49121* optimization groups: Optimization groups. 49122 (line 6) 49123* optimization info file names: Dump files and streams. 49124 (line 6) 49125* Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 49126* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 8) 49127* option specification files: Options. (line 6) 49128* optional hardware or system features: Run-time Target. (line 59) 49129* options, directory search: Including Patterns. (line 47) 49130* OPTION_DEFAULT_SPECS: Driver. (line 25) 49131* order of register allocation: Allocation Order. (line 6) 49132* ordered_comparison_operator: Machine-Independent Predicates. 49133 (line 115) 49134* ORDERED_EXPR: Unary and Binary Expressions. 49135 (line 6) 49136* Ordering of Patterns: Pattern Ordering. (line 6) 49137* ORIGINAL_REGNO: Special Accessors. (line 53) 49138* other register constraints: Simple Constraints. (line 171) 49139* outgoing_args_size: Stack Arguments. (line 48) 49140* OUTGOING_REGNO: Register Basics. (line 93) 49141* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 79) 49142* output of assembler code: File Framework. (line 6) 49143* output statements: Output Statement. (line 6) 49144* output templates: Output Template. (line 6) 49145* output_asm_insn: Output Statement. (line 52) 49146* OUTPUT_QUOTED_STRING: File Framework. (line 106) 49147* OVERLAPPING_REGISTER_NAMES: Instruction Output. (line 20) 49148* OVERLOAD: Functions for C++. (line 6) 49149* OVERRIDE_ABI_FORMAT: Register Arguments. (line 153) 49150* OVL_CURRENT: Functions for C++. (line 6) 49151* OVL_NEXT: Functions for C++. (line 6) 49152* p in constraint: Simple Constraints. (line 162) 49153* PAD_VARARGS_DOWN: Register Arguments. (line 234) 49154* parallel: Side Effects. (line 210) 49155* parameters, c++ abi: C++ ABI. (line 6) 49156* parameters, miscellaneous: Misc. (line 6) 49157* parameters, precompiled headers: PCH Target. (line 6) 49158* parity: Arithmetic. (line 242) 49159* parityM2 instruction pattern: Standard Names. (line 795) 49160* PARM_BOUNDARY: Storage Layout. (line 133) 49161* PARM_DECL: Declarations. (line 6) 49162* PARSE_LDD_OUTPUT: Macros for Initialization. 49163 (line 125) 49164* pass dumps: Passes. (line 6) 49165* passes and files of the compiler: Passes. (line 6) 49166* passing arguments: Interface. (line 36) 49167* pass_duplicate_computed_gotos: Edges. (line 161) 49168* PATH_SEPARATOR: Filesystem. (line 31) 49169* PATTERN: Insns. (line 284) 49170* pattern conditions: Patterns. (line 43) 49171* pattern names: Standard Names. (line 6) 49172* Pattern Ordering: Pattern Ordering. (line 6) 49173* patterns: Patterns. (line 6) 49174* pc: Regs and Memory. (line 357) 49175* pc and attributes: Insn Lengths. (line 20) 49176* pc, RTL sharing: Sharing. (line 25) 49177* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 330) 49178* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 64) 49179* PC_REGNUM: Register Basics. (line 107) 49180* pc_rtx: Regs and Memory. (line 362) 49181* PDImode: Machine Modes. (line 40) 49182* peephole optimization, RTL representation: Side Effects. (line 244) 49183* peephole optimizer definitions: Peephole Definitions. 49184 (line 6) 49185* per-function data: Per-Function Data. (line 6) 49186* percent sign: Output Template. (line 6) 49187* PHI nodes: SSA. (line 31) 49188* PIC: PIC. (line 6) 49189* PIC_OFFSET_TABLE_REGNUM: PIC. (line 15) 49190* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 25) 49191* pipeline hazard recognizer: Processor pipeline description. 49192 (line 6) 49193* pipeline hazard recognizer <1>: Processor pipeline description. 49194 (line 53) 49195* Plugins: Plugins. (line 6) 49196* plus: Arithmetic. (line 14) 49197* plus and attributes: Expressions. (line 83) 49198* plus, canonicalization of: Insn Canonicalizations. 49199 (line 27) 49200* PLUS_EXPR: Unary and Binary Expressions. 49201 (line 6) 49202* Pmode: Misc. (line 329) 49203* pmode_register_operand: Machine-Independent Predicates. 49204 (line 34) 49205* pointer: Types. (line 6) 49206* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 76) 49207* POINTER_PLUS_EXPR: Unary and Binary Expressions. 49208 (line 6) 49209* POINTER_SIZE: Storage Layout. (line 70) 49210* POINTER_TYPE: Types. (line 6) 49211* popcount: Arithmetic. (line 238) 49212* popcountM2 instruction pattern: Standard Names. (line 789) 49213* pops_args: Function Entry. (line 104) 49214* pop_operand: Machine-Independent Predicates. 49215 (line 87) 49216* portability: Portability. (line 6) 49217* position independent code: PIC. (line 6) 49218* POSTDECREMENT_EXPR: Unary and Binary Expressions. 49219 (line 6) 49220* POSTINCREMENT_EXPR: Unary and Binary Expressions. 49221 (line 6) 49222* post_dec: Incdec. (line 25) 49223* post_inc: Incdec. (line 30) 49224* post_modify: Incdec. (line 33) 49225* post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks. 49226 (line 34) 49227* POWI_MAX_MULTS: Misc. (line 961) 49228* powM3 instruction pattern: Standard Names. (line 656) 49229* pragma: Misc. (line 387) 49230* PREDECREMENT_EXPR: Unary and Binary Expressions. 49231 (line 6) 49232* predefined macros: Run-time Target. (line 6) 49233* predicates: Predicates. (line 6) 49234* predicates and machine modes: Predicates. (line 31) 49235* predication: Conditional Execution. 49236 (line 6) 49237* predict.def: Profile information. 49238 (line 24) 49239* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 41) 49240* PREFERRED_RELOAD_CLASS: Register Classes. (line 249) 49241* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 147) 49242* prefetch: Side Effects. (line 324) 49243* prefetch and /v: Flags. (line 214) 49244* prefetch instruction pattern: Standard Names. (line 1611) 49245* PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 214) 49246* PREINCREMENT_EXPR: Unary and Binary Expressions. 49247 (line 6) 49248* presence_set: Processor pipeline description. 49249 (line 223) 49250* preserving SSA form: SSA. (line 74) 49251* preserving virtual SSA form: SSA. (line 182) 49252* pretend_args_size: Function Entry. (line 110) 49253* prev_active_insn: define_peephole. (line 60) 49254* PREV_INSN: Insns. (line 26) 49255* pre_dec: Incdec. (line 8) 49256* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 126) 49257* pre_inc: Incdec. (line 22) 49258* pre_modify: Incdec. (line 52) 49259* PRINT_OPERAND: Instruction Output. (line 95) 49260* PRINT_OPERAND_ADDRESS: Instruction Output. (line 122) 49261* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 115) 49262* probe_stack instruction pattern: Standard Names. (line 1460) 49263* probe_stack_address instruction pattern: Standard Names. (line 1453) 49264* processor functional units: Processor pipeline description. 49265 (line 6) 49266* processor functional units <1>: Processor pipeline description. 49267 (line 68) 49268* processor pipeline description: Processor pipeline description. 49269 (line 6) 49270* product: Arithmetic. (line 93) 49271* profile feedback: Profile information. 49272 (line 14) 49273* profile representation: Profile information. 49274 (line 6) 49275* PROFILE_BEFORE_PROLOGUE: Profiling. (line 34) 49276* PROFILE_HOOK: Profiling. (line 22) 49277* profiling, code generation: Profiling. (line 6) 49278* program counter: Regs and Memory. (line 358) 49279* prologue: Function Entry. (line 6) 49280* prologue instruction pattern: Standard Names. (line 1549) 49281* PROMOTE_MODE: Storage Layout. (line 87) 49282* pseudo registers: Regs and Memory. (line 9) 49283* PSImode: Machine Modes. (line 32) 49284* PTRDIFF_TYPE: Type Layout. (line 163) 49285* purge_dead_edges: Edges. (line 103) 49286* purge_dead_edges <1>: Maintaining the CFG. 49287 (line 81) 49288* push address instruction: Simple Constraints. (line 162) 49289* pushM1 instruction pattern: Standard Names. (line 253) 49290* PUSH_ARGS: Stack Arguments. (line 17) 49291* PUSH_ARGS_REVERSED: Stack Arguments. (line 25) 49292* push_operand: Machine-Independent Predicates. 49293 (line 80) 49294* push_reload: Addressing Modes. (line 176) 49295* PUSH_ROUNDING: Stack Arguments. (line 31) 49296* PUT_CODE: RTL Objects. (line 47) 49297* PUT_MODE: Machine Modes. (line 294) 49298* PUT_REG_NOTE_KIND: Insns. (line 346) 49299* PUT_SDB_...: SDB and DWARF. (line 109) 49300* QCmode: Machine Modes. (line 199) 49301* QFmode: Machine Modes. (line 57) 49302* QImode: Machine Modes. (line 25) 49303* QImode, in insn: Insns. (line 268) 49304* QQmode: Machine Modes. (line 106) 49305* qualified type: Types. (line 6) 49306* qualified type <1>: Types for C++. (line 6) 49307* querying function unit reservations: Processor pipeline description. 49308 (line 90) 49309* question mark: Multi-Alternative. (line 41) 49310* quotient: Arithmetic. (line 116) 49311* r in constraint: Simple Constraints. (line 64) 49312* RDIV_EXPR: Unary and Binary Expressions. 49313 (line 6) 49314* READONLY_DATA_SECTION_ASM_OP: Sections. (line 62) 49315* real operands: SSA Operands. (line 6) 49316* REALPART_EXPR: Unary and Binary Expressions. 49317 (line 6) 49318* REAL_ARITHMETIC: Floating Point. (line 64) 49319* REAL_CST: Constant expressions. 49320 (line 6) 49321* REAL_LIBGCC_SPEC: Driver. (line 124) 49322* REAL_NM_FILE_NAME: Macros for Initialization. 49323 (line 105) 49324* REAL_TYPE: Types. (line 6) 49325* REAL_VALUES_EQUAL: Floating Point. (line 31) 49326* REAL_VALUES_LESS: Floating Point. (line 37) 49327* REAL_VALUE_ABS: Floating Point. (line 81) 49328* REAL_VALUE_ATOF: Floating Point. (line 48) 49329* REAL_VALUE_FIX: Floating Point. (line 40) 49330* REAL_VALUE_ISINF: Floating Point. (line 58) 49331* REAL_VALUE_ISNAN: Floating Point. (line 61) 49332* REAL_VALUE_NEGATE: Floating Point. (line 78) 49333* REAL_VALUE_NEGATIVE: Floating Point. (line 55) 49334* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 147) 49335* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 145) 49336* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 146) 49337* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 143) 49338* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 144) 49339* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 142) 49340* REAL_VALUE_TYPE: Floating Point. (line 25) 49341* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 43) 49342* recognizing insns: RTL Template. (line 6) 49343* recog_data.operand: Instruction Output. (line 54) 49344* RECORD_TYPE: Types. (line 6) 49345* RECORD_TYPE <1>: Classes. (line 6) 49346* redirect_edge_and_branch: Profile information. 49347 (line 71) 49348* redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 49349 (line 90) 49350* reduc_plus_scal_M instruction pattern: Standard Names. (line 364) 49351* reduc_smax_M instruction pattern: Standard Names. (line 331) 49352* reduc_smax_scal_M instruction pattern: Standard Names. (line 354) 49353* reduc_smin_M instruction pattern: Standard Names. (line 331) 49354* reduc_smin_scal_M instruction pattern: Standard Names. (line 354) 49355* reduc_splus_M instruction pattern: Standard Names. (line 347) 49356* reduc_umax_M instruction pattern: Standard Names. (line 339) 49357* reduc_umax_scal_M instruction pattern: Standard Names. (line 359) 49358* reduc_umin_M instruction pattern: Standard Names. (line 339) 49359* reduc_umin_scal_M instruction pattern: Standard Names. (line 359) 49360* reduc_uplus_M instruction pattern: Standard Names. (line 347) 49361* reference: Types. (line 6) 49362* REFERENCE_TYPE: Types. (line 6) 49363* reg: Regs and Memory. (line 9) 49364* reg and /f: Flags. (line 94) 49365* reg and /i: Flags. (line 89) 49366* reg and /v: Flags. (line 98) 49367* reg, RTL sharing: Sharing. (line 17) 49368* register allocation order: Allocation Order. (line 6) 49369* register class definitions: Register Classes. (line 6) 49370* register class preference constraints: Class Preferences. (line 6) 49371* register pairs: Values in Registers. 49372 (line 69) 49373* Register Transfer Language (RTL): RTL. (line 6) 49374* register usage: Registers. (line 6) 49375* registers arguments: Register Arguments. (line 6) 49376* registers in constraints: Simple Constraints. (line 64) 49377* REGISTER_MOVE_COST: Costs. (line 9) 49378* REGISTER_NAMES: Instruction Output. (line 8) 49379* register_operand: Machine-Independent Predicates. 49380 (line 29) 49381* REGISTER_PREFIX: Instruction Output. (line 150) 49382* REGISTER_TARGET_PRAGMAS: Misc. (line 387) 49383* REGMODE_NATURAL_SIZE: Values in Registers. 49384 (line 49) 49385* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 172) 49386* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 150) 49387* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 160) 49388* REGNO_OK_FOR_BASE_P: Register Classes. (line 146) 49389* REGNO_OK_FOR_INDEX_P: Register Classes. (line 186) 49390* REGNO_REG_CLASS: Register Classes. (line 105) 49391* regs_ever_live: Function Entry. (line 21) 49392* regular expressions: Processor pipeline description. 49393 (line 6) 49394* regular expressions <1>: Processor pipeline description. 49395 (line 105) 49396* REG_ALLOC_ORDER: Allocation Order. (line 8) 49397* REG_BR_PRED: Insns. (line 526) 49398* REG_BR_PROB: Insns. (line 519) 49399* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 49400 (line 82) 49401* REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 49402 (line 52) 49403* REG_CC_SETTER: Insns. (line 491) 49404* REG_CC_USER: Insns. (line 491) 49405* reg_class_contents: Register Basics. (line 59) 49406* REG_CLASS_CONTENTS: Register Classes. (line 91) 49407* reg_class_for_constraint: C Constraint Interface. 49408 (line 48) 49409* REG_CLASS_NAMES: Register Classes. (line 86) 49410* REG_CROSSING_JUMP: Insns. (line 405) 49411* REG_DEAD: Insns. (line 357) 49412* REG_DEAD, REG_UNUSED: Liveness information. 49413 (line 32) 49414* REG_DEP_ANTI: Insns. (line 513) 49415* REG_DEP_OUTPUT: Insns. (line 509) 49416* REG_DEP_TRUE: Insns. (line 506) 49417* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 109) 49418* REG_EQUAL: Insns. (line 420) 49419* REG_EQUIV: Insns. (line 420) 49420* REG_EXPR: Special Accessors. (line 58) 49421* REG_FRAME_RELATED_EXPR: Insns. (line 532) 49422* REG_FUNCTION_VALUE_P: Flags. (line 89) 49423* REG_INC: Insns. (line 373) 49424* reg_label and /v: Flags. (line 65) 49425* REG_LABEL_OPERAND: Insns. (line 387) 49426* REG_LABEL_TARGET: Insns. (line 396) 49427* reg_names: Register Basics. (line 59) 49428* reg_names <1>: Instruction Output. (line 107) 49429* REG_NONNEG: Insns. (line 379) 49430* REG_NOTES: Insns. (line 321) 49431* REG_NOTE_KIND: Insns. (line 346) 49432* REG_OFFSET: Special Accessors. (line 62) 49433* REG_OK_STRICT: Addressing Modes. (line 99) 49434* REG_PARM_STACK_SPACE: Stack Arguments. (line 58) 49435* REG_PARM_STACK_SPACE, and TARGET_FUNCTION_ARG: Register Arguments. 49436 (line 56) 49437* REG_POINTER: Flags. (line 94) 49438* REG_SETJMP: Insns. (line 414) 49439* REG_UNUSED: Insns. (line 366) 49440* REG_USERVAR_P: Flags. (line 98) 49441* REG_VALUE_IN_UNWIND_CONTEXT: Frame Registers. (line 158) 49442* REG_WORDS_BIG_ENDIAN: Storage Layout. (line 35) 49443* relative costs: Costs. (line 6) 49444* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 262) 49445* reloading: RTL passes. (line 170) 49446* reload_completed: Standard Names. (line 1248) 49447* reload_in instruction pattern: Standard Names. (line 98) 49448* reload_in_progress: Standard Names. (line 57) 49449* reload_out instruction pattern: Standard Names. (line 98) 49450* remainder: Arithmetic. (line 136) 49451* remainderM3 instruction pattern: Standard Names. (line 602) 49452* reorder: GTY Options. (line 182) 49453* representation of RTL: RTL. (line 6) 49454* reservation delays: Processor pipeline description. 49455 (line 6) 49456* restore_stack_block instruction pattern: Standard Names. (line 1374) 49457* restore_stack_function instruction pattern: Standard Names. 49458 (line 1374) 49459* restore_stack_nonlocal instruction pattern: Standard Names. 49460 (line 1374) 49461* rest_of_decl_compilation: Parsing pass. (line 51) 49462* rest_of_type_compilation: Parsing pass. (line 51) 49463* RESULT_DECL: Declarations. (line 6) 49464* return: Side Effects. (line 72) 49465* return instruction pattern: Standard Names. (line 1222) 49466* return values in registers: Scalar Return. (line 6) 49467* returning aggregate values: Aggregate Return. (line 6) 49468* returning structures and unions: Interface. (line 10) 49469* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 64) 49470* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 133) 49471* RETURN_ADDR_OFFSET: Exception Handling. (line 59) 49472* RETURN_ADDR_RTX: Frame Layout. (line 122) 49473* RETURN_EXPR: Statements for C++. (line 6) 49474* RETURN_STMT: Statements for C++. (line 6) 49475* return_val: Flags. (line 274) 49476* return_val, in call_insn: Flags. (line 24) 49477* return_val, in reg: Flags. (line 89) 49478* return_val, in symbol_ref: Flags. (line 202) 49479* reverse probability: Profile information. 49480 (line 66) 49481* REVERSE_CONDITION: MODE_CC Condition Codes. 49482 (line 92) 49483* REVERSIBLE_CC_MODE: MODE_CC Condition Codes. 49484 (line 77) 49485* right rotate: Arithmetic. (line 195) 49486* right shift: Arithmetic. (line 190) 49487* rintM2 instruction pattern: Standard Names. (line 715) 49488* RISC: Processor pipeline description. 49489 (line 6) 49490* RISC <1>: Processor pipeline description. 49491 (line 223) 49492* roots, marking: GGC Roots. (line 6) 49493* rotate: Arithmetic. (line 195) 49494* rotate <1>: Arithmetic. (line 195) 49495* rotatert: Arithmetic. (line 195) 49496* rotlM3 instruction pattern: Standard Names. (line 563) 49497* rotrM3 instruction pattern: Standard Names. (line 563) 49498* roundM2 instruction pattern: Standard Names. (line 691) 49499* ROUND_DIV_EXPR: Unary and Binary Expressions. 49500 (line 6) 49501* ROUND_MOD_EXPR: Unary and Binary Expressions. 49502 (line 6) 49503* ROUND_TYPE_ALIGN: Storage Layout. (line 427) 49504* RSHIFT_EXPR: Unary and Binary Expressions. 49505 (line 6) 49506* RTL addition: Arithmetic. (line 14) 49507* RTL addition with signed saturation: Arithmetic. (line 14) 49508* RTL addition with unsigned saturation: Arithmetic. (line 14) 49509* RTL classes: RTL Classes. (line 6) 49510* RTL comparison: Arithmetic. (line 46) 49511* RTL comparison operations: Comparisons. (line 6) 49512* RTL constant expression types: Constants. (line 6) 49513* RTL constants: Constants. (line 6) 49514* RTL declarations: RTL Declarations. (line 6) 49515* RTL difference: Arithmetic. (line 38) 49516* RTL expression: RTL Objects. (line 6) 49517* RTL expressions for arithmetic: Arithmetic. (line 6) 49518* RTL format: RTL Classes. (line 72) 49519* RTL format characters: RTL Classes. (line 77) 49520* RTL function-call insns: Calls. (line 6) 49521* RTL insn template: RTL Template. (line 6) 49522* RTL integers: RTL Objects. (line 6) 49523* RTL memory expressions: Regs and Memory. (line 6) 49524* RTL object types: RTL Objects. (line 6) 49525* RTL postdecrement: Incdec. (line 6) 49526* RTL postincrement: Incdec. (line 6) 49527* RTL predecrement: Incdec. (line 6) 49528* RTL preincrement: Incdec. (line 6) 49529* RTL register expressions: Regs and Memory. (line 6) 49530* RTL representation: RTL. (line 6) 49531* RTL side effect expressions: Side Effects. (line 6) 49532* RTL strings: RTL Objects. (line 6) 49533* RTL structure sharing assumptions: Sharing. (line 6) 49534* RTL subtraction: Arithmetic. (line 38) 49535* RTL subtraction with signed saturation: Arithmetic. (line 38) 49536* RTL subtraction with unsigned saturation: Arithmetic. (line 38) 49537* RTL sum: Arithmetic. (line 14) 49538* RTL vectors: RTL Objects. (line 6) 49539* RTL_CONST_CALL_P: Flags. (line 19) 49540* RTL_CONST_OR_PURE_CALL_P: Flags. (line 29) 49541* RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 33) 49542* RTL_PURE_CALL_P: Flags. (line 24) 49543* RTX (See RTL): RTL Objects. (line 6) 49544* RTX codes, classes of: RTL Classes. (line 6) 49545* RTX_FRAME_RELATED_P: Flags. (line 107) 49546* run-time conventions: Interface. (line 6) 49547* run-time target specification: Run-time Target. (line 6) 49548* s in constraint: Simple Constraints. (line 100) 49549* SAD_EXPR: Vectors. (line 6) 49550* same_type_p: Types. (line 86) 49551* SAmode: Machine Modes. (line 150) 49552* satfractMN2 instruction pattern: Standard Names. (line 987) 49553* satfractunsMN2 instruction pattern: Standard Names. (line 1000) 49554* satisfies_constraint_M: C Constraint Interface. 49555 (line 36) 49556* sat_fract: Conversions. (line 90) 49557* SAVE_EXPR: Unary and Binary Expressions. 49558 (line 6) 49559* save_stack_block instruction pattern: Standard Names. (line 1374) 49560* save_stack_function instruction pattern: Standard Names. (line 1374) 49561* save_stack_nonlocal instruction pattern: Standard Names. (line 1374) 49562* SBSS_SECTION_ASM_OP: Sections. (line 75) 49563* Scalar evolutions: Scalar evolutions. (line 6) 49564* scalars, returned as values: Scalar Return. (line 6) 49565* SCHED_GROUP_P: Flags. (line 148) 49566* SCmode: Machine Modes. (line 199) 49567* scratch: Regs and Memory. (line 294) 49568* scratch operands: Regs and Memory. (line 294) 49569* scratch, RTL sharing: Sharing. (line 35) 49570* scratch_operand: Machine-Independent Predicates. 49571 (line 49) 49572* SDATA_SECTION_ASM_OP: Sections. (line 57) 49573* SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 127) 49574* SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 122) 49575* SDB_DEBUGGING_INFO: SDB and DWARF. (line 8) 49576* SDB_DELIM: SDB and DWARF. (line 115) 49577* SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 132) 49578* SDmode: Machine Modes. (line 88) 49579* sdot_prodM instruction pattern: Standard Names. (line 369) 49580* search options: Including Patterns. (line 47) 49581* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 391) 49582* SECONDARY_MEMORY_NEEDED: Register Classes. (line 447) 49583* SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 466) 49584* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 457) 49585* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 392) 49586* SECONDARY_RELOAD_CLASS: Register Classes. (line 390) 49587* SELECT_CC_MODE: MODE_CC Condition Codes. 49588 (line 6) 49589* sequence: Side Effects. (line 259) 49590* Sequence iterators: Sequence iterators. (line 6) 49591* set: Side Effects. (line 15) 49592* set and /f: Flags. (line 107) 49593* setmemM instruction pattern: Standard Names. (line 851) 49594* SETUP_FRAME_ADDRESSES: Frame Layout. (line 100) 49595* SET_ASM_OP: Label Output. (line 423) 49596* SET_ASM_OP <1>: Label Output. (line 434) 49597* set_attr: Tagging Insns. (line 31) 49598* set_attr_alternative: Tagging Insns. (line 49) 49599* set_bb_seq: GIMPLE sequences. (line 75) 49600* SET_DEST: Side Effects. (line 69) 49601* SET_IS_RETURN_P: Flags. (line 157) 49602* SET_LABEL_KIND: Insns. (line 146) 49603* set_optab_libfunc: Library Calls. (line 15) 49604* SET_RATIO: Costs. (line 216) 49605* SET_SRC: Side Effects. (line 69) 49606* set_thread_pointerMODE instruction pattern: Standard Names. 49607 (line 1905) 49608* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6) 49609* SET_TYPE_STRUCTURAL_EQUALITY <1>: Types. (line 81) 49610* SFmode: Machine Modes. (line 69) 49611* sharing of RTL components: Sharing. (line 6) 49612* shift: Arithmetic. (line 173) 49613* SHIFT_COUNT_TRUNCATED: Misc. (line 112) 49614* SHLIB_SUFFIX: Macros for Initialization. 49615 (line 133) 49616* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 82) 49617* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 62) 49618* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 86) 49619* SHORT_TYPE_SIZE: Type Layout. (line 15) 49620* sibcall_epilogue instruction pattern: Standard Names. (line 1581) 49621* sibling call: Edges. (line 121) 49622* SIBLING_CALL_P: Flags. (line 161) 49623* signed division: Arithmetic. (line 116) 49624* signed division with signed saturation: Arithmetic. (line 116) 49625* signed maximum: Arithmetic. (line 141) 49626* signed minimum: Arithmetic. (line 141) 49627* sign_extend: Conversions. (line 23) 49628* sign_extract: Bit-Fields. (line 8) 49629* sign_extract, canonicalization of: Insn Canonicalizations. 49630 (line 87) 49631* SIG_ATOMIC_TYPE: Type Layout. (line 214) 49632* SImode: Machine Modes. (line 37) 49633* simple constraints: Simple Constraints. (line 6) 49634* simple_return: Side Effects. (line 86) 49635* simple_return instruction pattern: Standard Names. (line 1237) 49636* sincosM3 instruction pattern: Standard Names. (line 627) 49637* sinM2 instruction pattern: Standard Names. (line 619) 49638* SIZETYPE: Type Layout. (line 153) 49639* SIZE_ASM_OP: Label Output. (line 33) 49640* SIZE_TYPE: Type Layout. (line 137) 49641* skip: GTY Options. (line 76) 49642* SLOW_BYTE_ACCESS: Costs. (line 117) 49643* SLOW_UNALIGNED_ACCESS: Costs. (line 132) 49644* smax: Arithmetic. (line 141) 49645* smin: Arithmetic. (line 141) 49646* sms, swing, software pipelining: RTL passes. (line 123) 49647* smulM3_highpart instruction pattern: Standard Names. (line 478) 49648* soft float library: Soft float library routines. 49649 (line 6) 49650* special: GTY Options. (line 245) 49651* special predicates: Predicates. (line 31) 49652* SPECS: Target Fragment. (line 191) 49653* speed of instructions: Costs. (line 6) 49654* splitting instructions: Insn Splitting. (line 6) 49655* split_block: Maintaining the CFG. 49656 (line 97) 49657* SQmode: Machine Modes. (line 114) 49658* sqrt: Arithmetic. (line 206) 49659* sqrtM2 instruction pattern: Standard Names. (line 585) 49660* square root: Arithmetic. (line 206) 49661* SSA: SSA. (line 6) 49662* ssaddM3 instruction pattern: Standard Names. (line 266) 49663* ssadM instruction pattern: Standard Names. (line 378) 49664* ssashlM3 instruction pattern: Standard Names. (line 553) 49665* SSA_NAME_DEF_STMT: SSA. (line 216) 49666* SSA_NAME_VERSION: SSA. (line 221) 49667* ssdivM3 instruction pattern: Standard Names. (line 266) 49668* ssmaddMN4 instruction pattern: Standard Names. (line 501) 49669* ssmsubMN4 instruction pattern: Standard Names. (line 525) 49670* ssmulM3 instruction pattern: Standard Names. (line 266) 49671* ssnegM2 instruction pattern: Standard Names. (line 575) 49672* sssubM3 instruction pattern: Standard Names. (line 266) 49673* ssum_widenM3 instruction pattern: Standard Names. (line 387) 49674* ss_abs: Arithmetic. (line 200) 49675* ss_ashift: Arithmetic. (line 173) 49676* ss_div: Arithmetic. (line 116) 49677* ss_minus: Arithmetic. (line 38) 49678* ss_mult: Arithmetic. (line 93) 49679* ss_neg: Arithmetic. (line 82) 49680* ss_plus: Arithmetic. (line 14) 49681* ss_truncate: Conversions. (line 43) 49682* stack arguments: Stack Arguments. (line 6) 49683* stack frame layout: Frame Layout. (line 6) 49684* stack smashing protection: Stack Smashing Protection. 49685 (line 6) 49686* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 47) 49687* STACK_BOUNDARY: Storage Layout. (line 139) 49688* STACK_CHECK_BUILTIN: Stack Checking. (line 31) 49689* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 82) 49690* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 73) 49691* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 89) 49692* STACK_CHECK_MOVING_SP: Stack Checking. (line 53) 49693* STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 45) 49694* STACK_CHECK_PROTECT: Stack Checking. (line 62) 49695* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 38) 49696* STACK_DYNAMIC_OFFSET: Frame Layout. (line 73) 49697* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 49698 (line 83) 49699* STACK_GROWS_DOWNWARD: Frame Layout. (line 8) 49700* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 89) 49701* STACK_POINTER_OFFSET: Frame Layout. (line 57) 49702* STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 49703 (line 93) 49704* STACK_POINTER_REGNUM: Frame Registers. (line 8) 49705* STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 49706 (line 83) 49707* stack_pointer_rtx: Frame Registers. (line 104) 49708* stack_protect_set instruction pattern: Standard Names. (line 1915) 49709* stack_protect_test instruction pattern: Standard Names. (line 1925) 49710* STACK_PUSH_CODE: Frame Layout. (line 16) 49711* STACK_REGS: Stack Registers. (line 19) 49712* STACK_REG_COVER_CLASS: Stack Registers. (line 22) 49713* STACK_SAVEAREA_MODE: Storage Layout. (line 443) 49714* STACK_SIZE_MODE: Storage Layout. (line 454) 49715* STACK_SLOT_ALIGNMENT: Storage Layout. (line 275) 49716* standard pattern names: Standard Names. (line 6) 49717* STANDARD_STARTFILE_PREFIX: Driver. (line 274) 49718* STANDARD_STARTFILE_PREFIX_1: Driver. (line 281) 49719* STANDARD_STARTFILE_PREFIX_2: Driver. (line 288) 49720* STARTFILE_SPEC: Driver. (line 147) 49721* STARTING_FRAME_OFFSET: Frame Layout. (line 38) 49722* STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 49723 (line 74) 49724* Statement and operand traversals: Statement and operand traversals. 49725 (line 6) 49726* Statement Sequences: Statement Sequences. 49727 (line 6) 49728* Statements: Statements. (line 6) 49729* statements: Function Properties. 49730 (line 6) 49731* statements <1>: Statements for C++. (line 6) 49732* Static profile estimation: Profile information. 49733 (line 24) 49734* static single assignment: SSA. (line 6) 49735* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 77) 49736* STATIC_CHAIN_REGNUM: Frame Registers. (line 76) 49737* stdarg.h and register arguments: Register Arguments. (line 51) 49738* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 350) 49739* STMT_EXPR: Unary and Binary Expressions. 49740 (line 6) 49741* STMT_IS_FULL_EXPR_P: Statements for C++. (line 22) 49742* storage layout: Storage Layout. (line 6) 49743* STORE_FLAG_VALUE: Misc. (line 201) 49744* store_multiple instruction pattern: Standard Names. (line 159) 49745* strcpy: Storage Layout. (line 228) 49746* STRICT_ALIGNMENT: Storage Layout. (line 325) 49747* strict_low_part: RTL Declarations. (line 9) 49748* strict_memory_address_p: Addressing Modes. (line 186) 49749* STRING_CST: Constant expressions. 49750 (line 6) 49751* STRING_POOL_ADDRESS_P: Flags. (line 165) 49752* strlenM instruction pattern: Standard Names. (line 922) 49753* structure value address: Aggregate Return. (line 6) 49754* structures, returning: Interface. (line 10) 49755* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 317) 49756* subM3 instruction pattern: Standard Names. (line 266) 49757* SUBOBJECT: Statements for C++. (line 6) 49758* SUBOBJECT_CLEANUP: Statements for C++. (line 6) 49759* subreg: Regs and Memory. (line 97) 49760* subreg and /s: Flags. (line 187) 49761* subreg and /u: Flags. (line 180) 49762* subreg and /u and /v: Flags. (line 170) 49763* subreg, in strict_low_part: RTL Declarations. (line 9) 49764* SUBREG_BYTE: Regs and Memory. (line 285) 49765* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 170) 49766* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 180) 49767* SUBREG_PROMOTED_VAR_P: Flags. (line 187) 49768* SUBREG_REG: Regs and Memory. (line 285) 49769* subst iterators in .md files: Subst Iterators. (line 6) 49770* subvM4 instruction pattern: Standard Names. (line 282) 49771* SUCCESS_EXIT_CODE: Host Misc. (line 12) 49772* SUPPORTS_INIT_PRIORITY: Macros for Initialization. 49773 (line 57) 49774* SUPPORTS_ONE_ONLY: Label Output. (line 262) 49775* SUPPORTS_WEAK: Label Output. (line 236) 49776* SWITCHABLE_TARGET: Run-time Target. (line 164) 49777* SWITCH_BODY: Statements for C++. (line 6) 49778* SWITCH_COND: Statements for C++. (line 6) 49779* SWITCH_STMT: Statements for C++. (line 6) 49780* symbolic label: Sharing. (line 20) 49781* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 117) 49782* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 99) 49783* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 92) 49784* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 113) 49785* SYMBOL_FLAG_LOCAL: Special Accessors. (line 95) 49786* SYMBOL_FLAG_SMALL: Special Accessors. (line 104) 49787* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 108) 49788* symbol_ref: Constants. (line 117) 49789* symbol_ref and /f: Flags. (line 165) 49790* symbol_ref and /i: Flags. (line 202) 49791* symbol_ref and /u: Flags. (line 10) 49792* symbol_ref and /v: Flags. (line 206) 49793* symbol_ref, RTL sharing: Sharing. (line 20) 49794* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 117) 49795* SYMBOL_REF_BLOCK: Special Accessors. (line 130) 49796* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 135) 49797* SYMBOL_REF_CONSTANT: Special Accessors. (line 78) 49798* SYMBOL_REF_DATA: Special Accessors. (line 82) 49799* SYMBOL_REF_DECL: Special Accessors. (line 67) 49800* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 99) 49801* SYMBOL_REF_FLAG: Flags. (line 206) 49802* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 277) 49803* SYMBOL_REF_FLAGS: Special Accessors. (line 86) 49804* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 92) 49805* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 113) 49806* SYMBOL_REF_LOCAL_P: Special Accessors. (line 95) 49807* SYMBOL_REF_SMALL_P: Special Accessors. (line 104) 49808* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 108) 49809* SYMBOL_REF_USED: Flags. (line 197) 49810* SYMBOL_REF_WEAK: Flags. (line 202) 49811* sync_addMODE instruction pattern: Standard Names. (line 1680) 49812* sync_andMODE instruction pattern: Standard Names. (line 1680) 49813* sync_compare_and_swapMODE instruction pattern: Standard Names. 49814 (line 1640) 49815* sync_iorMODE instruction pattern: Standard Names. (line 1680) 49816* sync_lock_releaseMODE instruction pattern: Standard Names. (line 1745) 49817* sync_lock_test_and_setMODE instruction pattern: Standard Names. 49818 (line 1719) 49819* sync_nandMODE instruction pattern: Standard Names. (line 1680) 49820* sync_new_addMODE instruction pattern: Standard Names. (line 1712) 49821* sync_new_andMODE instruction pattern: Standard Names. (line 1712) 49822* sync_new_iorMODE instruction pattern: Standard Names. (line 1712) 49823* sync_new_nandMODE instruction pattern: Standard Names. (line 1712) 49824* sync_new_subMODE instruction pattern: Standard Names. (line 1712) 49825* sync_new_xorMODE instruction pattern: Standard Names. (line 1712) 49826* sync_old_addMODE instruction pattern: Standard Names. (line 1695) 49827* sync_old_andMODE instruction pattern: Standard Names. (line 1695) 49828* sync_old_iorMODE instruction pattern: Standard Names. (line 1695) 49829* sync_old_nandMODE instruction pattern: Standard Names. (line 1695) 49830* sync_old_subMODE instruction pattern: Standard Names. (line 1695) 49831* sync_old_xorMODE instruction pattern: Standard Names. (line 1695) 49832* sync_subMODE instruction pattern: Standard Names. (line 1680) 49833* sync_xorMODE instruction pattern: Standard Names. (line 1680) 49834* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 176) 49835* SYSROOT_SUFFIX_SPEC: Driver. (line 171) 49836* t-TARGET: Target Fragment. (line 6) 49837* table jump: Basic Blocks. (line 67) 49838* tablejump instruction pattern: Standard Names. (line 1310) 49839* tag: GTY Options. (line 88) 49840* tagging insns: Tagging Insns. (line 6) 49841* tail calls: Tail Calls. (line 6) 49842* TAmode: Machine Modes. (line 158) 49843* target attributes: Target Attributes. (line 6) 49844* target description macros: Target Macros. (line 6) 49845* target functions: Target Structure. (line 6) 49846* target hooks: Target Structure. (line 6) 49847* target makefile fragment: Target Fragment. (line 6) 49848* target specifications: Run-time Target. (line 6) 49849* targetm: Target Structure. (line 6) 49850* targets, makefile: Makefile. (line 6) 49851* TARGET_ABSOLUTE_BIGGEST_ALIGNMENT: Storage Layout. (line 168) 49852* TARGET_ADDRESS_COST: Costs. (line 308) 49853* TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces. 49854 (line 43) 49855* TARGET_ADDR_SPACE_CONVERT: Named Address Spaces. 49856 (line 85) 49857* TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces. 49858 (line 61) 49859* TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces. 49860 (line 69) 49861* TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces. 49862 (line 36) 49863* TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces. 49864 (line 76) 49865* TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces. 49866 (line 50) 49867* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 402) 49868* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 809) 49869* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 1114) 49870* TARGET_ALWAYS_STRIP_DOTDOT: Driver. (line 246) 49871* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 95) 49872* TARGET_ARM_EABI_UNWINDER: Exception Region Output. 49873 (line 133) 49874* TARGET_ARRAY_MODE_SUPPORTED_P: Register Arguments. (line 345) 49875* TARGET_ASAN_SHADOW_OFFSET: Misc. (line 1142) 49876* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 9) 49877* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 7) 49878* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 8) 49879* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 10) 49880* TARGET_ASM_ASSEMBLE_UNDEFINED_DECL: Label Output. (line 203) 49881* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 273) 49882* TARGET_ASM_BYTE_OP: Data Output. (line 6) 49883* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 202) 49884* TARGET_ASM_CLOSE_PAREN: Data Output. (line 133) 49885* TARGET_ASM_CODE_END: File Framework. (line 57) 49886* TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 49887 (line 68) 49888* TARGET_ASM_DECLARE_CONSTANT_NAME: Label Output. (line 149) 49889* TARGET_ASM_DECL_END: Data Output. (line 38) 49890* TARGET_ASM_DESTRUCTOR: Macros for Initialization. 49891 (line 82) 49892* TARGET_ASM_EMIT_EXCEPT_PERSONALITY: Dispatch Tables. (line 80) 49893* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 73) 49894* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 61) 49895* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 309) 49896* TARGET_ASM_FILE_END: File Framework. (line 35) 49897* TARGET_ASM_FILE_START: File Framework. (line 8) 49898* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 16) 49899* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 29) 49900* TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 82) 49901* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 59) 49902* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 53) 49903* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 65) 49904* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 9) 49905* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 213) 49906* TARGET_ASM_FUNCTION_SECTION: File Framework. (line 121) 49907* TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework. 49908 (line 131) 49909* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 194) 49910* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 185) 49911* TARGET_ASM_INIT_SECTIONS: Sections. (line 159) 49912* TARGET_ASM_INTEGER: Data Output. (line 25) 49913* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 352) 49914* TARGET_ASM_JUMP_ALIGN_MAX_SKIP: Alignment Output. (line 21) 49915* TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. 49916 (line 34) 49917* TARGET_ASM_LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 68) 49918* TARGET_ASM_LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 53) 49919* TARGET_ASM_LTO_END: File Framework. (line 52) 49920* TARGET_ASM_LTO_START: File Framework. (line 47) 49921* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 315) 49922* TARGET_ASM_MERGEABLE_RODATA_PREFIX: Sections. (line 221) 49923* TARGET_ASM_NAMED_SECTION: File Framework. (line 113) 49924* TARGET_ASM_OPEN_PAREN: Data Output. (line 132) 49925* TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 42) 49926* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 42) 49927* TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 103) 49928* TARGET_ASM_OUTPUT_IDENT: File Framework. (line 100) 49929* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 160) 49930* TARGET_ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 91) 49931* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 162) 49932* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 207) 49933* TARGET_ASM_RELOC_RW_MASK: Sections. (line 168) 49934* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 230) 49935* TARGET_ASM_SELECT_SECTION: Sections. (line 179) 49936* TARGET_ASM_TM_CLONE_TABLE_SECTION: Sections. (line 226) 49937* TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 28) 49938* TARGET_ASM_TTYPE: Exception Region Output. 49939 (line 127) 49940* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 13) 49941* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 11) 49942* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 12) 49943* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 14) 49944* TARGET_ASM_UNIQUE_SECTION: Sections. (line 201) 49945* TARGET_ASM_UNWIND_EMIT: Dispatch Tables. (line 87) 49946* TARGET_ASM_UNWIND_EMIT_BEFORE_INSN: Dispatch Tables. (line 93) 49947* TARGET_ATOMIC_ALIGN_FOR_MODE: Misc. (line 1161) 49948* TARGET_ATOMIC_ASSIGN_EXPAND_FENV: Misc. (line 1167) 49949* TARGET_ATOMIC_TEST_AND_SET_TRUEVAL: Misc. (line 1152) 49950* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 10) 49951* TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P: Target Attributes. (line 17) 49952* TARGET_BINDS_LOCAL_P: Sections. (line 308) 49953* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 906) 49954* TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 899) 49955* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 285) 49956* TARGET_BUILTIN_CHKP_FUNCTION: Misc. (line 624) 49957* TARGET_BUILTIN_DECL: Misc. (line 603) 49958* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 261) 49959* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 107) 49960* TARGET_CALLEE_COPIES: Register Arguments. (line 127) 49961* TARGET_CALL_ARGS: Varargs. (line 123) 49962* TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS: Miscellaneous Register Hooks. 49963 (line 6) 49964* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 234) 49965* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 886) 49966* TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P: Register Classes. (line 590) 49967* TARGET_CANONICALIZE_COMPARISON: MODE_CC Condition Codes. 49968 (line 55) 49969* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 306) 49970* TARGET_CAN_ELIMINATE: Elimination. (line 73) 49971* TARGET_CAN_FOLLOW_JUMP: Misc. (line 795) 49972* TARGET_CAN_INLINE_P: Target Attributes. (line 165) 49973* TARGET_CAN_USE_DOLOOP_P: Misc. (line 759) 49974* TARGET_CASE_VALUES_THRESHOLD: Misc. (line 46) 49975* TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes. 49976 (line 120) 49977* TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 26) 49978* TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target. (line 119) 49979* TARGET_CHKP_BOUND_MODE: Misc. (line 696) 49980* TARGET_CHKP_BOUND_TYPE: Misc. (line 694) 49981* TARGET_CHKP_FUNCTION_VALUE_BOUNDS: Varargs. (line 182) 49982* TARGET_CHKP_INITIALIZE_BOUNDS: Misc. (line 702) 49983* TARGET_CHKP_MAKE_BOUNDS_CONSTANT: Misc. (line 698) 49984* TARGET_CLASS_LIKELY_SPILLED_P: Register Classes. (line 489) 49985* TARGET_CLASS_MAX_NREGS: Register Classes. (line 505) 49986* TARGET_COMMUTATIVE_P: Misc. (line 802) 49987* TARGET_COMPARE_VERSION_PRIORITY: Misc. (line 736) 49988* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 25) 49989* TARGET_CONDITIONAL_REGISTER_USAGE: Register Basics. (line 59) 49990* TARGET_CONST_ANCHOR: Misc. (line 1125) 49991* TARGET_CONST_NOT_OK_FOR_DEBUG_P: Addressing Modes. (line 230) 49992* TARGET_CONVERT_TO_TYPE: Misc. (line 1079) 49993* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 8) 49994* TARGET_CSTORE_MODE: Register Classes. (line 613) 49995* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 86) 49996* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 37) 49997* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 61) 49998* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 24) 49999* TARGET_CXX_DECL_MANGLING_CONTEXT: C++ ABI. (line 92) 50000* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 52) 50001* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 17) 50002* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 11) 50003* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 6) 50004* TARGET_CXX_IMPLICIT_EXTERN_C: Misc. (line 373) 50005* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 28) 50006* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 42) 50007* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 68) 50008* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 73) 50009* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 79) 50010* TARGET_C_PREINCLUDE: Misc. (line 361) 50011* TARGET_DEBUG_UNWIND_INFO: SDB and DWARF. (line 36) 50012* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 507) 50013* TARGET_DECLSPEC: Target Attributes. (line 72) 50014* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 446) 50015* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 129) 50016* TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 55) 50017* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 437) 50018* TARGET_DELAY_SCHED2: SDB and DWARF. (line 65) 50019* TARGET_DELAY_VARTRACK: SDB and DWARF. (line 69) 50020* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 221) 50021* TARGET_DIFFERENT_ADDR_DISPLACEMENT_P: Register Classes. (line 583) 50022* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 55) 50023* TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 16) 50024* TARGET_DWARF_FRAME_REG_MODE: Exception Region Output. 50025 (line 113) 50026* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 171) 50027* TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 50028 (line 104) 50029* TARGET_EDOM: Library Calls. (line 59) 50030* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 67) 50031* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 18) 50032* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 23) 50033* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 44) 50034* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 35) 50035* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 62) 50036* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 48) 50037* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 55) 50038* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 40) 50039* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 30) 50040* TARGET_ENCODE_SECTION_INFO: Sections. (line 251) 50041* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 50042 (line 82) 50043* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 127) 50044* TARGET_END_CALL_ARGS: Varargs. (line 137) 50045* TARGET_ENUM_VA_LIST_P: Register Arguments. (line 289) 50046* TARGET_EXCEPT_UNWIND_INFO: Exception Region Output. 50047 (line 45) 50048* TARGET_EXECUTABLE_SUFFIX: Misc. (line 860) 50049* TARGET_EXPAND_BUILTIN: Misc. (line 613) 50050* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 64) 50051* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 513) 50052* TARGET_EXPR: Unary and Binary Expressions. 50053 (line 6) 50054* TARGET_EXTRA_INCLUDES: Misc. (line 971) 50055* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 20) 50056* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 978) 50057* TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes. 50058 (line 105) 50059* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 510) 50060* target_flags: Run-time Target. (line 51) 50061* TARGET_FLAGS_REGNUM: MODE_CC Condition Codes. 50062 (line 133) 50063* TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P: Run-time Target. 50064 (line 183) 50065* TARGET_FLT_EVAL_METHOD: Type Layout. (line 110) 50066* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 301) 50067* TARGET_FOLD_BUILTIN: Misc. (line 719) 50068* TARGET_FORCE_AT_COMP_DIR: SDB and DWARF. (line 60) 50069* TARGET_FORMAT_TYPES: Misc. (line 999) 50070* TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 8) 50071* TARGET_FUNCTION_ARG: Register Arguments. (line 10) 50072* TARGET_FUNCTION_ARG_ADVANCE: Register Arguments. (line 198) 50073* TARGET_FUNCTION_ARG_BOUNDARY: Register Arguments. (line 252) 50074* TARGET_FUNCTION_ARG_ROUND_BOUNDARY: Register Arguments. (line 258) 50075* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 93) 50076* TARGET_FUNCTION_INCOMING_ARG: Register Arguments. (line 71) 50077* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 6) 50078* TARGET_FUNCTION_VALUE: Scalar Return. (line 9) 50079* TARGET_FUNCTION_VALUE_REGNO_P: Scalar Return. (line 96) 50080* TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc. (line 752) 50081* TARGET_GEN_CCMP_FIRST: Misc. (line 926) 50082* TARGET_GEN_CCMP_NEXT: Misc. (line 937) 50083* TARGET_GET_DRAP_RTX: Misc. (line 1108) 50084* TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc. (line 745) 50085* TARGET_GET_PCH_VALIDITY: PCH Target. (line 6) 50086* TARGET_GET_RAW_ARG_MODE: Aggregate Return. (line 81) 50087* TARGET_GET_RAW_RESULT_MODE: Aggregate Return. (line 76) 50088* TARGET_GIMPLE_FOLD_BUILTIN: Misc. (line 729) 50089* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 311) 50090* TARGET_HANDLE_C_OPTION: Run-time Target. (line 73) 50091* TARGET_HANDLE_OPTION: Run-time Target. (line 59) 50092* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers. 50093 (line 141) 50094* TARGET_HAS_IFUNC_P: Misc. (line 1156) 50095* TARGET_HAS_NO_HW_DIVIDE: Library Calls. (line 52) 50096* TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 920) 50097* TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 50098 (line 63) 50099* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 139) 50100* TARGET_HAVE_SRODATA_SECTION: Sections. (line 297) 50101* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 144) 50102* TARGET_HAVE_TLS: Sections. (line 317) 50103* TARGET_INIT_BUILTINS: Misc. (line 587) 50104* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output. 50105 (line 119) 50106* TARGET_INIT_LIBFUNCS: Library Calls. (line 15) 50107* TARGET_INIT_PIC_REG: Register Arguments. (line 91) 50108* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 80) 50109* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 521) 50110* TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 1032) 50111* TARGET_INVALID_BINARY_OP: Misc. (line 1051) 50112* TARGET_INVALID_CONVERSION: Misc. (line 1038) 50113* TARGET_INVALID_PARAMETER_TYPE: Misc. (line 1057) 50114* TARGET_INVALID_RETURN_TYPE: Misc. (line 1064) 50115* TARGET_INVALID_UNARY_OP: Misc. (line 1044) 50116* TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 776) 50117* TARGET_IN_SMALL_DATA_P: Sections. (line 293) 50118* TARGET_KEEP_LEAF_WHEN_PROFILED: Profiling. (line 39) 50119* TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 48) 50120* TARGET_LEGITIMATE_COMBINED_INSN: Misc. (line 790) 50121* TARGET_LEGITIMATE_CONSTANT_P: Addressing Modes. (line 213) 50122* TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 129) 50123* TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: Register Classes. (line 598) 50124* TARGET_LIBCALL_VALUE: Scalar Return. (line 65) 50125* TARGET_LIBC_HAS_FUNCTION: Library Calls. (line 77) 50126* TARGET_LIBFUNC_GNU_PREFIX: Library Calls. (line 24) 50127* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 463) 50128* TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P: Register Arguments. 50129 (line 369) 50130* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 131) 50131* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 469) 50132* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 42) 50133* TARGET_LOAD_BOUNDS_FOR_ARG: Varargs. (line 153) 50134* TARGET_LOAD_RETURNED_BOUNDS: Varargs. (line 172) 50135* TARGET_LOOP_UNROLL_ADJUST: Misc. (line 952) 50136* TARGET_LRA_P: Register Classes. (line 557) 50137* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 572) 50138* TARGET_MANGLE_ASSEMBLER_NAME: Label Output. (line 328) 50139* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 241) 50140* TARGET_MANGLE_TYPE: Storage Layout. (line 525) 50141* TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 38) 50142* TARGET_MD_ASM_CLOBBERS: Misc. (line 491) 50143* TARGET_MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 415) 50144* TARGET_MEMMODEL_CHECK: Misc. (line 1147) 50145* TARGET_MEMORY_MOVE_COST: Costs. (line 79) 50146* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 107) 50147* TARGET_MEM_REF: Storage References. (line 6) 50148* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 45) 50149* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 37) 50150* TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 32) 50151* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 90) 50152* TARGET_MODE_AFTER: Mode Switching. (line 57) 50153* TARGET_MODE_DEPENDENT_ADDRESS_P: Addressing Modes. (line 196) 50154* TARGET_MODE_EMIT: Mode Switching. (line 42) 50155* TARGET_MODE_ENTRY: Mode Switching. (line 64) 50156* TARGET_MODE_EXIT: Mode Switching. (line 71) 50157* TARGET_MODE_NEEDED: Mode Switching. (line 50) 50158* TARGET_MODE_PRIORITY: Mode Switching. (line 78) 50159* TARGET_MODE_REP_EXTENDED: Misc. (line 175) 50160* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 479) 50161* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 64) 50162* TARGET_MUST_PASS_IN_STACK, and TARGET_FUNCTION_ARG: Register Arguments. 50163 (line 56) 50164* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 408) 50165* TARGET_NO_REGISTER_ALLOCATION: SDB and DWARF. (line 73) 50166* TARGET_N_FORMAT_TYPES: Misc. (line 1004) 50167* TARGET_OBJC_CONSTRUCT_STRING_OBJECT: Run-time Target. (line 88) 50168* TARGET_OBJC_DECLARE_CLASS_DEFINITION: Run-time Target. (line 109) 50169* TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target. 50170 (line 104) 50171* TARGET_OBJECT_SUFFIX: Misc. (line 855) 50172* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 45) 50173* TARGET_OFFLOAD_OPTIONS: Misc. (line 1190) 50174* TARGET_OMIT_STRUCT_RETURN_REG: Scalar Return. (line 117) 50175* TARGET_OPTF: Misc. (line 986) 50176* TARGET_OPTION_DEFAULT_PARAMS: Run-time Target. (line 160) 50177* TARGET_OPTION_FUNCTION_VERSIONS: Target Attributes. (line 157) 50178* TARGET_OPTION_INIT_STRUCT: Run-time Target. (line 156) 50179* TARGET_OPTION_OPTIMIZATION_TABLE: Run-time Target. (line 142) 50180* TARGET_OPTION_OVERRIDE: Target Attributes. (line 144) 50181* TARGET_OPTION_POST_STREAM_IN: Target Attributes. (line 125) 50182* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 137) 50183* TARGET_OPTION_PRINT: Target Attributes. (line 131) 50184* TARGET_OPTION_RESTORE: Target Attributes. (line 119) 50185* TARGET_OPTION_SAVE: Target Attributes. (line 112) 50186* TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 100) 50187* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 41) 50188* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 1008) 50189* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 1014) 50190* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 1018) 50191* TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 126) 50192* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 115) 50193* TARGET_PCH_VALID_P: PCH Target. (line 11) 50194* TARGET_POSIX_IO: Misc. (line 516) 50195* TARGET_PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 284) 50196* TARGET_PREFERRED_RELOAD_CLASS: Register Classes. (line 213) 50197* TARGET_PREFERRED_RENAME_CLASS: Register Classes. (line 201) 50198* TARGET_PREPARE_PCH_SAVE: PCH Target. (line 34) 50199* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 144) 50200* TARGET_PROFILE_BEFORE_PROLOGUE: Sections. (line 301) 50201* TARGET_PROMOTED_TYPE: Misc. (line 1071) 50202* TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 109) 50203* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 10) 50204* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 256) 50205* TARGET_RECORD_OFFLOAD_SYMBOL: Misc. (line 1185) 50206* TARGET_REF_MAY_ALIAS_ERRNO: Register Arguments. (line 322) 50207* TARGET_REGISTER_MOVE_COST: Costs. (line 31) 50208* TARGET_REGISTER_PRIORITY: Register Classes. (line 562) 50209* TARGET_REGISTER_USAGE_LEVELING_P: Register Classes. (line 573) 50210* TARGET_RELAXED_ORDERING: Misc. (line 1023) 50211* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 708) 50212* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 15) 50213* TARGET_RETURN_IN_MSB: Scalar Return. (line 124) 50214* TARGET_RETURN_POPS_ARGS: Stack Arguments. (line 98) 50215* TARGET_RTX_COSTS: Costs. (line 277) 50216* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 329) 50217* TARGET_SCHED_ADJUST_COST: Scheduling. (line 35) 50218* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 50) 50219* TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 294) 50220* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 309) 50221* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 101) 50222* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 255) 50223* TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 172) 50224* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 156) 50225* TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 165) 50226* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 144) 50227* TARGET_SCHED_DISPATCH: Scheduling. (line 363) 50228* TARGET_SCHED_DISPATCH_DO: Scheduling. (line 368) 50229* TARGET_SCHED_EXPOSED_PIPELINE: Scheduling. (line 372) 50230* TARGET_SCHED_FINISH: Scheduling. (line 122) 50231* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 137) 50232* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling. (line 235) 50233* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling. (line 223) 50234* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 50235 (line 179) 50236* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 50237 (line 207) 50238* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling. (line 240) 50239* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling. (line 250) 50240* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling. (line 245) 50241* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling. (line 229) 50242* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 313) 50243* TARGET_SCHED_FUSION_PRIORITY: Scheduling. (line 382) 50244* TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 335) 50245* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 289) 50246* TARGET_SCHED_INIT: Scheduling. (line 111) 50247* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 161) 50248* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 153) 50249* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 129) 50250* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 298) 50251* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 11) 50252* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 267) 50253* TARGET_SCHED_MACRO_FUSION_P: Scheduling. (line 87) 50254* TARGET_SCHED_MACRO_FUSION_PAIR_P: Scheduling. (line 91) 50255* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 328) 50256* TARGET_SCHED_REASSOCIATION_WIDTH: Scheduling. (line 377) 50257* TARGET_SCHED_REORDER: Scheduling. (line 58) 50258* TARGET_SCHED_REORDER2: Scheduling. (line 75) 50259* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 305) 50260* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 347) 50261* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 354) 50262* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 316) 50263* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 22) 50264* TARGET_SECONDARY_RELOAD: Register Classes. (line 312) 50265* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 149) 50266* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 71) 50267* TARGET_SETUP_INCOMING_VARARG_BOUNDS: Varargs. (line 188) 50268* TARGET_SET_CURRENT_FUNCTION: Misc. (line 837) 50269* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 33) 50270* TARGET_SET_UP_BY_PROLOGUE: Tail Calls. (line 29) 50271* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 138) 50272* TARGET_SIMD_CLONE_ADJUST: Addressing Modes. (line 413) 50273* TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN: Addressing Modes. 50274 (line 405) 50275* TARGET_SIMD_CLONE_USABLE: Addressing Modes. (line 417) 50276* TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments. 50277 (line 377) 50278* TARGET_SPILL_CLASS: Register Classes. (line 606) 50279* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 273) 50280* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 50281 (line 16) 50282* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 50283 (line 6) 50284* TARGET_STATIC_CHAIN: Frame Registers. (line 90) 50285* TARGET_STORE_BOUNDS_FOR_ARG: Varargs. (line 163) 50286* TARGET_STORE_RETURNED_BOUNDS: Varargs. (line 177) 50287* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 107) 50288* TARGET_STRING_OBJECT_REF_TYPE_P: Run-time Target. (line 114) 50289* TARGET_STRIP_NAME_ENCODING: Sections. (line 288) 50290* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44) 50291* TARGET_SUPPORTS_SPLIT_STACK: Stack Smashing Protection. 50292 (line 25) 50293* TARGET_SUPPORTS_WEAK: Label Output. (line 244) 50294* TARGET_SUPPORTS_WIDE_INT: Misc. (line 1198) 50295* TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output. 50296 (line 98) 50297* TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 74) 50298* TARGET_TRAMPOLINE_INIT: Trampolines. (line 54) 50299* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 828) 50300* TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output. 50301 (line 72) 50302* TARGET_UNWIND_WORD_MODE: Storage Layout. (line 475) 50303* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 1104) 50304* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 123) 50305* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 53) 50306* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 248) 50307* TARGET_USE_BLOCKS_FOR_DECL_P: Addressing Modes. (line 255) 50308* TARGET_USE_BY_PIECES_INFRASTRUCTURE_P: Costs. (line 164) 50309* TARGET_USE_JCR_SECTION: Misc. (line 1086) 50310* TARGET_USE_PSEUDO_PIC_REG: Register Arguments. (line 87) 50311* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 66) 50312* TARGET_VALID_POINTER_MODE: Register Arguments. (line 317) 50313* TARGET_VECTORIZE_ADD_STMT_COST: Addressing Modes. (line 367) 50314* TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES: Addressing Modes. 50315 (line 350) 50316* TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 312) 50317* TARGET_VECTORIZE_BUILTIN_GATHER: Addressing Modes. (line 398) 50318* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 271) 50319* TARGET_VECTORIZE_BUILTIN_TM_LOAD: Addressing Modes. (line 390) 50320* TARGET_VECTORIZE_BUILTIN_TM_STORE: Addressing Modes. (line 394) 50321* TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes. 50322 (line 297) 50323* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes. 50324 (line 324) 50325* TARGET_VECTORIZE_DESTROY_COST_DATA: Addressing Modes. (line 385) 50326* TARGET_VECTORIZE_FINISH_COST: Addressing Modes. (line 378) 50327* TARGET_VECTORIZE_INIT_COST: Addressing Modes. (line 358) 50328* TARGET_VECTORIZE_PREFERRED_SIMD_MODE: Addressing Modes. (line 343) 50329* TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes. 50330 (line 333) 50331* TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes. 50332 (line 303) 50333* TARGET_VECTORIZE_VEC_PERM_CONST_OK: Addressing Modes. (line 308) 50334* TARGET_VECTOR_ALIGNMENT: Storage Layout. (line 268) 50335* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 340) 50336* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 309) 50337* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 303) 50338* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 292) 50339* TARGET_WANT_DEBUG_PUB_SECTIONS: SDB and DWARF. (line 55) 50340* TARGET_WARN_FUNC_RETURN: Tail Calls. (line 35) 50341* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 280) 50342* TCmode: Machine Modes. (line 199) 50343* TDmode: Machine Modes. (line 97) 50344* TEMPLATE_DECL: Declarations. (line 6) 50345* Temporaries: Temporaries. (line 6) 50346* termination routines: Initialization. (line 6) 50347* testing constraints: C Constraint Interface. 50348 (line 6) 50349* TEXT_SECTION_ASM_OP: Sections. (line 37) 50350* TFmode: Machine Modes. (line 101) 50351* The Language: The Language. (line 6) 50352* THEN_CLAUSE: Statements for C++. (line 6) 50353* THREAD_MODEL_SPEC: Driver. (line 162) 50354* THROW_EXPR: Unary and Binary Expressions. 50355 (line 6) 50356* THUNK_DECL: Declarations. (line 6) 50357* THUNK_DELTA: Declarations. (line 6) 50358* TImode: Machine Modes. (line 48) 50359* TImode, in insn: Insns. (line 268) 50360* TLS_COMMON_ASM_OP: Sections. (line 80) 50361* TLS_SECTION_ASM_FLAG: Sections. (line 85) 50362* tm.h macros: Target Macros. (line 6) 50363* TQFmode: Machine Modes. (line 65) 50364* TQmode: Machine Modes. (line 122) 50365* trampolines for nested functions: Trampolines. (line 6) 50366* TRAMPOLINE_ALIGNMENT: Trampolines. (line 48) 50367* TRAMPOLINE_SECTION: Trampolines. (line 39) 50368* TRAMPOLINE_SIZE: Trampolines. (line 44) 50369* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 110) 50370* trap instruction pattern: Standard Names. (line 1591) 50371* tree: Tree overview. (line 6) 50372* tree <1>: Macros and Functions. 50373 (line 6) 50374* Tree SSA: Tree SSA. (line 6) 50375* TREE_CHAIN: Macros and Functions. 50376 (line 6) 50377* TREE_CODE: Tree overview. (line 6) 50378* tree_fits_shwi_p: Constant expressions. 50379 (line 6) 50380* tree_fits_uhwi_p: Constant expressions. 50381 (line 6) 50382* TREE_INT_CST_ELT: Constant expressions. 50383 (line 6) 50384* tree_int_cst_equal: Constant expressions. 50385 (line 6) 50386* TREE_INT_CST_LOW: Constant expressions. 50387 (line 6) 50388* tree_int_cst_lt: Constant expressions. 50389 (line 6) 50390* TREE_INT_CST_NUNITS: Constant expressions. 50391 (line 6) 50392* TREE_LIST: Containers. (line 6) 50393* TREE_OPERAND: Expression trees. (line 6) 50394* TREE_PUBLIC: Function Basics. (line 6) 50395* TREE_PUBLIC <1>: Function Properties. 50396 (line 28) 50397* TREE_PURPOSE: Containers. (line 6) 50398* TREE_READONLY: Function Properties. 50399 (line 37) 50400* tree_size: Macros and Functions. 50401 (line 13) 50402* TREE_STATIC: Function Properties. 50403 (line 31) 50404* TREE_STRING_LENGTH: Constant expressions. 50405 (line 6) 50406* TREE_STRING_POINTER: Constant expressions. 50407 (line 6) 50408* TREE_THIS_VOLATILE: Function Properties. 50409 (line 34) 50410* tree_to_shwi: Constant expressions. 50411 (line 6) 50412* tree_to_uhwi: Constant expressions. 50413 (line 6) 50414* TREE_TYPE: Macros and Functions. 50415 (line 6) 50416* TREE_TYPE <1>: Types. (line 6) 50417* TREE_TYPE <2>: Working with declarations. 50418 (line 11) 50419* TREE_TYPE <3>: Expression trees. (line 6) 50420* TREE_TYPE <4>: Expression trees. (line 17) 50421* TREE_TYPE <5>: Function Basics. (line 47) 50422* TREE_TYPE <6>: Types for C++. (line 6) 50423* TREE_VALUE: Containers. (line 6) 50424* TREE_VEC: Containers. (line 6) 50425* TREE_VEC_ELT: Containers. (line 6) 50426* TREE_VEC_LENGTH: Containers. (line 6) 50427* TRULY_NOOP_TRUNCATION: Misc. (line 162) 50428* truncate: Conversions. (line 38) 50429* truncMN2 instruction pattern: Standard Names. (line 965) 50430* TRUNC_DIV_EXPR: Unary and Binary Expressions. 50431 (line 6) 50432* TRUNC_MOD_EXPR: Unary and Binary Expressions. 50433 (line 6) 50434* TRUTH_ANDIF_EXPR: Unary and Binary Expressions. 50435 (line 6) 50436* TRUTH_AND_EXPR: Unary and Binary Expressions. 50437 (line 6) 50438* TRUTH_NOT_EXPR: Unary and Binary Expressions. 50439 (line 6) 50440* TRUTH_ORIF_EXPR: Unary and Binary Expressions. 50441 (line 6) 50442* TRUTH_OR_EXPR: Unary and Binary Expressions. 50443 (line 6) 50444* TRUTH_XOR_EXPR: Unary and Binary Expressions. 50445 (line 6) 50446* TRY_BLOCK: Statements for C++. (line 6) 50447* TRY_HANDLERS: Statements for C++. (line 6) 50448* TRY_STMTS: Statements for C++. (line 6) 50449* Tuple specific accessors: Tuple specific accessors. 50450 (line 6) 50451* tuples: Tuple representation. 50452 (line 6) 50453* type: Types. (line 6) 50454* type declaration: Declarations. (line 6) 50455* TYPENAME_TYPE: Types for C++. (line 6) 50456* TYPENAME_TYPE_FULLNAME: Types. (line 6) 50457* TYPENAME_TYPE_FULLNAME <1>: Types for C++. (line 6) 50458* TYPEOF_TYPE: Types for C++. (line 6) 50459* TYPE_ALIGN: Types. (line 6) 50460* TYPE_ALIGN <1>: Types. (line 30) 50461* TYPE_ALIGN <2>: Types for C++. (line 6) 50462* TYPE_ALIGN <3>: Types for C++. (line 44) 50463* TYPE_ARG_TYPES: Types. (line 6) 50464* TYPE_ARG_TYPES <1>: Types for C++. (line 6) 50465* TYPE_ASM_OP: Label Output. (line 76) 50466* TYPE_ATTRIBUTES: Attributes. (line 24) 50467* TYPE_BINFO: Classes. (line 6) 50468* TYPE_BUILT_IN: Types for C++. (line 66) 50469* TYPE_CANONICAL: Types. (line 6) 50470* TYPE_CANONICAL <1>: Types. (line 41) 50471* TYPE_CONTEXT: Types. (line 6) 50472* TYPE_CONTEXT <1>: Types for C++. (line 6) 50473* TYPE_DECL: Declarations. (line 6) 50474* TYPE_FIELDS: Types. (line 6) 50475* TYPE_FIELDS <1>: Types for C++. (line 6) 50476* TYPE_FIELDS <2>: Classes. (line 6) 50477* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 96) 50478* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 81) 50479* TYPE_HAS_MUTABLE_P: Classes. (line 86) 50480* TYPE_HAS_NEW_OPERATOR: Classes. (line 93) 50481* TYPE_MAIN_VARIANT: Types. (line 6) 50482* TYPE_MAIN_VARIANT <1>: Types. (line 19) 50483* TYPE_MAIN_VARIANT <2>: Types for C++. (line 6) 50484* TYPE_MAX_VALUE: Types. (line 6) 50485* TYPE_METHODS: Classes. (line 6) 50486* TYPE_METHOD_BASETYPE: Types. (line 6) 50487* TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6) 50488* TYPE_MIN_VALUE: Types. (line 6) 50489* TYPE_NAME: Types. (line 6) 50490* TYPE_NAME <1>: Types. (line 33) 50491* TYPE_NAME <2>: Types for C++. (line 6) 50492* TYPE_NAME <3>: Types for C++. (line 47) 50493* TYPE_NOTHROW_P: Functions for C++. (line 154) 50494* TYPE_OFFSET_BASETYPE: Types. (line 6) 50495* TYPE_OFFSET_BASETYPE <1>: Types for C++. (line 6) 50496* TYPE_OPERAND_FMT: Label Output. (line 87) 50497* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 104) 50498* TYPE_OVERLOADS_ARROW: Classes. (line 107) 50499* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 100) 50500* TYPE_POLYMORPHIC_P: Classes. (line 77) 50501* TYPE_PRECISION: Types. (line 6) 50502* TYPE_PRECISION <1>: Types for C++. (line 6) 50503* TYPE_PTRDATAMEM_P: Types for C++. (line 6) 50504* TYPE_PTRDATAMEM_P <1>: Types for C++. (line 69) 50505* TYPE_PTRFN_P: Types for C++. (line 76) 50506* TYPE_PTROBV_P: Types for C++. (line 6) 50507* TYPE_PTROB_P: Types for C++. (line 79) 50508* TYPE_PTR_P: Types for C++. (line 72) 50509* TYPE_QUAL_CONST: Types. (line 6) 50510* TYPE_QUAL_CONST <1>: Types for C++. (line 6) 50511* TYPE_QUAL_RESTRICT: Types. (line 6) 50512* TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6) 50513* TYPE_QUAL_VOLATILE: Types. (line 6) 50514* TYPE_QUAL_VOLATILE <1>: Types for C++. (line 6) 50515* TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149) 50516* TYPE_SIZE: Types. (line 6) 50517* TYPE_SIZE <1>: Types. (line 25) 50518* TYPE_SIZE <2>: Types for C++. (line 6) 50519* TYPE_SIZE <3>: Types for C++. (line 39) 50520* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6) 50521* TYPE_STRUCTURAL_EQUALITY_P <1>: Types. (line 77) 50522* TYPE_UNQUALIFIED: Types. (line 6) 50523* TYPE_UNQUALIFIED <1>: Types for C++. (line 6) 50524* TYPE_VFIELD: Classes. (line 6) 50525* UDAmode: Machine Modes. (line 170) 50526* udiv: Arithmetic. (line 130) 50527* udivM3 instruction pattern: Standard Names. (line 266) 50528* udivmodM4 instruction pattern: Standard Names. (line 550) 50529* udot_prodM instruction pattern: Standard Names. (line 370) 50530* UDQmode: Machine Modes. (line 138) 50531* UHAmode: Machine Modes. (line 162) 50532* UHQmode: Machine Modes. (line 130) 50533* UINT16_TYPE: Type Layout. (line 220) 50534* UINT32_TYPE: Type Layout. (line 221) 50535* UINT64_TYPE: Type Layout. (line 222) 50536* UINT8_TYPE: Type Layout. (line 219) 50537* UINTMAX_TYPE: Type Layout. (line 203) 50538* UINTPTR_TYPE: Type Layout. (line 240) 50539* UINT_FAST16_TYPE: Type Layout. (line 236) 50540* UINT_FAST32_TYPE: Type Layout. (line 237) 50541* UINT_FAST64_TYPE: Type Layout. (line 238) 50542* UINT_FAST8_TYPE: Type Layout. (line 235) 50543* UINT_LEAST16_TYPE: Type Layout. (line 228) 50544* UINT_LEAST32_TYPE: Type Layout. (line 229) 50545* UINT_LEAST64_TYPE: Type Layout. (line 230) 50546* UINT_LEAST8_TYPE: Type Layout. (line 227) 50547* umaddMN4 instruction pattern: Standard Names. (line 497) 50548* umax: Arithmetic. (line 149) 50549* umaxM3 instruction pattern: Standard Names. (line 266) 50550* umin: Arithmetic. (line 149) 50551* uminM3 instruction pattern: Standard Names. (line 266) 50552* umod: Arithmetic. (line 136) 50553* umodM3 instruction pattern: Standard Names. (line 266) 50554* umsubMN4 instruction pattern: Standard Names. (line 521) 50555* umulhisi3 instruction pattern: Standard Names. (line 469) 50556* umulM3_highpart instruction pattern: Standard Names. (line 483) 50557* umulqihi3 instruction pattern: Standard Names. (line 469) 50558* umulsidi3 instruction pattern: Standard Names. (line 469) 50559* umulvM4 instruction pattern: Standard Names. (line 285) 50560* unchanging: Flags. (line 296) 50561* unchanging, in call_insn: Flags. (line 19) 50562* unchanging, in jump_insn, call_insn and insn: Flags. (line 39) 50563* unchanging, in mem: Flags. (line 134) 50564* unchanging, in subreg: Flags. (line 170) 50565* unchanging, in subreg <1>: Flags. (line 180) 50566* unchanging, in symbol_ref: Flags. (line 10) 50567* UNEQ_EXPR: Unary and Binary Expressions. 50568 (line 6) 50569* UNGE_EXPR: Unary and Binary Expressions. 50570 (line 6) 50571* UNGT_EXPR: Unary and Binary Expressions. 50572 (line 6) 50573* unions, returning: Interface. (line 10) 50574* UNION_TYPE: Types. (line 6) 50575* UNION_TYPE <1>: Classes. (line 6) 50576* UNITS_PER_WORD: Storage Layout. (line 60) 50577* UNKNOWN_TYPE: Types. (line 6) 50578* UNKNOWN_TYPE <1>: Types for C++. (line 6) 50579* UNLE_EXPR: Unary and Binary Expressions. 50580 (line 6) 50581* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 48) 50582* UNLT_EXPR: Unary and Binary Expressions. 50583 (line 6) 50584* UNORDERED_EXPR: Unary and Binary Expressions. 50585 (line 6) 50586* unshare_all_rtl: Sharing. (line 58) 50587* unsigned division: Arithmetic. (line 130) 50588* unsigned division with unsigned saturation: Arithmetic. (line 130) 50589* unsigned greater than: Comparisons. (line 64) 50590* unsigned greater than <1>: Comparisons. (line 72) 50591* unsigned less than: Comparisons. (line 68) 50592* unsigned less than <1>: Comparisons. (line 76) 50593* unsigned minimum and maximum: Arithmetic. (line 149) 50594* unsigned_fix: Conversions. (line 77) 50595* unsigned_float: Conversions. (line 62) 50596* unsigned_fract_convert: Conversions. (line 97) 50597* unsigned_sat_fract: Conversions. (line 103) 50598* unspec: Side Effects. (line 299) 50599* unspec <1>: Constant Definitions. 50600 (line 111) 50601* unspec_volatile: Side Effects. (line 299) 50602* unspec_volatile <1>: Constant Definitions. 50603 (line 99) 50604* untyped_call instruction pattern: Standard Names. (line 1207) 50605* untyped_return instruction pattern: Standard Names. (line 1270) 50606* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 50607* update_ssa: SSA. (line 74) 50608* update_stmt: Manipulating GIMPLE statements. 50609 (line 140) 50610* update_stmt <1>: SSA Operands. (line 6) 50611* update_stmt_if_modified: Manipulating GIMPLE statements. 50612 (line 143) 50613* UQQmode: Machine Modes. (line 126) 50614* usaddM3 instruction pattern: Standard Names. (line 266) 50615* usadM instruction pattern: Standard Names. (line 379) 50616* USAmode: Machine Modes. (line 166) 50617* usashlM3 instruction pattern: Standard Names. (line 553) 50618* usdivM3 instruction pattern: Standard Names. (line 266) 50619* use: Side Effects. (line 168) 50620* used: Flags. (line 314) 50621* used, in symbol_ref: Flags. (line 197) 50622* user: GTY Options. (line 252) 50623* user gc: User GC. (line 6) 50624* USER_LABEL_PREFIX: Instruction Output. (line 152) 50625* USE_C_ALLOCA: Host Misc. (line 19) 50626* USE_LD_AS_NEEDED: Driver. (line 135) 50627* USE_LOAD_POST_DECREMENT: Costs. (line 233) 50628* USE_LOAD_POST_INCREMENT: Costs. (line 228) 50629* USE_LOAD_PRE_DECREMENT: Costs. (line 243) 50630* USE_LOAD_PRE_INCREMENT: Costs. (line 238) 50631* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 193) 50632* USE_STORE_POST_DECREMENT: Costs. (line 253) 50633* USE_STORE_POST_INCREMENT: Costs. (line 248) 50634* USE_STORE_PRE_DECREMENT: Costs. (line 263) 50635* USE_STORE_PRE_INCREMENT: Costs. (line 258) 50636* USING_STMT: Statements for C++. (line 6) 50637* usmaddMN4 instruction pattern: Standard Names. (line 505) 50638* usmsubMN4 instruction pattern: Standard Names. (line 529) 50639* usmulhisi3 instruction pattern: Standard Names. (line 473) 50640* usmulM3 instruction pattern: Standard Names. (line 266) 50641* usmulqihi3 instruction pattern: Standard Names. (line 473) 50642* usmulsidi3 instruction pattern: Standard Names. (line 473) 50643* usnegM2 instruction pattern: Standard Names. (line 575) 50644* USQmode: Machine Modes. (line 134) 50645* ussubM3 instruction pattern: Standard Names. (line 266) 50646* usum_widenM3 instruction pattern: Standard Names. (line 388) 50647* us_ashift: Arithmetic. (line 173) 50648* us_minus: Arithmetic. (line 38) 50649* us_mult: Arithmetic. (line 93) 50650* us_neg: Arithmetic. (line 82) 50651* us_plus: Arithmetic. (line 14) 50652* us_truncate: Conversions. (line 48) 50653* UTAmode: Machine Modes. (line 174) 50654* UTQmode: Machine Modes. (line 142) 50655* V in constraint: Simple Constraints. (line 43) 50656* values, returned by functions: Scalar Return. (line 6) 50657* varargs implementation: Varargs. (line 6) 50658* variable: Declarations. (line 6) 50659* Variable Location Debug Information in RTL: Debug Information. 50660 (line 6) 50661* VAR_DECL: Declarations. (line 6) 50662* var_location: Debug Information. (line 14) 50663* vashlM3 instruction pattern: Standard Names. (line 567) 50664* vashrM3 instruction pattern: Standard Names. (line 567) 50665* VA_ARG_EXPR: Unary and Binary Expressions. 50666 (line 6) 50667* vcondMN instruction pattern: Standard Names. (line 213) 50668* vector: Containers. (line 6) 50669* vector operations: Vector Operations. (line 6) 50670* VECTOR_CST: Constant expressions. 50671 (line 6) 50672* VECTOR_STORE_FLAG_VALUE: Misc. (line 293) 50673* vec_concat: Vector Operations. (line 28) 50674* vec_duplicate: Vector Operations. (line 33) 50675* vec_extractM instruction pattern: Standard Names. (line 203) 50676* vec_initM instruction pattern: Standard Names. (line 208) 50677* vec_load_lanesMN instruction pattern: Standard Names. (line 165) 50678* VEC_LSHIFT_EXPR: Vectors. (line 6) 50679* vec_merge: Vector Operations. (line 11) 50680* VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6) 50681* VEC_PACK_SAT_EXPR: Vectors. (line 6) 50682* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 414) 50683* vec_pack_ssat_M instruction pattern: Standard Names. (line 407) 50684* VEC_PACK_TRUNC_EXPR: Vectors. (line 6) 50685* vec_pack_trunc_M instruction pattern: Standard Names. (line 400) 50686* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 414) 50687* vec_pack_usat_M instruction pattern: Standard Names. (line 407) 50688* vec_permM instruction pattern: Standard Names. (line 223) 50689* vec_perm_constM instruction pattern: Standard Names. (line 239) 50690* VEC_RSHIFT_EXPR: Vectors. (line 6) 50691* vec_select: Vector Operations. (line 19) 50692* vec_setM instruction pattern: Standard Names. (line 198) 50693* vec_shr_M instruction pattern: Standard Names. (line 394) 50694* vec_store_lanesMN instruction pattern: Standard Names. (line 187) 50695* vec_unpacks_float_hi_M instruction pattern: Standard Names. 50696 (line 435) 50697* vec_unpacks_float_lo_M instruction pattern: Standard Names. 50698 (line 435) 50699* vec_unpacks_hi_M instruction pattern: Standard Names. (line 421) 50700* vec_unpacks_lo_M instruction pattern: Standard Names. (line 421) 50701* vec_unpacku_float_hi_M instruction pattern: Standard Names. 50702 (line 435) 50703* vec_unpacku_float_lo_M instruction pattern: Standard Names. 50704 (line 435) 50705* vec_unpacku_hi_M instruction pattern: Standard Names. (line 428) 50706* vec_unpacku_lo_M instruction pattern: Standard Names. (line 428) 50707* VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6) 50708* VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6) 50709* VEC_UNPACK_HI_EXPR: Vectors. (line 6) 50710* VEC_UNPACK_LO_EXPR: Vectors. (line 6) 50711* VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6) 50712* VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6) 50713* vec_widen_smult_even_M instruction pattern: Standard Names. 50714 (line 444) 50715* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 444) 50716* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 444) 50717* vec_widen_smult_odd_M instruction pattern: Standard Names. (line 444) 50718* vec_widen_sshiftl_hi_M instruction pattern: Standard Names. 50719 (line 455) 50720* vec_widen_sshiftl_lo_M instruction pattern: Standard Names. 50721 (line 455) 50722* vec_widen_umult_even_M instruction pattern: Standard Names. 50723 (line 444) 50724* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 444) 50725* vec_widen_umult_lo_M instruction pattern: Standard Names. (line 444) 50726* vec_widen_umult_odd_M instruction pattern: Standard Names. (line 444) 50727* vec_widen_ushiftl_hi_M instruction pattern: Standard Names. 50728 (line 455) 50729* vec_widen_ushiftl_lo_M instruction pattern: Standard Names. 50730 (line 455) 50731* verify_flow_info: Maintaining the CFG. 50732 (line 117) 50733* virtual operands: SSA Operands. (line 6) 50734* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 50735* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 50736* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 50737* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 50738* VLIW: Processor pipeline description. 50739 (line 6) 50740* VLIW <1>: Processor pipeline description. 50741 (line 223) 50742* vlshrM3 instruction pattern: Standard Names. (line 567) 50743* VMS: Filesystem. (line 37) 50744* VMS_DEBUGGING_INFO: VMS Debug. (line 8) 50745* void: Misc. (line 685) 50746* void <1>: Misc. (line 690) 50747* VOIDmode: Machine Modes. (line 192) 50748* VOID_TYPE: Types. (line 6) 50749* volatil: Flags. (line 328) 50750* volatil, in insn, call_insn, jump_insn, code_label, jump_table_data, barrier, and note: Flags. 50751 (line 44) 50752* volatil, in label_ref and reg_label: Flags. (line 65) 50753* volatil, in mem, asm_operands, and asm_input: Flags. (line 76) 50754* volatil, in reg: Flags. (line 98) 50755* volatil, in subreg: Flags. (line 170) 50756* volatil, in subreg <1>: Flags. (line 180) 50757* volatil, in symbol_ref: Flags. (line 206) 50758* volatile memory references: Flags. (line 329) 50759* volatile, in prefetch: Flags. (line 214) 50760* voting between constraint alternatives: Class Preferences. (line 6) 50761* vrotlM3 instruction pattern: Standard Names. (line 567) 50762* vrotrM3 instruction pattern: Standard Names. (line 567) 50763* walk_dominator_tree: SSA. (line 227) 50764* walk_gimple_op: Statement and operand traversals. 50765 (line 30) 50766* walk_gimple_seq: Statement and operand traversals. 50767 (line 47) 50768* walk_gimple_stmt: Statement and operand traversals. 50769 (line 10) 50770* WCHAR_TYPE: Type Layout. (line 171) 50771* WCHAR_TYPE_SIZE: Type Layout. (line 179) 50772* which_alternative: Output Statement. (line 58) 50773* WHILE_BODY: Statements for C++. (line 6) 50774* WHILE_COND: Statements for C++. (line 6) 50775* WHILE_STMT: Statements for C++. (line 6) 50776* whopr: LTO. (line 6) 50777* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 116) 50778* window_save instruction pattern: Standard Names. (line 1562) 50779* WINT_TYPE: Type Layout. (line 184) 50780* WORDS_BIG_ENDIAN: Storage Layout. (line 28) 50781* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 215) 50782* word_mode: Machine Modes. (line 367) 50783* WORD_REGISTER_OPERATIONS: Misc. (line 53) 50784* wpa: LTO. (line 6) 50785* X in constraint: Simple Constraints. (line 122) 50786* x-HOST: Host Fragment. (line 6) 50787* XCmode: Machine Modes. (line 199) 50788* XCOFF_DEBUGGING_INFO: DBX Options. (line 12) 50789* XEXP: Accessors. (line 6) 50790* XFmode: Machine Modes. (line 82) 50791* XImode: Machine Modes. (line 54) 50792* XINT: Accessors. (line 6) 50793* xm-MACHINE.h: Filesystem. (line 6) 50794* xm-MACHINE.h <1>: Host Misc. (line 6) 50795* xor: Arithmetic. (line 168) 50796* xor, canonicalization of: Insn Canonicalizations. 50797 (line 78) 50798* xorM3 instruction pattern: Standard Names. (line 266) 50799* XSTR: Accessors. (line 6) 50800* XVEC: Accessors. (line 41) 50801* XVECEXP: Accessors. (line 48) 50802* XVECLEN: Accessors. (line 44) 50803* XWINT: Accessors. (line 6) 50804* zero_extend: Conversions. (line 28) 50805* zero_extendMN2 instruction pattern: Standard Names. (line 975) 50806* zero_extract: Bit-Fields. (line 30) 50807* zero_extract, canonicalization of: Insn Canonicalizations. 50808 (line 87) 50809 50810 50811 50812Tag Table: 50813Node: Top1789 50814Node: Contributing4971 50815Node: Portability5700 50816Node: Interface7488 50817Node: Libgcc10529 50818Node: Integer library routines12356 50819Node: Soft float library routines19324 50820Node: Decimal float library routines31262 50821Node: Fixed-point fractional library routines47020 50822Node: Exception handling routines147416 50823Node: Miscellaneous routines148523 50824Node: Languages150643 50825Node: Source Tree152190 50826Node: Configure Terms152772 50827Node: Top Level155728 50828Node: gcc Directory159215 50829Node: Subdirectories160167 50830Node: Configuration162335 50831Node: Config Fragments163055 50832Node: System Config164280 50833Node: Configuration Files165216 50834Node: Build168033 50835Node: Makefile168445 50836Ref: Makefile-Footnote-1175249 50837Ref: Makefile-Footnote-2175396 50838Node: Library Files175470 50839Node: Headers176032 50840Node: Documentation178115 50841Node: Texinfo Manuals178974 50842Node: Man Page Generation181303 50843Node: Miscellaneous Docs183216 50844Node: Front End184603 50845Node: Front End Directory188277 50846Node: Front End Config189593 50847Node: Front End Makefile192409 50848Node: Back End196177 50849Node: Testsuites199958 50850Node: Test Idioms200889 50851Node: Test Directives204287 50852Node: Directives204814 50853Node: Selectors215111 50854Node: Effective-Target Keywords216467 50855Ref: arm_neon_ok224330 50856Ref: arm_neonv2_ok224488 50857Ref: arm_neon_fp16_ok224660 50858Ref: arm_vfp3_ok225100 50859Node: Add Options235632 50860Node: Require Support236949 50861Node: Final Actions239456 50862Node: Ada Tests244621 50863Node: C Tests245952 50864Node: libgcj Tests250347 50865Node: LTO Testing251474 50866Node: gcov Testing253122 50867Node: profopt Testing256112 50868Node: compat Testing257827 50869Node: Torture Tests262067 50870Node: Options263682 50871Node: Option file format264123 50872Node: Option properties271112 50873Node: Passes284662 50874Node: Parsing pass285552 50875Node: Cilk Plus Transformation289085 50876Node: Gimplification pass292467 50877Node: Pass manager294312 50878Node: Tree SSA passes296158 50879Node: RTL passes317343 50880Node: Optimization info329647 50881Node: Dump setup330466 50882Node: Optimization groups331595 50883Node: Dump files and streams332484 50884Node: Dump output verbosity333682 50885Node: Dump types334738 50886Node: Dump examples336228 50887Node: GENERIC337574 50888Node: Deficiencies339450 50889Node: Tree overview339691 50890Node: Macros and Functions343815 50891Node: Identifiers344640 50892Node: Containers346249 50893Node: Types347406 50894Node: Declarations359480 50895Node: Working with declarations359975 50896Node: Internal structure365579 50897Node: Current structure hierarchy365963 50898Node: Adding new DECL node types368056 50899Node: Attributes372340 50900Node: Expression trees373584 50901Node: Constant expressions375338 50902Node: Storage References378634 50903Node: Unary and Binary Expressions382153 50904Node: Vectors402301 50905Node: Statements407496 50906Node: Basic Statements408028 50907Node: Blocks412535 50908Node: Statement Sequences413939 50909Node: Empty Statements414272 50910Node: Jumps414846 50911Node: Cleanups415499 50912Node: OpenMP417266 50913Node: OpenACC423111 50914Node: Functions424152 50915Node: Function Basics424623 50916Node: Function Properties428307 50917Node: Language-dependent trees431088 50918Node: C and C++ Trees431975 50919Node: Types for C++434879 50920Node: Namespaces439849 50921Node: Classes442955 50922Node: Functions for C++448032 50923Node: Statements for C++454283 50924Node: C++ Expressions463060 50925Node: Java Trees464565 50926Node: GIMPLE464678 50927Node: Tuple representation468343 50928Node: Class hierarchy of GIMPLE statements475348 50929Node: GIMPLE instruction set480351 50930Node: GIMPLE Exception Handling481983 50931Node: Temporaries483895 50932Ref: Temporaries-Footnote-1485213 50933Node: Operands485278 50934Node: Compound Expressions486039 50935Node: Compound Lvalues486273 50936Node: Conditional Expressions487035 50937Node: Logical Operators487694 50938Node: Manipulating GIMPLE statements494558 50939Node: Tuple specific accessors500494 50940Node: GIMPLE_ASM501273 50941Node: GIMPLE_ASSIGN503656 50942Node: GIMPLE_BIND508360 50943Node: GIMPLE_CALL510174 50944Node: GIMPLE_CATCH514202 50945Node: GIMPLE_COND515352 50946Node: GIMPLE_DEBUG518147 50947Node: GIMPLE_EH_FILTER521520 50948Node: GIMPLE_LABEL523083 50949Node: GIMPLE_GOTO523696 50950Node: GIMPLE_NOP524219 50951Node: GIMPLE_OMP_ATOMIC_LOAD524581 50952Node: GIMPLE_OMP_ATOMIC_STORE525577 50953Node: GIMPLE_OMP_CONTINUE526276 50954Node: GIMPLE_OMP_CRITICAL527755 50955Node: GIMPLE_OMP_FOR528749 50956Node: GIMPLE_OMP_MASTER532165 50957Node: GIMPLE_OMP_ORDERED532543 50958Node: GIMPLE_OMP_PARALLEL532937 50959Node: GIMPLE_OMP_RETURN535706 50960Node: GIMPLE_OMP_SECTION536351 50961Node: GIMPLE_OMP_SECTIONS537011 50962Node: GIMPLE_OMP_SINGLE538621 50963Node: GIMPLE_PHI539567 50964Node: GIMPLE_RESX540846 50965Node: GIMPLE_RETURN541565 50966Node: GIMPLE_SWITCH542139 50967Node: GIMPLE_TRY544014 50968Node: GIMPLE_WITH_CLEANUP_EXPR545786 50969Node: GIMPLE sequences546665 50970Node: Sequence iterators549871 50971Node: Adding a new GIMPLE statement code558328 50972Node: Statement and operand traversals559703 50973Node: Tree SSA562295 50974Node: Annotations564083 50975Node: SSA Operands564488 50976Node: SSA578562 50977Node: Alias analysis589594 50978Node: Memory model593368 50979Node: RTL594727 50980Node: RTL Objects596915 50981Node: RTL Classes600789 50982Node: Accessors605835 50983Node: Special Accessors608229 50984Node: Flags614016 50985Node: Machine Modes628780 50986Node: Constants642428 50987Node: Regs and Memory650515 50988Node: Arithmetic668403 50989Node: Comparisons678448 50990Node: Bit-Fields682740 50991Node: Vector Operations684292 50992Node: Conversions686173 50993Node: RTL Declarations690671 50994Node: Side Effects691492 50995Node: Incdec708503 50996Node: Assembler711839 50997Node: Debug Information713384 50998Node: Insns714581 50999Node: Calls740978 51000Node: Sharing743571 51001Node: Reading RTL746682 51002Node: Control Flow747673 51003Node: Basic Blocks749442 51004Node: Edges754896 51005Node: Profile information763525 51006Node: Maintaining the CFG768209 51007Node: Liveness information774071 51008Node: Loop Analysis and Representation776197 51009Node: Loop representation777307 51010Node: Loop querying784870 51011Node: Loop manipulation787686 51012Node: LCSSA790047 51013Node: Scalar evolutions792116 51014Node: loop-iv795360 51015Node: Number of iterations797282 51016Node: Dependency analysis800088 51017Node: Omega806452 51018Node: Machine Desc808028 51019Node: Overview810591 51020Node: Patterns812631 51021Node: Example816139 51022Node: RTL Template817600 51023Node: Output Template828256 51024Node: Output Statement832219 51025Node: Predicates836558 51026Node: Machine-Independent Predicates839476 51027Node: Defining Predicates844420 51028Node: Constraints850383 51029Node: Simple Constraints851852 51030Node: Multi-Alternative864692 51031Node: Class Preferences867819 51032Node: Modifiers868711 51033Node: Machine Constraints873444 51034Node: Disable Insn Alternatives931734 51035Node: Define Constraints935226 51036Node: C Constraint Interface942011 51037Node: Standard Names945160 51038Ref: shift patterns970043 51039Ref: prologue instruction pattern1015303 51040Ref: window_save instruction pattern1015796 51041Ref: epilogue instruction pattern1016073 51042Node: Pattern Ordering1033643 51043Node: Dependent Patterns1034879 51044Node: Jump Patterns1036499 51045Ref: Jump Patterns-Footnote-11038646 51046Node: Looping Patterns1038694 51047Node: Insn Canonicalizations1043423 51048Node: Expander Definitions1048008 51049Node: Insn Splitting1056222 51050Node: Including Patterns1065825 51051Node: Peephole Definitions1067609 51052Node: define_peephole1068862 51053Node: define_peephole21075192 51054Node: Insn Attributes1078258 51055Node: Defining Attributes1079440 51056Ref: define_enum_attr1082933 51057Node: Expressions1083969 51058Node: Tagging Insns1090719 51059Node: Attr Example1095072 51060Node: Insn Lengths1097445 51061Node: Constant Attributes1100853 51062Node: Mnemonic Attribute1102029 51063Node: Delay Slots1103548 51064Node: Processor pipeline description1106771 51065Ref: Processor pipeline description-Footnote-11125589 51066Node: Conditional Execution1125913 51067Node: Define Subst1129396 51068Node: Define Subst Example1131432 51069Node: Define Subst Pattern Matching1134426 51070Node: Define Subst Output Template1135652 51071Node: Constant Definitions1137722 51072Ref: define_enum1141504 51073Node: Iterators1141992 51074Node: Mode Iterators1142570 51075Node: Defining Mode Iterators1143548 51076Node: Substitutions1145042 51077Node: Examples1147284 51078Node: Code Iterators1148732 51079Node: Int Iterators1151011 51080Node: Subst Iterators1153457 51081Node: Target Macros1155149 51082Node: Target Structure1158161 51083Node: Driver1160277 51084Node: Run-time Target1179089 51085Node: Per-Function Data1188800 51086Node: Storage Layout1191564 51087Node: Type Layout1217321 51088Node: Registers1230947 51089Node: Register Basics1231921 51090Node: Allocation Order1237359 51091Node: Values in Registers1239843 51092Node: Leaf Functions1247321 51093Node: Stack Registers1250180 51094Node: Register Classes1251452 51095Node: Stack and Calling1283805 51096Node: Frame Layout1284371 51097Node: Exception Handling1295339 51098Node: Stack Checking1301549 51099Node: Frame Registers1306361 51100Node: Elimination1314626 51101Node: Stack Arguments1318854 51102Node: Register Arguments1326036 51103Node: Scalar Return1347081 51104Node: Aggregate Return1353538 51105Node: Caller Saves1357727 51106Node: Function Entry1358469 51107Node: Profiling1369561 51108Node: Tail Calls1371671 51109Node: Stack Smashing Protection1373572 51110Node: Miscellaneous Register Hooks1375235 51111Node: Varargs1376101 51112Node: Trampolines1386210 51113Node: Library Calls1392253 51114Node: Addressing Modes1396937 51115Node: Anchored Addresses1417860 51116Node: Condition Code1420503 51117Node: CC0 Condition Codes1422830 51118Node: MODE_CC Condition Codes1426076 51119Node: Costs1432884 51120Node: Scheduling1449746 51121Node: Sections1472924 51122Node: PIC1488617 51123Node: Assembler Format1490676 51124Node: File Framework1491814 51125Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1498746 51126Node: Data Output1502016 51127Node: Uninitialized Data1509962 51128Node: Label Output1514973 51129Node: Initialization1538319 51130Node: Macros for Initialization1544280 51131Node: Instruction Output1550999 51132Node: Dispatch Tables1561628 51133Node: Exception Region Output1566028 51134Node: Alignment Output1573051 51135Node: Debugging Info1577654 51136Node: All Debuggers1578324 51137Node: DBX Options1581179 51138Node: DBX Hooks1586617 51139Node: File Names and DBX1587926 51140Node: SDB and DWARF1590038 51141Node: VMS Debug1596297 51142Node: Floating Point1596884 51143Node: Mode Switching1600776 51144Node: Target Attributes1605212 51145Node: Emulated TLS1613922 51146Node: MIPS Coprocessors1617312 51147Node: PCH Target1618471 51148Node: C++ ABI1620313 51149Node: Named Address Spaces1625107 51150Node: Misc1630016 51151Ref: TARGET_SHIFT_TRUNCATION_MASK1636753 51152Node: Host Config1693410 51153Node: Host Common1694478 51154Node: Filesystem1696852 51155Node: Host Misc1700967 51156Node: Fragments1703416 51157Node: Target Fragment1704611 51158Node: Host Fragment1715239 51159Node: Collect21715479 51160Node: Header Dirs1718115 51161Node: Type Information1719538 51162Node: GTY Options1722814 51163Node: Inheritance and GTY1734466 51164Ref: Inheritance and GTY-Footnote-11736029 51165Node: User GC1736299 51166Node: GGC Roots1740038 51167Node: Files1740751 51168Node: Invoking the garbage collector1743458 51169Node: Troubleshooting1744963 51170Node: Plugins1746038 51171Node: Plugins loading1747167 51172Node: Plugin API1748037 51173Node: Plugins pass1755595 51174Node: Plugins GC1757566 51175Node: Plugins description1759284 51176Node: Plugins attr1759820 51177Node: Plugins recording1762094 51178Node: Plugins gate1762944 51179Node: Plugins tracking1763535 51180Node: Plugins building1764123 51181Node: LTO1765913 51182Node: LTO Overview1766785 51183Node: LTO object file layout1772612 51184Node: IPA1777242 51185Node: WHOPR1786207 51186Node: Internal flags1790896 51187Node: Match and Simplify1792307 51188Node: GIMPLE API1793261 51189Node: The Language1795883 51190Node: Funding1804726 51191Node: GNU Project1807225 51192Node: Copying1807874 51193Node: GNU Free Documentation License1845386 51194Node: Contributors1870507 51195Node: Option Index1909275 51196Node: Concept Index1910152 51197 51198End Tag Table 51199