1This is gccint.info, produced by makeinfo version 6.4 from gccint.texi. 2 3Copyright (C) 1988-2017 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-2017 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 6.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_min_max' 4614 Target does not support a vector min and 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 4712'vect_max_reduc' 4713 Target supports max reduction for vectors. 4714 47157.2.3.4 Thread Local Storage attributes 4716....................................... 4717 4718'tls' 4719 Target supports thread-local storage. 4720 4721'tls_native' 4722 Target supports native (rather than emulated) thread-local storage. 4723 4724'tls_runtime' 4725 Test system supports executing TLS executables. 4726 47277.2.3.5 Decimal floating point attributes 4728......................................... 4729 4730'dfp' 4731 Targets supports compiling decimal floating point extension to C. 4732 4733'dfp_nocache' 4734 Including the options used to compile this particular test, the 4735 target supports compiling decimal floating point extension to C. 4736 4737'dfprt' 4738 Test system can execute decimal floating point tests. 4739 4740'dfprt_nocache' 4741 Including the options used to compile this particular test, the 4742 test system can execute decimal floating point tests. 4743 4744'hard_dfp' 4745 Target generates decimal floating point instructions with current 4746 options. 4747 47487.2.3.6 ARM-specific attributes 4749............................... 4750 4751'arm32' 4752 ARM target generates 32-bit code. 4753 4754'arm_eabi' 4755 ARM target adheres to the ABI for the ARM Architecture. 4756 4757'arm_fp_ok' 4758 ARM target defines '__ARM_FP' using '-mfloat-abi=softfp' or 4759 equivalent options. Some multilibs may be incompatible with these 4760 options. 4761 4762'arm_hf_eabi' 4763 ARM target adheres to the VFP and Advanced SIMD Register Arguments 4764 variant of the ABI for the ARM Architecture (as selected with 4765 '-mfloat-abi=hard'). 4766 4767'arm_hard_vfp_ok' 4768 ARM target supports '-mfpu=vfp -mfloat-abi=hard'. Some multilibs 4769 may be incompatible with these options. 4770 4771'arm_iwmmxt_ok' 4772 ARM target supports '-mcpu=iwmmxt'. Some multilibs may be 4773 incompatible with this option. 4774 4775'arm_neon' 4776 ARM target supports generating NEON instructions. 4777 4778'arm_tune_string_ops_prefer_neon' 4779 Test CPU tune supports inlining string operations with NEON 4780 instructions. 4781 4782'arm_neon_hw' 4783 Test system supports executing NEON instructions. 4784 4785'arm_neonv2_hw' 4786 Test system supports executing NEON v2 instructions. 4787 4788'arm_neon_ok' 4789 ARM Target supports '-mfpu=neon -mfloat-abi=softfp' or compatible 4790 options. Some multilibs may be incompatible with these options. 4791 4792'arm_neonv2_ok' 4793 ARM Target supports '-mfpu=neon-vfpv4 -mfloat-abi=softfp' or 4794 compatible options. Some multilibs may be incompatible with these 4795 options. 4796 4797'arm_neon_fp16_ok' 4798 ARM Target supports '-mfpu=neon-fp16 -mfloat-abi=softfp' or 4799 compatible options, including '-mfp16-format=ieee' if necessary to 4800 obtain the '__fp16' type. Some multilibs may be incompatible with 4801 these options. 4802 4803'arm_neon_fp16_hw' 4804 Test system supports executing Neon half-precision float 4805 instructions. (Implies previous.) 4806 4807'arm_thumb1_ok' 4808 ARM target generates Thumb-1 code for '-mthumb'. 4809 4810'arm_thumb2_ok' 4811 ARM target generates Thumb-2 code for '-mthumb'. 4812 4813'arm_vfp_ok' 4814 ARM target supports '-mfpu=vfp -mfloat-abi=softfp'. Some multilibs 4815 may be incompatible with these options. 4816 4817'arm_vfp3_ok' 4818 ARM target supports '-mfpu=vfp3 -mfloat-abi=softfp'. Some 4819 multilibs may be incompatible with these options. 4820 4821'arm_v8_vfp_ok' 4822 ARM target supports '-mfpu=fp-armv8 -mfloat-abi=softfp'. Some 4823 multilibs may be incompatible with these options. 4824 4825'arm_v8_neon_ok' 4826 ARM target supports '-mfpu=neon-fp-armv8 -mfloat-abi=softfp'. Some 4827 multilibs may be incompatible with these options. 4828 4829'arm_v8_1a_neon_ok' 4830 ARM target supports options to generate ARMv8.1 Adv.SIMD 4831 instructions. Some multilibs may be incompatible with these 4832 options. 4833 4834'arm_v8_1a_neon_hw' 4835 ARM target supports executing ARMv8.1 Adv.SIMD instructions. Some 4836 multilibs may be incompatible with the options needed. Implies 4837 arm_v8_1a_neon_ok. 4838 4839'arm_prefer_ldrd_strd' 4840 ARM target prefers 'LDRD' and 'STRD' instructions over 'LDM' and 4841 'STM' instructions. 4842 48437.2.3.7 AArch64-specific attributes 4844................................... 4845 4846'aarch64_asm_<ext>_ok' 4847 AArch64 assembler supports the architecture extension 'ext' via the 4848 '.arch_extension' pseudo-op. 4849'aarch64_tiny' 4850 AArch64 target which generates instruction sequences for tiny 4851 memory model. 4852'aarch64_small' 4853 AArch64 target which generates instruction sequences for small 4854 memory model. 4855'aarch64_large' 4856 AArch64 target which generates instruction sequences for large 4857 memory model. 4858'aarch64_little_endian' 4859 AArch64 target which generates instruction sequences for little 4860 endian. 4861'aarch64_big_endian' 4862 AArch64 target which generates instruction sequences for big 4863 endian. 4864'aarch64_small_fpic' 4865 Binutils installed on test system supports relocation types 4866 required by -fpic for AArch64 small memory model. 4867 48687.2.3.8 MIPS-specific attributes 4869................................ 4870 4871'mips64' 4872 MIPS target supports 64-bit instructions. 4873 4874'nomips16' 4875 MIPS target does not produce MIPS16 code. 4876 4877'mips16_attribute' 4878 MIPS target can generate MIPS16 code. 4879 4880'mips_loongson' 4881 MIPS target is a Loongson-2E or -2F target using an ABI that 4882 supports the Loongson vector modes. 4883 4884'mips_newabi_large_long_double' 4885 MIPS target supports 'long double' larger than 'double' when using 4886 the new ABI. 4887 4888'mpaired_single' 4889 MIPS target supports '-mpaired-single'. 4890 48917.2.3.9 PowerPC-specific attributes 4892................................... 4893 4894'dfp_hw' 4895 PowerPC target supports executing hardware DFP instructions. 4896 4897'p8vector_hw' 4898 PowerPC target supports executing VSX instructions (ISA 2.07). 4899 4900'powerpc64' 4901 Test system supports executing 64-bit instructions. 4902 4903'powerpc_altivec' 4904 PowerPC target supports AltiVec. 4905 4906'powerpc_altivec_ok' 4907 PowerPC target supports '-maltivec'. 4908 4909'powerpc_eabi_ok' 4910 PowerPC target supports '-meabi'. 4911 4912'powerpc_elfv2' 4913 PowerPC target supports '-mabi=elfv2'. 4914 4915'powerpc_fprs' 4916 PowerPC target supports floating-point registers. 4917 4918'powerpc_hard_double' 4919 PowerPC target supports hardware double-precision floating-point. 4920 4921'powerpc_htm_ok' 4922 PowerPC target supports '-mhtm' 4923 4924'powerpc_p8vector_ok' 4925 PowerPC target supports '-mpower8-vector' 4926 4927'powerpc_ppu_ok' 4928 PowerPC target supports '-mcpu=cell'. 4929 4930'powerpc_spe' 4931 PowerPC target supports PowerPC SPE. 4932 4933'powerpc_spe_nocache' 4934 Including the options used to compile this particular test, the 4935 PowerPC target supports PowerPC SPE. 4936 4937'powerpc_spu' 4938 PowerPC target supports PowerPC SPU. 4939 4940'powerpc_vsx_ok' 4941 PowerPC target supports '-mvsx'. 4942 4943'powerpc_405_nocache' 4944 Including the options used to compile this particular test, the 4945 PowerPC target supports PowerPC 405. 4946 4947'ppc_recip_hw' 4948 PowerPC target supports executing reciprocal estimate instructions. 4949 4950'spu_auto_overlay' 4951 SPU target has toolchain that supports automatic overlay 4952 generation. 4953 4954'vmx_hw' 4955 PowerPC target supports executing AltiVec instructions. 4956 4957'vsx_hw' 4958 PowerPC target supports executing VSX instructions (ISA 2.06). 4959 49607.2.3.10 Other hardware attributes 4961.................................. 4962 4963'avx' 4964 Target supports compiling 'avx' instructions. 4965 4966'avx_runtime' 4967 Target supports the execution of 'avx' instructions. 4968 4969'cell_hw' 4970 Test system can execute AltiVec and Cell PPU instructions. 4971 4972'coldfire_fpu' 4973 Target uses a ColdFire FPU. 4974 4975'hard_float' 4976 Target supports FPU instructions. 4977 4978'non_strict_align' 4979 Target does not require strict alignment. 4980 4981'sqrt_insn' 4982 Target has a square root instruction that the compiler can 4983 generate. 4984 4985'sse' 4986 Target supports compiling 'sse' instructions. 4987 4988'sse_runtime' 4989 Target supports the execution of 'sse' instructions. 4990 4991'sse2' 4992 Target supports compiling 'sse2' instructions. 4993 4994'sse2_runtime' 4995 Target supports the execution of 'sse2' instructions. 4996 4997'sync_char_short' 4998 Target supports atomic operations on 'char' and 'short'. 4999 5000'sync_int_long' 5001 Target supports atomic operations on 'int' and 'long'. 5002 5003'ultrasparc_hw' 5004 Test environment appears to run executables on a simulator that 5005 accepts only 'EM_SPARC' executables and chokes on 'EM_SPARC32PLUS' 5006 or 'EM_SPARCV9' executables. 5007 5008'vect_cmdline_needed' 5009 Target requires a command line argument to enable a SIMD 5010 instruction set. 5011 5012'pie_copyreloc' 5013 The x86-64 target linker supports PIE with copy reloc. 5014 50157.2.3.11 Environment attributes 5016............................... 5017 5018'c' 5019 The language for the compiler under test is C. 5020 5021'c++' 5022 The language for the compiler under test is C++. 5023 5024'c99_runtime' 5025 Target provides a full C99 runtime. 5026 5027'correct_iso_cpp_string_wchar_protos' 5028 Target 'string.h' and 'wchar.h' headers provide C++ required 5029 overloads for 'strchr' etc. functions. 5030 5031'dummy_wcsftime' 5032 Target uses a dummy 'wcsftime' function that always returns zero. 5033 5034'fd_truncate' 5035 Target can truncate a file from a file descriptor, as used by 5036 'libgfortran/io/unix.c:fd_truncate'; i.e. 'ftruncate' or 'chsize'. 5037 5038'freestanding' 5039 Target is 'freestanding' as defined in section 4 of the C99 5040 standard. Effectively, it is a target which supports no extra 5041 headers or libraries other than what is considered essential. 5042 5043'init_priority' 5044 Target supports constructors with initialization priority 5045 arguments. 5046 5047'inttypes_types' 5048 Target has the basic signed and unsigned types in 'inttypes.h'. 5049 This is for tests that GCC's notions of these types agree with 5050 those in the header, as some systems have only 'inttypes.h'. 5051 5052'lax_strtofp' 5053 Target might have errors of a few ULP in string to floating-point 5054 conversion functions and overflow is not always detected correctly 5055 by those functions. 5056 5057'mempcpy' 5058 Target provides 'mempcpy' function. 5059 5060'mmap' 5061 Target supports 'mmap'. 5062 5063'newlib' 5064 Target supports Newlib. 5065 5066'pow10' 5067 Target provides 'pow10' function. 5068 5069'pthread' 5070 Target can compile using 'pthread.h' with no errors or warnings. 5071 5072'pthread_h' 5073 Target has 'pthread.h'. 5074 5075'run_expensive_tests' 5076 Expensive testcases (usually those that consume excessive amounts 5077 of CPU time) should be run on this target. This can be enabled by 5078 setting the 'GCC_TEST_RUN_EXPENSIVE' environment variable to a 5079 non-empty string. 5080 5081'simulator' 5082 Test system runs executables on a simulator (i.e. slowly) rather 5083 than hardware (i.e. fast). 5084 5085'stabs' 5086 Target supports the stabs debugging format. 5087 5088'stdint_types' 5089 Target has the basic signed and unsigned C types in 'stdint.h'. 5090 This will be obsolete when GCC ensures a working 'stdint.h' for all 5091 targets. 5092 5093'stpcpy' 5094 Target provides 'stpcpy' function. 5095 5096'trampolines' 5097 Target supports trampolines. 5098 5099'uclibc' 5100 Target supports uClibc. 5101 5102'unwrapped' 5103 Target does not use a status wrapper. 5104 5105'vxworks_kernel' 5106 Target is a VxWorks kernel. 5107 5108'vxworks_rtp' 5109 Target is a VxWorks RTP. 5110 5111'wchar' 5112 Target supports wide characters. 5113 51147.2.3.12 Other attributes 5115......................... 5116 5117'automatic_stack_alignment' 5118 Target supports automatic stack alignment. 5119 5120'cxa_atexit' 5121 Target uses '__cxa_atexit'. 5122 5123'default_packed' 5124 Target has packed layout of structure members by default. 5125 5126'fgraphite' 5127 Target supports Graphite optimizations. 5128 5129'fixed_point' 5130 Target supports fixed-point extension to C. 5131 5132'fopenacc' 5133 Target supports OpenACC via '-fopenacc'. 5134 5135'fopenmp' 5136 Target supports OpenMP via '-fopenmp'. 5137 5138'fpic' 5139 Target supports '-fpic' and '-fPIC'. 5140 5141'freorder' 5142 Target supports '-freorder-blocks-and-partition'. 5143 5144'fstack_protector' 5145 Target supports '-fstack-protector'. 5146 5147'gas' 5148 Target uses GNU 'as'. 5149 5150'gc_sections' 5151 Target supports '--gc-sections'. 5152 5153'gld' 5154 Target uses GNU 'ld'. 5155 5156'keeps_null_pointer_checks' 5157 Target keeps null pointer checks, either due to the use of 5158 '-fno-delete-null-pointer-checks' or hardwired into the target. 5159 5160'lto' 5161 Compiler has been configured to support link-time optimization 5162 (LTO). 5163 5164'naked_functions' 5165 Target supports the 'naked' function attribute. 5166 5167'named_sections' 5168 Target supports named sections. 5169 5170'natural_alignment_32' 5171 Target uses natural alignment (aligned to type size) for types of 5172 32 bits or less. 5173 5174'target_natural_alignment_64' 5175 Target uses natural alignment (aligned to type size) for types of 5176 64 bits or less. 5177 5178'nonpic' 5179 Target does not generate PIC by default. 5180 5181'pie_enabled' 5182 Target generates PIE by default. 5183 5184'pcc_bitfield_type_matters' 5185 Target defines 'PCC_BITFIELD_TYPE_MATTERS'. 5186 5187'pe_aligned_commons' 5188 Target supports '-mpe-aligned-commons'. 5189 5190'pie' 5191 Target supports '-pie', '-fpie' and '-fPIE'. 5192 5193'rdynamic' 5194 Target supports '-rdynamic'. 5195 5196'section_anchors' 5197 Target supports section anchors. 5198 5199'short_enums' 5200 Target defaults to short enums. 5201 5202'static' 5203 Target supports '-static'. 5204 5205'static_libgfortran' 5206 Target supports statically linking 'libgfortran'. 5207 5208'string_merging' 5209 Target supports merging string constants at link time. 5210 5211'ucn' 5212 Target supports compiling and assembling UCN. 5213 5214'ucn_nocache' 5215 Including the options used to compile this particular test, the 5216 target supports compiling and assembling UCN. 5217 5218'unaligned_stack' 5219 Target does not guarantee that its 'STACK_BOUNDARY' is greater than 5220 or equal to the required vector alignment. 5221 5222'vector_alignment_reachable' 5223 Vector alignment is reachable for types of 32 bits or less. 5224 5225'vector_alignment_reachable_for_64bit' 5226 Vector alignment is reachable for types of 64 bits or less. 5227 5228'wchar_t_char16_t_compatible' 5229 Target supports 'wchar_t' that is compatible with 'char16_t'. 5230 5231'wchar_t_char32_t_compatible' 5232 Target supports 'wchar_t' that is compatible with 'char32_t'. 5233 5234'comdat_group' 5235 Target uses comdat groups. 5236 52377.2.3.13 Local to tests in 'gcc.target/i386' 5238............................................ 5239 5240'3dnow' 5241 Target supports compiling '3dnow' instructions. 5242 5243'aes' 5244 Target supports compiling 'aes' instructions. 5245 5246'fma4' 5247 Target supports compiling 'fma4' instructions. 5248 5249'ms_hook_prologue' 5250 Target supports attribute 'ms_hook_prologue'. 5251 5252'pclmul' 5253 Target supports compiling 'pclmul' instructions. 5254 5255'sse3' 5256 Target supports compiling 'sse3' instructions. 5257 5258'sse4' 5259 Target supports compiling 'sse4' instructions. 5260 5261'sse4a' 5262 Target supports compiling 'sse4a' instructions. 5263 5264'ssse3' 5265 Target supports compiling 'ssse3' instructions. 5266 5267'vaes' 5268 Target supports compiling 'vaes' instructions. 5269 5270'vpclmul' 5271 Target supports compiling 'vpclmul' instructions. 5272 5273'xop' 5274 Target supports compiling 'xop' instructions. 5275 52767.2.3.14 Local to tests in 'gcc.target/spu/ea' 5277.............................................. 5278 5279'ealib' 5280 Target '__ea' library functions are available. 5281 52827.2.3.15 Local to tests in 'gcc.test-framework' 5283............................................... 5284 5285'no' 5286 Always returns 0. 5287 5288'yes' 5289 Always returns 1. 5290 5291 5292File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives 5293 52947.2.4 Features for 'dg-add-options' 5295----------------------------------- 5296 5297The supported values of FEATURE for directive 'dg-add-options' are: 5298 5299'arm_fp' 5300 '__ARM_FP' definition. Only ARM targets support this feature, and 5301 only then in certain modes; see the *note arm_fp_ok effective 5302 target keyword: arm_fp_ok. 5303 5304'arm_neon' 5305 NEON support. Only ARM targets support this feature, and only then 5306 in certain modes; see the *note arm_neon_ok effective target 5307 keyword: arm_neon_ok. 5308 5309'arm_neon_fp16' 5310 NEON and half-precision floating point support. Only ARM targets 5311 support this feature, and only then in certain modes; see the *note 5312 arm_neon_fp16_ok effective target keyword: arm_neon_fp16_ok. 5313 5314'arm_vfp3' 5315 arm vfp3 floating point support; see the *note arm_vfp3_ok 5316 effective target keyword: arm_vfp3_ok. 5317 5318'bind_pic_locally' 5319 Add the target-specific flags needed to enable functions to bind 5320 locally when using pic/PIC passes in the testsuite. 5321 5322'c99_runtime' 5323 Add the target-specific flags needed to access the C99 runtime. 5324 5325'ieee' 5326 Add the target-specific flags needed to enable full IEEE compliance 5327 mode. 5328 5329'mips16_attribute' 5330 'mips16' function attributes. Only MIPS targets support this 5331 feature, and only then in certain modes. 5332 5333'tls' 5334 Add the target-specific flags needed to use thread-local storage. 5335 5336 5337File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives 5338 53397.2.5 Variants of 'dg-require-SUPPORT' 5340-------------------------------------- 5341 5342A few of the 'dg-require' directives take arguments. 5343 5344'dg-require-iconv CODESET' 5345 Skip the test if the target does not support iconv. CODESET is the 5346 codeset to convert to. 5347 5348'dg-require-profiling PROFOPT' 5349 Skip the test if the target does not support profiling with option 5350 PROFOPT. 5351 5352'dg-require-visibility VIS' 5353 Skip the test if the target does not support the 'visibility' 5354 attribute. If VIS is '""', support for 'visibility("hidden")' is 5355 checked, for 'visibility("VIS")' otherwise. 5356 5357 The original 'dg-require' directives were defined before there was 5358support for effective-target keywords. The directives that do not take 5359arguments could be replaced with effective-target keywords. 5360 5361'dg-require-alias ""' 5362 Skip the test if the target does not support the 'alias' attribute. 5363 5364'dg-require-ascii-locale ""' 5365 Skip the test if the host does not support an ASCII locale. 5366 5367'dg-require-compat-dfp ""' 5368 Skip this test unless both compilers in a 'compat' testsuite 5369 support decimal floating point. 5370 5371'dg-require-cxa-atexit ""' 5372 Skip the test if the target does not support '__cxa_atexit'. This 5373 is equivalent to 'dg-require-effective-target cxa_atexit'. 5374 5375'dg-require-dll ""' 5376 Skip the test if the target does not support DLL attributes. 5377 5378'dg-require-fork ""' 5379 Skip the test if the target does not support 'fork'. 5380 5381'dg-require-gc-sections ""' 5382 Skip the test if the target's linker does not support the 5383 '--gc-sections' flags. This is equivalent to 5384 'dg-require-effective-target gc-sections'. 5385 5386'dg-require-host-local ""' 5387 Skip the test if the host is remote, rather than the same as the 5388 build system. Some tests are incompatible with DejaGnu's handling 5389 of remote hosts, which involves copying the source file to the host 5390 and compiling it with a relative path and "'-o a.out'". 5391 5392'dg-require-mkfifo ""' 5393 Skip the test if the target does not support 'mkfifo'. 5394 5395'dg-require-named-sections ""' 5396 Skip the test is the target does not support named sections. This 5397 is equivalent to 'dg-require-effective-target named_sections'. 5398 5399'dg-require-weak ""' 5400 Skip the test if the target does not support weak symbols. 5401 5402'dg-require-weak-override ""' 5403 Skip the test if the target does not support overriding weak 5404 symbols. 5405 5406 5407File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives 5408 54097.2.6 Commands for use in 'dg-final' 5410------------------------------------ 5411 5412The GCC testsuite defines the following directives to be used within 5413'dg-final'. 5414 54157.2.6.1 Scan a particular file 5416.............................. 5417 5418'scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 5419 Passes if REGEXP matches text in FILENAME. 5420'scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 5421 Passes if REGEXP does not match text in FILENAME. 5422'scan-module MODULE REGEXP [{ target/xfail SELECTOR }]' 5423 Passes if REGEXP matches in Fortran module MODULE. 5424 54257.2.6.2 Scan the assembly output 5426................................ 5427 5428'scan-assembler REGEX [{ target/xfail SELECTOR }]' 5429 Passes if REGEX matches text in the test's assembler output. 5430 5431'scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 5432 Passes if REGEX does not match text in the test's assembler output. 5433 5434'scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 5435 Passes if REGEX is matched exactly NUM times in the test's 5436 assembler output. 5437 5438'scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 5439 Passes if REGEX matches text in the test's demangled assembler 5440 output. 5441 5442'scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 5443 Passes if REGEX does not match text in the test's demangled 5444 assembler output. 5445 5446'scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 5447 Passes if SYMBOL is defined as a hidden symbol in the test's 5448 assembly output. 5449 5450'scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 5451 Passes if SYMBOL is not defined as a hidden symbol in the test's 5452 assembly output. 5453 54547.2.6.3 Scan optimization dump files 5455.................................... 5456 5457These commands are available for KIND of 'tree', 'rtl', and 'ipa'. 5458 5459'scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 5460 Passes if REGEX matches text in the dump file with suffix SUFFIX. 5461 5462'scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5463 Passes if REGEX does not match text in the dump file with suffix 5464 SUFFIX. 5465 5466'scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 5467 Passes if REGEX is found exactly NUM times in the dump file with 5468 suffix SUFFIX. 5469 5470'scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 5471 Passes if REGEX matches demangled text in the dump file with suffix 5472 SUFFIX. 5473 5474'scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5475 Passes if REGEX does not match demangled text in the dump file with 5476 suffix SUFFIX. 5477 54787.2.6.4 Verify that an output files exists or not 5479................................................. 5480 5481'output-exists [{ target/xfail SELECTOR }]' 5482 Passes if compiler output file exists. 5483 5484'output-exists-not [{ target/xfail SELECTOR }]' 5485 Passes if compiler output file does not exist. 5486 54877.2.6.5 Check for LTO tests 5488........................... 5489 5490'scan-symbol REGEXP [{ target/xfail SELECTOR }]' 5491 Passes if the pattern is present in the final executable. 5492 54937.2.6.6 Checks for 'gcov' tests 5494............................... 5495 5496'run-gcov SOURCEFILE' 5497 Check line counts in 'gcov' tests. 5498 5499'run-gcov [branches] [calls] { OPTS SOURCEFILE }' 5500 Check branch and/or call counts, in addition to line counts, in 5501 'gcov' tests. 5502 55037.2.6.7 Clean up generated test files 5504..................................... 5505 5506Usually the test-framework removes files that were generated during 5507testing. If a testcase, for example, uses any dumping mechanism to 5508inspect a passes dump file, the testsuite recognized the dump option 5509passed to the tool and schedules a final cleanup to remove these files. 5510 5511 There are, however, following additional cleanup directives that can be 5512used to annotate a testcase "manually". 5513'cleanup-coverage-files' 5514 Removes coverage data files generated for this test. 5515 5516'cleanup-modules "LIST-OF-EXTRA-MODULES"' 5517 Removes Fortran module files generated for this test, excluding the 5518 module names listed in keep-modules. Cleaning up module files is 5519 usually done automatically by the testsuite by looking at the 5520 source files and removing the modules after the test has been 5521 executed. 5522 module MoD1 5523 end module MoD1 5524 module Mod2 5525 end module Mod2 5526 module moD3 5527 end module moD3 5528 module mod4 5529 end module mod4 5530 ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant 5531 ! { dg-final { keep-modules "mod3 mod4" } } 5532 5533'keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"' 5534 Whitespace separated list of module names that should not be 5535 deleted by cleanup-modules. If the list of modules is empty, all 5536 modules defined in this file are kept. 5537 module maybe_unneeded 5538 end module maybe_unneeded 5539 module keep1 5540 end module keep1 5541 module keep2 5542 end module keep2 5543 ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two 5544 ! { dg-final { keep-modules "" } } ! keep all 5545 5546'dg-keep-saved-temps "LIST-OF-SUFFIXES-NOT-TO-DELETE"' 5547 Whitespace separated list of suffixes that should not be deleted 5548 automatically in a testcase that uses '-save-temps'. 5549 // { dg-options "-save-temps -fpch-preprocess -I." } 5550 int main() { return 0; } 5551 // { dg-keep-saved-temps ".s" } ! just keep assembler file 5552 // { dg-keep-saved-temps ".s" ".i" } ! ... and .i 5553 // { dg-keep-saved-temps ".ii" ".o" } ! or just .ii and .o 5554 5555'cleanup-profile-file' 5556 Removes profiling files generated for this test. 5557 5558'cleanup-repo-files' 5559 Removes files generated for this test for '-frepo'. 5560 5561 5562File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 5563 55647.3 Ada Language Testsuites 5565=========================== 5566 5567The Ada testsuite includes executable tests from the ACATS testsuite, 5568publicly available at <http://www.ada-auth.org/acats.html>. 5569 5570 These tests are integrated in the GCC testsuite in the 'ada/acats' 5571directory, and enabled automatically when running 'make check', assuming 5572the Ada language has been enabled when configuring GCC. 5573 5574 You can also run the Ada testsuite independently, using 'make 5575check-ada', or run a subset of the tests by specifying which chapter to 5576run, e.g.: 5577 5578 $ make check-ada CHAPTERS="c3 c9" 5579 5580 The tests are organized by directory, each directory corresponding to a 5581chapter of the Ada Reference Manual. So for example, 'c9' corresponds 5582to chapter 9, which deals with tasking features of the language. 5583 5584 There is also an extra chapter called 'gcc' containing a template for 5585creating new executable tests, although this is deprecated in favor of 5586the 'gnat.dg' testsuite. 5587 5588 The tests are run using two 'sh' scripts: 'run_acats' and 'run_all.sh'. 5589To run the tests using a simulator or a cross target, see the small 5590customization section at the top of 'run_all.sh'. 5591 5592 These tests are run using the build tree: they can be run without doing 5593a 'make install'. 5594 5595 5596File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites 5597 55987.4 C Language Testsuites 5599========================= 5600 5601GCC contains the following C language testsuites, in the 'gcc/testsuite' 5602directory: 5603 5604'gcc.dg' 5605 This contains tests of particular features of the C compiler, using 5606 the more modern 'dg' harness. Correctness tests for various 5607 compiler features should go here if possible. 5608 5609 Magic comments determine whether the file is preprocessed, 5610 compiled, linked or run. In these tests, error and warning message 5611 texts are compared against expected texts or regular expressions 5612 given in comments. These tests are run with the options '-ansi 5613 -pedantic' unless other options are given in the test. Except as 5614 noted below they are not run with multiple optimization options. 5615'gcc.dg/compat' 5616 This subdirectory contains tests for binary compatibility using 5617 'lib/compat.exp', which in turn uses the language-independent 5618 support (*note Support for testing binary compatibility: compat 5619 Testing.). 5620'gcc.dg/cpp' 5621 This subdirectory contains tests of the preprocessor. 5622'gcc.dg/debug' 5623 This subdirectory contains tests for debug formats. Tests in this 5624 subdirectory are run for each debug format that the compiler 5625 supports. 5626'gcc.dg/format' 5627 This subdirectory contains tests of the '-Wformat' format checking. 5628 Tests in this directory are run with and without '-DWIDE'. 5629'gcc.dg/noncompile' 5630 This subdirectory contains tests of code that should not compile 5631 and does not need any special compilation options. They are run 5632 with multiple optimization options, since sometimes invalid code 5633 crashes the compiler with optimization. 5634'gcc.dg/special' 5635 FIXME: describe this. 5636 5637'gcc.c-torture' 5638 This contains particular code fragments which have historically 5639 broken easily. These tests are run with multiple optimization 5640 options, so tests for features which only break at some 5641 optimization levels belong here. This also contains tests to check 5642 that certain optimizations occur. It might be worthwhile to 5643 separate the correctness tests cleanly from the code quality tests, 5644 but it hasn't been done yet. 5645 5646'gcc.c-torture/compat' 5647 FIXME: describe this. 5648 5649 This directory should probably not be used for new tests. 5650'gcc.c-torture/compile' 5651 This testsuite contains test cases that should compile, but do not 5652 need to link or run. These test cases are compiled with several 5653 different combinations of optimization options. All warnings are 5654 disabled for these test cases, so this directory is not suitable if 5655 you wish to test for the presence or absence of compiler warnings. 5656 While special options can be set, and tests disabled on specific 5657 platforms, by the use of '.x' files, mostly these test cases should 5658 not contain platform dependencies. FIXME: discuss how defines such 5659 as 'NO_LABEL_VALUES' and 'STACK_SIZE' are used. 5660'gcc.c-torture/execute' 5661 This testsuite contains test cases that should compile, link and 5662 run; otherwise the same comments as for 'gcc.c-torture/compile' 5663 apply. 5664'gcc.c-torture/execute/ieee' 5665 This contains tests which are specific to IEEE floating point. 5666'gcc.c-torture/unsorted' 5667 FIXME: describe this. 5668 5669 This directory should probably not be used for new tests. 5670'gcc.misc-tests' 5671 This directory contains C tests that require special handling. 5672 Some of these tests have individual expect files, and others share 5673 special-purpose expect files: 5674 5675 'bprob*.c' 5676 Test '-fbranch-probabilities' using 5677 'gcc.misc-tests/bprob.exp', which in turn uses the generic, 5678 language-independent framework (*note Support for testing 5679 profile-directed optimizations: profopt Testing.). 5680 5681 'gcov*.c' 5682 Test 'gcov' output using 'gcov.exp', which in turn uses the 5683 language-independent support (*note Support for testing gcov: 5684 gcov Testing.). 5685 5686 'i386-pf-*.c' 5687 Test i386-specific support for data prefetch using 5688 'i386-prefetch.exp'. 5689 5690'gcc.test-framework' 5691 'dg-*.c' 5692 Test the testsuite itself using 5693 'gcc.test-framework/test-framework.exp'. 5694 5695 FIXME: merge in 'testsuite/README.gcc' and discuss the format of test 5696cases and magic comments more. 5697 5698 5699File: gccint.info, Node: libgcj Tests, Next: LTO Testing, Prev: C Tests, Up: Testsuites 5700 57017.5 The Java library testsuites. 5702================================ 5703 5704Runtime tests are executed via 'make check' in the 5705'TARGET/libjava/testsuite' directory in the build tree. Additional 5706runtime tests can be checked into this testsuite. 5707 5708 Regression testing of the core packages in libgcj is also covered by 5709the Mauve testsuite. The Mauve Project develops tests for the Java 5710Class Libraries. These tests are run as part of libgcj testing by 5711placing the Mauve tree within the libjava testsuite sources at 5712'libjava/testsuite/libjava.mauve/mauve', or by specifying the location 5713of that tree when invoking 'make', as in 'make MAUVEDIR=~/mauve check'. 5714 5715 To detect regressions, a mechanism in 'mauve.exp' compares the failures 5716for a test run against the list of expected failures in 5717'libjava/testsuite/libjava.mauve/xfails' from the source hierarchy. 5718Update this file when adding new failing tests to Mauve, or when fixing 5719bugs in libgcj that had caused Mauve test failures. 5720 5721 We encourage developers to contribute test cases to Mauve. 5722 5723 5724File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: libgcj Tests, Up: Testsuites 5725 57267.6 Support for testing link-time optimizations 5727=============================================== 5728 5729Tests for link-time optimizations usually require multiple source files 5730that are compiled separately, perhaps with different sets of options. 5731There are several special-purpose test directives used for these tests. 5732 5733'{ dg-lto-do DO-WHAT-KEYWORD }' 5734 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 5735 is executed. It is one of: 5736 5737 'assemble' 5738 Compile with '-c' to produce a relocatable object file. 5739 'link' 5740 Compile, assemble, and link to produce an executable file. 5741 'run' 5742 Produce and run an executable file, which is expected to 5743 return an exit code of 0. 5744 5745 The default is 'assemble'. That can be overridden for a set of 5746 tests by redefining 'dg-do-what-default' within the '.exp' file for 5747 those tests. 5748 5749 Unlike 'dg-do', 'dg-lto-do' does not support an optional 'target' 5750 or 'xfail' list. Use 'dg-skip-if', 'dg-xfail-if', or 5751 'dg-xfail-run-if'. 5752 5753'{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}' 5754 This directive provides a list of one or more sets of compiler 5755 options to override LTO_OPTIONS. Each test will be compiled and 5756 run with each of these sets of options. 5757 5758'{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}' 5759 This directive adds OPTIONS to the linker options used. 5760 5761'{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}' 5762 This directive removes OPTIONS from the set of linker options used. 5763 5764 5765File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites 5766 57677.7 Support for testing 'gcov' 5768============================== 5769 5770Language-independent support for testing 'gcov', and for checking that 5771branch profiling produces expected values, is provided by the expect 5772file 'lib/gcov.exp'. 'gcov' tests also rely on procedures in 5773'lib/gcc-dg.exp' to compile and run the test program. A typical 'gcov' 5774test contains the following DejaGnu commands within comments: 5775 5776 { dg-options "-fprofile-arcs -ftest-coverage" } 5777 { dg-do run { target native } } 5778 { dg-final { run-gcov sourcefile } } 5779 5780 Checks of 'gcov' output can include line counts, branch percentages, 5781and call return percentages. All of these checks are requested via 5782commands that appear in comments in the test's source file. Commands to 5783check line counts are processed by default. Commands to check branch 5784percentages and call return percentages are processed if the 'run-gcov' 5785command has arguments 'branches' or 'calls', respectively. For example, 5786the following specifies checking both, as well as passing '-b' to 5787'gcov': 5788 5789 { dg-final { run-gcov branches calls { -b sourcefile } } } 5790 5791 A line count command appears within a comment on the source line that 5792is expected to get the specified count and has the form 'count(CNT)'. A 5793test should only check line counts for lines that will get the same 5794count for any architecture. 5795 5796 Commands to check branch percentages ('branch') and call return 5797percentages ('returns') are very similar to each other. A beginning 5798command appears on or before the first of a range of lines that will 5799report the percentage, and the ending command follows that range of 5800lines. The beginning command can include a list of percentages, all of 5801which are expected to be found within the range. A range is terminated 5802by the next command of the same kind. A command 'branch(end)' or 5803'returns(end)' marks the end of a range without starting a new one. For 5804example: 5805 5806 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 5807 /* branch(end) */ 5808 foo (i, j); 5809 5810 For a call return percentage, the value specified is the percentage of 5811calls reported to return. For a branch percentage, the value is either 5812the expected percentage or 100 minus that value, since the direction of 5813a branch can differ depending on the target or the optimization level. 5814 5815 Not all branches and calls need to be checked. A test should not check 5816for branches that might be optimized away or replaced with predicated 5817instructions. Don't check for calls inserted by the compiler or ones 5818that might be inlined or optimized away. 5819 5820 A single test can check for combinations of line counts, branch 5821percentages, and call return percentages. The command to check a line 5822count must appear on the line that will report that count, but commands 5823to check branch percentages and call return percentages can bracket the 5824lines that report them. 5825 5826 5827File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 5828 58297.8 Support for testing profile-directed optimizations 5830====================================================== 5831 5832The file 'profopt.exp' provides language-independent support for 5833checking correct execution of a test built with profile-directed 5834optimization. This testing requires that a test program be built and 5835executed twice. The first time it is compiled to generate profile data, 5836and the second time it is compiled to use the data that was generated 5837during the first execution. The second execution is to verify that the 5838test produces the expected results. 5839 5840 To check that the optimization actually generated better code, a test 5841can be built and run a third time with normal optimizations to verify 5842that the performance is better with the profile-directed optimizations. 5843'profopt.exp' has the beginnings of this kind of support. 5844 5845 'profopt.exp' provides generic support for profile-directed 5846optimizations. Each set of tests that uses it provides information 5847about a specific optimization: 5848 5849'tool' 5850 tool being tested, e.g., 'gcc' 5851 5852'profile_option' 5853 options used to generate profile data 5854 5855'feedback_option' 5856 options used to optimize using that profile data 5857 5858'prof_ext' 5859 suffix of profile data files 5860 5861'PROFOPT_OPTIONS' 5862 list of options with which to run each test, similar to the lists 5863 for torture tests 5864 5865'{ dg-final-generate { LOCAL-DIRECTIVE } }' 5866 This directive is similar to 'dg-final', but the LOCAL-DIRECTIVE is 5867 run after the generation of profile data. 5868 5869'{ dg-final-use { LOCAL-DIRECTIVE } }' 5870 The LOCAL-DIRECTIVE is run after the profile data have been used. 5871 5872 5873File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites 5874 58757.9 Support for testing binary compatibility 5876============================================ 5877 5878The file 'compat.exp' provides language-independent support for binary 5879compatibility testing. It supports testing interoperability of two 5880compilers that follow the same ABI, or of multiple sets of compiler 5881options that should not affect binary compatibility. It is intended to 5882be used for testsuites that complement ABI testsuites. 5883 5884 A test supported by this framework has three parts, each in a separate 5885source file: a main program and two pieces that interact with each other 5886to split up the functionality being tested. 5887 5888'TESTNAME_main.SUFFIX' 5889 Contains the main program, which calls a function in file 5890 'TESTNAME_x.SUFFIX'. 5891 5892'TESTNAME_x.SUFFIX' 5893 Contains at least one call to a function in 'TESTNAME_y.SUFFIX'. 5894 5895'TESTNAME_y.SUFFIX' 5896 Shares data with, or gets arguments from, 'TESTNAME_x.SUFFIX'. 5897 5898 Within each test, the main program and one functional piece are 5899compiled by the GCC under test. The other piece can be compiled by an 5900alternate compiler. If no alternate compiler is specified, then all 5901three source files are all compiled by the GCC under test. You can 5902specify pairs of sets of compiler options. The first element of such a 5903pair specifies options used with the GCC under test, and the second 5904element of the pair specifies options used with the alternate compiler. 5905Each test is compiled with each pair of options. 5906 5907 'compat.exp' defines default pairs of compiler options. These can be 5908overridden by defining the environment variable 'COMPAT_OPTIONS' as: 5909 5910 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 5911 ...[list {TSTN} {ALTN}]]" 5912 5913 where TSTI and ALTI are lists of options, with TSTI used by the 5914compiler under test and ALTI used by the alternate compiler. For 5915example, with '[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 5916the test is first built with '-g -O0' by the compiler under test and 5917with '-O3' by the alternate compiler. The test is built a second time 5918using '-fpic' by the compiler under test and '-fPIC -O2' by the 5919alternate compiler. 5920 5921 An alternate compiler is specified by defining an environment variable 5922to be the full pathname of an installed compiler; for C define 5923'ALT_CC_UNDER_TEST', and for C++ define 'ALT_CXX_UNDER_TEST'. These 5924will be written to the 'site.exp' file used by DejaGnu. The default is 5925to build each test with the compiler under test using the first of each 5926pair of compiler options from 'COMPAT_OPTIONS'. When 5927'ALT_CC_UNDER_TEST' or 'ALT_CXX_UNDER_TEST' is 'same', each test is 5928built using the compiler under test but with combinations of the options 5929from 'COMPAT_OPTIONS'. 5930 5931 To run only the C++ compatibility suite using the compiler under test 5932and another version of GCC using specific compiler options, do the 5933following from 'OBJDIR/gcc': 5934 5935 rm site.exp 5936 make -k \ 5937 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 5938 COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \ 5939 check-c++ \ 5940 RUNTESTFLAGS="compat.exp" 5941 5942 A test that fails when the source files are compiled with different 5943compilers, but passes when the files are compiled with the same 5944compiler, demonstrates incompatibility of the generated code or runtime 5945support. A test that fails for the alternate compiler but passes for 5946the compiler under test probably tests for a bug that was fixed in the 5947compiler under test but is present in the alternate compiler. 5948 5949 The binary compatibility tests support a small number of test framework 5950commands that appear within comments in a test file. 5951 5952'dg-require-*' 5953 These commands can be used in 'TESTNAME_main.SUFFIX' to skip the 5954 test if specific support is not available on the target. 5955 5956'dg-options' 5957 The specified options are used for compiling this particular source 5958 file, appended to the options from 'COMPAT_OPTIONS'. When this 5959 command appears in 'TESTNAME_main.SUFFIX' the options are also used 5960 to link the test program. 5961 5962'dg-xfail-if' 5963 This command can be used in a secondary source file to specify that 5964 compilation is expected to fail for particular options on 5965 particular targets. 5966 5967 5968File: gccint.info, Node: Torture Tests, Prev: compat Testing, Up: Testsuites 5969 59707.10 Support for torture testing using multiple options 5971======================================================= 5972 5973Throughout the compiler testsuite there are several directories whose 5974tests are run multiple times, each with a different set of options. 5975These are known as torture tests. 'lib/torture-options.exp' defines 5976procedures to set up these lists: 5977 5978'torture-init' 5979 Initialize use of torture lists. 5980'set-torture-options' 5981 Set lists of torture options to use for tests with and without 5982 loops. Optionally combine a set of torture options with a set of 5983 other options, as is done with Objective-C runtime options. 5984'torture-finish' 5985 Finalize use of torture lists. 5986 5987 The '.exp' file for a set of tests that use torture options must 5988include calls to these three procedures if: 5989 5990 * It calls 'gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS. 5991 5992 * It calls ${TOOL}'-torture' or ${TOOL}'-torture-execute', where TOOL 5993 is 'c', 'fortran', or 'objc'. 5994 5995 * It calls 'dg-pch'. 5996 5997 It is not necessary for a '.exp' file that calls 'gcc-dg-runtest' to 5998call the torture procedures if the tests should use the list in 5999DG_TORTURE_OPTIONS defined in 'gcc-dg.exp'. 6000 6001 Most uses of torture options can override the default lists by defining 6002TORTURE_OPTIONS or add to the default list by defining 6003ADDITIONAL_TORTURE_OPTIONS. Define these in a '.dejagnurc' file or add 6004them to the 'site.exp' file; for example 6005 6006 set ADDITIONAL_TORTURE_OPTIONS [list \ 6007 { -O2 -ftree-loop-linear } \ 6008 { -O2 -fpeel-loops } ] 6009 6010 6011File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top 6012 60138 Option specification files 6014**************************** 6015 6016Most GCC command-line options are described by special option definition 6017files, the names of which conventionally end in '.opt'. This chapter 6018describes the format of these files. 6019 6020* Menu: 6021 6022* Option file format:: The general layout of the files 6023* Option properties:: Supported option properties 6024 6025 6026File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 6027 60288.1 Option file format 6029====================== 6030 6031Option files are a simple list of records in which each field occupies 6032its own line and in which the records themselves are separated by blank 6033lines. Comments may appear on their own line anywhere within the file 6034and are preceded by semicolons. Whitespace is allowed before the 6035semicolon. 6036 6037 The files can contain the following types of record: 6038 6039 * A language definition record. These records have two fields: the 6040 string 'Language' and the name of the language. Once a language 6041 has been declared in this way, it can be used as an option 6042 property. *Note Option properties::. 6043 6044 * A target specific save record to save additional information. 6045 These records have two fields: the string 'TargetSave', and a 6046 declaration type to go in the 'cl_target_option' structure. 6047 6048 * A variable record to define a variable used to store option 6049 information. These records have two fields: the string 'Variable', 6050 and a declaration of the type and name of the variable, optionally 6051 with an initializer (but without any trailing ';'). These records 6052 may be used for variables used for many options where declaring the 6053 initializer in a single option definition record, or duplicating it 6054 in many records, would be inappropriate, or for variables set in 6055 option handlers rather than referenced by 'Var' properties. 6056 6057 * A variable record to define a variable used to store option 6058 information. These records have two fields: the string 6059 'TargetVariable', and a declaration of the type and name of the 6060 variable, optionally with an initializer (but without any trailing 6061 ';'). 'TargetVariable' is a combination of 'Variable' and 6062 'TargetSave' records in that the variable is defined in the 6063 'gcc_options' structure, but these variables are also stored in the 6064 'cl_target_option' structure. The variables are saved in the 6065 target save code and restored in the target restore code. 6066 6067 * A variable record to record any additional files that the 6068 'options.h' file should include. This is useful to provide 6069 enumeration or structure definitions needed for target variables. 6070 These records have two fields: the string 'HeaderInclude' and the 6071 name of the include file. 6072 6073 * A variable record to record any additional files that the 6074 'options.c' or 'options-save.c' file should include. This is 6075 useful to provide inline functions needed for target variables 6076 and/or '#ifdef' sequences to properly set up the initialization. 6077 These records have two fields: the string 'SourceInclude' and the 6078 name of the include file. 6079 6080 * An enumeration record to define a set of strings that may be used 6081 as arguments to an option or options. These records have three 6082 fields: the string 'Enum', a space-separated list of properties and 6083 help text used to describe the set of strings in '--help' output. 6084 Properties use the same format as option properties; the following 6085 are valid: 6086 'Name(NAME)' 6087 This property is required; NAME must be a name (suitable for 6088 use in C identifiers) used to identify the set of strings in 6089 'Enum' option properties. 6090 6091 'Type(TYPE)' 6092 This property is required; TYPE is the C type for variables 6093 set by options using this enumeration together with 'Var'. 6094 6095 'UnknownError(MESSAGE)' 6096 The message MESSAGE will be used as an error message if the 6097 argument is invalid; for enumerations without 'UnknownError', 6098 a generic error message is used. MESSAGE should contain a 6099 single '%qs' format, which will be used to format the invalid 6100 argument. 6101 6102 * An enumeration value record to define one of the strings in a set 6103 given in an 'Enum' record. These records have two fields: the 6104 string 'EnumValue' and a space-separated list of properties. 6105 Properties use the same format as option properties; the following 6106 are valid: 6107 'Enum(NAME)' 6108 This property is required; NAME says which 'Enum' record this 6109 'EnumValue' record corresponds to. 6110 6111 'String(STRING)' 6112 This property is required; STRING is the string option 6113 argument being described by this record. 6114 6115 'Value(VALUE)' 6116 This property is required; it says what value (representable 6117 as 'int') should be used for the given string. 6118 6119 'Canonical' 6120 This property is optional. If present, it says the present 6121 string is the canonical one among all those with the given 6122 value. Other strings yielding that value will be mapped to 6123 this one so specs do not need to handle them. 6124 6125 'DriverOnly' 6126 This property is optional. If present, the present string 6127 will only be accepted by the driver. This is used for cases 6128 such as '-march=native' that are processed by the driver so 6129 that 'gcc -v' shows how the options chosen depended on the 6130 system on which the compiler was run. 6131 6132 * An option definition record. These records have the following 6133 fields: 6134 1. the name of the option, with the leading "-" removed 6135 2. a space-separated list of option properties (*note Option 6136 properties::) 6137 3. the help text to use for '--help' (omitted if the second field 6138 contains the 'Undocumented' property). 6139 6140 By default, all options beginning with "f", "W" or "m" are 6141 implicitly assumed to take a "no-" form. This form should not be 6142 listed separately. If an option beginning with one of these 6143 letters does not have a "no-" form, you can use the 6144 'RejectNegative' property to reject it. 6145 6146 The help text is automatically line-wrapped before being displayed. 6147 Normally the name of the option is printed on the left-hand side of 6148 the output and the help text is printed on the right. However, if 6149 the help text contains a tab character, the text to the left of the 6150 tab is used instead of the option's name and the text to the right 6151 of the tab forms the help text. This allows you to elaborate on 6152 what type of argument the option takes. 6153 6154 * A target mask record. These records have one field of the form 6155 'Mask(X)'. The options-processing script will automatically 6156 allocate a bit in 'target_flags' (*note Run-time Target::) for each 6157 mask name X and set the macro 'MASK_X' to the appropriate bitmask. 6158 It will also declare a 'TARGET_X' macro that has the value 1 when 6159 bit 'MASK_X' is set and 0 otherwise. 6160 6161 They are primarily intended to declare target masks that are not 6162 associated with user options, either because these masks represent 6163 internal switches or because the options are not available on all 6164 configurations and yet the masks always need to be defined. 6165 6166 6167File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 6168 61698.2 Option properties 6170===================== 6171 6172The second field of an option record can specify any of the following 6173properties. When an option takes an argument, it is enclosed in 6174parentheses following the option property name. The parser that handles 6175option files is quite simplistic, and will be tricked by any nested 6176parentheses within the argument text itself; in this case, the entire 6177option argument can be wrapped in curly braces within the parentheses to 6178demarcate it, e.g.: 6179 6180 Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)}) 6181 6182'Common' 6183 The option is available for all languages and targets. 6184 6185'Target' 6186 The option is available for all languages but is target-specific. 6187 6188'Driver' 6189 The option is handled by the compiler driver using code not shared 6190 with the compilers proper ('cc1' etc.). 6191 6192'LANGUAGE' 6193 The option is available when compiling for the given language. 6194 6195 It is possible to specify several different languages for the same 6196 option. Each LANGUAGE must have been declared by an earlier 6197 'Language' record. *Note Option file format::. 6198 6199'RejectDriver' 6200 The option is only handled by the compilers proper ('cc1' etc.) and 6201 should not be accepted by the driver. 6202 6203'RejectNegative' 6204 The option does not have a "no-" form. All options beginning with 6205 "f", "W" or "m" are assumed to have a "no-" form unless this 6206 property is used. 6207 6208'Negative(OTHERNAME)' 6209 The option will turn off another option OTHERNAME, which is the 6210 option name with the leading "-" removed. This chain action will 6211 propagate through the 'Negative' property of the option to be 6212 turned off. 6213 6214 As a consequence, if you have a group of mutually-exclusive 6215 options, their 'Negative' properties should form a circular chain. 6216 For example, if options '-A', '-B' and '-C' are mutually exclusive, 6217 their respective 'Negative' properties should be 'Negative(B)', 6218 'Negative(C)' and 'Negative(A)'. 6219 6220'Joined' 6221'Separate' 6222 The option takes a mandatory argument. 'Joined' indicates that the 6223 option and argument can be included in the same 'argv' entry (as 6224 with '-mflush-func=NAME', for example). 'Separate' indicates that 6225 the option and argument can be separate 'argv' entries (as with 6226 '-o'). An option is allowed to have both of these properties. 6227 6228'JoinedOrMissing' 6229 The option takes an optional argument. If the argument is given, 6230 it will be part of the same 'argv' entry as the option itself. 6231 6232 This property cannot be used alongside 'Joined' or 'Separate'. 6233 6234'MissingArgError(MESSAGE)' 6235 For an option marked 'Joined' or 'Separate', the message MESSAGE 6236 will be used as an error message if the mandatory argument is 6237 missing; for options without 'MissingArgError', a generic error 6238 message is used. MESSAGE should contain a single '%qs' format, 6239 which will be used to format the name of the option passed. 6240 6241'Args(N)' 6242 For an option marked 'Separate', indicate that it takes N 6243 arguments. The default is 1. 6244 6245'UInteger' 6246 The option's argument is a non-negative integer. The option parser 6247 will check and convert the argument before passing it to the 6248 relevant option handler. 'UInteger' should also be used on options 6249 like '-falign-loops' where both '-falign-loops' and 6250 '-falign-loops'=N are supported to make sure the saved options are 6251 given a full integer. 6252 6253'ToLower' 6254 The option's argument should be converted to lowercase as part of 6255 putting it in canonical form, and before comparing with the strings 6256 indicated by any 'Enum' property. 6257 6258'NoDriverArg' 6259 For an option marked 'Separate', the option only takes an argument 6260 in the compiler proper, not in the driver. This is for 6261 compatibility with existing options that are used both directly and 6262 via '-Wp,'; new options should not have this property. 6263 6264'Var(VAR)' 6265 The state of this option should be stored in variable VAR (actually 6266 a macro for 'global_options.x_VAR'). The way that the state is 6267 stored depends on the type of option: 6268 6269 * If the option uses the 'Mask' or 'InverseMask' properties, VAR 6270 is the integer variable that contains the mask. 6271 6272 * If the option is a normal on/off switch, VAR is an integer 6273 variable that is nonzero when the option is enabled. The 6274 options parser will set the variable to 1 when the positive 6275 form of the option is used and 0 when the "no-" form is used. 6276 6277 * If the option takes an argument and has the 'UInteger' 6278 property, VAR is an integer variable that stores the value of 6279 the argument. 6280 6281 * If the option takes an argument and has the 'Enum' property, 6282 VAR is a variable (type given in the 'Type' property of the 6283 'Enum' record whose 'Name' property has the same argument as 6284 the 'Enum' property of this option) that stores the value of 6285 the argument. 6286 6287 * If the option has the 'Defer' property, VAR is a pointer to a 6288 'VEC(cl_deferred_option,heap)' that stores the option for 6289 later processing. (VAR is declared with type 'void *' and 6290 needs to be cast to 'VEC(cl_deferred_option,heap)' before 6291 use.) 6292 6293 * Otherwise, if the option takes an argument, VAR is a pointer 6294 to the argument string. The pointer will be null if the 6295 argument is optional and wasn't given. 6296 6297 The option-processing script will usually zero-initialize VAR. You 6298 can modify this behavior using 'Init'. 6299 6300'Var(VAR, SET)' 6301 The option controls an integer variable VAR and is active when VAR 6302 equals SET. The option parser will set VAR to SET when the 6303 positive form of the option is used and '!SET' when the "no-" form 6304 is used. 6305 6306 VAR is declared in the same way as for the single-argument form 6307 described above. 6308 6309'Init(VALUE)' 6310 The variable specified by the 'Var' property should be statically 6311 initialized to VALUE. If more than one option using the same 6312 variable specifies 'Init', all must specify the same initializer. 6313 6314'Mask(NAME)' 6315 The option is associated with a bit in the 'target_flags' variable 6316 (*note Run-time Target::) and is active when that bit is set. You 6317 may also specify 'Var' to select a variable other than 6318 'target_flags'. 6319 6320 The options-processing script will automatically allocate a unique 6321 bit for the option. If the option is attached to 'target_flags', 6322 the script will set the macro 'MASK_NAME' to the appropriate 6323 bitmask. It will also declare a 'TARGET_NAME' macro that has the 6324 value 1 when the option is active and 0 otherwise. If you use 6325 'Var' to attach the option to a different variable, the bitmask 6326 macro with be called 'OPTION_MASK_NAME'. 6327 6328'InverseMask(OTHERNAME)' 6329'InverseMask(OTHERNAME, THISNAME)' 6330 The option is the inverse of another option that has the 6331 'Mask(OTHERNAME)' property. If THISNAME is given, the 6332 options-processing script will declare a 'TARGET_THISNAME' macro 6333 that is 1 when the option is active and 0 otherwise. 6334 6335'Enum(NAME)' 6336 The option's argument is a string from the set of strings 6337 associated with the corresponding 'Enum' record. The string is 6338 checked and converted to the integer specified in the corresponding 6339 'EnumValue' record before being passed to option handlers. 6340 6341'Defer' 6342 The option should be stored in a vector, specified with 'Var', for 6343 later processing. 6344 6345'Alias(OPT)' 6346'Alias(OPT, ARG)' 6347'Alias(OPT, POSARG, NEGARG)' 6348 The option is an alias for '-OPT' (or the negative form of that 6349 option, depending on 'NegativeAlias'). In the first form, any 6350 argument passed to the alias is considered to be passed to '-OPT', 6351 and '-OPT' is considered to be negated if the alias is used in 6352 negated form. In the second form, the alias may not be negated or 6353 have an argument, and POSARG is considered to be passed as an 6354 argument to '-OPT'. In the third form, the alias may not have an 6355 argument, if the alias is used in the positive form then POSARG is 6356 considered to be passed to '-OPT', and if the alias is used in the 6357 negative form then NEGARG is considered to be passed to '-OPT'. 6358 6359 Aliases should not specify 'Var' or 'Mask' or 'UInteger'. Aliases 6360 should normally specify the same languages as the target of the 6361 alias; the flags on the target will be used to determine any 6362 diagnostic for use of an option for the wrong language, while those 6363 on the alias will be used to identify what command-line text is the 6364 option and what text is any argument to that option. 6365 6366 When an 'Alias' definition is used for an option, driver specs do 6367 not need to handle it and no 'OPT_' enumeration value is defined 6368 for it; only the canonical form of the option will be seen in those 6369 places. 6370 6371'NegativeAlias' 6372 For an option marked with 'Alias(OPT)', the option is considered to 6373 be an alias for the positive form of '-OPT' if negated and for the 6374 negative form of '-OPT' if not negated. 'NegativeAlias' may not be 6375 used with the forms of 'Alias' taking more than one argument. 6376 6377'Ignore' 6378 This option is ignored apart from printing any warning specified 6379 using 'Warn'. The option will not be seen by specs and no 'OPT_' 6380 enumeration value is defined for it. 6381 6382'SeparateAlias' 6383 For an option marked with 'Joined', 'Separate' and 'Alias', the 6384 option only acts as an alias when passed a separate argument; with 6385 a joined argument it acts as a normal option, with an 'OPT_' 6386 enumeration value. This is for compatibility with the Java '-d' 6387 option and should not be used for new options. 6388 6389'Warn(MESSAGE)' 6390 If this option is used, output the warning MESSAGE. MESSAGE is a 6391 format string, either taking a single operand with a '%qs' format 6392 which is the option name, or not taking any operands, which is 6393 passed to the 'warning' function. If an alias is marked 'Warn', 6394 the target of the alias must not also be marked 'Warn'. 6395 6396'Report' 6397 The state of the option should be printed by '-fverbose-asm'. 6398 6399'Warning' 6400 This is a warning option and should be shown as such in '--help' 6401 output. This flag does not currently affect anything other than 6402 '--help'. 6403 6404'Optimization' 6405 This is an optimization option. It should be shown as such in 6406 '--help' output, and any associated variable named using 'Var' 6407 should be saved and restored when the optimization level is changed 6408 with 'optimize' attributes. 6409 6410'Undocumented' 6411 The option is deliberately missing documentation and should not be 6412 included in the '--help' output. 6413 6414'Condition(COND)' 6415 The option should only be accepted if preprocessor condition COND 6416 is true. Note that any C declarations associated with the option 6417 will be present even if COND is false; COND simply controls whether 6418 the option is accepted and whether it is printed in the '--help' 6419 output. 6420 6421'Save' 6422 Build the 'cl_target_option' structure to hold a copy of the 6423 option, add the functions 'cl_target_option_save' and 6424 'cl_target_option_restore' to save and restore the options. 6425 6426'SetByCombined' 6427 The option may also be set by a combined option such as 6428 '-ffast-math'. This causes the 'gcc_options' struct to have a 6429 field 'frontend_set_NAME', where 'NAME' is the name of the field 6430 holding the value of this option (without the leading 'x_'). This 6431 gives the front end a way to indicate that the value has been set 6432 explicitly and should not be changed by the combined option. For 6433 example, some front ends use this to prevent '-ffast-math' and 6434 '-fno-fast-math' from changing the value of '-fmath-errno' for 6435 languages that do not use 'errno'. 6436 6437'EnabledBy(OPT)' 6438'EnabledBy(OPT || OPT2)' 6439'EnabledBy(OPT && OPT2)' 6440 If not explicitly set, the option is set to the value of '-OPT'; 6441 multiple options can be given, separated by '||'. The third form 6442 using '&&' specifies that the option is only set if both OPT and 6443 OPT2 are set. The options OPT and OPT2 must have the 'Common' 6444 property; otherwise, use 'LangEnabledBy'. 6445 6446'LangEnabledBy(LANGUAGE, OPT)' 6447'LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)' 6448 When compiling for the given language, the option is set to the 6449 value of '-OPT', if not explicitly set. OPT can be also a list of 6450 '||' separated options. In the second form, if OPT is used in the 6451 positive form then POSARG is considered to be passed to the option, 6452 and if OPT is used in the negative form then NEGARG is considered 6453 to be passed to the option. It is possible to specify several 6454 different languages. Each LANGUAGE must have been declared by an 6455 earlier 'Language' record. *Note Option file format::. 6456 6457'NoDWARFRecord' 6458 The option is omitted from the producer string written by 6459 '-grecord-gcc-switches'. 6460 6461'PchIgnore' 6462 Even if this is a target option, this option will not be recorded / 6463 compared to determine if a precompiled header file matches. 6464 6465'CPP(VAR)' 6466 The state of this option should be kept in sync with the 6467 preprocessor option VAR. If this property is set, then properties 6468 'Var' and 'Init' must be set as well. 6469 6470'CppReason(CPP_W_ENUM)' 6471 This warning option corresponds to 'cpplib.h' warning reason code 6472 CPP_W_ENUM. This should only be used for warning options of the 6473 C-family front-ends. 6474 6475 6476File: gccint.info, Node: Passes, Next: GENERIC, Prev: Options, Up: Top 6477 64789 Passes and Files of the Compiler 6479********************************** 6480 6481This chapter is dedicated to giving an overview of the optimization and 6482code generation passes of the compiler. In the process, it describes 6483some of the language front end interface, though this description is no 6484where near complete. 6485 6486* Menu: 6487 6488* Parsing pass:: The language front end turns text into bits. 6489* Cilk Plus Transformation:: Transform Cilk Plus Code to equivalent C/C++. 6490* Gimplification pass:: The bits are turned into something we can optimize. 6491* Pass manager:: Sequencing the optimization passes. 6492* Tree SSA passes:: Optimizations on a high-level representation. 6493* RTL passes:: Optimizations on a low-level representation. 6494* Optimization info:: Dumping optimization information from passes. 6495 6496 6497File: gccint.info, Node: Parsing pass, Next: Cilk Plus Transformation, Up: Passes 6498 64999.1 Parsing pass 6500================ 6501 6502The language front end is invoked only once, via 6503'lang_hooks.parse_file', to parse the entire input. The language front 6504end may use any intermediate language representation deemed appropriate. 6505The C front end uses GENERIC trees (*note GENERIC::), plus a double 6506handful of language specific tree codes defined in 'c-common.def'. The 6507Fortran front end uses a completely different private representation. 6508 6509 At some point the front end must translate the representation used in 6510the front end to a representation understood by the language-independent 6511portions of the compiler. Current practice takes one of two forms. The 6512C front end manually invokes the gimplifier (*note GIMPLE::) on each 6513function, and uses the gimplifier callbacks to convert the 6514language-specific tree nodes directly to GIMPLE before passing the 6515function off to be compiled. The Fortran front end converts from a 6516private representation to GENERIC, which is later lowered to GIMPLE when 6517the function is compiled. Which route to choose probably depends on how 6518well GENERIC (plus extensions) can be made to match up with the source 6519language and necessary parsing data structures. 6520 6521 BUG: Gimplification must occur before nested function lowering, and 6522nested function lowering must be done by the front end before passing 6523the data off to cgraph. 6524 6525 TODO: Cgraph should control nested function lowering. It would only be 6526invoked when it is certain that the outer-most function is used. 6527 6528 TODO: Cgraph needs a gimplify_function callback. It should be invoked 6529when (1) it is certain that the function is used, (2) warning flags 6530specified by the user require some amount of compilation in order to 6531honor, (3) the language indicates that semantic analysis is not complete 6532until gimplification occurs. Hum... this sounds overly complicated. 6533Perhaps we should just have the front end gimplify always; in most cases 6534it's only one function call. 6535 6536 The front end needs to pass all function definitions and top level 6537declarations off to the middle-end so that they can be compiled and 6538emitted to the object file. For a simple procedural language, it is 6539usually most convenient to do this as each top level declaration or 6540definition is seen. There is also a distinction to be made between 6541generating functional code and generating complete debug information. 6542The only thing that is absolutely required for functional code is that 6543function and data _definitions_ be passed to the middle-end. For 6544complete debug information, function, data and type declarations should 6545all be passed as well. 6546 6547 In any case, the front end needs each complete top-level function or 6548data declaration, and each data definition should be passed to 6549'rest_of_decl_compilation'. Each complete type definition should be 6550passed to 'rest_of_type_compilation'. Each function definition should 6551be passed to 'cgraph_finalize_function'. 6552 6553 TODO: I know rest_of_compilation currently has all sorts of RTL 6554generation semantics. I plan to move all code generation bits (both 6555Tree and RTL) to compile_function. Should we hide cgraph from the front 6556ends and move back to rest_of_compilation as the official interface? 6557Possibly we should rename all three interfaces such that the names match 6558in some meaningful way and that is more descriptive than "rest_of". 6559 6560 The middle-end will, at its option, emit the function and data 6561definitions immediately or queue them for later processing. 6562 6563 6564File: gccint.info, Node: Cilk Plus Transformation, Next: Gimplification pass, Prev: Parsing pass, Up: Passes 6565 65669.2 Cilk Plus Transformation 6567============================ 6568 6569If Cilk Plus generation (flag '-fcilkplus') is enabled, all the Cilk 6570Plus code is transformed into equivalent C and C++ functions. Majority 6571of this transformation occurs toward the end of the parsing and right 6572before the gimplification pass. 6573 6574 These are the major components to the Cilk Plus language extension: 6575 * Array Notations: During parsing phase, all the array notation 6576 specific information is stored in 'ARRAY_NOTATION_REF' tree using 6577 the function 'c_parser_array_notation'. During the end of parsing, 6578 we check the entire function to see if there are any array notation 6579 specific code (using the function 'contains_array_notation_expr'). 6580 If this function returns true, then we expand them using either 6581 'expand_array_notation_exprs' or 'build_array_notation_expr'. For 6582 the cases where array notations are inside conditions, they are 6583 transformed using the function 'fix_conditional_array_notations'. 6584 The C language-specific routines are located in 6585 'c/c-array-notation.c' and the equivalent C++ routines are in the 6586 file 'cp/cp-array-notation.c'. Common routines such as functions 6587 to initialize built-in functions are stored in 6588 'array-notation-common.c'. 6589 6590 * Cilk keywords: 6591 * '_Cilk_spawn': The '_Cilk_spawn' keyword is parsed and the 6592 function it contains is marked as a spawning function. The 6593 spawning function is called the spawner. At the end of the 6594 parsing phase, appropriate built-in functions are added to the 6595 spawner that are defined in the Cilk runtime. The appropriate 6596 locations of these functions, and the internal structures are 6597 detailed in 'cilk_init_builtins' in the file 'cilk-common.c'. 6598 The pointers to Cilk functions and fields of internal 6599 structures are described in 'cilk.h'. The built-in functions 6600 are described in 'cilk-builtins.def'. 6601 6602 During gimplification, a new "spawn-helper" function is 6603 created. The spawned function is replaced with a spawn helper 6604 function in the spawner. The spawned function-call is moved 6605 into the spawn helper. The main function that does these 6606 transformations is 'gimplify_cilk_spawn' in 'c-family/cilk.c'. 6607 In the spawn-helper, the gimplification function 6608 'gimplify_call_expr', inserts a function call 6609 '__cilkrts_detach'. This function is expanded by 6610 'builtin_expand_cilk_detach' located in 'c-family/cilk.c'. 6611 6612 * '_Cilk_sync': '_Cilk_sync' is parsed like a keyword. During 6613 gimplification, the function 'gimplify_cilk_sync' in 6614 'c-family/cilk.c', will replace this keyword with a set of 6615 functions that are stored in the Cilk runtime. One of the 6616 internal functions inserted during gimplification, 6617 '__cilkrts_pop_frame' must be expanded by the compiler and is 6618 done by 'builtin_expand_cilk_pop_frame' in 'cilk-common.c'. 6619 6620 Documentation about Cilk Plus and language specification is provided 6621under the "Learn" section in <https://www.cilkplus.org>. It is worth 6622mentioning that the current implementation follows ABI 1.1. 6623 6624 6625File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Cilk Plus Transformation, Up: Passes 6626 66279.3 Gimplification pass 6628======================= 6629 6630"Gimplification" is a whimsical term for the process of converting the 6631intermediate representation of a function into the GIMPLE language 6632(*note GIMPLE::). The term stuck, and so words like "gimplification", 6633"gimplify", "gimplifier" and the like are sprinkled throughout this 6634section of code. 6635 6636 While a front end may certainly choose to generate GIMPLE directly if 6637it chooses, this can be a moderately complex process unless the 6638intermediate language used by the front end is already fairly simple. 6639Usually it is easier to generate GENERIC trees plus extensions and let 6640the language-independent gimplifier do most of the work. 6641 6642 The main entry point to this pass is 'gimplify_function_tree' located 6643in 'gimplify.c'. From here we process the entire function gimplifying 6644each statement in turn. The main workhorse for this pass is 6645'gimplify_expr'. Approximately everything passes through here at least 6646once, and it is from here that we invoke the 'lang_hooks.gimplify_expr' 6647callback. 6648 6649 The callback should examine the expression in question and return 6650'GS_UNHANDLED' if the expression is not a language specific construct 6651that requires attention. Otherwise it should alter the expression in 6652some way to such that forward progress is made toward producing valid 6653GIMPLE. If the callback is certain that the transformation is complete 6654and the expression is valid GIMPLE, it should return 'GS_ALL_DONE'. 6655Otherwise it should return 'GS_OK', which will cause the expression to 6656be processed again. If the callback encounters an error during the 6657transformation (because the front end is relying on the gimplification 6658process to finish semantic checks), it should return 'GS_ERROR'. 6659 6660 6661File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes 6662 66639.4 Pass manager 6664================ 6665 6666The pass manager is located in 'passes.c', 'tree-optimize.c' and 6667'tree-pass.h'. It processes passes as described in 'passes.def'. Its 6668job is to run all of the individual passes in the correct order, and 6669take care of standard bookkeeping that applies to every pass. 6670 6671 The theory of operation is that each pass defines a structure that 6672represents everything we need to know about that pass--when it should be 6673run, how it should be run, what intermediate language form or 6674on-the-side data structures it needs. We register the pass to be run in 6675some particular order, and the pass manager arranges for everything to 6676happen in the correct order. 6677 6678 The actuality doesn't completely live up to the theory at present. 6679Command-line switches and 'timevar_id_t' enumerations must still be 6680defined elsewhere. The pass manager validates constraints but does not 6681attempt to (re-)generate data structures or lower intermediate language 6682form based on the requirements of the next pass. Nevertheless, what is 6683present is useful, and a far sight better than nothing at all. 6684 6685 Each pass should have a unique name. Each pass may have its own dump 6686file (for GCC debugging purposes). Passes with a name starting with a 6687star do not dump anything. Sometimes passes are supposed to share a 6688dump file / option name. To still give these unique names, you can use 6689a prefix that is delimited by a space from the part that is used for the 6690dump file / option name. E.g. When the pass name is "ud dce", the name 6691used for dump file/options is "dce". 6692 6693 TODO: describe the global variables set up by the pass manager, and a 6694brief description of how a new pass should use it. I need to look at 6695what info RTL passes use first... 6696 6697 6698File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes 6699 67009.5 Tree SSA passes 6701=================== 6702 6703The following briefly describes the Tree optimization passes that are 6704run after gimplification and what source files they are located in. 6705 6706 * Remove useless statements 6707 6708 This pass is an extremely simple sweep across the gimple code in 6709 which we identify obviously dead code and remove it. Here we do 6710 things like simplify 'if' statements with constant conditions, 6711 remove exception handling constructs surrounding code that 6712 obviously cannot throw, remove lexical bindings that contain no 6713 variables, and other assorted simplistic cleanups. The idea is to 6714 get rid of the obvious stuff quickly rather than wait until later 6715 when it's more work to get rid of it. This pass is located in 6716 'tree-cfg.c' and described by 'pass_remove_useless_stmts'. 6717 6718 * OpenMP lowering 6719 6720 If OpenMP generation ('-fopenmp') is enabled, this pass lowers 6721 OpenMP constructs into GIMPLE. 6722 6723 Lowering of OpenMP constructs involves creating replacement 6724 expressions for local variables that have been mapped using data 6725 sharing clauses, exposing the control flow of most synchronization 6726 directives and adding region markers to facilitate the creation of 6727 the control flow graph. The pass is located in 'omp-low.c' and is 6728 described by 'pass_lower_omp'. 6729 6730 * OpenMP expansion 6731 6732 If OpenMP generation ('-fopenmp') is enabled, this pass expands 6733 parallel regions into their own functions to be invoked by the 6734 thread library. The pass is located in 'omp-low.c' and is 6735 described by 'pass_expand_omp'. 6736 6737 * Lower control flow 6738 6739 This pass flattens 'if' statements ('COND_EXPR') and moves lexical 6740 bindings ('BIND_EXPR') out of line. After this pass, all 'if' 6741 statements will have exactly two 'goto' statements in its 'then' 6742 and 'else' arms. Lexical binding information for each statement 6743 will be found in 'TREE_BLOCK' rather than being inferred from its 6744 position under a 'BIND_EXPR'. This pass is found in 'gimple-low.c' 6745 and is described by 'pass_lower_cf'. 6746 6747 * Lower exception handling control flow 6748 6749 This pass decomposes high-level exception handling constructs 6750 ('TRY_FINALLY_EXPR' and 'TRY_CATCH_EXPR') into a form that 6751 explicitly represents the control flow involved. After this pass, 6752 'lookup_stmt_eh_region' will return a non-negative number for any 6753 statement that may have EH control flow semantics; examine 6754 'tree_can_throw_internal' or 'tree_can_throw_external' for exact 6755 semantics. Exact control flow may be extracted from 6756 'foreach_reachable_handler'. The EH region nesting tree is defined 6757 in 'except.h' and built in 'except.c'. The lowering pass itself is 6758 in 'tree-eh.c' and is described by 'pass_lower_eh'. 6759 6760 * Build the control flow graph 6761 6762 This pass decomposes a function into basic blocks and creates all 6763 of the edges that connect them. It is located in 'tree-cfg.c' and 6764 is described by 'pass_build_cfg'. 6765 6766 * Find all referenced variables 6767 6768 This pass walks the entire function and collects an array of all 6769 variables referenced in the function, 'referenced_vars'. The index 6770 at which a variable is found in the array is used as a UID for the 6771 variable within this function. This data is needed by the SSA 6772 rewriting routines. The pass is located in 'tree-dfa.c' and is 6773 described by 'pass_referenced_vars'. 6774 6775 * Enter static single assignment form 6776 6777 This pass rewrites the function such that it is in SSA form. After 6778 this pass, all 'is_gimple_reg' variables will be referenced by 6779 'SSA_NAME', and all occurrences of other variables will be 6780 annotated with 'VDEFS' and 'VUSES'; PHI nodes will have been 6781 inserted as necessary for each basic block. This pass is located 6782 in 'tree-ssa.c' and is described by 'pass_build_ssa'. 6783 6784 * Warn for uninitialized variables 6785 6786 This pass scans the function for uses of 'SSA_NAME's that are fed 6787 by default definition. For non-parameter variables, such uses are 6788 uninitialized. The pass is run twice, before and after 6789 optimization (if turned on). In the first pass we only warn for 6790 uses that are positively uninitialized; in the second pass we warn 6791 for uses that are possibly uninitialized. The pass is located in 6792 'tree-ssa.c' and is defined by 'pass_early_warn_uninitialized' and 6793 'pass_late_warn_uninitialized'. 6794 6795 * Dead code elimination 6796 6797 This pass scans the function for statements without side effects 6798 whose result is unused. It does not do memory life analysis, so 6799 any value that is stored in memory is considered used. The pass is 6800 run multiple times throughout the optimization process. It is 6801 located in 'tree-ssa-dce.c' and is described by 'pass_dce'. 6802 6803 * Dominator optimizations 6804 6805 This pass performs trivial dominator-based copy and constant 6806 propagation, expression simplification, and jump threading. It is 6807 run multiple times throughout the optimization process. It is 6808 located in 'tree-ssa-dom.c' and is described by 'pass_dominator'. 6809 6810 * Forward propagation of single-use variables 6811 6812 This pass attempts to remove redundant computation by substituting 6813 variables that are used once into the expression that uses them and 6814 seeing if the result can be simplified. It is located in 6815 'tree-ssa-forwprop.c' and is described by 'pass_forwprop'. 6816 6817 * Copy Renaming 6818 6819 This pass attempts to change the name of compiler temporaries 6820 involved in copy operations such that SSA->normal can coalesce the 6821 copy away. When compiler temporaries are copies of user variables, 6822 it also renames the compiler temporary to the user variable 6823 resulting in better use of user symbols. It is located in 6824 'tree-ssa-copyrename.c' and is described by 'pass_copyrename'. 6825 6826 * PHI node optimizations 6827 6828 This pass recognizes forms of PHI inputs that can be represented as 6829 conditional expressions and rewrites them into straight line code. 6830 It is located in 'tree-ssa-phiopt.c' and is described by 6831 'pass_phiopt'. 6832 6833 * May-alias optimization 6834 6835 This pass performs a flow sensitive SSA-based points-to analysis. 6836 The resulting may-alias, must-alias, and escape analysis 6837 information is used to promote variables from in-memory addressable 6838 objects to non-aliased variables that can be renamed into SSA form. 6839 We also update the 'VDEF'/'VUSE' memory tags for non-renameable 6840 aggregates so that we get fewer false kills. The pass is located 6841 in 'tree-ssa-alias.c' and is described by 'pass_may_alias'. 6842 6843 Interprocedural points-to information is located in 6844 'tree-ssa-structalias.c' and described by 'pass_ipa_pta'. 6845 6846 * Profiling 6847 6848 This pass instruments the function in order to collect runtime 6849 block and value profiling data. Such data may be fed back into the 6850 compiler on a subsequent run so as to allow optimization based on 6851 expected execution frequencies. The pass is located in 6852 'tree-profile.c' and is described by 'pass_ipa_tree_profile'. 6853 6854 * Static profile estimation 6855 6856 This pass implements series of heuristics to guess propababilities 6857 of branches. The resulting predictions are turned into edge 6858 profile by propagating branches across the control flow graphs. 6859 The pass is located in 'tree-profile.c' and is described by 6860 'pass_profile'. 6861 6862 * Lower complex arithmetic 6863 6864 This pass rewrites complex arithmetic operations into their 6865 component scalar arithmetic operations. The pass is located in 6866 'tree-complex.c' and is described by 'pass_lower_complex'. 6867 6868 * Scalar replacement of aggregates 6869 6870 This pass rewrites suitable non-aliased local aggregate variables 6871 into a set of scalar variables. The resulting scalar variables are 6872 rewritten into SSA form, which allows subsequent optimization 6873 passes to do a significantly better job with them. The pass is 6874 located in 'tree-sra.c' and is described by 'pass_sra'. 6875 6876 * Dead store elimination 6877 6878 This pass eliminates stores to memory that are subsequently 6879 overwritten by another store, without any intervening loads. The 6880 pass is located in 'tree-ssa-dse.c' and is described by 'pass_dse'. 6881 6882 * Tail recursion elimination 6883 6884 This pass transforms tail recursion into a loop. It is located in 6885 'tree-tailcall.c' and is described by 'pass_tail_recursion'. 6886 6887 * Forward store motion 6888 6889 This pass sinks stores and assignments down the flowgraph closer to 6890 their use point. The pass is located in 'tree-ssa-sink.c' and is 6891 described by 'pass_sink_code'. 6892 6893 * Partial redundancy elimination 6894 6895 This pass eliminates partially redundant computations, as well as 6896 performing load motion. The pass is located in 'tree-ssa-pre.c' 6897 and is described by 'pass_pre'. 6898 6899 Just before partial redundancy elimination, if 6900 '-funsafe-math-optimizations' is on, GCC tries to convert divisions 6901 to multiplications by the reciprocal. The pass is located in 6902 'tree-ssa-math-opts.c' and is described by 'pass_cse_reciprocal'. 6903 6904 * Full redundancy elimination 6905 6906 This is a simpler form of PRE that only eliminates redundancies 6907 that occur on all paths. It is located in 'tree-ssa-pre.c' and 6908 described by 'pass_fre'. 6909 6910 * Loop optimization 6911 6912 The main driver of the pass is placed in 'tree-ssa-loop.c' and 6913 described by 'pass_loop'. 6914 6915 The optimizations performed by this pass are: 6916 6917 Loop invariant motion. This pass moves only invariants that would 6918 be hard to handle on RTL level (function calls, operations that 6919 expand to nontrivial sequences of insns). With '-funswitch-loops' 6920 it also moves operands of conditions that are invariant out of the 6921 loop, so that we can use just trivial invariantness analysis in 6922 loop unswitching. The pass also includes store motion. The pass 6923 is implemented in 'tree-ssa-loop-im.c'. 6924 6925 Canonical induction variable creation. This pass creates a simple 6926 counter for number of iterations of the loop and replaces the exit 6927 condition of the loop using it, in case when a complicated analysis 6928 is necessary to determine the number of iterations. Later 6929 optimizations then may determine the number easily. The pass is 6930 implemented in 'tree-ssa-loop-ivcanon.c'. 6931 6932 Induction variable optimizations. This pass performs standard 6933 induction variable optimizations, including strength reduction, 6934 induction variable merging and induction variable elimination. The 6935 pass is implemented in 'tree-ssa-loop-ivopts.c'. 6936 6937 Loop unswitching. This pass moves the conditional jumps that are 6938 invariant out of the loops. To achieve this, a duplicate of the 6939 loop is created for each possible outcome of conditional jump(s). 6940 The pass is implemented in 'tree-ssa-loop-unswitch.c'. 6941 6942 The optimizations also use various utility functions contained in 6943 'tree-ssa-loop-manip.c', 'cfgloop.c', 'cfgloopanal.c' and 6944 'cfgloopmanip.c'. 6945 6946 Vectorization. This pass transforms loops to operate on vector 6947 types instead of scalar types. Data parallelism across loop 6948 iterations is exploited to group data elements from consecutive 6949 iterations into a vector and operate on them in parallel. 6950 Depending on available target support the loop is conceptually 6951 unrolled by a factor 'VF' (vectorization factor), which is the 6952 number of elements operated upon in parallel in each iteration, and 6953 the 'VF' copies of each scalar operation are fused to form a vector 6954 operation. Additional loop transformations such as peeling and 6955 versioning may take place to align the number of iterations, and to 6956 align the memory accesses in the loop. The pass is implemented in 6957 'tree-vectorizer.c' (the main driver), 'tree-vect-loop.c' and 6958 'tree-vect-loop-manip.c' (loop specific parts and general loop 6959 utilities), 'tree-vect-slp' (loop-aware SLP functionality), 6960 'tree-vect-stmts.c' and 'tree-vect-data-refs.c'. Analysis of data 6961 references is in 'tree-data-ref.c'. 6962 6963 SLP Vectorization. This pass performs vectorization of 6964 straight-line code. The pass is implemented in 'tree-vectorizer.c' 6965 (the main driver), 'tree-vect-slp.c', 'tree-vect-stmts.c' and 6966 'tree-vect-data-refs.c'. 6967 6968 Autoparallelization. This pass splits the loop iteration space to 6969 run into several threads. The pass is implemented in 6970 'tree-parloops.c'. 6971 6972 Graphite is a loop transformation framework based on the polyhedral 6973 model. Graphite stands for Gimple Represented as Polyhedra. The 6974 internals of this infrastructure are documented in 6975 <http://gcc.gnu.org/wiki/Graphite>. The passes working on this 6976 representation are implemented in the various 'graphite-*' files. 6977 6978 * Tree level if-conversion for vectorizer 6979 6980 This pass applies if-conversion to simple loops to help vectorizer. 6981 We identify if convertible loops, if-convert statements and merge 6982 basic blocks in one big block. The idea is to present loop in such 6983 form so that vectorizer can have one to one mapping between 6984 statements and available vector operations. This pass is located 6985 in 'tree-if-conv.c' and is described by 'pass_if_conversion'. 6986 6987 * Conditional constant propagation 6988 6989 This pass relaxes a lattice of values in order to identify those 6990 that must be constant even in the presence of conditional branches. 6991 The pass is located in 'tree-ssa-ccp.c' and is described by 6992 'pass_ccp'. 6993 6994 A related pass that works on memory loads and stores, and not just 6995 register values, is located in 'tree-ssa-ccp.c' and described by 6996 'pass_store_ccp'. 6997 6998 * Conditional copy propagation 6999 7000 This is similar to constant propagation but the lattice of values 7001 is the "copy-of" relation. It eliminates redundant copies from the 7002 code. The pass is located in 'tree-ssa-copy.c' and described by 7003 'pass_copy_prop'. 7004 7005 A related pass that works on memory copies, and not just register 7006 copies, is located in 'tree-ssa-copy.c' and described by 7007 'pass_store_copy_prop'. 7008 7009 * Value range propagation 7010 7011 This transformation is similar to constant propagation but instead 7012 of propagating single constant values, it propagates known value 7013 ranges. The implementation is based on Patterson's range 7014 propagation algorithm (Accurate Static Branch Prediction by Value 7015 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 7016 Patterson's algorithm, this implementation does not propagate 7017 branch probabilities nor it uses more than a single range per SSA 7018 name. This means that the current implementation cannot be used 7019 for branch prediction (though adapting it would not be difficult). 7020 The pass is located in 'tree-vrp.c' and is described by 'pass_vrp'. 7021 7022 * Folding built-in functions 7023 7024 This pass simplifies built-in functions, as applicable, with 7025 constant arguments or with inferable string lengths. It is located 7026 in 'tree-ssa-ccp.c' and is described by 'pass_fold_builtins'. 7027 7028 * Split critical edges 7029 7030 This pass identifies critical edges and inserts empty basic blocks 7031 such that the edge is no longer critical. The pass is located in 7032 'tree-cfg.c' and is described by 'pass_split_crit_edges'. 7033 7034 * Control dependence dead code elimination 7035 7036 This pass is a stronger form of dead code elimination that can 7037 eliminate unnecessary control flow statements. It is located in 7038 'tree-ssa-dce.c' and is described by 'pass_cd_dce'. 7039 7040 * Tail call elimination 7041 7042 This pass identifies function calls that may be rewritten into 7043 jumps. No code transformation is actually applied here, but the 7044 data and control flow problem is solved. The code transformation 7045 requires target support, and so is delayed until RTL. In the 7046 meantime 'CALL_EXPR_TAILCALL' is set indicating the possibility. 7047 The pass is located in 'tree-tailcall.c' and is described by 7048 'pass_tail_calls'. The RTL transformation is handled by 7049 'fixup_tail_calls' in 'calls.c'. 7050 7051 * Warn for function return without value 7052 7053 For non-void functions, this pass locates return statements that do 7054 not specify a value and issues a warning. Such a statement may 7055 have been injected by falling off the end of the function. This 7056 pass is run last so that we have as much time as possible to prove 7057 that the statement is not reachable. It is located in 'tree-cfg.c' 7058 and is described by 'pass_warn_function_return'. 7059 7060 * Leave static single assignment form 7061 7062 This pass rewrites the function such that it is in normal form. At 7063 the same time, we eliminate as many single-use temporaries as 7064 possible, so the intermediate language is no longer GIMPLE, but 7065 GENERIC. The pass is located in 'tree-outof-ssa.c' and is 7066 described by 'pass_del_ssa'. 7067 7068 * Merge PHI nodes that feed into one another 7069 7070 This is part of the CFG cleanup passes. It attempts to join PHI 7071 nodes from a forwarder CFG block into another block with PHI nodes. 7072 The pass is located in 'tree-cfgcleanup.c' and is described by 7073 'pass_merge_phi'. 7074 7075 * Return value optimization 7076 7077 If a function always returns the same local variable, and that 7078 local variable is an aggregate type, then the variable is replaced 7079 with the return value for the function (i.e., the function's 7080 DECL_RESULT). This is equivalent to the C++ named return value 7081 optimization applied to GIMPLE. The pass is located in 7082 'tree-nrv.c' and is described by 'pass_nrv'. 7083 7084 * Return slot optimization 7085 7086 If a function returns a memory object and is called as 'var = 7087 foo()', this pass tries to change the call so that the address of 7088 'var' is sent to the caller to avoid an extra memory copy. This 7089 pass is located in 'tree-nrv.c' and is described by 7090 'pass_return_slot'. 7091 7092 * Optimize calls to '__builtin_object_size' 7093 7094 This is a propagation pass similar to CCP that tries to remove 7095 calls to '__builtin_object_size' when the size of the object can be 7096 computed at compile-time. This pass is located in 7097 'tree-object-size.c' and is described by 'pass_object_sizes'. 7098 7099 * Loop invariant motion 7100 7101 This pass removes expensive loop-invariant computations out of 7102 loops. The pass is located in 'tree-ssa-loop.c' and described by 7103 'pass_lim'. 7104 7105 * Loop nest optimizations 7106 7107 This is a family of loop transformations that works on loop nests. 7108 It includes loop interchange, scaling, skewing and reversal and 7109 they are all geared to the optimization of data locality in array 7110 traversals and the removal of dependencies that hamper 7111 optimizations such as loop parallelization and vectorization. The 7112 pass is located in 'tree-loop-linear.c' and described by 7113 'pass_linear_transform'. 7114 7115 * Removal of empty loops 7116 7117 This pass removes loops with no code in them. The pass is located 7118 in 'tree-ssa-loop-ivcanon.c' and described by 'pass_empty_loop'. 7119 7120 * Unrolling of small loops 7121 7122 This pass completely unrolls loops with few iterations. The pass 7123 is located in 'tree-ssa-loop-ivcanon.c' and described by 7124 'pass_complete_unroll'. 7125 7126 * Predictive commoning 7127 7128 This pass makes the code reuse the computations from the previous 7129 iterations of the loops, especially loads and stores to memory. It 7130 does so by storing the values of these computations to a bank of 7131 temporary variables that are rotated at the end of loop. To avoid 7132 the need for this rotation, the loop is then unrolled and the 7133 copies of the loop body are rewritten to use the appropriate 7134 version of the temporary variable. This pass is located in 7135 'tree-predcom.c' and described by 'pass_predcom'. 7136 7137 * Array prefetching 7138 7139 This pass issues prefetch instructions for array references inside 7140 loops. The pass is located in 'tree-ssa-loop-prefetch.c' and 7141 described by 'pass_loop_prefetch'. 7142 7143 * Reassociation 7144 7145 This pass rewrites arithmetic expressions to enable optimizations 7146 that operate on them, like redundancy elimination and 7147 vectorization. The pass is located in 'tree-ssa-reassoc.c' and 7148 described by 'pass_reassoc'. 7149 7150 * Optimization of 'stdarg' functions 7151 7152 This pass tries to avoid the saving of register arguments into the 7153 stack on entry to 'stdarg' functions. If the function doesn't use 7154 any 'va_start' macros, no registers need to be saved. If 7155 'va_start' macros are used, the 'va_list' variables don't escape 7156 the function, it is only necessary to save registers that will be 7157 used in 'va_arg' macros. For instance, if 'va_arg' is only used 7158 with integral types in the function, floating point registers don't 7159 need to be saved. This pass is located in 'tree-stdarg.c' and 7160 described by 'pass_stdarg'. 7161 7162 7163File: gccint.info, Node: RTL passes, Next: Optimization info, Prev: Tree SSA passes, Up: Passes 7164 71659.6 RTL passes 7166============== 7167 7168The following briefly describes the RTL generation and optimization 7169passes that are run after the Tree optimization passes. 7170 7171 * RTL generation 7172 7173 The source files for RTL generation include 'stmt.c', 'calls.c', 7174 'expr.c', 'explow.c', 'expmed.c', 'function.c', 'optabs.c' and 7175 'emit-rtl.c'. Also, the file 'insn-emit.c', generated from the 7176 machine description by the program 'genemit', is used in this pass. 7177 The header file 'expr.h' is used for communication within this 7178 pass. 7179 7180 The header files 'insn-flags.h' and 'insn-codes.h', generated from 7181 the machine description by the programs 'genflags' and 'gencodes', 7182 tell this pass which standard names are available for use and which 7183 patterns correspond to them. 7184 7185 * Generation of exception landing pads 7186 7187 This pass generates the glue that handles communication between the 7188 exception handling library routines and the exception handlers 7189 within the function. Entry points in the function that are invoked 7190 by the exception handling library are called "landing pads". The 7191 code for this pass is located in 'except.c'. 7192 7193 * Control flow graph cleanup 7194 7195 This pass removes unreachable code, simplifies jumps to next, jumps 7196 to jump, jumps across jumps, etc. The pass is run multiple times. 7197 For historical reasons, it is occasionally referred to as the "jump 7198 optimization pass". The bulk of the code for this pass is in 7199 'cfgcleanup.c', and there are support routines in 'cfgrtl.c' and 7200 'jump.c'. 7201 7202 * Forward propagation of single-def values 7203 7204 This pass attempts to remove redundant computation by substituting 7205 variables that come from a single definition, and seeing if the 7206 result can be simplified. It performs copy propagation and 7207 addressing mode selection. The pass is run twice, with values 7208 being propagated into loops only on the second run. The code is 7209 located in 'fwprop.c'. 7210 7211 * Common subexpression elimination 7212 7213 This pass removes redundant computation within basic blocks, and 7214 optimizes addressing modes based on cost. The pass is run twice. 7215 The code for this pass is located in 'cse.c'. 7216 7217 * Global common subexpression elimination 7218 7219 This pass performs two different types of GCSE depending on whether 7220 you are optimizing for size or not (LCM based GCSE tends to 7221 increase code size for a gain in speed, while Morel-Renvoise based 7222 GCSE does not). When optimizing for size, GCSE is done using 7223 Morel-Renvoise Partial Redundancy Elimination, with the exception 7224 that it does not try to move invariants out of loops--that is left 7225 to the loop optimization pass. If MR PRE GCSE is done, code 7226 hoisting (aka unification) is also done, as well as load motion. 7227 If you are optimizing for speed, LCM (lazy code motion) based GCSE 7228 is done. LCM is based on the work of Knoop, Ruthing, and Steffen. 7229 LCM based GCSE also does loop invariant code motion. We also 7230 perform load and store motion when optimizing for speed. 7231 Regardless of which type of GCSE is used, the GCSE pass also 7232 performs global constant and copy propagation. The source file for 7233 this pass is 'gcse.c', and the LCM routines are in 'lcm.c'. 7234 7235 * Loop optimization 7236 7237 This pass performs several loop related optimizations. The source 7238 files 'cfgloopanal.c' and 'cfgloopmanip.c' contain generic loop 7239 analysis and manipulation code. Initialization and finalization of 7240 loop structures is handled by 'loop-init.c'. A loop invariant 7241 motion pass is implemented in 'loop-invariant.c'. Basic block 7242 level optimizations--unrolling, and peeling loops-- are implemented 7243 in 'loop-unroll.c'. Replacing of the exit condition of loops by 7244 special machine-dependent instructions is handled by 7245 'loop-doloop.c'. 7246 7247 * Jump bypassing 7248 7249 This pass is an aggressive form of GCSE that transforms the control 7250 flow graph of a function by propagating constants into conditional 7251 branch instructions. The source file for this pass is 'gcse.c'. 7252 7253 * If conversion 7254 7255 This pass attempts to replace conditional branches and surrounding 7256 assignments with arithmetic, boolean value producing comparison 7257 instructions, and conditional move instructions. In the very last 7258 invocation after reload/LRA, it will generate predicated 7259 instructions when supported by the target. The code is located in 7260 'ifcvt.c'. 7261 7262 * Web construction 7263 7264 This pass splits independent uses of each pseudo-register. This 7265 can improve effect of the other transformation, such as CSE or 7266 register allocation. The code for this pass is located in 'web.c'. 7267 7268 * Instruction combination 7269 7270 This pass attempts to combine groups of two or three instructions 7271 that are related by data flow into single instructions. It 7272 combines the RTL expressions for the instructions by substitution, 7273 simplifies the result using algebra, and then attempts to match the 7274 result against the machine description. The code is located in 7275 'combine.c'. 7276 7277 * Mode switching optimization 7278 7279 This pass looks for instructions that require the processor to be 7280 in a specific "mode" and minimizes the number of mode changes 7281 required to satisfy all users. What these modes are, and what they 7282 apply to are completely target-specific. The code for this pass is 7283 located in 'mode-switching.c'. 7284 7285 * Modulo scheduling 7286 7287 This pass looks at innermost loops and reorders their instructions 7288 by overlapping different iterations. Modulo scheduling is 7289 performed immediately before instruction scheduling. The code for 7290 this pass is located in 'modulo-sched.c'. 7291 7292 * Instruction scheduling 7293 7294 This pass looks for instructions whose output will not be available 7295 by the time that it is used in subsequent instructions. Memory 7296 loads and floating point instructions often have this behavior on 7297 RISC machines. It re-orders instructions within a basic block to 7298 try to separate the definition and use of items that otherwise 7299 would cause pipeline stalls. This pass is performed twice, before 7300 and after register allocation. The code for this pass is located 7301 in 'haifa-sched.c', 'sched-deps.c', 'sched-ebb.c', 'sched-rgn.c' 7302 and 'sched-vis.c'. 7303 7304 * Register allocation 7305 7306 These passes make sure that all occurrences of pseudo registers are 7307 eliminated, either by allocating them to a hard register, replacing 7308 them by an equivalent expression (e.g. a constant) or by placing 7309 them on the stack. This is done in several subpasses: 7310 7311 * The integrated register allocator (IRA). It is called 7312 integrated because coalescing, register live range splitting, 7313 and hard register preferencing are done on-the-fly during 7314 coloring. It also has better integration with the reload/LRA 7315 pass. Pseudo-registers spilled by the allocator or the 7316 reload/LRA have still a chance to get hard-registers if the 7317 reload/LRA evicts some pseudo-registers from hard-registers. 7318 The allocator helps to choose better pseudos for spilling 7319 based on their live ranges and to coalesce stack slots 7320 allocated for the spilled pseudo-registers. IRA is a regional 7321 register allocator which is transformed into Chaitin-Briggs 7322 allocator if there is one region. By default, IRA chooses 7323 regions using register pressure but the user can force it to 7324 use one region or regions corresponding to all loops. 7325 7326 Source files of the allocator are 'ira.c', 'ira-build.c', 7327 'ira-costs.c', 'ira-conflicts.c', 'ira-color.c', 'ira-emit.c', 7328 'ira-lives', plus header files 'ira.h' and 'ira-int.h' used 7329 for the communication between the allocator and the rest of 7330 the compiler and between the IRA files. 7331 7332 * Reloading. This pass renumbers pseudo registers with the 7333 hardware registers numbers they were allocated. Pseudo 7334 registers that did not get hard registers are replaced with 7335 stack slots. Then it finds instructions that are invalid 7336 because a value has failed to end up in a register, or has 7337 ended up in a register of the wrong kind. It fixes up these 7338 instructions by reloading the problematical values temporarily 7339 into registers. Additional instructions are generated to do 7340 the copying. 7341 7342 The reload pass also optionally eliminates the frame pointer 7343 and inserts instructions to save and restore call-clobbered 7344 registers around calls. 7345 7346 Source files are 'reload.c' and 'reload1.c', plus the header 7347 'reload.h' used for communication between them. 7348 7349 * This pass is a modern replacement of the reload pass. Source 7350 files are 'lra.c', 'lra-assign.c', 'lra-coalesce.c', 7351 'lra-constraints.c', 'lra-eliminations.c', 'lra-lives.c', 7352 'lra-remat.c', 'lra-spills.c', the header 'lra-int.h' used for 7353 communication between them, and the header 'lra.h' used for 7354 communication between LRA and the rest of compiler. 7355 7356 Unlike the reload pass, intermediate LRA decisions are 7357 reflected in RTL as much as possible. This reduces the number 7358 of target-dependent macros and hooks, leaving instruction 7359 constraints as the primary source of control. 7360 7361 LRA is run on targets for which TARGET_LRA_P returns true. 7362 7363 * Basic block reordering 7364 7365 This pass implements profile guided code positioning. If profile 7366 information is not available, various types of static analysis are 7367 performed to make the predictions normally coming from the profile 7368 feedback (IE execution frequency, branch probability, etc). It is 7369 implemented in the file 'bb-reorder.c', and the various prediction 7370 routines are in 'predict.c'. 7371 7372 * Variable tracking 7373 7374 This pass computes where the variables are stored at each position 7375 in code and generates notes describing the variable locations to 7376 RTL code. The location lists are then generated according to these 7377 notes to debug information if the debugging information format 7378 supports location lists. The code is located in 'var-tracking.c'. 7379 7380 * Delayed branch scheduling 7381 7382 This optional pass attempts to find instructions that can go into 7383 the delay slots of other instructions, usually jumps and calls. 7384 The code for this pass is located in 'reorg.c'. 7385 7386 * Branch shortening 7387 7388 On many RISC machines, branch instructions have a limited range. 7389 Thus, longer sequences of instructions must be used for long 7390 branches. In this pass, the compiler figures out what how far each 7391 instruction will be from each other instruction, and therefore 7392 whether the usual instructions, or the longer sequences, must be 7393 used for each branch. The code for this pass is located in 7394 'final.c'. 7395 7396 * Register-to-stack conversion 7397 7398 Conversion from usage of some hard registers to usage of a register 7399 stack may be done at this point. Currently, this is supported only 7400 for the floating-point registers of the Intel 80387 coprocessor. 7401 The code for this pass is located in 'reg-stack.c'. 7402 7403 * Final 7404 7405 This pass outputs the assembler code for the function. The source 7406 files are 'final.c' plus 'insn-output.c'; the latter is generated 7407 automatically from the machine description by the tool 'genoutput'. 7408 The header file 'conditions.h' is used for communication between 7409 these files. 7410 7411 * Debugging information output 7412 7413 This is run after final because it must output the stack slot 7414 offsets for pseudo registers that did not get hard registers. 7415 Source files are 'dbxout.c' for DBX symbol table format, 'sdbout.c' 7416 for SDB symbol table format, 'dwarfout.c' for DWARF symbol table 7417 format, files 'dwarf2out.c' and 'dwarf2asm.c' for DWARF2 symbol 7418 table format, and 'vmsdbgout.c' for VMS debug symbol table format. 7419 7420 7421File: gccint.info, Node: Optimization info, Prev: RTL passes, Up: Passes 7422 74239.7 Optimization info 7424===================== 7425 7426This section is describes dump infrastructure which is common to both 7427pass dumps as well as optimization dumps. The goal for this 7428infrastructure is to provide both gcc developers and users detailed 7429information about various compiler transformations and optimizations. 7430 7431* Menu: 7432 7433* Dump setup:: Setup of optimization dumps. 7434* Optimization groups:: Groups made up of optimization passes. 7435* Dump files and streams:: Dump output file names and streams. 7436* Dump output verbosity:: How much information to dump. 7437* Dump types:: Various types of dump functions. 7438* Dump examples:: Sample usage. 7439 7440 7441File: gccint.info, Node: Dump setup, Next: Optimization groups, Up: Optimization info 7442 74439.7.1 Dump setup 7444---------------- 7445 7446A dump_manager class is defined in 'dumpfile.h'. Various passes 7447register dumping pass-specific information via 'dump_register' in 7448'passes.c'. During the registration, an optimization pass can select 7449its optimization group (*note Optimization groups::). After that 7450optimization information corresponding to the entire group (presumably 7451from multiple passes) can be output via command-line switches. Note 7452that if a pass does not fit into any of the pre-defined groups, it can 7453select 'OPTGROUP_NONE'. 7454 7455 Note that in general, a pass need not know its dump output file name, 7456whether certain flags are enabled, etc. However, for legacy reasons, 7457passes could also call 'dump_begin' which returns a stream in case the 7458particular pass has optimization dumps enabled. A pass could call 7459'dump_end' when the dump has ended. These methods should go away once 7460all the passes are converted to use the new dump infrastructure. 7461 7462 The recommended way to setup the dump output is via 'dump_start' and 7463'dump_end'. 7464 7465 7466File: gccint.info, Node: Optimization groups, Next: Dump files and streams, Prev: Dump setup, Up: Optimization info 7467 74689.7.2 Optimization groups 7469------------------------- 7470 7471The optimization passes are grouped into several categories. Currently 7472defined categories in 'dumpfile.h' are 7473 7474'OPTGROUP_IPA' 7475 IPA optimization passes. Enabled by '-ipa' 7476 7477'OPTGROUP_LOOP' 7478 Loop optimization passes. Enabled by '-loop'. 7479 7480'OPTGROUP_INLINE' 7481 Inlining passes. Enabled by '-inline'. 7482 7483'OPTGROUP_VEC' 7484 Vectorization passes. Enabled by '-vec'. 7485 7486'OPTGROUP_OTHER' 7487 All other optimization passes which do not fall into one of the 7488 above. 7489 7490'OPTGROUP_ALL' 7491 All optimization passes. Enabled by '-all'. 7492 7493 By using groups a user could selectively enable optimization 7494information only for a group of passes. By default, the optimization 7495information for all the passes is dumped. 7496 7497 7498File: gccint.info, Node: Dump files and streams, Next: Dump output verbosity, Prev: Optimization groups, Up: Optimization info 7499 75009.7.3 Dump files and streams 7501---------------------------- 7502 7503There are two separate output streams available for outputting 7504optimization information from passes. Note that both these streams 7505accept 'stderr' and 'stdout' as valid streams and thus it is possible to 7506dump output to standard output or error. This is specially handy for 7507outputting all available information in a single file by redirecting 7508'stderr'. 7509 7510'pstream' 7511 This stream is for pass-specific dump output. For example, 7512 '-fdump-tree-vect=foo.v' dumps tree vectorization pass output into 7513 the given file name 'foo.v'. If the file name is not provided, the 7514 default file name is based on the source file and pass number. 7515 Note that one could also use special file names 'stdout' and 7516 'stderr' for dumping to standard output and standard error 7517 respectively. 7518 7519'alt_stream' 7520 This steam is used for printing optimization specific output in 7521 response to the '-fopt-info'. Again a file name can be given. If 7522 the file name is not given, it defaults to 'stderr'. 7523 7524 7525File: gccint.info, Node: Dump output verbosity, Next: Dump types, Prev: Dump files and streams, Up: Optimization info 7526 75279.7.4 Dump output verbosity 7528--------------------------- 7529 7530The dump verbosity has the following options 7531 7532'optimized' 7533 Print information when an optimization is successfully applied. It 7534 is up to a pass to decide which information is relevant. For 7535 example, the vectorizer passes print the source location of loops 7536 which got successfully vectorized. 7537 7538'missed' 7539 Print information about missed optimizations. Individual passes 7540 control which information to include in the output. For example, 7541 7542 gcc -O2 -ftree-vectorize -fopt-info-vec-missed 7543 7544 will print information about missed optimization opportunities from 7545 vectorization passes on stderr. 7546 7547'note' 7548 Print verbose information about optimizations, such as certain 7549 transformations, more detailed messages about decisions etc. 7550 7551'all' 7552 Print detailed optimization information. This includes OPTIMIZED, 7553 MISSED, and NOTE. 7554 7555 7556File: gccint.info, Node: Dump types, Next: Dump examples, Prev: Dump output verbosity, Up: Optimization info 7557 75589.7.5 Dump types 7559---------------- 7560 7561'dump_printf' 7562 7563 This is a generic method for doing formatted output. It takes an 7564 additional argument 'dump_kind' which signifies the type of dump. 7565 This method outputs information only when the dumps are enabled for 7566 this particular 'dump_kind'. Note that the caller doesn't need to 7567 know if the particular dump is enabled or not, or even the file 7568 name. The caller only needs to decide which dump output 7569 information is relevant, and under what conditions. This 7570 determines the associated flags. 7571 7572 Consider the following example from 'loop-unroll.c' where an 7573 informative message about a loop (along with its location) is 7574 printed when any of the following flags is enabled 7575 7576 - optimization messages 7577 - RTL dumps 7578 - detailed dumps 7579 7580 int report_flags = MSG_OPTIMIZED_LOCATIONS | TDF_RTL | TDF_DETAILS; 7581 dump_printf_loc (report_flags, locus, 7582 "loop turned into non-loop; it never loops.\n"); 7583 7584'dump_basic_block' 7585 Output basic block. 7586'dump_generic_expr' 7587 Output generic expression. 7588'dump_gimple_stmt' 7589 Output gimple statement. 7590 7591 Note that the above methods also have variants prefixed with 7592 '_loc', such as 'dump_printf_loc', which are similar except they 7593 also output the source location information. 7594 7595 7596File: gccint.info, Node: Dump examples, Prev: Dump types, Up: Optimization info 7597 75989.7.6 Dump examples 7599------------------- 7600 7601 gcc -O3 -fopt-info-missed=missed.all 7602 7603 outputs missed optimization report from all the passes into 7604'missed.all'. 7605 7606 As another example, 7607 gcc -O3 -fopt-info-inline-optimized-missed=inline.txt 7608 7609 will output information about missed optimizations as well as optimized 7610locations from all the inlining passes into 'inline.txt'. 7611 7612 If the FILENAME is provided, then the dumps from all the applicable 7613optimizations are concatenated into the 'filename'. Otherwise the dump 7614is output onto 'stderr'. If OPTIONS is omitted, it defaults to 7615'all-all', which means dump all available optimization info from all the 7616passes. In the following example, all optimization info is output on to 7617'stderr'. 7618 7619 gcc -O3 -fopt-info 7620 7621 Note that '-fopt-info-vec-missed' behaves the same as 7622'-fopt-info-missed-vec'. 7623 7624 As another example, consider 7625 7626 gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt 7627 7628 Here the two output file names 'vec.miss' and 'loop.opt' are in 7629conflict since only one output file is allowed. In this case, only the 7630first option takes effect and the subsequent options are ignored. Thus 7631only the 'vec.miss' is produced which containts dumps from the 7632vectorizer about missed opportunities. 7633 7634 7635File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: Passes, Up: Top 7636 763710 GENERIC 7638********** 7639 7640The purpose of GENERIC is simply to provide a language-independent way 7641of representing an entire function in trees. To this end, it was 7642necessary to add a few new tree codes to the back end, but almost 7643everything was already there. If you can express it with the codes in 7644'gcc/tree.def', it's GENERIC. 7645 7646 Early on, there was a great deal of debate about how to think about 7647statements in a tree IL. In GENERIC, a statement is defined as any 7648expression whose value, if any, is ignored. A statement will always 7649have 'TREE_SIDE_EFFECTS' set (or it will be discarded), but a 7650non-statement expression may also have side effects. A 'CALL_EXPR', for 7651instance. 7652 7653 It would be possible for some local optimizations to work on the 7654GENERIC form of a function; indeed, the adapted tree inliner works fine 7655on GENERIC, but the current compiler performs inlining after lowering to 7656GIMPLE (a restricted form described in the next section). Indeed, 7657currently the frontends perform this lowering before handing off to 7658'tree_rest_of_compilation', but this seems inelegant. 7659 7660* Menu: 7661 7662* Deficiencies:: Topics net yet covered in this document. 7663* Tree overview:: All about 'tree's. 7664* Types:: Fundamental and aggregate types. 7665* Declarations:: Type declarations and variables. 7666* Attributes:: Declaration and type attributes. 7667* Expressions: Expression trees. Operating on data. 7668* Statements:: Control flow and related trees. 7669* Functions:: Function bodies, linkage, and other aspects. 7670* Language-dependent trees:: Topics and trees specific to language front ends. 7671* C and C++ Trees:: Trees specific to C and C++. 7672* Java Trees:: Trees specific to Java. 7673 7674 7675File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC 7676 767710.1 Deficiencies 7678================= 7679 7680There are many places in which this document is incomplet and incorrekt. 7681It is, as of yet, only _preliminary_ documentation. 7682 7683 7684File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC 7685 768610.2 Overview 7687============= 7688 7689The central data structure used by the internal representation is the 7690'tree'. These nodes, while all of the C type 'tree', are of many 7691varieties. A 'tree' is a pointer type, but the object to which it 7692points may be of a variety of types. From this point forward, we will 7693refer to trees in ordinary type, rather than in 'this font', except when 7694talking about the actual C type 'tree'. 7695 7696 You can tell what kind of node a particular tree is by using the 7697'TREE_CODE' macro. Many, many macros take trees as input and return 7698trees as output. However, most macros require a certain kind of tree 7699node as input. In other words, there is a type-system for trees, but it 7700is not reflected in the C type-system. 7701 7702 For safety, it is useful to configure GCC with '--enable-checking'. 7703Although this results in a significant performance penalty (since all 7704tree types are checked at run-time), and is therefore inappropriate in a 7705release version, it is extremely helpful during the development process. 7706 7707 Many macros behave as predicates. Many, although not all, of these 7708predicates end in '_P'. Do not rely on the result type of these macros 7709being of any particular type. You may, however, rely on the fact that 7710the type can be compared to '0', so that statements like 7711 if (TEST_P (t) && !TEST_P (y)) 7712 x = 1; 7713and 7714 int i = (TEST_P (t) != 0); 7715are legal. Macros that return 'int' values now may be changed to return 7716'tree' values, or other pointers in the future. Even those that 7717continue to return 'int' may return multiple nonzero codes where 7718previously they returned only zero and one. Therefore, you should not 7719write code like 7720 if (TEST_P (t) == 1) 7721as this code is not guaranteed to work correctly in the future. 7722 7723 You should not take the address of values returned by the macros or 7724functions described here. In particular, no guarantee is given that the 7725values are lvalues. 7726 7727 In general, the names of macros are all in uppercase, while the names 7728of functions are entirely in lowercase. There are rare exceptions to 7729this rule. You should assume that any macro or function whose name is 7730made up entirely of uppercase letters may evaluate its arguments more 7731than once. You may assume that a macro or function whose name is made 7732up entirely of lowercase letters will evaluate its arguments only once. 7733 7734 The 'error_mark_node' is a special tree. Its tree code is 7735'ERROR_MARK', but since there is only ever one node with that code, the 7736usual practice is to compare the tree against 'error_mark_node'. (This 7737test is just a test for pointer equality.) If an error has occurred 7738during front-end processing the flag 'errorcount' will be set. If the 7739front end has encountered code it cannot handle, it will issue a message 7740to the user and set 'sorrycount'. When these flags are set, any macro 7741or function which normally returns a tree of a particular kind may 7742instead return the 'error_mark_node'. Thus, if you intend to do any 7743processing of erroneous code, you must be prepared to deal with the 7744'error_mark_node'. 7745 7746 Occasionally, a particular tree slot (like an operand to an expression, 7747or a particular field in a declaration) will be referred to as "reserved 7748for the back end". These slots are used to store RTL when the tree is 7749converted to RTL for use by the GCC back end. However, if that process 7750is not taking place (e.g., if the front end is being hooked up to an 7751intelligent editor), then those slots may be used by the back end 7752presently in use. 7753 7754 If you encounter situations that do not match this documentation, such 7755as tree nodes of types not mentioned here, or macros documented to 7756return entities of a particular kind that instead return entities of 7757some different kind, you have found a bug, either in the front end or in 7758the documentation. Please report these bugs as you would any other bug. 7759 7760* Menu: 7761 7762* Macros and Functions::Macros and functions that can be used with all trees. 7763* Identifiers:: The names of things. 7764* Containers:: Lists and vectors. 7765 7766 7767File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 7768 776910.2.1 Trees 7770------------ 7771 7772All GENERIC trees have two fields in common. First, 'TREE_CHAIN' is a 7773pointer that can be used as a singly-linked list to other trees. The 7774other is 'TREE_TYPE'. Many trees store the type of an expression or 7775declaration in this field. 7776 7777 These are some other functions for handling trees: 7778 7779'tree_size' 7780 Return the number of bytes a tree takes. 7781 7782'build0' 7783'build1' 7784'build2' 7785'build3' 7786'build4' 7787'build5' 7788'build6' 7789 7790 These functions build a tree and supply values to put in each 7791 parameter. The basic signature is 'code, type, [operands]'. 7792 'code' is the 'TREE_CODE', and 'type' is a tree representing the 7793 'TREE_TYPE'. These are followed by the operands, each of which is 7794 also a tree. 7795 7796 7797File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 7798 779910.2.2 Identifiers 7800------------------ 7801 7802An 'IDENTIFIER_NODE' represents a slightly more general concept than the 7803standard C or C++ concept of identifier. In particular, an 7804'IDENTIFIER_NODE' may contain a '$', or other extraordinary characters. 7805 7806 There are never two distinct 'IDENTIFIER_NODE's representing the same 7807identifier. Therefore, you may use pointer equality to compare 7808'IDENTIFIER_NODE's, rather than using a routine like 'strcmp'. Use 7809'get_identifier' to obtain the unique 'IDENTIFIER_NODE' for a supplied 7810string. 7811 7812 You can use the following macros to access identifiers: 7813'IDENTIFIER_POINTER' 7814 The string represented by the identifier, represented as a 'char*'. 7815 This string is always 'NUL'-terminated, and contains no embedded 7816 'NUL' characters. 7817 7818'IDENTIFIER_LENGTH' 7819 The length of the string returned by 'IDENTIFIER_POINTER', not 7820 including the trailing 'NUL'. This value of 'IDENTIFIER_LENGTH 7821 (x)' is always the same as 'strlen (IDENTIFIER_POINTER (x))'. 7822 7823'IDENTIFIER_OPNAME_P' 7824 This predicate holds if the identifier represents the name of an 7825 overloaded operator. In this case, you should not depend on the 7826 contents of either the 'IDENTIFIER_POINTER' or the 7827 'IDENTIFIER_LENGTH'. 7828 7829'IDENTIFIER_TYPENAME_P' 7830 This predicate holds if the identifier represents the name of a 7831 user-defined conversion operator. In this case, the 'TREE_TYPE' of 7832 the 'IDENTIFIER_NODE' holds the type to which the conversion 7833 operator converts. 7834 7835 7836File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 7837 783810.2.3 Containers 7839----------------- 7840 7841Two common container data structures can be represented directly with 7842tree nodes. A 'TREE_LIST' is a singly linked list containing two trees 7843per node. These are the 'TREE_PURPOSE' and 'TREE_VALUE' of each node. 7844(Often, the 'TREE_PURPOSE' contains some kind of tag, or additional 7845information, while the 'TREE_VALUE' contains the majority of the 7846payload. In other cases, the 'TREE_PURPOSE' is simply 'NULL_TREE', 7847while in still others both the 'TREE_PURPOSE' and 'TREE_VALUE' are of 7848equal stature.) Given one 'TREE_LIST' node, the next node is found by 7849following the 'TREE_CHAIN'. If the 'TREE_CHAIN' is 'NULL_TREE', then 7850you have reached the end of the list. 7851 7852 A 'TREE_VEC' is a simple vector. The 'TREE_VEC_LENGTH' is an integer 7853(not a tree) giving the number of nodes in the vector. The nodes 7854themselves are accessed using the 'TREE_VEC_ELT' macro, which takes two 7855arguments. The first is the 'TREE_VEC' in question; the second is an 7856integer indicating which element in the vector is desired. The elements 7857are indexed from zero. 7858 7859 7860File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC 7861 786210.3 Types 7863========== 7864 7865All types have corresponding tree nodes. However, you should not assume 7866that there is exactly one tree node corresponding to each type. There 7867are often multiple nodes corresponding to the same type. 7868 7869 For the most part, different kinds of types have different tree codes. 7870(For example, pointer types use a 'POINTER_TYPE' code while arrays use 7871an 'ARRAY_TYPE' code.) However, pointers to member functions use the 7872'RECORD_TYPE' code. Therefore, when writing a 'switch' statement that 7873depends on the code associated with a particular type, you should take 7874care to handle pointers to member functions under the 'RECORD_TYPE' case 7875label. 7876 7877 The following functions and macros deal with cv-qualification of types: 7878'TYPE_MAIN_VARIANT' 7879 This macro returns the unqualified version of a type. It may be 7880 applied to an unqualified type, but it is not always the identity 7881 function in that case. 7882 7883 A few other macros and functions are usable with all types: 7884'TYPE_SIZE' 7885 The number of bits required to represent the type, represented as 7886 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 7887 'NULL_TREE'. 7888 7889'TYPE_ALIGN' 7890 The alignment of the type, in bits, represented as an 'int'. 7891 7892'TYPE_NAME' 7893 This macro returns a declaration (in the form of a 'TYPE_DECL') for 7894 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 7895 as you might expect, given its name!) You can look at the 7896 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 7897 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 7898 built-in type, the result of a typedef, or a named class type. 7899 7900'TYPE_CANONICAL' 7901 This macro returns the "canonical" type for the given type node. 7902 Canonical types are used to improve performance in the C++ and 7903 Objective-C++ front ends by allowing efficient comparison between 7904 two type nodes in 'same_type_p': if the 'TYPE_CANONICAL' values of 7905 the types are equal, the types are equivalent; otherwise, the types 7906 are not equivalent. The notion of equivalence for canonical types 7907 is the same as the notion of type equivalence in the language 7908 itself. For instance, 7909 7910 When 'TYPE_CANONICAL' is 'NULL_TREE', there is no canonical type 7911 for the given type node. In this case, comparison between this 7912 type and any other type requires the compiler to perform a deep, 7913 "structural" comparison to see if the two type nodes have the same 7914 form and properties. 7915 7916 The canonical type for a node is always the most fundamental type 7917 in the equivalence class of types. For instance, 'int' is its own 7918 canonical type. A typedef 'I' of 'int' will have 'int' as its 7919 canonical type. Similarly, 'I*' and a typedef 'IP' (defined to 7920 'I*') will has 'int*' as their canonical type. When building a new 7921 type node, be sure to set 'TYPE_CANONICAL' to the appropriate 7922 canonical type. If the new type is a compound type (built from 7923 other types), and any of those other types require structural 7924 equality, use 'SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the new 7925 type also requires structural equality. Finally, if for some 7926 reason you cannot guarantee that 'TYPE_CANONICAL' will point to the 7927 canonical type, use 'SET_TYPE_STRUCTURAL_EQUALITY' to make sure 7928 that the new type-and any type constructed based on it-requires 7929 structural equality. If you suspect that the canonical type system 7930 is miscomparing types, pass '--param verify-canonical-types=1' to 7931 the compiler or configure with '--enable-checking' to force the 7932 compiler to verify its canonical-type comparisons against the 7933 structural comparisons; the compiler will then print any warnings 7934 if the canonical types miscompare. 7935 7936'TYPE_STRUCTURAL_EQUALITY_P' 7937 This predicate holds when the node requires structural equality 7938 checks, e.g., when 'TYPE_CANONICAL' is 'NULL_TREE'. 7939 7940'SET_TYPE_STRUCTURAL_EQUALITY' 7941 This macro states that the type node it is given requires 7942 structural equality checks, e.g., it sets 'TYPE_CANONICAL' to 7943 'NULL_TREE'. 7944 7945'same_type_p' 7946 This predicate takes two types as input, and holds if they are the 7947 same type. For example, if one type is a 'typedef' for the other, 7948 or both are 'typedef's for the same type. This predicate also 7949 holds if the two trees given as input are simply copies of one 7950 another; i.e., there is no difference between them at the source 7951 level, but, for whatever reason, a duplicate has been made in the 7952 representation. You should never use '==' (pointer equality) to 7953 compare types; always use 'same_type_p' instead. 7954 7955 Detailed below are the various kinds of types, and the macros that can 7956be used to access them. Although other kinds of types are used 7957elsewhere in G++, the types described here are the only ones that you 7958will encounter while examining the intermediate representation. 7959 7960'VOID_TYPE' 7961 Used to represent the 'void' type. 7962 7963'INTEGER_TYPE' 7964 Used to represent the various integral types, including 'char', 7965 'short', 'int', 'long', and 'long long'. This code is not used for 7966 enumeration types, nor for the 'bool' type. The 'TYPE_PRECISION' 7967 is the number of bits used in the representation, represented as an 7968 'unsigned int'. (Note that in the general case this is not the 7969 same value as 'TYPE_SIZE'; suppose that there were a 24-bit integer 7970 type, but that alignment requirements for the ABI required 32-bit 7971 alignment. Then, 'TYPE_SIZE' would be an 'INTEGER_CST' for 32, 7972 while 'TYPE_PRECISION' would be 24.) The integer type is unsigned 7973 if 'TYPE_UNSIGNED' holds; otherwise, it is signed. 7974 7975 The 'TYPE_MIN_VALUE' is an 'INTEGER_CST' for the smallest integer 7976 that may be represented by this type. Similarly, the 7977 'TYPE_MAX_VALUE' is an 'INTEGER_CST' for the largest integer that 7978 may be represented by this type. 7979 7980'REAL_TYPE' 7981 Used to represent the 'float', 'double', and 'long double' types. 7982 The number of bits in the floating-point representation is given by 7983 'TYPE_PRECISION', as in the 'INTEGER_TYPE' case. 7984 7985'FIXED_POINT_TYPE' 7986 Used to represent the 'short _Fract', '_Fract', 'long _Fract', 7987 'long long _Fract', 'short _Accum', '_Accum', 'long _Accum', and 7988 'long long _Accum' types. The number of bits in the fixed-point 7989 representation is given by 'TYPE_PRECISION', as in the 7990 'INTEGER_TYPE' case. There may be padding bits, fractional bits 7991 and integral bits. The number of fractional bits is given by 7992 'TYPE_FBIT', and the number of integral bits is given by 7993 'TYPE_IBIT'. The fixed-point type is unsigned if 'TYPE_UNSIGNED' 7994 holds; otherwise, it is signed. The fixed-point type is saturating 7995 if 'TYPE_SATURATING' holds; otherwise, it is not saturating. 7996 7997'COMPLEX_TYPE' 7998 Used to represent GCC built-in '__complex__' data types. The 7999 'TREE_TYPE' is the type of the real and imaginary parts. 8000 8001'ENUMERAL_TYPE' 8002 Used to represent an enumeration type. The 'TYPE_PRECISION' gives 8003 (as an 'int'), the number of bits used to represent the type. If 8004 there are no negative enumeration constants, 'TYPE_UNSIGNED' will 8005 hold. The minimum and maximum enumeration constants may be 8006 obtained with 'TYPE_MIN_VALUE' and 'TYPE_MAX_VALUE', respectively; 8007 each of these macros returns an 'INTEGER_CST'. 8008 8009 The actual enumeration constants themselves may be obtained by 8010 looking at the 'TYPE_VALUES'. This macro will return a 8011 'TREE_LIST', containing the constants. The 'TREE_PURPOSE' of each 8012 node will be an 'IDENTIFIER_NODE' giving the name of the constant; 8013 the 'TREE_VALUE' will be an 'INTEGER_CST' giving the value assigned 8014 to that constant. These constants will appear in the order in 8015 which they were declared. The 'TREE_TYPE' of each of these 8016 constants will be the type of enumeration type itself. 8017 8018'BOOLEAN_TYPE' 8019 Used to represent the 'bool' type. 8020 8021'POINTER_TYPE' 8022 Used to represent pointer types, and pointer to data member types. 8023 The 'TREE_TYPE' gives the type to which this type points. 8024 8025'REFERENCE_TYPE' 8026 Used to represent reference types. The 'TREE_TYPE' gives the type 8027 to which this type refers. 8028 8029'FUNCTION_TYPE' 8030 Used to represent the type of non-member functions and of static 8031 member functions. The 'TREE_TYPE' gives the return type of the 8032 function. The 'TYPE_ARG_TYPES' are a 'TREE_LIST' of the argument 8033 types. The 'TREE_VALUE' of each node in this list is the type of 8034 the corresponding argument; the 'TREE_PURPOSE' is an expression for 8035 the default argument value, if any. If the last node in the list 8036 is 'void_list_node' (a 'TREE_LIST' node whose 'TREE_VALUE' is the 8037 'void_type_node'), then functions of this type do not take variable 8038 arguments. Otherwise, they do take a variable number of arguments. 8039 8040 Note that in C (but not in C++) a function declared like 'void f()' 8041 is an unprototyped function taking a variable number of arguments; 8042 the 'TYPE_ARG_TYPES' of such a function will be 'NULL'. 8043 8044'METHOD_TYPE' 8045 Used to represent the type of a non-static member function. Like a 8046 'FUNCTION_TYPE', the return type is given by the 'TREE_TYPE'. The 8047 type of '*this', i.e., the class of which functions of this type 8048 are a member, is given by the 'TYPE_METHOD_BASETYPE'. The 8049 'TYPE_ARG_TYPES' is the parameter list, as for a 'FUNCTION_TYPE', 8050 and includes the 'this' argument. 8051 8052'ARRAY_TYPE' 8053 Used to represent array types. The 'TREE_TYPE' gives the type of 8054 the elements in the array. If the array-bound is present in the 8055 type, the 'TYPE_DOMAIN' is an 'INTEGER_TYPE' whose 'TYPE_MIN_VALUE' 8056 and 'TYPE_MAX_VALUE' will be the lower and upper bounds of the 8057 array, respectively. The 'TYPE_MIN_VALUE' will always be an 8058 'INTEGER_CST' for zero, while the 'TYPE_MAX_VALUE' will be one less 8059 than the number of elements in the array, i.e., the highest value 8060 which may be used to index an element in the array. 8061 8062'RECORD_TYPE' 8063 Used to represent 'struct' and 'class' types, as well as pointers 8064 to member functions and similar constructs in other languages. 8065 'TYPE_FIELDS' contains the items contained in this type, each of 8066 which can be a 'FIELD_DECL', 'VAR_DECL', 'CONST_DECL', or 8067 'TYPE_DECL'. You may not make any assumptions about the ordering 8068 of the fields in the type or whether one or more of them overlap. 8069 8070'UNION_TYPE' 8071 Used to represent 'union' types. Similar to 'RECORD_TYPE' except 8072 that all 'FIELD_DECL' nodes in 'TYPE_FIELD' start at bit position 8073 zero. 8074 8075'QUAL_UNION_TYPE' 8076 Used to represent part of a variant record in Ada. Similar to 8077 'UNION_TYPE' except that each 'FIELD_DECL' has a 'DECL_QUALIFIER' 8078 field, which contains a boolean expression that indicates whether 8079 the field is present in the object. The type will only have one 8080 field, so each field's 'DECL_QUALIFIER' is only evaluated if none 8081 of the expressions in the previous fields in 'TYPE_FIELDS' are 8082 nonzero. Normally these expressions will reference a field in the 8083 outer object using a 'PLACEHOLDER_EXPR'. 8084 8085'LANG_TYPE' 8086 This node is used to represent a language-specific type. The front 8087 end must handle it. 8088 8089'OFFSET_TYPE' 8090 This node is used to represent a pointer-to-data member. For a 8091 data member 'X::m' the 'TYPE_OFFSET_BASETYPE' is 'X' and the 8092 'TREE_TYPE' is the type of 'm'. 8093 8094 There are variables whose values represent some of the basic types. 8095These include: 8096'void_type_node' 8097 A node for 'void'. 8098 8099'integer_type_node' 8100 A node for 'int'. 8101 8102'unsigned_type_node.' 8103 A node for 'unsigned int'. 8104 8105'char_type_node.' 8106 A node for 'char'. 8107It may sometimes be useful to compare one of these variables with a type 8108in hand, using 'same_type_p'. 8109 8110 8111File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC 8112 811310.4 Declarations 8114================= 8115 8116This section covers the various kinds of declarations that appear in the 8117internal representation, except for declarations of functions 8118(represented by 'FUNCTION_DECL' nodes), which are described in *note 8119Functions::. 8120 8121* Menu: 8122 8123* Working with declarations:: Macros and functions that work on 8124declarations. 8125* Internal structure:: How declaration nodes are represented. 8126 8127 8128File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 8129 813010.4.1 Working with declarations 8131-------------------------------- 8132 8133Some macros can be used with any kind of declaration. These include: 8134'DECL_NAME' 8135 This macro returns an 'IDENTIFIER_NODE' giving the name of the 8136 entity. 8137 8138'TREE_TYPE' 8139 This macro returns the type of the entity declared. 8140 8141'EXPR_FILENAME' 8142 This macro returns the name of the file in which the entity was 8143 declared, as a 'char*'. For an entity declared implicitly by the 8144 compiler (like '__builtin_memcpy'), this will be the string 8145 '"<internal>"'. 8146 8147'EXPR_LINENO' 8148 This macro returns the line number at which the entity was 8149 declared, as an 'int'. 8150 8151'DECL_ARTIFICIAL' 8152 This predicate holds if the declaration was implicitly generated by 8153 the compiler. For example, this predicate will hold of an 8154 implicitly declared member function, or of the 'TYPE_DECL' 8155 implicitly generated for a class type. Recall that in C++ code 8156 like: 8157 struct S {}; 8158 is roughly equivalent to C code like: 8159 struct S {}; 8160 typedef struct S S; 8161 The implicitly generated 'typedef' declaration is represented by a 8162 'TYPE_DECL' for which 'DECL_ARTIFICIAL' holds. 8163 8164 The various kinds of declarations include: 8165'LABEL_DECL' 8166 These nodes are used to represent labels in function bodies. For 8167 more information, see *note Functions::. These nodes only appear 8168 in block scopes. 8169 8170'CONST_DECL' 8171 These nodes are used to represent enumeration constants. The value 8172 of the constant is given by 'DECL_INITIAL' which will be an 8173 'INTEGER_CST' with the same type as the 'TREE_TYPE' of the 8174 'CONST_DECL', i.e., an 'ENUMERAL_TYPE'. 8175 8176'RESULT_DECL' 8177 These nodes represent the value returned by a function. When a 8178 value is assigned to a 'RESULT_DECL', that indicates that the value 8179 should be returned, via bitwise copy, by the function. You can use 8180 'DECL_SIZE' and 'DECL_ALIGN' on a 'RESULT_DECL', just as with a 8181 'VAR_DECL'. 8182 8183'TYPE_DECL' 8184 These nodes represent 'typedef' declarations. The 'TREE_TYPE' is 8185 the type declared to have the name given by 'DECL_NAME'. In some 8186 cases, there is no associated name. 8187 8188'VAR_DECL' 8189 These nodes represent variables with namespace or block scope, as 8190 well as static data members. The 'DECL_SIZE' and 'DECL_ALIGN' are 8191 analogous to 'TYPE_SIZE' and 'TYPE_ALIGN'. For a declaration, you 8192 should always use the 'DECL_SIZE' and 'DECL_ALIGN' rather than the 8193 'TYPE_SIZE' and 'TYPE_ALIGN' given by the 'TREE_TYPE', since 8194 special attributes may have been applied to the variable to give it 8195 a particular size and alignment. You may use the predicates 8196 'DECL_THIS_STATIC' or 'DECL_THIS_EXTERN' to test whether the 8197 storage class specifiers 'static' or 'extern' were used to declare 8198 a variable. 8199 8200 If this variable is initialized (but does not require a 8201 constructor), the 'DECL_INITIAL' will be an expression for the 8202 initializer. The initializer should be evaluated, and a bitwise 8203 copy into the variable performed. If the 'DECL_INITIAL' is the 8204 'error_mark_node', there is an initializer, but it is given by an 8205 explicit statement later in the code; no bitwise copy is required. 8206 8207 GCC provides an extension that allows either automatic variables, 8208 or global variables, to be placed in particular registers. This 8209 extension is being used for a particular 'VAR_DECL' if 8210 'DECL_REGISTER' holds for the 'VAR_DECL', and if 8211 'DECL_ASSEMBLER_NAME' is not equal to 'DECL_NAME'. In that case, 8212 'DECL_ASSEMBLER_NAME' is the name of the register into which the 8213 variable will be placed. 8214 8215'PARM_DECL' 8216 Used to represent a parameter to a function. Treat these nodes 8217 similarly to 'VAR_DECL' nodes. These nodes only appear in the 8218 'DECL_ARGUMENTS' for a 'FUNCTION_DECL'. 8219 8220 The 'DECL_ARG_TYPE' for a 'PARM_DECL' is the type that will 8221 actually be used when a value is passed to this function. It may 8222 be a wider type than the 'TREE_TYPE' of the parameter; for example, 8223 the ordinary type might be 'short' while the 'DECL_ARG_TYPE' is 8224 'int'. 8225 8226'DEBUG_EXPR_DECL' 8227 Used to represent an anonymous debug-information temporary created 8228 to hold an expression as it is optimized away, so that its value 8229 can be referenced in debug bind statements. 8230 8231'FIELD_DECL' 8232 These nodes represent non-static data members. The 'DECL_SIZE' and 8233 'DECL_ALIGN' behave as for 'VAR_DECL' nodes. The position of the 8234 field within the parent record is specified by a combination of 8235 three attributes. 'DECL_FIELD_OFFSET' is the position, counting in 8236 bytes, of the 'DECL_OFFSET_ALIGN'-bit sized word containing the bit 8237 of the field closest to the beginning of the structure. 8238 'DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 8239 field within this word; this may be nonzero even for fields that 8240 are not bit-fields, since 'DECL_OFFSET_ALIGN' may be greater than 8241 the natural alignment of the field's type. 8242 8243 If 'DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 8244 bit-field, 'DECL_BIT_FIELD_TYPE' also contains the type that was 8245 originally specified for it, while DECL_TYPE may be a modified type 8246 with lesser precision, according to the size of the bit field. 8247 8248'NAMESPACE_DECL' 8249 Namespaces provide a name hierarchy for other declarations. They 8250 appear in the 'DECL_CONTEXT' of other '_DECL' nodes. 8251 8252 8253File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 8254 825510.4.2 Internal structure 8256------------------------- 8257 8258'DECL' nodes are represented internally as a hierarchy of structures. 8259 8260* Menu: 8261 8262* Current structure hierarchy:: The current DECL node structure 8263hierarchy. 8264* Adding new DECL node types:: How to add a new DECL node to a 8265frontend. 8266 8267 8268File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 8269 827010.4.2.1 Current structure hierarchy 8271.................................... 8272 8273'struct tree_decl_minimal' 8274 This is the minimal structure to inherit from in order for common 8275 'DECL' macros to work. The fields it contains are a unique ID, 8276 source location, context, and name. 8277 8278'struct tree_decl_common' 8279 This structure inherits from 'struct tree_decl_minimal'. It 8280 contains fields that most 'DECL' nodes need, such as a field to 8281 store alignment, machine mode, size, and attributes. 8282 8283'struct tree_field_decl' 8284 This structure inherits from 'struct tree_decl_common'. It is used 8285 to represent 'FIELD_DECL'. 8286 8287'struct tree_label_decl' 8288 This structure inherits from 'struct tree_decl_common'. It is used 8289 to represent 'LABEL_DECL'. 8290 8291'struct tree_translation_unit_decl' 8292 This structure inherits from 'struct tree_decl_common'. It is used 8293 to represent 'TRANSLATION_UNIT_DECL'. 8294 8295'struct tree_decl_with_rtl' 8296 This structure inherits from 'struct tree_decl_common'. It 8297 contains a field to store the low-level RTL associated with a 8298 'DECL' node. 8299 8300'struct tree_result_decl' 8301 This structure inherits from 'struct tree_decl_with_rtl'. It is 8302 used to represent 'RESULT_DECL'. 8303 8304'struct tree_const_decl' 8305 This structure inherits from 'struct tree_decl_with_rtl'. It is 8306 used to represent 'CONST_DECL'. 8307 8308'struct tree_parm_decl' 8309 This structure inherits from 'struct tree_decl_with_rtl'. It is 8310 used to represent 'PARM_DECL'. 8311 8312'struct tree_decl_with_vis' 8313 This structure inherits from 'struct tree_decl_with_rtl'. It 8314 contains fields necessary to store visibility information, as well 8315 as a section name and assembler name. 8316 8317'struct tree_var_decl' 8318 This structure inherits from 'struct tree_decl_with_vis'. It is 8319 used to represent 'VAR_DECL'. 8320 8321'struct tree_function_decl' 8322 This structure inherits from 'struct tree_decl_with_vis'. It is 8323 used to represent 'FUNCTION_DECL'. 8324 8325 8326File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 8327 832810.4.2.2 Adding new DECL node types 8329................................... 8330 8331Adding a new 'DECL' tree consists of the following steps 8332 8333Add a new tree code for the 'DECL' node 8334 For language specific 'DECL' nodes, there is a '.def' file in each 8335 frontend directory where the tree code should be added. For 'DECL' 8336 nodes that are part of the middle-end, the code should be added to 8337 'tree.def'. 8338 8339Create a new structure type for the 'DECL' node 8340 These structures should inherit from one of the existing structures 8341 in the language hierarchy by using that structure as the first 8342 member. 8343 8344 struct tree_foo_decl 8345 { 8346 struct tree_decl_with_vis common; 8347 } 8348 8349 Would create a structure name 'tree_foo_decl' that inherits from 8350 'struct tree_decl_with_vis'. 8351 8352 For language specific 'DECL' nodes, this new structure type should 8353 go in the appropriate '.h' file. For 'DECL' nodes that are part of 8354 the middle-end, the structure type should go in 'tree.h'. 8355 8356Add a member to the tree structure enumerator for the node 8357 For garbage collection and dynamic checking purposes, each 'DECL' 8358 node structure type is required to have a unique enumerator value 8359 specified with it. For language specific 'DECL' nodes, this new 8360 enumerator value should go in the appropriate '.def' file. For 8361 'DECL' nodes that are part of the middle-end, the enumerator values 8362 are specified in 'treestruct.def'. 8363 8364Update 'union tree_node' 8365 In order to make your new structure type usable, it must be added 8366 to 'union tree_node'. For language specific 'DECL' nodes, a new 8367 entry should be added to the appropriate '.h' file of the form 8368 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 8369 For 'DECL' nodes that are part of the middle-end, the additional 8370 member goes directly into 'union tree_node' in 'tree.h'. 8371 8372Update dynamic checking info 8373 In order to be able to check whether accessing a named portion of 8374 'union tree_node' is legal, and whether a certain 'DECL' node 8375 contains one of the enumerated 'DECL' node structures in the 8376 hierarchy, a simple lookup table is used. This lookup table needs 8377 to be kept up to date with the tree structure hierarchy, or else 8378 checking and containment macros will fail inappropriately. 8379 8380 For language specific 'DECL' nodes, their is an 'init_ts' function 8381 in an appropriate '.c' file, which initializes the lookup table. 8382 Code setting up the table for new 'DECL' nodes should be added 8383 there. For each 'DECL' tree code and enumerator value representing 8384 a member of the inheritance hierarchy, the table should contain 1 8385 if that tree code inherits (directly or indirectly) from that 8386 member. Thus, a 'FOO_DECL' node derived from 'struct 8387 decl_with_rtl', and enumerator value 'TS_FOO_DECL', would be set up 8388 as follows 8389 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 8390 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 8391 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 8392 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 8393 8394 For 'DECL' nodes that are part of the middle-end, the setup code 8395 goes into 'tree.c'. 8396 8397Add macros to access any new fields and flags 8398 8399 Each added field or flag should have a macro that is used to access 8400 it, that performs appropriate checking to ensure only the right 8401 type of 'DECL' nodes access the field. 8402 8403 These macros generally take the following form 8404 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 8405 However, if the structure is simply a base class for further 8406 structures, something like the following should be used 8407 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 8408 #define BASE_STRUCT_FIELDNAME(NODE) \ 8409 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 8410 8411 Reading them from the generated 'all-tree.def' file (which in turn 8412 includes all the 'tree.def' files), 'gencheck.c' is used during 8413 GCC's build to generate the '*_CHECK' macros for all tree codes. 8414 8415 8416File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC 8417 841810.5 Attributes in trees 8419======================== 8420 8421Attributes, as specified using the '__attribute__' keyword, are 8422represented internally as a 'TREE_LIST'. The 'TREE_PURPOSE' is the name 8423of the attribute, as an 'IDENTIFIER_NODE'. The 'TREE_VALUE' is a 8424'TREE_LIST' of the arguments of the attribute, if any, or 'NULL_TREE' if 8425there are no arguments; the arguments are stored as the 'TREE_VALUE' of 8426successive entries in the list, and may be identifiers or expressions. 8427The 'TREE_CHAIN' of the attribute is the next attribute in a list of 8428attributes applying to the same declaration or type, or 'NULL_TREE' if 8429there are no further attributes in the list. 8430 8431 Attributes may be attached to declarations and to types; these 8432attributes may be accessed with the following macros. All attributes 8433are stored in this way, and many also cause other changes to the 8434declaration or type or to other internal compiler data structures. 8435 8436 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 8437 This macro returns the attributes on the declaration DECL. 8438 8439 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 8440 This macro returns the attributes on the type TYPE. 8441 8442 8443File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC 8444 844510.6 Expressions 8446================ 8447 8448The internal representation for expressions is for the most part quite 8449straightforward. However, there are a few facts that one must bear in 8450mind. In particular, the expression "tree" is actually a directed 8451acyclic graph. (For example there may be many references to the integer 8452constant zero throughout the source program; many of these will be 8453represented by the same expression node.) You should not rely on 8454certain kinds of node being shared, nor should you rely on certain kinds 8455of nodes being unshared. 8456 8457 The following macros can be used with all expression nodes: 8458 8459'TREE_TYPE' 8460 Returns the type of the expression. This value may not be 8461 precisely the same type that would be given the expression in the 8462 original program. 8463 8464 In what follows, some nodes that one might expect to always have type 8465'bool' are documented to have either integral or boolean type. At some 8466point in the future, the C front end may also make use of this same 8467intermediate representation, and at this point these nodes will 8468certainly have integral type. The previous sentence is not meant to 8469imply that the C++ front end does not or will not give these nodes 8470integral type. 8471 8472 Below, we list the various kinds of expression nodes. Except where 8473noted otherwise, the operands to an expression are accessed using the 8474'TREE_OPERAND' macro. For example, to access the first operand to a 8475binary plus expression 'expr', use: 8476 8477 TREE_OPERAND (expr, 0) 8478 8479 As this example indicates, the operands are zero-indexed. 8480 8481* Menu: 8482 8483* Constants: Constant expressions. 8484* Storage References:: 8485* Unary and Binary Expressions:: 8486* Vectors:: 8487 8488 8489File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees 8490 849110.6.1 Constant expressions 8492--------------------------- 8493 8494The table below begins with constants, moves on to unary expressions, 8495then proceeds to binary expressions, and concludes with various other 8496kinds of expressions: 8497 8498'INTEGER_CST' 8499 These nodes represent integer constants. Note that the type of 8500 these constants is obtained with 'TREE_TYPE'; they are not always 8501 of type 'int'. In particular, 'char' constants are represented 8502 with 'INTEGER_CST' nodes. The value of the integer constant 'e' is 8503 represented in an array of HOST_WIDE_INT. There are enough elements 8504 in the array to represent the value without taking extra elements 8505 for redundant 0s or -1. The number of elements used to represent 8506 'e' is available via 'TREE_INT_CST_NUNITS'. Element 'i' can be 8507 extracted by using 'TREE_INT_CST_ELT (e, i)'. 'TREE_INT_CST_LOW' 8508 is a shorthand for 'TREE_INT_CST_ELT (e, 0)'. 8509 8510 The functions 'tree_fits_shwi_p' and 'tree_fits_uhwi_p' can be used 8511 to tell if the value is small enough to fit in a signed 8512 HOST_WIDE_INT or an unsigned HOST_WIDE_INT respectively. The value 8513 can then be extracted using 'tree_to_shwi' and 'tree_to_uhwi'. 8514 8515'REAL_CST' 8516 8517 FIXME: Talk about how to obtain representations of this constant, 8518 do comparisons, and so forth. 8519 8520'FIXED_CST' 8521 8522 These nodes represent fixed-point constants. The type of these 8523 constants is obtained with 'TREE_TYPE'. 'TREE_FIXED_CST_PTR' 8524 points to a 'struct fixed_value'; 'TREE_FIXED_CST' returns the 8525 structure itself. 'struct fixed_value' contains 'data' with the 8526 size of two 'HOST_BITS_PER_WIDE_INT' and 'mode' as the associated 8527 fixed-point machine mode for 'data'. 8528 8529'COMPLEX_CST' 8530 These nodes are used to represent complex number constants, that is 8531 a '__complex__' whose parts are constant nodes. The 8532 'TREE_REALPART' and 'TREE_IMAGPART' return the real and the 8533 imaginary parts respectively. 8534 8535'VECTOR_CST' 8536 These nodes are used to represent vector constants, whose parts are 8537 constant nodes. Each individual constant node is either an integer 8538 or a double constant node. The first operand is a 'TREE_LIST' of 8539 the constant nodes and is accessed through 'TREE_VECTOR_CST_ELTS'. 8540 8541'STRING_CST' 8542 These nodes represent string-constants. The 'TREE_STRING_LENGTH' 8543 returns the length of the string, as an 'int'. The 8544 'TREE_STRING_POINTER' is a 'char*' containing the string itself. 8545 The string may not be 'NUL'-terminated, and it may contain embedded 8546 'NUL' characters. Therefore, the 'TREE_STRING_LENGTH' includes the 8547 trailing 'NUL' if it is present. 8548 8549 For wide string constants, the 'TREE_STRING_LENGTH' is the number 8550 of bytes in the string, and the 'TREE_STRING_POINTER' points to an 8551 array of the bytes of the string, as represented on the target 8552 system (that is, as integers in the target endianness). Wide and 8553 non-wide string constants are distinguished only by the 'TREE_TYPE' 8554 of the 'STRING_CST'. 8555 8556 FIXME: The formats of string constants are not well-defined when 8557 the target system bytes are not the same width as host system 8558 bytes. 8559 8560 8561File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees 8562 856310.6.2 References to storage 8564---------------------------- 8565 8566'ARRAY_REF' 8567 These nodes represent array accesses. The first operand is the 8568 array; the second is the index. To calculate the address of the 8569 memory accessed, you must scale the index by the size of the type 8570 of the array elements. The type of these expressions must be the 8571 type of a component of the array. The third and fourth operands 8572 are used after gimplification to represent the lower bound and 8573 component size but should not be used directly; call 8574 'array_ref_low_bound' and 'array_ref_element_size' instead. 8575 8576'ARRAY_RANGE_REF' 8577 These nodes represent access to a range (or "slice") of an array. 8578 The operands are the same as that for 'ARRAY_REF' and have the same 8579 meanings. The type of these expressions must be an array whose 8580 component type is the same as that of the first operand. The range 8581 of that array type determines the amount of data these expressions 8582 access. 8583 8584'TARGET_MEM_REF' 8585 These nodes represent memory accesses whose address directly map to 8586 an addressing mode of the target architecture. The first argument 8587 is 'TMR_SYMBOL' and must be a 'VAR_DECL' of an object with a fixed 8588 address. The second argument is 'TMR_BASE' and the third one is 8589 'TMR_INDEX'. The fourth argument is 'TMR_STEP' and must be an 8590 'INTEGER_CST'. The fifth argument is 'TMR_OFFSET' and must be an 8591 'INTEGER_CST'. Any of the arguments may be NULL if the appropriate 8592 component does not appear in the address. Address of the 8593 'TARGET_MEM_REF' is determined in the following way. 8594 8595 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 8596 8597 The sixth argument is the reference to the original memory access, 8598 which is preserved for the purposes of the RTL alias analysis. The 8599 seventh argument is a tag representing the results of tree level 8600 alias analysis. 8601 8602'ADDR_EXPR' 8603 These nodes are used to represent the address of an object. (These 8604 expressions will always have pointer or reference type.) The 8605 operand may be another expression, or it may be a declaration. 8606 8607 As an extension, GCC allows users to take the address of a label. 8608 In this case, the operand of the 'ADDR_EXPR' will be a 8609 'LABEL_DECL'. The type of such an expression is 'void*'. 8610 8611 If the object addressed is not an lvalue, a temporary is created, 8612 and the address of the temporary is used. 8613 8614'INDIRECT_REF' 8615 These nodes are used to represent the object pointed to by a 8616 pointer. The operand is the pointer being dereferenced; it will 8617 always have pointer or reference type. 8618 8619'MEM_REF' 8620 These nodes are used to represent the object pointed to by a 8621 pointer offset by a constant. The first operand is the pointer 8622 being dereferenced; it will always have pointer or reference type. 8623 The second operand is a pointer constant. Its type is specifying 8624 the type to be used for type-based alias analysis. 8625 8626'COMPONENT_REF' 8627 These nodes represent non-static data member accesses. The first 8628 operand is the object (rather than a pointer to it); the second 8629 operand is the 'FIELD_DECL' for the data member. The third operand 8630 represents the byte offset of the field, but should not be used 8631 directly; call 'component_ref_field_offset' instead. 8632 8633 8634File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees 8635 863610.6.3 Unary and Binary Expressions 8637----------------------------------- 8638 8639'NEGATE_EXPR' 8640 These nodes represent unary negation of the single operand, for 8641 both integer and floating-point types. The type of negation can be 8642 determined by looking at the type of the expression. 8643 8644 The behavior of this operation on signed arithmetic overflow is 8645 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 8646 8647'ABS_EXPR' 8648 These nodes represent the absolute value of the single operand, for 8649 both integer and floating-point types. This is typically used to 8650 implement the 'abs', 'labs' and 'llabs' builtins for integer types, 8651 and the 'fabs', 'fabsf' and 'fabsl' builtins for floating point 8652 types. The type of abs operation can be determined by looking at 8653 the type of the expression. 8654 8655 This node is not used for complex types. To represent the modulus 8656 or complex abs of a complex value, use the 'BUILT_IN_CABS', 8657 'BUILT_IN_CABSF' or 'BUILT_IN_CABSL' builtins, as used to implement 8658 the C99 'cabs', 'cabsf' and 'cabsl' built-in functions. 8659 8660'BIT_NOT_EXPR' 8661 These nodes represent bitwise complement, and will always have 8662 integral type. The only operand is the value to be complemented. 8663 8664'TRUTH_NOT_EXPR' 8665 These nodes represent logical negation, and will always have 8666 integral (or boolean) type. The operand is the value being 8667 negated. The type of the operand and that of the result are always 8668 of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 8669 8670'PREDECREMENT_EXPR' 8671'PREINCREMENT_EXPR' 8672'POSTDECREMENT_EXPR' 8673'POSTINCREMENT_EXPR' 8674 These nodes represent increment and decrement expressions. The 8675 value of the single operand is computed, and the operand 8676 incremented or decremented. In the case of 'PREDECREMENT_EXPR' and 8677 'PREINCREMENT_EXPR', the value of the expression is the value 8678 resulting after the increment or decrement; in the case of 8679 'POSTDECREMENT_EXPR' and 'POSTINCREMENT_EXPR' is the value before 8680 the increment or decrement occurs. The type of the operand, like 8681 that of the result, will be either integral, boolean, or 8682 floating-point. 8683 8684'FIX_TRUNC_EXPR' 8685 These nodes represent conversion of a floating-point value to an 8686 integer. The single operand will have a floating-point type, while 8687 the complete expression will have an integral (or boolean) type. 8688 The operand is rounded towards zero. 8689 8690'FLOAT_EXPR' 8691 These nodes represent conversion of an integral (or boolean) value 8692 to a floating-point value. The single operand will have integral 8693 type, while the complete expression will have a floating-point 8694 type. 8695 8696 FIXME: How is the operand supposed to be rounded? Is this 8697 dependent on '-mieee'? 8698 8699'COMPLEX_EXPR' 8700 These nodes are used to represent complex numbers constructed from 8701 two expressions of the same (integer or real) type. The first 8702 operand is the real part and the second operand is the imaginary 8703 part. 8704 8705'CONJ_EXPR' 8706 These nodes represent the conjugate of their operand. 8707 8708'REALPART_EXPR' 8709'IMAGPART_EXPR' 8710 These nodes represent respectively the real and the imaginary parts 8711 of complex numbers (their sole argument). 8712 8713'NON_LVALUE_EXPR' 8714 These nodes indicate that their one and only operand is not an 8715 lvalue. A back end can treat these identically to the single 8716 operand. 8717 8718'NOP_EXPR' 8719 These nodes are used to represent conversions that do not require 8720 any code-generation. For example, conversion of a 'char*' to an 8721 'int*' does not require any code be generated; such a conversion is 8722 represented by a 'NOP_EXPR'. The single operand is the expression 8723 to be converted. The conversion from a pointer to a reference is 8724 also represented with a 'NOP_EXPR'. 8725 8726'CONVERT_EXPR' 8727 These nodes are similar to 'NOP_EXPR's, but are used in those 8728 situations where code may need to be generated. For example, if an 8729 'int*' is converted to an 'int' code may need to be generated on 8730 some platforms. These nodes are never used for C++-specific 8731 conversions, like conversions between pointers to different classes 8732 in an inheritance hierarchy. Any adjustments that need to be made 8733 in such cases are always indicated explicitly. Similarly, a 8734 user-defined conversion is never represented by a 'CONVERT_EXPR'; 8735 instead, the function calls are made explicit. 8736 8737'FIXED_CONVERT_EXPR' 8738 These nodes are used to represent conversions that involve 8739 fixed-point values. For example, from a fixed-point value to 8740 another fixed-point value, from an integer to a fixed-point value, 8741 from a fixed-point value to an integer, from a floating-point value 8742 to a fixed-point value, or from a fixed-point value to a 8743 floating-point value. 8744 8745'LSHIFT_EXPR' 8746'RSHIFT_EXPR' 8747 These nodes represent left and right shifts, respectively. The 8748 first operand is the value to shift; it will always be of integral 8749 type. The second operand is an expression for the number of bits 8750 by which to shift. Right shift should be treated as arithmetic, 8751 i.e., the high-order bits should be zero-filled when the expression 8752 has unsigned type and filled with the sign bit when the expression 8753 has signed type. Note that the result is undefined if the second 8754 operand is larger than or equal to the first operand's type size. 8755 Unlike most nodes, these can have a vector as first operand and a 8756 scalar as second operand. 8757 8758'BIT_IOR_EXPR' 8759'BIT_XOR_EXPR' 8760'BIT_AND_EXPR' 8761 These nodes represent bitwise inclusive or, bitwise exclusive or, 8762 and bitwise and, respectively. Both operands will always have 8763 integral type. 8764 8765'TRUTH_ANDIF_EXPR' 8766'TRUTH_ORIF_EXPR' 8767 These nodes represent logical "and" and logical "or", respectively. 8768 These operators are not strict; i.e., the second operand is 8769 evaluated only if the value of the expression is not determined by 8770 evaluation of the first operand. The type of the operands and that 8771 of the result are always of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 8772 8773'TRUTH_AND_EXPR' 8774'TRUTH_OR_EXPR' 8775'TRUTH_XOR_EXPR' 8776 These nodes represent logical and, logical or, and logical 8777 exclusive or. They are strict; both arguments are always 8778 evaluated. There are no corresponding operators in C or C++, but 8779 the front end will sometimes generate these expressions anyhow, if 8780 it can tell that strictness does not matter. The type of the 8781 operands and that of the result are always of 'BOOLEAN_TYPE' or 8782 'INTEGER_TYPE'. 8783 8784'POINTER_PLUS_EXPR' 8785 This node represents pointer arithmetic. The first operand is 8786 always a pointer/reference type. The second operand is always an 8787 unsigned integer type compatible with sizetype. This is the only 8788 binary arithmetic operand that can operate on pointer types. 8789 8790'PLUS_EXPR' 8791'MINUS_EXPR' 8792'MULT_EXPR' 8793 These nodes represent various binary arithmetic operations. 8794 Respectively, these operations are addition, subtraction (of the 8795 second operand from the first) and multiplication. Their operands 8796 may have either integral or floating type, but there will never be 8797 case in which one operand is of floating type and the other is of 8798 integral type. 8799 8800 The behavior of these operations on signed arithmetic overflow is 8801 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 8802 8803'MULT_HIGHPART_EXPR' 8804 This node represents the "high-part" of a widening multiplication. 8805 For an integral type with B bits of precision, the result is the 8806 most significant B bits of the full 2B product. 8807 8808'RDIV_EXPR' 8809 This node represents a floating point division operation. 8810 8811'TRUNC_DIV_EXPR' 8812'FLOOR_DIV_EXPR' 8813'CEIL_DIV_EXPR' 8814'ROUND_DIV_EXPR' 8815 These nodes represent integer division operations that return an 8816 integer result. 'TRUNC_DIV_EXPR' rounds towards zero, 8817 'FLOOR_DIV_EXPR' rounds towards negative infinity, 'CEIL_DIV_EXPR' 8818 rounds towards positive infinity and 'ROUND_DIV_EXPR' rounds to the 8819 closest integer. Integer division in C and C++ is truncating, i.e. 8820 'TRUNC_DIV_EXPR'. 8821 8822 The behavior of these operations on signed arithmetic overflow, 8823 when dividing the minimum signed integer by minus one, is 8824 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 8825 8826'TRUNC_MOD_EXPR' 8827'FLOOR_MOD_EXPR' 8828'CEIL_MOD_EXPR' 8829'ROUND_MOD_EXPR' 8830 These nodes represent the integer remainder or modulus operation. 8831 The integer modulus of two operands 'a' and 'b' is defined as 'a - 8832 (a/b)*b' where the division calculated using the corresponding 8833 division operator. Hence for 'TRUNC_MOD_EXPR' this definition 8834 assumes division using truncation towards zero, i.e. 8835 'TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 8836 division, i.e. 'TRUNC_MOD_EXPR'. 8837 8838'EXACT_DIV_EXPR' 8839 The 'EXACT_DIV_EXPR' code is used to represent integer divisions 8840 where the numerator is known to be an exact multiple of the 8841 denominator. This allows the backend to choose between the faster 8842 of 'TRUNC_DIV_EXPR', 'CEIL_DIV_EXPR' and 'FLOOR_DIV_EXPR' for the 8843 current target. 8844 8845'LT_EXPR' 8846'LE_EXPR' 8847'GT_EXPR' 8848'GE_EXPR' 8849'EQ_EXPR' 8850'NE_EXPR' 8851 These nodes represent the less than, less than or equal to, greater 8852 than, greater than or equal to, equal, and not equal comparison 8853 operators. The first and second operands will either be both of 8854 integral type, both of floating type or both of vector type. The 8855 result type of these expressions will always be of integral, 8856 boolean or signed integral vector type. These operations return 8857 the result type's zero value for false, the result type's one value 8858 for true, and a vector whose elements are zero (false) or minus one 8859 (true) for vectors. 8860 8861 For floating point comparisons, if we honor IEEE NaNs and either 8862 operand is NaN, then 'NE_EXPR' always returns true and the 8863 remaining operators always return false. On some targets, 8864 comparisons against an IEEE NaN, other than equality and 8865 inequality, may generate a floating point exception. 8866 8867'ORDERED_EXPR' 8868'UNORDERED_EXPR' 8869 These nodes represent non-trapping ordered and unordered comparison 8870 operators. These operations take two floating point operands and 8871 determine whether they are ordered or unordered relative to each 8872 other. If either operand is an IEEE NaN, their comparison is 8873 defined to be unordered, otherwise the comparison is defined to be 8874 ordered. The result type of these expressions will always be of 8875 integral or boolean type. These operations return the result 8876 type's zero value for false, and the result type's one value for 8877 true. 8878 8879'UNLT_EXPR' 8880'UNLE_EXPR' 8881'UNGT_EXPR' 8882'UNGE_EXPR' 8883'UNEQ_EXPR' 8884'LTGT_EXPR' 8885 These nodes represent the unordered comparison operators. These 8886 operations take two floating point operands and determine whether 8887 the operands are unordered or are less than, less than or equal to, 8888 greater than, greater than or equal to, or equal respectively. For 8889 example, 'UNLT_EXPR' returns true if either operand is an IEEE NaN 8890 or the first operand is less than the second. With the possible 8891 exception of 'LTGT_EXPR', all of these operations are guaranteed 8892 not to generate a floating point exception. The result type of 8893 these expressions will always be of integral or boolean type. 8894 These operations return the result type's zero value for false, and 8895 the result type's one value for true. 8896 8897'MODIFY_EXPR' 8898 These nodes represent assignment. The left-hand side is the first 8899 operand; the right-hand side is the second operand. The left-hand 8900 side will be a 'VAR_DECL', 'INDIRECT_REF', 'COMPONENT_REF', or 8901 other lvalue. 8902 8903 These nodes are used to represent not only assignment with '=' but 8904 also compound assignments (like '+='), by reduction to '=' 8905 assignment. In other words, the representation for 'i += 3' looks 8906 just like that for 'i = i + 3'. 8907 8908'INIT_EXPR' 8909 These nodes are just like 'MODIFY_EXPR', but are used only when a 8910 variable is initialized, rather than assigned to subsequently. 8911 This means that we can assume that the target of the initialization 8912 is not used in computing its own value; any reference to the lhs in 8913 computing the rhs is undefined. 8914 8915'COMPOUND_EXPR' 8916 These nodes represent comma-expressions. The first operand is an 8917 expression whose value is computed and thrown away prior to the 8918 evaluation of the second operand. The value of the entire 8919 expression is the value of the second operand. 8920 8921'COND_EXPR' 8922 These nodes represent '?:' expressions. The first operand is of 8923 boolean or integral type. If it evaluates to a nonzero value, the 8924 second operand should be evaluated, and returned as the value of 8925 the expression. Otherwise, the third operand is evaluated, and 8926 returned as the value of the expression. 8927 8928 The second operand must have the same type as the entire 8929 expression, unless it unconditionally throws an exception or calls 8930 a noreturn function, in which case it should have void type. The 8931 same constraints apply to the third operand. This allows array 8932 bounds checks to be represented conveniently as '(i >= 0 && i < 10) 8933 ? i : abort()'. 8934 8935 As a GNU extension, the C language front-ends allow the second 8936 operand of the '?:' operator may be omitted in the source. For 8937 example, 'x ? : 3' is equivalent to 'x ? x : 3', assuming that 'x' 8938 is an expression without side-effects. In the tree representation, 8939 however, the second operand is always present, possibly protected 8940 by 'SAVE_EXPR' if the first argument does cause side-effects. 8941 8942'CALL_EXPR' 8943 These nodes are used to represent calls to functions, including 8944 non-static member functions. 'CALL_EXPR's are implemented as 8945 expression nodes with a variable number of operands. Rather than 8946 using 'TREE_OPERAND' to extract them, it is preferable to use the 8947 specialized accessor macros and functions that operate specifically 8948 on 'CALL_EXPR' nodes. 8949 8950 'CALL_EXPR_FN' returns a pointer to the function to call; it is 8951 always an expression whose type is a 'POINTER_TYPE'. 8952 8953 The number of arguments to the call is returned by 8954 'call_expr_nargs', while the arguments themselves can be accessed 8955 with the 'CALL_EXPR_ARG' macro. The arguments are zero-indexed and 8956 numbered left-to-right. You can iterate over the arguments using 8957 'FOR_EACH_CALL_EXPR_ARG', as in: 8958 8959 tree call, arg; 8960 call_expr_arg_iterator iter; 8961 FOR_EACH_CALL_EXPR_ARG (arg, iter, call) 8962 /* arg is bound to successive arguments of call. */ 8963 ...; 8964 8965 For non-static member functions, there will be an operand 8966 corresponding to the 'this' pointer. There will always be 8967 expressions corresponding to all of the arguments, even if the 8968 function is declared with default arguments and some arguments are 8969 not explicitly provided at the call sites. 8970 8971 'CALL_EXPR's also have a 'CALL_EXPR_STATIC_CHAIN' operand that is 8972 used to implement nested functions. This operand is otherwise 8973 null. 8974 8975'CLEANUP_POINT_EXPR' 8976 These nodes represent full-expressions. The single operand is an 8977 expression to evaluate. Any destructor calls engendered by the 8978 creation of temporaries during the evaluation of that expression 8979 should be performed immediately after the expression is evaluated. 8980 8981'CONSTRUCTOR' 8982 These nodes represent the brace-enclosed initializers for a 8983 structure or an array. They contain a sequence of component values 8984 made out of a vector of constructor_elt, which is a ('INDEX', 8985 'VALUE') pair. 8986 8987 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is a 'RECORD_TYPE', 8988 'UNION_TYPE' or 'QUAL_UNION_TYPE' then the 'INDEX' of each node in 8989 the sequence will be a 'FIELD_DECL' and the 'VALUE' will be the 8990 expression used to initialize that field. 8991 8992 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is an 'ARRAY_TYPE', then 8993 the 'INDEX' of each node in the sequence will be an 'INTEGER_CST' 8994 or a 'RANGE_EXPR' of two 'INTEGER_CST's. A single 'INTEGER_CST' 8995 indicates which element of the array is being assigned to. A 8996 'RANGE_EXPR' indicates an inclusive range of elements to 8997 initialize. In both cases the 'VALUE' is the corresponding 8998 initializer. It is re-evaluated for each element of a 8999 'RANGE_EXPR'. If the 'INDEX' is 'NULL_TREE', then the initializer 9000 is for the next available array element. 9001 9002 In the front end, you should not depend on the fields appearing in 9003 any particular order. However, in the middle end, fields must 9004 appear in declaration order. You should not assume that all fields 9005 will be represented. Unrepresented fields will be cleared 9006 (zeroed), unless the CONSTRUCTOR_NO_CLEARING flag is set, in which 9007 case their value becomes undefined. 9008 9009'COMPOUND_LITERAL_EXPR' 9010 These nodes represent ISO C99 compound literals. The 9011 'COMPOUND_LITERAL_EXPR_DECL_EXPR' is a 'DECL_EXPR' containing an 9012 anonymous 'VAR_DECL' for the unnamed object represented by the 9013 compound literal; the 'DECL_INITIAL' of that 'VAR_DECL' is a 9014 'CONSTRUCTOR' representing the brace-enclosed list of initializers 9015 in the compound literal. That anonymous 'VAR_DECL' can also be 9016 accessed directly by the 'COMPOUND_LITERAL_EXPR_DECL' macro. 9017 9018'SAVE_EXPR' 9019 9020 A 'SAVE_EXPR' represents an expression (possibly involving 9021 side-effects) that is used more than once. The side-effects should 9022 occur only the first time the expression is evaluated. Subsequent 9023 uses should just reuse the computed value. The first operand to 9024 the 'SAVE_EXPR' is the expression to evaluate. The side-effects 9025 should be executed where the 'SAVE_EXPR' is first encountered in a 9026 depth-first preorder traversal of the expression tree. 9027 9028'TARGET_EXPR' 9029 A 'TARGET_EXPR' represents a temporary object. The first operand 9030 is a 'VAR_DECL' for the temporary variable. The second operand is 9031 the initializer for the temporary. The initializer is evaluated 9032 and, if non-void, copied (bitwise) into the temporary. If the 9033 initializer is void, that means that it will perform the 9034 initialization itself. 9035 9036 Often, a 'TARGET_EXPR' occurs on the right-hand side of an 9037 assignment, or as the second operand to a comma-expression which is 9038 itself the right-hand side of an assignment, etc. In this case, we 9039 say that the 'TARGET_EXPR' is "normal"; otherwise, we say it is 9040 "orphaned". For a normal 'TARGET_EXPR' the temporary variable 9041 should be treated as an alias for the left-hand side of the 9042 assignment, rather than as a new temporary variable. 9043 9044 The third operand to the 'TARGET_EXPR', if present, is a 9045 cleanup-expression (i.e., destructor call) for the temporary. If 9046 this expression is orphaned, then this expression must be executed 9047 when the statement containing this expression is complete. These 9048 cleanups must always be executed in the order opposite to that in 9049 which they were encountered. Note that if a temporary is created 9050 on one branch of a conditional operator (i.e., in the second or 9051 third operand to a 'COND_EXPR'), the cleanup must be run only if 9052 that branch is actually executed. 9053 9054'VA_ARG_EXPR' 9055 This node is used to implement support for the C/C++ variable 9056 argument-list mechanism. It represents expressions like 'va_arg 9057 (ap, type)'. Its 'TREE_TYPE' yields the tree representation for 9058 'type' and its sole argument yields the representation for 'ap'. 9059 9060'ANNOTATE_EXPR' 9061 This node is used to attach markers to an expression. The first 9062 operand is the annotated expression, the second is an 'INTEGER_CST' 9063 with a value from 'enum annot_expr_kind'. 9064 9065 9066File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees 9067 906810.6.4 Vectors 9069-------------- 9070 9071'VEC_LSHIFT_EXPR' 9072'VEC_RSHIFT_EXPR' 9073 These nodes represent whole vector left and right shifts, 9074 respectively. The first operand is the vector to shift; it will 9075 always be of vector type. The second operand is an expression for 9076 the number of bits by which to shift. Note that the result is 9077 undefined if the second operand is larger than or equal to the 9078 first operand's type size. 9079 9080'VEC_WIDEN_MULT_HI_EXPR' 9081'VEC_WIDEN_MULT_LO_EXPR' 9082 These nodes represent widening vector multiplication of the high 9083 and low parts of the two input vectors, respectively. Their 9084 operands are vectors that contain the same number of elements ('N') 9085 of the same integral type. The result is a vector that contains 9086 half as many elements, of an integral type whose size is twice as 9087 wide. In the case of 'VEC_WIDEN_MULT_HI_EXPR' the high 'N/2' 9088 elements of the two vector are multiplied to produce the vector of 9089 'N/2' products. In the case of 'VEC_WIDEN_MULT_LO_EXPR' the low 9090 'N/2' elements of the two vector are multiplied to produce the 9091 vector of 'N/2' products. 9092 9093'VEC_UNPACK_HI_EXPR' 9094'VEC_UNPACK_LO_EXPR' 9095 These nodes represent unpacking of the high and low parts of the 9096 input vector, respectively. The single operand is a vector that 9097 contains 'N' elements of the same integral or floating point type. 9098 The result is a vector that contains half as many elements, of an 9099 integral or floating point type whose size is twice as wide. In 9100 the case of 'VEC_UNPACK_HI_EXPR' the high 'N/2' elements of the 9101 vector are extracted and widened (promoted). In the case of 9102 'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the vector are 9103 extracted and widened (promoted). 9104 9105'VEC_UNPACK_FLOAT_HI_EXPR' 9106'VEC_UNPACK_FLOAT_LO_EXPR' 9107 These nodes represent unpacking of the high and low parts of the 9108 input vector, where the values are converted from fixed point to 9109 floating point. The single operand is a vector that contains 'N' 9110 elements of the same integral type. The result is a vector that 9111 contains half as many elements of a floating point type whose size 9112 is twice as wide. In the case of 'VEC_UNPACK_HI_EXPR' the high 9113 'N/2' elements of the vector are extracted, converted and widened. 9114 In the case of 'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the 9115 vector are extracted, converted and widened. 9116 9117'VEC_PACK_TRUNC_EXPR' 9118 This node represents packing of truncated elements of the two input 9119 vectors into the output vector. Input operands are vectors that 9120 contain the same number of elements of the same integral or 9121 floating point type. The result is a vector that contains twice as 9122 many elements of an integral or floating point type whose size is 9123 half as wide. The elements of the two vectors are demoted and 9124 merged (concatenated) to form the output vector. 9125 9126'VEC_PACK_SAT_EXPR' 9127 This node represents packing of elements of the two input vectors 9128 into the output vector using saturation. Input operands are 9129 vectors that contain the same number of elements of the same 9130 integral type. The result is a vector that contains twice as many 9131 elements of an integral type whose size is half as wide. The 9132 elements of the two vectors are demoted and merged (concatenated) 9133 to form the output vector. 9134 9135'VEC_PACK_FIX_TRUNC_EXPR' 9136 This node represents packing of elements of the two input vectors 9137 into the output vector, where the values are converted from 9138 floating point to fixed point. Input operands are vectors that 9139 contain the same number of elements of a floating point type. The 9140 result is a vector that contains twice as many elements of an 9141 integral type whose size is half as wide. The elements of the two 9142 vectors are merged (concatenated) to form the output vector. 9143 9144'VEC_COND_EXPR' 9145 These nodes represent '?:' expressions. The three operands must be 9146 vectors of the same size and number of elements. The second and 9147 third operands must have the same type as the entire expression. 9148 The first operand is of signed integral vector type. If an element 9149 of the first operand evaluates to a zero value, the corresponding 9150 element of the result is taken from the third operand. If it 9151 evaluates to a minus one value, it is taken from the second 9152 operand. It should never evaluate to any other value currently, 9153 but optimizations should not rely on that property. In contrast 9154 with a 'COND_EXPR', all operands are always evaluated. 9155 9156'SAD_EXPR' 9157 This node represents the Sum of Absolute Differences operation. 9158 The three operands must be vectors of integral types. The first 9159 and second operand must have the same type. The size of the vector 9160 element of the third operand must be at lease twice of the size of 9161 the vector element of the first and second one. The SAD is 9162 calculated between the first and second operands, added to the 9163 third operand, and returned. 9164 9165 9166File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC 9167 916810.7 Statements 9169=============== 9170 9171Most statements in GIMPLE are assignment statements, represented by 9172'GIMPLE_ASSIGN'. No other C expressions can appear at statement level; 9173a reference to a volatile object is converted into a 'GIMPLE_ASSIGN'. 9174 9175 There are also several varieties of complex statements. 9176 9177* Menu: 9178 9179* Basic Statements:: 9180* Blocks:: 9181* Statement Sequences:: 9182* Empty Statements:: 9183* Jumps:: 9184* Cleanups:: 9185* OpenMP:: 9186* OpenACC:: 9187 9188 9189File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements 9190 919110.7.1 Basic Statements 9192----------------------- 9193 9194'ASM_EXPR' 9195 9196 Used to represent an inline assembly statement. For an inline 9197 assembly statement like: 9198 asm ("mov x, y"); 9199 The 'ASM_STRING' macro will return a 'STRING_CST' node for '"mov x, 9200 y"'. If the original statement made use of the extended-assembly 9201 syntax, then 'ASM_OUTPUTS', 'ASM_INPUTS', and 'ASM_CLOBBERS' will 9202 be the outputs, inputs, and clobbers for the statement, represented 9203 as 'STRING_CST' nodes. The extended-assembly syntax looks like: 9204 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 9205 The first string is the 'ASM_STRING', containing the instruction 9206 template. The next two strings are the output and inputs, 9207 respectively; this statement has no clobbers. As this example 9208 indicates, "plain" assembly statements are merely a special case of 9209 extended assembly statements; they have no cv-qualifiers, outputs, 9210 inputs, or clobbers. All of the strings will be 'NUL'-terminated, 9211 and will contain no embedded 'NUL'-characters. 9212 9213 If the assembly statement is declared 'volatile', or if the 9214 statement was not an extended assembly statement, and is therefore 9215 implicitly volatile, then the predicate 'ASM_VOLATILE_P' will hold 9216 of the 'ASM_EXPR'. 9217 9218'DECL_EXPR' 9219 9220 Used to represent a local declaration. The 'DECL_EXPR_DECL' macro 9221 can be used to obtain the entity declared. This declaration may be 9222 a 'LABEL_DECL', indicating that the label declared is a local 9223 label. (As an extension, GCC allows the declaration of labels with 9224 scope.) In C, this declaration may be a 'FUNCTION_DECL', 9225 indicating the use of the GCC nested function extension. For more 9226 information, *note Functions::. 9227 9228'LABEL_EXPR' 9229 9230 Used to represent a label. The 'LABEL_DECL' declared by this 9231 statement can be obtained with the 'LABEL_EXPR_LABEL' macro. The 9232 'IDENTIFIER_NODE' giving the name of the label can be obtained from 9233 the 'LABEL_DECL' with 'DECL_NAME'. 9234 9235'GOTO_EXPR' 9236 9237 Used to represent a 'goto' statement. The 'GOTO_DESTINATION' will 9238 usually be a 'LABEL_DECL'. However, if the "computed goto" 9239 extension has been used, the 'GOTO_DESTINATION' will be an 9240 arbitrary expression indicating the destination. This expression 9241 will always have pointer type. 9242 9243'RETURN_EXPR' 9244 9245 Used to represent a 'return' statement. Operand 0 represents the 9246 value to return. It should either be the 'RESULT_DECL' for the 9247 containing function, or a 'MODIFY_EXPR' or 'INIT_EXPR' setting the 9248 function's 'RESULT_DECL'. It will be 'NULL_TREE' if the statement 9249 was just 9250 return; 9251 9252'LOOP_EXPR' 9253 These nodes represent "infinite" loops. The 'LOOP_EXPR_BODY' 9254 represents the body of the loop. It should be executed forever, 9255 unless an 'EXIT_EXPR' is encountered. 9256 9257'EXIT_EXPR' 9258 These nodes represent conditional exits from the nearest enclosing 9259 'LOOP_EXPR'. The single operand is the condition; if it is 9260 nonzero, then the loop should be exited. An 'EXIT_EXPR' will only 9261 appear within a 'LOOP_EXPR'. 9262 9263'SWITCH_STMT' 9264 9265 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 9266 the expression on which the switch is occurring. See the 9267 documentation for an 'IF_STMT' for more information on the 9268 representation used for the condition. The 'SWITCH_STMT_BODY' is 9269 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 9270 original type of switch expression as given in the source, before 9271 any compiler conversions. 9272 9273'CASE_LABEL_EXPR' 9274 9275 Use to represent a 'case' label, range of 'case' labels, or a 9276 'default' label. If 'CASE_LOW' is 'NULL_TREE', then this is a 9277 'default' label. Otherwise, if 'CASE_HIGH' is 'NULL_TREE', then 9278 this is an ordinary 'case' label. In this case, 'CASE_LOW' is an 9279 expression giving the value of the label. Both 'CASE_LOW' and 9280 'CASE_HIGH' are 'INTEGER_CST' nodes. These values will have the 9281 same type as the condition expression in the switch statement. 9282 9283 Otherwise, if both 'CASE_LOW' and 'CASE_HIGH' are defined, the 9284 statement is a range of case labels. Such statements originate 9285 with the extension that allows users to write things of the form: 9286 case 2 ... 5: 9287 The first value will be 'CASE_LOW', while the second will be 9288 'CASE_HIGH'. 9289 9290 9291File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements 9292 929310.7.2 Blocks 9294------------- 9295 9296Block scopes and the variables they declare in GENERIC are expressed 9297using the 'BIND_EXPR' code, which in previous versions of GCC was 9298primarily used for the C statement-expression extension. 9299 9300 Variables in a block are collected into 'BIND_EXPR_VARS' in declaration 9301order through their 'TREE_CHAIN' field. Any runtime initialization is 9302moved out of 'DECL_INITIAL' and into a statement in the controlled 9303block. When gimplifying from C or C++, this initialization replaces the 9304'DECL_STMT'. These variables will never require cleanups. The scope of 9305these variables is just the body 9306 9307 Variable-length arrays (VLAs) complicate this process, as their size 9308often refers to variables initialized earlier in the block and their 9309initialization involves an explicit stack allocation. To handle this, 9310we add an indirection and replace them with a pointer to stack space 9311allocated by means of 'alloca'. In most cases, we also arrange for this 9312space to be reclaimed when the enclosing 'BIND_EXPR' is exited, the 9313exception to this being when there is an explicit call to 'alloca' in 9314the source code, in which case the stack is left depressed on exit of 9315the 'BIND_EXPR'. 9316 9317 A C++ program will usually contain more 'BIND_EXPR's than there are 9318syntactic blocks in the source code, since several C++ constructs have 9319implicit scopes associated with them. On the other hand, although the 9320C++ front end uses pseudo-scopes to handle cleanups for objects with 9321destructors, these don't translate into the GIMPLE form; multiple 9322declarations at the same level use the same 'BIND_EXPR'. 9323 9324 9325File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 9326 932710.7.3 Statement Sequences 9328-------------------------- 9329 9330Multiple statements at the same nesting level are collected into a 9331'STATEMENT_LIST'. Statement lists are modified and traversed using the 9332interface in 'tree-iterator.h'. 9333 9334 9335File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements 9336 933710.7.4 Empty Statements 9338----------------------- 9339 9340Whenever possible, statements with no effect are discarded. But if they 9341are nested within another construct which cannot be discarded for some 9342reason, they are instead replaced with an empty statement, generated by 9343'build_empty_stmt'. Initially, all empty statements were shared, after 9344the pattern of the Java front end, but this caused a lot of trouble in 9345practice. 9346 9347 An empty statement is represented as '(void)0'. 9348 9349 9350File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements 9351 935210.7.5 Jumps 9353------------ 9354 9355Other jumps are expressed by either 'GOTO_EXPR' or 'RETURN_EXPR'. 9356 9357 The operand of a 'GOTO_EXPR' must be either a label or a variable 9358containing the address to jump to. 9359 9360 The operand of a 'RETURN_EXPR' is either 'NULL_TREE', 'RESULT_DECL', or 9361a 'MODIFY_EXPR' which sets the return value. It would be nice to move 9362the 'MODIFY_EXPR' into a separate statement, but the special return 9363semantics in 'expand_return' make that difficult. It may still happen 9364in the future, perhaps by moving most of that logic into 9365'expand_assignment'. 9366 9367 9368File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements 9369 937010.7.6 Cleanups 9371--------------- 9372 9373Destructors for local C++ objects and similar dynamic cleanups are 9374represented in GIMPLE by a 'TRY_FINALLY_EXPR'. 'TRY_FINALLY_EXPR' has 9375two operands, both of which are a sequence of statements to execute. 9376The first sequence is executed. When it completes the second sequence 9377is executed. 9378 9379 The first sequence may complete in the following ways: 9380 9381 1. Execute the last statement in the sequence and fall off the end. 9382 9383 2. Execute a goto statement ('GOTO_EXPR') to an ordinary label outside 9384 the sequence. 9385 9386 3. Execute a return statement ('RETURN_EXPR'). 9387 9388 4. Throw an exception. This is currently not explicitly represented 9389 in GIMPLE. 9390 9391 The second sequence is not executed if the first sequence completes by 9392calling 'setjmp' or 'exit' or any other function that does not return. 9393The second sequence is also not executed if the first sequence completes 9394via a non-local goto or a computed goto (in general the compiler does 9395not know whether such a goto statement exits the first sequence or not, 9396so we assume that it doesn't). 9397 9398 After the second sequence is executed, if it completes normally by 9399falling off the end, execution continues wherever the first sequence 9400would have continued, by falling off the end, or doing a goto, etc. 9401 9402 'TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 9403to appear on every edge out of the controlled block; this reduces the 9404freedom to move code across these edges. Therefore, the EH lowering 9405pass which runs before most of the optimization passes eliminates these 9406expressions by explicitly adding the cleanup to each edge. Rethrowing 9407the exception is represented using 'RESX_EXPR'. 9408 9409 9410File: gccint.info, Node: OpenMP, Next: OpenACC, Prev: Cleanups, Up: Statements 9411 941210.7.7 OpenMP 9413------------- 9414 9415All the statements starting with 'OMP_' represent directives and clauses 9416used by the OpenMP API <http://www.openmp.org/>. 9417 9418'OMP_PARALLEL' 9419 9420 Represents '#pragma omp parallel [clause1 ... clauseN]'. It has 9421 four operands: 9422 9423 Operand 'OMP_PARALLEL_BODY' is valid while in GENERIC and High 9424 GIMPLE forms. It contains the body of code to be executed by all 9425 the threads. During GIMPLE lowering, this operand becomes 'NULL' 9426 and the body is emitted linearly after 'OMP_PARALLEL'. 9427 9428 Operand 'OMP_PARALLEL_CLAUSES' is the list of clauses associated 9429 with the directive. 9430 9431 Operand 'OMP_PARALLEL_FN' is created by 'pass_lower_omp', it 9432 contains the 'FUNCTION_DECL' for the function that will contain the 9433 body of the parallel region. 9434 9435 Operand 'OMP_PARALLEL_DATA_ARG' is also created by 9436 'pass_lower_omp'. If there are shared variables to be communicated 9437 to the children threads, this operand will contain the 'VAR_DECL' 9438 that contains all the shared values and variables. 9439 9440'OMP_FOR' 9441 9442 Represents '#pragma omp for [clause1 ... clauseN]'. It has six 9443 operands: 9444 9445 Operand 'OMP_FOR_BODY' contains the loop body. 9446 9447 Operand 'OMP_FOR_CLAUSES' is the list of clauses associated with 9448 the directive. 9449 9450 Operand 'OMP_FOR_INIT' is the loop initialization code of the form 9451 'VAR = N1'. 9452 9453 Operand 'OMP_FOR_COND' is the loop conditional expression of the 9454 form 'VAR {<,>,<=,>=} N2'. 9455 9456 Operand 'OMP_FOR_INCR' is the loop index increment of the form 'VAR 9457 {+=,-=} INCR'. 9458 9459 Operand 'OMP_FOR_PRE_BODY' contains side-effect code from operands 9460 'OMP_FOR_INIT', 'OMP_FOR_COND' and 'OMP_FOR_INC'. These 9461 side-effects are part of the 'OMP_FOR' block but must be evaluated 9462 before the start of loop body. 9463 9464 The loop index variable 'VAR' must be a signed integer variable, 9465 which is implicitly private to each thread. Bounds 'N1' and 'N2' 9466 and the increment expression 'INCR' are required to be loop 9467 invariant integer expressions that are evaluated without any 9468 synchronization. The evaluation order, frequency of evaluation and 9469 side-effects are unspecified by the standard. 9470 9471'OMP_SECTIONS' 9472 9473 Represents '#pragma omp sections [clause1 ... clauseN]'. 9474 9475 Operand 'OMP_SECTIONS_BODY' contains the sections body, which in 9476 turn contains a set of 'OMP_SECTION' nodes for each of the 9477 concurrent sections delimited by '#pragma omp section'. 9478 9479 Operand 'OMP_SECTIONS_CLAUSES' is the list of clauses associated 9480 with the directive. 9481 9482'OMP_SECTION' 9483 9484 Section delimiter for 'OMP_SECTIONS'. 9485 9486'OMP_SINGLE' 9487 9488 Represents '#pragma omp single'. 9489 9490 Operand 'OMP_SINGLE_BODY' contains the body of code to be executed 9491 by a single thread. 9492 9493 Operand 'OMP_SINGLE_CLAUSES' is the list of clauses associated with 9494 the directive. 9495 9496'OMP_MASTER' 9497 9498 Represents '#pragma omp master'. 9499 9500 Operand 'OMP_MASTER_BODY' contains the body of code to be executed 9501 by the master thread. 9502 9503'OMP_ORDERED' 9504 9505 Represents '#pragma omp ordered'. 9506 9507 Operand 'OMP_ORDERED_BODY' contains the body of code to be executed 9508 in the sequential order dictated by the loop index variable. 9509 9510'OMP_CRITICAL' 9511 9512 Represents '#pragma omp critical [name]'. 9513 9514 Operand 'OMP_CRITICAL_BODY' is the critical section. 9515 9516 Operand 'OMP_CRITICAL_NAME' is an optional identifier to label the 9517 critical section. 9518 9519'OMP_RETURN' 9520 9521 This does not represent any OpenMP directive, it is an artificial 9522 marker to indicate the end of the body of an OpenMP. It is used by 9523 the flow graph ('tree-cfg.c') and OpenMP region building code 9524 ('omp-low.c'). 9525 9526'OMP_CONTINUE' 9527 9528 Similarly, this instruction does not represent an OpenMP directive, 9529 it is used by 'OMP_FOR' (and similar codes) as well as 9530 'OMP_SECTIONS' to mark the place where the code needs to loop to 9531 the next iteration, or the next section, respectively. 9532 9533 In some cases, 'OMP_CONTINUE' is placed right before 'OMP_RETURN'. 9534 But if there are cleanups that need to occur right after the 9535 looping body, it will be emitted between 'OMP_CONTINUE' and 9536 'OMP_RETURN'. 9537 9538'OMP_ATOMIC' 9539 9540 Represents '#pragma omp atomic'. 9541 9542 Operand 0 is the address at which the atomic operation is to be 9543 performed. 9544 9545 Operand 1 is the expression to evaluate. The gimplifier tries 9546 three alternative code generation strategies. Whenever possible, 9547 an atomic update built-in is used. If that fails, a 9548 compare-and-swap loop is attempted. If that also fails, a regular 9549 critical section around the expression is used. 9550 9551'OMP_CLAUSE' 9552 9553 Represents clauses associated with one of the 'OMP_' directives. 9554 Clauses are represented by separate subcodes defined in 'tree.h'. 9555 Clauses codes can be one of: 'OMP_CLAUSE_PRIVATE', 9556 'OMP_CLAUSE_SHARED', 'OMP_CLAUSE_FIRSTPRIVATE', 9557 'OMP_CLAUSE_LASTPRIVATE', 'OMP_CLAUSE_COPYIN', 9558 'OMP_CLAUSE_COPYPRIVATE', 'OMP_CLAUSE_IF', 9559 'OMP_CLAUSE_NUM_THREADS', 'OMP_CLAUSE_SCHEDULE', 9560 'OMP_CLAUSE_NOWAIT', 'OMP_CLAUSE_ORDERED', 'OMP_CLAUSE_DEFAULT', 9561 'OMP_CLAUSE_REDUCTION', 'OMP_CLAUSE_COLLAPSE', 'OMP_CLAUSE_UNTIED', 9562 'OMP_CLAUSE_FINAL', and 'OMP_CLAUSE_MERGEABLE'. Each code 9563 represents the corresponding OpenMP clause. 9564 9565 Clauses associated with the same directive are chained together via 9566 'OMP_CLAUSE_CHAIN'. Those clauses that accept a list of variables 9567 are restricted to exactly one, accessed with 'OMP_CLAUSE_VAR'. 9568 Therefore, multiple variables under the same clause 'C' need to be 9569 represented as multiple 'C' clauses chained together. This 9570 facilitates adding new clauses during compilation. 9571 9572 9573File: gccint.info, Node: OpenACC, Prev: OpenMP, Up: Statements 9574 957510.7.8 OpenACC 9576-------------- 9577 9578All the statements starting with 'OACC_' represent directives and 9579clauses used by the OpenACC API <http://www.openacc.org/>. 9580 9581'OACC_CACHE' 9582 9583 Represents '#pragma acc cache (var ...)'. 9584 9585'OACC_DATA' 9586 9587 Represents '#pragma acc data [clause1 ... clauseN]'. 9588 9589'OACC_DECLARE' 9590 9591 Represents '#pragma acc declare [clause1 ... clauseN]'. 9592 9593'OACC_ENTER_DATA' 9594 9595 Represents '#pragma acc enter data [clause1 ... clauseN]'. 9596 9597'OACC_EXIT_DATA' 9598 9599 Represents '#pragma acc exit data [clause1 ... clauseN]'. 9600 9601'OACC_HOST_DATA' 9602 9603 Represents '#pragma acc host_data [clause1 ... clauseN]'. 9604 9605'OACC_KERNELS' 9606 9607 Represents '#pragma acc kernels [clause1 ... clauseN]'. 9608 9609'OACC_LOOP' 9610 9611 Represents '#pragma acc loop [clause1 ... clauseN]'. 9612 9613 See the description of the 'OMP_FOR' code. 9614 9615'OACC_PARALLEL' 9616 9617 Represents '#pragma acc parallel [clause1 ... clauseN]'. 9618 9619'OACC_UPDATE' 9620 9621 Represents '#pragma acc update [clause1 ... clauseN]'. 9622 9623 9624File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC 9625 962610.8 Functions 9627============== 9628 9629A function is represented by a 'FUNCTION_DECL' node. It stores the 9630basic pieces of the function such as body, parameters, and return type 9631as well as information on the surrounding context, visibility, and 9632linkage. 9633 9634* Menu: 9635 9636* Function Basics:: Function names, body, and parameters. 9637* Function Properties:: Context, linkage, etc. 9638 9639 9640File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions 9641 964210.8.1 Function Basics 9643---------------------- 9644 9645A function has four core parts: the name, the parameters, the result, 9646and the body. The following macros and functions access these parts of 9647a 'FUNCTION_DECL' as well as other basic features: 9648'DECL_NAME' 9649 This macro returns the unqualified name of the function, as an 9650 'IDENTIFIER_NODE'. For an instantiation of a function template, 9651 the 'DECL_NAME' is the unqualified name of the template, not 9652 something like 'f<int>'. The value of 'DECL_NAME' is undefined 9653 when used on a constructor, destructor, overloaded operator, or 9654 type-conversion operator, or any function that is implicitly 9655 generated by the compiler. See below for macros that can be used 9656 to distinguish these cases. 9657 9658'DECL_ASSEMBLER_NAME' 9659 This macro returns the mangled name of the function, also an 9660 'IDENTIFIER_NODE'. This name does not contain leading underscores 9661 on systems that prefix all identifiers with underscores. The 9662 mangled name is computed in the same way on all platforms; if 9663 special processing is required to deal with the object file format 9664 used on a particular platform, it is the responsibility of the back 9665 end to perform those modifications. (Of course, the back end 9666 should not modify 'DECL_ASSEMBLER_NAME' itself.) 9667 9668 Using 'DECL_ASSEMBLER_NAME' will cause additional memory to be 9669 allocated (for the mangled name of the entity) so it should be used 9670 only when emitting assembly code. It should not be used within the 9671 optimizers to determine whether or not two declarations are the 9672 same, even though some of the existing optimizers do use it in that 9673 way. These uses will be removed over time. 9674 9675'DECL_ARGUMENTS' 9676 This macro returns the 'PARM_DECL' for the first argument to the 9677 function. Subsequent 'PARM_DECL' nodes can be obtained by 9678 following the 'TREE_CHAIN' links. 9679 9680'DECL_RESULT' 9681 This macro returns the 'RESULT_DECL' for the function. 9682 9683'DECL_SAVED_TREE' 9684 This macro returns the complete body of the function. 9685 9686'TREE_TYPE' 9687 This macro returns the 'FUNCTION_TYPE' or 'METHOD_TYPE' for the 9688 function. 9689 9690'DECL_INITIAL' 9691 A function that has a definition in the current translation unit 9692 will have a non-'NULL' 'DECL_INITIAL'. However, back ends should 9693 not make use of the particular value given by 'DECL_INITIAL'. 9694 9695 It should contain a tree of 'BLOCK' nodes that mirrors the scopes 9696 that variables are bound in the function. Each block contains a 9697 list of decls declared in a basic block, a pointer to a chain of 9698 blocks at the next lower scope level, then a pointer to the next 9699 block at the same level and a backpointer to the parent 'BLOCK' or 9700 'FUNCTION_DECL'. So given a function as follows: 9701 9702 void foo() 9703 { 9704 int a; 9705 { 9706 int b; 9707 } 9708 int c; 9709 } 9710 9711 you would get the following: 9712 9713 tree foo = FUNCTION_DECL; 9714 tree decl_a = VAR_DECL; 9715 tree decl_b = VAR_DECL; 9716 tree decl_c = VAR_DECL; 9717 tree block_a = BLOCK; 9718 tree block_b = BLOCK; 9719 tree block_c = BLOCK; 9720 BLOCK_VARS(block_a) = decl_a; 9721 BLOCK_SUBBLOCKS(block_a) = block_b; 9722 BLOCK_CHAIN(block_a) = block_c; 9723 BLOCK_SUPERCONTEXT(block_a) = foo; 9724 BLOCK_VARS(block_b) = decl_b; 9725 BLOCK_SUPERCONTEXT(block_b) = block_a; 9726 BLOCK_VARS(block_c) = decl_c; 9727 BLOCK_SUPERCONTEXT(block_c) = foo; 9728 DECL_INITIAL(foo) = block_a; 9729 9730 9731File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions 9732 973310.8.2 Function Properties 9734-------------------------- 9735 9736To determine the scope of a function, you can use the 'DECL_CONTEXT' 9737macro. This macro will return the class (either a 'RECORD_TYPE' or a 9738'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 9739a member. For a virtual function, this macro returns the class in which 9740the function was actually defined, not the base class in which the 9741virtual declaration occurred. 9742 9743 In C, the 'DECL_CONTEXT' for a function maybe another function. This 9744representation indicates that the GNU nested function extension is in 9745use. For details on the semantics of nested functions, see the GCC 9746Manual. The nested function can refer to local variables in its 9747containing function. Such references are not explicitly marked in the 9748tree structure; back ends must look at the 'DECL_CONTEXT' for the 9749referenced 'VAR_DECL'. If the 'DECL_CONTEXT' for the referenced 9750'VAR_DECL' is not the same as the function currently being processed, 9751and neither 'DECL_EXTERNAL' nor 'TREE_STATIC' hold, then the reference 9752is to a local variable in a containing function, and the back end must 9753take appropriate action. 9754 9755'DECL_EXTERNAL' 9756 This predicate holds if the function is undefined. 9757 9758'TREE_PUBLIC' 9759 This predicate holds if the function has external linkage. 9760 9761'TREE_STATIC' 9762 This predicate holds if the function has been defined. 9763 9764'TREE_THIS_VOLATILE' 9765 This predicate holds if the function does not return normally. 9766 9767'TREE_READONLY' 9768 This predicate holds if the function can only read its arguments. 9769 9770'DECL_PURE_P' 9771 This predicate holds if the function can only read its arguments, 9772 but may also read global memory. 9773 9774'DECL_VIRTUAL_P' 9775 This predicate holds if the function is virtual. 9776 9777'DECL_ARTIFICIAL' 9778 This macro holds if the function was implicitly generated by the 9779 compiler, rather than explicitly declared. In addition to 9780 implicitly generated class member functions, this macro holds for 9781 the special functions created to implement static initialization 9782 and destruction, to compute run-time type information, and so 9783 forth. 9784 9785'DECL_FUNCTION_SPECIFIC_TARGET' 9786 This macro returns a tree node that holds the target options that 9787 are to be used to compile this particular function or 'NULL_TREE' 9788 if the function is to be compiled with the target options specified 9789 on the command line. 9790 9791'DECL_FUNCTION_SPECIFIC_OPTIMIZATION' 9792 This macro returns a tree node that holds the optimization options 9793 that are to be used to compile this particular function or 9794 'NULL_TREE' if the function is to be compiled with the optimization 9795 options specified on the command line. 9796 9797 9798File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC 9799 980010.9 Language-dependent trees 9801============================= 9802 9803Front ends may wish to keep some state associated with various GENERIC 9804trees while parsing. To support this, trees provide a set of flags that 9805may be used by the front end. They are accessed using 9806'TREE_LANG_FLAG_n' where 'n' is currently 0 through 6. 9807 9808 If necessary, a front end can use some language-dependent tree codes in 9809its GENERIC representation, so long as it provides a hook for converting 9810them to GIMPLE and doesn't expect them to work with any (hypothetical) 9811optimizers that run before the conversion to GIMPLE. The intermediate 9812representation used while parsing C and C++ looks very little like 9813GENERIC, but the C and C++ gimplifier hooks are perfectly happy to take 9814it as input and spit out GIMPLE. 9815 9816 9817File: gccint.info, Node: C and C++ Trees, Next: Java Trees, Prev: Language-dependent trees, Up: GENERIC 9818 981910.10 C and C++ Trees 9820===================== 9821 9822This section documents the internal representation used by GCC to 9823represent C and C++ source programs. When presented with a C or C++ 9824source program, GCC parses the program, performs semantic analysis 9825(including the generation of error messages), and then produces the 9826internal representation described here. This representation contains a 9827complete representation for the entire translation unit provided as 9828input to the front end. This representation is then typically processed 9829by a code-generator in order to produce machine code, but could also be 9830used in the creation of source browsers, intelligent editors, automatic 9831documentation generators, interpreters, and any other programs needing 9832the ability to process C or C++ code. 9833 9834 This section explains the internal representation. In particular, it 9835documents the internal representation for C and C++ source constructs, 9836and the macros, functions, and variables that can be used to access 9837these constructs. The C++ representation is largely a superset of the 9838representation used in the C front end. There is only one construct 9839used in C that does not appear in the C++ front end and that is the GNU 9840"nested function" extension. Many of the macros documented here do not 9841apply in C because the corresponding language constructs do not appear 9842in C. 9843 9844 The C and C++ front ends generate a mix of GENERIC trees and ones 9845specific to C and C++. These language-specific trees are higher-level 9846constructs than the ones in GENERIC to make the parser's job easier. 9847This section describes those trees that aren't part of GENERIC as well 9848as aspects of GENERIC trees that are treated in a language-specific 9849manner. 9850 9851 If you are developing a "back end", be it is a code-generator or some 9852other tool, that uses this representation, you may occasionally find 9853that you need to ask questions not easily answered by the functions and 9854macros available here. If that situation occurs, it is quite likely 9855that GCC already supports the functionality you desire, but that the 9856interface is simply not documented here. In that case, you should ask 9857the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting 9858the functionality you require. Similarly, if you find yourself writing 9859functions that do not deal directly with your back end, but instead 9860might be useful to other people using the GCC front end, you should 9861submit your patches for inclusion in GCC. 9862 9863* Menu: 9864 9865* Types for C++:: Fundamental and aggregate types. 9866* Namespaces:: Namespaces. 9867* Classes:: Classes. 9868* Functions for C++:: Overloading and accessors for C++. 9869* Statements for C++:: Statements specific to C and C++. 9870* C++ Expressions:: From 'typeid' to 'throw'. 9871 9872 9873File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees 9874 987510.10.1 Types for C++ 9876--------------------- 9877 9878In C++, an array type is not qualified; rather the type of the array 9879elements is qualified. This situation is reflected in the intermediate 9880representation. The macros described here will always examine the 9881qualification of the underlying element type when applied to an array 9882type. (If the element type is itself an array, then the recursion 9883continues until a non-array type is found, and the qualification of this 9884type is examined.) So, for example, 'CP_TYPE_CONST_P' will hold of the 9885type 'const int ()[7]', denoting an array of seven 'int's. 9886 9887 The following functions and macros deal with cv-qualification of types: 9888'cp_type_quals' 9889 This function returns the set of type qualifiers applied to this 9890 type. This value is 'TYPE_UNQUALIFIED' if no qualifiers have been 9891 applied. The 'TYPE_QUAL_CONST' bit is set if the type is 9892 'const'-qualified. The 'TYPE_QUAL_VOLATILE' bit is set if the type 9893 is 'volatile'-qualified. The 'TYPE_QUAL_RESTRICT' bit is set if 9894 the type is 'restrict'-qualified. 9895 9896'CP_TYPE_CONST_P' 9897 This macro holds if the type is 'const'-qualified. 9898 9899'CP_TYPE_VOLATILE_P' 9900 This macro holds if the type is 'volatile'-qualified. 9901 9902'CP_TYPE_RESTRICT_P' 9903 This macro holds if the type is 'restrict'-qualified. 9904 9905'CP_TYPE_CONST_NON_VOLATILE_P' 9906 This predicate holds for a type that is 'const'-qualified, but 9907 _not_ 'volatile'-qualified; other cv-qualifiers are ignored as 9908 well: only the 'const'-ness is tested. 9909 9910 A few other macros and functions are usable with all types: 9911'TYPE_SIZE' 9912 The number of bits required to represent the type, represented as 9913 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 9914 'NULL_TREE'. 9915 9916'TYPE_ALIGN' 9917 The alignment of the type, in bits, represented as an 'int'. 9918 9919'TYPE_NAME' 9920 This macro returns a declaration (in the form of a 'TYPE_DECL') for 9921 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 9922 as you might expect, given its name!) You can look at the 9923 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 9924 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 9925 built-in type, the result of a typedef, or a named class type. 9926 9927'CP_INTEGRAL_TYPE' 9928 This predicate holds if the type is an integral type. Notice that 9929 in C++, enumerations are _not_ integral types. 9930 9931'ARITHMETIC_TYPE_P' 9932 This predicate holds if the type is an integral type (in the C++ 9933 sense) or a floating point type. 9934 9935'CLASS_TYPE_P' 9936 This predicate holds for a class-type. 9937 9938'TYPE_BUILT_IN' 9939 This predicate holds for a built-in type. 9940 9941'TYPE_PTRDATAMEM_P' 9942 This predicate holds if the type is a pointer to data member. 9943 9944'TYPE_PTR_P' 9945 This predicate holds if the type is a pointer type, and the pointee 9946 is not a data member. 9947 9948'TYPE_PTRFN_P' 9949 This predicate holds for a pointer to function type. 9950 9951'TYPE_PTROB_P' 9952 This predicate holds for a pointer to object type. Note however 9953 that it does not hold for the generic pointer to object type 'void 9954 *'. You may use 'TYPE_PTROBV_P' to test for a pointer to object 9955 type as well as 'void *'. 9956 9957 The table below describes types specific to C and C++ as well as 9958language-dependent info about GENERIC types. 9959 9960'POINTER_TYPE' 9961 Used to represent pointer types, and pointer to data member types. 9962 If 'TREE_TYPE' is a pointer to data member type, then 9963 'TYPE_PTRDATAMEM_P' will hold. For a pointer to data member type 9964 of the form 'T X::*', 'TYPE_PTRMEM_CLASS_TYPE' will be the type 9965 'X', while 'TYPE_PTRMEM_POINTED_TO_TYPE' will be the type 'T'. 9966 9967'RECORD_TYPE' 9968 Used to represent 'struct' and 'class' types in C and C++. If 9969 'TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 9970 type. In that case, the 'TYPE_PTRMEMFUNC_FN_TYPE' is a 9971 'POINTER_TYPE' pointing to a 'METHOD_TYPE'. The 'METHOD_TYPE' is 9972 the type of a function pointed to by the pointer-to-member 9973 function. If 'TYPE_PTRMEMFUNC_P' does not hold, this type is a 9974 class type. For more information, *note Classes::. 9975 9976'UNKNOWN_TYPE' 9977 This node is used to represent a type the knowledge of which is 9978 insufficient for a sound processing. 9979 9980'TYPENAME_TYPE' 9981 Used to represent a construct of the form 'typename T::A'. The 9982 'TYPE_CONTEXT' is 'T'; the 'TYPE_NAME' is an 'IDENTIFIER_NODE' for 9983 'A'. If the type is specified via a template-id, then 9984 'TYPENAME_TYPE_FULLNAME' yields a 'TEMPLATE_ID_EXPR'. The 9985 'TREE_TYPE' is non-'NULL' if the node is implicitly generated in 9986 support for the implicit typename extension; in which case the 9987 'TREE_TYPE' is a type node for the base-class. 9988 9989'TYPEOF_TYPE' 9990 Used to represent the '__typeof__' extension. The 'TYPE_FIELDS' is 9991 the expression the type of which is being represented. 9992 9993 9994File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees 9995 999610.10.2 Namespaces 9997------------------ 9998 9999The root of the entire intermediate representation is the variable 10000'global_namespace'. This is the namespace specified with '::' in C++ 10001source code. All other namespaces, types, variables, functions, and so 10002forth can be found starting with this namespace. 10003 10004 However, except for the fact that it is distinguished as the root of 10005the representation, the global namespace is no different from any other 10006namespace. Thus, in what follows, we describe namespaces generally, 10007rather than the global namespace in particular. 10008 10009 A namespace is represented by a 'NAMESPACE_DECL' node. 10010 10011 The following macros and functions can be used on a 'NAMESPACE_DECL': 10012 10013'DECL_NAME' 10014 This macro is used to obtain the 'IDENTIFIER_NODE' corresponding to 10015 the unqualified name of the name of the namespace (*note 10016 Identifiers::). The name of the global namespace is '::', even 10017 though in C++ the global namespace is unnamed. However, you should 10018 use comparison with 'global_namespace', rather than 'DECL_NAME' to 10019 determine whether or not a namespace is the global one. An unnamed 10020 namespace will have a 'DECL_NAME' equal to 10021 'anonymous_namespace_name'. Within a single translation unit, all 10022 unnamed namespaces will have the same name. 10023 10024'DECL_CONTEXT' 10025 This macro returns the enclosing namespace. The 'DECL_CONTEXT' for 10026 the 'global_namespace' is 'NULL_TREE'. 10027 10028'DECL_NAMESPACE_ALIAS' 10029 If this declaration is for a namespace alias, then 10030 'DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 10031 alias. 10032 10033 Do not attempt to use 'cp_namespace_decls' for a namespace which is 10034 an alias. Instead, follow 'DECL_NAMESPACE_ALIAS' links until you 10035 reach an ordinary, non-alias, namespace, and call 10036 'cp_namespace_decls' there. 10037 10038'DECL_NAMESPACE_STD_P' 10039 This predicate holds if the namespace is the special '::std' 10040 namespace. 10041 10042'cp_namespace_decls' 10043 This function will return the declarations contained in the 10044 namespace, including types, overloaded functions, other namespaces, 10045 and so forth. If there are no declarations, this function will 10046 return 'NULL_TREE'. The declarations are connected through their 10047 'TREE_CHAIN' fields. 10048 10049 Although most entries on this list will be declarations, 10050 'TREE_LIST' nodes may also appear. In this case, the 'TREE_VALUE' 10051 will be an 'OVERLOAD'. The value of the 'TREE_PURPOSE' is 10052 unspecified; back ends should ignore this value. As with the other 10053 kinds of declarations returned by 'cp_namespace_decls', the 10054 'TREE_CHAIN' will point to the next declaration in this list. 10055 10056 For more information on the kinds of declarations that can occur on 10057 this list, *Note Declarations::. Some declarations will not appear 10058 on this list. In particular, no 'FIELD_DECL', 'LABEL_DECL', or 10059 'PARM_DECL' nodes will appear here. 10060 10061 This function cannot be used with namespaces that have 10062 'DECL_NAMESPACE_ALIAS' set. 10063 10064 10065File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees 10066 1006710.10.3 Classes 10068--------------- 10069 10070Besides namespaces, the other high-level scoping construct in C++ is the 10071class. (Throughout this manual the term "class" is used to mean the 10072types referred to in the ANSI/ISO C++ Standard as classes; these include 10073types defined with the 'class', 'struct', and 'union' keywords.) 10074 10075 A class type is represented by either a 'RECORD_TYPE' or a 10076'UNION_TYPE'. A class declared with the 'union' tag is represented by a 10077'UNION_TYPE', while classes declared with either the 'struct' or the 10078'class' tag are represented by 'RECORD_TYPE's. You can use the 10079'CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 10080type is a 'class' as opposed to a 'struct'. This macro will be true 10081only for classes declared with the 'class' tag. 10082 10083 Almost all non-function members are available on the 'TYPE_FIELDS' 10084list. Given one member, the next can be found by following the 10085'TREE_CHAIN'. You should not depend in any way on the order in which 10086fields appear on this list. All nodes on this list will be 'DECL' 10087nodes. A 'FIELD_DECL' is used to represent a non-static data member, a 10088'VAR_DECL' is used to represent a static data member, and a 'TYPE_DECL' 10089is used to represent a type. Note that the 'CONST_DECL' for an 10090enumeration constant will appear on this list, if the enumeration type 10091was declared in the class. (Of course, the 'TYPE_DECL' for the 10092enumeration type will appear here as well.) There are no entries for 10093base classes on this list. In particular, there is no 'FIELD_DECL' for 10094the "base-class portion" of an object. 10095 10096 The 'TYPE_VFIELD' is a compiler-generated field used to point to 10097virtual function tables. It may or may not appear on the 'TYPE_FIELDS' 10098list. However, back ends should handle the 'TYPE_VFIELD' just like all 10099the entries on the 'TYPE_FIELDS' list. 10100 10101 The function members are available on the 'TYPE_METHODS' list. Again, 10102subsequent members are found by following the 'TREE_CHAIN' field. If a 10103function is overloaded, each of the overloaded functions appears; no 10104'OVERLOAD' nodes appear on the 'TYPE_METHODS' list. Implicitly declared 10105functions (including default constructors, copy constructors, assignment 10106operators, and destructors) will appear on this list as well. 10107 10108 Every class has an associated "binfo", which can be obtained with 10109'TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 10110given by 'TYPE_BINFO' is the degenerate case, whereby every class is 10111considered to be its own base-class. The base binfos for a particular 10112binfo are held in a vector, whose length is obtained with 10113'BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 10114'BINFO_BASE_BINFO' and 'BINFO_BASE_ITERATE'. To add a new binfo, use 10115'BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 10116'BINFO_BASE_BINFOS', but normally you do not need to use that. The 10117class type associated with a binfo is given by 'BINFO_TYPE'. It is not 10118always the case that 'BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 10119and qualified types. Neither is it the case that 'TYPE_BINFO 10120(BINFO_TYPE (y))' is the same binfo as 'y'. The reason is that if 'y' 10121is a binfo representing a base-class 'B' of a derived class 'D', then 10122'BINFO_TYPE (y)' will be 'B', and 'TYPE_BINFO (BINFO_TYPE (y))' will be 10123'B' as its own base-class, rather than as a base-class of 'D'. 10124 10125 The access to a base type can be found with 'BINFO_BASE_ACCESS'. This 10126will produce 'access_public_node', 'access_private_node' or 10127'access_protected_node'. If bases are always public, 10128'BINFO_BASE_ACCESSES' may be 'NULL'. 10129 10130 'BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 10131virtually or not. The other flags, 'BINFO_FLAG_0' to 'BINFO_FLAG_6', 10132can be used for language specific use. 10133 10134 The following macros can be used on a tree node representing a 10135class-type. 10136 10137'LOCAL_CLASS_P' 10138 This predicate holds if the class is local class _i.e._ declared 10139 inside a function body. 10140 10141'TYPE_POLYMORPHIC_P' 10142 This predicate holds if the class has at least one virtual function 10143 (declared or inherited). 10144 10145'TYPE_HAS_DEFAULT_CONSTRUCTOR' 10146 This predicate holds whenever its argument represents a class-type 10147 with default constructor. 10148 10149'CLASSTYPE_HAS_MUTABLE' 10150'TYPE_HAS_MUTABLE_P' 10151 These predicates hold for a class-type having a mutable data 10152 member. 10153 10154'CLASSTYPE_NON_POD_P' 10155 This predicate holds only for class-types that are not PODs. 10156 10157'TYPE_HAS_NEW_OPERATOR' 10158 This predicate holds for a class-type that defines 'operator new'. 10159 10160'TYPE_HAS_ARRAY_NEW_OPERATOR' 10161 This predicate holds for a class-type for which 'operator new[]' is 10162 defined. 10163 10164'TYPE_OVERLOADS_CALL_EXPR' 10165 This predicate holds for class-type for which the function call 10166 'operator()' is overloaded. 10167 10168'TYPE_OVERLOADS_ARRAY_REF' 10169 This predicate holds for a class-type that overloads 'operator[]' 10170 10171'TYPE_OVERLOADS_ARROW' 10172 This predicate holds for a class-type for which 'operator->' is 10173 overloaded. 10174 10175 10176File: gccint.info, Node: Functions for C++, Next: Statements for C++, Prev: Classes, Up: C and C++ Trees 10177 1017810.10.4 Functions for C++ 10179------------------------- 10180 10181A function is represented by a 'FUNCTION_DECL' node. A set of 10182overloaded functions is sometimes represented by an 'OVERLOAD' node. 10183 10184 An 'OVERLOAD' node is not a declaration, so none of the 'DECL_' macros 10185should be used on an 'OVERLOAD'. An 'OVERLOAD' node is similar to a 10186'TREE_LIST'. Use 'OVL_CURRENT' to get the function associated with an 10187'OVERLOAD' node; use 'OVL_NEXT' to get the next 'OVERLOAD' node in the 10188list of overloaded functions. The macros 'OVL_CURRENT' and 'OVL_NEXT' 10189are actually polymorphic; you can use them to work with 'FUNCTION_DECL' 10190nodes as well as with overloads. In the case of a 'FUNCTION_DECL', 10191'OVL_CURRENT' will always return the function itself, and 'OVL_NEXT' 10192will always be 'NULL_TREE'. 10193 10194 To determine the scope of a function, you can use the 'DECL_CONTEXT' 10195macro. This macro will return the class (either a 'RECORD_TYPE' or a 10196'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 10197a member. For a virtual function, this macro returns the class in which 10198the function was actually defined, not the base class in which the 10199virtual declaration occurred. 10200 10201 If a friend function is defined in a class scope, the 10202'DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 10203it was defined. For example, in 10204 class C { friend void f() {} }; 10205the 'DECL_CONTEXT' for 'f' will be the 'global_namespace', but the 10206'DECL_FRIEND_CONTEXT' will be the 'RECORD_TYPE' for 'C'. 10207 10208 The following macros and functions can be used on a 'FUNCTION_DECL': 10209'DECL_MAIN_P' 10210 This predicate holds for a function that is the program entry point 10211 '::code'. 10212 10213'DECL_LOCAL_FUNCTION_P' 10214 This predicate holds if the function was declared at block scope, 10215 even though it has a global scope. 10216 10217'DECL_ANTICIPATED' 10218 This predicate holds if the function is a built-in function but its 10219 prototype is not yet explicitly declared. 10220 10221'DECL_EXTERN_C_FUNCTION_P' 10222 This predicate holds if the function is declared as an ''extern 10223 "C"'' function. 10224 10225'DECL_LINKONCE_P' 10226 This macro holds if multiple copies of this function may be emitted 10227 in various translation units. It is the responsibility of the 10228 linker to merge the various copies. Template instantiations are 10229 the most common example of functions for which 'DECL_LINKONCE_P' 10230 holds; G++ instantiates needed templates in all translation units 10231 which require them, and then relies on the linker to remove 10232 duplicate instantiations. 10233 10234 FIXME: This macro is not yet implemented. 10235 10236'DECL_FUNCTION_MEMBER_P' 10237 This macro holds if the function is a member of a class, rather 10238 than a member of a namespace. 10239 10240'DECL_STATIC_FUNCTION_P' 10241 This predicate holds if the function a static member function. 10242 10243'DECL_NONSTATIC_MEMBER_FUNCTION_P' 10244 This macro holds for a non-static member function. 10245 10246'DECL_CONST_MEMFUNC_P' 10247 This predicate holds for a 'const'-member function. 10248 10249'DECL_VOLATILE_MEMFUNC_P' 10250 This predicate holds for a 'volatile'-member function. 10251 10252'DECL_CONSTRUCTOR_P' 10253 This macro holds if the function is a constructor. 10254 10255'DECL_NONCONVERTING_P' 10256 This predicate holds if the constructor is a non-converting 10257 constructor. 10258 10259'DECL_COMPLETE_CONSTRUCTOR_P' 10260 This predicate holds for a function which is a constructor for an 10261 object of a complete type. 10262 10263'DECL_BASE_CONSTRUCTOR_P' 10264 This predicate holds for a function which is a constructor for a 10265 base class sub-object. 10266 10267'DECL_COPY_CONSTRUCTOR_P' 10268 This predicate holds for a function which is a copy-constructor. 10269 10270'DECL_DESTRUCTOR_P' 10271 This macro holds if the function is a destructor. 10272 10273'DECL_COMPLETE_DESTRUCTOR_P' 10274 This predicate holds if the function is the destructor for an 10275 object a complete type. 10276 10277'DECL_OVERLOADED_OPERATOR_P' 10278 This macro holds if the function is an overloaded operator. 10279 10280'DECL_CONV_FN_P' 10281 This macro holds if the function is a type-conversion operator. 10282 10283'DECL_GLOBAL_CTOR_P' 10284 This predicate holds if the function is a file-scope initialization 10285 function. 10286 10287'DECL_GLOBAL_DTOR_P' 10288 This predicate holds if the function is a file-scope finalization 10289 function. 10290 10291'DECL_THUNK_P' 10292 This predicate holds if the function is a thunk. 10293 10294 These functions represent stub code that adjusts the 'this' pointer 10295 and then jumps to another function. When the jumped-to function 10296 returns, control is transferred directly to the caller, without 10297 returning to the thunk. The first parameter to the thunk is always 10298 the 'this' pointer; the thunk should add 'THUNK_DELTA' to this 10299 value. (The 'THUNK_DELTA' is an 'int', not an 'INTEGER_CST'.) 10300 10301 Then, if 'THUNK_VCALL_OFFSET' (an 'INTEGER_CST') is nonzero the 10302 adjusted 'this' pointer must be adjusted again. The complete 10303 calculation is given by the following pseudo-code: 10304 10305 this += THUNK_DELTA 10306 if (THUNK_VCALL_OFFSET) 10307 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 10308 10309 Finally, the thunk should jump to the location given by 10310 'DECL_INITIAL'; this will always be an expression for the address 10311 of a function. 10312 10313'DECL_NON_THUNK_FUNCTION_P' 10314 This predicate holds if the function is _not_ a thunk function. 10315 10316'GLOBAL_INIT_PRIORITY' 10317 If either 'DECL_GLOBAL_CTOR_P' or 'DECL_GLOBAL_DTOR_P' holds, then 10318 this gives the initialization priority for the function. The 10319 linker will arrange that all functions for which 10320 'DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 10321 before 'main' is called. When the program exits, all functions for 10322 which 'DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 10323 10324'TYPE_RAISES_EXCEPTIONS' 10325 This macro returns the list of exceptions that a (member-)function 10326 can raise. The returned list, if non 'NULL', is comprised of nodes 10327 whose 'TREE_VALUE' represents a type. 10328 10329'TYPE_NOTHROW_P' 10330 This predicate holds when the exception-specification of its 10331 arguments is of the form ''()''. 10332 10333'DECL_ARRAY_DELETE_OPERATOR_P' 10334 This predicate holds if the function an overloaded 'operator 10335 delete[]'. 10336 10337 10338File: gccint.info, Node: Statements for C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees 10339 1034010.10.5 Statements for C++ 10341-------------------------- 10342 10343A function that has a definition in the current translation unit will 10344have a non-'NULL' 'DECL_INITIAL'. However, back ends should not make 10345use of the particular value given by 'DECL_INITIAL'. 10346 10347 The 'DECL_SAVED_TREE' macro will give the complete body of the 10348function. 10349 1035010.10.5.1 Statements 10351.................... 10352 10353There are tree nodes corresponding to all of the source-level statement 10354constructs, used within the C and C++ frontends. These are enumerated 10355here, together with a list of the various macros that can be used to 10356obtain information about them. There are a few macros that can be used 10357with all statements: 10358 10359'STMT_IS_FULL_EXPR_P' 10360 In C++, statements normally constitute "full expressions"; 10361 temporaries created during a statement are destroyed when the 10362 statement is complete. However, G++ sometimes represents 10363 expressions by statements; these statements will not have 10364 'STMT_IS_FULL_EXPR_P' set. Temporaries created during such 10365 statements should be destroyed when the innermost enclosing 10366 statement with 'STMT_IS_FULL_EXPR_P' set is exited. 10367 10368 Here is the list of the various statement nodes, and the macros used to 10369access them. This documentation describes the use of these nodes in 10370non-template functions (including instantiations of template functions). 10371In template functions, the same nodes are used, but sometimes in 10372slightly different ways. 10373 10374 Many of the statements have substatements. For example, a 'while' loop 10375will have a body, which is itself a statement. If the substatement is 10376'NULL_TREE', it is considered equivalent to a statement consisting of a 10377single ';', i.e., an expression statement in which the expression has 10378been omitted. A substatement may in fact be a list of statements, 10379connected via their 'TREE_CHAIN's. So, you should always process the 10380statement tree by looping over substatements, like this: 10381 void process_stmt (stmt) 10382 tree stmt; 10383 { 10384 while (stmt) 10385 { 10386 switch (TREE_CODE (stmt)) 10387 { 10388 case IF_STMT: 10389 process_stmt (THEN_CLAUSE (stmt)); 10390 /* More processing here. */ 10391 break; 10392 10393 ... 10394 } 10395 10396 stmt = TREE_CHAIN (stmt); 10397 } 10398 } 10399 In other words, while the 'then' clause of an 'if' statement in C++ can 10400be only one statement (although that one statement may be a compound 10401statement), the intermediate representation will sometimes use several 10402statements chained together. 10403 10404'BREAK_STMT' 10405 10406 Used to represent a 'break' statement. There are no additional 10407 fields. 10408 10409'CILK_SPAWN_STMT' 10410 10411 Used to represent a spawning function in the Cilk Plus language 10412 extension. This tree has one field that holds the name of the 10413 spawning function. '_Cilk_spawn' can be written in C in the 10414 following way: 10415 10416 _Cilk_spawn <function_name> (<parameters>); 10417 10418 Detailed description for usage and functionality of '_Cilk_spawn' 10419 can be found at <https://www.cilkplus.org>. 10420 10421'CILK_SYNC_STMT' 10422 10423 This statement is part of the Cilk Plus language extension. It 10424 indicates that the current function cannot continue in parallel 10425 with its spawned children. There are no additional fields. 10426 '_Cilk_sync' can be written in C in the following way: 10427 10428 _Cilk_sync; 10429 10430'CLEANUP_STMT' 10431 10432 Used to represent an action that should take place upon exit from 10433 the enclosing scope. Typically, these actions are calls to 10434 destructors for local objects, but back ends cannot rely on this 10435 fact. If these nodes are in fact representing such destructors, 10436 'CLEANUP_DECL' will be the 'VAR_DECL' destroyed. Otherwise, 10437 'CLEANUP_DECL' will be 'NULL_TREE'. In any case, the 10438 'CLEANUP_EXPR' is the expression to execute. The cleanups executed 10439 on exit from a scope should be run in the reverse order of the 10440 order in which the associated 'CLEANUP_STMT's were encountered. 10441 10442'CONTINUE_STMT' 10443 10444 Used to represent a 'continue' statement. There are no additional 10445 fields. 10446 10447'CTOR_STMT' 10448 10449 Used to mark the beginning (if 'CTOR_BEGIN_P' holds) or end (if 10450 'CTOR_END_P' holds of the main body of a constructor. See also 10451 'SUBOBJECT' for more information on how to use these nodes. 10452 10453'DO_STMT' 10454 10455 Used to represent a 'do' loop. The body of the loop is given by 10456 'DO_BODY' while the termination condition for the loop is given by 10457 'DO_COND'. The condition for a 'do'-statement is always an 10458 expression. 10459 10460'EMPTY_CLASS_EXPR' 10461 10462 Used to represent a temporary object of a class with no data whose 10463 address is never taken. (All such objects are interchangeable.) 10464 The 'TREE_TYPE' represents the type of the object. 10465 10466'EXPR_STMT' 10467 10468 Used to represent an expression statement. Use 'EXPR_STMT_EXPR' to 10469 obtain the expression. 10470 10471'FOR_STMT' 10472 10473 Used to represent a 'for' statement. The 'FOR_INIT_STMT' is the 10474 initialization statement for the loop. The 'FOR_COND' is the 10475 termination condition. The 'FOR_EXPR' is the expression executed 10476 right before the 'FOR_COND' on each loop iteration; often, this 10477 expression increments a counter. The body of the loop is given by 10478 'FOR_BODY'. Note that 'FOR_INIT_STMT' and 'FOR_BODY' return 10479 statements, while 'FOR_COND' and 'FOR_EXPR' return expressions. 10480 10481'HANDLER' 10482 10483 Used to represent a C++ 'catch' block. The 'HANDLER_TYPE' is the 10484 type of exception that will be caught by this handler; it is equal 10485 (by pointer equality) to 'NULL' if this handler is for all types. 10486 'HANDLER_PARMS' is the 'DECL_STMT' for the catch parameter, and 10487 'HANDLER_BODY' is the code for the block itself. 10488 10489'IF_STMT' 10490 10491 Used to represent an 'if' statement. The 'IF_COND' is the 10492 expression. 10493 10494 If the condition is a 'TREE_LIST', then the 'TREE_PURPOSE' is a 10495 statement (usually a 'DECL_STMT'). Each time the condition is 10496 evaluated, the statement should be executed. Then, the 10497 'TREE_VALUE' should be used as the conditional expression itself. 10498 This representation is used to handle C++ code like this: 10499 10500 C++ distinguishes between this and 'COND_EXPR' for handling 10501 templates. 10502 10503 if (int i = 7) ... 10504 10505 where there is a new local variable (or variables) declared within 10506 the condition. 10507 10508 The 'THEN_CLAUSE' represents the statement given by the 'then' 10509 condition, while the 'ELSE_CLAUSE' represents the statement given 10510 by the 'else' condition. 10511 10512'SUBOBJECT' 10513 10514 In a constructor, these nodes are used to mark the point at which a 10515 subobject of 'this' is fully constructed. If, after this point, an 10516 exception is thrown before a 'CTOR_STMT' with 'CTOR_END_P' set is 10517 encountered, the 'SUBOBJECT_CLEANUP' must be executed. The 10518 cleanups must be executed in the reverse order in which they 10519 appear. 10520 10521'SWITCH_STMT' 10522 10523 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 10524 the expression on which the switch is occurring. See the 10525 documentation for an 'IF_STMT' for more information on the 10526 representation used for the condition. The 'SWITCH_STMT_BODY' is 10527 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 10528 original type of switch expression as given in the source, before 10529 any compiler conversions. 10530 10531'TRY_BLOCK' 10532 Used to represent a 'try' block. The body of the try block is 10533 given by 'TRY_STMTS'. Each of the catch blocks is a 'HANDLER' 10534 node. The first handler is given by 'TRY_HANDLERS'. Subsequent 10535 handlers are obtained by following the 'TREE_CHAIN' link from one 10536 handler to the next. The body of the handler is given by 10537 'HANDLER_BODY'. 10538 10539 If 'CLEANUP_P' holds of the 'TRY_BLOCK', then the 'TRY_HANDLERS' 10540 will not be a 'HANDLER' node. Instead, it will be an expression 10541 that should be executed if an exception is thrown in the try block. 10542 It must rethrow the exception after executing that code. And, if 10543 an exception is thrown while the expression is executing, 10544 'terminate' must be called. 10545 10546'USING_STMT' 10547 Used to represent a 'using' directive. The namespace is given by 10548 'USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 10549 is needed inside template functions, to implement using directives 10550 during instantiation. 10551 10552'WHILE_STMT' 10553 10554 Used to represent a 'while' loop. The 'WHILE_COND' is the 10555 termination condition for the loop. See the documentation for an 10556 'IF_STMT' for more information on the representation used for the 10557 condition. 10558 10559 The 'WHILE_BODY' is the body of the loop. 10560 10561 10562File: gccint.info, Node: C++ Expressions, Prev: Statements for C++, Up: C and C++ Trees 10563 1056410.10.6 C++ Expressions 10565----------------------- 10566 10567This section describes expressions specific to the C and C++ front ends. 10568 10569'TYPEID_EXPR' 10570 10571 Used to represent a 'typeid' expression. 10572 10573'NEW_EXPR' 10574'VEC_NEW_EXPR' 10575 10576 Used to represent a call to 'new' and 'new[]' respectively. 10577 10578'DELETE_EXPR' 10579'VEC_DELETE_EXPR' 10580 10581 Used to represent a call to 'delete' and 'delete[]' respectively. 10582 10583'MEMBER_REF' 10584 10585 Represents a reference to a member of a class. 10586 10587'THROW_EXPR' 10588 10589 Represents an instance of 'throw' in the program. Operand 0, which 10590 is the expression to throw, may be 'NULL_TREE'. 10591 10592'AGGR_INIT_EXPR' 10593 An 'AGGR_INIT_EXPR' represents the initialization as the return 10594 value of a function call, or as the result of a constructor. An 10595 'AGGR_INIT_EXPR' will only appear as a full-expression, or as the 10596 second operand of a 'TARGET_EXPR'. 'AGGR_INIT_EXPR's have a 10597 representation similar to that of 'CALL_EXPR's. You can use the 10598 'AGGR_INIT_EXPR_FN' and 'AGGR_INIT_EXPR_ARG' macros to access the 10599 function to call and the arguments to pass. 10600 10601 If 'AGGR_INIT_VIA_CTOR_P' holds of the 'AGGR_INIT_EXPR', then the 10602 initialization is via a constructor call. The address of the 10603 'AGGR_INIT_EXPR_SLOT' operand, which is always a 'VAR_DECL', is 10604 taken, and this value replaces the first argument in the argument 10605 list. 10606 10607 In either case, the expression is void. 10608 10609 10610File: gccint.info, Node: Java Trees, Prev: C and C++ Trees, Up: GENERIC 10611 1061210.11 Java Trees 10613================ 10614 10615 10616File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top 10617 1061811 GIMPLE 10619********* 10620 10621GIMPLE is a three-address representation derived from GENERIC by 10622breaking down GENERIC expressions into tuples of no more than 3 operands 10623(with some exceptions like function calls). GIMPLE was heavily 10624influenced by the SIMPLE IL used by the McCAT compiler project at McGill 10625University, though we have made some different choices. For one thing, 10626SIMPLE doesn't support 'goto'. 10627 10628 Temporaries are introduced to hold intermediate values needed to 10629compute complex expressions. Additionally, all the control structures 10630used in GENERIC are lowered into conditional jumps, lexical scopes are 10631removed and exception regions are converted into an on the side 10632exception region tree. 10633 10634 The compiler pass which converts GENERIC into GIMPLE is referred to as 10635the 'gimplifier'. The gimplifier works recursively, generating GIMPLE 10636tuples out of the original GENERIC expressions. 10637 10638 One of the early implementation strategies used for the GIMPLE 10639representation was to use the same internal data structures used by 10640front ends to represent parse trees. This simplified implementation 10641because we could leverage existing functionality and interfaces. 10642However, GIMPLE is a much more restrictive representation than abstract 10643syntax trees (AST), therefore it does not require the full structural 10644complexity provided by the main tree data structure. 10645 10646 The GENERIC representation of a function is stored in the 10647'DECL_SAVED_TREE' field of the associated 'FUNCTION_DECL' tree node. It 10648is converted to GIMPLE by a call to 'gimplify_function_tree'. 10649 10650 If a front end wants to include language-specific tree codes in the 10651tree representation which it provides to the back end, it must provide a 10652definition of 'LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 10653front end trees to GIMPLE. Usually such a hook will involve much of the 10654same code for expanding front end trees to RTL. This function can 10655return fully lowered GIMPLE, or it can return GENERIC trees and let the 10656main gimplifier lower them the rest of the way; this is often simpler. 10657GIMPLE that is not fully lowered is known as "High GIMPLE" and consists 10658of the IL before the pass 'pass_lower_cf'. High GIMPLE contains some 10659container statements like lexical scopes (represented by 'GIMPLE_BIND') 10660and nested expressions (e.g., 'GIMPLE_TRY'), while "Low GIMPLE" exposes 10661all of the implicit jumps for control and exception expressions directly 10662in the IL and EH region trees. 10663 10664 The C and C++ front ends currently convert directly from front end 10665trees to GIMPLE, and hand that off to the back end rather than first 10666converting to GENERIC. Their gimplifier hooks know about all the 10667'_STMT' nodes and how to convert them to GENERIC forms. There was some 10668work done on a genericization pass which would run first, but the 10669existence of 'STMT_EXPR' meant that in order to convert all of the C 10670statements into GENERIC equivalents would involve walking the entire 10671tree anyway, so it was simpler to lower all the way. This might change 10672in the future if someone writes an optimization pass which would work 10673better with higher-level trees, but currently the optimizers all expect 10674GIMPLE. 10675 10676 You can request to dump a C-like representation of the GIMPLE form with 10677the flag '-fdump-tree-gimple'. 10678 10679* Menu: 10680 10681* Tuple representation:: 10682* Class hierarchy of GIMPLE statements:: 10683* GIMPLE instruction set:: 10684* GIMPLE Exception Handling:: 10685* Temporaries:: 10686* Operands:: 10687* Manipulating GIMPLE statements:: 10688* Tuple specific accessors:: 10689* GIMPLE sequences:: 10690* Sequence iterators:: 10691* Adding a new GIMPLE statement code:: 10692* Statement and operand traversals:: 10693 10694 10695File: gccint.info, Node: Tuple representation, Next: Class hierarchy of GIMPLE statements, Up: GIMPLE 10696 1069711.1 Tuple representation 10698========================= 10699 10700GIMPLE instructions are tuples of variable size divided in two groups: a 10701header describing the instruction and its locations, and a variable 10702length body with all the operands. Tuples are organized into a 10703hierarchy with 3 main classes of tuples. 10704 1070511.1.1 'gimple' (gsbase) 10706------------------------ 10707 10708This is the root of the hierarchy, it holds basic information needed by 10709most GIMPLE statements. There are some fields that may not be relevant 10710to every GIMPLE statement, but those were moved into the base structure 10711to take advantage of holes left by other fields (thus making the 10712structure more compact). The structure takes 4 words (32 bytes) on 64 10713bit hosts: 10714 10715Field Size (bits) 10716'code' 8 10717'subcode' 16 10718'no_warning' 1 10719'visited' 1 10720'nontemporal_move' 1 10721'plf' 2 10722'modified' 1 10723'has_volatile_ops' 1 10724'references_memory_p' 1 10725'uid' 32 10726'location' 32 10727'num_ops' 32 10728'bb' 64 10729'block' 63 10730Total size 32 bytes 10731 10732 * 'code' Main identifier for a GIMPLE instruction. 10733 10734 * 'subcode' Used to distinguish different variants of the same basic 10735 instruction or provide flags applicable to a given code. The 10736 'subcode' flags field has different uses depending on the code of 10737 the instruction, but mostly it distinguishes instructions of the 10738 same family. The most prominent use of this field is in 10739 assignments, where subcode indicates the operation done on the RHS 10740 of the assignment. For example, a = b + c is encoded as 10741 'GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'. 10742 10743 * 'no_warning' Bitflag to indicate whether a warning has already been 10744 issued on this statement. 10745 10746 * 'visited' General purpose "visited" marker. Set and cleared by 10747 each pass when needed. 10748 10749 * 'nontemporal_move' Bitflag used in assignments that represent 10750 non-temporal moves. Although this bitflag is only used in 10751 assignments, it was moved into the base to take advantage of the 10752 bit holes left by the previous fields. 10753 10754 * 'plf' Pass Local Flags. This 2-bit mask can be used as general 10755 purpose markers by any pass. Passes are responsible for clearing 10756 and setting these two flags accordingly. 10757 10758 * 'modified' Bitflag to indicate whether the statement has been 10759 modified. Used mainly by the operand scanner to determine when to 10760 re-scan a statement for operands. 10761 10762 * 'has_volatile_ops' Bitflag to indicate whether this statement 10763 contains operands that have been marked volatile. 10764 10765 * 'references_memory_p' Bitflag to indicate whether this statement 10766 contains memory references (i.e., its operands are either global 10767 variables, or pointer dereferences or anything that must reside in 10768 memory). 10769 10770 * 'uid' This is an unsigned integer used by passes that want to 10771 assign IDs to every statement. These IDs must be assigned and used 10772 by each pass. 10773 10774 * 'location' This is a 'location_t' identifier to specify source code 10775 location for this statement. It is inherited from the front end. 10776 10777 * 'num_ops' Number of operands that this statement has. This 10778 specifies the size of the operand vector embedded in the tuple. 10779 Only used in some tuples, but it is declared in the base tuple to 10780 take advantage of the 32-bit hole left by the previous fields. 10781 10782 * 'bb' Basic block holding the instruction. 10783 10784 * 'block' Lexical block holding this statement. Also used for debug 10785 information generation. 10786 1078711.1.2 'gimple_statement_with_ops' 10788---------------------------------- 10789 10790This tuple is actually split in two: 'gimple_statement_with_ops_base' 10791and 'gimple_statement_with_ops'. This is needed to accommodate the way 10792the operand vector is allocated. The operand vector is defined to be an 10793array of 1 element. So, to allocate a dynamic number of operands, the 10794memory allocator ('gimple_alloc') simply allocates enough memory to hold 10795the structure itself plus 'N - 1' operands which run "off the end" of 10796the structure. For example, to allocate space for a tuple with 3 10797operands, 'gimple_alloc' reserves 'sizeof (struct 10798gimple_statement_with_ops) + 2 * sizeof (tree)' bytes. 10799 10800 On the other hand, several fields in this tuple need to be shared with 10801the 'gimple_statement_with_memory_ops' tuple. So, these common fields 10802are placed in 'gimple_statement_with_ops_base' which is then inherited 10803from the other two tuples. 10804 10805'gsbase' 256 10806'def_ops' 64 10807'use_ops' 64 10808'op' 'num_ops' * 64 10809Total 48 + 8 * 'num_ops' bytes 10810size 10811 10812 * 'gsbase' Inherited from 'struct gimple'. 10813 10814 * 'def_ops' Array of pointers into the operand array indicating all 10815 the slots that contain a variable written-to by the statement. 10816 This array is also used for immediate use chaining. Note that it 10817 would be possible to not rely on this array, but the changes 10818 required to implement this are pretty invasive. 10819 10820 * 'use_ops' Similar to 'def_ops' but for variables read by the 10821 statement. 10822 10823 * 'op' Array of trees with 'num_ops' slots. 10824 1082511.1.3 'gimple_statement_with_memory_ops' 10826----------------------------------------- 10827 10828This tuple is essentially identical to 'gimple_statement_with_ops', 10829except that it contains 4 additional fields to hold vectors related 10830memory stores and loads. Similar to the previous case, the structure is 10831split in two to accommodate for the operand vector 10832('gimple_statement_with_memory_ops_base' and 10833'gimple_statement_with_memory_ops'). 10834 10835Field Size (bits) 10836'gsbase' 256 10837'def_ops' 64 10838'use_ops' 64 10839'vdef_ops' 64 10840'vuse_ops' 64 10841'stores' 64 10842'loads' 64 10843'op' 'num_ops' * 64 10844Total size 80 + 8 * 'num_ops' bytes 10845 10846 * 'vdef_ops' Similar to 'def_ops' but for 'VDEF' operators. There is 10847 one entry per memory symbol written by this statement. This is 10848 used to maintain the memory SSA use-def and def-def chains. 10849 10850 * 'vuse_ops' Similar to 'use_ops' but for 'VUSE' operators. There is 10851 one entry per memory symbol loaded by this statement. This is used 10852 to maintain the memory SSA use-def chains. 10853 10854 * 'stores' Bitset with all the UIDs for the symbols written-to by the 10855 statement. This is different than 'vdef_ops' in that all the 10856 affected symbols are mentioned in this set. If memory partitioning 10857 is enabled, the 'vdef_ops' vector will refer to memory partitions. 10858 Furthermore, no SSA information is stored in this set. 10859 10860 * 'loads' Similar to 'stores', but for memory loads. (Note that 10861 there is some amount of redundancy here, it should be possible to 10862 reduce memory utilization further by removing these sets). 10863 10864 All the other tuples are defined in terms of these three basic ones. 10865Each tuple will add some fields. 10866 10867 10868File: gccint.info, Node: Class hierarchy of GIMPLE statements, Next: GIMPLE instruction set, Prev: Tuple representation, Up: GIMPLE 10869 1087011.2 Class hierarchy of GIMPLE statements 10871========================================= 10872 10873The following diagram shows the C++ inheritance hierarchy of statement 10874kinds, along with their relationships to 'GSS_' values (layouts) and 10875'GIMPLE_' values (codes): 10876 10877 gimple 10878 | layout: GSS_BASE 10879 | used for 4 codes: GIMPLE_ERROR_MARK 10880 | GIMPLE_NOP 10881 | GIMPLE_OMP_SECTIONS_SWITCH 10882 | GIMPLE_PREDICT 10883 | 10884 + gimple_statement_with_ops_base 10885 | | (no GSS layout) 10886 | | 10887 | + gimple_statement_with_ops 10888 | | | layout: GSS_WITH_OPS 10889 | | | 10890 | | + gcond 10891 | | | code: GIMPLE_COND 10892 | | | 10893 | | + gdebug 10894 | | | code: GIMPLE_DEBUG 10895 | | | 10896 | | + ggoto 10897 | | | code: GIMPLE_GOTO 10898 | | | 10899 | | + glabel 10900 | | | code: GIMPLE_LABEL 10901 | | | 10902 | | + gswitch 10903 | | code: GIMPLE_SWITCH 10904 | | 10905 | + gimple_statement_with_memory_ops_base 10906 | | layout: GSS_WITH_MEM_OPS_BASE 10907 | | 10908 | + gimple_statement_with_memory_ops 10909 | | | layout: GSS_WITH_MEM_OPS 10910 | | | 10911 | | + gassign 10912 | | | code GIMPLE_ASSIGN 10913 | | | 10914 | | + greturn 10915 | | code GIMPLE_RETURN 10916 | | 10917 | + gcall 10918 | | layout: GSS_CALL, code: GIMPLE_CALL 10919 | | 10920 | + gasm 10921 | | layout: GSS_ASM, code: GIMPLE_ASM 10922 | | 10923 | + gtransaction 10924 | layout: GSS_TRANSACTION, code: GIMPLE_TRANSACTION 10925 | 10926 + gimple_statement_omp 10927 | | layout: GSS_OMP. Used for code GIMPLE_OMP_SECTION 10928 | | 10929 | + gomp_critical 10930 | | layout: GSS_OMP_CRITICAL, code: GIMPLE_OMP_CRITICAL 10931 | | 10932 | + gomp_for 10933 | | layout: GSS_OMP_FOR, code: GIMPLE_OMP_FOR 10934 | | 10935 | + gomp_parallel_layout 10936 | | | layout: GSS_OMP_PARALLEL_LAYOUT 10937 | | | 10938 | | + gimple_statement_omp_taskreg 10939 | | | | 10940 | | | + gomp_parallel 10941 | | | | code: GIMPLE_OMP_PARALLEL 10942 | | | | 10943 | | | + gomp_task 10944 | | | code: GIMPLE_OMP_TASK 10945 | | | 10946 | | + gimple_statement_omp_target 10947 | | code: GIMPLE_OMP_TARGET 10948 | | 10949 | + gomp_sections 10950 | | layout: GSS_OMP_SECTIONS, code: GIMPLE_OMP_SECTIONS 10951 | | 10952 | + gimple_statement_omp_single_layout 10953 | | layout: GSS_OMP_SINGLE_LAYOUT 10954 | | 10955 | + gomp_single 10956 | | code: GIMPLE_OMP_SINGLE 10957 | | 10958 | + gomp_teams 10959 | code: GIMPLE_OMP_TEAMS 10960 | 10961 + gbind 10962 | layout: GSS_BIND, code: GIMPLE_BIND 10963 | 10964 + gcatch 10965 | layout: GSS_CATCH, code: GIMPLE_CATCH 10966 | 10967 + geh_filter 10968 | layout: GSS_EH_FILTER, code: GIMPLE_EH_FILTER 10969 | 10970 + geh_else 10971 | layout: GSS_EH_ELSE, code: GIMPLE_EH_ELSE 10972 | 10973 + geh_mnt 10974 | layout: GSS_EH_MNT, code: GIMPLE_EH_MUST_NOT_THROW 10975 | 10976 + gphi 10977 | layout: GSS_PHI, code: GIMPLE_PHI 10978 | 10979 + gimple_statement_eh_ctrl 10980 | | layout: GSS_EH_CTRL 10981 | | 10982 | + gresx 10983 | | code: GIMPLE_RESX 10984 | | 10985 | + geh_dispatch 10986 | code: GIMPLE_EH_DISPATCH 10987 | 10988 + gtry 10989 | layout: GSS_TRY, code: GIMPLE_TRY 10990 | 10991 + gimple_statement_wce 10992 | layout: GSS_WCE, code: GIMPLE_WITH_CLEANUP_EXPR 10993 | 10994 + gomp_continue 10995 | layout: GSS_OMP_CONTINUE, code: GIMPLE_OMP_CONTINUE 10996 | 10997 + gomp_atomic_load 10998 | layout: GSS_OMP_ATOMIC_LOAD, code: GIMPLE_OMP_ATOMIC_LOAD 10999 | 11000 + gimple_statement_omp_atomic_store_layout 11001 | layout: GSS_OMP_ATOMIC_STORE_LAYOUT, 11002 | code: GIMPLE_OMP_ATOMIC_STORE 11003 | 11004 + gomp_atomic_store 11005 | code: GIMPLE_OMP_ATOMIC_STORE 11006 | 11007 + gomp_return 11008 code: GIMPLE_OMP_RETURN 11009 11010 11011File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Class hierarchy of GIMPLE statements, Up: GIMPLE 11012 1101311.3 GIMPLE instruction set 11014=========================== 11015 11016The following table briefly describes the GIMPLE instruction set. 11017 11018Instruction High GIMPLE Low GIMPLE 11019'GIMPLE_ASM' x x 11020'GIMPLE_ASSIGN' x x 11021'GIMPLE_BIND' x 11022'GIMPLE_CALL' x x 11023'GIMPLE_CATCH' x 11024'GIMPLE_COND' x x 11025'GIMPLE_DEBUG' x x 11026'GIMPLE_EH_FILTER' x 11027'GIMPLE_GOTO' x x 11028'GIMPLE_LABEL' x x 11029'GIMPLE_NOP' x x 11030'GIMPLE_OMP_ATOMIC_LOAD' x x 11031'GIMPLE_OMP_ATOMIC_STORE' x x 11032'GIMPLE_OMP_CONTINUE' x x 11033'GIMPLE_OMP_CRITICAL' x x 11034'GIMPLE_OMP_FOR' x x 11035'GIMPLE_OMP_MASTER' x x 11036'GIMPLE_OMP_ORDERED' x x 11037'GIMPLE_OMP_PARALLEL' x x 11038'GIMPLE_OMP_RETURN' x x 11039'GIMPLE_OMP_SECTION' x x 11040'GIMPLE_OMP_SECTIONS' x x 11041'GIMPLE_OMP_SECTIONS_SWITCH' x x 11042'GIMPLE_OMP_SINGLE' x x 11043'GIMPLE_PHI' x 11044'GIMPLE_RESX' x 11045'GIMPLE_RETURN' x x 11046'GIMPLE_SWITCH' x x 11047'GIMPLE_TRY' x 11048 11049 11050File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE 11051 1105211.4 Exception Handling 11053======================= 11054 11055Other exception handling constructs are represented using 11056'GIMPLE_TRY_CATCH'. 'GIMPLE_TRY_CATCH' has two operands. The first 11057operand is a sequence of statements to execute. If executing these 11058statements does not throw an exception, then the second operand is 11059ignored. Otherwise, if an exception is thrown, then the second operand 11060of the 'GIMPLE_TRY_CATCH' is checked. The second operand may have the 11061following forms: 11062 11063 1. A sequence of statements to execute. When an exception occurs, 11064 these statements are executed, and then the exception is rethrown. 11065 11066 2. A sequence of 'GIMPLE_CATCH' statements. Each 'GIMPLE_CATCH' has a 11067 list of applicable exception types and handler code. If the thrown 11068 exception matches one of the caught types, the associated handler 11069 code is executed. If the handler code falls off the bottom, 11070 execution continues after the original 'GIMPLE_TRY_CATCH'. 11071 11072 3. A 'GIMPLE_EH_FILTER' statement. This has a list of permitted 11073 exception types, and code to handle a match failure. If the thrown 11074 exception does not match one of the allowed types, the associated 11075 match failure code is executed. If the thrown exception does 11076 match, it continues unwinding the stack looking for the next 11077 handler. 11078 11079 Currently throwing an exception is not directly represented in GIMPLE, 11080since it is implemented by calling a function. At some point in the 11081future we will want to add some way to express that the call will throw 11082an exception of a known type. 11083 11084 Just before running the optimizers, the compiler lowers the high-level 11085EH constructs above into a set of 'goto's, magic labels, and EH regions. 11086Continuing to unwind at the end of a cleanup is represented with a 11087'GIMPLE_RESX'. 11088 11089 11090File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE 11091 1109211.5 Temporaries 11093================ 11094 11095When gimplification encounters a subexpression that is too complex, it 11096creates a new temporary variable to hold the value of the subexpression, 11097and adds a new statement to initialize it before the current statement. 11098These special temporaries are known as 'expression temporaries', and are 11099allocated using 'get_formal_tmp_var'. The compiler tries to always 11100evaluate identical expressions into the same temporary, to simplify 11101elimination of redundant calculations. 11102 11103 We can only use expression temporaries when we know that it will not be 11104reevaluated before its value is used, and that it will not be otherwise 11105modified(1). Other temporaries can be allocated using 11106'get_initialized_tmp_var' or 'create_tmp_var'. 11107 11108 Currently, an expression like 'a = b + 5' is not reduced any further. 11109We tried converting it to something like 11110 T1 = b + 5; 11111 a = T1; 11112 but this bloated the representation for minimal benefit. However, a 11113variable which must live in memory cannot appear in an expression; its 11114value is explicitly loaded into a temporary first. Similarly, storing 11115the value of an expression to a memory variable goes through a 11116temporary. 11117 11118 ---------- Footnotes ---------- 11119 11120 (1) These restrictions are derived from those in Morgan 4.8. 11121 11122 11123File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE 11124 1112511.6 Operands 11126============= 11127 11128In general, expressions in GIMPLE consist of an operation and the 11129appropriate number of simple operands; these operands must either be a 11130GIMPLE rvalue ('is_gimple_val'), i.e. a constant or a register variable. 11131More complex operands are factored out into temporaries, so that 11132 a = b + c + d 11133 becomes 11134 T1 = b + c; 11135 a = T1 + d; 11136 11137 The same rule holds for arguments to a 'GIMPLE_CALL'. 11138 11139 The target of an assignment is usually a variable, but can also be a 11140'MEM_REF' or a compound lvalue as described below. 11141 11142* Menu: 11143 11144* Compound Expressions:: 11145* Compound Lvalues:: 11146* Conditional Expressions:: 11147* Logical Operators:: 11148 11149 11150File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands 11151 1115211.6.1 Compound Expressions 11153--------------------------- 11154 11155The left-hand side of a C comma expression is simply moved into a 11156separate statement. 11157 11158 11159File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands 11160 1116111.6.2 Compound Lvalues 11162----------------------- 11163 11164Currently compound lvalues involving array and structure field 11165references are not broken down; an expression like 'a.b[2] = 42' is not 11166reduced any further (though complex array subscripts are). This 11167restriction is a workaround for limitations in later optimizers; if we 11168were to convert this to 11169 11170 T1 = &a.b; 11171 T1[2] = 42; 11172 11173 alias analysis would not remember that the reference to 'T1[2]' came by 11174way of 'a.b', so it would think that the assignment could alias another 11175member of 'a'; this broke 'struct-alias-1.c'. Future optimizer 11176improvements may make this limitation unnecessary. 11177 11178 11179File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands 11180 1118111.6.3 Conditional Expressions 11182------------------------------ 11183 11184A C '?:' expression is converted into an 'if' statement with each branch 11185assigning to the same temporary. So, 11186 11187 a = b ? c : d; 11188 becomes 11189 if (b == 1) 11190 T1 = c; 11191 else 11192 T1 = d; 11193 a = T1; 11194 11195 The GIMPLE level if-conversion pass re-introduces '?:' expression, if 11196appropriate. It is used to vectorize loops with conditions using vector 11197conditional operations. 11198 11199 Note that in GIMPLE, 'if' statements are represented using 11200'GIMPLE_COND', as described below. 11201 11202 11203File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands 11204 1120511.6.4 Logical Operators 11206------------------------ 11207 11208Except when they appear in the condition operand of a 'GIMPLE_COND', 11209logical 'and' and 'or' operators are simplified as follows: 'a = b && c' 11210becomes 11211 11212 T1 = (bool)b; 11213 if (T1 == true) 11214 T1 = (bool)c; 11215 a = T1; 11216 11217 Note that 'T1' in this example cannot be an expression temporary, 11218because it has two different assignments. 11219 1122011.6.5 Manipulating operands 11221---------------------------- 11222 11223All gimple operands are of type 'tree'. But only certain types of trees 11224are allowed to be used as operand tuples. Basic validation is 11225controlled by the function 'get_gimple_rhs_class', which given a tree 11226code, returns an 'enum' with the following values of type 'enum 11227gimple_rhs_class' 11228 11229 * 'GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand. 11230 11231 * 'GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation. 11232 11233 * 'GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation. 11234 11235 * 'GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation. 11236 11237 * 'GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be 11238 split into simpler operands (for instance, 'SSA_NAME', 'VAR_DECL', 11239 'COMPONENT_REF', etc). 11240 11241 This operand class also acts as an escape hatch for tree nodes that 11242 may be flattened out into the operand vector, but would need more 11243 than two slots on the RHS. For instance, a 'COND_EXPR' expression 11244 of the form '(a op b) ? x : y' could be flattened out on the 11245 operand vector using 4 slots, but it would also require additional 11246 processing to distinguish 'c = a op b' from 'c = a op b ? x : y'. 11247 Something similar occurs with 'ASSERT_EXPR'. In time, these 11248 special case tree expressions should be flattened into the operand 11249 vector. 11250 11251 For tree nodes in the categories 'GIMPLE_TERNARY_RHS', 11252'GIMPLE_BINARY_RHS' and 'GIMPLE_UNARY_RHS', they cannot be stored inside 11253tuples directly. They first need to be flattened and separated into 11254individual components. For instance, given the GENERIC expression 11255 11256 a = b + c 11257 11258 its tree representation is: 11259 11260 MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> 11261 11262 In this case, the GIMPLE form for this statement is logically identical 11263to its GENERIC form but in GIMPLE, the 'PLUS_EXPR' on the RHS of the 11264assignment is not represented as a tree, instead the two operands are 11265taken out of the 'PLUS_EXPR' sub-tree and flattened into the GIMPLE 11266tuple as follows: 11267 11268 GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> 11269 1127011.6.6 Operand vector allocation 11271-------------------------------- 11272 11273The operand vector is stored at the bottom of the three tuple structures 11274that accept operands. This means, that depending on the code of a given 11275statement, its operand vector will be at different offsets from the base 11276of the structure. To access tuple operands use the following accessors 11277 11278 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 11279 Returns the number of operands in statement G. 11280 11281 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 11282 Returns operand 'I' from statement 'G'. 11283 11284 -- GIMPLE function: tree * gimple_ops (gimple g) 11285 Returns a pointer into the operand vector for statement 'G'. This 11286 is computed using an internal table called 'gimple_ops_offset_'[]. 11287 This table is indexed by the gimple code of 'G'. 11288 11289 When the compiler is built, this table is filled-in using the sizes 11290 of the structures used by each statement code defined in 11291 gimple.def. Since the operand vector is at the bottom of the 11292 structure, for a gimple code 'C' the offset is computed as sizeof 11293 (struct-of 'C') - sizeof (tree). 11294 11295 This mechanism adds one memory indirection to every access when 11296 using 'gimple_op'(), if this becomes a bottleneck, a pass can 11297 choose to memoize the result from 'gimple_ops'() and use that to 11298 access the operands. 11299 1130011.6.7 Operand validation 11301------------------------- 11302 11303When adding a new operand to a gimple statement, the operand will be 11304validated according to what each tuple accepts in its operand vector. 11305These predicates are called by the 'gimple_NAME_set_...()'. Each tuple 11306will use one of the following predicates (Note, this list is not 11307exhaustive): 11308 11309 -- GIMPLE function: bool is_gimple_val (tree t) 11310 Returns true if t is a "GIMPLE value", which are all the 11311 non-addressable stack variables (variables for which 11312 'is_gimple_reg' returns true) and constants (expressions for which 11313 'is_gimple_min_invariant' returns true). 11314 11315 -- GIMPLE function: bool is_gimple_addressable (tree t) 11316 Returns true if t is a symbol or memory reference whose address can 11317 be taken. 11318 11319 -- GIMPLE function: bool is_gimple_asm_val (tree t) 11320 Similar to 'is_gimple_val' but it also accepts hard registers. 11321 11322 -- GIMPLE function: bool is_gimple_call_addr (tree t) 11323 Return true if t is a valid expression to use as the function 11324 called by a 'GIMPLE_CALL'. 11325 11326 -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t) 11327 Return true if t is a valid expression to use as first operand of a 11328 'MEM_REF' expression. 11329 11330 -- GIMPLE function: bool is_gimple_constant (tree t) 11331 Return true if t is a valid gimple constant. 11332 11333 -- GIMPLE function: bool is_gimple_min_invariant (tree t) 11334 Return true if t is a valid minimal invariant. This is different 11335 from constants, in that the specific value of t may not be known at 11336 compile time, but it is known that it doesn't change (e.g., the 11337 address of a function local variable). 11338 11339 -- GIMPLE function: bool is_gimple_ip_invariant (tree t) 11340 Return true if t is an interprocedural invariant. This means that 11341 t is a valid invariant in all functions (e.g. it can be an address 11342 of a global variable but not of a local one). 11343 11344 -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t) 11345 Return true if t is an 'ADDR_EXPR' that does not change once the 11346 program is running (and which is valid in all functions). 11347 1134811.6.8 Statement validation 11349--------------------------- 11350 11351 -- GIMPLE function: bool is_gimple_assign (gimple g) 11352 Return true if the code of g is 'GIMPLE_ASSIGN'. 11353 11354 -- GIMPLE function: bool is_gimple_call (gimple g) 11355 Return true if the code of g is 'GIMPLE_CALL'. 11356 11357 -- GIMPLE function: bool is_gimple_debug (gimple g) 11358 Return true if the code of g is 'GIMPLE_DEBUG'. 11359 11360 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple g) 11361 Return true if g is a 'GIMPLE_ASSIGN' that performs a type cast 11362 operation. 11363 11364 -- GIMPLE function: bool gimple_debug_bind_p (gimple g) 11365 Return true if g is a 'GIMPLE_DEBUG' that binds the value of an 11366 expression to a variable. 11367 11368 -- GIMPLE function: bool is_gimple_omp (gimple g) 11369 Return true if g is any of the OpenMP codes. 11370 11371 11372File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE 11373 1137411.7 Manipulating GIMPLE statements 11375=================================== 11376 11377This section documents all the functions available to handle each of the 11378GIMPLE instructions. 11379 1138011.7.1 Common accessors 11381----------------------- 11382 11383The following are common accessors for gimple statements. 11384 11385 -- GIMPLE function: enum gimple_code gimple_code (gimple g) 11386 Return the code for statement 'G'. 11387 11388 -- GIMPLE function: basic_block gimple_bb (gimple g) 11389 Return the basic block to which statement 'G' belongs to. 11390 11391 -- GIMPLE function: tree gimple_block (gimple g) 11392 Return the lexical scope block holding statement 'G'. 11393 11394 -- GIMPLE function: tree gimple_expr_type (gimple stmt) 11395 Return the type of the main expression computed by 'STMT'. Return 11396 'void_type_node' if 'STMT' computes nothing. This will only return 11397 something meaningful for 'GIMPLE_ASSIGN', 'GIMPLE_COND' and 11398 'GIMPLE_CALL'. For all other tuple codes, it will return 11399 'void_type_node'. 11400 11401 -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt) 11402 Return the tree code for the expression computed by 'STMT'. This 11403 is only meaningful for 'GIMPLE_CALL', 'GIMPLE_ASSIGN' and 11404 'GIMPLE_COND'. If 'STMT' is 'GIMPLE_CALL', it will return 11405 'CALL_EXPR'. For 'GIMPLE_COND', it returns the code of the 11406 comparison predicate. For 'GIMPLE_ASSIGN' it returns the code of 11407 the operation performed by the 'RHS' of the assignment. 11408 11409 -- GIMPLE function: void gimple_set_block (gimple g, tree block) 11410 Set the lexical scope block of 'G' to 'BLOCK'. 11411 11412 -- GIMPLE function: location_t gimple_locus (gimple g) 11413 Return locus information for statement 'G'. 11414 11415 -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus) 11416 Set locus information for statement 'G'. 11417 11418 -- GIMPLE function: bool gimple_locus_empty_p (gimple g) 11419 Return true if 'G' does not have locus information. 11420 11421 -- GIMPLE function: bool gimple_no_warning_p (gimple stmt) 11422 Return true if no warnings should be emitted for statement 'STMT'. 11423 11424 -- GIMPLE function: void gimple_set_visited (gimple stmt, bool 11425 visited_p) 11426 Set the visited status on statement 'STMT' to 'VISITED_P'. 11427 11428 -- GIMPLE function: bool gimple_visited_p (gimple stmt) 11429 Return the visited status on statement 'STMT'. 11430 11431 -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask 11432 plf, bool val_p) 11433 Set pass local flag 'PLF' on statement 'STMT' to 'VAL_P'. 11434 11435 -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum plf_mask 11436 plf) 11437 Return the value of pass local flag 'PLF' on statement 'STMT'. 11438 11439 -- GIMPLE function: bool gimple_has_ops (gimple g) 11440 Return true if statement 'G' has register or memory operands. 11441 11442 -- GIMPLE function: bool gimple_has_mem_ops (gimple g) 11443 Return true if statement 'G' has memory operands. 11444 11445 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 11446 Return the number of operands for statement 'G'. 11447 11448 -- GIMPLE function: tree * gimple_ops (gimple g) 11449 Return the array of operands for statement 'G'. 11450 11451 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 11452 Return operand 'I' for statement 'G'. 11453 11454 -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i) 11455 Return a pointer to operand 'I' for statement 'G'. 11456 11457 -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op) 11458 Set operand 'I' of statement 'G' to 'OP'. 11459 11460 -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt) 11461 Return the set of symbols that have had their address taken by 11462 'STMT'. 11463 11464 -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g) 11465 Return the set of 'DEF' operands for statement 'G'. 11466 11467 -- GIMPLE function: void gimple_set_def_ops (gimple g, struct 11468 def_optype_d *def) 11469 Set 'DEF' to be the set of 'DEF' operands for statement 'G'. 11470 11471 -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g) 11472 Return the set of 'USE' operands for statement 'G'. 11473 11474 -- GIMPLE function: void gimple_set_use_ops (gimple g, struct 11475 use_optype_d *use) 11476 Set 'USE' to be the set of 'USE' operands for statement 'G'. 11477 11478 -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g) 11479 Return the set of 'VUSE' operands for statement 'G'. 11480 11481 -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct 11482 voptype_d *ops) 11483 Set 'OPS' to be the set of 'VUSE' operands for statement 'G'. 11484 11485 -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g) 11486 Return the set of 'VDEF' operands for statement 'G'. 11487 11488 -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct 11489 voptype_d *ops) 11490 Set 'OPS' to be the set of 'VDEF' operands for statement 'G'. 11491 11492 -- GIMPLE function: bitmap gimple_loaded_syms (gimple g) 11493 Return the set of symbols loaded by statement 'G'. Each element of 11494 the set is the 'DECL_UID' of the corresponding symbol. 11495 11496 -- GIMPLE function: bitmap gimple_stored_syms (gimple g) 11497 Return the set of symbols stored by statement 'G'. Each element of 11498 the set is the 'DECL_UID' of the corresponding symbol. 11499 11500 -- GIMPLE function: bool gimple_modified_p (gimple g) 11501 Return true if statement 'G' has operands and the modified field 11502 has been set. 11503 11504 -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt) 11505 Return true if statement 'STMT' contains volatile operands. 11506 11507 -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, bool 11508 volatilep) 11509 Return true if statement 'STMT' contains volatile operands. 11510 11511 -- GIMPLE function: void update_stmt (gimple s) 11512 Mark statement 'S' as modified, and update it. 11513 11514 -- GIMPLE function: void update_stmt_if_modified (gimple s) 11515 Update statement 'S' if it has been marked modified. 11516 11517 -- GIMPLE function: gimple gimple_copy (gimple stmt) 11518 Return a deep copy of statement 'STMT'. 11519 11520 11521File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE 11522 1152311.8 Tuple specific accessors 11524============================= 11525 11526* Menu: 11527 11528* GIMPLE_ASM:: 11529* GIMPLE_ASSIGN:: 11530* GIMPLE_BIND:: 11531* GIMPLE_CALL:: 11532* GIMPLE_CATCH:: 11533* GIMPLE_COND:: 11534* GIMPLE_DEBUG:: 11535* GIMPLE_EH_FILTER:: 11536* GIMPLE_LABEL:: 11537* GIMPLE_GOTO:: 11538* GIMPLE_NOP:: 11539* GIMPLE_OMP_ATOMIC_LOAD:: 11540* GIMPLE_OMP_ATOMIC_STORE:: 11541* GIMPLE_OMP_CONTINUE:: 11542* GIMPLE_OMP_CRITICAL:: 11543* GIMPLE_OMP_FOR:: 11544* GIMPLE_OMP_MASTER:: 11545* GIMPLE_OMP_ORDERED:: 11546* GIMPLE_OMP_PARALLEL:: 11547* GIMPLE_OMP_RETURN:: 11548* GIMPLE_OMP_SECTION:: 11549* GIMPLE_OMP_SECTIONS:: 11550* GIMPLE_OMP_SINGLE:: 11551* GIMPLE_PHI:: 11552* GIMPLE_RESX:: 11553* GIMPLE_RETURN:: 11554* GIMPLE_SWITCH:: 11555* GIMPLE_TRY:: 11556* GIMPLE_WITH_CLEANUP_EXPR:: 11557 11558 11559File: gccint.info, Node: GIMPLE_ASM, Next: GIMPLE_ASSIGN, Up: Tuple specific accessors 11560 1156111.8.1 'GIMPLE_ASM' 11562------------------- 11563 11564 -- GIMPLE function: gasm *gimple_build_asm_vec ( const char *string, 11565 vec<tree, va_gc> *inputs, vec<tree, va_gc> *outputs, vec<tree, 11566 va_gc> *clobbers, vec<tree, va_gc> *labels) 11567 Build a 'GIMPLE_ASM' statement. This statement is used for 11568 building in-line assembly constructs. 'STRING' is the assembly 11569 code. 'INPUTS', 'OUTPUTS', 'CLOBBERS' and 'LABELS' are the inputs, 11570 outputs, clobbered registers and labels. 11571 11572 -- GIMPLE function: unsigned gimple_asm_ninputs (const gasm *g) 11573 Return the number of input operands for 'GIMPLE_ASM' 'G'. 11574 11575 -- GIMPLE function: unsigned gimple_asm_noutputs (const gasm *g) 11576 Return the number of output operands for 'GIMPLE_ASM' 'G'. 11577 11578 -- GIMPLE function: unsigned gimple_asm_nclobbers (const gasm *g) 11579 Return the number of clobber operands for 'GIMPLE_ASM' 'G'. 11580 11581 -- GIMPLE function: tree gimple_asm_input_op (const gasm *g, unsigned 11582 index) 11583 Return input operand 'INDEX' of 'GIMPLE_ASM' 'G'. 11584 11585 -- GIMPLE function: void gimple_asm_set_input_op (gasm *g, unsigned 11586 index, tree in_op) 11587 Set 'IN_OP' to be input operand 'INDEX' in 'GIMPLE_ASM' 'G'. 11588 11589 -- GIMPLE function: tree gimple_asm_output_op (const gasm *g, unsigned 11590 index) 11591 Return output operand 'INDEX' of 'GIMPLE_ASM' 'G'. 11592 11593 -- GIMPLE function: void gimple_asm_set_output_op (gasm *g, unsigned 11594 index, tree out_op) 11595 Set 'OUT_OP' to be output operand 'INDEX' in 'GIMPLE_ASM' 'G'. 11596 11597 -- GIMPLE function: tree gimple_asm_clobber_op (const gasm *g, unsigned 11598 index) 11599 Return clobber operand 'INDEX' of 'GIMPLE_ASM' 'G'. 11600 11601 -- GIMPLE function: void gimple_asm_set_clobber_op (gasm *g, unsigned 11602 index, tree clobber_op) 11603 Set 'CLOBBER_OP' to be clobber operand 'INDEX' in 'GIMPLE_ASM' 'G'. 11604 11605 -- GIMPLE function: const char * gimple_asm_string (const gasm *g) 11606 Return the string representing the assembly instruction in 11607 'GIMPLE_ASM' 'G'. 11608 11609 -- GIMPLE function: bool gimple_asm_volatile_p (const gasm *g) 11610 Return true if 'G' is an asm statement marked volatile. 11611 11612 -- GIMPLE function: void gimple_asm_set_volatile (gasm *g, bool 11613 volatile_p) 11614 Mark asm statement 'G' as volatile or non-volatile based on 11615 'VOLATILE_P'. 11616 11617 11618File: gccint.info, Node: GIMPLE_ASSIGN, Next: GIMPLE_BIND, Prev: GIMPLE_ASM, Up: Tuple specific accessors 11619 1162011.8.2 'GIMPLE_ASSIGN' 11621---------------------- 11622 11623 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, tree rhs) 11624 Build a 'GIMPLE_ASSIGN' statement. The left-hand side is an lvalue 11625 passed in lhs. The right-hand side can be either a unary or binary 11626 tree expression. The expression tree rhs will be flattened and its 11627 operands assigned to the corresponding operand slots in the new 11628 statement. This function is useful when you already have a tree 11629 expression that you want to convert into a tuple. However, try to 11630 avoid building expression trees for the sole purpose of calling 11631 this function. If you already have the operands in separate trees, 11632 it is better to use 'gimple_build_assign' with 'enum tree_code' 11633 argument and separate arguments for each operand. 11634 11635 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 11636 tree_code subcode, tree op1, tree op2, tree op3) 11637 This function is similar to two operand 'gimple_build_assign', but 11638 is used to build a 'GIMPLE_ASSIGN' statement when the operands of 11639 the right-hand side of the assignment are already split into 11640 different operands. 11641 11642 The left-hand side is an lvalue passed in lhs. Subcode is the 11643 'tree_code' for the right-hand side of the assignment. Op1, op2 11644 and op3 are the operands. 11645 11646 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 11647 tree_code subcode, tree op1, tree op2) 11648 Like the above 5 operand 'gimple_build_assign', but with the last 11649 argument 'NULL' - this overload should not be used for 11650 'GIMPLE_TERNARY_RHS' assignments. 11651 11652 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 11653 tree_code subcode, tree op1) 11654 Like the above 4 operand 'gimple_build_assign', but with the last 11655 argument 'NULL' - this overload should be used only for 11656 'GIMPLE_UNARY_RHS' and 'GIMPLE_SINGLE_RHS' assignments. 11657 11658 -- GIMPLE function: gimple gimplify_assign (tree dst, tree src, 11659 gimple_seq *seq_p) 11660 Build a new 'GIMPLE_ASSIGN' tuple and append it to the end of 11661 '*SEQ_P'. 11662 11663 'DST'/'SRC' are the destination and source respectively. You can pass 11664ungimplified trees in 'DST' or 'SRC', in which case they will be 11665converted to a gimple operand if necessary. 11666 11667 This function returns the newly created 'GIMPLE_ASSIGN' tuple. 11668 11669 -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g) 11670 Return the code of the expression computed on the 'RHS' of 11671 assignment statement 'G'. 11672 11673 -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class 11674 (gimple g) 11675 Return the gimple rhs class of the code for the expression computed 11676 on the rhs of assignment statement 'G'. This will never return 11677 'GIMPLE_INVALID_RHS'. 11678 11679 -- GIMPLE function: tree gimple_assign_lhs (gimple g) 11680 Return the 'LHS' of assignment statement 'G'. 11681 11682 -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g) 11683 Return a pointer to the 'LHS' of assignment statement 'G'. 11684 11685 -- GIMPLE function: tree gimple_assign_rhs1 (gimple g) 11686 Return the first operand on the 'RHS' of assignment statement 'G'. 11687 11688 -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g) 11689 Return the address of the first operand on the 'RHS' of assignment 11690 statement 'G'. 11691 11692 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 11693 Return the second operand on the 'RHS' of assignment statement 'G'. 11694 11695 -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g) 11696 Return the address of the second operand on the 'RHS' of assignment 11697 statement 'G'. 11698 11699 -- GIMPLE function: tree gimple_assign_rhs3 (gimple g) 11700 Return the third operand on the 'RHS' of assignment statement 'G'. 11701 11702 -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g) 11703 Return the address of the third operand on the 'RHS' of assignment 11704 statement 'G'. 11705 11706 -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs) 11707 Set 'LHS' to be the 'LHS' operand of assignment statement 'G'. 11708 11709 -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs) 11710 Set 'RHS' to be the first operand on the 'RHS' of assignment 11711 statement 'G'. 11712 11713 -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs) 11714 Set 'RHS' to be the second operand on the 'RHS' of assignment 11715 statement 'G'. 11716 11717 -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs) 11718 Set 'RHS' to be the third operand on the 'RHS' of assignment 11719 statement 'G'. 11720 11721 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple s) 11722 Return true if 'S' is a type-cast assignment. 11723 11724 11725File: gccint.info, Node: GIMPLE_BIND, Next: GIMPLE_CALL, Prev: GIMPLE_ASSIGN, Up: Tuple specific accessors 11726 1172711.8.3 'GIMPLE_BIND' 11728-------------------- 11729 11730 -- GIMPLE function: gbind *gimple_build_bind (tree vars, gimple_seq 11731 body) 11732 Build a 'GIMPLE_BIND' statement with a list of variables in 'VARS' 11733 and a body of statements in sequence 'BODY'. 11734 11735 -- GIMPLE function: tree gimple_bind_vars (const gbind *g) 11736 Return the variables declared in the 'GIMPLE_BIND' statement 'G'. 11737 11738 -- GIMPLE function: void gimple_bind_set_vars (gbind *g, tree vars) 11739 Set 'VARS' to be the set of variables declared in the 'GIMPLE_BIND' 11740 statement 'G'. 11741 11742 -- GIMPLE function: void gimple_bind_append_vars (gbind *g, tree vars) 11743 Append 'VARS' to the set of variables declared in the 'GIMPLE_BIND' 11744 statement 'G'. 11745 11746 -- GIMPLE function: gimple_seq gimple_bind_body (gbind *g) 11747 Return the GIMPLE sequence contained in the 'GIMPLE_BIND' statement 11748 'G'. 11749 11750 -- GIMPLE function: void gimple_bind_set_body (gbind *g, gimple_seq 11751 seq) 11752 Set 'SEQ' to be sequence contained in the 'GIMPLE_BIND' statement 11753 'G'. 11754 11755 -- GIMPLE function: void gimple_bind_add_stmt (gbind *gs, gimple stmt) 11756 Append a statement to the end of a 'GIMPLE_BIND''s body. 11757 11758 -- GIMPLE function: void gimple_bind_add_seq (gbind *gs, gimple_seq 11759 seq) 11760 Append a sequence of statements to the end of a 'GIMPLE_BIND''s 11761 body. 11762 11763 -- GIMPLE function: tree gimple_bind_block (const gbind *g) 11764 Return the 'TREE_BLOCK' node associated with 'GIMPLE_BIND' 11765 statement 'G'. This is analogous to the 'BIND_EXPR_BLOCK' field in 11766 trees. 11767 11768 -- GIMPLE function: void gimple_bind_set_block (gbind *g, tree block) 11769 Set 'BLOCK' to be the 'TREE_BLOCK' node associated with 11770 'GIMPLE_BIND' statement 'G'. 11771 11772 11773File: gccint.info, Node: GIMPLE_CALL, Next: GIMPLE_CATCH, Prev: GIMPLE_BIND, Up: Tuple specific accessors 11774 1177511.8.4 'GIMPLE_CALL' 11776-------------------- 11777 11778 -- GIMPLE function: gcall *gimple_build_call (tree fn, unsigned nargs, 11779 ...) 11780 Build a 'GIMPLE_CALL' statement to function 'FN'. The argument 11781 'FN' must be either a 'FUNCTION_DECL' or a gimple call address as 11782 determined by 'is_gimple_call_addr'. 'NARGS' are the number of 11783 arguments. The rest of the arguments follow the argument 'NARGS', 11784 and must be trees that are valid as rvalues in gimple (i.e., each 11785 operand is validated with 'is_gimple_operand'). 11786 11787 -- GIMPLE function: gcall *gimple_build_call_from_tree (tree call_expr) 11788 Build a 'GIMPLE_CALL' from a 'CALL_EXPR' node. The arguments and 11789 the function are taken from the expression directly. This routine 11790 assumes that 'call_expr' is already in GIMPLE form. That is, its 11791 operands are GIMPLE values and the function call needs no further 11792 simplification. All the call flags in 'call_expr' are copied over 11793 to the new 'GIMPLE_CALL'. 11794 11795 -- GIMPLE function: gcall *gimple_build_call_vec (tree fn, 'vec<tree>' 11796 args) 11797 Identical to 'gimple_build_call' but the arguments are stored in a 11798 'vec<tree>'. 11799 11800 -- GIMPLE function: tree gimple_call_lhs (gimple g) 11801 Return the 'LHS' of call statement 'G'. 11802 11803 -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g) 11804 Return a pointer to the 'LHS' of call statement 'G'. 11805 11806 -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs) 11807 Set 'LHS' to be the 'LHS' operand of call statement 'G'. 11808 11809 -- GIMPLE function: tree gimple_call_fn (gimple g) 11810 Return the tree node representing the function called by call 11811 statement 'G'. 11812 11813 -- GIMPLE function: void gimple_call_set_fn (gcall *g, tree fn) 11814 Set 'FN' to be the function called by call statement 'G'. This has 11815 to be a gimple value specifying the address of the called function. 11816 11817 -- GIMPLE function: tree gimple_call_fndecl (gimple g) 11818 If a given 'GIMPLE_CALL''s callee is a 'FUNCTION_DECL', return it. 11819 Otherwise return 'NULL'. This function is analogous to 11820 'get_callee_fndecl' in 'GENERIC'. 11821 11822 -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl) 11823 Set the called function to 'FNDECL'. 11824 11825 -- GIMPLE function: tree gimple_call_return_type (const gcall *g) 11826 Return the type returned by call statement 'G'. 11827 11828 -- GIMPLE function: tree gimple_call_chain (gimple g) 11829 Return the static chain for call statement 'G'. 11830 11831 -- GIMPLE function: void gimple_call_set_chain (gcall *g, tree chain) 11832 Set 'CHAIN' to be the static chain for call statement 'G'. 11833 11834 -- GIMPLE function: unsigned gimple_call_num_args (gimple g) 11835 Return the number of arguments used by call statement 'G'. 11836 11837 -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index) 11838 Return the argument at position 'INDEX' for call statement 'G'. 11839 The first argument is 0. 11840 11841 -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned 11842 index) 11843 Return a pointer to the argument at position 'INDEX' for call 11844 statement 'G'. 11845 11846 -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned index, 11847 tree arg) 11848 Set 'ARG' to be the argument at position 'INDEX' for call statement 11849 'G'. 11850 11851 -- GIMPLE function: void gimple_call_set_tail (gcall *s) 11852 Mark call statement 'S' as being a tail call (i.e., a call just 11853 before the exit of a function). These calls are candidate for tail 11854 call optimization. 11855 11856 -- GIMPLE function: bool gimple_call_tail_p (gcall *s) 11857 Return true if 'GIMPLE_CALL' 'S' is marked as a tail call. 11858 11859 -- GIMPLE function: bool gimple_call_noreturn_p (gimple s) 11860 Return true if 'S' is a noreturn call. 11861 11862 -- GIMPLE function: gimple gimple_call_copy_skip_args (gcall *stmt, 11863 bitmap args_to_skip) 11864 Build a 'GIMPLE_CALL' identical to 'STMT' but skipping the 11865 arguments in the positions marked by the set 'ARGS_TO_SKIP'. 11866 11867 11868File: gccint.info, Node: GIMPLE_CATCH, Next: GIMPLE_COND, Prev: GIMPLE_CALL, Up: Tuple specific accessors 11869 1187011.8.5 'GIMPLE_CATCH' 11871--------------------- 11872 11873 -- GIMPLE function: gcatch *gimple_build_catch (tree types, gimple_seq 11874 handler) 11875 Build a 'GIMPLE_CATCH' statement. 'TYPES' are the tree types this 11876 catch handles. 'HANDLER' is a sequence of statements with the code 11877 for the handler. 11878 11879 -- GIMPLE function: tree gimple_catch_types (const gcatch *g) 11880 Return the types handled by 'GIMPLE_CATCH' statement 'G'. 11881 11882 -- GIMPLE function: tree * gimple_catch_types_ptr (gcatch *g) 11883 Return a pointer to the types handled by 'GIMPLE_CATCH' statement 11884 'G'. 11885 11886 -- GIMPLE function: gimple_seq gimple_catch_handler (gcatch *g) 11887 Return the GIMPLE sequence representing the body of the handler of 11888 'GIMPLE_CATCH' statement 'G'. 11889 11890 -- GIMPLE function: void gimple_catch_set_types (gcatch *g, tree t) 11891 Set 'T' to be the set of types handled by 'GIMPLE_CATCH' 'G'. 11892 11893 -- GIMPLE function: void gimple_catch_set_handler (gcatch *g, 11894 gimple_seq handler) 11895 Set 'HANDLER' to be the body of 'GIMPLE_CATCH' 'G'. 11896 11897 11898File: gccint.info, Node: GIMPLE_COND, Next: GIMPLE_DEBUG, Prev: GIMPLE_CATCH, Up: Tuple specific accessors 11899 1190011.8.6 'GIMPLE_COND' 11901-------------------- 11902 11903 -- GIMPLE function: gcond *gimple_build_cond ( enum tree_code 11904 pred_code, tree lhs, tree rhs, tree t_label, tree f_label) 11905 Build a 'GIMPLE_COND' statement. 'A' 'GIMPLE_COND' statement 11906 compares 'LHS' and 'RHS' and if the condition in 'PRED_CODE' is 11907 true, jump to the label in 't_label', otherwise jump to the label 11908 in 'f_label'. 'PRED_CODE' are relational operator tree codes like 11909 'EQ_EXPR', 'LT_EXPR', 'LE_EXPR', 'NE_EXPR', etc. 11910 11911 -- GIMPLE function: gcond *gimple_build_cond_from_tree (tree cond, tree 11912 t_label, tree f_label) 11913 Build a 'GIMPLE_COND' statement from the conditional expression 11914 tree 'COND'. 'T_LABEL' and 'F_LABEL' are as in 11915 'gimple_build_cond'. 11916 11917 -- GIMPLE function: enum tree_code gimple_cond_code (gimple g) 11918 Return the code of the predicate computed by conditional statement 11919 'G'. 11920 11921 -- GIMPLE function: void gimple_cond_set_code (gcond *g, enum tree_code 11922 code) 11923 Set 'CODE' to be the predicate code for the conditional statement 11924 'G'. 11925 11926 -- GIMPLE function: tree gimple_cond_lhs (gimple g) 11927 Return the 'LHS' of the predicate computed by conditional statement 11928 'G'. 11929 11930 -- GIMPLE function: void gimple_cond_set_lhs (gcond *g, tree lhs) 11931 Set 'LHS' to be the 'LHS' operand of the predicate computed by 11932 conditional statement 'G'. 11933 11934 -- GIMPLE function: tree gimple_cond_rhs (gimple g) 11935 Return the 'RHS' operand of the predicate computed by conditional 11936 'G'. 11937 11938 -- GIMPLE function: void gimple_cond_set_rhs (gcond *g, tree rhs) 11939 Set 'RHS' to be the 'RHS' operand of the predicate computed by 11940 conditional statement 'G'. 11941 11942 -- GIMPLE function: tree gimple_cond_true_label (const gcond *g) 11943 Return the label used by conditional statement 'G' when its 11944 predicate evaluates to true. 11945 11946 -- GIMPLE function: void gimple_cond_set_true_label (gcond *g, tree 11947 label) 11948 Set 'LABEL' to be the label used by conditional statement 'G' when 11949 its predicate evaluates to true. 11950 11951 -- GIMPLE function: void gimple_cond_set_false_label (gcond *g, tree 11952 label) 11953 Set 'LABEL' to be the label used by conditional statement 'G' when 11954 its predicate evaluates to false. 11955 11956 -- GIMPLE function: tree gimple_cond_false_label (const gcond *g) 11957 Return the label used by conditional statement 'G' when its 11958 predicate evaluates to false. 11959 11960 -- GIMPLE function: void gimple_cond_make_false (gcond *g) 11961 Set the conditional 'COND_STMT' to be of the form 'if (1 == 0)'. 11962 11963 -- GIMPLE function: void gimple_cond_make_true (gcond *g) 11964 Set the conditional 'COND_STMT' to be of the form 'if (1 == 1)'. 11965 11966 11967File: gccint.info, Node: GIMPLE_DEBUG, Next: GIMPLE_EH_FILTER, Prev: GIMPLE_COND, Up: Tuple specific accessors 11968 1196911.8.7 'GIMPLE_DEBUG' 11970--------------------- 11971 11972 -- GIMPLE function: gdebug *gimple_build_debug_bind (tree var, tree 11973 value, gimple stmt) 11974 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BIND' of 11975 'subcode'. The effect of this statement is to tell debug 11976 information generation machinery that the value of user variable 11977 'var' is given by 'value' at that point, and to remain with that 11978 value until 'var' runs out of scope, a dynamically-subsequent debug 11979 bind statement overrides the binding, or conflicting values reach a 11980 control flow merge point. Even if components of the 'value' 11981 expression change afterwards, the variable is supposed to retain 11982 the same value, though not necessarily the same location. 11983 11984 It is expected that 'var' be most often a tree for automatic user 11985 variables ('VAR_DECL' or 'PARM_DECL') that satisfy the requirements 11986 for gimple registers, but it may also be a tree for a scalarized 11987 component of a user variable ('ARRAY_REF', 'COMPONENT_REF'), or a 11988 debug temporary ('DEBUG_EXPR_DECL'). 11989 11990 As for 'value', it can be an arbitrary tree expression, but it is 11991 recommended that it be in a suitable form for a gimple assignment 11992 'RHS'. It is not expected that user variables that could appear as 11993 'var' ever appear in 'value', because in the latter we'd have their 11994 'SSA_NAME's instead, but even if they were not in SSA form, user 11995 variables appearing in 'value' are to be regarded as part of the 11996 executable code space, whereas those in 'var' are to be regarded as 11997 part of the source code space. There is no way to refer to the 11998 value bound to a user variable within a 'value' expression. 11999 12000 If 'value' is 'GIMPLE_DEBUG_BIND_NOVALUE', debug information 12001 generation machinery is informed that the variable 'var' is 12002 unbound, i.e., that its value is indeterminate, which sometimes 12003 means it is really unavailable, and other times that the compiler 12004 could not keep track of it. 12005 12006 Block and location information for the newly-created stmt are taken 12007 from 'stmt', if given. 12008 12009 -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt) 12010 Return the user variable VAR that is bound at 'stmt'. 12011 12012 -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt) 12013 Return the value expression that is bound to a user variable at 12014 'stmt'. 12015 12016 -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple 12017 stmt) 12018 Return a pointer to the value expression that is bound to a user 12019 variable at 'stmt'. 12020 12021 -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree 12022 var) 12023 Modify the user variable bound at 'stmt' to VAR. 12024 12025 -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, tree 12026 var) 12027 Modify the value bound to the user variable bound at 'stmt' to 12028 VALUE. 12029 12030 -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt) 12031 Modify the value bound to the user variable bound at 'stmt' so that 12032 the variable becomes unbound. 12033 12034 -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt) 12035 Return 'TRUE' if 'stmt' binds a user variable to a value, and 12036 'FALSE' if it unbinds the variable. 12037 12038 12039File: gccint.info, Node: GIMPLE_EH_FILTER, Next: GIMPLE_LABEL, Prev: GIMPLE_DEBUG, Up: Tuple specific accessors 12040 1204111.8.8 'GIMPLE_EH_FILTER' 12042------------------------- 12043 12044 -- GIMPLE function: geh_filter *gimple_build_eh_filter (tree types, 12045 gimple_seq failure) 12046 Build a 'GIMPLE_EH_FILTER' statement. 'TYPES' are the filter's 12047 types. 'FAILURE' is a sequence with the filter's failure action. 12048 12049 -- GIMPLE function: tree gimple_eh_filter_types (gimple g) 12050 Return the types handled by 'GIMPLE_EH_FILTER' statement 'G'. 12051 12052 -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g) 12053 Return a pointer to the types handled by 'GIMPLE_EH_FILTER' 12054 statement 'G'. 12055 12056 -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g) 12057 Return the sequence of statement to execute when 'GIMPLE_EH_FILTER' 12058 statement fails. 12059 12060 -- GIMPLE function: void gimple_eh_filter_set_types (geh_filter *g, 12061 tree types) 12062 Set 'TYPES' to be the set of types handled by 'GIMPLE_EH_FILTER' 12063 'G'. 12064 12065 -- GIMPLE function: void gimple_eh_filter_set_failure (geh_filter *g, 12066 gimple_seq failure) 12067 Set 'FAILURE' to be the sequence of statements to execute on 12068 failure for 'GIMPLE_EH_FILTER' 'G'. 12069 12070 -- GIMPLE function: tree gimple_eh_must_not_throw_fndecl ( geh_mnt 12071 *eh_mnt_stmt) 12072 Get the function decl to be called by the MUST_NOT_THROW region. 12073 12074 -- GIMPLE function: void gimple_eh_must_not_throw_set_fndecl ( geh_mnt 12075 *eh_mnt_stmt, tree decl) 12076 Set the function decl to be called by GS to DECL. 12077 12078 12079File: gccint.info, Node: GIMPLE_LABEL, Next: GIMPLE_GOTO, Prev: GIMPLE_EH_FILTER, Up: Tuple specific accessors 12080 1208111.8.9 'GIMPLE_LABEL' 12082--------------------- 12083 12084 -- GIMPLE function: glabel *gimple_build_label (tree label) 12085 Build a 'GIMPLE_LABEL' statement with corresponding to the tree 12086 label, 'LABEL'. 12087 12088 -- GIMPLE function: tree gimple_label_label (const glabel *g) 12089 Return the 'LABEL_DECL' node used by 'GIMPLE_LABEL' statement 'G'. 12090 12091 -- GIMPLE function: void gimple_label_set_label (glabel *g, tree label) 12092 Set 'LABEL' to be the 'LABEL_DECL' node used by 'GIMPLE_LABEL' 12093 statement 'G'. 12094 12095 12096File: gccint.info, Node: GIMPLE_GOTO, Next: GIMPLE_NOP, Prev: GIMPLE_LABEL, Up: Tuple specific accessors 12097 1209811.8.10 'GIMPLE_GOTO' 12099--------------------- 12100 12101 -- GIMPLE function: ggoto *gimple_build_goto (tree dest) 12102 Build a 'GIMPLE_GOTO' statement to label 'DEST'. 12103 12104 -- GIMPLE function: tree gimple_goto_dest (gimple g) 12105 Return the destination of the unconditional jump 'G'. 12106 12107 -- GIMPLE function: void gimple_goto_set_dest (ggoto *g, tree dest) 12108 Set 'DEST' to be the destination of the unconditional jump 'G'. 12109 12110 12111File: gccint.info, Node: GIMPLE_NOP, Next: GIMPLE_OMP_ATOMIC_LOAD, Prev: GIMPLE_GOTO, Up: Tuple specific accessors 12112 1211311.8.11 'GIMPLE_NOP' 12114-------------------- 12115 12116 -- GIMPLE function: gimple gimple_build_nop (void) 12117 Build a 'GIMPLE_NOP' statement. 12118 12119 -- GIMPLE function: bool gimple_nop_p (gimple g) 12120 Returns 'TRUE' if statement 'G' is a 'GIMPLE_NOP'. 12121 12122 12123File: gccint.info, Node: GIMPLE_OMP_ATOMIC_LOAD, Next: GIMPLE_OMP_ATOMIC_STORE, Prev: GIMPLE_NOP, Up: Tuple specific accessors 12124 1212511.8.12 'GIMPLE_OMP_ATOMIC_LOAD' 12126-------------------------------- 12127 12128 -- GIMPLE function: gomp_atomic_load *gimple_build_omp_atomic_load ( 12129 tree lhs, tree rhs) 12130 Build a 'GIMPLE_OMP_ATOMIC_LOAD' statement. 'LHS' is the left-hand 12131 side of the assignment. 'RHS' is the right-hand side of the 12132 assignment. 12133 12134 -- GIMPLE function: void gimple_omp_atomic_load_set_lhs ( 12135 gomp_atomic_load *g, tree lhs) 12136 Set the 'LHS' of an atomic load. 12137 12138 -- GIMPLE function: tree gimple_omp_atomic_load_lhs ( const 12139 gomp_atomic_load *g) 12140 Get the 'LHS' of an atomic load. 12141 12142 -- GIMPLE function: void gimple_omp_atomic_load_set_rhs ( 12143 gomp_atomic_load *g, tree rhs) 12144 Set the 'RHS' of an atomic set. 12145 12146 -- GIMPLE function: tree gimple_omp_atomic_load_rhs ( const 12147 gomp_atomic_load *g) 12148 Get the 'RHS' of an atomic set. 12149 12150 12151File: gccint.info, Node: GIMPLE_OMP_ATOMIC_STORE, Next: GIMPLE_OMP_CONTINUE, Prev: GIMPLE_OMP_ATOMIC_LOAD, Up: Tuple specific accessors 12152 1215311.8.13 'GIMPLE_OMP_ATOMIC_STORE' 12154--------------------------------- 12155 12156 -- GIMPLE function: gomp_atomic_store *gimple_build_omp_atomic_store ( 12157 tree val) 12158 Build a 'GIMPLE_OMP_ATOMIC_STORE' statement. 'VAL' is the value to 12159 be stored. 12160 12161 -- GIMPLE function: void gimple_omp_atomic_store_set_val ( 12162 gomp_atomic_store *g, tree val) 12163 Set the value being stored in an atomic store. 12164 12165 -- GIMPLE function: tree gimple_omp_atomic_store_val ( const 12166 gomp_atomic_store *g) 12167 Return the value being stored in an atomic store. 12168 12169 12170File: gccint.info, Node: GIMPLE_OMP_CONTINUE, Next: GIMPLE_OMP_CRITICAL, Prev: GIMPLE_OMP_ATOMIC_STORE, Up: Tuple specific accessors 12171 1217211.8.14 'GIMPLE_OMP_CONTINUE' 12173----------------------------- 12174 12175 -- GIMPLE function: gomp_continue *gimple_build_omp_continue ( tree 12176 control_def, tree control_use) 12177 Build a 'GIMPLE_OMP_CONTINUE' statement. 'CONTROL_DEF' is the 12178 definition of the control variable. 'CONTROL_USE' is the use of 12179 the control variable. 12180 12181 -- GIMPLE function: tree gimple_omp_continue_control_def ( const 12182 gomp_continue *s) 12183 Return the definition of the control variable on a 12184 'GIMPLE_OMP_CONTINUE' in 'S'. 12185 12186 -- GIMPLE function: tree gimple_omp_continue_control_def_ptr ( 12187 gomp_continue *s) 12188 Same as above, but return the pointer. 12189 12190 -- GIMPLE function: tree gimple_omp_continue_set_control_def ( 12191 gomp_continue *s) 12192 Set the control variable definition for a 'GIMPLE_OMP_CONTINUE' 12193 statement in 'S'. 12194 12195 -- GIMPLE function: tree gimple_omp_continue_control_use ( const 12196 gomp_continue *s) 12197 Return the use of the control variable on a 'GIMPLE_OMP_CONTINUE' 12198 in 'S'. 12199 12200 -- GIMPLE function: tree gimple_omp_continue_control_use_ptr ( 12201 gomp_continue *s) 12202 Same as above, but return the pointer. 12203 12204 -- GIMPLE function: tree gimple_omp_continue_set_control_use ( 12205 gomp_continue *s) 12206 Set the control variable use for a 'GIMPLE_OMP_CONTINUE' statement 12207 in 'S'. 12208 12209 12210File: gccint.info, Node: GIMPLE_OMP_CRITICAL, Next: GIMPLE_OMP_FOR, Prev: GIMPLE_OMP_CONTINUE, Up: Tuple specific accessors 12211 1221211.8.15 'GIMPLE_OMP_CRITICAL' 12213----------------------------- 12214 12215 -- GIMPLE function: gomp_critical *gimple_build_omp_critical ( 12216 gimple_seq body, tree name) 12217 Build a 'GIMPLE_OMP_CRITICAL' statement. 'BODY' is the sequence of 12218 statements for which only one thread can execute. 'NAME' is an 12219 optional identifier for this critical block. 12220 12221 -- GIMPLE function: tree gimple_omp_critical_name ( const gomp_critical 12222 *g) 12223 Return the name associated with 'OMP_CRITICAL' statement 'G'. 12224 12225 -- GIMPLE function: tree * gimple_omp_critical_name_ptr ( gomp_critical 12226 *g) 12227 Return a pointer to the name associated with 'OMP' critical 12228 statement 'G'. 12229 12230 -- GIMPLE function: void gimple_omp_critical_set_name ( gomp_critical 12231 *g, tree name) 12232 Set 'NAME' to be the name associated with 'OMP' critical statement 12233 'G'. 12234 12235 12236File: gccint.info, Node: GIMPLE_OMP_FOR, Next: GIMPLE_OMP_MASTER, Prev: GIMPLE_OMP_CRITICAL, Up: Tuple specific accessors 12237 1223811.8.16 'GIMPLE_OMP_FOR' 12239------------------------ 12240 12241 -- GIMPLE function: gomp_for *gimple_build_omp_for (gimple_seq body, 12242 tree clauses, tree index, tree initial, tree final, tree incr, 12243 gimple_seq pre_body, enum tree_code omp_for_cond) 12244 Build a 'GIMPLE_OMP_FOR' statement. 'BODY' is sequence of 12245 statements inside the for loop. 'CLAUSES', are any of the loop 12246 construct's clauses. 'PRE_BODY' is the sequence of statements that 12247 are loop invariant. 'INDEX' is the index variable. 'INITIAL' is 12248 the initial value of 'INDEX'. 'FINAL' is final value of 'INDEX'. 12249 OMP_FOR_COND is the predicate used to compare 'INDEX' and 'FINAL'. 12250 'INCR' is the increment expression. 12251 12252 -- GIMPLE function: tree gimple_omp_for_clauses (gimple g) 12253 Return the clauses associated with 'OMP_FOR' 'G'. 12254 12255 -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g) 12256 Return a pointer to the 'OMP_FOR' 'G'. 12257 12258 -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree 12259 clauses) 12260 Set 'CLAUSES' to be the list of clauses associated with 'OMP_FOR' 12261 'G'. 12262 12263 -- GIMPLE function: tree gimple_omp_for_index (gimple g) 12264 Return the index variable for 'OMP_FOR' 'G'. 12265 12266 -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g) 12267 Return a pointer to the index variable for 'OMP_FOR' 'G'. 12268 12269 -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree 12270 index) 12271 Set 'INDEX' to be the index variable for 'OMP_FOR' 'G'. 12272 12273 -- GIMPLE function: tree gimple_omp_for_initial (gimple g) 12274 Return the initial value for 'OMP_FOR' 'G'. 12275 12276 -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g) 12277 Return a pointer to the initial value for 'OMP_FOR' 'G'. 12278 12279 -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree 12280 initial) 12281 Set 'INITIAL' to be the initial value for 'OMP_FOR' 'G'. 12282 12283 -- GIMPLE function: tree gimple_omp_for_final (gimple g) 12284 Return the final value for 'OMP_FOR' 'G'. 12285 12286 -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g) 12287 turn a pointer to the final value for 'OMP_FOR' 'G'. 12288 12289 -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree 12290 final) 12291 Set 'FINAL' to be the final value for 'OMP_FOR' 'G'. 12292 12293 -- GIMPLE function: tree gimple_omp_for_incr (gimple g) 12294 Return the increment value for 'OMP_FOR' 'G'. 12295 12296 -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g) 12297 Return a pointer to the increment value for 'OMP_FOR' 'G'. 12298 12299 -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr) 12300 Set 'INCR' to be the increment value for 'OMP_FOR' 'G'. 12301 12302 -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g) 12303 Return the sequence of statements to execute before the 'OMP_FOR' 12304 statement 'G' starts. 12305 12306 -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g, 12307 gimple_seq pre_body) 12308 Set 'PRE_BODY' to be the sequence of statements to execute before 12309 the 'OMP_FOR' statement 'G' starts. 12310 12311 -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum 12312 tree_code cond) 12313 Set 'COND' to be the condition code for 'OMP_FOR' 'G'. 12314 12315 -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g) 12316 Return the condition code associated with 'OMP_FOR' 'G'. 12317 12318 12319File: gccint.info, Node: GIMPLE_OMP_MASTER, Next: GIMPLE_OMP_ORDERED, Prev: GIMPLE_OMP_FOR, Up: Tuple specific accessors 12320 1232111.8.17 'GIMPLE_OMP_MASTER' 12322--------------------------- 12323 12324 -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body) 12325 Build a 'GIMPLE_OMP_MASTER' statement. 'BODY' is the sequence of 12326 statements to be executed by just the master. 12327 12328 12329File: gccint.info, Node: GIMPLE_OMP_ORDERED, Next: GIMPLE_OMP_PARALLEL, Prev: GIMPLE_OMP_MASTER, Up: Tuple specific accessors 12330 1233111.8.18 'GIMPLE_OMP_ORDERED' 12332---------------------------- 12333 12334 -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body) 12335 Build a 'GIMPLE_OMP_ORDERED' statement. 12336 12337 'BODY' is the sequence of statements inside a loop that will executed 12338in sequence. 12339 12340 12341File: gccint.info, Node: GIMPLE_OMP_PARALLEL, Next: GIMPLE_OMP_RETURN, Prev: GIMPLE_OMP_ORDERED, Up: Tuple specific accessors 12342 1234311.8.19 'GIMPLE_OMP_PARALLEL' 12344----------------------------- 12345 12346 -- GIMPLE function: gomp_parallel *gimple_build_omp_parallel 12347 (gimple_seq body, tree clauses, tree child_fn, tree data_arg) 12348 Build a 'GIMPLE_OMP_PARALLEL' statement. 12349 12350 'BODY' is sequence of statements which are executed in parallel. 12351'CLAUSES', are the 'OMP' parallel construct's clauses. 'CHILD_FN' is 12352the function created for the parallel threads to execute. 'DATA_ARG' 12353are the shared data argument(s). 12354 12355 -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g) 12356 Return true if 'OMP' parallel statement 'G' has the 12357 'GF_OMP_PARALLEL_COMBINED' flag set. 12358 12359 -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g) 12360 Set the 'GF_OMP_PARALLEL_COMBINED' field in 'OMP' parallel 12361 statement 'G'. 12362 12363 -- GIMPLE function: gimple_seq gimple_omp_body (gimple g) 12364 Return the body for the 'OMP' statement 'G'. 12365 12366 -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq 12367 body) 12368 Set 'BODY' to be the body for the 'OMP' statement 'G'. 12369 12370 -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g) 12371 Return the clauses associated with 'OMP_PARALLEL' 'G'. 12372 12373 -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr ( 12374 gomp_parallel *g) 12375 Return a pointer to the clauses associated with 'OMP_PARALLEL' 'G'. 12376 12377 -- GIMPLE function: void gimple_omp_parallel_set_clauses ( 12378 gomp_parallel *g, tree clauses) 12379 Set 'CLAUSES' to be the list of clauses associated with 12380 'OMP_PARALLEL' 'G'. 12381 12382 -- GIMPLE function: tree gimple_omp_parallel_child_fn ( const 12383 gomp_parallel *g) 12384 Return the child function used to hold the body of 'OMP_PARALLEL' 12385 'G'. 12386 12387 -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr ( 12388 gomp_parallel *g) 12389 Return a pointer to the child function used to hold the body of 12390 'OMP_PARALLEL' 'G'. 12391 12392 -- GIMPLE function: void gimple_omp_parallel_set_child_fn ( 12393 gomp_parallel *g, tree child_fn) 12394 Set 'CHILD_FN' to be the child function for 'OMP_PARALLEL' 'G'. 12395 12396 -- GIMPLE function: tree gimple_omp_parallel_data_arg ( const 12397 gomp_parallel *g) 12398 Return the artificial argument used to send variables and values 12399 from the parent to the children threads in 'OMP_PARALLEL' 'G'. 12400 12401 -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr ( 12402 gomp_parallel *g) 12403 Return a pointer to the data argument for 'OMP_PARALLEL' 'G'. 12404 12405 -- GIMPLE function: void gimple_omp_parallel_set_data_arg ( 12406 gomp_parallel *g, tree data_arg) 12407 Set 'DATA_ARG' to be the data argument for 'OMP_PARALLEL' 'G'. 12408 12409 12410File: gccint.info, Node: GIMPLE_OMP_RETURN, Next: GIMPLE_OMP_SECTION, Prev: GIMPLE_OMP_PARALLEL, Up: Tuple specific accessors 12411 1241211.8.20 'GIMPLE_OMP_RETURN' 12413--------------------------- 12414 12415 -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p) 12416 Build a 'GIMPLE_OMP_RETURN' statement. 'WAIT_P' is true if this is 12417 a non-waiting return. 12418 12419 -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s) 12420 Set the nowait flag on 'GIMPLE_OMP_RETURN' statement 'S'. 12421 12422 -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g) 12423 Return true if 'OMP' return statement 'G' has the 12424 'GF_OMP_RETURN_NOWAIT' flag set. 12425 12426 12427File: gccint.info, Node: GIMPLE_OMP_SECTION, Next: GIMPLE_OMP_SECTIONS, Prev: GIMPLE_OMP_RETURN, Up: Tuple specific accessors 12428 1242911.8.21 'GIMPLE_OMP_SECTION' 12430---------------------------- 12431 12432 -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body) 12433 Build a 'GIMPLE_OMP_SECTION' statement for a sections statement. 12434 12435 'BODY' is the sequence of statements in the section. 12436 12437 -- GIMPLE function: bool gimple_omp_section_last_p (gimple g) 12438 Return true if 'OMP' section statement 'G' has the 12439 'GF_OMP_SECTION_LAST' flag set. 12440 12441 -- GIMPLE function: void gimple_omp_section_set_last (gimple g) 12442 Set the 'GF_OMP_SECTION_LAST' flag on 'G'. 12443 12444 12445File: gccint.info, Node: GIMPLE_OMP_SECTIONS, Next: GIMPLE_OMP_SINGLE, Prev: GIMPLE_OMP_SECTION, Up: Tuple specific accessors 12446 1244711.8.22 'GIMPLE_OMP_SECTIONS' 12448----------------------------- 12449 12450 -- GIMPLE function: gomp_sections *gimple_build_omp_sections ( 12451 gimple_seq body, tree clauses) 12452 Build a 'GIMPLE_OMP_SECTIONS' statement. 'BODY' is a sequence of 12453 section statements. 'CLAUSES' are any of the 'OMP' sections 12454 construct's clauses: private, firstprivate, lastprivate, reduction, 12455 and nowait. 12456 12457 -- GIMPLE function: gimple gimple_build_omp_sections_switch (void) 12458 Build a 'GIMPLE_OMP_SECTIONS_SWITCH' statement. 12459 12460 -- GIMPLE function: tree gimple_omp_sections_control (gimple g) 12461 Return the control variable associated with the 12462 'GIMPLE_OMP_SECTIONS' in 'G'. 12463 12464 -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g) 12465 Return a pointer to the clauses associated with the 12466 'GIMPLE_OMP_SECTIONS' in 'G'. 12467 12468 -- GIMPLE function: void gimple_omp_sections_set_control (gimple g, 12469 tree control) 12470 Set 'CONTROL' to be the set of clauses associated with the 12471 'GIMPLE_OMP_SECTIONS' in 'G'. 12472 12473 -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g) 12474 Return the clauses associated with 'OMP_SECTIONS' 'G'. 12475 12476 -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g) 12477 Return a pointer to the clauses associated with 'OMP_SECTIONS' 'G'. 12478 12479 -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g, 12480 tree clauses) 12481 Set 'CLAUSES' to be the set of clauses associated with 12482 'OMP_SECTIONS' 'G'. 12483 12484 12485File: gccint.info, Node: GIMPLE_OMP_SINGLE, Next: GIMPLE_PHI, Prev: GIMPLE_OMP_SECTIONS, Up: Tuple specific accessors 12486 1248711.8.23 'GIMPLE_OMP_SINGLE' 12488--------------------------- 12489 12490 -- GIMPLE function: gomp_single *gimple_build_omp_single ( gimple_seq 12491 body, tree clauses) 12492 Build a 'GIMPLE_OMP_SINGLE' statement. 'BODY' is the sequence of 12493 statements that will be executed once. 'CLAUSES' are any of the 12494 'OMP' single construct's clauses: private, firstprivate, 12495 copyprivate, nowait. 12496 12497 -- GIMPLE function: tree gimple_omp_single_clauses (gimple g) 12498 Return the clauses associated with 'OMP_SINGLE' 'G'. 12499 12500 -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g) 12501 Return a pointer to the clauses associated with 'OMP_SINGLE' 'G'. 12502 12503 -- GIMPLE function: void gimple_omp_single_set_clauses ( gomp_single 12504 *g, tree clauses) 12505 Set 'CLAUSES' to be the clauses associated with 'OMP_SINGLE' 'G'. 12506 12507 12508File: gccint.info, Node: GIMPLE_PHI, Next: GIMPLE_RESX, Prev: GIMPLE_OMP_SINGLE, Up: Tuple specific accessors 12509 1251011.8.24 'GIMPLE_PHI' 12511-------------------- 12512 12513 -- GIMPLE function: unsigned gimple_phi_capacity (gimple g) 12514 Return the maximum number of arguments supported by 'GIMPLE_PHI' 12515 'G'. 12516 12517 -- GIMPLE function: unsigned gimple_phi_num_args (gimple g) 12518 Return the number of arguments in 'GIMPLE_PHI' 'G'. This must 12519 always be exactly the number of incoming edges for the basic block 12520 holding 'G'. 12521 12522 -- GIMPLE function: tree gimple_phi_result (gimple g) 12523 Return the 'SSA' name created by 'GIMPLE_PHI' 'G'. 12524 12525 -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g) 12526 Return a pointer to the 'SSA' name created by 'GIMPLE_PHI' 'G'. 12527 12528 -- GIMPLE function: void gimple_phi_set_result (gphi *g, tree result) 12529 Set 'RESULT' to be the 'SSA' name created by 'GIMPLE_PHI' 'G'. 12530 12531 -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index) 12532 Return the 'PHI' argument corresponding to incoming edge 'INDEX' 12533 for 'GIMPLE_PHI' 'G'. 12534 12535 -- GIMPLE function: void gimple_phi_set_arg (gphi *g, index, struct 12536 phi_arg_d * phiarg) 12537 Set 'PHIARG' to be the argument corresponding to incoming edge 12538 'INDEX' for 'GIMPLE_PHI' 'G'. 12539 12540 12541File: gccint.info, Node: GIMPLE_RESX, Next: GIMPLE_RETURN, Prev: GIMPLE_PHI, Up: Tuple specific accessors 12542 1254311.8.25 'GIMPLE_RESX' 12544--------------------- 12545 12546 -- GIMPLE function: gresx *gimple_build_resx (int region) 12547 Build a 'GIMPLE_RESX' statement which is a statement. This 12548 statement is a placeholder for _Unwind_Resume before we know if a 12549 function call or a branch is needed. 'REGION' is the exception 12550 region from which control is flowing. 12551 12552 -- GIMPLE function: int gimple_resx_region (const gresx *g) 12553 Return the region number for 'GIMPLE_RESX' 'G'. 12554 12555 -- GIMPLE function: void gimple_resx_set_region (gresx *g, int region) 12556 Set 'REGION' to be the region number for 'GIMPLE_RESX' 'G'. 12557 12558 12559File: gccint.info, Node: GIMPLE_RETURN, Next: GIMPLE_SWITCH, Prev: GIMPLE_RESX, Up: Tuple specific accessors 12560 1256111.8.26 'GIMPLE_RETURN' 12562----------------------- 12563 12564 -- GIMPLE function: greturn *gimple_build_return (tree retval) 12565 Build a 'GIMPLE_RETURN' statement whose return value is retval. 12566 12567 -- GIMPLE function: tree gimple_return_retval (const greturn *g) 12568 Return the return value for 'GIMPLE_RETURN' 'G'. 12569 12570 -- GIMPLE function: void gimple_return_set_retval (greturn *g, tree 12571 retval) 12572 Set 'RETVAL' to be the return value for 'GIMPLE_RETURN' 'G'. 12573 12574 12575File: gccint.info, Node: GIMPLE_SWITCH, Next: GIMPLE_TRY, Prev: GIMPLE_RETURN, Up: Tuple specific accessors 12576 1257711.8.27 'GIMPLE_SWITCH' 12578----------------------- 12579 12580 -- GIMPLE function: gswitch *gimple_build_switch (tree index, tree 12581 default_label, 'vec'<tree> *args) 12582 Build a 'GIMPLE_SWITCH' statement. 'INDEX' is the index variable 12583 to switch on, and 'DEFAULT_LABEL' represents the default label. 12584 'ARGS' is a vector of 'CASE_LABEL_EXPR' trees that contain the 12585 non-default case labels. Each label is a tree of code 12586 'CASE_LABEL_EXPR'. 12587 12588 -- GIMPLE function: unsigned gimple_switch_num_labels ( const gswitch 12589 *g) 12590 Return the number of labels associated with the switch statement 12591 'G'. 12592 12593 -- GIMPLE function: void gimple_switch_set_num_labels (gswitch *g, 12594 unsigned nlabels) 12595 Set 'NLABELS' to be the number of labels for the switch statement 12596 'G'. 12597 12598 -- GIMPLE function: tree gimple_switch_index (const gswitch *g) 12599 Return the index variable used by the switch statement 'G'. 12600 12601 -- GIMPLE function: void gimple_switch_set_index (gswitch *g, tree 12602 index) 12603 Set 'INDEX' to be the index variable for switch statement 'G'. 12604 12605 -- GIMPLE function: tree gimple_switch_label (const gswitch *g, 12606 unsigned index) 12607 Return the label numbered 'INDEX'. The default label is 0, 12608 followed by any labels in a switch statement. 12609 12610 -- GIMPLE function: void gimple_switch_set_label (gswitch *g, unsigned 12611 index, tree label) 12612 Set the label number 'INDEX' to 'LABEL'. 0 is always the default 12613 label. 12614 12615 -- GIMPLE function: tree gimple_switch_default_label ( const gswitch 12616 *g) 12617 Return the default label for a switch statement. 12618 12619 -- GIMPLE function: void gimple_switch_set_default_label (gswitch *g, 12620 tree label) 12621 Set the default label for a switch statement. 12622 12623 12624File: gccint.info, Node: GIMPLE_TRY, Next: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_SWITCH, Up: Tuple specific accessors 12625 1262611.8.28 'GIMPLE_TRY' 12627-------------------- 12628 12629 -- GIMPLE function: gtry *gimple_build_try (gimple_seq eval, gimple_seq 12630 cleanup, unsigned int kind) 12631 Build a 'GIMPLE_TRY' statement. 'EVAL' is a sequence with the 12632 expression to evaluate. 'CLEANUP' is a sequence of statements to 12633 run at clean-up time. 'KIND' is the enumeration value 12634 'GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct 12635 or 'GIMPLE_TRY_FINALLY' if this statement denotes a try/finally 12636 construct. 12637 12638 -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g) 12639 Return the kind of try block represented by 'GIMPLE_TRY' 'G'. This 12640 is either 'GIMPLE_TRY_CATCH' or 'GIMPLE_TRY_FINALLY'. 12641 12642 -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g) 12643 Return the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 12644 12645 -- GIMPLE function: gimple_seq gimple_try_eval (gimple g) 12646 Return the sequence of statements used as the body for 'GIMPLE_TRY' 12647 'G'. 12648 12649 -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g) 12650 Return the sequence of statements used as the cleanup body for 12651 'GIMPLE_TRY' 'G'. 12652 12653 -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g, 12654 bool catch_is_cleanup) 12655 Set the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 12656 12657 -- GIMPLE function: void gimple_try_set_eval (gtry *g, gimple_seq eval) 12658 Set 'EVAL' to be the sequence of statements to use as the body for 12659 'GIMPLE_TRY' 'G'. 12660 12661 -- GIMPLE function: void gimple_try_set_cleanup (gtry *g, gimple_seq 12662 cleanup) 12663 Set 'CLEANUP' to be the sequence of statements to use as the 12664 cleanup body for 'GIMPLE_TRY' 'G'. 12665 12666 12667File: gccint.info, Node: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_TRY, Up: Tuple specific accessors 12668 1266911.8.29 'GIMPLE_WITH_CLEANUP_EXPR' 12670---------------------------------- 12671 12672 -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup) 12673 Build a 'GIMPLE_WITH_CLEANUP_EXPR' statement. 'CLEANUP' is the 12674 clean-up expression. 12675 12676 -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g) 12677 Return the cleanup sequence for cleanup statement 'G'. 12678 12679 -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq 12680 cleanup) 12681 Set 'CLEANUP' to be the cleanup sequence for 'G'. 12682 12683 -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g) 12684 Return the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 12685 12686 -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, bool 12687 eh_only_p) 12688 Set the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 12689 12690 12691File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE 12692 1269311.9 GIMPLE sequences 12694===================== 12695 12696GIMPLE sequences are the tuple equivalent of 'STATEMENT_LIST''s used in 12697'GENERIC'. They are used to chain statements together, and when used in 12698conjunction with sequence iterators, provide a framework for iterating 12699through statements. 12700 12701 GIMPLE sequences are of type struct 'gimple_sequence', but are more 12702commonly passed by reference to functions dealing with sequences. The 12703type for a sequence pointer is 'gimple_seq' which is the same as struct 12704'gimple_sequence' *. When declaring a local sequence, you can define a 12705local variable of type struct 'gimple_sequence'. When declaring a 12706sequence allocated on the garbage collected heap, use the function 12707'gimple_seq_alloc' documented below. 12708 12709 There are convenience functions for iterating through sequences in the 12710section entitled Sequence Iterators. 12711 12712 Below is a list of functions to manipulate and query sequences. 12713 12714 -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple 12715 g) 12716 Link a gimple statement to the end of the sequence *'SEQ' if 'G' is 12717 not 'NULL'. If *'SEQ' is 'NULL', allocate a sequence before 12718 linking. 12719 12720 -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest, 12721 gimple_seq src) 12722 Append sequence 'SRC' to the end of sequence *'DEST' if 'SRC' is 12723 not 'NULL'. If *'DEST' is 'NULL', allocate a new sequence before 12724 appending. 12725 12726 -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src) 12727 Perform a deep copy of sequence 'SRC' and return the result. 12728 12729 -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq) 12730 Reverse the order of the statements in the sequence 'SEQ'. Return 12731 'SEQ'. 12732 12733 -- GIMPLE function: gimple gimple_seq_first (gimple_seq s) 12734 Return the first statement in sequence 'S'. 12735 12736 -- GIMPLE function: gimple gimple_seq_last (gimple_seq s) 12737 Return the last statement in sequence 'S'. 12738 12739 -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple 12740 last) 12741 Set the last statement in sequence 'S' to the statement in 'LAST'. 12742 12743 -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple 12744 first) 12745 Set the first statement in sequence 'S' to the statement in 12746 'FIRST'. 12747 12748 -- GIMPLE function: void gimple_seq_init (gimple_seq s) 12749 Initialize sequence 'S' to an empty sequence. 12750 12751 -- GIMPLE function: gimple_seq gimple_seq_alloc (void) 12752 Allocate a new sequence in the garbage collected store and return 12753 it. 12754 12755 -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq 12756 src) 12757 Copy the sequence 'SRC' into the sequence 'DEST'. 12758 12759 -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s) 12760 Return true if the sequence 'S' is empty. 12761 12762 -- GIMPLE function: gimple_seq bb_seq (basic_block bb) 12763 Returns the sequence of statements in 'BB'. 12764 12765 -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq) 12766 Sets the sequence of statements in 'BB' to 'SEQ'. 12767 12768 -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq) 12769 Determine whether 'SEQ' contains exactly one statement. 12770 12771 12772File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE 12773 1277411.10 Sequence iterators 12775======================== 12776 12777Sequence iterators are convenience constructs for iterating through 12778statements in a sequence. Given a sequence 'SEQ', here is a typical use 12779of gimple sequence iterators: 12780 12781 gimple_stmt_iterator gsi; 12782 12783 for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi)) 12784 { 12785 gimple g = gsi_stmt (gsi); 12786 /* Do something with gimple statement G. */ 12787 } 12788 12789 Backward iterations are possible: 12790 12791 for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi)) 12792 12793 Forward and backward iterations on basic blocks are possible with 12794'gsi_start_bb' and 'gsi_last_bb'. 12795 12796 In the documentation below we sometimes refer to enum 12797'gsi_iterator_update'. The valid options for this enumeration are: 12798 12799 * 'GSI_NEW_STMT' Only valid when a single statement is added. Move 12800 the iterator to it. 12801 12802 * 'GSI_SAME_STMT' Leave the iterator at the same statement. 12803 12804 * 'GSI_CONTINUE_LINKING' Move iterator to whatever position is 12805 suitable for linking other statements in the same direction. 12806 12807 Below is a list of the functions used to manipulate and use statement 12808iterators. 12809 12810 -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq) 12811 Return a new iterator pointing to the sequence 'SEQ''s first 12812 statement. If 'SEQ' is empty, the iterator's basic block is 12813 'NULL'. Use 'gsi_start_bb' instead when the iterator needs to 12814 always have the correct basic block set. 12815 12816 -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb) 12817 Return a new iterator pointing to the first statement in basic 12818 block 'BB'. 12819 12820 -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq) 12821 Return a new iterator initially pointing to the last statement of 12822 sequence 'SEQ'. If 'SEQ' is empty, the iterator's basic block is 12823 'NULL'. Use 'gsi_last_bb' instead when the iterator needs to 12824 always have the correct basic block set. 12825 12826 -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb) 12827 Return a new iterator pointing to the last statement in basic block 12828 'BB'. 12829 12830 -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i) 12831 Return 'TRUE' if at the end of 'I'. 12832 12833 -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i) 12834 Return 'TRUE' if we're one statement before the end of 'I'. 12835 12836 -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i) 12837 Advance the iterator to the next gimple statement. 12838 12839 -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i) 12840 Advance the iterator to the previous gimple statement. 12841 12842 -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i) 12843 Return the current stmt. 12844 12845 -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block 12846 bb) 12847 Return a block statement iterator that points to the first 12848 non-label statement in block 'BB'. 12849 12850 -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i) 12851 Return a pointer to the current stmt. 12852 12853 -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i) 12854 Return the basic block associated with this iterator. 12855 12856 -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i) 12857 Return the sequence associated with this iterator. 12858 12859 -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool 12860 remove_eh_info) 12861 Remove the current stmt from the sequence. The iterator is updated 12862 to point to the next statement. When 'REMOVE_EH_INFO' is true we 12863 remove the statement pointed to by iterator 'I' from the 'EH' 12864 tables. Otherwise we do not modify the 'EH' tables. Generally, 12865 'REMOVE_EH_INFO' should be true when the statement is going to be 12866 removed from the 'IL' and not reinserted elsewhere. 12867 12868 -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i, 12869 gimple_seq seq, enum gsi_iterator_update mode) 12870 Links the sequence of statements 'SEQ' before the statement pointed 12871 by iterator 'I'. 'MODE' indicates what to do with the iterator 12872 after insertion (see 'enum gsi_iterator_update' above). 12873 12874 -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i, 12875 gimple g, enum gsi_iterator_update mode) 12876 Links statement 'G' before the statement pointed-to by iterator 12877 'I'. Updates iterator 'I' according to 'MODE'. 12878 12879 -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i, 12880 gimple_seq seq, enum gsi_iterator_update mode) 12881 Links sequence 'SEQ' after the statement pointed-to by iterator 12882 'I'. 'MODE' is as in 'gsi_insert_after'. 12883 12884 -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i, 12885 gimple g, enum gsi_iterator_update mode) 12886 Links statement 'G' after the statement pointed-to by iterator 'I'. 12887 'MODE' is as in 'gsi_insert_after'. 12888 12889 -- GIMPLE function: gimple_seq gsi_split_seq_after 12890 (gimple_stmt_iterator i) 12891 Move all statements in the sequence after 'I' to a new sequence. 12892 Return this new sequence. 12893 12894 -- GIMPLE function: gimple_seq gsi_split_seq_before 12895 (gimple_stmt_iterator *i) 12896 Move all statements in the sequence before 'I' to a new sequence. 12897 Return this new sequence. 12898 12899 -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple 12900 stmt, bool update_eh_info) 12901 Replace the statement pointed-to by 'I' to 'STMT'. If 12902 'UPDATE_EH_INFO' is true, the exception handling information of the 12903 original statement is moved to the new statement. 12904 12905 -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i, 12906 gimple stmt, enum gsi_iterator_update mode) 12907 Insert statement 'STMT' before the statement pointed-to by iterator 12908 'I', update 'STMT''s basic block and scan it for new operands. 12909 'MODE' specifies how to update iterator 'I' after insertion (see 12910 enum 'gsi_iterator_update'). 12911 12912 -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator 12913 *i, gimple_seq seq, enum gsi_iterator_update mode) 12914 Like 'gsi_insert_before', but for all the statements in 'SEQ'. 12915 12916 -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i, 12917 gimple stmt, enum gsi_iterator_update mode) 12918 Insert statement 'STMT' after the statement pointed-to by iterator 12919 'I', update 'STMT''s basic block and scan it for new operands. 12920 'MODE' specifies how to update iterator 'I' after insertion (see 12921 enum 'gsi_iterator_update'). 12922 12923 -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator *i, 12924 gimple_seq seq, enum gsi_iterator_update mode) 12925 Like 'gsi_insert_after', but for all the statements in 'SEQ'. 12926 12927 -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt) 12928 Finds iterator for 'STMT'. 12929 12930 -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from, 12931 gimple_stmt_iterator *to) 12932 Move the statement at 'FROM' so it comes right after the statement 12933 at 'TO'. 12934 12935 -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from, 12936 gimple_stmt_iterator *to) 12937 Move the statement at 'FROM' so it comes right before the statement 12938 at 'TO'. 12939 12940 -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator 12941 *from, basic_block bb) 12942 Move the statement at 'FROM' to the end of basic block 'BB'. 12943 12944 -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt) 12945 Add 'STMT' to the pending list of edge 'E'. No actual insertion is 12946 made until a call to 'gsi_commit_edge_inserts'() is made. 12947 12948 -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq 12949 seq) 12950 Add the sequence of statements in 'SEQ' to the pending list of edge 12951 'E'. No actual insertion is made until a call to 12952 'gsi_commit_edge_inserts'() is made. 12953 12954 -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e, 12955 gimple stmt) 12956 Similar to 'gsi_insert_on_edge'+'gsi_commit_edge_inserts'. If a 12957 new block has to be created, it is returned. 12958 12959 -- GIMPLE function: void gsi_commit_one_edge_insert (edge e, 12960 basic_block *new_bb) 12961 Commit insertions pending at edge 'E'. If a new block is created, 12962 set 'NEW_BB' to this block, otherwise set it to 'NULL'. 12963 12964 -- GIMPLE function: void gsi_commit_edge_inserts (void) 12965 This routine will commit all pending edge insertions, creating any 12966 new basic blocks which are necessary. 12967 12968 12969File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE 12970 1297111.11 Adding a new GIMPLE statement code 12972======================================== 12973 12974The first step in adding a new GIMPLE statement code, is modifying the 12975file 'gimple.def', which contains all the GIMPLE codes. Then you must 12976add a corresponding gimple subclass located in 'gimple.h'. This in 12977turn, will require you to add a corresponding 'GTY' tag in 12978'gsstruct.def', and code to handle this tag in 'gss_for_code' which is 12979located in 'gimple.c'. 12980 12981 In order for the garbage collector to know the size of the structure 12982you created in 'gimple.h', you need to add a case to handle your new 12983GIMPLE statement in 'gimple_size' which is located in 'gimple.c'. 12984 12985 You will probably want to create a function to build the new gimple 12986statement in 'gimple.c'. The function should be called 12987'gimple_build_NEW-TUPLE-NAME', and should return the new tuple as a 12988pointer to the appropriate gimple subclass. 12989 12990 If your new statement requires accessors for any members or operands it 12991may have, put simple inline accessors in 'gimple.h' and any non-trivial 12992accessors in 'gimple.c' with a corresponding prototype in 'gimple.h'. 12993 12994 You should add the new statement subclass to the class hierarchy 12995diagram in 'gimple.texi'. 12996 12997 12998File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE 12999 1300011.12 Statement and operand traversals 13001====================================== 13002 13003There are two functions available for walking statements and sequences: 13004'walk_gimple_stmt' and 'walk_gimple_seq', accordingly, and a third 13005function for walking the operands in a statement: 'walk_gimple_op'. 13006 13007 -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi, 13008 walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct 13009 walk_stmt_info *wi) 13010 This function is used to walk the current statement in 'GSI', 13011 optionally using traversal state stored in 'WI'. If 'WI' is 13012 'NULL', no state is kept during the traversal. 13013 13014 The callback 'CALLBACK_STMT' is called. If 'CALLBACK_STMT' returns 13015 true, it means that the callback function has handled all the 13016 operands of the statement and it is not necessary to walk its 13017 operands. 13018 13019 If 'CALLBACK_STMT' is 'NULL' or it returns false, 'CALLBACK_OP' is 13020 called on each operand of the statement via 'walk_gimple_op'. If 13021 'walk_gimple_op' returns non-'NULL' for any operand, the remaining 13022 operands are not scanned. 13023 13024 The return value is that returned by the last call to 13025 'walk_gimple_op', or 'NULL_TREE' if no 'CALLBACK_OP' is specified. 13026 13027 -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn 13028 callback_op, struct walk_stmt_info *wi) 13029 Use this function to walk the operands of statement 'STMT'. Every 13030 operand is walked via 'walk_tree' with optional state information 13031 in 'WI'. 13032 13033 'CALLBACK_OP' is called on each operand of 'STMT' via 'walk_tree'. 13034 Additional parameters to 'walk_tree' must be stored in 'WI'. For 13035 each operand 'OP', 'walk_tree' is called as: 13036 13037 walk_tree (&OP, CALLBACK_OP, WI, PSET) 13038 13039 If 'CALLBACK_OP' returns non-'NULL' for an operand, the remaining 13040 operands are not scanned. The return value is that returned by the 13041 last call to 'walk_tree', or 'NULL_TREE' if no 'CALLBACK_OP' is 13042 specified. 13043 13044 -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn 13045 callback_stmt, walk_tree_fn callback_op, struct walk_stmt_info 13046 *wi) 13047 This function walks all the statements in the sequence 'SEQ' 13048 calling 'walk_gimple_stmt' on each one. 'WI' is as in 13049 'walk_gimple_stmt'. If 'walk_gimple_stmt' returns non-'NULL', the 13050 walk is stopped and the value returned. Otherwise, all the 13051 statements are walked and 'NULL_TREE' returned. 13052 13053 13054File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top 13055 1305612 Analysis and Optimization of GIMPLE tuples 13057********************************************* 13058 13059GCC uses three main intermediate languages to represent the program 13060during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 13061language-independent representation generated by each front end. It is 13062used to serve as an interface between the parser and optimizer. GENERIC 13063is a common representation that is able to represent programs written in 13064all the languages supported by GCC. 13065 13066 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 13067target and language independent optimizations (e.g., inlining, constant 13068propagation, tail call elimination, redundancy elimination, etc). Much 13069like GENERIC, GIMPLE is a language independent, tree based 13070representation. However, it differs from GENERIC in that the GIMPLE 13071grammar is more restrictive: expressions contain no more than 3 operands 13072(except function calls), it has no control flow structures and 13073expressions with side-effects are only allowed on the right hand side of 13074assignments. See the chapter describing GENERIC and GIMPLE for more 13075details. 13076 13077 This chapter describes the data structures and functions used in the 13078GIMPLE optimizers (also known as "tree optimizers" or "middle end"). In 13079particular, it focuses on all the macros, data structures, functions and 13080programming constructs needed to implement optimization passes for 13081GIMPLE. 13082 13083* Menu: 13084 13085* Annotations:: Attributes for variables. 13086* SSA Operands:: SSA names referenced by GIMPLE statements. 13087* SSA:: Static Single Assignment representation. 13088* Alias analysis:: Representing aliased loads and stores. 13089* Memory model:: Memory model used by the middle-end. 13090 13091 13092File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA 13093 1309412.1 Annotations 13095================ 13096 13097The optimizers need to associate attributes with variables during the 13098optimization process. For instance, we need to know whether a variable 13099has aliases. All these attributes are stored in data structures called 13100annotations which are then linked to the field 'ann' in 'struct 13101tree_common'. 13102 13103 13104File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 13105 1310612.2 SSA Operands 13107================= 13108 13109Almost every GIMPLE statement will contain a reference to a variable or 13110memory location. Since statements come in different shapes and sizes, 13111their operands are going to be located at various spots inside the 13112statement's tree. To facilitate access to the statement's operands, 13113they are organized into lists associated inside each statement's 13114annotation. Each element in an operand list is a pointer to a 13115'VAR_DECL', 'PARM_DECL' or 'SSA_NAME' tree node. This provides a very 13116convenient way of examining and replacing operands. 13117 13118 Data flow analysis and optimization is done on all tree nodes 13119representing variables. Any node for which 'SSA_VAR_P' returns nonzero 13120is considered when scanning statement operands. However, not all 13121'SSA_VAR_P' variables are processed in the same way. For the purposes 13122of optimization, we need to distinguish between references to local 13123scalar variables and references to globals, statics, structures, arrays, 13124aliased variables, etc. The reason is simple, the compiler can gather 13125complete data flow information for a local scalar. On the other hand, a 13126global variable may be modified by a function call, it may not be 13127possible to keep track of all the elements of an array or the fields of 13128a structure, etc. 13129 13130 The operand scanner gathers two kinds of operands: "real" and 13131"virtual". An operand for which 'is_gimple_reg' returns true is 13132considered real, otherwise it is a virtual operand. We also distinguish 13133between uses and definitions. An operand is used if its value is loaded 13134by the statement (e.g., the operand at the RHS of an assignment). If 13135the statement assigns a new value to the operand, the operand is 13136considered a definition (e.g., the operand at the LHS of an assignment). 13137 13138 Virtual and real operands also have very different data flow 13139properties. Real operands are unambiguous references to the full object 13140that they represent. For instance, given 13141 13142 { 13143 int a, b; 13144 a = b 13145 } 13146 13147 Since 'a' and 'b' are non-aliased locals, the statement 'a = b' will 13148have one real definition and one real use because variable 'a' is 13149completely modified with the contents of variable 'b'. Real definition 13150are also known as "killing definitions". Similarly, the use of 'b' 13151reads all its bits. 13152 13153 In contrast, virtual operands are used with variables that can have a 13154partial or ambiguous reference. This includes structures, arrays, 13155globals, and aliased variables. In these cases, we have two types of 13156definitions. For globals, structures, and arrays, we can determine from 13157a statement whether a variable of these types has a killing definition. 13158If the variable does, then the statement is marked as having a "must 13159definition" of that variable. However, if a statement is only defining 13160a part of the variable (i.e. a field in a structure), or if we know that 13161a statement might define the variable but we cannot say for sure, then 13162we mark that statement as having a "may definition". For instance, 13163given 13164 13165 { 13166 int a, b, *p; 13167 13168 if (...) 13169 p = &a; 13170 else 13171 p = &b; 13172 *p = 5; 13173 return *p; 13174 } 13175 13176 The assignment '*p = 5' may be a definition of 'a' or 'b'. If we 13177cannot determine statically where 'p' is pointing to at the time of the 13178store operation, we create virtual definitions to mark that statement as 13179a potential definition site for 'a' and 'b'. Memory loads are similarly 13180marked with virtual use operands. Virtual operands are shown in tree 13181dumps right before the statement that contains them. To request a tree 13182dump with virtual operands, use the '-vops' option to '-fdump-tree': 13183 13184 { 13185 int a, b, *p; 13186 13187 if (...) 13188 p = &a; 13189 else 13190 p = &b; 13191 # a = VDEF <a> 13192 # b = VDEF <b> 13193 *p = 5; 13194 13195 # VUSE <a> 13196 # VUSE <b> 13197 return *p; 13198 } 13199 13200 Notice that 'VDEF' operands have two copies of the referenced variable. 13201This indicates that this is not a killing definition of that variable. 13202In this case we refer to it as a "may definition" or "aliased store". 13203The presence of the second copy of the variable in the 'VDEF' operand 13204will become important when the function is converted into SSA form. 13205This will be used to link all the non-killing definitions to prevent 13206optimizations from making incorrect assumptions about them. 13207 13208 Operands are updated as soon as the statement is finished via a call to 13209'update_stmt'. If statement elements are changed via 'SET_USE' or 13210'SET_DEF', then no further action is required (i.e., those macros take 13211care of updating the statement). If changes are made by manipulating 13212the statement's tree directly, then a call must be made to 'update_stmt' 13213when complete. Calling one of the 'bsi_insert' routines or 13214'bsi_replace' performs an implicit call to 'update_stmt'. 13215 1321612.2.1 Operand Iterators And Access Routines 13217-------------------------------------------- 13218 13219Operands are collected by 'tree-ssa-operands.c'. They are stored inside 13220each statement's annotation and can be accessed through either the 13221operand iterators or an access routine. 13222 13223 The following access routines are available for examining operands: 13224 13225 1. 'SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 13226 NULL unless there is exactly one operand matching the specified 13227 flags. If there is exactly one operand, the operand is returned as 13228 either a 'tree', 'def_operand_p', or 'use_operand_p'. 13229 13230 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 13231 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 13232 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 13233 13234 2. 'ZERO_SSA_OPERANDS': This macro returns true if there are no 13235 operands matching the specified flags. 13236 13237 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 13238 return; 13239 13240 3. 'NUM_SSA_OPERANDS': This macro Returns the number of operands 13241 matching 'flags'. This actually executes a loop to perform the 13242 count, so only use this if it is really needed. 13243 13244 int count = NUM_SSA_OPERANDS (stmt, flags) 13245 13246 If you wish to iterate over some or all operands, use the 13247'FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 13248all the operands for a statement: 13249 13250 void 13251 print_ops (tree stmt) 13252 { 13253 ssa_op_iter; 13254 tree var; 13255 13256 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 13257 print_generic_expr (stderr, var, TDF_SLIM); 13258 } 13259 13260 How to choose the appropriate iterator: 13261 13262 1. Determine whether you are need to see the operand pointers, or just 13263 the trees, and choose the appropriate macro: 13264 13265 Need Macro: 13266 ---- ------- 13267 use_operand_p FOR_EACH_SSA_USE_OPERAND 13268 def_operand_p FOR_EACH_SSA_DEF_OPERAND 13269 tree FOR_EACH_SSA_TREE_OPERAND 13270 13271 2. You need to declare a variable of the type you are interested in, 13272 and an ssa_op_iter structure which serves as the loop controlling 13273 variable. 13274 13275 3. Determine which operands you wish to use, and specify the flags of 13276 those you are interested in. They are documented in 13277 'tree-ssa-operands.h': 13278 13279 #define SSA_OP_USE 0x01 /* Real USE operands. */ 13280 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 13281 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 13282 #define SSA_OP_VDEF 0x08 /* VDEF operands. */ 13283 13284 /* These are commonly grouped operand flags. */ 13285 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE) 13286 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF) 13287 #define SSA_OP_ALL_VIRTUALS (SSA_OP_VIRTUAL_USES | SSA_OP_VIRTUAL_DEFS) 13288 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 13289 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 13290 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 13291 13292 So if you want to look at the use pointers for all the 'USE' and 'VUSE' 13293operands, you would do something like: 13294 13295 use_operand_p use_p; 13296 ssa_op_iter iter; 13297 13298 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 13299 { 13300 process_use_ptr (use_p); 13301 } 13302 13303 The 'TREE' macro is basically the same as the 'USE' and 'DEF' macros, 13304only with the use or def dereferenced via 'USE_FROM_PTR (use_p)' and 13305'DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use and 13306defs flags can be mixed. 13307 13308 tree var; 13309 ssa_op_iter iter; 13310 13311 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE) 13312 { 13313 print_generic_expr (stderr, var, TDF_SLIM); 13314 } 13315 13316 'VDEF's are broken into two flags, one for the 'DEF' portion 13317('SSA_OP_VDEF') and one for the USE portion ('SSA_OP_VUSE'). 13318 13319 There are many examples in the code, in addition to the documentation 13320in 'tree-ssa-operands.h' and 'ssa-iterators.h'. 13321 13322 There are also a couple of variants on the stmt iterators regarding PHI 13323nodes. 13324 13325 'FOR_EACH_PHI_ARG' Works exactly like 'FOR_EACH_SSA_USE_OPERAND', 13326except it works over 'PHI' arguments instead of statement operands. 13327 13328 /* Look at every virtual PHI use. */ 13329 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 13330 { 13331 my_code; 13332 } 13333 13334 /* Look at every real PHI use. */ 13335 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 13336 my_code; 13337 13338 /* Look at every PHI use. */ 13339 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 13340 my_code; 13341 13342 'FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 13343'FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 13344statement or a 'PHI' node. These should be used when it is appropriate 13345but they are not quite as efficient as the individual 'FOR_EACH_PHI' and 13346'FOR_EACH_SSA' routines. 13347 13348 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 13349 { 13350 my_code; 13351 } 13352 13353 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 13354 { 13355 my_code; 13356 } 13357 1335812.2.2 Immediate Uses 13359--------------------- 13360 13361Immediate use information is now always available. Using the immediate 13362use iterators, you may examine every use of any 'SSA_NAME'. For 13363instance, to change each use of 'ssa_var' to 'ssa_var2' and call 13364fold_stmt on each stmt after that is done: 13365 13366 use_operand_p imm_use_p; 13367 imm_use_iterator iterator; 13368 tree ssa_var, stmt; 13369 13370 13371 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 13372 { 13373 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 13374 SET_USE (imm_use_p, ssa_var_2); 13375 fold_stmt (stmt); 13376 } 13377 13378 There are 2 iterators which can be used. 'FOR_EACH_IMM_USE_FAST' is 13379used when the immediate uses are not changed, i.e., you are looking at 13380the uses, but not setting them. 13381 13382 If they do get changed, then care must be taken that things are not 13383changed under the iterators, so use the 'FOR_EACH_IMM_USE_STMT' and 13384'FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 13385sanity of the use list by moving all the uses for a statement into a 13386controlled position, and then iterating over those uses. Then the 13387optimization can manipulate the stmt when all the uses have been 13388processed. This is a little slower than the FAST version since it adds 13389a placeholder element and must sort through the list a bit for each 13390statement. This placeholder element must be also be removed if the loop 13391is terminated early. The macro 'BREAK_FROM_IMM_USE_SAFE' is provided to 13392do this : 13393 13394 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 13395 { 13396 if (stmt == last_stmt) 13397 BREAK_FROM_SAFE_IMM_USE (iter); 13398 13399 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 13400 SET_USE (imm_use_p, ssa_var_2); 13401 fold_stmt (stmt); 13402 } 13403 13404 There are checks in 'verify_ssa' which verify that the immediate use 13405list is up to date, as well as checking that an optimization didn't 13406break from the loop without using this macro. It is safe to simply 13407'break'; from a 'FOR_EACH_IMM_USE_FAST' traverse. 13408 13409 Some useful functions and macros: 13410 1. 'has_zero_uses (ssa_var)' : Returns true if there are no uses of 13411 'ssa_var'. 13412 2. 'has_single_use (ssa_var)' : Returns true if there is only a single 13413 use of 'ssa_var'. 13414 3. 'single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 13415 Returns true if there is only a single use of 'ssa_var', and also 13416 returns the use pointer and statement it occurs in, in the second 13417 and third parameters. 13418 4. 'num_imm_uses (ssa_var)' : Returns the number of immediate uses of 13419 'ssa_var'. It is better not to use this if possible since it 13420 simply utilizes a loop to count the uses. 13421 5. 'PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a 'PHI' node, 13422 return the index number for the use. An assert is triggered if the 13423 use isn't located in a 'PHI' node. 13424 6. 'USE_STMT (use_p)' : Return the statement a use occurs in. 13425 13426 Note that uses are not put into an immediate use list until their 13427statement is actually inserted into the instruction stream via a 'bsi_*' 13428routine. 13429 13430 It is also still possible to utilize lazy updating of statements, but 13431this should be used only when absolutely required. Both alias analysis 13432and the dominator optimizations currently do this. 13433 13434 When lazy updating is being used, the immediate use information is out 13435of date and cannot be used reliably. Lazy updating is achieved by 13436simply marking statements modified via calls to 'gimple_set_modified' 13437instead of 'update_stmt'. When lazy updating is no longer required, all 13438the modified statements must have 'update_stmt' called in order to bring 13439them up to date. This must be done before the optimization is finished, 13440or 'verify_ssa' will trigger an abort. 13441 13442 This is done with a simple loop over the instruction stream: 13443 block_stmt_iterator bsi; 13444 basic_block bb; 13445 FOR_EACH_BB (bb) 13446 { 13447 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 13448 update_stmt_if_modified (bsi_stmt (bsi)); 13449 } 13450 13451 13452File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA 13453 1345412.3 Static Single Assignment 13455============================= 13456 13457Most of the tree optimizers rely on the data flow information provided 13458by the Static Single Assignment (SSA) form. We implement the SSA form 13459as described in 'R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 13460Zadeck. Efficiently Computing Static Single Assignment Form and the 13461Control Dependence Graph. ACM Transactions on Programming Languages and 13462Systems, 13(4):451-490, October 1991'. 13463 13464 The SSA form is based on the premise that program variables are 13465assigned in exactly one location in the program. Multiple assignments 13466to the same variable create new versions of that variable. Naturally, 13467actual programs are seldom in SSA form initially because variables tend 13468to be assigned multiple times. The compiler modifies the program 13469representation so that every time a variable is assigned in the code, a 13470new version of the variable is created. Different versions of the same 13471variable are distinguished by subscripting the variable name with its 13472version number. Variables used in the right-hand side of expressions 13473are renamed so that their version number matches that of the most recent 13474assignment. 13475 13476 We represent variable versions using 'SSA_NAME' nodes. The renaming 13477process in 'tree-ssa.c' wraps every real and virtual operand with an 13478'SSA_NAME' node which contains the version number and the statement that 13479created the 'SSA_NAME'. Only definitions and virtual definitions may 13480create new 'SSA_NAME' nodes. 13481 13482 Sometimes, flow of control makes it impossible to determine the most 13483recent version of a variable. In these cases, the compiler inserts an 13484artificial definition for that variable called "PHI function" or "PHI 13485node". This new definition merges all the incoming versions of the 13486variable to create a new name for it. For instance, 13487 13488 if (...) 13489 a_1 = 5; 13490 else if (...) 13491 a_2 = 2; 13492 else 13493 a_3 = 13; 13494 13495 # a_4 = PHI <a_1, a_2, a_3> 13496 return a_4; 13497 13498 Since it is not possible to determine which of the three branches will 13499be taken at runtime, we don't know which of 'a_1', 'a_2' or 'a_3' to use 13500at the return statement. So, the SSA renamer creates a new version 13501'a_4' which is assigned the result of "merging" 'a_1', 'a_2' and 'a_3'. 13502Hence, PHI nodes mean "one of these operands. I don't know which". 13503 13504 The following functions can be used to examine PHI nodes 13505 13506 -- Function: gimple_phi_result (PHI) 13507 Returns the 'SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 13508 13509 -- Function: gimple_phi_num_args (PHI) 13510 Returns the number of arguments in PHI. This number is exactly the 13511 number of incoming edges to the basic block holding PHI. 13512 13513 -- Function: gimple_phi_arg (PHI, I) 13514 Returns Ith argument of PHI. 13515 13516 -- Function: gimple_phi_arg_edge (PHI, I) 13517 Returns the incoming edge for the Ith argument of PHI. 13518 13519 -- Function: gimple_phi_arg_def (PHI, I) 13520 Returns the 'SSA_NAME' for the Ith argument of PHI. 13521 1352212.3.1 Preserving the SSA form 13523------------------------------ 13524 13525Some optimization passes make changes to the function that invalidate 13526the SSA property. This can happen when a pass has added new symbols or 13527changed the program so that variables that were previously aliased 13528aren't anymore. Whenever something like this happens, the affected 13529symbols must be renamed into SSA form again. Transformations that emit 13530new code or replicate existing statements will also need to update the 13531SSA form. 13532 13533 Since GCC implements two different SSA forms for register and virtual 13534variables, keeping the SSA form up to date depends on whether you are 13535updating register or virtual names. In both cases, the general idea 13536behind incremental SSA updates is similar: when new SSA names are 13537created, they typically are meant to replace other existing names in the 13538program. 13539 13540 For instance, given the following code: 13541 13542 1 L0: 13543 2 x_1 = PHI (0, x_5) 13544 3 if (x_1 < 10) 13545 4 if (x_1 > 7) 13546 5 y_2 = 0 13547 6 else 13548 7 y_3 = x_1 + x_7 13549 8 endif 13550 9 x_5 = x_1 + 1 13551 10 goto L0; 13552 11 endif 13553 13554 Suppose that we insert new names 'x_10' and 'x_11' (lines '4' and '8'). 13555 13556 1 L0: 13557 2 x_1 = PHI (0, x_5) 13558 3 if (x_1 < 10) 13559 4 x_10 = ... 13560 5 if (x_1 > 7) 13561 6 y_2 = 0 13562 7 else 13563 8 x_11 = ... 13564 9 y_3 = x_1 + x_7 13565 10 endif 13566 11 x_5 = x_1 + 1 13567 12 goto L0; 13568 13 endif 13569 13570 We want to replace all the uses of 'x_1' with the new definitions of 13571'x_10' and 'x_11'. Note that the only uses that should be replaced are 13572those at lines '5', '9' and '11'. Also, the use of 'x_7' at line '9' 13573should _not_ be replaced (this is why we cannot just mark symbol 'x' for 13574renaming). 13575 13576 Additionally, we may need to insert a PHI node at line '11' because 13577that is a merge point for 'x_10' and 'x_11'. So the use of 'x_1' at 13578line '11' will be replaced with the new PHI node. The insertion of PHI 13579nodes is optional. They are not strictly necessary to preserve the SSA 13580form, and depending on what the caller inserted, they may not even be 13581useful for the optimizers. 13582 13583 Updating the SSA form is a two step process. First, the pass has to 13584identify which names need to be updated and/or which symbols need to be 13585renamed into SSA form for the first time. When new names are introduced 13586to replace existing names in the program, the mapping between the old 13587and the new names are registered by calling 'register_new_name_mapping' 13588(note that if your pass creates new code by duplicating basic blocks, 13589the call to 'tree_duplicate_bb' will set up the necessary mappings 13590automatically). 13591 13592 After the replacement mappings have been registered and new symbols 13593marked for renaming, a call to 'update_ssa' makes the registered 13594changes. This can be done with an explicit call or by creating 'TODO' 13595flags in the 'tree_opt_pass' structure for your pass. There are several 13596'TODO' flags that control the behavior of 'update_ssa': 13597 13598 * 'TODO_update_ssa'. Update the SSA form inserting PHI nodes for 13599 newly exposed symbols and virtual names marked for updating. When 13600 updating real names, only insert PHI nodes for a real name 'O_j' in 13601 blocks reached by all the new and old definitions for 'O_j'. If 13602 the iterated dominance frontier for 'O_j' is not pruned, we may end 13603 up inserting PHI nodes in blocks that have one or more edges with 13604 no incoming definition for 'O_j'. This would lead to uninitialized 13605 warnings for 'O_j''s symbol. 13606 13607 * 'TODO_update_ssa_no_phi'. Update the SSA form without inserting 13608 any new PHI nodes at all. This is used by passes that have either 13609 inserted all the PHI nodes themselves or passes that need only to 13610 patch use-def and def-def chains for virtuals (e.g., DCE). 13611 13612 * 'TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are 13613 needed. No pruning of the IDF is done. This is used by passes 13614 that need the PHI nodes for 'O_j' even if it means that some 13615 arguments will come from the default definition of 'O_j''s symbol 13616 (e.g., 'pass_linear_transform'). 13617 13618 WARNING: If you need to use this flag, chances are that your pass 13619 may be doing something wrong. Inserting PHI nodes for an old name 13620 where not all edges carry a new replacement may lead to silent 13621 codegen errors or spurious uninitialized warnings. 13622 13623 * 'TODO_update_ssa_only_virtuals'. Passes that update the SSA form 13624 on their own may want to delegate the updating of virtual names to 13625 the generic updater. Since FUD chains are easier to maintain, this 13626 simplifies the work they need to do. NOTE: If this flag is used, 13627 any OLD->NEW mappings for real names are explicitly destroyed and 13628 only the symbols marked for renaming are processed. 13629 1363012.3.2 Examining 'SSA_NAME' nodes 13631--------------------------------- 13632 13633The following macros can be used to examine 'SSA_NAME' nodes 13634 13635 -- Macro: SSA_NAME_DEF_STMT (VAR) 13636 Returns the statement S that creates the 'SSA_NAME' VAR. If S is 13637 an empty statement (i.e., 'IS_EMPTY_STMT (S)' returns 'true'), it 13638 means that the first reference to this variable is a USE or a VUSE. 13639 13640 -- Macro: SSA_NAME_VERSION (VAR) 13641 Returns the version number of the 'SSA_NAME' object VAR. 13642 1364312.3.3 Walking the dominator tree 13644--------------------------------- 13645 13646 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 13647 13648 This function walks the dominator tree for the current CFG calling 13649 a set of callback functions defined in STRUCT DOM_WALK_DATA in 13650 'domwalk.h'. The call back functions you need to define give you 13651 hooks to execute custom code at various points during traversal: 13652 13653 1. Once to initialize any local data needed while processing BB 13654 and its children. This local data is pushed into an internal 13655 stack which is automatically pushed and popped as the walker 13656 traverses the dominator tree. 13657 13658 2. Once before traversing all the statements in the BB. 13659 13660 3. Once for every statement inside BB. 13661 13662 4. Once after traversing all the statements and before recursing 13663 into BB's dominator children. 13664 13665 5. It then recurses into all the dominator children of BB. 13666 13667 6. After recursing into all the dominator children of BB it can, 13668 optionally, traverse every statement in BB again (i.e., 13669 repeating steps 2 and 3). 13670 13671 7. Once after walking the statements in BB and BB's dominator 13672 children. At this stage, the block local data stack is 13673 popped. 13674 13675 13676File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA 13677 1367812.4 Alias analysis 13679=================== 13680 13681Alias analysis in GIMPLE SSA form consists of two pieces. First the 13682virtual SSA web ties conflicting memory accesses and provides a SSA 13683use-def chain and SSA immediate-use chains for walking possibly 13684dependent memory accesses. Second an alias-oracle can be queried to 13685disambiguate explicit and implicit memory references. 13686 13687 1. Memory SSA form. 13688 13689 All statements that may use memory have exactly one accompanied use 13690 of a virtual SSA name that represents the state of memory at the 13691 given point in the IL. 13692 13693 All statements that may define memory have exactly one accompanied 13694 definition of a virtual SSA name using the previous state of memory 13695 and defining the new state of memory after the given point in the 13696 IL. 13697 13698 int i; 13699 int foo (void) 13700 { 13701 # .MEM_3 = VDEF <.MEM_2(D)> 13702 i = 1; 13703 # VUSE <.MEM_3> 13704 return i; 13705 } 13706 13707 The virtual SSA names in this case are '.MEM_2(D)' and '.MEM_3'. 13708 The store to the global variable 'i' defines '.MEM_3' invalidating 13709 '.MEM_2(D)'. The load from 'i' uses that new state '.MEM_3'. 13710 13711 The virtual SSA web serves as constraints to SSA optimizers 13712 preventing illegitimate code-motion and optimization. It also 13713 provides a way to walk related memory statements. 13714 13715 2. Points-to and escape analysis. 13716 13717 Points-to analysis builds a set of constraints from the GIMPLE SSA 13718 IL representing all pointer operations and facts we do or do not 13719 know about pointers. Solving this set of constraints yields a 13720 conservatively correct solution for each pointer variable in the 13721 program (though we are only interested in SSA name pointers) as to 13722 what it may possibly point to. 13723 13724 This points-to solution for a given SSA name pointer is stored in 13725 the 'pt_solution' sub-structure of the 'SSA_NAME_PTR_INFO' record. 13726 The following accessor functions are available: 13727 13728 * 'pt_solution_includes' 13729 * 'pt_solutions_intersect' 13730 13731 Points-to analysis also computes the solution for two special set 13732 of pointers, 'ESCAPED' and 'CALLUSED'. Those represent all memory 13733 that has escaped the scope of analysis or that is used by pure or 13734 nested const calls. 13735 13736 3. Type-based alias analysis 13737 13738 Type-based alias analysis is frontend dependent though generic 13739 support is provided by the middle-end in 'alias.c'. TBAA code is 13740 used by both tree optimizers and RTL optimizers. 13741 13742 Every language that wishes to perform language-specific alias 13743 analysis should define a function that computes, given a 'tree' 13744 node, an alias set for the node. Nodes in different alias sets are 13745 not allowed to alias. For an example, see the C front-end function 13746 'c_get_alias_set'. 13747 13748 4. Tree alias-oracle 13749 13750 The tree alias-oracle provides means to disambiguate two memory 13751 references and memory references against statements. The following 13752 queries are available: 13753 13754 * 'refs_may_alias_p' 13755 * 'ref_maybe_used_by_stmt_p' 13756 * 'stmt_may_clobber_ref_p' 13757 13758 In addition to those two kind of statement walkers are available 13759 walking statements related to a reference ref. 13760 'walk_non_aliased_vuses' walks over dominating memory defining 13761 statements and calls back if the statement does not clobber ref 13762 providing the non-aliased VUSE. The walk stops at the first 13763 clobbering statement or if asked to. 'walk_aliased_vdefs' walks 13764 over dominating memory defining statements and calls back on each 13765 statement clobbering ref providing its aliasing VDEF. The walk 13766 stops if asked to. 13767 13768 13769File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA 13770 1377112.5 Memory model 13772================= 13773 13774The memory model used by the middle-end models that of the C/C++ 13775languages. The middle-end has the notion of an effective type of a 13776memory region which is used for type-based alias analysis. 13777 13778 The following is a refinement of ISO C99 6.5/6, clarifying the block 13779copy case to follow common sense and extending the concept of a dynamic 13780effective type to objects with a declared type as required for C++. 13781 13782 The effective type of an object for an access to its stored value is 13783 the declared type of the object or the effective type determined by 13784 a previous store to it. If a value is stored into an object through 13785 an lvalue having a type that is not a character type, then the 13786 type of the lvalue becomes the effective type of the object for that 13787 access and for subsequent accesses that do not modify the stored value. 13788 If a value is copied into an object using memcpy or memmove, 13789 or is copied as an array of character type, then the effective type 13790 of the modified object for that access and for subsequent accesses that 13791 do not modify the value is undetermined. For all other accesses to an 13792 object, the effective type of the object is simply the type of the 13793 lvalue used for the access. 13794 13795 13796File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top 13797 1379813 RTL Representation 13799********************* 13800 13801The last part of the compiler work is done on a low-level intermediate 13802representation called Register Transfer Language. In this language, the 13803instructions to be output are described, pretty much one by one, in an 13804algebraic form that describes what the instruction does. 13805 13806 RTL is inspired by Lisp lists. It has both an internal form, made up 13807of structures that point at other structures, and a textual form that is 13808used in the machine description and in printed debugging dumps. The 13809textual form uses nested parentheses to indicate the pointers in the 13810internal form. 13811 13812* Menu: 13813 13814* RTL Objects:: Expressions vs vectors vs strings vs integers. 13815* RTL Classes:: Categories of RTL expression objects, and their structure. 13816* Accessors:: Macros to access expression operands or vector elts. 13817* Special Accessors:: Macros to access specific annotations on RTL. 13818* Flags:: Other flags in an RTL expression. 13819* Machine Modes:: Describing the size and format of a datum. 13820* Constants:: Expressions with constant values. 13821* Regs and Memory:: Expressions representing register contents or memory. 13822* Arithmetic:: Expressions representing arithmetic on other expressions. 13823* Comparisons:: Expressions representing comparison of expressions. 13824* Bit-Fields:: Expressions representing bit-fields in memory or reg. 13825* Vector Operations:: Expressions involving vector datatypes. 13826* Conversions:: Extending, truncating, floating or fixing. 13827* RTL Declarations:: Declaring volatility, constancy, etc. 13828* Side Effects:: Expressions for storing in registers, etc. 13829* Incdec:: Embedded side-effects for autoincrement addressing. 13830* Assembler:: Representing 'asm' with operands. 13831* Debug Information:: Expressions representing debugging information. 13832* Insns:: Expression types for entire insns. 13833* Calls:: RTL representation of function call insns. 13834* Sharing:: Some expressions are unique; others *must* be copied. 13835* Reading RTL:: Reading textual RTL from a file. 13836 13837 13838File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 13839 1384013.1 RTL Object Types 13841===================== 13842 13843RTL uses five kinds of objects: expressions, integers, wide integers, 13844strings and vectors. Expressions are the most important ones. An RTL 13845expression ("RTX", for short) is a C structure, but it is usually 13846referred to with a pointer; a type that is given the typedef name 'rtx'. 13847 13848 An integer is simply an 'int'; their written form uses decimal digits. 13849A wide integer is an integral object whose type is 'HOST_WIDE_INT'; 13850their written form uses decimal digits. 13851 13852 A string is a sequence of characters. In core it is represented as a 13853'char *' in usual C fashion, and it is written in C syntax as well. 13854However, strings in RTL may never be null. If you write an empty string 13855in a machine description, it is represented in core as a null pointer 13856rather than as a pointer to a null character. In certain contexts, 13857these null pointers instead of strings are valid. Within RTL code, 13858strings are most commonly found inside 'symbol_ref' expressions, but 13859they appear in other contexts in the RTL expressions that make up 13860machine descriptions. 13861 13862 In a machine description, strings are normally written with double 13863quotes, as you would in C. However, strings in machine descriptions may 13864extend over many lines, which is invalid C, and adjacent string 13865constants are not concatenated as they are in C. Any string constant 13866may be surrounded with a single set of parentheses. Sometimes this 13867makes the machine description easier to read. 13868 13869 There is also a special syntax for strings, which can be useful when C 13870code is embedded in a machine description. Wherever a string can 13871appear, it is also valid to write a C-style brace block. The entire 13872brace block, including the outermost pair of braces, is considered to be 13873the string constant. Double quote characters inside the braces are not 13874special. Therefore, if you write string constants in the C code, you 13875need not escape each quote character with a backslash. 13876 13877 A vector contains an arbitrary number of pointers to expressions. The 13878number of elements in the vector is explicitly present in the vector. 13879The written form of a vector consists of square brackets ('[...]') 13880surrounding the elements, in sequence and with whitespace separating 13881them. Vectors of length zero are not created; null pointers are used 13882instead. 13883 13884 Expressions are classified by "expression codes" (also called RTX 13885codes). The expression code is a name defined in 'rtl.def', which is 13886also (in uppercase) a C enumeration constant. The possible expression 13887codes and their meanings are machine-independent. The code of an RTX 13888can be extracted with the macro 'GET_CODE (X)' and altered with 13889'PUT_CODE (X, NEWCODE)'. 13890 13891 The expression code determines how many operands the expression 13892contains, and what kinds of objects they are. In RTL, unlike Lisp, you 13893cannot tell by looking at an operand what kind of object it is. 13894Instead, you must know from its context--from the expression code of the 13895containing expression. For example, in an expression of code 'subreg', 13896the first operand is to be regarded as an expression and the second 13897operand as an integer. In an expression of code 'plus', there are two 13898operands, both of which are to be regarded as expressions. In a 13899'symbol_ref' expression, there is one operand, which is to be regarded 13900as a string. 13901 13902 Expressions are written as parentheses containing the name of the 13903expression type, its flags and machine mode if any, and then the 13904operands of the expression (separated by spaces). 13905 13906 Expression code names in the 'md' file are written in lowercase, but 13907when they appear in C code they are written in uppercase. In this 13908manual, they are shown as follows: 'const_int'. 13909 13910 In a few contexts a null pointer is valid where an expression is 13911normally wanted. The written form of this is '(nil)'. 13912 13913 13914File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 13915 1391613.2 RTL Classes and Formats 13917============================ 13918 13919The various expression codes are divided into several "classes", which 13920are represented by single characters. You can determine the class of an 13921RTX code with the macro 'GET_RTX_CLASS (CODE)'. Currently, 'rtl.def' 13922defines these classes: 13923 13924'RTX_OBJ' 13925 An RTX code that represents an actual object, such as a register 13926 ('REG') or a memory location ('MEM', 'SYMBOL_REF'). 'LO_SUM') is 13927 also included; instead, 'SUBREG' and 'STRICT_LOW_PART' are not in 13928 this class, but in class 'x'. 13929 13930'RTX_CONST_OBJ' 13931 An RTX code that represents a constant object. 'HIGH' is also 13932 included in this class. 13933 13934'RTX_COMPARE' 13935 An RTX code for a non-symmetric comparison, such as 'GEU' or 'LT'. 13936 13937'RTX_COMM_COMPARE' 13938 An RTX code for a symmetric (commutative) comparison, such as 'EQ' 13939 or 'ORDERED'. 13940 13941'RTX_UNARY' 13942 An RTX code for a unary arithmetic operation, such as 'NEG', 'NOT', 13943 or 'ABS'. This category also includes value extension (sign or 13944 zero) and conversions between integer and floating point. 13945 13946'RTX_COMM_ARITH' 13947 An RTX code for a commutative binary operation, such as 'PLUS' or 13948 'AND'. 'NE' and 'EQ' are comparisons, so they have class '<'. 13949 13950'RTX_BIN_ARITH' 13951 An RTX code for a non-commutative binary operation, such as 13952 'MINUS', 'DIV', or 'ASHIFTRT'. 13953 13954'RTX_BITFIELD_OPS' 13955 An RTX code for a bit-field operation. Currently only 13956 'ZERO_EXTRACT' and 'SIGN_EXTRACT'. These have three inputs and are 13957 lvalues (so they can be used for insertion as well). *Note 13958 Bit-Fields::. 13959 13960'RTX_TERNARY' 13961 An RTX code for other three input operations. Currently only 13962 'IF_THEN_ELSE', 'VEC_MERGE', 'SIGN_EXTRACT', 'ZERO_EXTRACT', and 13963 'FMA'. 13964 13965'RTX_INSN' 13966 An RTX code for an entire instruction: 'INSN', 'JUMP_INSN', and 13967 'CALL_INSN'. *Note Insns::. 13968 13969'RTX_MATCH' 13970 An RTX code for something that matches in insns, such as 13971 'MATCH_DUP'. These only occur in machine descriptions. 13972 13973'RTX_AUTOINC' 13974 An RTX code for an auto-increment addressing mode, such as 13975 'POST_INC'. 'XEXP (X, 0)' gives the auto-modified register. 13976 13977'RTX_EXTRA' 13978 All other RTX codes. This category includes the remaining codes 13979 used only in machine descriptions ('DEFINE_*', etc.). It also 13980 includes all the codes describing side effects ('SET', 'USE', 13981 'CLOBBER', etc.) and the non-insns that may appear on an insn 13982 chain, such as 'NOTE', 'BARRIER', and 'CODE_LABEL'. 'SUBREG' is 13983 also part of this class. 13984 13985 For each expression code, 'rtl.def' specifies the number of contained 13986objects and their kinds using a sequence of characters called the 13987"format" of the expression code. For example, the format of 'subreg' is 13988'ei'. 13989 13990 These are the most commonly used format characters: 13991 13992'e' 13993 An expression (actually a pointer to an expression). 13994 13995'i' 13996 An integer. 13997 13998'w' 13999 A wide integer. 14000 14001's' 14002 A string. 14003 14004'E' 14005 A vector of expressions. 14006 14007 A few other format characters are used occasionally: 14008 14009'u' 14010 'u' is equivalent to 'e' except that it is printed differently in 14011 debugging dumps. It is used for pointers to insns. 14012 14013'n' 14014 'n' is equivalent to 'i' except that it is printed differently in 14015 debugging dumps. It is used for the line number or code number of 14016 a 'note' insn. 14017 14018'S' 14019 'S' indicates a string which is optional. In the RTL objects in 14020 core, 'S' is equivalent to 's', but when the object is read, from 14021 an 'md' file, the string value of this operand may be omitted. An 14022 omitted string is taken to be the null string. 14023 14024'V' 14025 'V' indicates a vector which is optional. In the RTL objects in 14026 core, 'V' is equivalent to 'E', but when the object is read from an 14027 'md' file, the vector value of this operand may be omitted. An 14028 omitted vector is effectively the same as a vector of no elements. 14029 14030'B' 14031 'B' indicates a pointer to basic block structure. 14032 14033'0' 14034 '0' means a slot whose contents do not fit any normal category. 14035 '0' slots are not printed at all in dumps, and are often used in 14036 special ways by small parts of the compiler. 14037 14038 There are macros to get the number of operands and the format of an 14039expression code: 14040 14041'GET_RTX_LENGTH (CODE)' 14042 Number of operands of an RTX of code CODE. 14043 14044'GET_RTX_FORMAT (CODE)' 14045 The format of an RTX of code CODE, as a C string. 14046 14047 Some classes of RTX codes always have the same format. For example, it 14048is safe to assume that all comparison operations have format 'ee'. 14049 14050'1' 14051 All codes of this class have format 'e'. 14052 14053'<' 14054'c' 14055'2' 14056 All codes of these classes have format 'ee'. 14057 14058'b' 14059'3' 14060 All codes of these classes have format 'eee'. 14061 14062'i' 14063 All codes of this class have formats that begin with 'iuueiee'. 14064 *Note Insns::. Note that not all RTL objects linked onto an insn 14065 chain are of class 'i'. 14066 14067'o' 14068'm' 14069'x' 14070 You can make no assumptions about the format of these codes. 14071 14072 14073File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 14074 1407513.3 Access to Operands 14076======================= 14077 14078Operands of expressions are accessed using the macros 'XEXP', 'XINT', 14079'XWINT' and 'XSTR'. Each of these macros takes two arguments: an 14080expression-pointer (RTX) and an operand number (counting from zero). 14081Thus, 14082 14083 XEXP (X, 2) 14084 14085accesses operand 2 of expression X, as an expression. 14086 14087 XINT (X, 2) 14088 14089accesses the same operand as an integer. 'XSTR', used in the same 14090fashion, would access it as a string. 14091 14092 Any operand can be accessed as an integer, as an expression or as a 14093string. You must choose the correct method of access for the kind of 14094value actually stored in the operand. You would do this based on the 14095expression code of the containing expression. That is also how you 14096would know how many operands there are. 14097 14098 For example, if X is a 'subreg' expression, you know that it has two 14099operands which can be correctly accessed as 'XEXP (X, 0)' and 'XINT (X, 141001)'. If you did 'XINT (X, 0)', you would get the address of the 14101expression operand but cast as an integer; that might occasionally be 14102useful, but it would be cleaner to write '(int) XEXP (X, 0)'. 'XEXP (X, 141031)' would also compile without error, and would return the second, 14104integer operand cast as an expression pointer, which would probably 14105result in a crash when accessed. Nothing stops you from writing 'XEXP 14106(X, 28)' either, but this will access memory past the end of the 14107expression with unpredictable results. 14108 14109 Access to operands which are vectors is more complicated. You can use 14110the macro 'XVEC' to get the vector-pointer itself, or the macros 14111'XVECEXP' and 'XVECLEN' to access the elements and length of a vector. 14112 14113'XVEC (EXP, IDX)' 14114 Access the vector-pointer which is operand number IDX in EXP. 14115 14116'XVECLEN (EXP, IDX)' 14117 Access the length (number of elements) in the vector which is in 14118 operand number IDX in EXP. This value is an 'int'. 14119 14120'XVECEXP (EXP, IDX, ELTNUM)' 14121 Access element number ELTNUM in the vector which is in operand 14122 number IDX in EXP. This value is an RTX. 14123 14124 It is up to you to make sure that ELTNUM is not negative and is 14125 less than 'XVECLEN (EXP, IDX)'. 14126 14127 All the macros defined in this section expand into lvalues and 14128therefore can be used to assign the operands, lengths and vector 14129elements as well as to access them. 14130 14131 14132File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 14133 1413413.4 Access to Special Operands 14135=============================== 14136 14137Some RTL nodes have special annotations associated with them. 14138 14139'MEM' 14140 'MEM_ALIAS_SET (X)' 14141 If 0, X is not in any alias set, and may alias anything. 14142 Otherwise, X can only alias 'MEM's in a conflicting alias set. 14143 This value is set in a language-dependent manner in the 14144 front-end, and should not be altered in the back-end. In some 14145 front-ends, these numbers may correspond in some way to types, 14146 or other language-level entities, but they need not, and the 14147 back-end makes no such assumptions. These set numbers are 14148 tested with 'alias_sets_conflict_p'. 14149 14150 'MEM_EXPR (X)' 14151 If this register is known to hold the value of some user-level 14152 declaration, this is that tree node. It may also be a 14153 'COMPONENT_REF', in which case this is some field reference, 14154 and 'TREE_OPERAND (X, 0)' contains the declaration, or another 14155 'COMPONENT_REF', or null if there is no compile-time object 14156 associated with the reference. 14157 14158 'MEM_OFFSET_KNOWN_P (X)' 14159 True if the offset of the memory reference from 'MEM_EXPR' is 14160 known. 'MEM_OFFSET (X)' provides the offset if so. 14161 14162 'MEM_OFFSET (X)' 14163 The offset from the start of 'MEM_EXPR'. The value is only 14164 valid if 'MEM_OFFSET_KNOWN_P (X)' is true. 14165 14166 'MEM_SIZE_KNOWN_P (X)' 14167 True if the size of the memory reference is known. 'MEM_SIZE 14168 (X)' provides its size if so. 14169 14170 'MEM_SIZE (X)' 14171 The size in bytes of the memory reference. This is mostly 14172 relevant for 'BLKmode' references as otherwise the size is 14173 implied by the mode. The value is only valid if 14174 'MEM_SIZE_KNOWN_P (X)' is true. 14175 14176 'MEM_ALIGN (X)' 14177 The known alignment in bits of the memory reference. 14178 14179 'MEM_ADDR_SPACE (X)' 14180 The address space of the memory reference. This will commonly 14181 be zero for the generic address space. 14182 14183'REG' 14184 'ORIGINAL_REGNO (X)' 14185 This field holds the number the register "originally" had; for 14186 a pseudo register turned into a hard reg this will hold the 14187 old pseudo register number. 14188 14189 'REG_EXPR (X)' 14190 If this register is known to hold the value of some user-level 14191 declaration, this is that tree node. 14192 14193 'REG_OFFSET (X)' 14194 If this register is known to hold the value of some user-level 14195 declaration, this is the offset into that logical storage. 14196 14197'SYMBOL_REF' 14198 'SYMBOL_REF_DECL (X)' 14199 If the 'symbol_ref' X was created for a 'VAR_DECL' or a 14200 'FUNCTION_DECL', that tree is recorded here. If this value is 14201 null, then X was created by back end code generation routines, 14202 and there is no associated front end symbol table entry. 14203 14204 'SYMBOL_REF_DECL' may also point to a tree of class ''c'', 14205 that is, some sort of constant. In this case, the 14206 'symbol_ref' is an entry in the per-file constant pool; again, 14207 there is no associated front end symbol table entry. 14208 14209 'SYMBOL_REF_CONSTANT (X)' 14210 If 'CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 14211 pool entry for X. It is null otherwise. 14212 14213 'SYMBOL_REF_DATA (X)' 14214 A field of opaque type used to store 'SYMBOL_REF_DECL' or 14215 'SYMBOL_REF_CONSTANT'. 14216 14217 'SYMBOL_REF_FLAGS (X)' 14218 In a 'symbol_ref', this is used to communicate various 14219 predicates about the symbol. Some of these are common enough 14220 to be computed by common code, some are specific to the 14221 target. The common bits are: 14222 14223 'SYMBOL_FLAG_FUNCTION' 14224 Set if the symbol refers to a function. 14225 14226 'SYMBOL_FLAG_LOCAL' 14227 Set if the symbol is local to this "module". See 14228 'TARGET_BINDS_LOCAL_P'. 14229 14230 'SYMBOL_FLAG_EXTERNAL' 14231 Set if this symbol is not defined in this translation 14232 unit. Note that this is not the inverse of 14233 'SYMBOL_FLAG_LOCAL'. 14234 14235 'SYMBOL_FLAG_SMALL' 14236 Set if the symbol is located in the small data section. 14237 See 'TARGET_IN_SMALL_DATA_P'. 14238 14239 'SYMBOL_REF_TLS_MODEL (X)' 14240 This is a multi-bit field accessor that returns the 14241 'tls_model' to be used for a thread-local storage symbol. 14242 It returns zero for non-thread-local symbols. 14243 14244 'SYMBOL_FLAG_HAS_BLOCK_INFO' 14245 Set if the symbol has 'SYMBOL_REF_BLOCK' and 14246 'SYMBOL_REF_BLOCK_OFFSET' fields. 14247 14248 'SYMBOL_FLAG_ANCHOR' 14249 Set if the symbol is used as a section anchor. "Section 14250 anchors" are symbols that have a known position within an 14251 'object_block' and that can be used to access nearby 14252 members of that block. They are used to implement 14253 '-fsection-anchors'. 14254 14255 If this flag is set, then 'SYMBOL_FLAG_HAS_BLOCK_INFO' 14256 will be too. 14257 14258 Bits beginning with 'SYMBOL_FLAG_MACH_DEP' are available for 14259 the target's use. 14260 14261'SYMBOL_REF_BLOCK (X)' 14262 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the 'object_block' 14263 structure to which the symbol belongs, or 'NULL' if it has not been 14264 assigned a block. 14265 14266'SYMBOL_REF_BLOCK_OFFSET (X)' 14267 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 14268 the first object in 'SYMBOL_REF_BLOCK (X)'. The value is negative 14269 if X has not yet been assigned to a block, or it has not been given 14270 an offset within that block. 14271 14272 14273File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 14274 1427513.5 Flags in an RTL Expression 14276=============================== 14277 14278RTL expressions contain several flags (one-bit bit-fields) that are used 14279in certain types of expression. Most often they are accessed with the 14280following macros, which expand into lvalues. 14281 14282'CONSTANT_POOL_ADDRESS_P (X)' 14283 Nonzero in a 'symbol_ref' if it refers to part of the current 14284 function's constant pool. For most targets these addresses are in 14285 a '.rodata' section entirely separate from the function, but for 14286 some targets the addresses are close to the beginning of the 14287 function. In either case GCC assumes these addresses can be 14288 addressed directly, perhaps with the help of base registers. 14289 Stored in the 'unchanging' field and printed as '/u'. 14290 14291'RTL_CONST_CALL_P (X)' 14292 In a 'call_insn' indicates that the insn represents a call to a 14293 const function. Stored in the 'unchanging' field and printed as 14294 '/u'. 14295 14296'RTL_PURE_CALL_P (X)' 14297 In a 'call_insn' indicates that the insn represents a call to a 14298 pure function. Stored in the 'return_val' field and printed as 14299 '/i'. 14300 14301'RTL_CONST_OR_PURE_CALL_P (X)' 14302 In a 'call_insn', true if 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' 14303 is true. 14304 14305'RTL_LOOPING_CONST_OR_PURE_CALL_P (X)' 14306 In a 'call_insn' indicates that the insn represents a possibly 14307 infinite looping call to a const or pure function. Stored in the 14308 'call' field and printed as '/c'. Only true if one of 14309 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' is true. 14310 14311'INSN_ANNULLED_BRANCH_P (X)' 14312 In a 'jump_insn', 'call_insn', or 'insn' indicates that the branch 14313 is an annulling one. See the discussion under 'sequence' below. 14314 Stored in the 'unchanging' field and printed as '/u'. 14315 14316'INSN_DELETED_P (X)' 14317 In an 'insn', 'call_insn', 'jump_insn', 'code_label', 14318 'jump_table_data', 'barrier', or 'note', nonzero if the insn has 14319 been deleted. Stored in the 'volatil' field and printed as '/v'. 14320 14321'INSN_FROM_TARGET_P (X)' 14322 In an 'insn' or 'jump_insn' or 'call_insn' in a delay slot of a 14323 branch, indicates that the insn is from the target of the branch. 14324 If the branch insn has 'INSN_ANNULLED_BRANCH_P' set, this insn will 14325 only be executed if the branch is taken. For annulled branches 14326 with 'INSN_FROM_TARGET_P' clear, the insn will be executed only if 14327 the branch is not taken. When 'INSN_ANNULLED_BRANCH_P' is not set, 14328 this insn will always be executed. Stored in the 'in_struct' field 14329 and printed as '/s'. 14330 14331'LABEL_PRESERVE_P (X)' 14332 In a 'code_label' or 'note', indicates that the label is referenced 14333 by code or data not visible to the RTL of a given function. Labels 14334 referenced by a non-local goto will have this bit set. Stored in 14335 the 'in_struct' field and printed as '/s'. 14336 14337'LABEL_REF_NONLOCAL_P (X)' 14338 In 'label_ref' and 'reg_label' expressions, nonzero if this is a 14339 reference to a non-local label. Stored in the 'volatil' field and 14340 printed as '/v'. 14341 14342'MEM_KEEP_ALIAS_SET_P (X)' 14343 In 'mem' expressions, 1 if we should keep the alias set for this 14344 mem unchanged when we access a component. Set to 1, for example, 14345 when we are already in a non-addressable component of an aggregate. 14346 Stored in the 'jump' field and printed as '/j'. 14347 14348'MEM_VOLATILE_P (X)' 14349 In 'mem', 'asm_operands', and 'asm_input' expressions, nonzero for 14350 volatile memory references. Stored in the 'volatil' field and 14351 printed as '/v'. 14352 14353'MEM_NOTRAP_P (X)' 14354 In 'mem', nonzero for memory references that will not trap. Stored 14355 in the 'call' field and printed as '/c'. 14356 14357'MEM_POINTER (X)' 14358 Nonzero in a 'mem' if the memory reference holds a pointer. Stored 14359 in the 'frame_related' field and printed as '/f'. 14360 14361'REG_FUNCTION_VALUE_P (X)' 14362 Nonzero in a 'reg' if it is the place in which this function's 14363 value is going to be returned. (This happens only in a hard 14364 register.) Stored in the 'return_val' field and printed as '/i'. 14365 14366'REG_POINTER (X)' 14367 Nonzero in a 'reg' if the register holds a pointer. Stored in the 14368 'frame_related' field and printed as '/f'. 14369 14370'REG_USERVAR_P (X)' 14371 In a 'reg', nonzero if it corresponds to a variable present in the 14372 user's source code. Zero for temporaries generated internally by 14373 the compiler. Stored in the 'volatil' field and printed as '/v'. 14374 14375 The same hard register may be used also for collecting the values 14376 of functions called by this one, but 'REG_FUNCTION_VALUE_P' is zero 14377 in this kind of use. 14378 14379'RTX_FRAME_RELATED_P (X)' 14380 Nonzero in an 'insn', 'call_insn', 'jump_insn', 'barrier', or 'set' 14381 which is part of a function prologue and sets the stack pointer, 14382 sets the frame pointer, or saves a register. This flag should also 14383 be set on an instruction that sets up a temporary register to use 14384 in place of the frame pointer. Stored in the 'frame_related' field 14385 and printed as '/f'. 14386 14387 In particular, on RISC targets where there are limits on the sizes 14388 of immediate constants, it is sometimes impossible to reach the 14389 register save area directly from the stack pointer. In that case, 14390 a temporary register is used that is near enough to the register 14391 save area, and the Canonical Frame Address, i.e., DWARF2's logical 14392 frame pointer, register must (temporarily) be changed to be this 14393 temporary register. So, the instruction that sets this temporary 14394 register must be marked as 'RTX_FRAME_RELATED_P'. 14395 14396 If the marked instruction is overly complex (defined in terms of 14397 what 'dwarf2out_frame_debug_expr' can handle), you will also have 14398 to create a 'REG_FRAME_RELATED_EXPR' note and attach it to the 14399 instruction. This note should contain a simple expression of the 14400 computation performed by this instruction, i.e., one that 14401 'dwarf2out_frame_debug_expr' can handle. 14402 14403 This flag is required for exception handling support on targets 14404 with RTL prologues. 14405 14406'MEM_READONLY_P (X)' 14407 Nonzero in a 'mem', if the memory is statically allocated and 14408 read-only. 14409 14410 Read-only in this context means never modified during the lifetime 14411 of the program, not necessarily in ROM or in write-disabled pages. 14412 A common example of the later is a shared library's global offset 14413 table. This table is initialized by the runtime loader, so the 14414 memory is technically writable, but after control is transferred 14415 from the runtime loader to the application, this memory will never 14416 be subsequently modified. 14417 14418 Stored in the 'unchanging' field and printed as '/u'. 14419 14420'SCHED_GROUP_P (X)' 14421 During instruction scheduling, in an 'insn', 'call_insn', 14422 'jump_insn' or 'jump_table_data', indicates that the previous insn 14423 must be scheduled together with this insn. This is used to ensure 14424 that certain groups of instructions will not be split up by the 14425 instruction scheduling pass, for example, 'use' insns before a 14426 'call_insn' may not be separated from the 'call_insn'. Stored in 14427 the 'in_struct' field and printed as '/s'. 14428 14429'SET_IS_RETURN_P (X)' 14430 For a 'set', nonzero if it is for a return. Stored in the 'jump' 14431 field and printed as '/j'. 14432 14433'SIBLING_CALL_P (X)' 14434 For a 'call_insn', nonzero if the insn is a sibling call. Stored 14435 in the 'jump' field and printed as '/j'. 14436 14437'STRING_POOL_ADDRESS_P (X)' 14438 For a 'symbol_ref' expression, nonzero if it addresses this 14439 function's string constant pool. Stored in the 'frame_related' 14440 field and printed as '/f'. 14441 14442'SUBREG_PROMOTED_UNSIGNED_P (X)' 14443 Returns a value greater then zero for a 'subreg' that has 14444 'SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 14445 kept zero-extended, zero if it is kept sign-extended, and less then 14446 zero if it is extended some other way via the 'ptr_extend' 14447 instruction. Stored in the 'unchanging' field and 'volatil' field, 14448 printed as '/u' and '/v'. This macro may only be used to get the 14449 value it may not be used to change the value. Use 14450 'SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 14451 14452'SUBREG_PROMOTED_UNSIGNED_SET (X)' 14453 Set the 'unchanging' and 'volatil' fields in a 'subreg' to reflect 14454 zero, sign, or other extension. If 'volatil' is zero, then 14455 'unchanging' as nonzero means zero extension and as zero means sign 14456 extension. If 'volatil' is nonzero then some other type of 14457 extension was done via the 'ptr_extend' instruction. 14458 14459'SUBREG_PROMOTED_VAR_P (X)' 14460 Nonzero in a 'subreg' if it was made when accessing an object that 14461 was promoted to a wider mode in accord with the 'PROMOTED_MODE' 14462 machine description macro (*note Storage Layout::). In this case, 14463 the mode of the 'subreg' is the declared mode of the object and the 14464 mode of 'SUBREG_REG' is the mode of the register that holds the 14465 object. Promoted variables are always either sign- or 14466 zero-extended to the wider mode on every assignment. Stored in the 14467 'in_struct' field and printed as '/s'. 14468 14469'SYMBOL_REF_USED (X)' 14470 In a 'symbol_ref', indicates that X has been used. This is 14471 normally only used to ensure that X is only declared external once. 14472 Stored in the 'used' field. 14473 14474'SYMBOL_REF_WEAK (X)' 14475 In a 'symbol_ref', indicates that X has been declared weak. Stored 14476 in the 'return_val' field and printed as '/i'. 14477 14478'SYMBOL_REF_FLAG (X)' 14479 In a 'symbol_ref', this is used as a flag for machine-specific 14480 purposes. Stored in the 'volatil' field and printed as '/v'. 14481 14482 Most uses of 'SYMBOL_REF_FLAG' are historic and may be subsumed by 14483 'SYMBOL_REF_FLAGS'. Certainly use of 'SYMBOL_REF_FLAGS' is 14484 mandatory if the target requires more than one bit of storage. 14485 14486'PREFETCH_SCHEDULE_BARRIER_P (X)' 14487 In a 'prefetch', indicates that the prefetch is a scheduling 14488 barrier. No other INSNs will be moved over it. Stored in the 14489 'volatil' field and printed as '/v'. 14490 14491 These are the fields to which the above macros refer: 14492 14493'call' 14494 In a 'mem', 1 means that the memory reference will not trap. 14495 14496 In a 'call', 1 means that this pure or const call may possibly 14497 infinite loop. 14498 14499 In an RTL dump, this flag is represented as '/c'. 14500 14501'frame_related' 14502 In an 'insn' or 'set' expression, 1 means that it is part of a 14503 function prologue and sets the stack pointer, sets the frame 14504 pointer, saves a register, or sets up a temporary register to use 14505 in place of the frame pointer. 14506 14507 In 'reg' expressions, 1 means that the register holds a pointer. 14508 14509 In 'mem' expressions, 1 means that the memory reference holds a 14510 pointer. 14511 14512 In 'symbol_ref' expressions, 1 means that the reference addresses 14513 this function's string constant pool. 14514 14515 In an RTL dump, this flag is represented as '/f'. 14516 14517'in_struct' 14518 In 'reg' expressions, it is 1 if the register has its entire life 14519 contained within the test expression of some loop. 14520 14521 In 'subreg' expressions, 1 means that the 'subreg' is accessing an 14522 object that has had its mode promoted from a wider mode. 14523 14524 In 'label_ref' expressions, 1 means that the referenced label is 14525 outside the innermost loop containing the insn in which the 14526 'label_ref' was found. 14527 14528 In 'code_label' expressions, it is 1 if the label may never be 14529 deleted. This is used for labels which are the target of non-local 14530 gotos. Such a label that would have been deleted is replaced with 14531 a 'note' of type 'NOTE_INSN_DELETED_LABEL'. 14532 14533 In an 'insn' during dead-code elimination, 1 means that the insn is 14534 dead code. 14535 14536 In an 'insn' or 'jump_insn' during reorg for an insn in the delay 14537 slot of a branch, 1 means that this insn is from the target of the 14538 branch. 14539 14540 In an 'insn' during instruction scheduling, 1 means that this insn 14541 must be scheduled as part of a group together with the previous 14542 insn. 14543 14544 In an RTL dump, this flag is represented as '/s'. 14545 14546'return_val' 14547 In 'reg' expressions, 1 means the register contains the value to be 14548 returned by the current function. On machines that pass parameters 14549 in registers, the same register number may be used for parameters 14550 as well, but this flag is not set on such uses. 14551 14552 In 'symbol_ref' expressions, 1 means the referenced symbol is weak. 14553 14554 In 'call' expressions, 1 means the call is pure. 14555 14556 In an RTL dump, this flag is represented as '/i'. 14557 14558'jump' 14559 In a 'mem' expression, 1 means we should keep the alias set for 14560 this mem unchanged when we access a component. 14561 14562 In a 'set', 1 means it is for a return. 14563 14564 In a 'call_insn', 1 means it is a sibling call. 14565 14566 In an RTL dump, this flag is represented as '/j'. 14567 14568'unchanging' 14569 In 'reg' and 'mem' expressions, 1 means that the value of the 14570 expression never changes. 14571 14572 In 'subreg' expressions, it is 1 if the 'subreg' references an 14573 unsigned object whose mode has been promoted to a wider mode. 14574 14575 In an 'insn' or 'jump_insn' in the delay slot of a branch 14576 instruction, 1 means an annulling branch should be used. 14577 14578 In a 'symbol_ref' expression, 1 means that this symbol addresses 14579 something in the per-function constant pool. 14580 14581 In a 'call_insn' 1 means that this instruction is a call to a const 14582 function. 14583 14584 In an RTL dump, this flag is represented as '/u'. 14585 14586'used' 14587 This flag is used directly (without an access macro) at the end of 14588 RTL generation for a function, to count the number of times an 14589 expression appears in insns. Expressions that appear more than 14590 once are copied, according to the rules for shared structure (*note 14591 Sharing::). 14592 14593 For a 'reg', it is used directly (without an access macro) by the 14594 leaf register renumbering code to ensure that each register is only 14595 renumbered once. 14596 14597 In a 'symbol_ref', it indicates that an external declaration for 14598 the symbol has already been written. 14599 14600'volatil' 14601 In a 'mem', 'asm_operands', or 'asm_input' expression, it is 1 if 14602 the memory reference is volatile. Volatile memory references may 14603 not be deleted, reordered or combined. 14604 14605 In a 'symbol_ref' expression, it is used for machine-specific 14606 purposes. 14607 14608 In a 'reg' expression, it is 1 if the value is a user-level 14609 variable. 0 indicates an internal compiler temporary. 14610 14611 In an 'insn', 1 means the insn has been deleted. 14612 14613 In 'label_ref' and 'reg_label' expressions, 1 means a reference to 14614 a non-local label. 14615 14616 In 'prefetch' expressions, 1 means that the containing insn is a 14617 scheduling barrier. 14618 14619 In an RTL dump, this flag is represented as '/v'. 14620 14621 14622File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 14623 1462413.6 Machine Modes 14625================== 14626 14627A machine mode describes a size of data object and the representation 14628used for it. In the C code, machine modes are represented by an 14629enumeration type, 'machine_mode', defined in 'machmode.def'. Each RTL 14630expression has room for a machine mode and so do certain kinds of tree 14631expressions (declarations and types, to be precise). 14632 14633 In debugging dumps and machine descriptions, the machine mode of an RTL 14634expression is written after the expression code with a colon to separate 14635them. The letters 'mode' which appear at the end of each machine mode 14636name are omitted. For example, '(reg:SI 38)' is a 'reg' expression with 14637machine mode 'SImode'. If the mode is 'VOIDmode', it is not written at 14638all. 14639 14640 Here is a table of machine modes. The term "byte" below refers to an 14641object of 'BITS_PER_UNIT' bits (*note Storage Layout::). 14642 14643'BImode' 14644 "Bit" mode represents a single bit, for predicate registers. 14645 14646'QImode' 14647 "Quarter-Integer" mode represents a single byte treated as an 14648 integer. 14649 14650'HImode' 14651 "Half-Integer" mode represents a two-byte integer. 14652 14653'PSImode' 14654 "Partial Single Integer" mode represents an integer which occupies 14655 four bytes but which doesn't really use all four. On some 14656 machines, this is the right mode to use for pointers. 14657 14658'SImode' 14659 "Single Integer" mode represents a four-byte integer. 14660 14661'PDImode' 14662 "Partial Double Integer" mode represents an integer which occupies 14663 eight bytes but which doesn't really use all eight. On some 14664 machines, this is the right mode to use for certain pointers. 14665 14666'DImode' 14667 "Double Integer" mode represents an eight-byte integer. 14668 14669'TImode' 14670 "Tetra Integer" (?) mode represents a sixteen-byte integer. 14671 14672'OImode' 14673 "Octa Integer" (?) mode represents a thirty-two-byte integer. 14674 14675'XImode' 14676 "Hexadeca Integer" (?) mode represents a sixty-four-byte integer. 14677 14678'QFmode' 14679 "Quarter-Floating" mode represents a quarter-precision (single 14680 byte) floating point number. 14681 14682'HFmode' 14683 "Half-Floating" mode represents a half-precision (two byte) 14684 floating point number. 14685 14686'TQFmode' 14687 "Three-Quarter-Floating" (?) mode represents a 14688 three-quarter-precision (three byte) floating point number. 14689 14690'SFmode' 14691 "Single Floating" mode represents a four byte floating point 14692 number. In the common case, of a processor with IEEE arithmetic 14693 and 8-bit bytes, this is a single-precision IEEE floating point 14694 number; it can also be used for double-precision (on processors 14695 with 16-bit bytes) and single-precision VAX and IBM types. 14696 14697'DFmode' 14698 "Double Floating" mode represents an eight byte floating point 14699 number. In the common case, of a processor with IEEE arithmetic 14700 and 8-bit bytes, this is a double-precision IEEE floating point 14701 number. 14702 14703'XFmode' 14704 "Extended Floating" mode represents an IEEE extended floating point 14705 number. This mode only has 80 meaningful bits (ten bytes). Some 14706 processors require such numbers to be padded to twelve bytes, 14707 others to sixteen; this mode is used for either. 14708 14709'SDmode' 14710 "Single Decimal Floating" mode represents a four byte decimal 14711 floating point number (as distinct from conventional binary 14712 floating point). 14713 14714'DDmode' 14715 "Double Decimal Floating" mode represents an eight byte decimal 14716 floating point number. 14717 14718'TDmode' 14719 "Tetra Decimal Floating" mode represents a sixteen byte decimal 14720 floating point number all 128 of whose bits are meaningful. 14721 14722'TFmode' 14723 "Tetra Floating" mode represents a sixteen byte floating point 14724 number all 128 of whose bits are meaningful. One common use is the 14725 IEEE quad-precision format. 14726 14727'QQmode' 14728 "Quarter-Fractional" mode represents a single byte treated as a 14729 signed fractional number. The default format is "s.7". 14730 14731'HQmode' 14732 "Half-Fractional" mode represents a two-byte signed fractional 14733 number. The default format is "s.15". 14734 14735'SQmode' 14736 "Single Fractional" mode represents a four-byte signed fractional 14737 number. The default format is "s.31". 14738 14739'DQmode' 14740 "Double Fractional" mode represents an eight-byte signed fractional 14741 number. The default format is "s.63". 14742 14743'TQmode' 14744 "Tetra Fractional" mode represents a sixteen-byte signed fractional 14745 number. The default format is "s.127". 14746 14747'UQQmode' 14748 "Unsigned Quarter-Fractional" mode represents a single byte treated 14749 as an unsigned fractional number. The default format is ".8". 14750 14751'UHQmode' 14752 "Unsigned Half-Fractional" mode represents a two-byte unsigned 14753 fractional number. The default format is ".16". 14754 14755'USQmode' 14756 "Unsigned Single Fractional" mode represents a four-byte unsigned 14757 fractional number. The default format is ".32". 14758 14759'UDQmode' 14760 "Unsigned Double Fractional" mode represents an eight-byte unsigned 14761 fractional number. The default format is ".64". 14762 14763'UTQmode' 14764 "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned 14765 fractional number. The default format is ".128". 14766 14767'HAmode' 14768 "Half-Accumulator" mode represents a two-byte signed accumulator. 14769 The default format is "s8.7". 14770 14771'SAmode' 14772 "Single Accumulator" mode represents a four-byte signed 14773 accumulator. The default format is "s16.15". 14774 14775'DAmode' 14776 "Double Accumulator" mode represents an eight-byte signed 14777 accumulator. The default format is "s32.31". 14778 14779'TAmode' 14780 "Tetra Accumulator" mode represents a sixteen-byte signed 14781 accumulator. The default format is "s64.63". 14782 14783'UHAmode' 14784 "Unsigned Half-Accumulator" mode represents a two-byte unsigned 14785 accumulator. The default format is "8.8". 14786 14787'USAmode' 14788 "Unsigned Single Accumulator" mode represents a four-byte unsigned 14789 accumulator. The default format is "16.16". 14790 14791'UDAmode' 14792 "Unsigned Double Accumulator" mode represents an eight-byte 14793 unsigned accumulator. The default format is "32.32". 14794 14795'UTAmode' 14796 "Unsigned Tetra Accumulator" mode represents a sixteen-byte 14797 unsigned accumulator. The default format is "64.64". 14798 14799'CCmode' 14800 "Condition Code" mode represents the value of a condition code, 14801 which is a machine-specific set of bits used to represent the 14802 result of a comparison operation. Other machine-specific modes may 14803 also be used for the condition code. These modes are not used on 14804 machines that use 'cc0' (*note Condition Code::). 14805 14806'BLKmode' 14807 "Block" mode represents values that are aggregates to which none of 14808 the other modes apply. In RTL, only memory references can have 14809 this mode, and only if they appear in string-move or vector 14810 instructions. On machines which have no such instructions, 14811 'BLKmode' will not appear in RTL. 14812 14813'VOIDmode' 14814 Void mode means the absence of a mode or an unspecified mode. For 14815 example, RTL expressions of code 'const_int' have mode 'VOIDmode' 14816 because they can be taken to have whatever mode the context 14817 requires. In debugging dumps of RTL, 'VOIDmode' is expressed by 14818 the absence of any mode. 14819 14820'QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 14821 These modes stand for a complex number represented as a pair of 14822 floating point values. The floating point values are in 'QFmode', 14823 'HFmode', 'SFmode', 'DFmode', 'XFmode', and 'TFmode', respectively. 14824 14825'CQImode, CHImode, CSImode, CDImode, CTImode, COImode' 14826 These modes stand for a complex number represented as a pair of 14827 integer values. The integer values are in 'QImode', 'HImode', 14828 'SImode', 'DImode', 'TImode', and 'OImode', respectively. 14829 14830'BND32mode BND64mode' 14831 These modes stand for bounds for pointer of 32 and 64 bit size 14832 respectively. Mode size is double pointer mode size. 14833 14834 The machine description defines 'Pmode' as a C macro which expands into 14835the machine mode used for addresses. Normally this is the mode whose 14836size is 'BITS_PER_WORD', 'SImode' on 32-bit machines. 14837 14838 The only modes which a machine description must support are 'QImode', 14839and the modes corresponding to 'BITS_PER_WORD', 'FLOAT_TYPE_SIZE' and 14840'DOUBLE_TYPE_SIZE'. The compiler will attempt to use 'DImode' for 148418-byte structures and unions, but this can be prevented by overriding 14842the definition of 'MAX_FIXED_MODE_SIZE'. Alternatively, you can have 14843the compiler use 'TImode' for 16-byte structures and unions. Likewise, 14844you can arrange for the C type 'short int' to avoid using 'HImode'. 14845 14846 Very few explicit references to machine modes remain in the compiler 14847and these few references will soon be removed. Instead, the machine 14848modes are divided into mode classes. These are represented by the 14849enumeration type 'enum mode_class' defined in 'machmode.h'. The 14850possible mode classes are: 14851 14852'MODE_INT' 14853 Integer modes. By default these are 'BImode', 'QImode', 'HImode', 14854 'SImode', 'DImode', 'TImode', and 'OImode'. 14855 14856'MODE_PARTIAL_INT' 14857 The "partial integer" modes, 'PQImode', 'PHImode', 'PSImode' and 14858 'PDImode'. 14859 14860'MODE_FLOAT' 14861 Floating point modes. By default these are 'QFmode', 'HFmode', 14862 'TQFmode', 'SFmode', 'DFmode', 'XFmode' and 'TFmode'. 14863 14864'MODE_DECIMAL_FLOAT' 14865 Decimal floating point modes. By default these are 'SDmode', 14866 'DDmode' and 'TDmode'. 14867 14868'MODE_FRACT' 14869 Signed fractional modes. By default these are 'QQmode', 'HQmode', 14870 'SQmode', 'DQmode' and 'TQmode'. 14871 14872'MODE_UFRACT' 14873 Unsigned fractional modes. By default these are 'UQQmode', 14874 'UHQmode', 'USQmode', 'UDQmode' and 'UTQmode'. 14875 14876'MODE_ACCUM' 14877 Signed accumulator modes. By default these are 'HAmode', 'SAmode', 14878 'DAmode' and 'TAmode'. 14879 14880'MODE_UACCUM' 14881 Unsigned accumulator modes. By default these are 'UHAmode', 14882 'USAmode', 'UDAmode' and 'UTAmode'. 14883 14884'MODE_COMPLEX_INT' 14885 Complex integer modes. (These are not currently implemented). 14886 14887'MODE_COMPLEX_FLOAT' 14888 Complex floating point modes. By default these are 'QCmode', 14889 'HCmode', 'SCmode', 'DCmode', 'XCmode', and 'TCmode'. 14890 14891'MODE_FUNCTION' 14892 Algol or Pascal function variables including a static chain. 14893 (These are not currently implemented). 14894 14895'MODE_CC' 14896 Modes representing condition code values. These are 'CCmode' plus 14897 any 'CC_MODE' modes listed in the 'MACHINE-modes.def'. *Note Jump 14898 Patterns::, also see *note Condition Code::. 14899 14900'MODE_POINTER_BOUNDS' 14901 Pointer bounds modes. Used to represent values of pointer bounds 14902 type. Operations in these modes may be executed as NOPs depending 14903 on hardware features and environment setup. 14904 14905'MODE_RANDOM' 14906 This is a catchall mode class for modes which don't fit into the 14907 above classes. Currently 'VOIDmode' and 'BLKmode' are in 14908 'MODE_RANDOM'. 14909 14910 Here are some C macros that relate to machine modes: 14911 14912'GET_MODE (X)' 14913 Returns the machine mode of the RTX X. 14914 14915'PUT_MODE (X, NEWMODE)' 14916 Alters the machine mode of the RTX X to be NEWMODE. 14917 14918'NUM_MACHINE_MODES' 14919 Stands for the number of machine modes available on the target 14920 machine. This is one greater than the largest numeric value of any 14921 machine mode. 14922 14923'GET_MODE_NAME (M)' 14924 Returns the name of mode M as a string. 14925 14926'GET_MODE_CLASS (M)' 14927 Returns the mode class of mode M. 14928 14929'GET_MODE_WIDER_MODE (M)' 14930 Returns the next wider natural mode. For example, the expression 14931 'GET_MODE_WIDER_MODE (QImode)' returns 'HImode'. 14932 14933'GET_MODE_SIZE (M)' 14934 Returns the size in bytes of a datum of mode M. 14935 14936'GET_MODE_BITSIZE (M)' 14937 Returns the size in bits of a datum of mode M. 14938 14939'GET_MODE_IBIT (M)' 14940 Returns the number of integral bits of a datum of fixed-point mode 14941 M. 14942 14943'GET_MODE_FBIT (M)' 14944 Returns the number of fractional bits of a datum of fixed-point 14945 mode M. 14946 14947'GET_MODE_MASK (M)' 14948 Returns a bitmask containing 1 for all bits in a word that fit 14949 within mode M. This macro can only be used for modes whose bitsize 14950 is less than or equal to 'HOST_BITS_PER_INT'. 14951 14952'GET_MODE_ALIGNMENT (M)' 14953 Return the required alignment, in bits, for an object of mode M. 14954 14955'GET_MODE_UNIT_SIZE (M)' 14956 Returns the size in bytes of the subunits of a datum of mode M. 14957 This is the same as 'GET_MODE_SIZE' except in the case of complex 14958 modes. For them, the unit size is the size of the real or 14959 imaginary part. 14960 14961'GET_MODE_NUNITS (M)' 14962 Returns the number of units contained in a mode, i.e., 14963 'GET_MODE_SIZE' divided by 'GET_MODE_UNIT_SIZE'. 14964 14965'GET_CLASS_NARROWEST_MODE (C)' 14966 Returns the narrowest mode in mode class C. 14967 14968 The following 3 variables are defined on every target. They can be 14969used to allocate buffers that are guaranteed to be large enough to hold 14970any value that can be represented on the target. The first two can be 14971overridden by defining them in the target's mode.def file, however, the 14972value must be a constant that can determined very early in the 14973compilation process. The third symbol cannot be overridden. 14974 14975'BITS_PER_UNIT' 14976 The number of bits in an addressable storage unit (byte). If you 14977 do not define this, the default is 8. 14978 14979'MAX_BITSIZE_MODE_ANY_INT' 14980 The maximum bitsize of any mode that is used in integer math. This 14981 should be overridden by the target if it uses large integers as 14982 containers for larger vectors but otherwise never uses the contents 14983 to compute integer values. 14984 14985'MAX_BITSIZE_MODE_ANY_MODE' 14986 The bitsize of the largest mode on the target. 14987 14988 The global variables 'byte_mode' and 'word_mode' contain modes whose 14989classes are 'MODE_INT' and whose bitsizes are either 'BITS_PER_UNIT' or 14990'BITS_PER_WORD', respectively. On 32-bit machines, these are 'QImode' 14991and 'SImode', respectively. 14992 14993 14994File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 14995 1499613.7 Constant Expression Types 14997============================== 14998 14999The simplest RTL expressions are those that represent constant values. 15000 15001'(const_int I)' 15002 This type of expression represents the integer value I. I is 15003 customarily accessed with the macro 'INTVAL' as in 'INTVAL (EXP)', 15004 which is equivalent to 'XWINT (EXP, 0)'. 15005 15006 Constants generated for modes with fewer bits than in 15007 'HOST_WIDE_INT' must be sign extended to full width (e.g., with 15008 'gen_int_mode'). For constants for modes with more bits than in 15009 'HOST_WIDE_INT' the implied high order bits of that constant are 15010 copies of the top bit. Note however that values are neither 15011 inherently signed nor inherently unsigned; where necessary, 15012 signedness is determined by the rtl operation instead. 15013 15014 There is only one expression object for the integer value zero; it 15015 is the value of the variable 'const0_rtx'. Likewise, the only 15016 expression for integer value one is found in 'const1_rtx', the only 15017 expression for integer value two is found in 'const2_rtx', and the 15018 only expression for integer value negative one is found in 15019 'constm1_rtx'. Any attempt to create an expression of code 15020 'const_int' and value zero, one, two or negative one will return 15021 'const0_rtx', 'const1_rtx', 'const2_rtx' or 'constm1_rtx' as 15022 appropriate. 15023 15024 Similarly, there is only one object for the integer whose value is 15025 'STORE_FLAG_VALUE'. It is found in 'const_true_rtx'. If 15026 'STORE_FLAG_VALUE' is one, 'const_true_rtx' and 'const1_rtx' will 15027 point to the same object. If 'STORE_FLAG_VALUE' is -1, 15028 'const_true_rtx' and 'constm1_rtx' will point to the same object. 15029 15030'(const_double:M I0 I1 ...)' 15031 This represents either a floating-point constant of mode M or (on 15032 older ports that do not define 'TARGET_SUPPORTS_WIDE_INT') an 15033 integer constant too large to fit into 'HOST_BITS_PER_WIDE_INT' 15034 bits but small enough to fit within twice that number of bits. In 15035 the latter case, M will be 'VOIDmode'. For integral values 15036 constants for modes with more bits than twice the number in 15037 'HOST_WIDE_INT' the implied high order bits of that constant are 15038 copies of the top bit of 'CONST_DOUBLE_HIGH'. Note however that 15039 integral values are neither inherently signed nor inherently 15040 unsigned; where necessary, signedness is determined by the rtl 15041 operation instead. 15042 15043 On more modern ports, 'CONST_DOUBLE' only represents floating point 15044 values. New ports define 'TARGET_SUPPORTS_WIDE_INT' to make this 15045 designation. 15046 15047 If M is 'VOIDmode', the bits of the value are stored in I0 and I1. 15048 I0 is customarily accessed with the macro 'CONST_DOUBLE_LOW' and I1 15049 with 'CONST_DOUBLE_HIGH'. 15050 15051 If the constant is floating point (regardless of its precision), 15052 then the number of integers used to store the value depends on the 15053 size of 'REAL_VALUE_TYPE' (*note Floating Point::). The integers 15054 represent a floating point number, but not precisely in the target 15055 machine's or host machine's floating point format. To convert them 15056 to the precise bit pattern used by the target machine, use the 15057 macro 'REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 15058 Output::). 15059 15060'(const_wide_int:M NUNITS ELT0 ...)' 15061 This contains an array of 'HOST_WIDE_INT's that is large enough to 15062 hold any constant that can be represented on the target. This form 15063 of rtl is only used on targets that define 15064 'TARGET_SUPPORTS_WIDE_INT' to be nonzero and then 'CONST_DOUBLE's 15065 are only used to hold floating-point values. If the target leaves 15066 'TARGET_SUPPORTS_WIDE_INT' defined as 0, 'CONST_WIDE_INT's are not 15067 used and 'CONST_DOUBLE's are as they were before. 15068 15069 The values are stored in a compressed format. The higher-order 0s 15070 or -1s are not represented if they are just the logical sign 15071 extension of the number that is represented. 15072 15073'CONST_WIDE_INT_VEC (CODE)' 15074 Returns the entire array of 'HOST_WIDE_INT's that are used to store 15075 the value. This macro should be rarely used. 15076 15077'CONST_WIDE_INT_NUNITS (CODE)' 15078 The number of 'HOST_WIDE_INT's used to represent the number. Note 15079 that this generally is smaller than the number of 'HOST_WIDE_INT's 15080 implied by the mode size. 15081 15082'CONST_WIDE_INT_NUNITS (CODE,I)' 15083 Returns the 'i'th element of the array. Element 0 is contains the 15084 low order bits of the constant. 15085 15086'(const_fixed:M ...)' 15087 Represents a fixed-point constant of mode M. The operand is a data 15088 structure of type 'struct fixed_value' and is accessed with the 15089 macro 'CONST_FIXED_VALUE'. The high part of data is accessed with 15090 'CONST_FIXED_VALUE_HIGH'; the low part is accessed with 15091 'CONST_FIXED_VALUE_LOW'. 15092 15093'(const_vector:M [X0 X1 ...])' 15094 Represents a vector constant. The square brackets stand for the 15095 vector containing the constant elements. X0, X1 and so on are the 15096 'const_int', 'const_double' or 'const_fixed' elements. 15097 15098 The number of units in a 'const_vector' is obtained with the macro 15099 'CONST_VECTOR_NUNITS' as in 'CONST_VECTOR_NUNITS (V)'. 15100 15101 Individual elements in a vector constant are accessed with the 15102 macro 'CONST_VECTOR_ELT' as in 'CONST_VECTOR_ELT (V, N)' where V is 15103 the vector constant and N is the element desired. 15104 15105'(const_string STR)' 15106 Represents a constant string with value STR. Currently this is 15107 used only for insn attributes (*note Insn Attributes::) since 15108 constant strings in C are placed in memory. 15109 15110'(symbol_ref:MODE SYMBOL)' 15111 Represents the value of an assembler label for data. SYMBOL is a 15112 string that describes the name of the assembler label. If it 15113 starts with a '*', the label is the rest of SYMBOL not including 15114 the '*'. Otherwise, the label is SYMBOL, usually prefixed with 15115 '_'. 15116 15117 The 'symbol_ref' contains a mode, which is usually 'Pmode'. 15118 Usually that is the only mode for which a symbol is directly valid. 15119 15120'(label_ref:MODE LABEL)' 15121 Represents the value of an assembler label for code. It contains 15122 one operand, an expression, which must be a 'code_label' or a 15123 'note' of type 'NOTE_INSN_DELETED_LABEL' that appears in the 15124 instruction sequence to identify the place where the label should 15125 go. 15126 15127 The reason for using a distinct expression type for code label 15128 references is so that jump optimization can distinguish them. 15129 15130 The 'label_ref' contains a mode, which is usually 'Pmode'. Usually 15131 that is the only mode for which a label is directly valid. 15132 15133'(const:M EXP)' 15134 Represents a constant that is the result of an assembly-time 15135 arithmetic computation. The operand, EXP, is an expression that 15136 contains only constants ('const_int', 'symbol_ref' and 'label_ref' 15137 expressions) combined with 'plus' and 'minus'. However, not all 15138 combinations are valid, since the assembler cannot do arbitrary 15139 arithmetic on relocatable symbols. 15140 15141 M should be 'Pmode'. 15142 15143'(high:M EXP)' 15144 Represents the high-order bits of EXP, usually a 'symbol_ref'. The 15145 number of bits is machine-dependent and is normally the number of 15146 bits specified in an instruction that initializes the high order 15147 bits of a register. It is used with 'lo_sum' to represent the 15148 typical two-instruction sequence used in RISC machines to reference 15149 a global memory location. 15150 15151 M should be 'Pmode'. 15152 15153 The macro 'CONST0_RTX (MODE)' refers to an expression with value 0 in 15154mode MODE. If mode MODE is of mode class 'MODE_INT', it returns 15155'const0_rtx'. If mode MODE is of mode class 'MODE_FLOAT', it returns a 15156'CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a 15157'CONST_VECTOR' expression in mode MODE. Similarly, the macro 15158'CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE 15159and similarly for 'CONST2_RTX'. The 'CONST1_RTX' and 'CONST2_RTX' 15160macros are undefined for vector modes. 15161 15162 15163File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 15164 1516513.8 Registers and Memory 15166========================= 15167 15168Here are the RTL expression types for describing access to machine 15169registers and to main memory. 15170 15171'(reg:M N)' 15172 For small values of the integer N (those that are less than 15173 'FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 15174 register number N: a "hard register". For larger values of N, it 15175 stands for a temporary value or "pseudo register". The compiler's 15176 strategy is to generate code assuming an unlimited number of such 15177 pseudo registers, and later convert them into hard registers or 15178 into memory references. 15179 15180 M is the machine mode of the reference. It is necessary because 15181 machines can generally refer to each register in more than one 15182 mode. For example, a register may contain a full word but there 15183 may be instructions to refer to it as a half word or as a single 15184 byte, as well as instructions to refer to it as a floating point 15185 number of various precisions. 15186 15187 Even for a register that the machine can access in only one mode, 15188 the mode must always be specified. 15189 15190 The symbol 'FIRST_PSEUDO_REGISTER' is defined by the machine 15191 description, since the number of hard registers on the machine is 15192 an invariant characteristic of the machine. Note, however, that 15193 not all of the machine registers must be general registers. All 15194 the machine registers that can be used for storage of data are 15195 given hard register numbers, even those that can be used only in 15196 certain instructions or can hold only certain types of data. 15197 15198 A hard register may be accessed in various modes throughout one 15199 function, but each pseudo register is given a natural mode and is 15200 accessed only in that mode. When it is necessary to describe an 15201 access to a pseudo register using a nonnatural mode, a 'subreg' 15202 expression is used. 15203 15204 A 'reg' expression with a machine mode that specifies more than one 15205 word of data may actually stand for several consecutive registers. 15206 If in addition the register number specifies a hardware register, 15207 then it actually represents several consecutive hardware registers 15208 starting with the specified one. 15209 15210 Each pseudo register number used in a function's RTL code is 15211 represented by a unique 'reg' expression. 15212 15213 Some pseudo register numbers, those within the range of 15214 'FIRST_VIRTUAL_REGISTER' to 'LAST_VIRTUAL_REGISTER' only appear 15215 during the RTL generation phase and are eliminated before the 15216 optimization phases. These represent locations in the stack frame 15217 that cannot be determined until RTL generation for the function has 15218 been completed. The following virtual register numbers are 15219 defined: 15220 15221 'VIRTUAL_INCOMING_ARGS_REGNUM' 15222 This points to the first word of the incoming arguments passed 15223 on the stack. Normally these arguments are placed there by 15224 the caller, but the callee may have pushed some arguments that 15225 were previously passed in registers. 15226 15227 When RTL generation is complete, this virtual register is 15228 replaced by the sum of the register given by 15229 'ARG_POINTER_REGNUM' and the value of 'FIRST_PARM_OFFSET'. 15230 15231 'VIRTUAL_STACK_VARS_REGNUM' 15232 If 'FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 15233 points to immediately above the first variable on the stack. 15234 Otherwise, it points to the first variable on the stack. 15235 15236 'VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 15237 register given by 'FRAME_POINTER_REGNUM' and the value 15238 'STARTING_FRAME_OFFSET'. 15239 15240 'VIRTUAL_STACK_DYNAMIC_REGNUM' 15241 This points to the location of dynamically allocated memory on 15242 the stack immediately after the stack pointer has been 15243 adjusted by the amount of memory desired. 15244 15245 This virtual register is replaced by the sum of the register 15246 given by 'STACK_POINTER_REGNUM' and the value 15247 'STACK_DYNAMIC_OFFSET'. 15248 15249 'VIRTUAL_OUTGOING_ARGS_REGNUM' 15250 This points to the location in the stack at which outgoing 15251 arguments should be written when the stack is pre-pushed 15252 (arguments pushed using push insns should always use 15253 'STACK_POINTER_REGNUM'). 15254 15255 This virtual register is replaced by the sum of the register 15256 given by 'STACK_POINTER_REGNUM' and the value 15257 'STACK_POINTER_OFFSET'. 15258 15259'(subreg:M1 REG:M2 BYTENUM)' 15260 15261 'subreg' expressions are used to refer to a register in a machine 15262 mode other than its natural one, or to refer to one register of a 15263 multi-part 'reg' that actually refers to several registers. 15264 15265 Each pseudo register has a natural mode. If it is necessary to 15266 operate on it in a different mode, the register must be enclosed in 15267 a 'subreg'. 15268 15269 There are currently three supported types for the first operand of 15270 a 'subreg': 15271 * pseudo registers This is the most common case. Most 'subreg's 15272 have pseudo 'reg's as their first operand. 15273 15274 * mem 'subreg's of 'mem' were common in earlier versions of GCC 15275 and are still supported. During the reload pass these are 15276 replaced by plain 'mem's. On machines that do not do 15277 instruction scheduling, use of 'subreg's of 'mem' are still 15278 used, but this is no longer recommended. Such 'subreg's are 15279 considered to be 'register_operand's rather than 15280 'memory_operand's before and during reload. Because of this, 15281 the scheduling passes cannot properly schedule instructions 15282 with 'subreg's of 'mem', so for machines that do scheduling, 15283 'subreg's of 'mem' should never be used. To support this, the 15284 combine and recog passes have explicit code to inhibit the 15285 creation of 'subreg's of 'mem' when 'INSN_SCHEDULING' is 15286 defined. 15287 15288 The use of 'subreg's of 'mem' after the reload pass is an area 15289 that is not well understood and should be avoided. There is 15290 still some code in the compiler to support this, but this code 15291 has possibly rotted. This use of 'subreg's is discouraged and 15292 will most likely not be supported in the future. 15293 15294 * hard registers It is seldom necessary to wrap hard registers 15295 in 'subreg's; such registers would normally reduce to a single 15296 'reg' rtx. This use of 'subreg's is discouraged and may not 15297 be supported in the future. 15298 15299 'subreg's of 'subreg's are not supported. Using 15300 'simplify_gen_subreg' is the recommended way to avoid this problem. 15301 15302 'subreg's come in two distinct flavors, each having its own usage 15303 and rules: 15304 15305 Paradoxical subregs 15306 When M1 is strictly wider than M2, the 'subreg' expression is 15307 called "paradoxical". The canonical test for this class of 15308 'subreg' is: 15309 15310 GET_MODE_SIZE (M1) > GET_MODE_SIZE (M2) 15311 15312 Paradoxical 'subreg's can be used as both lvalues and rvalues. 15313 When used as an lvalue, the low-order bits of the source value 15314 are stored in REG and the high-order bits are discarded. When 15315 used as an rvalue, the low-order bits of the 'subreg' are 15316 taken from REG while the high-order bits may or may not be 15317 defined. 15318 15319 The high-order bits of rvalues are in the following 15320 circumstances: 15321 15322 * 'subreg's of 'mem' When M2 is smaller than a word, the 15323 macro 'LOAD_EXTEND_OP', can control how the high-order 15324 bits are defined. 15325 15326 * 'subreg' of 'reg's The upper bits are defined when 15327 'SUBREG_PROMOTED_VAR_P' is true. 15328 'SUBREG_PROMOTED_UNSIGNED_P' describes what the upper 15329 bits hold. Such subregs usually represent local 15330 variables, register variables and parameter pseudo 15331 variables that have been promoted to a wider mode. 15332 15333 BYTENUM is always zero for a paradoxical 'subreg', even on 15334 big-endian targets. 15335 15336 For example, the paradoxical 'subreg': 15337 15338 (set (subreg:SI (reg:HI X) 0) Y) 15339 15340 stores the lower 2 bytes of Y in X and discards the upper 2 15341 bytes. A subsequent: 15342 15343 (set Z (subreg:SI (reg:HI X) 0)) 15344 15345 would set the lower two bytes of Z to Y and set the upper two 15346 bytes to an unknown value assuming 'SUBREG_PROMOTED_VAR_P' is 15347 false. 15348 15349 Normal subregs 15350 When M1 is at least as narrow as M2 the 'subreg' expression is 15351 called "normal". 15352 15353 Normal 'subreg's restrict consideration to certain bits of 15354 REG. There are two cases. If M1 is smaller than a word, the 15355 'subreg' refers to the least-significant part (or "lowpart") 15356 of one word of REG. If M1 is word-sized or greater, the 15357 'subreg' refers to one or more complete words. 15358 15359 When used as an lvalue, 'subreg' is a word-based accessor. 15360 Storing to a 'subreg' modifies all the words of REG that 15361 overlap the 'subreg', but it leaves the other words of REG 15362 alone. 15363 15364 When storing to a normal 'subreg' that is smaller than a word, 15365 the other bits of the referenced word are usually left in an 15366 undefined state. This laxity makes it easier to generate 15367 efficient code for such instructions. To represent an 15368 instruction that preserves all the bits outside of those in 15369 the 'subreg', use 'strict_low_part' or 'zero_extract' around 15370 the 'subreg'. 15371 15372 BYTENUM must identify the offset of the first byte of the 15373 'subreg' from the start of REG, assuming that REG is laid out 15374 in memory order. The memory order of bytes is defined by two 15375 target macros, 'WORDS_BIG_ENDIAN' and 'BYTES_BIG_ENDIAN': 15376 15377 * 'WORDS_BIG_ENDIAN', if set to 1, says that byte number 15378 zero is part of the most significant word; otherwise, it 15379 is part of the least significant word. 15380 15381 * 'BYTES_BIG_ENDIAN', if set to 1, says that byte number 15382 zero is the most significant byte within a word; 15383 otherwise, it is the least significant byte within a 15384 word. 15385 15386 On a few targets, 'FLOAT_WORDS_BIG_ENDIAN' disagrees with 15387 'WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 15388 floating point values as if they had the same endianness as 15389 integer values. This works because they handle them solely as 15390 a collection of integer values, with no particular numerical 15391 value. Only real.c and the runtime libraries care about 15392 'FLOAT_WORDS_BIG_ENDIAN'. 15393 15394 Thus, 15395 15396 (subreg:HI (reg:SI X) 2) 15397 15398 on a 'BYTES_BIG_ENDIAN', 'UNITS_PER_WORD == 4' target is the 15399 same as 15400 15401 (subreg:HI (reg:SI X) 0) 15402 15403 on a little-endian, 'UNITS_PER_WORD == 4' target. Both 15404 'subreg's access the lower two bytes of register X. 15405 15406 A 'MODE_PARTIAL_INT' mode behaves as if it were as wide as the 15407 corresponding 'MODE_INT' mode, except that it has an unknown number 15408 of undefined bits. For example: 15409 15410 (subreg:PSI (reg:SI 0) 0) 15411 15412 accesses the whole of '(reg:SI 0)', but the exact relationship 15413 between the 'PSImode' value and the 'SImode' value is not defined. 15414 If we assume 'UNITS_PER_WORD <= 4', then the following two 15415 'subreg's: 15416 15417 (subreg:PSI (reg:DI 0) 0) 15418 (subreg:PSI (reg:DI 0) 4) 15419 15420 represent independent 4-byte accesses to the two halves of '(reg:DI 15421 0)'. Both 'subreg's have an unknown number of undefined bits. 15422 15423 If 'UNITS_PER_WORD <= 2' then these two 'subreg's: 15424 15425 (subreg:HI (reg:PSI 0) 0) 15426 (subreg:HI (reg:PSI 0) 2) 15427 15428 represent independent 2-byte accesses that together span the whole 15429 of '(reg:PSI 0)'. Storing to the first 'subreg' does not affect 15430 the value of the second, and vice versa. '(reg:PSI 0)' has an 15431 unknown number of undefined bits, so the assignment: 15432 15433 (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4)) 15434 15435 does not guarantee that '(subreg:HI (reg:PSI 0) 0)' has the value 15436 '(reg:HI 4)'. 15437 15438 The rules above apply to both pseudo REGs and hard REGs. If the 15439 semantics are not correct for particular combinations of M1, M2 and 15440 hard REG, the target-specific code must ensure that those 15441 combinations are never used. For example: 15442 15443 CANNOT_CHANGE_MODE_CLASS (M2, M1, CLASS) 15444 15445 must be true for every class CLASS that includes REG. 15446 15447 The first operand of a 'subreg' expression is customarily accessed 15448 with the 'SUBREG_REG' macro and the second operand is customarily 15449 accessed with the 'SUBREG_BYTE' macro. 15450 15451 It has been several years since a platform in which 15452 'BYTES_BIG_ENDIAN' not equal to 'WORDS_BIG_ENDIAN' has been tested. 15453 Anyone wishing to support such a platform in the future may be 15454 confronted with code rot. 15455 15456'(scratch:M)' 15457 This represents a scratch register that will be required for the 15458 execution of a single instruction and not used subsequently. It is 15459 converted into a 'reg' by either the local register allocator or 15460 the reload pass. 15461 15462 'scratch' is usually present inside a 'clobber' operation (*note 15463 Side Effects::). 15464 15465'(cc0)' 15466 This refers to the machine's condition code register. It has no 15467 operands and may not have a machine mode. There are two ways to 15468 use it: 15469 15470 * To stand for a complete set of condition code flags. This is 15471 best on most machines, where each comparison sets the entire 15472 series of flags. 15473 15474 With this technique, '(cc0)' may be validly used in only two 15475 contexts: as the destination of an assignment (in test and 15476 compare instructions) and in comparison operators comparing 15477 against zero ('const_int' with value zero; that is to say, 15478 'const0_rtx'). 15479 15480 * To stand for a single flag that is the result of a single 15481 condition. This is useful on machines that have only a single 15482 flag bit, and in which comparison instructions must specify 15483 the condition to test. 15484 15485 With this technique, '(cc0)' may be validly used in only two 15486 contexts: as the destination of an assignment (in test and 15487 compare instructions) where the source is a comparison 15488 operator, and as the first operand of 'if_then_else' (in a 15489 conditional branch). 15490 15491 There is only one expression object of code 'cc0'; it is the value 15492 of the variable 'cc0_rtx'. Any attempt to create an expression of 15493 code 'cc0' will return 'cc0_rtx'. 15494 15495 Instructions can set the condition code implicitly. On many 15496 machines, nearly all instructions set the condition code based on 15497 the value that they compute or store. It is not necessary to 15498 record these actions explicitly in the RTL because the machine 15499 description includes a prescription for recognizing the 15500 instructions that do so (by means of the macro 'NOTICE_UPDATE_CC'). 15501 *Note Condition Code::. Only instructions whose sole purpose is to 15502 set the condition code, and instructions that use the condition 15503 code, need mention '(cc0)'. 15504 15505 On some machines, the condition code register is given a register 15506 number and a 'reg' is used instead of '(cc0)'. This is usually the 15507 preferable approach if only a small subset of instructions modify 15508 the condition code. Other machines store condition codes in 15509 general registers; in such cases a pseudo register should be used. 15510 15511 Some machines, such as the SPARC and RS/6000, have two sets of 15512 arithmetic instructions, one that sets and one that does not set 15513 the condition code. This is best handled by normally generating 15514 the instruction that does not set the condition code, and making a 15515 pattern that both performs the arithmetic and sets the condition 15516 code register (which would not be '(cc0)' in this case). For 15517 examples, search for 'addcc' and 'andcc' in 'sparc.md'. 15518 15519'(pc)' 15520 This represents the machine's program counter. It has no operands 15521 and may not have a machine mode. '(pc)' may be validly used only 15522 in certain specific contexts in jump instructions. 15523 15524 There is only one expression object of code 'pc'; it is the value 15525 of the variable 'pc_rtx'. Any attempt to create an expression of 15526 code 'pc' will return 'pc_rtx'. 15527 15528 All instructions that do not jump alter the program counter 15529 implicitly by incrementing it, but there is no need to mention this 15530 in the RTL. 15531 15532'(mem:M ADDR ALIAS)' 15533 This RTX represents a reference to main memory at an address 15534 represented by the expression ADDR. M specifies how large a unit 15535 of memory is accessed. ALIAS specifies an alias set for the 15536 reference. In general two items are in different alias sets if 15537 they cannot reference the same memory address. 15538 15539 The construct '(mem:BLK (scratch))' is considered to alias all 15540 other memories. Thus it may be used as a memory barrier in 15541 epilogue stack deallocation patterns. 15542 15543'(concatM RTX RTX)' 15544 This RTX represents the concatenation of two other RTXs. This is 15545 used for complex values. It should only appear in the RTL attached 15546 to declarations and during RTL generation. It should not appear in 15547 the ordinary insn chain. 15548 15549'(concatnM [RTX ...])' 15550 This RTX represents the concatenation of all the RTX to make a 15551 single value. Like 'concat', this should only appear in 15552 declarations, and not in the insn chain. 15553 15554 15555File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 15556 1555713.9 RTL Expressions for Arithmetic 15558=================================== 15559 15560Unless otherwise specified, all the operands of arithmetic expressions 15561must be valid for mode M. An operand is valid for mode M if it has mode 15562M, or if it is a 'const_int' or 'const_double' and M is a mode of class 15563'MODE_INT'. 15564 15565 For commutative binary operations, constants should be placed in the 15566second operand. 15567 15568'(plus:M X Y)' 15569'(ss_plus:M X Y)' 15570'(us_plus:M X Y)' 15571 15572 These three expressions all represent the sum of the values 15573 represented by X and Y carried out in machine mode M. They differ 15574 in their behavior on overflow of integer modes. 'plus' wraps round 15575 modulo the width of M; 'ss_plus' saturates at the maximum signed 15576 value representable in M; 'us_plus' saturates at the maximum 15577 unsigned value. 15578 15579'(lo_sum:M X Y)' 15580 15581 This expression represents the sum of X and the low-order bits of 15582 Y. It is used with 'high' (*note Constants::) to represent the 15583 typical two-instruction sequence used in RISC machines to reference 15584 a global memory location. 15585 15586 The number of low order bits is machine-dependent but is normally 15587 the number of bits in a 'Pmode' item minus the number of bits set 15588 by 'high'. 15589 15590 M should be 'Pmode'. 15591 15592'(minus:M X Y)' 15593'(ss_minus:M X Y)' 15594'(us_minus:M X Y)' 15595 15596 These three expressions represent the result of subtracting Y from 15597 X, carried out in mode M. Behavior on overflow is the same as for 15598 the three variants of 'plus' (see above). 15599 15600'(compare:M X Y)' 15601 Represents the result of subtracting Y from X for purposes of 15602 comparison. The result is computed without overflow, as if with 15603 infinite precision. 15604 15605 Of course, machines can't really subtract with infinite precision. 15606 However, they can pretend to do so when only the sign of the result 15607 will be used, which is the case when the result is stored in the 15608 condition code. And that is the _only_ way this kind of expression 15609 may validly be used: as a value to be stored in the condition 15610 codes, either '(cc0)' or a register. *Note Comparisons::. 15611 15612 The mode M is not related to the modes of X and Y, but instead is 15613 the mode of the condition code value. If '(cc0)' is used, it is 15614 'VOIDmode'. Otherwise it is some mode in class 'MODE_CC', often 15615 'CCmode'. *Note Condition Code::. If M is 'VOIDmode' or 'CCmode', 15616 the operation returns sufficient information (in an unspecified 15617 format) so that any comparison operator can be applied to the 15618 result of the 'COMPARE' operation. For other modes in class 15619 'MODE_CC', the operation only returns a subset of this information. 15620 15621 Normally, X and Y must have the same mode. Otherwise, 'compare' is 15622 valid only if the mode of X is in class 'MODE_INT' and Y is a 15623 'const_int' or 'const_double' with mode 'VOIDmode'. The mode of X 15624 determines what mode the comparison is to be done in; thus it must 15625 not be 'VOIDmode'. 15626 15627 If one of the operands is a constant, it should be placed in the 15628 second operand and the comparison code adjusted as appropriate. 15629 15630 A 'compare' specifying two 'VOIDmode' constants is not valid since 15631 there is no way to know in what mode the comparison is to be 15632 performed; the comparison must either be folded during the 15633 compilation or the first operand must be loaded into a register 15634 while its mode is still known. 15635 15636'(neg:M X)' 15637'(ss_neg:M X)' 15638'(us_neg:M X)' 15639 These two expressions represent the negation (subtraction from 15640 zero) of the value represented by X, carried out in mode M. They 15641 differ in the behavior on overflow of integer modes. In the case 15642 of 'neg', the negation of the operand may be a number not 15643 representable in mode M, in which case it is truncated to M. 15644 'ss_neg' and 'us_neg' ensure that an out-of-bounds result saturates 15645 to the maximum or minimum signed or unsigned value. 15646 15647'(mult:M X Y)' 15648'(ss_mult:M X Y)' 15649'(us_mult:M X Y)' 15650 Represents the signed product of the values represented by X and Y 15651 carried out in machine mode M. 'ss_mult' and 'us_mult' ensure that 15652 an out-of-bounds result saturates to the maximum or minimum signed 15653 or unsigned value. 15654 15655 Some machines support a multiplication that generates a product 15656 wider than the operands. Write the pattern for this as 15657 15658 (mult:M (sign_extend:M X) (sign_extend:M Y)) 15659 15660 where M is wider than the modes of X and Y, which need not be the 15661 same. 15662 15663 For unsigned widening multiplication, use the same idiom, but with 15664 'zero_extend' instead of 'sign_extend'. 15665 15666'(fma:M X Y Z)' 15667 Represents the 'fma', 'fmaf', and 'fmal' builtin functions, which 15668 compute 'X * Y + Z' without doing an intermediate rounding step. 15669 15670'(div:M X Y)' 15671'(ss_div:M X Y)' 15672 Represents the quotient in signed division of X by Y, carried out 15673 in machine mode M. If M is a floating point mode, it represents 15674 the exact quotient; otherwise, the integerized quotient. 'ss_div' 15675 ensures that an out-of-bounds result saturates to the maximum or 15676 minimum signed value. 15677 15678 Some machines have division instructions in which the operands and 15679 quotient widths are not all the same; you should represent such 15680 instructions using 'truncate' and 'sign_extend' as in, 15681 15682 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 15683 15684'(udiv:M X Y)' 15685'(us_div:M X Y)' 15686 Like 'div' but represents unsigned division. 'us_div' ensures that 15687 an out-of-bounds result saturates to the maximum or minimum 15688 unsigned value. 15689 15690'(mod:M X Y)' 15691'(umod:M X Y)' 15692 Like 'div' and 'udiv' but represent the remainder instead of the 15693 quotient. 15694 15695'(smin:M X Y)' 15696'(smax:M X Y)' 15697 Represents the smaller (for 'smin') or larger (for 'smax') of X and 15698 Y, interpreted as signed values in mode M. When used with floating 15699 point, if both operands are zeros, or if either operand is 'NaN', 15700 then it is unspecified which of the two operands is returned as the 15701 result. 15702 15703'(umin:M X Y)' 15704'(umax:M X Y)' 15705 Like 'smin' and 'smax', but the values are interpreted as unsigned 15706 integers. 15707 15708'(not:M X)' 15709 Represents the bitwise complement of the value represented by X, 15710 carried out in mode M, which must be a fixed-point machine mode. 15711 15712'(and:M X Y)' 15713 Represents the bitwise logical-and of the values represented by X 15714 and Y, carried out in machine mode M, which must be a fixed-point 15715 machine mode. 15716 15717'(ior:M X Y)' 15718 Represents the bitwise inclusive-or of the values represented by X 15719 and Y, carried out in machine mode M, which must be a fixed-point 15720 mode. 15721 15722'(xor:M X Y)' 15723 Represents the bitwise exclusive-or of the values represented by X 15724 and Y, carried out in machine mode M, which must be a fixed-point 15725 mode. 15726 15727'(ashift:M X C)' 15728'(ss_ashift:M X C)' 15729'(us_ashift:M X C)' 15730 These three expressions represent the result of arithmetically 15731 shifting X left by C places. They differ in their behavior on 15732 overflow of integer modes. An 'ashift' operation is a plain shift 15733 with no special behavior in case of a change in the sign bit; 15734 'ss_ashift' and 'us_ashift' saturates to the minimum or maximum 15735 representable value if any of the bits shifted out differs from the 15736 final sign bit. 15737 15738 X have mode M, a fixed-point machine mode. C be a fixed-point mode 15739 or be a constant with mode 'VOIDmode'; which mode is determined by 15740 the mode called for in the machine description entry for the 15741 left-shift instruction. For example, on the VAX, the mode of C is 15742 'QImode' regardless of M. 15743 15744'(lshiftrt:M X C)' 15745'(ashiftrt:M X C)' 15746 Like 'ashift' but for right shift. Unlike the case for left shift, 15747 these two operations are distinct. 15748 15749'(rotate:M X C)' 15750'(rotatert:M X C)' 15751 Similar but represent left and right rotate. If C is a constant, 15752 use 'rotate'. 15753 15754'(abs:M X)' 15755'(ss_abs:M X)' 15756 Represents the absolute value of X, computed in mode M. 'ss_abs' 15757 ensures that an out-of-bounds result saturates to the maximum 15758 signed value. 15759 15760'(sqrt:M X)' 15761 Represents the square root of X, computed in mode M. Most often M 15762 will be a floating point mode. 15763 15764'(ffs:M X)' 15765 Represents one plus the index of the least significant 1-bit in X, 15766 represented as an integer of mode M. (The value is zero if X is 15767 zero.) The mode of X must be M or 'VOIDmode'. 15768 15769'(clrsb:M X)' 15770 Represents the number of redundant leading sign bits in X, 15771 represented as an integer of mode M, starting at the most 15772 significant bit position. This is one less than the number of 15773 leading sign bits (either 0 or 1), with no special cases. The mode 15774 of X must be M or 'VOIDmode'. 15775 15776'(clz:M X)' 15777 Represents the number of leading 0-bits in X, represented as an 15778 integer of mode M, starting at the most significant bit position. 15779 If X is zero, the value is determined by 15780 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one 15781 of the few expressions that is not invariant under widening. The 15782 mode of X must be M or 'VOIDmode'. 15783 15784'(ctz:M X)' 15785 Represents the number of trailing 0-bits in X, represented as an 15786 integer of mode M, starting at the least significant bit position. 15787 If X is zero, the value is determined by 15788 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case, 15789 'ctz(x)' is equivalent to 'ffs(X) - 1'. The mode of X must be M or 15790 'VOIDmode'. 15791 15792'(popcount:M X)' 15793 Represents the number of 1-bits in X, represented as an integer of 15794 mode M. The mode of X must be M or 'VOIDmode'. 15795 15796'(parity:M X)' 15797 Represents the number of 1-bits modulo 2 in X, represented as an 15798 integer of mode M. The mode of X must be M or 'VOIDmode'. 15799 15800'(bswap:M X)' 15801 Represents the value X with the order of bytes reversed, carried 15802 out in mode M, which must be a fixed-point machine mode. The mode 15803 of X must be M or 'VOIDmode'. 15804 15805 15806File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 15807 1580813.10 Comparison Operations 15809=========================== 15810 15811Comparison operators test a relation on two operands and are considered 15812to represent a machine-dependent nonzero value described by, but not 15813necessarily equal to, 'STORE_FLAG_VALUE' (*note Misc::) if the relation 15814holds, or zero if it does not, for comparison operators whose results 15815have a 'MODE_INT' mode, 'FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 15816relation holds, or zero if it does not, for comparison operators that 15817return floating-point values, and a vector of either 15818'VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 15819zeros if it does not, for comparison operators that return vector 15820results. The mode of the comparison operation is independent of the 15821mode of the data being compared. If the comparison operation is being 15822tested (e.g., the first operand of an 'if_then_else'), the mode must be 15823'VOIDmode'. 15824 15825 There are two ways that comparison operations may be used. The 15826comparison operators may be used to compare the condition codes '(cc0)' 15827against zero, as in '(eq (cc0) (const_int 0))'. Such a construct 15828actually refers to the result of the preceding instruction in which the 15829condition codes were set. The instruction setting the condition code 15830must be adjacent to the instruction using the condition code; only 15831'note' insns may separate them. 15832 15833 Alternatively, a comparison operation may directly compare two data 15834objects. The mode of the comparison is determined by the operands; they 15835must both be valid for a common machine mode. A comparison with both 15836operands constant would be invalid as the machine mode could not be 15837deduced from it, but such a comparison should never exist in RTL due to 15838constant folding. 15839 15840 In the example above, if '(cc0)' were last set to '(compare X Y)', the 15841comparison operation is identical to '(eq X Y)'. Usually only one style 15842of comparisons is supported on a particular machine, but the combine 15843pass will try to merge the operations to produce the 'eq' shown in case 15844it exists in the context of the particular insn involved. 15845 15846 Inequality comparisons come in two flavors, signed and unsigned. Thus, 15847there are distinct expression codes 'gt' and 'gtu' for signed and 15848unsigned greater-than. These can produce different results for the same 15849pair of integer values: for example, 1 is signed greater-than -1 but not 15850unsigned greater-than, because -1 when regarded as unsigned is actually 15851'0xffffffff' which is greater than 1. 15852 15853 The signed comparisons are also used for floating point values. 15854Floating point comparisons are distinguished by the machine modes of the 15855operands. 15856 15857'(eq:M X Y)' 15858 'STORE_FLAG_VALUE' if the values represented by X and Y are equal, 15859 otherwise 0. 15860 15861'(ne:M X Y)' 15862 'STORE_FLAG_VALUE' if the values represented by X and Y are not 15863 equal, otherwise 0. 15864 15865'(gt:M X Y)' 15866 'STORE_FLAG_VALUE' if the X is greater than Y. If they are 15867 fixed-point, the comparison is done in a signed sense. 15868 15869'(gtu:M X Y)' 15870 Like 'gt' but does unsigned comparison, on fixed-point numbers 15871 only. 15872 15873'(lt:M X Y)' 15874'(ltu:M X Y)' 15875 Like 'gt' and 'gtu' but test for "less than". 15876 15877'(ge:M X Y)' 15878'(geu:M X Y)' 15879 Like 'gt' and 'gtu' but test for "greater than or equal". 15880 15881'(le:M X Y)' 15882'(leu:M X Y)' 15883 Like 'gt' and 'gtu' but test for "less than or equal". 15884 15885'(if_then_else COND THEN ELSE)' 15886 This is not a comparison operation but is listed here because it is 15887 always used in conjunction with a comparison operation. To be 15888 precise, COND is a comparison expression. This expression 15889 represents a choice, according to COND, between the value 15890 represented by THEN and the one represented by ELSE. 15891 15892 On most machines, 'if_then_else' expressions are valid only to 15893 express conditional jumps. 15894 15895'(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 15896 Similar to 'if_then_else', but more general. Each of TEST1, TEST2, 15897 ... is performed in turn. The result of this expression is the 15898 VALUE corresponding to the first nonzero test, or DEFAULT if none 15899 of the tests are nonzero expressions. 15900 15901 This is currently not valid for instruction patterns and is 15902 supported only for insn attributes. *Note Insn Attributes::. 15903 15904 15905File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 15906 1590713.11 Bit-Fields 15908================ 15909 15910Special expression codes exist to represent bit-field instructions. 15911 15912'(sign_extract:M LOC SIZE POS)' 15913 This represents a reference to a sign-extended bit-field contained 15914 or starting in LOC (a memory or register reference). The bit-field 15915 is SIZE bits wide and starts at bit POS. The compilation option 15916 'BITS_BIG_ENDIAN' says which end of the memory unit POS counts 15917 from. 15918 15919 If LOC is in memory, its mode must be a single-byte integer mode. 15920 If LOC is in a register, the mode to use is specified by the 15921 operand of the 'insv' or 'extv' pattern (*note Standard Names::) 15922 and is usually a full-word integer mode, which is the default if 15923 none is specified. 15924 15925 The mode of POS is machine-specific and is also specified in the 15926 'insv' or 'extv' pattern. 15927 15928 The mode M is the same as the mode that would be used for LOC if it 15929 were a register. 15930 15931 A 'sign_extract' can not appear as an lvalue, or part thereof, in 15932 RTL. 15933 15934'(zero_extract:M LOC SIZE POS)' 15935 Like 'sign_extract' but refers to an unsigned or zero-extended 15936 bit-field. The same sequence of bits are extracted, but they are 15937 filled to an entire word with zeros instead of by sign-extension. 15938 15939 Unlike 'sign_extract', this type of expressions can be lvalues in 15940 RTL; they may appear on the left side of an assignment, indicating 15941 insertion of a value into the specified bit-field. 15942 15943 15944File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 15945 1594613.12 Vector Operations 15947======================= 15948 15949All normal RTL expressions can be used with vector modes; they are 15950interpreted as operating on each part of the vector independently. 15951Additionally, there are a few new expressions to describe specific 15952vector operations. 15953 15954'(vec_merge:M VEC1 VEC2 ITEMS)' 15955 This describes a merge operation between two vectors. The result 15956 is a vector of mode M; its elements are selected from either VEC1 15957 or VEC2. Which elements are selected is described by ITEMS, which 15958 is a bit mask represented by a 'const_int'; a zero bit indicates 15959 the corresponding element in the result vector is taken from VEC2 15960 while a set bit indicates it is taken from VEC1. 15961 15962'(vec_select:M VEC1 SELECTION)' 15963 This describes an operation that selects parts of a vector. VEC1 15964 is the source vector, and SELECTION is a 'parallel' that contains a 15965 'const_int' for each of the subparts of the result vector, giving 15966 the number of the source subpart that should be stored into it. 15967 The result mode M is either the submode for a single element of 15968 VEC1 (if only one subpart is selected), or another vector mode with 15969 that element submode (if multiple subparts are selected). 15970 15971'(vec_concat:M X1 X2)' 15972 Describes a vector concat operation. The result is a concatenation 15973 of the vectors or scalars X1 and X2; its length is the sum of the 15974 lengths of the two inputs. 15975 15976'(vec_duplicate:M X)' 15977 This operation converts a scalar into a vector or a small vector 15978 into a larger one by duplicating the input values. The output 15979 vector mode must have the same submodes as the input vector mode or 15980 the scalar modes, and the number of output parts must be an integer 15981 multiple of the number of input parts. 15982 15983 15984File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 15985 1598613.13 Conversions 15987================= 15988 15989All conversions between machine modes must be represented by explicit 15990conversion operations. For example, an expression which is the sum of a 15991byte and a full word cannot be written as '(plus:SI (reg:QI 34) (reg:SI 1599280))' because the 'plus' operation requires two operands of the same 15993machine mode. Therefore, the byte-sized operand is enclosed in a 15994conversion operation, as in 15995 15996 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 15997 15998 The conversion operation is not a mere placeholder, because there may 15999be more than one way of converting from a given starting mode to the 16000desired final mode. The conversion operation code says how to do it. 16001 16002 For all conversion operations, X must not be 'VOIDmode' because the 16003mode in which to do the conversion would not be known. The conversion 16004must either be done at compile-time or X must be placed into a register. 16005 16006'(sign_extend:M X)' 16007 Represents the result of sign-extending the value X to machine mode 16008 M. M must be a fixed-point mode and X a fixed-point value of a 16009 mode narrower than M. 16010 16011'(zero_extend:M X)' 16012 Represents the result of zero-extending the value X to machine mode 16013 M. M must be a fixed-point mode and X a fixed-point value of a 16014 mode narrower than M. 16015 16016'(float_extend:M X)' 16017 Represents the result of extending the value X to machine mode M. 16018 M must be a floating point mode and X a floating point value of a 16019 mode narrower than M. 16020 16021'(truncate:M X)' 16022 Represents the result of truncating the value X to machine mode M. 16023 M must be a fixed-point mode and X a fixed-point value of a mode 16024 wider than M. 16025 16026'(ss_truncate:M X)' 16027 Represents the result of truncating the value X to machine mode M, 16028 using signed saturation in the case of overflow. Both M and the 16029 mode of X must be fixed-point modes. 16030 16031'(us_truncate:M X)' 16032 Represents the result of truncating the value X to machine mode M, 16033 using unsigned saturation in the case of overflow. Both M and the 16034 mode of X must be fixed-point modes. 16035 16036'(float_truncate:M X)' 16037 Represents the result of truncating the value X to machine mode M. 16038 M must be a floating point mode and X a floating point value of a 16039 mode wider than M. 16040 16041'(float:M X)' 16042 Represents the result of converting fixed point value X, regarded 16043 as signed, to floating point mode M. 16044 16045'(unsigned_float:M X)' 16046 Represents the result of converting fixed point value X, regarded 16047 as unsigned, to floating point mode M. 16048 16049'(fix:M X)' 16050 When M is a floating-point mode, represents the result of 16051 converting floating point value X (valid for mode M) to an integer, 16052 still represented in floating point mode M, by rounding towards 16053 zero. 16054 16055 When M is a fixed-point mode, represents the result of converting 16056 floating point value X to mode M, regarded as signed. How rounding 16057 is done is not specified, so this operation may be used validly in 16058 compiling C code only for integer-valued operands. 16059 16060'(unsigned_fix:M X)' 16061 Represents the result of converting floating point value X to fixed 16062 point mode M, regarded as unsigned. How rounding is done is not 16063 specified. 16064 16065'(fract_convert:M X)' 16066 Represents the result of converting fixed-point value X to 16067 fixed-point mode M, signed integer value X to fixed-point mode M, 16068 floating-point value X to fixed-point mode M, fixed-point value X 16069 to integer mode M regarded as signed, or fixed-point value X to 16070 floating-point mode M. When overflows or underflows happen, the 16071 results are undefined. 16072 16073'(sat_fract:M X)' 16074 Represents the result of converting fixed-point value X to 16075 fixed-point mode M, signed integer value X to fixed-point mode M, 16076 or floating-point value X to fixed-point mode M. When overflows or 16077 underflows happen, the results are saturated to the maximum or the 16078 minimum. 16079 16080'(unsigned_fract_convert:M X)' 16081 Represents the result of converting fixed-point value X to integer 16082 mode M regarded as unsigned, or unsigned integer value X to 16083 fixed-point mode M. When overflows or underflows happen, the 16084 results are undefined. 16085 16086'(unsigned_sat_fract:M X)' 16087 Represents the result of converting unsigned integer value X to 16088 fixed-point mode M. When overflows or underflows happen, the 16089 results are saturated to the maximum or the minimum. 16090 16091 16092File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 16093 1609413.14 Declarations 16095================== 16096 16097Declaration expression codes do not represent arithmetic operations but 16098rather state assertions about their operands. 16099 16100'(strict_low_part (subreg:M (reg:N R) 0))' 16101 This expression code is used in only one context: as the 16102 destination operand of a 'set' expression. In addition, the 16103 operand of this expression must be a non-paradoxical 'subreg' 16104 expression. 16105 16106 The presence of 'strict_low_part' says that the part of the 16107 register which is meaningful in mode N, but is not part of mode M, 16108 is not to be altered. Normally, an assignment to such a subreg is 16109 allowed to have undefined effects on the rest of the register when 16110 M is less than a word. 16111 16112 16113File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 16114 1611513.15 Side Effect Expressions 16116============================= 16117 16118The expression codes described so far represent values, not actions. 16119But machine instructions never produce values; they are meaningful only 16120for their side effects on the state of the machine. Special expression 16121codes are used to represent side effects. 16122 16123 The body of an instruction is always one of these side effect codes; 16124the codes described above, which represent values, appear only as the 16125operands of these. 16126 16127'(set LVAL X)' 16128 Represents the action of storing the value of X into the place 16129 represented by LVAL. LVAL must be an expression representing a 16130 place that can be stored in: 'reg' (or 'subreg', 'strict_low_part' 16131 or 'zero_extract'), 'mem', 'pc', 'parallel', or 'cc0'. 16132 16133 If LVAL is a 'reg', 'subreg' or 'mem', it has a machine mode; then 16134 X must be valid for that mode. 16135 16136 If LVAL is a 'reg' whose machine mode is less than the full width 16137 of the register, then it means that the part of the register 16138 specified by the machine mode is given the specified value and the 16139 rest of the register receives an undefined value. Likewise, if 16140 LVAL is a 'subreg' whose machine mode is narrower than the mode of 16141 the register, the rest of the register can be changed in an 16142 undefined way. 16143 16144 If LVAL is a 'strict_low_part' of a subreg, then the part of the 16145 register specified by the machine mode of the 'subreg' is given the 16146 value X and the rest of the register is not changed. 16147 16148 If LVAL is a 'zero_extract', then the referenced part of the 16149 bit-field (a memory or register reference) specified by the 16150 'zero_extract' is given the value X and the rest of the bit-field 16151 is not changed. Note that 'sign_extract' can not appear in LVAL. 16152 16153 If LVAL is '(cc0)', it has no machine mode, and X may be either a 16154 'compare' expression or a value that may have any mode. The latter 16155 case represents a "test" instruction. The expression '(set (cc0) 16156 (reg:M N))' is equivalent to '(set (cc0) (compare (reg:M N) 16157 (const_int 0)))'. Use the former expression to save space during 16158 the compilation. 16159 16160 If LVAL is a 'parallel', it is used to represent the case of a 16161 function returning a structure in multiple registers. Each element 16162 of the 'parallel' is an 'expr_list' whose first operand is a 'reg' 16163 and whose second operand is a 'const_int' representing the offset 16164 (in bytes) into the structure at which the data in that register 16165 corresponds. The first element may be null to indicate that the 16166 structure is also passed partly in memory. 16167 16168 If LVAL is '(pc)', we have a jump instruction, and the 16169 possibilities for X are very limited. It may be a 'label_ref' 16170 expression (unconditional jump). It may be an 'if_then_else' 16171 (conditional jump), in which case either the second or the third 16172 operand must be '(pc)' (for the case which does not jump) and the 16173 other of the two must be a 'label_ref' (for the case which does 16174 jump). X may also be a 'mem' or '(plus:SI (pc) Y)', where Y may be 16175 a 'reg' or a 'mem'; these unusual patterns are used to represent 16176 jumps through branch tables. 16177 16178 If LVAL is neither '(cc0)' nor '(pc)', the mode of LVAL must not be 16179 'VOIDmode' and the mode of X must be valid for the mode of LVAL. 16180 16181 LVAL is customarily accessed with the 'SET_DEST' macro and X with 16182 the 'SET_SRC' macro. 16183 16184'(return)' 16185 As the sole expression in a pattern, represents a return from the 16186 current function, on machines where this can be done with one 16187 instruction, such as VAXen. On machines where a multi-instruction 16188 "epilogue" must be executed in order to return from the function, 16189 returning is done by jumping to a label which precedes the 16190 epilogue, and the 'return' expression code is never used. 16191 16192 Inside an 'if_then_else' expression, represents the value to be 16193 placed in 'pc' to return to the caller. 16194 16195 Note that an insn pattern of '(return)' is logically equivalent to 16196 '(set (pc) (return))', but the latter form is never used. 16197 16198'(simple_return)' 16199 Like '(return)', but truly represents only a function return, while 16200 '(return)' may represent an insn that also performs other functions 16201 of the function epilogue. Like '(return)', this may also occur in 16202 conditional jumps. 16203 16204'(call FUNCTION NARGS)' 16205 Represents a function call. FUNCTION is a 'mem' expression whose 16206 address is the address of the function to be called. NARGS is an 16207 expression which can be used for two purposes: on some machines it 16208 represents the number of bytes of stack argument; on others, it 16209 represents the number of argument registers. 16210 16211 Each machine has a standard machine mode which FUNCTION must have. 16212 The machine description defines macro 'FUNCTION_MODE' to expand 16213 into the requisite mode name. The purpose of this mode is to 16214 specify what kind of addressing is allowed, on machines where the 16215 allowed kinds of addressing depend on the machine mode being 16216 addressed. 16217 16218'(clobber X)' 16219 Represents the storing or possible storing of an unpredictable, 16220 undescribed value into X, which must be a 'reg', 'scratch', 16221 'parallel' or 'mem' expression. 16222 16223 One place this is used is in string instructions that store 16224 standard values into particular hard registers. It may not be 16225 worth the trouble to describe the values that are stored, but it is 16226 essential to inform the compiler that the registers will be 16227 altered, lest it attempt to keep data in them across the string 16228 instruction. 16229 16230 If X is '(mem:BLK (const_int 0))' or '(mem:BLK (scratch))', it 16231 means that all memory locations must be presumed clobbered. If X 16232 is a 'parallel', it has the same meaning as a 'parallel' in a 'set' 16233 expression. 16234 16235 Note that the machine description classifies certain hard registers 16236 as "call-clobbered". All function call instructions are assumed by 16237 default to clobber these registers, so there is no need to use 16238 'clobber' expressions to indicate this fact. Also, each function 16239 call is assumed to have the potential to alter any memory location, 16240 unless the function is declared 'const'. 16241 16242 If the last group of expressions in a 'parallel' are each a 16243 'clobber' expression whose arguments are 'reg' or 'match_scratch' 16244 (*note RTL Template::) expressions, the combiner phase can add the 16245 appropriate 'clobber' expressions to an insn it has constructed 16246 when doing so will cause a pattern to be matched. 16247 16248 This feature can be used, for example, on a machine that whose 16249 multiply and add instructions don't use an MQ register but which 16250 has an add-accumulate instruction that does clobber the MQ 16251 register. Similarly, a combined instruction might require a 16252 temporary register while the constituent instructions might not. 16253 16254 When a 'clobber' expression for a register appears inside a 16255 'parallel' with other side effects, the register allocator 16256 guarantees that the register is unoccupied both before and after 16257 that insn if it is a hard register clobber. For pseudo-register 16258 clobber, the register allocator and the reload pass do not assign 16259 the same hard register to the clobber and the input operands if 16260 there is an insn alternative containing the '&' constraint (*note 16261 Modifiers::) for the clobber and the hard register is in register 16262 classes of the clobber in the alternative. You can clobber either 16263 a specific hard register, a pseudo register, or a 'scratch' 16264 expression; in the latter two cases, GCC will allocate a hard 16265 register that is available there for use as a temporary. 16266 16267 For instructions that require a temporary register, you should use 16268 'scratch' instead of a pseudo-register because this will allow the 16269 combiner phase to add the 'clobber' when required. You do this by 16270 coding ('clobber' ('match_scratch' ...)). If you do clobber a 16271 pseudo register, use one which appears nowhere else--generate a new 16272 one each time. Otherwise, you may confuse CSE. 16273 16274 There is one other known use for clobbering a pseudo register in a 16275 'parallel': when one of the input operands of the insn is also 16276 clobbered by the insn. In this case, using the same pseudo 16277 register in the clobber and elsewhere in the insn produces the 16278 expected results. 16279 16280'(use X)' 16281 Represents the use of the value of X. It indicates that the value 16282 in X at this point in the program is needed, even though it may not 16283 be apparent why this is so. Therefore, the compiler will not 16284 attempt to delete previous instructions whose only effect is to 16285 store a value in X. X must be a 'reg' expression. 16286 16287 In some situations, it may be tempting to add a 'use' of a register 16288 in a 'parallel' to describe a situation where the value of a 16289 special register will modify the behavior of the instruction. A 16290 hypothetical example might be a pattern for an addition that can 16291 either wrap around or use saturating addition depending on the 16292 value of a special control register: 16293 16294 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 16295 (reg:SI 4)] 0)) 16296 (use (reg:SI 1))]) 16297 16298 16299 This will not work, several of the optimizers only look at 16300 expressions locally; it is very likely that if you have multiple 16301 insns with identical inputs to the 'unspec', they will be optimized 16302 away even if register 1 changes in between. 16303 16304 This means that 'use' can _only_ be used to describe that the 16305 register is live. You should think twice before adding 'use' 16306 statements, more often you will want to use 'unspec' instead. The 16307 'use' RTX is most commonly useful to describe that a fixed register 16308 is implicitly used in an insn. It is also safe to use in patterns 16309 where the compiler knows for other reasons that the result of the 16310 whole pattern is variable, such as 'movmemM' or 'call' patterns. 16311 16312 During the reload phase, an insn that has a 'use' as pattern can 16313 carry a reg_equal note. These 'use' insns will be deleted before 16314 the reload phase exits. 16315 16316 During the delayed branch scheduling phase, X may be an insn. This 16317 indicates that X previously was located at this place in the code 16318 and its data dependencies need to be taken into account. These 16319 'use' insns will be deleted before the delayed branch scheduling 16320 phase exits. 16321 16322'(parallel [X0 X1 ...])' 16323 Represents several side effects performed in parallel. The square 16324 brackets stand for a vector; the operand of 'parallel' is a vector 16325 of expressions. X0, X1 and so on are individual side effect 16326 expressions--expressions of code 'set', 'call', 'return', 16327 'simple_return', 'clobber' or 'use'. 16328 16329 "In parallel" means that first all the values used in the 16330 individual side-effects are computed, and second all the actual 16331 side-effects are performed. For example, 16332 16333 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 16334 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 16335 16336 says unambiguously that the values of hard register 1 and the 16337 memory location addressed by it are interchanged. In both places 16338 where '(reg:SI 1)' appears as a memory address it refers to the 16339 value in register 1 _before_ the execution of the insn. 16340 16341 It follows that it is _incorrect_ to use 'parallel' and expect the 16342 result of one 'set' to be available for the next one. For example, 16343 people sometimes attempt to represent a jump-if-zero instruction 16344 this way: 16345 16346 (parallel [(set (cc0) (reg:SI 34)) 16347 (set (pc) (if_then_else 16348 (eq (cc0) (const_int 0)) 16349 (label_ref ...) 16350 (pc)))]) 16351 16352 But this is incorrect, because it says that the jump condition 16353 depends on the condition code value _before_ this instruction, not 16354 on the new value that is set by this instruction. 16355 16356 Peephole optimization, which takes place together with final 16357 assembly code output, can produce insns whose patterns consist of a 16358 'parallel' whose elements are the operands needed to output the 16359 resulting assembler code--often 'reg', 'mem' or constant 16360 expressions. This would not be well-formed RTL at any other stage 16361 in compilation, but it is OK then because no further optimization 16362 remains to be done. However, the definition of the macro 16363 'NOTICE_UPDATE_CC', if any, must deal with such insns if you define 16364 any peephole optimizations. 16365 16366'(cond_exec [COND EXPR])' 16367 Represents a conditionally executed expression. The EXPR is 16368 executed only if the COND is nonzero. The COND expression must not 16369 have side-effects, but the EXPR may very well have side-effects. 16370 16371'(sequence [INSNS ...])' 16372 Represents a sequence of insns. If a 'sequence' appears in the 16373 chain of insns, then each of the INSNS that appears in the sequence 16374 must be suitable for appearing in the chain of insns, i.e. must 16375 satisfy the 'INSN_P' predicate. 16376 16377 After delay-slot scheduling is completed, an insn and all the insns 16378 that reside in its delay slots are grouped together into a 16379 'sequence'. The insn requiring the delay slot is the first insn in 16380 the vector; subsequent insns are to be placed in the delay slot. 16381 16382 'INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 16383 indicate that a branch insn should be used that will conditionally 16384 annul the effect of the insns in the delay slots. In such a case, 16385 'INSN_FROM_TARGET_P' indicates that the insn is from the target of 16386 the branch and should be executed only if the branch is taken; 16387 otherwise the insn should be executed only if the branch is not 16388 taken. *Note Delay Slots::. 16389 16390 Some back ends also use 'sequence' objects for purposes other than 16391 delay-slot groups. This is not supported in the common parts of 16392 the compiler, which treat such sequences as delay-slot groups. 16393 16394 DWARF2 Call Frame Address (CFA) adjustments are sometimes also 16395 expressed using 'sequence' objects as the value of a 16396 'RTX_FRAME_RELATED_P' note. This only happens if the CFA 16397 adjustments cannot be easily derived from the pattern of the 16398 instruction to which the note is attached. In such cases, the 16399 value of the note is used instead of best-guesing the semantics of 16400 the instruction. The back end can attach notes containing a 16401 'sequence' of 'set' patterns that express the effect of the parent 16402 instruction. 16403 16404 These expression codes appear in place of a side effect, as the body of 16405an insn, though strictly speaking they do not always describe side 16406effects as such: 16407 16408'(asm_input S)' 16409 Represents literal assembler code as described by the string S. 16410 16411'(unspec [OPERANDS ...] INDEX)' 16412'(unspec_volatile [OPERANDS ...] INDEX)' 16413 Represents a machine-specific operation on OPERANDS. INDEX selects 16414 between multiple machine-specific operations. 'unspec_volatile' is 16415 used for volatile operations and operations that may trap; 'unspec' 16416 is used for other operations. 16417 16418 These codes may appear inside a 'pattern' of an insn, inside a 16419 'parallel', or inside an expression. 16420 16421'(addr_vec:M [LR0 LR1 ...])' 16422 Represents a table of jump addresses. The vector elements LR0, 16423 etc., are 'label_ref' expressions. The mode M specifies how much 16424 space is given to each address; normally M would be 'Pmode'. 16425 16426'(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 16427 Represents a table of jump addresses expressed as offsets from 16428 BASE. The vector elements LR0, etc., are 'label_ref' expressions 16429 and so is BASE. The mode M specifies how much space is given to 16430 each address-difference. MIN and MAX are set up by branch 16431 shortening and hold a label with a minimum and a maximum address, 16432 respectively. FLAGS indicates the relative position of BASE, MIN 16433 and MAX to the containing insn and of MIN and MAX to BASE. See 16434 rtl.def for details. 16435 16436'(prefetch:M ADDR RW LOCALITY)' 16437 Represents prefetch of memory at address ADDR. Operand RW is 1 if 16438 the prefetch is for data to be written, 0 otherwise; targets that 16439 do not support write prefetches should treat this as a normal 16440 prefetch. Operand LOCALITY specifies the amount of temporal 16441 locality; 0 if there is none or 1, 2, or 3 for increasing levels of 16442 temporal locality; targets that do not support locality hints 16443 should ignore this. 16444 16445 This insn is used to minimize cache-miss latency by moving data 16446 into a cache before it is accessed. It should use only 16447 non-faulting data prefetch instructions. 16448 16449 16450File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 16451 1645213.16 Embedded Side-Effects on Addresses 16453======================================== 16454 16455Six special side-effect expression codes appear as memory addresses. 16456 16457'(pre_dec:M X)' 16458 Represents the side effect of decrementing X by a standard amount 16459 and represents also the value that X has after being decremented. 16460 X must be a 'reg' or 'mem', but most machines allow only a 'reg'. 16461 M must be the machine mode for pointers on the machine in use. The 16462 amount X is decremented by is the length in bytes of the machine 16463 mode of the containing memory reference of which this expression 16464 serves as the address. Here is an example of its use: 16465 16466 (mem:DF (pre_dec:SI (reg:SI 39))) 16467 16468 This says to decrement pseudo register 39 by the length of a 16469 'DFmode' value and use the result to address a 'DFmode' value. 16470 16471'(pre_inc:M X)' 16472 Similar, but specifies incrementing X instead of decrementing it. 16473 16474'(post_dec:M X)' 16475 Represents the same side effect as 'pre_dec' but a different value. 16476 The value represented here is the value X has before being 16477 decremented. 16478 16479'(post_inc:M X)' 16480 Similar, but specifies incrementing X instead of decrementing it. 16481 16482'(post_modify:M X Y)' 16483 16484 Represents the side effect of setting X to Y and represents X 16485 before X is modified. X must be a 'reg' or 'mem', but most 16486 machines allow only a 'reg'. M must be the machine mode for 16487 pointers on the machine in use. 16488 16489 The expression Y must be one of three forms: '(plus:M X Z)', 16490 '(minus:M X Z)', or '(plus:M X I)', where Z is an index register 16491 and I is a constant. 16492 16493 Here is an example of its use: 16494 16495 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 16496 (reg:SI 48)))) 16497 16498 This says to modify pseudo register 42 by adding the contents of 16499 pseudo register 48 to it, after the use of what ever 42 points to. 16500 16501'(pre_modify:M X EXPR)' 16502 Similar except side effects happen before the use. 16503 16504 These embedded side effect expressions must be used with care. 16505Instruction patterns may not use them. Until the 'flow' pass of the 16506compiler, they may occur only to represent pushes onto the stack. The 16507'flow' pass finds cases where registers are incremented or decremented 16508in one instruction and used as an address shortly before or after; these 16509cases are then transformed to use pre- or post-increment or -decrement. 16510 16511 If a register used as the operand of these expressions is used in 16512another address in an insn, the original value of the register is used. 16513Uses of the register outside of an address are not permitted within the 16514same insn as a use in an embedded side effect expression because such 16515insns behave differently on different machines and hence must be treated 16516as ambiguous and disallowed. 16517 16518 An instruction that can be represented with an embedded side effect 16519could also be represented using 'parallel' containing an additional 16520'set' to describe how the address register is altered. This is not done 16521because machines that allow these operations at all typically allow them 16522wherever a memory address is called for. Describing them as additional 16523parallel stores would require doubling the number of entries in the 16524machine description. 16525 16526 16527File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL 16528 1652913.17 Assembler Instructions as Expressions 16530=========================================== 16531 16532The RTX code 'asm_operands' represents a value produced by a 16533user-specified assembler instruction. It is used to represent an 'asm' 16534statement with arguments. An 'asm' statement with a single output 16535operand, like this: 16536 16537 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 16538 16539is represented using a single 'asm_operands' RTX which represents the 16540value that is stored in 'outputvar': 16541 16542 (set RTX-FOR-OUTPUTVAR 16543 (asm_operands "foo %1,%2,%0" "a" 0 16544 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 16545 [(asm_input:M1 "g") 16546 (asm_input:M2 "di")])) 16547 16548Here the operands of the 'asm_operands' RTX are the assembler template 16549string, the output-operand's constraint, the index-number of the output 16550operand among the output operands specified, a vector of input operand 16551RTX's, and a vector of input-operand modes and constraints. The mode M1 16552is the mode of the sum 'x+y'; M2 is that of '*z'. 16553 16554 When an 'asm' statement has multiple output values, its insn has 16555several such 'set' RTX's inside of a 'parallel'. Each 'set' contains an 16556'asm_operands'; all of these share the same assembler template and 16557vectors, but each contains the constraint for the respective output 16558operand. They are also distinguished by the output-operand index 16559number, which is 0, 1, ... for successive output operands. 16560 16561 16562File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL 16563 1656413.18 Variable Location Debug Information in RTL 16565================================================ 16566 16567Variable tracking relies on 'MEM_EXPR' and 'REG_EXPR' annotations to 16568determine what user variables memory and register references refer to. 16569 16570 Variable tracking at assignments uses these notes only when they refer 16571to variables that live at fixed locations (e.g., addressable variables, 16572global non-automatic variables). For variables whose location may vary, 16573it relies on the following types of notes. 16574 16575'(var_location:MODE VAR EXP STAT)' 16576 Binds variable 'var', a tree, to value EXP, an RTL expression. It 16577 appears only in 'NOTE_INSN_VAR_LOCATION' and 'DEBUG_INSN's, with 16578 slightly different meanings. MODE, if present, represents the mode 16579 of EXP, which is useful if it is a modeless expression. STAT is 16580 only meaningful in notes, indicating whether the variable is known 16581 to be initialized or uninitialized. 16582 16583'(debug_expr:MODE DECL)' 16584 Stands for the value bound to the 'DEBUG_EXPR_DECL' DECL, that 16585 points back to it, within value expressions in 'VAR_LOCATION' 16586 nodes. 16587 16588 16589File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL 16590 1659113.19 Insns 16592=========== 16593 16594The RTL representation of the code for a function is a doubly-linked 16595chain of objects called "insns". Insns are expressions with special 16596codes that are used for no other purpose. Some insns are actual 16597instructions; others represent dispatch tables for 'switch' statements; 16598others represent labels to jump to or various sorts of declarative 16599information. 16600 16601 In addition to its own specific data, each insn must have a unique 16602id-number that distinguishes it from all other insns in the current 16603function (after delayed branch scheduling, copies of an insn with the 16604same id-number may be present in multiple places in a function, but 16605these copies will always be identical and will only appear inside a 16606'sequence'), and chain pointers to the preceding and following insns. 16607These three fields occupy the same position in every insn, independent 16608of the expression code of the insn. They could be accessed with 'XEXP' 16609and 'XINT', but instead three special macros are always used: 16610 16611'INSN_UID (I)' 16612 Accesses the unique id of insn I. 16613 16614'PREV_INSN (I)' 16615 Accesses the chain pointer to the insn preceding I. If I is the 16616 first insn, this is a null pointer. 16617 16618'NEXT_INSN (I)' 16619 Accesses the chain pointer to the insn following I. If I is the 16620 last insn, this is a null pointer. 16621 16622 The first insn in the chain is obtained by calling 'get_insns'; the 16623last insn is the result of calling 'get_last_insn'. Within the chain 16624delimited by these insns, the 'NEXT_INSN' and 'PREV_INSN' pointers must 16625always correspond: if INSN is not the first insn, 16626 16627 NEXT_INSN (PREV_INSN (INSN)) == INSN 16628 16629is always true and if INSN is not the last insn, 16630 16631 PREV_INSN (NEXT_INSN (INSN)) == INSN 16632 16633is always true. 16634 16635 After delay slot scheduling, some of the insns in the chain might be 16636'sequence' expressions, which contain a vector of insns. The value of 16637'NEXT_INSN' in all but the last of these insns is the next insn in the 16638vector; the value of 'NEXT_INSN' of the last insn in the vector is the 16639same as the value of 'NEXT_INSN' for the 'sequence' in which it is 16640contained. Similar rules apply for 'PREV_INSN'. 16641 16642 This means that the above invariants are not necessarily true for insns 16643inside 'sequence' expressions. Specifically, if INSN is the first insn 16644in a 'sequence', 'NEXT_INSN (PREV_INSN (INSN))' is the insn containing 16645the 'sequence' expression, as is the value of 'PREV_INSN (NEXT_INSN 16646(INSN))' if INSN is the last insn in the 'sequence' expression. You can 16647use these expressions to find the containing 'sequence' expression. 16648 16649 Every insn has one of the following expression codes: 16650 16651'insn' 16652 The expression code 'insn' is used for instructions that do not 16653 jump and do not do function calls. 'sequence' expressions are 16654 always contained in insns with code 'insn' even if one of those 16655 insns should jump or do function calls. 16656 16657 Insns with code 'insn' have four additional fields beyond the three 16658 mandatory ones listed above. These four are described in a table 16659 below. 16660 16661'jump_insn' 16662 The expression code 'jump_insn' is used for instructions that may 16663 jump (or, more generally, may contain 'label_ref' expressions to 16664 which 'pc' can be set in that instruction). If there is an 16665 instruction to return from the current function, it is recorded as 16666 a 'jump_insn'. 16667 16668 'jump_insn' insns have the same extra fields as 'insn' insns, 16669 accessed in the same way and in addition contain a field 16670 'JUMP_LABEL' which is defined once jump optimization has completed. 16671 16672 For simple conditional and unconditional jumps, this field contains 16673 the 'code_label' to which this insn will (possibly conditionally) 16674 branch. In a more complex jump, 'JUMP_LABEL' records one of the 16675 labels that the insn refers to; other jump target labels are 16676 recorded as 'REG_LABEL_TARGET' notes. The exception is 'addr_vec' 16677 and 'addr_diff_vec', where 'JUMP_LABEL' is 'NULL_RTX' and the only 16678 way to find the labels is to scan the entire body of the insn. 16679 16680 Return insns count as jumps, but their 'JUMP_LABEL' is 'RETURN' or 16681 'SIMPLE_RETURN'. 16682 16683'call_insn' 16684 The expression code 'call_insn' is used for instructions that may 16685 do function calls. It is important to distinguish these 16686 instructions because they imply that certain registers and memory 16687 locations may be altered unpredictably. 16688 16689 'call_insn' insns have the same extra fields as 'insn' insns, 16690 accessed in the same way and in addition contain a field 16691 'CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 16692 'expr_list' expressions) containing 'use', 'clobber' and sometimes 16693 'set' expressions that denote hard registers and 'mem's used or 16694 clobbered by the called function. 16695 16696 A 'mem' generally points to a stack slot in which arguments passed 16697 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 16698 Register Arguments.) are stored. If the argument is caller-copied 16699 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 16700 will be mentioned in 'clobber' and 'use' entries; if it's 16701 callee-copied, only a 'use' will appear, and the 'mem' may point to 16702 addresses that are not stack slots. 16703 16704 Registers occurring inside a 'clobber' in this list augment 16705 registers specified in 'CALL_USED_REGISTERS' (*note Register 16706 Basics::). 16707 16708 If the list contains a 'set' involving two registers, it indicates 16709 that the function returns one of its arguments. Such a 'set' may 16710 look like a no-op if the same register holds the argument and the 16711 return value. 16712 16713'code_label' 16714 A 'code_label' insn represents a label that a jump insn can jump 16715 to. It contains two special fields of data in addition to the 16716 three standard ones. 'CODE_LABEL_NUMBER' is used to hold the 16717 "label number", a number that identifies this label uniquely among 16718 all the labels in the compilation (not just in the current 16719 function). Ultimately, the label is represented in the assembler 16720 output as an assembler label, usually of the form 'LN' where N is 16721 the label number. 16722 16723 When a 'code_label' appears in an RTL expression, it normally 16724 appears within a 'label_ref' which represents the address of the 16725 label, as a number. 16726 16727 Besides as a 'code_label', a label can also be represented as a 16728 'note' of type 'NOTE_INSN_DELETED_LABEL'. 16729 16730 The field 'LABEL_NUSES' is only defined once the jump optimization 16731 phase is completed. It contains the number of times this label is 16732 referenced in the current function. 16733 16734 The field 'LABEL_KIND' differentiates four different types of 16735 labels: 'LABEL_NORMAL', 'LABEL_STATIC_ENTRY', 'LABEL_GLOBAL_ENTRY', 16736 and 'LABEL_WEAK_ENTRY'. The only labels that do not have type 16737 'LABEL_NORMAL' are "alternate entry points" to the current 16738 function. These may be static (visible only in the containing 16739 translation unit), global (exposed to all translation units), or 16740 weak (global, but can be overridden by another symbol with the same 16741 name). 16742 16743 Much of the compiler treats all four kinds of label identically. 16744 Some of it needs to know whether or not a label is an alternate 16745 entry point; for this purpose, the macro 'LABEL_ALT_ENTRY_P' is 16746 provided. It is equivalent to testing whether 'LABEL_KIND (label) 16747 == LABEL_NORMAL'. The only place that cares about the distinction 16748 between static, global, and weak alternate entry points, besides 16749 the front-end code that creates them, is the function 16750 'output_alternate_entry_point', in 'final.c'. 16751 16752 To set the kind of a label, use the 'SET_LABEL_KIND' macro. 16753 16754'jump_table_data' 16755 A 'jump_table_data' insn is a placeholder for the jump-table data 16756 of a 'casesi' or 'tablejump' insn. They are placed after a 16757 'tablejump_p' insn. A 'jump_table_data' insn is not part o a basic 16758 blockm but it is associated with the basic block that ends with the 16759 'tablejump_p' insn. The 'PATTERN' of a 'jump_table_data' is always 16760 either an 'addr_vec' or an 'addr_diff_vec', and a 'jump_table_data' 16761 insn is always preceded by a 'code_label'. The 'tablejump_p' insn 16762 refers to that 'code_label' via its 'JUMP_LABEL'. 16763 16764'barrier' 16765 Barriers are placed in the instruction stream when control cannot 16766 flow past them. They are placed after unconditional jump 16767 instructions to indicate that the jumps are unconditional and after 16768 calls to 'volatile' functions, which do not return (e.g., 'exit'). 16769 They contain no information beyond the three standard fields. 16770 16771'note' 16772 'note' insns are used to represent additional debugging and 16773 declarative information. They contain two nonstandard fields, an 16774 integer which is accessed with the macro 'NOTE_LINE_NUMBER' and a 16775 string accessed with 'NOTE_SOURCE_FILE'. 16776 16777 If 'NOTE_LINE_NUMBER' is positive, the note represents the position 16778 of a source line and 'NOTE_SOURCE_FILE' is the source file name 16779 that the line came from. These notes control generation of line 16780 number data in the assembler output. 16781 16782 Otherwise, 'NOTE_LINE_NUMBER' is not really a line number but a 16783 code with one of the following values (and 'NOTE_SOURCE_FILE' must 16784 contain a null pointer): 16785 16786 'NOTE_INSN_DELETED' 16787 Such a note is completely ignorable. Some passes of the 16788 compiler delete insns by altering them into notes of this 16789 kind. 16790 16791 'NOTE_INSN_DELETED_LABEL' 16792 This marks what used to be a 'code_label', but was not used 16793 for other purposes than taking its address and was transformed 16794 to mark that no code jumps to it. 16795 16796 'NOTE_INSN_BLOCK_BEG' 16797 'NOTE_INSN_BLOCK_END' 16798 These types of notes indicate the position of the beginning 16799 and end of a level of scoping of variable names. They control 16800 the output of debugging information. 16801 16802 'NOTE_INSN_EH_REGION_BEG' 16803 'NOTE_INSN_EH_REGION_END' 16804 These types of notes indicate the position of the beginning 16805 and end of a level of scoping for exception handling. 16806 'NOTE_EH_HANDLER' identifies which region is associated with 16807 these notes. 16808 16809 'NOTE_INSN_FUNCTION_BEG' 16810 Appears at the start of the function body, after the function 16811 prologue. 16812 16813 'NOTE_INSN_VAR_LOCATION' 16814 This note is used to generate variable location debugging 16815 information. It indicates that the user variable in its 16816 'VAR_LOCATION' operand is at the location given in the RTL 16817 expression, or holds a value that can be computed by 16818 evaluating the RTL expression from that static point in the 16819 program up to the next such note for the same user variable. 16820 16821 These codes are printed symbolically when they appear in debugging 16822 dumps. 16823 16824'debug_insn' 16825 The expression code 'debug_insn' is used for pseudo-instructions 16826 that hold debugging information for variable tracking at 16827 assignments (see '-fvar-tracking-assignments' option). They are 16828 the RTL representation of 'GIMPLE_DEBUG' statements (*note 16829 GIMPLE_DEBUG::), with a 'VAR_LOCATION' operand that binds a user 16830 variable tree to an RTL representation of the 'value' in the 16831 corresponding statement. A 'DEBUG_EXPR' in it stands for the value 16832 bound to the corresponding 'DEBUG_EXPR_DECL'. 16833 16834 Throughout optimization passes, binding information is kept in 16835 pseudo-instruction form, so that, unlike notes, it gets the same 16836 treatment and adjustments that regular instructions would. It is 16837 the variable tracking pass that turns these pseudo-instructions 16838 into var location notes, analyzing control flow, value equivalences 16839 and changes to registers and memory referenced in value 16840 expressions, propagating the values of debug temporaries and 16841 determining expressions that can be used to compute the value of 16842 each user variable at as many points (ranges, actually) in the 16843 program as possible. 16844 16845 Unlike 'NOTE_INSN_VAR_LOCATION', the value expression in an 16846 'INSN_VAR_LOCATION' denotes a value at that specific point in the 16847 program, rather than an expression that can be evaluated at any 16848 later point before an overriding 'VAR_LOCATION' is encountered. 16849 E.g., if a user variable is bound to a 'REG' and then a subsequent 16850 insn modifies the 'REG', the note location would keep mapping the 16851 user variable to the register across the insn, whereas the insn 16852 location would keep the variable bound to the value, so that the 16853 variable tracking pass would emit another location note for the 16854 variable at the point in which the register is modified. 16855 16856 The machine mode of an insn is normally 'VOIDmode', but some phases use 16857the mode for various purposes. 16858 16859 The common subexpression elimination pass sets the mode of an insn to 16860'QImode' when it is the first insn in a block that has already been 16861processed. 16862 16863 The second Haifa scheduling pass, for targets that can multiple issue, 16864sets the mode of an insn to 'TImode' when it is believed that the 16865instruction begins an issue group. That is, when the instruction cannot 16866issue simultaneously with the previous. This may be relied on by later 16867passes, in particular machine-dependent reorg. 16868 16869 Here is a table of the extra fields of 'insn', 'jump_insn' and 16870'call_insn' insns: 16871 16872'PATTERN (I)' 16873 An expression for the side effect performed by this insn. This 16874 must be one of the following codes: 'set', 'call', 'use', 16875 'clobber', 'return', 'simple_return', 'asm_input', 'asm_output', 16876 'addr_vec', 'addr_diff_vec', 'trap_if', 'unspec', 16877 'unspec_volatile', 'parallel', 'cond_exec', or 'sequence'. If it 16878 is a 'parallel', each element of the 'parallel' must be one these 16879 codes, except that 'parallel' expressions cannot be nested and 16880 'addr_vec' and 'addr_diff_vec' are not permitted inside a 16881 'parallel' expression. 16882 16883'INSN_CODE (I)' 16884 An integer that says which pattern in the machine description 16885 matches this insn, or -1 if the matching has not yet been 16886 attempted. 16887 16888 Such matching is never attempted and this field remains -1 on an 16889 insn whose pattern consists of a single 'use', 'clobber', 16890 'asm_input', 'addr_vec' or 'addr_diff_vec' expression. 16891 16892 Matching is also never attempted on insns that result from an 'asm' 16893 statement. These contain at least one 'asm_operands' expression. 16894 The function 'asm_noperands' returns a non-negative value for such 16895 insns. 16896 16897 In the debugging output, this field is printed as a number followed 16898 by a symbolic representation that locates the pattern in the 'md' 16899 file as some small positive or negative offset from a named 16900 pattern. 16901 16902'LOG_LINKS (I)' 16903 A list (chain of 'insn_list' expressions) giving information about 16904 dependencies between instructions within a basic block. Neither a 16905 jump nor a label may come between the related insns. These are 16906 only used by the schedulers and by combine. This is a deprecated 16907 data structure. Def-use and use-def chains are now preferred. 16908 16909'REG_NOTES (I)' 16910 A list (chain of 'expr_list', 'insn_list' and 'int_list' 16911 expressions) giving miscellaneous information about the insn. It 16912 is often information pertaining to the registers used in this insn. 16913 16914 The 'LOG_LINKS' field of an insn is a chain of 'insn_list' expressions. 16915Each of these has two operands: the first is an insn, and the second is 16916another 'insn_list' expression (the next one in the chain). The last 16917'insn_list' in the chain has a null pointer as second operand. The 16918significant thing about the chain is which insns appear in it (as first 16919operands of 'insn_list' expressions). Their order is not significant. 16920 16921 This list is originally set up by the flow analysis pass; it is a null 16922pointer until then. Flow only adds links for those data dependencies 16923which can be used for instruction combination. For each insn, the flow 16924analysis pass adds a link to insns which store into registers values 16925that are used for the first time in this insn. 16926 16927 The 'REG_NOTES' field of an insn is a chain similar to the 'LOG_LINKS' 16928field but it includes 'expr_list' and 'int_list' expressions in addition 16929to 'insn_list' expressions. There are several kinds of register notes, 16930which are distinguished by the machine mode, which in a register note is 16931really understood as being an 'enum reg_note'. The first operand OP of 16932the note is data whose meaning depends on the kind of note. 16933 16934 The macro 'REG_NOTE_KIND (X)' returns the kind of register note. Its 16935counterpart, the macro 'PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 16936register note type of X to be NEWKIND. 16937 16938 Register notes are of three classes: They may say something about an 16939input to an insn, they may say something about an output of an insn, or 16940they may create a linkage between two insns. There are also a set of 16941values that are only used in 'LOG_LINKS'. 16942 16943 These register notes annotate inputs to an insn: 16944 16945'REG_DEAD' 16946 The value in OP dies in this insn; that is to say, altering the 16947 value immediately after this insn would not affect the future 16948 behavior of the program. 16949 16950 It does not follow that the register OP has no useful value after 16951 this insn since OP is not necessarily modified by this insn. 16952 Rather, no subsequent instruction uses the contents of OP. 16953 16954'REG_UNUSED' 16955 The register OP being set by this insn will not be used in a 16956 subsequent insn. This differs from a 'REG_DEAD' note, which 16957 indicates that the value in an input will not be used subsequently. 16958 These two notes are independent; both may be present for the same 16959 register. 16960 16961'REG_INC' 16962 The register OP is incremented (or decremented; at this level there 16963 is no distinction) by an embedded side effect inside this insn. 16964 This means it appears in a 'post_inc', 'pre_inc', 'post_dec' or 16965 'pre_dec' expression. 16966 16967'REG_NONNEG' 16968 The register OP is known to have a nonnegative value when this insn 16969 is reached. This is used so that decrement and branch until zero 16970 instructions, such as the m68k dbra, can be matched. 16971 16972 The 'REG_NONNEG' note is added to insns only if the machine 16973 description has a 'decrement_and_branch_until_zero' pattern. 16974 16975'REG_LABEL_OPERAND' 16976 This insn uses OP, a 'code_label' or a 'note' of type 16977 'NOTE_INSN_DELETED_LABEL', but is not a 'jump_insn', or it is a 16978 'jump_insn' that refers to the operand as an ordinary operand. The 16979 label may still eventually be a jump target, but if so in an 16980 indirect jump in a subsequent insn. The presence of this note 16981 allows jump optimization to be aware that OP is, in fact, being 16982 used, and flow optimization to build an accurate flow graph. 16983 16984'REG_LABEL_TARGET' 16985 This insn is a 'jump_insn' but not an 'addr_vec' or 16986 'addr_diff_vec'. It uses OP, a 'code_label' as a direct or 16987 indirect jump target. Its purpose is similar to that of 16988 'REG_LABEL_OPERAND'. This note is only present if the insn has 16989 multiple targets; the last label in the insn (in the highest 16990 numbered insn-field) goes into the 'JUMP_LABEL' field and does not 16991 have a 'REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns. 16992 16993'REG_CROSSING_JUMP' 16994 This insn is a branching instruction (either an unconditional jump 16995 or an indirect jump) which crosses between hot and cold sections, 16996 which could potentially be very far apart in the executable. The 16997 presence of this note indicates to other optimizations that this 16998 branching instruction should not be "collapsed" into a simpler 16999 branching construct. It is used when the optimization to partition 17000 basic blocks into hot and cold sections is turned on. 17001 17002'REG_SETJMP' 17003 Appears attached to each 'CALL_INSN' to 'setjmp' or a related 17004 function. 17005 17006 The following notes describe attributes of outputs of an insn: 17007 17008'REG_EQUIV' 17009'REG_EQUAL' 17010 This note is only valid on an insn that sets only one register and 17011 indicates that that register will be equal to OP at run time; the 17012 scope of this equivalence differs between the two types of notes. 17013 The value which the insn explicitly copies into the register may 17014 look different from OP, but they will be equal at run time. If the 17015 output of the single 'set' is a 'strict_low_part' or 'zero_extract' 17016 expression, the note refers to the register that is contained in 17017 its first operand. 17018 17019 For 'REG_EQUIV', the register is equivalent to OP throughout the 17020 entire function, and could validly be replaced in all its 17021 occurrences by OP. ("Validly" here refers to the data flow of the 17022 program; simple replacement may make some insns invalid.) For 17023 example, when a constant is loaded into a register that is never 17024 assigned any other value, this kind of note is used. 17025 17026 When a parameter is copied into a pseudo-register at entry to a 17027 function, a note of this kind records that the register is 17028 equivalent to the stack slot where the parameter was passed. 17029 Although in this case the register may be set by other insns, it is 17030 still valid to replace the register by the stack slot throughout 17031 the function. 17032 17033 A 'REG_EQUIV' note is also used on an instruction which copies a 17034 register parameter into a pseudo-register at entry to a function, 17035 if there is a stack slot where that parameter could be stored. 17036 Although other insns may set the pseudo-register, it is valid for 17037 the compiler to replace the pseudo-register by stack slot 17038 throughout the function, provided the compiler ensures that the 17039 stack slot is properly initialized by making the replacement in the 17040 initial copy instruction as well. This is used on machines for 17041 which the calling convention allocates stack space for register 17042 parameters. See 'REG_PARM_STACK_SPACE' in *note Stack Arguments::. 17043 17044 In the case of 'REG_EQUAL', the register that is set by this insn 17045 will be equal to OP at run time at the end of this insn but not 17046 necessarily elsewhere in the function. In this case, OP is 17047 typically an arithmetic expression. For example, when a sequence 17048 of insns such as a library call is used to perform an arithmetic 17049 operation, this kind of note is attached to the insn that produces 17050 or copies the final value. 17051 17052 These two notes are used in different ways by the compiler passes. 17053 'REG_EQUAL' is used by passes prior to register allocation (such as 17054 common subexpression elimination and loop optimization) to tell 17055 them how to think of that value. 'REG_EQUIV' notes are used by 17056 register allocation to indicate that there is an available 17057 substitute expression (either a constant or a 'mem' expression for 17058 the location of a parameter on the stack) that may be used in place 17059 of a register if insufficient registers are available. 17060 17061 Except for stack homes for parameters, which are indicated by a 17062 'REG_EQUIV' note and are not useful to the early optimization 17063 passes and pseudo registers that are equivalent to a memory 17064 location throughout their entire life, which is not detected until 17065 later in the compilation, all equivalences are initially indicated 17066 by an attached 'REG_EQUAL' note. In the early stages of register 17067 allocation, a 'REG_EQUAL' note is changed into a 'REG_EQUIV' note 17068 if OP is a constant and the insn represents the only set of its 17069 destination register. 17070 17071 Thus, compiler passes prior to register allocation need only check 17072 for 'REG_EQUAL' notes and passes subsequent to register allocation 17073 need only check for 'REG_EQUIV' notes. 17074 17075 These notes describe linkages between insns. They occur in pairs: one 17076insn has one of a pair of notes that points to a second insn, which has 17077the inverse note pointing back to the first insn. 17078 17079'REG_CC_SETTER' 17080'REG_CC_USER' 17081 On machines that use 'cc0', the insns which set and use 'cc0' set 17082 and use 'cc0' are adjacent. However, when branch delay slot 17083 filling is done, this may no longer be true. In this case a 17084 'REG_CC_USER' note will be placed on the insn setting 'cc0' to 17085 point to the insn using 'cc0' and a 'REG_CC_SETTER' note will be 17086 placed on the insn using 'cc0' to point to the insn setting 'cc0'. 17087 17088 These values are only used in the 'LOG_LINKS' field, and indicate the 17089type of dependency that each link represents. Links which indicate a 17090data dependence (a read after write dependence) do not use any code, 17091they simply have mode 'VOIDmode', and are printed without any 17092descriptive text. 17093 17094'REG_DEP_TRUE' 17095 This indicates a true dependence (a read after write dependence). 17096 17097'REG_DEP_OUTPUT' 17098 This indicates an output dependence (a write after write 17099 dependence). 17100 17101'REG_DEP_ANTI' 17102 This indicates an anti dependence (a write after read dependence). 17103 17104 These notes describe information gathered from gcov profile data. They 17105are stored in the 'REG_NOTES' field of an insn. 17106 17107'REG_BR_PROB' 17108 This is used to specify the ratio of branches to non-branches of a 17109 branch insn according to the profile data. The note is represented 17110 as an 'int_list' expression whose integer value is between 0 and 17111 REG_BR_PROB_BASE. Larger values indicate a higher probability that 17112 the branch will be taken. 17113 17114'REG_BR_PRED' 17115 These notes are found in JUMP insns after delayed branch scheduling 17116 has taken place. They indicate both the direction and the 17117 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 17118 values. 17119 17120'REG_FRAME_RELATED_EXPR' 17121 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 17122 expression is used in place of the actual insn pattern. This is 17123 done in cases where the pattern is either complex or misleading. 17124 17125 For convenience, the machine mode in an 'insn_list' or 'expr_list' is 17126printed using these symbolic codes in debugging dumps. 17127 17128 The only difference between the expression codes 'insn_list' and 17129'expr_list' is that the first operand of an 'insn_list' is assumed to be 17130an insn and is printed in debugging dumps as the insn's unique id; the 17131first operand of an 'expr_list' is printed in the ordinary way as an 17132expression. 17133 17134 17135File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 17136 1713713.20 RTL Representation of Function-Call Insns 17138=============================================== 17139 17140Insns that call subroutines have the RTL expression code 'call_insn'. 17141These insns must satisfy special rules, and their bodies must use a 17142special RTL expression code, 'call'. 17143 17144 A 'call' expression has two operands, as follows: 17145 17146 (call (mem:FM ADDR) NBYTES) 17147 17148Here NBYTES is an operand that represents the number of bytes of 17149argument data being passed to the subroutine, FM is a machine mode 17150(which must equal as the definition of the 'FUNCTION_MODE' macro in the 17151machine description) and ADDR represents the address of the subroutine. 17152 17153 For a subroutine that returns no value, the 'call' expression as shown 17154above is the entire body of the insn, except that the insn might also 17155contain 'use' or 'clobber' expressions. 17156 17157 For a subroutine that returns a value whose mode is not 'BLKmode', the 17158value is returned in a hard register. If this register's number is R, 17159then the body of the call insn looks like this: 17160 17161 (set (reg:M R) 17162 (call (mem:FM ADDR) NBYTES)) 17163 17164This RTL expression makes it clear (to the optimizer passes) that the 17165appropriate register receives a useful value in this insn. 17166 17167 When a subroutine returns a 'BLKmode' value, it is handled by passing 17168to the subroutine the address of a place to store the value. So the 17169call insn itself does not "return" any value, and it has the same RTL 17170form as a call that returns nothing. 17171 17172 On some machines, the call instruction itself clobbers some register, 17173for example to contain the return address. 'call_insn' insns on these 17174machines should have a body which is a 'parallel' that contains both the 17175'call' expression and 'clobber' expressions that indicate which 17176registers are destroyed. Similarly, if the call instruction requires 17177some register other than the stack pointer that is not explicitly 17178mentioned in its RTL, a 'use' subexpression should mention that 17179register. 17180 17181 Functions that are called are assumed to modify all registers listed in 17182the configuration macro 'CALL_USED_REGISTERS' (*note Register Basics::) 17183and, with the exception of 'const' functions and library calls, to 17184modify all of memory. 17185 17186 Insns containing just 'use' expressions directly precede the 17187'call_insn' insn to indicate which registers contain inputs to the 17188function. Similarly, if registers other than those in 17189'CALL_USED_REGISTERS' are clobbered by the called function, insns 17190containing a single 'clobber' follow immediately after the call to 17191indicate which registers. 17192 17193 17194File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 17195 1719613.21 Structure Sharing Assumptions 17197=================================== 17198 17199The compiler assumes that certain kinds of RTL expressions are unique; 17200there do not exist two distinct objects representing the same value. In 17201other cases, it makes an opposite assumption: that no RTL expression 17202object of a certain kind appears in more than one place in the 17203containing structure. 17204 17205 These assumptions refer to a single function; except for the RTL 17206objects that describe global variables and external functions, and a few 17207standard objects such as small integer constants, no RTL objects are 17208common to two functions. 17209 17210 * Each pseudo-register has only a single 'reg' object to represent 17211 it, and therefore only a single machine mode. 17212 17213 * For any symbolic label, there is only one 'symbol_ref' object 17214 referring to it. 17215 17216 * All 'const_int' expressions with equal values are shared. 17217 17218 * There is only one 'pc' expression. 17219 17220 * There is only one 'cc0' expression. 17221 17222 * There is only one 'const_double' expression with value 0 for each 17223 floating point mode. Likewise for values 1 and 2. 17224 17225 * There is only one 'const_vector' expression with value 0 for each 17226 vector mode, be it an integer or a double constant vector. 17227 17228 * No 'label_ref' or 'scratch' appears in more than one place in the 17229 RTL structure; in other words, it is safe to do a tree-walk of all 17230 the insns in the function and assume that each time a 'label_ref' 17231 or 'scratch' is seen it is distinct from all others that are seen. 17232 17233 * Only one 'mem' object is normally created for each static variable 17234 or stack slot, so these objects are frequently shared in all the 17235 places they appear. However, separate but equal objects for these 17236 variables are occasionally made. 17237 17238 * When a single 'asm' statement has multiple output operands, a 17239 distinct 'asm_operands' expression is made for each output operand. 17240 However, these all share the vector which contains the sequence of 17241 input operands. This sharing is used later on to test whether two 17242 'asm_operands' expressions come from the same statement, so all 17243 optimizations must carefully preserve the sharing if they copy the 17244 vector at all. 17245 17246 * No RTL object appears in more than one place in the RTL structure 17247 except as described above. Many passes of the compiler rely on 17248 this by assuming that they can modify RTL objects in place without 17249 unwanted side-effects on other insns. 17250 17251 * During initial RTL generation, shared structure is freely 17252 introduced. After all the RTL for a function has been generated, 17253 all shared structure is copied by 'unshare_all_rtl' in 17254 'emit-rtl.c', after which the above rules are guaranteed to be 17255 followed. 17256 17257 * During the combiner pass, shared structure within an insn can exist 17258 temporarily. However, the shared structure is copied before the 17259 combiner is finished with the insn. This is done by calling 17260 'copy_rtx_if_shared', which is a subroutine of 'unshare_all_rtl'. 17261 17262 17263File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 17264 1726513.22 Reading RTL 17266================= 17267 17268To read an RTL object from a file, call 'read_rtx'. It takes one 17269argument, a stdio stream, and returns a single RTL object. This routine 17270is defined in 'read-rtl.c'. It is not available in the compiler itself, 17271only the various programs that generate the compiler back end from the 17272machine description. 17273 17274 People frequently have the idea of using RTL stored as text in a file 17275as an interface between a language front end and the bulk of GCC. This 17276idea is not feasible. 17277 17278 GCC was designed to use RTL internally only. Correct RTL for a given 17279program is very dependent on the particular target machine. And the RTL 17280does not contain all the information about the program. 17281 17282 The proper way to interface GCC to a new language front end is with the 17283"tree" data structure, described in the files 'tree.h' and 'tree.def'. 17284The documentation for this structure (*note GENERIC::) is incomplete. 17285 17286 17287File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top 17288 1728914 Control Flow Graph 17290********************* 17291 17292A control flow graph (CFG) is a data structure built on top of the 17293intermediate code representation (the RTL or 'GIMPLE' instruction 17294stream) abstracting the control flow behavior of a function that is 17295being compiled. The CFG is a directed graph where the vertices 17296represent basic blocks and edges represent possible transfer of control 17297flow from one basic block to another. The data structures used to 17298represent the control flow graph are defined in 'basic-block.h'. 17299 17300 In GCC, the representation of control flow is maintained throughout the 17301compilation process, from constructing the CFG early in 'pass_build_cfg' 17302to 'pass_free_cfg' (see 'passes.def'). The CFG takes various different 17303modes and may undergo extensive manipulations, but the graph is always 17304valid between its construction and its release. This way, transfer of 17305information such as data flow, a measured profile, or the loop tree, can 17306be propagated through the passes pipeline, and even from 'GIMPLE' to 17307'RTL'. 17308 17309 Often the CFG may be better viewed as integral part of instruction 17310chain, than structure built on the top of it. Updating the compiler's 17311intermediate representation for instructions can not be easily done 17312without proper maintenance of the CFG simultaneously. 17313 17314* Menu: 17315 17316* Basic Blocks:: The definition and representation of basic blocks. 17317* Edges:: Types of edges and their representation. 17318* Profile information:: Representation of frequencies and probabilities. 17319* Maintaining the CFG:: Keeping the control flow graph and up to date. 17320* Liveness information:: Using and maintaining liveness information. 17321 17322 17323File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 17324 1732514.1 Basic Blocks 17326================= 17327 17328A basic block is a straight-line sequence of code with only one entry 17329point and only one exit. In GCC, basic blocks are represented using the 17330'basic_block' data type. 17331 17332 Special basic blocks represent possible entry and exit points of a 17333function. These blocks are called 'ENTRY_BLOCK_PTR' and 17334'EXIT_BLOCK_PTR'. These blocks do not contain any code. 17335 17336 The 'BASIC_BLOCK' array contains all basic blocks in an unspecified 17337order. Each 'basic_block' structure has a field that holds a unique 17338integer identifier 'index' that is the index of the block in the 17339'BASIC_BLOCK' array. The total number of basic blocks in the function 17340is 'n_basic_blocks'. Both the basic block indices and the total number 17341of basic blocks may vary during the compilation process, as passes 17342reorder, create, duplicate, and destroy basic blocks. The index for any 17343block should never be greater than 'last_basic_block'. The indices 0 17344and 1 are special codes reserved for 'ENTRY_BLOCK' and 'EXIT_BLOCK', the 17345indices of 'ENTRY_BLOCK_PTR' and 'EXIT_BLOCK_PTR'. 17346 17347 Two pointer members of the 'basic_block' structure are the pointers 17348'next_bb' and 'prev_bb'. These are used to keep doubly linked chain of 17349basic blocks in the same order as the underlying instruction stream. 17350The chain of basic blocks is updated transparently by the provided API 17351for manipulating the CFG. The macro 'FOR_EACH_BB' can be used to visit 17352all the basic blocks in lexicographical order, except 'ENTRY_BLOCK' and 17353'EXIT_BLOCK'. The macro 'FOR_ALL_BB' also visits all basic blocks in 17354lexicographical order, including 'ENTRY_BLOCK' and 'EXIT_BLOCK'. 17355 17356 The functions 'post_order_compute' and 'inverted_post_order_compute' 17357can be used to compute topological orders of the CFG. The orders are 17358stored as vectors of basic block indices. The 'BASIC_BLOCK' array can 17359be used to iterate each basic block by index. Dominator traversals are 17360also possible using 'walk_dominator_tree'. Given two basic blocks A and 17361B, block A dominates block B if A is _always_ executed before B. 17362 17363 Each 'basic_block' also contains pointers to the first instruction (the 17364"head") and the last instruction (the "tail") or "end" of the 17365instruction stream contained in a basic block. In fact, since the 17366'basic_block' data type is used to represent blocks in both major 17367intermediate representations of GCC ('GIMPLE' and RTL), there are 17368pointers to the head and end of a basic block for both representations, 17369stored in intermediate representation specific data in the 'il' field of 17370'struct basic_block_def'. 17371 17372 For RTL, these pointers are 'BB_HEAD' and 'BB_END'. 17373 17374 In the RTL representation of a function, the instruction stream 17375contains not only the "real" instructions, but also "notes" or "insn 17376notes" (to distinguish them from "reg notes"). Any function that moves 17377or duplicates the basic blocks needs to take care of updating of these 17378notes. Many of these notes expect that the instruction stream consists 17379of linear regions, so updating can sometimes be tedious. All types of 17380insn notes are defined in 'insn-notes.def'. 17381 17382 In the RTL function representation, the instructions contained in a 17383basic block always follow a 'NOTE_INSN_BASIC_BLOCK', but zero or more 17384'CODE_LABEL' nodes can precede the block note. A basic block ends with 17385a control flow instruction or with the last instruction before the next 17386'CODE_LABEL' or 'NOTE_INSN_BASIC_BLOCK'. By definition, a 'CODE_LABEL' 17387cannot appear in the middle of the instruction stream of a basic block. 17388 17389 In addition to notes, the jump table vectors are also represented as 17390"pseudo-instructions" inside the insn stream. These vectors never 17391appear in the basic block and should always be placed just after the 17392table jump instructions referencing them. After removing the table-jump 17393it is often difficult to eliminate the code computing the address and 17394referencing the vector, so cleaning up these vectors is postponed until 17395after liveness analysis. Thus the jump table vectors may appear in the 17396insn stream unreferenced and without any purpose. Before any edge is 17397made "fall-thru", the existence of such construct in the way needs to be 17398checked by calling 'can_fallthru' function. 17399 17400 For the 'GIMPLE' representation, the PHI nodes and statements contained 17401in a basic block are in a 'gimple_seq' pointed to by the basic block 17402intermediate language specific pointers. Abstract containers and 17403iterators are used to access the PHI nodes and statements in a basic 17404blocks. These iterators are called "GIMPLE statement iterators" (GSIs). 17405Grep for '^gsi' in the various 'gimple-*' and 'tree-*' files. There is 17406a 'gimple_stmt_iterator' type for iterating over all kinds of statement, 17407and a 'gphi_iterator' subclass for iterating over PHI nodes. The 17408following snippet will pretty-print all PHI nodes the statements of the 17409current function in the GIMPLE representation. 17410 17411 basic_block bb; 17412 17413 FOR_EACH_BB (bb) 17414 { 17415 gphi_iterator pi; 17416 gimple_stmt_iterator si; 17417 17418 for (pi = gsi_start_phis (bb); !gsi_end_p (pi); gsi_next (&pi)) 17419 { 17420 gphi *phi = pi.phi (); 17421 print_gimple_stmt (dump_file, phi, 0, TDF_SLIM); 17422 } 17423 for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si)) 17424 { 17425 gimple stmt = gsi_stmt (si); 17426 print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM); 17427 } 17428 } 17429 17430 17431File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 17432 1743314.2 Edges 17434========== 17435 17436Edges represent possible control flow transfers from the end of some 17437basic block A to the head of another basic block B. We say that A is a 17438predecessor of B, and B is a successor of A. Edges are represented in 17439GCC with the 'edge' data type. Each 'edge' acts as a link between two 17440basic blocks: The 'src' member of an edge points to the predecessor 17441basic block of the 'dest' basic block. The members 'preds' and 'succs' 17442of the 'basic_block' data type point to type-safe vectors of edges to 17443the predecessors and successors of the block. 17444 17445 When walking the edges in an edge vector, "edge iterators" should be 17446used. Edge iterators are constructed using the 'edge_iterator' data 17447structure and several methods are available to operate on them: 17448 17449'ei_start' 17450 This function initializes an 'edge_iterator' that points to the 17451 first edge in a vector of edges. 17452 17453'ei_last' 17454 This function initializes an 'edge_iterator' that points to the 17455 last edge in a vector of edges. 17456 17457'ei_end_p' 17458 This predicate is 'true' if an 'edge_iterator' represents the last 17459 edge in an edge vector. 17460 17461'ei_one_before_end_p' 17462 This predicate is 'true' if an 'edge_iterator' represents the 17463 second last edge in an edge vector. 17464 17465'ei_next' 17466 This function takes a pointer to an 'edge_iterator' and makes it 17467 point to the next edge in the sequence. 17468 17469'ei_prev' 17470 This function takes a pointer to an 'edge_iterator' and makes it 17471 point to the previous edge in the sequence. 17472 17473'ei_edge' 17474 This function returns the 'edge' currently pointed to by an 17475 'edge_iterator'. 17476 17477'ei_safe_safe' 17478 This function returns the 'edge' currently pointed to by an 17479 'edge_iterator', but returns 'NULL' if the iterator is pointing at 17480 the end of the sequence. This function has been provided for 17481 existing code makes the assumption that a 'NULL' edge indicates the 17482 end of the sequence. 17483 17484 The convenience macro 'FOR_EACH_EDGE' can be used to visit all of the 17485edges in a sequence of predecessor or successor edges. It must not be 17486used when an element might be removed during the traversal, otherwise 17487elements will be missed. Here is an example of how to use the macro: 17488 17489 edge e; 17490 edge_iterator ei; 17491 17492 FOR_EACH_EDGE (e, ei, bb->succs) 17493 { 17494 if (e->flags & EDGE_FALLTHRU) 17495 break; 17496 } 17497 17498 There are various reasons why control flow may transfer from one block 17499to another. One possibility is that some instruction, for example a 17500'CODE_LABEL', in a linearized instruction stream just always starts a 17501new basic block. In this case a "fall-thru" edge links the basic block 17502to the first following basic block. But there are several other reasons 17503why edges may be created. The 'flags' field of the 'edge' data type is 17504used to store information about the type of edge we are dealing with. 17505Each edge is of one of the following types: 17506 17507_jump_ 17508 No type flags are set for edges corresponding to jump instructions. 17509 These edges are used for unconditional or conditional jumps and in 17510 RTL also for table jumps. They are the easiest to manipulate as 17511 they may be freely redirected when the flow graph is not in SSA 17512 form. 17513 17514_fall-thru_ 17515 Fall-thru edges are present in case where the basic block may 17516 continue execution to the following one without branching. These 17517 edges have the 'EDGE_FALLTHRU' flag set. Unlike other types of 17518 edges, these edges must come into the basic block immediately 17519 following in the instruction stream. The function 17520 'force_nonfallthru' is available to insert an unconditional jump in 17521 the case that redirection is needed. Note that this may require 17522 creation of a new basic block. 17523 17524_exception handling_ 17525 Exception handling edges represent possible control transfers from 17526 a trapping instruction to an exception handler. The definition of 17527 "trapping" varies. In C++, only function calls can throw, but for 17528 Java and Ada, exceptions like division by zero or segmentation 17529 fault are defined and thus each instruction possibly throwing this 17530 kind of exception needs to be handled as control flow instruction. 17531 Exception edges have the 'EDGE_ABNORMAL' and 'EDGE_EH' flags set. 17532 17533 When updating the instruction stream it is easy to change possibly 17534 trapping instruction to non-trapping, by simply removing the 17535 exception edge. The opposite conversion is difficult, but should 17536 not happen anyway. The edges can be eliminated via 17537 'purge_dead_edges' call. 17538 17539 In the RTL representation, the destination of an exception edge is 17540 specified by 'REG_EH_REGION' note attached to the insn. In case of 17541 a trapping call the 'EDGE_ABNORMAL_CALL' flag is set too. In the 17542 'GIMPLE' representation, this extra flag is not set. 17543 17544 In the RTL representation, the predicate 'may_trap_p' may be used 17545 to check whether instruction still may trap or not. For the tree 17546 representation, the 'tree_could_trap_p' predicate is available, but 17547 this predicate only checks for possible memory traps, as in 17548 dereferencing an invalid pointer location. 17549 17550_sibling calls_ 17551 Sibling calls or tail calls terminate the function in a 17552 non-standard way and thus an edge to the exit must be present. 17553 'EDGE_SIBCALL' and 'EDGE_ABNORMAL' are set in such case. These 17554 edges only exist in the RTL representation. 17555 17556_computed jumps_ 17557 Computed jumps contain edges to all labels in the function 17558 referenced from the code. All those edges have 'EDGE_ABNORMAL' 17559 flag set. The edges used to represent computed jumps often cause 17560 compile time performance problems, since functions consisting of 17561 many taken labels and many computed jumps may have _very_ dense 17562 flow graphs, so these edges need to be handled with special care. 17563 During the earlier stages of the compilation process, GCC tries to 17564 avoid such dense flow graphs by factoring computed jumps. For 17565 example, given the following series of jumps, 17566 17567 goto *x; 17568 [ ... ] 17569 17570 goto *x; 17571 [ ... ] 17572 17573 goto *x; 17574 [ ... ] 17575 17576 factoring the computed jumps results in the following code sequence 17577 which has a much simpler flow graph: 17578 17579 goto y; 17580 [ ... ] 17581 17582 goto y; 17583 [ ... ] 17584 17585 goto y; 17586 [ ... ] 17587 17588 y: 17589 goto *x; 17590 17591 However, the classic problem with this transformation is that it 17592 has a runtime cost in there resulting code: An extra jump. 17593 Therefore, the computed jumps are un-factored in the later passes 17594 of the compiler (in the pass called 17595 'pass_duplicate_computed_gotos'). Be aware of that when you work 17596 on passes in that area. There have been numerous examples already 17597 where the compile time for code with unfactored computed jumps 17598 caused some serious headaches. 17599 17600_nonlocal goto handlers_ 17601 GCC allows nested functions to return into caller using a 'goto' to 17602 a label passed to as an argument to the callee. The labels passed 17603 to nested functions contain special code to cleanup after function 17604 call. Such sections of code are referred to as "nonlocal goto 17605 receivers". If a function contains such nonlocal goto receivers, 17606 an edge from the call to the label is created with the 17607 'EDGE_ABNORMAL' and 'EDGE_ABNORMAL_CALL' flags set. 17608 17609_function entry points_ 17610 By definition, execution of function starts at basic block 0, so 17611 there is always an edge from the 'ENTRY_BLOCK_PTR' to basic block 17612 0. There is no 'GIMPLE' representation for alternate entry points 17613 at this moment. In RTL, alternate entry points are specified by 17614 'CODE_LABEL' with 'LABEL_ALTERNATE_NAME' defined. This feature is 17615 currently used for multiple entry point prologues and is limited to 17616 post-reload passes only. This can be used by back-ends to emit 17617 alternate prologues for functions called from different contexts. 17618 In future full support for multiple entry functions defined by 17619 Fortran 90 needs to be implemented. 17620 17621_function exits_ 17622 In the pre-reload representation a function terminates after the 17623 last instruction in the insn chain and no explicit return 17624 instructions are used. This corresponds to the fall-thru edge into 17625 exit block. After reload, optimal RTL epilogues are used that use 17626 explicit (conditional) return instructions that are represented by 17627 edges with no flags set. 17628 17629 17630File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 17631 1763214.3 Profile information 17633======================== 17634 17635In many cases a compiler must make a choice whether to trade speed in 17636one part of code for speed in another, or to trade code size for code 17637speed. In such cases it is useful to know information about how often 17638some given block will be executed. That is the purpose for maintaining 17639profile within the flow graph. GCC can handle profile information 17640obtained through "profile feedback", but it can also estimate branch 17641probabilities based on statics and heuristics. 17642 17643 The feedback based profile is produced by compiling the program with 17644instrumentation, executing it on a train run and reading the numbers of 17645executions of basic blocks and edges back to the compiler while 17646re-compiling the program to produce the final executable. This method 17647provides very accurate information about where a program spends most of 17648its time on the train run. Whether it matches the average run of course 17649depends on the choice of train data set, but several studies have shown 17650that the behavior of a program usually changes just marginally over 17651different data sets. 17652 17653 When profile feedback is not available, the compiler may be asked to 17654attempt to predict the behavior of each branch in the program using a 17655set of heuristics (see 'predict.def' for details) and compute estimated 17656frequencies of each basic block by propagating the probabilities over 17657the graph. 17658 17659 Each 'basic_block' contains two integer fields to represent profile 17660information: 'frequency' and 'count'. The 'frequency' is an estimation 17661how often is basic block executed within a function. It is represented 17662as an integer scaled in the range from 0 to 'BB_FREQ_BASE'. The most 17663frequently executed basic block in function is initially set to 17664'BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 17665During optimization, the frequency of the most frequent basic block can 17666both decrease (for instance by loop unrolling) or grow (for instance by 17667cross-jumping optimization), so scaling sometimes has to be performed 17668multiple times. 17669 17670 The 'count' contains hard-counted numbers of execution measured during 17671training runs and is nonzero only when profile feedback is available. 17672This value is represented as the host's widest integer (typically a 64 17673bit integer) of the special type 'gcov_type'. 17674 17675 Most optimization passes can use only the frequency information of a 17676basic block, but a few passes may want to know hard execution counts. 17677The frequencies should always match the counts after scaling, however 17678during updating of the profile information numerical error may 17679accumulate into quite large errors. 17680 17681 Each edge also contains a branch probability field: an integer in the 17682range from 0 to 'REG_BR_PROB_BASE'. It represents probability of 17683passing control from the end of the 'src' basic block to the 'dest' 17684basic block, i.e. the probability that control will flow along this 17685edge. The 'EDGE_FREQUENCY' macro is available to compute how frequently 17686a given edge is taken. There is a 'count' field for each edge as well, 17687representing same information as for a basic block. 17688 17689 The basic block frequencies are not represented in the instruction 17690stream, but in the RTL representation the edge frequencies are 17691represented for conditional jumps (via the 'REG_BR_PROB' macro) since 17692they are used when instructions are output to the assembly file and the 17693flow graph is no longer maintained. 17694 17695 The probability that control flow arrives via a given edge to its 17696destination basic block is called "reverse probability" and is not 17697directly represented, but it may be easily computed from frequencies of 17698basic blocks. 17699 17700 Updating profile information is a delicate task that can unfortunately 17701not be easily integrated with the CFG manipulation API. Many of the 17702functions and hooks to modify the CFG, such as 17703'redirect_edge_and_branch', do not have enough information to easily 17704update the profile, so updating it is in the majority of cases left up 17705to the caller. It is difficult to uncover bugs in the profile updating 17706code, because they manifest themselves only by producing worse code, and 17707checking profile consistency is not possible because of numeric error 17708accumulation. Hence special attention needs to be given to this issue 17709in each pass that modifies the CFG. 17710 17711 It is important to point out that 'REG_BR_PROB_BASE' and 'BB_FREQ_BASE' 17712are both set low enough to be possible to compute second power of any 17713frequency or probability in the flow graph, it is not possible to even 17714square the 'count' field, as modern CPUs are fast enough to execute 17715$2^32$ operations quickly. 17716 17717 17718File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 17719 1772014.4 Maintaining the CFG 17721======================== 17722 17723An important task of each compiler pass is to keep both the control flow 17724graph and all profile information up-to-date. Reconstruction of the 17725control flow graph after each pass is not an option, since it may be 17726very expensive and lost profile information cannot be reconstructed at 17727all. 17728 17729 GCC has two major intermediate representations, and both use the 17730'basic_block' and 'edge' data types to represent control flow. Both 17731representations share as much of the CFG maintenance code as possible. 17732For each representation, a set of "hooks" is defined so that each 17733representation can provide its own implementation of CFG manipulation 17734routines when necessary. These hooks are defined in 'cfghooks.h'. 17735There are hooks for almost all common CFG manipulations, including block 17736splitting and merging, edge redirection and creating and deleting basic 17737blocks. These hooks should provide everything you need to maintain and 17738manipulate the CFG in both the RTL and 'GIMPLE' representation. 17739 17740 At the moment, the basic block boundaries are maintained transparently 17741when modifying instructions, so there rarely is a need to move them 17742manually (such as in case someone wants to output instruction outside 17743basic block explicitly). 17744 17745 In the RTL representation, each instruction has a 'BLOCK_FOR_INSN' 17746value that represents pointer to the basic block that contains the 17747instruction. In the 'GIMPLE' representation, the function 'gimple_bb' 17748returns a pointer to the basic block containing the queried statement. 17749 17750 When changes need to be applied to a function in its 'GIMPLE' 17751representation, "GIMPLE statement iterators" should be used. These 17752iterators provide an integrated abstraction of the flow graph and the 17753instruction stream. Block statement iterators are constructed using the 17754'gimple_stmt_iterator' data structure and several modifiers are 17755available, including the following: 17756 17757'gsi_start' 17758 This function initializes a 'gimple_stmt_iterator' that points to 17759 the first non-empty statement in a basic block. 17760 17761'gsi_last' 17762 This function initializes a 'gimple_stmt_iterator' that points to 17763 the last statement in a basic block. 17764 17765'gsi_end_p' 17766 This predicate is 'true' if a 'gimple_stmt_iterator' represents the 17767 end of a basic block. 17768 17769'gsi_next' 17770 This function takes a 'gimple_stmt_iterator' and makes it point to 17771 its successor. 17772 17773'gsi_prev' 17774 This function takes a 'gimple_stmt_iterator' and makes it point to 17775 its predecessor. 17776 17777'gsi_insert_after' 17778 This function inserts a statement after the 'gimple_stmt_iterator' 17779 passed in. The final parameter determines whether the statement 17780 iterator is updated to point to the newly inserted statement, or 17781 left pointing to the original statement. 17782 17783'gsi_insert_before' 17784 This function inserts a statement before the 'gimple_stmt_iterator' 17785 passed in. The final parameter determines whether the statement 17786 iterator is updated to point to the newly inserted statement, or 17787 left pointing to the original statement. 17788 17789'gsi_remove' 17790 This function removes the 'gimple_stmt_iterator' passed in and 17791 rechains the remaining statements in a basic block, if any. 17792 17793 In the RTL representation, the macros 'BB_HEAD' and 'BB_END' may be 17794used to get the head and end 'rtx' of a basic block. No abstract 17795iterators are defined for traversing the insn chain, but you can just 17796use 'NEXT_INSN' and 'PREV_INSN' instead. *Note Insns::. 17797 17798 Usually a code manipulating pass simplifies the instruction stream and 17799the flow of control, possibly eliminating some edges. This may for 17800example happen when a conditional jump is replaced with an unconditional 17801jump, but also when simplifying possibly trapping instruction to 17802non-trapping while compiling Java. Updating of edges is not transparent 17803and each optimization pass is required to do so manually. However only 17804few cases occur in practice. The pass may call 'purge_dead_edges' on a 17805given basic block to remove superfluous edges, if any. 17806 17807 Another common scenario is redirection of branch instructions, but this 17808is best modeled as redirection of edges in the control flow graph and 17809thus use of 'redirect_edge_and_branch' is preferred over more low level 17810functions, such as 'redirect_jump' that operate on RTL chain only. The 17811CFG hooks defined in 'cfghooks.h' should provide the complete API 17812required for manipulating and maintaining the CFG. 17813 17814 It is also possible that a pass has to insert control flow instruction 17815into the middle of a basic block, thus creating an entry point in the 17816middle of the basic block, which is impossible by definition: The block 17817must be split to make sure it only has one entry point, i.e. the head of 17818the basic block. The CFG hook 'split_block' may be used when an 17819instruction in the middle of a basic block has to become the target of a 17820jump or branch instruction. 17821 17822 For a global optimizer, a common operation is to split edges in the 17823flow graph and insert instructions on them. In the RTL representation, 17824this can be easily done using the 'insert_insn_on_edge' function that 17825emits an instruction "on the edge", caching it for a later 17826'commit_edge_insertions' call that will take care of moving the inserted 17827instructions off the edge into the instruction stream contained in a 17828basic block. This includes the creation of new basic blocks where 17829needed. In the 'GIMPLE' representation, the equivalent functions are 17830'gsi_insert_on_edge' which inserts a block statement iterator on an 17831edge, and 'gsi_commit_edge_inserts' which flushes the instruction to 17832actual instruction stream. 17833 17834 While debugging the optimization pass, the 'verify_flow_info' function 17835may be useful to find bugs in the control flow graph updating code. 17836 17837 17838File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 17839 1784014.5 Liveness information 17841========================= 17842 17843Liveness information is useful to determine whether some register is 17844"live" at given point of program, i.e. that it contains a value that may 17845be used at a later point in the program. This information is used, for 17846instance, during register allocation, as the pseudo registers only need 17847to be assigned to a unique hard register or to a stack slot if they are 17848live. The hard registers and stack slots may be freely reused for other 17849values when a register is dead. 17850 17851 Liveness information is available in the back end starting with 17852'pass_df_initialize' and ending with 'pass_df_finish'. Three flavors of 17853live analysis are available: With 'LR', it is possible to determine at 17854any point 'P' in the function if the register may be used on some path 17855from 'P' to the end of the function. With 'UR', it is possible to 17856determine if there is a path from the beginning of the function to 'P' 17857that defines the variable. 'LIVE' is the intersection of the 'LR' and 17858'UR' and a variable is live at 'P' if there is both an assignment that 17859reaches it from the beginning of the function and a use that can be 17860reached on some path from 'P' to the end of the function. 17861 17862 In general 'LIVE' is the most useful of the three. The macros 17863'DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The 17864macros take a basic block number and return a bitmap that is indexed by 17865the register number. This information is only guaranteed to be up to 17866date after calls are made to 'df_analyze'. See the file 'df-core.c' for 17867details on using the dataflow. 17868 17869 The liveness information is stored partly in the RTL instruction stream 17870and partly in the flow graph. Local information is stored in the 17871instruction stream: Each instruction may contain 'REG_DEAD' notes 17872representing that the value of a given register is no longer needed, or 17873'REG_UNUSED' notes representing that the value computed by the 17874instruction is never used. The second is useful for instructions 17875computing multiple values at once. 17876 17877 17878File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top 17879 1788015 Analysis and Representation of Loops 17881*************************************** 17882 17883GCC provides extensive infrastructure for work with natural loops, i.e., 17884strongly connected components of CFG with only one entry block. This 17885chapter describes representation of loops in GCC, both on GIMPLE and in 17886RTL, as well as the interfaces to loop-related analyses (induction 17887variable analysis and number of iterations analysis). 17888 17889* Menu: 17890 17891* Loop representation:: Representation and analysis of loops. 17892* Loop querying:: Getting information about loops. 17893* Loop manipulation:: Loop manipulation functions. 17894* LCSSA:: Loop-closed SSA form. 17895* Scalar evolutions:: Induction variables on GIMPLE. 17896* loop-iv:: Induction variables on RTL. 17897* Number of iterations:: Number of iterations analysis. 17898* Dependency analysis:: Data dependency analysis. 17899 17900 17901File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 17902 1790315.1 Loop representation 17904======================== 17905 17906This chapter describes the representation of loops in GCC, and functions 17907that can be used to build, modify and analyze this representation. Most 17908of the interfaces and data structures are declared in 'cfgloop.h'. Loop 17909structures are analyzed and this information disposed or updated at the 17910discretion of individual passes. Still most of the generic CFG 17911manipulation routines are aware of loop structures and try to keep them 17912up-to-date. By this means an increasing part of the compilation 17913pipeline is setup to maintain loop structure across passes to allow 17914attaching meta information to individual loops for consumption by later 17915passes. 17916 17917 In general, a natural loop has one entry block (header) and possibly 17918several back edges (latches) leading to the header from the inside of 17919the loop. Loops with several latches may appear if several loops share 17920a single header, or if there is a branching in the middle of the loop. 17921The representation of loops in GCC however allows only loops with a 17922single latch. During loop analysis, headers of such loops are split and 17923forwarder blocks are created in order to disambiguate their structures. 17924Heuristic based on profile information and structure of the induction 17925variables in the loops is used to determine whether the latches 17926correspond to sub-loops or to control flow in a single loop. This means 17927that the analysis sometimes changes the CFG, and if you run it in the 17928middle of an optimization pass, you must be able to deal with the new 17929blocks. You may avoid CFG changes by passing 17930'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note 17931however that most other loop manipulation functions will not work 17932correctly for loops with multiple latch edges (the functions that only 17933query membership of blocks to loops and subloop relationships, or 17934enumerate and test loop exits, can be expected to work). 17935 17936 Body of the loop is the set of blocks that are dominated by its header, 17937and reachable from its latch against the direction of edges in CFG. The 17938loops are organized in a containment hierarchy (tree) such that all the 17939loops immediately contained inside loop L are the children of L in the 17940tree. This tree is represented by the 'struct loops' structure. The 17941root of this tree is a fake loop that contains all blocks in the 17942function. Each of the loops is represented in a 'struct loop' 17943structure. Each loop is assigned an index ('num' field of the 'struct 17944loop' structure), and the pointer to the loop is stored in the 17945corresponding field of the 'larray' vector in the loops structure. The 17946indices do not have to be continuous, there may be empty ('NULL') 17947entries in the 'larray' created by deleting loops. Also, there is no 17948guarantee on the relative order of a loop and its subloops in the 17949numbering. The index of a loop never changes. 17950 17951 The entries of the 'larray' field should not be accessed directly. The 17952function 'get_loop' returns the loop description for a loop with the 17953given index. 'number_of_loops' function returns number of loops in the 17954function. To traverse all loops, use 'FOR_EACH_LOOP' macro. The 17955'flags' argument of the macro is used to determine the direction of 17956traversal and the set of loops visited. Each loop is guaranteed to be 17957visited exactly once, regardless of the changes to the loop tree, and 17958the loops may be removed during the traversal. The newly created loops 17959are never traversed, if they need to be visited, this must be done 17960separately after their creation. The 'FOR_EACH_LOOP' macro allocates 17961temporary variables. If the 'FOR_EACH_LOOP' loop were ended using break 17962or goto, they would not be released; 'FOR_EACH_LOOP_BREAK' macro must be 17963used instead. 17964 17965 Each basic block contains the reference to the innermost loop it 17966belongs to ('loop_father'). For this reason, it is only possible to 17967have one 'struct loops' structure initialized at the same time for each 17968CFG. The global variable 'current_loops' contains the 'struct loops' 17969structure. Many of the loop manipulation functions assume that 17970dominance information is up-to-date. 17971 17972 The loops are analyzed through 'loop_optimizer_init' function. The 17973argument of this function is a set of flags represented in an integer 17974bitmask. These flags specify what other properties of the loop 17975structures should be calculated/enforced and preserved later: 17976 17977 * 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes 17978 to CFG will be performed in the loop analysis, in particular, loops 17979 with multiple latch edges will not be disambiguated. If a loop has 17980 multiple latches, its latch block is set to NULL. Most of the loop 17981 manipulation functions will not work for loops in this shape. No 17982 other flags that require CFG changes can be passed to 17983 loop_optimizer_init. 17984 * 'LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a way 17985 that each loop has only one entry edge, and additionally, the 17986 source block of this entry edge has only one successor. This 17987 creates a natural place where the code can be moved out of the 17988 loop, and ensures that the entry edge of the loop leads from its 17989 immediate super-loop. 17990 * 'LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 17991 the latch block of each loop to have only one successor. This 17992 ensures that the latch of the loop does not belong to any of its 17993 sub-loops, and makes manipulation with the loops significantly 17994 easier. Most of the loop manipulation functions assume that the 17995 loops are in this shape. Note that with this flag, the "normal" 17996 loop without any control flow inside and with one exit consists of 17997 two basic blocks. 17998 * 'LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 17999 the strongly connected components that are not natural loops (have 18000 more than one entry block) are marked with 'BB_IRREDUCIBLE_LOOP' 18001 and 'EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 18002 and edges that belong to natural loops that are in such an 18003 irreducible region (but it is set for the entry and exit edges of 18004 such a loop, if they lead to/from this region). 18005 * 'LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and 18006 updated for each loop. This makes some functions (e.g., 18007 'get_loop_exit_edges') more efficient. Some functions (e.g., 18008 'single_exit') can be used only if the lists of exits are recorded. 18009 18010 These properties may also be computed/enforced later, using functions 18011'create_preheaders', 'force_single_succ_latches', 18012'mark_irreducible_loops' and 'record_loop_exits'. The properties can be 18013queried using 'loops_state_satisfies_p'. 18014 18015 The memory occupied by the loops structures should be freed with 18016'loop_optimizer_finalize' function. When loop structures are setup to 18017be preserved across passes this function reduces the information to be 18018kept up-to-date to a minimum (only 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' 18019set). 18020 18021 The CFG manipulation functions in general do not update loop 18022structures. Specialized versions that additionally do so are provided 18023for the most common tasks. On GIMPLE, 'cleanup_tree_cfg_loop' function 18024can be used to cleanup CFG while updating the loops structures if 18025'current_loops' is set. 18026 18027 At the moment loop structure is preserved from the start of GIMPLE loop 18028optimizations until the end of RTL loop optimizations. During this time 18029a loop can be tracked by its 'struct loop' and number. 18030 18031 18032File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 18033 1803415.2 Loop querying 18035================== 18036 18037The functions to query the information about loops are declared in 18038'cfgloop.h'. Some of the information can be taken directly from the 18039structures. 'loop_father' field of each basic block contains the 18040innermost loop to that the block belongs. The most useful fields of 18041loop structure (that are kept up-to-date at all times) are: 18042 18043 * 'header', 'latch': Header and latch basic blocks of the loop. 18044 * 'num_nodes': Number of basic blocks in the loop (including the 18045 basic blocks of the sub-loops). 18046 * 'outer', 'inner', 'next': The super-loop, the first sub-loop, and 18047 the sibling of the loop in the loops tree. 18048 18049 There are other fields in the loop structures, many of them used only 18050by some of the passes, or not updated during CFG changes; in general, 18051they should not be accessed directly. 18052 18053 The most important functions to query loop structures are: 18054 18055 * 'loop_depth': The depth of the loop in the loops tree, i.e., the 18056 number of super-loops of the loop. 18057 * 'flow_loops_dump': Dumps the information about loops to a file. 18058 * 'verify_loop_structure': Checks consistency of the loop structures. 18059 * 'loop_latch_edge': Returns the latch edge of a loop. 18060 * 'loop_preheader_edge': If loops have preheaders, returns the 18061 preheader edge of a loop. 18062 * 'flow_loop_nested_p': Tests whether loop is a sub-loop of another 18063 loop. 18064 * 'flow_bb_inside_loop_p': Tests whether a basic block belongs to a 18065 loop (including its sub-loops). 18066 * 'find_common_loop': Finds the common super-loop of two loops. 18067 * 'superloop_at_depth': Returns the super-loop of a loop with the 18068 given depth. 18069 * 'tree_num_loop_insns', 'num_loop_insns': Estimates the number of 18070 insns in the loop, on GIMPLE and on RTL. 18071 * 'loop_exit_edge_p': Tests whether edge is an exit from a loop. 18072 * 'mark_loop_exit_edges': Marks all exit edges of all loops with 18073 'EDGE_LOOP_EXIT' flag. 18074 * 'get_loop_body', 'get_loop_body_in_dom_order', 18075 'get_loop_body_in_bfs_order': Enumerates the basic blocks in the 18076 loop in depth-first search order in reversed CFG, ordered by 18077 dominance relation, and breath-first search order, respectively. 18078 * 'single_exit': Returns the single exit edge of the loop, or 'NULL' 18079 if the loop has more than one exit. You can only use this function 18080 if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used. 18081 * 'get_loop_exit_edges': Enumerates the exit edges of a loop. 18082 * 'just_once_each_iteration_p': Returns true if the basic block is 18083 executed exactly once during each iteration of a loop (that is, it 18084 does not belong to a sub-loop, and it dominates the latch of the 18085 loop). 18086 18087 18088File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 18089 1809015.3 Loop manipulation 18091====================== 18092 18093The loops tree can be manipulated using the following functions: 18094 18095 * 'flow_loop_tree_node_add': Adds a node to the tree. 18096 * 'flow_loop_tree_node_remove': Removes a node from the tree. 18097 * 'add_bb_to_loop': Adds a basic block to a loop. 18098 * 'remove_bb_from_loops': Removes a basic block from loops. 18099 18100 Most low-level CFG functions update loops automatically. The following 18101functions handle some more complicated cases of CFG manipulations: 18102 18103 * 'remove_path': Removes an edge and all blocks it dominates. 18104 * 'split_loop_exit_edge': Splits exit edge of the loop, ensuring that 18105 PHI node arguments remain in the loop (this ensures that 18106 loop-closed SSA form is preserved). Only useful on GIMPLE. 18107 18108 Finally, there are some higher-level loop transformations implemented. 18109While some of them are written so that they should work on non-innermost 18110loops, they are mostly untested in that case, and at the moment, they 18111are only reliable for the innermost loops: 18112 18113 * 'create_iv': Creates a new induction variable. Only works on 18114 GIMPLE. 'standard_iv_increment_position' can be used to find a 18115 suitable place for the iv increment. 18116 * 'duplicate_loop_to_header_edge', 18117 'tree_duplicate_loop_to_header_edge': These functions (on RTL and 18118 on GIMPLE) duplicate the body of the loop prescribed number of 18119 times on one of the edges entering loop header, thus performing 18120 either loop unrolling or loop peeling. 'can_duplicate_loop_p' 18121 ('can_unroll_loop_p' on GIMPLE) must be true for the duplicated 18122 loop. 18123 * 'loop_version', 'tree_ssa_loop_version': These function create a 18124 copy of a loop, and a branch before them that selects one of them 18125 depending on the prescribed condition. This is useful for 18126 optimizations that need to verify some assumptions in runtime (one 18127 of the copies of the loop is usually left unchanged, while the 18128 other one is transformed in some way). 18129 * 'tree_unroll_loop': Unrolls the loop, including peeling the extra 18130 iterations to make the number of iterations divisible by unroll 18131 factor, updating the exit condition, and removing the exits that 18132 now cannot be taken. Works only on GIMPLE. 18133 18134 18135File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 18136 1813715.4 Loop-closed SSA form 18138========================= 18139 18140Throughout the loop optimizations on tree level, one extra condition is 18141enforced on the SSA form: No SSA name is used outside of the loop in 18142that it is defined. The SSA form satisfying this condition is called 18143"loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 18144created at the exits of the loops for the SSA names that are used 18145outside of them. Only the real operands (not virtual SSA names) are 18146held in LCSSA, in order to save memory. 18147 18148 There are various benefits of LCSSA: 18149 18150 * Many optimizations (value range analysis, final value replacement) 18151 are interested in the values that are defined in the loop and used 18152 outside of it, i.e., exactly those for that we create new PHI 18153 nodes. 18154 * In induction variable analysis, it is not necessary to specify the 18155 loop in that the analysis should be performed - the scalar 18156 evolution analysis always returns the results with respect to the 18157 loop in that the SSA name is defined. 18158 * It makes updating of SSA form during loop transformations simpler. 18159 Without LCSSA, operations like loop unrolling may force creation of 18160 PHI nodes arbitrarily far from the loop, while in LCSSA, the SSA 18161 form can be updated locally. However, since we only keep real 18162 operands in LCSSA, we cannot use this advantage (we could have 18163 local updating of real operands, but it is not much more efficient 18164 than to use generic SSA form updating for it as well; the amount of 18165 changes to SSA is the same). 18166 18167 However, it also means LCSSA must be updated. This is usually 18168straightforward, unless you create a new value in loop and use it 18169outside, or unless you manipulate loop exit edges (functions are 18170provided to make these manipulations simple). 18171'rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, and 18172'verify_loop_closed_ssa' to check that the invariant of LCSSA is 18173preserved. 18174 18175 18176File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 18177 1817815.5 Scalar evolutions 18179====================== 18180 18181Scalar evolutions (SCEV) are used to represent results of induction 18182variable analysis on GIMPLE. They enable us to represent variables with 18183complicated behavior in a simple and consistent way (we only use it to 18184express values of polynomial induction variables, but it is possible to 18185extend it). The interfaces to SCEV analysis are declared in 18186'tree-scalar-evolution.h'. To use scalar evolutions analysis, 18187'scev_initialize' must be used. To stop using SCEV, 'scev_finalize' 18188should be used. SCEV analysis caches results in order to save time and 18189memory. This cache however is made invalid by most of the loop 18190transformations, including removal of code. If such a transformation is 18191performed, 'scev_reset' must be called to clean the caches. 18192 18193 Given an SSA name, its behavior in loops can be analyzed using the 18194'analyze_scalar_evolution' function. The returned SCEV however does not 18195have to be fully analyzed and it may contain references to other SSA 18196names defined in the loop. To resolve these (potentially recursive) 18197references, 'instantiate_parameters' or 'resolve_mixers' functions must 18198be used. 'instantiate_parameters' is useful when you use the results of 18199SCEV only for some analysis, and when you work with whole nest of loops 18200at once. It will try replacing all SSA names by their SCEV in all 18201loops, including the super-loops of the current loop, thus providing a 18202complete information about the behavior of the variable in the loop 18203nest. 'resolve_mixers' is useful if you work with only one loop at a 18204time, and if you possibly need to create code based on the value of the 18205induction variable. It will only resolve the SSA names defined in the 18206current loop, leaving the SSA names defined outside unchanged, even if 18207their evolution in the outer loops is known. 18208 18209 The SCEV is a normal tree expression, except for the fact that it may 18210contain several special tree nodes. One of them is 'SCEV_NOT_KNOWN', 18211used for SSA names whose value cannot be expressed. The other one is 18212'POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 18213and loop (both base and step may contain further polynomial chrecs). 18214Type of the expression and of base and step must be the same. A 18215variable has evolution 'POLYNOMIAL_CHREC(base, step, loop)' if it is (in 18216the specified loop) equivalent to 'x_1' in the following example 18217 18218 while (...) 18219 { 18220 x_1 = phi (base, x_2); 18221 x_2 = x_1 + step; 18222 } 18223 18224 Note that this includes the language restrictions on the operations. 18225For example, if we compile C code and 'x' has signed type, then the 18226overflow in addition would cause undefined behavior, and we may assume 18227that this does not happen. Hence, the value with this SCEV cannot 18228overflow (which restricts the number of iterations of such a loop). 18229 18230 In many cases, one wants to restrict the attention just to affine 18231induction variables. In this case, the extra expressive power of SCEV 18232is not useful, and may complicate the optimizations. In this case, 18233'simple_iv' function may be used to analyze a value - the result is a 18234loop-invariant base and step. 18235 18236 18237File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 18238 1823915.6 IV analysis on RTL 18240======================= 18241 18242The induction variable on RTL is simple and only allows analysis of 18243affine induction variables, and only in one loop at once. The interface 18244is declared in 'cfgloop.h'. Before analyzing induction variables in a 18245loop L, 'iv_analysis_loop_init' function must be called on L. After the 18246analysis (possibly calling 'iv_analysis_loop_init' for several loops) is 18247finished, 'iv_analysis_done' should be called. The following functions 18248can be used to access the results of the analysis: 18249 18250 * 'iv_analyze': Analyzes a single register used in the given insn. 18251 If no use of the register in this insn is found, the following 18252 insns are scanned, so that this function can be called on the insn 18253 returned by get_condition. 18254 * 'iv_analyze_result': Analyzes result of the assignment in the given 18255 insn. 18256 * 'iv_analyze_expr': Analyzes a more complicated expression. All its 18257 operands are analyzed by 'iv_analyze', and hence they must be used 18258 in the specified insn or one of the following insns. 18259 18260 The description of the induction variable is provided in 'struct 18261rtx_iv'. In order to handle subregs, the representation is a bit 18262complicated; if the value of the 'extend' field is not 'UNKNOWN', the 18263value of the induction variable in the i-th iteration is 18264 18265 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 18266 18267 with the following exception: if 'first_special' is true, then the 18268value in the first iteration (when 'i' is zero) is 'delta + mult * 18269base'. However, if 'extend' is equal to 'UNKNOWN', then 'first_special' 18270must be false, 'delta' 0, 'mult' 1 and the value in the i-th iteration 18271is 18272 18273 subreg_{mode} (base + i * step) 18274 18275 The function 'get_iv_value' can be used to perform these calculations. 18276 18277 18278File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 18279 1828015.7 Number of iterations analysis 18281================================== 18282 18283Both on GIMPLE and on RTL, there are functions available to determine 18284the number of iterations of a loop, with a similar interface. The 18285number of iterations of a loop in GCC is defined as the number of 18286executions of the loop latch. In many cases, it is not possible to 18287determine the number of iterations unconditionally - the determined 18288number is correct only if some assumptions are satisfied. The analysis 18289tries to verify these conditions using the information contained in the 18290program; if it fails, the conditions are returned together with the 18291result. The following information and conditions are provided by the 18292analysis: 18293 18294 * 'assumptions': If this condition is false, the rest of the 18295 information is invalid. 18296 * 'noloop_assumptions' on RTL, 'may_be_zero' on GIMPLE: If this 18297 condition is true, the loop exits in the first iteration. 18298 * 'infinite': If this condition is true, the loop is infinite. This 18299 condition is only available on RTL. On GIMPLE, conditions for 18300 finiteness of the loop are included in 'assumptions'. 18301 * 'niter_expr' on RTL, 'niter' on GIMPLE: The expression that gives 18302 number of iterations. The number of iterations is defined as the 18303 number of executions of the loop latch. 18304 18305 Both on GIMPLE and on RTL, it necessary for the induction variable 18306analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 18307On GIMPLE, the results are stored to 'struct tree_niter_desc' structure. 18308Number of iterations before the loop is exited through a given exit can 18309be determined using 'number_of_iterations_exit' function. On RTL, the 18310results are returned in 'struct niter_desc' structure. The 18311corresponding function is named 'check_simple_exit'. There are also 18312functions that pass through all the exits of a loop and try to find one 18313with easy to determine number of iterations - 'find_loop_niter' on 18314GIMPLE and 'find_simple_exit' on RTL. Finally, there are functions that 18315provide the same information, but additionally cache it, so that 18316repeated calls to number of iterations are not so costly - 18317'number_of_latch_executions' on GIMPLE and 'get_simple_loop_desc' on 18318RTL. 18319 18320 Note that some of these functions may behave slightly differently than 18321others - some of them return only the expression for the number of 18322iterations, and fail if there are some assumptions. The function 18323'number_of_latch_executions' works only for single-exit loops. The 18324function 'number_of_cond_exit_executions' can be used to determine 18325number of executions of the exit condition of a single-exit loop (i.e., 18326the 'number_of_latch_executions' increased by one). 18327 18328 18329File: gccint.info, Node: Dependency analysis, Prev: Number of iterations, Up: Loop Analysis and Representation 18330 1833115.8 Data Dependency Analysis 18332============================= 18333 18334The code for the data dependence analysis can be found in 18335'tree-data-ref.c' and its interface and data structures are described in 18336'tree-data-ref.h'. The function that computes the data dependences for 18337all the array and pointer references for a given loop is 18338'compute_data_dependences_for_loop'. This function is currently used by 18339the linear loop transform and the vectorization passes. Before calling 18340this function, one has to allocate two vectors: a first vector will 18341contain the set of data references that are contained in the analyzed 18342loop body, and the second vector will contain the dependence relations 18343between the data references. Thus if the vector of data references is 18344of size 'n', the vector containing the dependence relations will contain 18345'n*n' elements. However if the analyzed loop contains side effects, 18346such as calls that potentially can interfere with the data references in 18347the current analyzed loop, the analysis stops while scanning the loop 18348body for data references, and inserts a single 'chrec_dont_know' in the 18349dependence relation array. 18350 18351 The data references are discovered in a particular order during the 18352scanning of the loop body: the loop body is analyzed in execution order, 18353and the data references of each statement are pushed at the end of the 18354data reference array. Two data references syntactically occur in the 18355program in the same order as in the array of data references. This 18356syntactic order is important in some classical data dependence tests, 18357and mapping this order to the elements of this array avoids costly 18358queries to the loop body representation. 18359 18360 Three types of data references are currently handled: ARRAY_REF, 18361INDIRECT_REF and COMPONENT_REF. The data structure for the data 18362reference is 'data_reference', where 'data_reference_p' is a name of a 18363pointer to the data reference structure. The structure contains the 18364following elements: 18365 18366 * 'base_object_info': Provides information about the base object of 18367 the data reference and its access functions. These access 18368 functions represent the evolution of the data reference in the loop 18369 relative to its base, in keeping with the classical meaning of the 18370 data reference access function for the support of arrays. For 18371 example, for a reference 'a.b[i][j]', the base object is 'a.b' and 18372 the access functions, one for each array subscript, are: '{i_init, 18373 + i_step}_1, {j_init, +, j_step}_2'. 18374 18375 * 'first_location_in_loop': Provides information about the first 18376 location accessed by the data reference in the loop and about the 18377 access function used to represent evolution relative to this 18378 location. This data is used to support pointers, and is not used 18379 for arrays (for which we have base objects). Pointer accesses are 18380 represented as a one-dimensional access that starts from the first 18381 location accessed in the loop. For example: 18382 18383 for1 i 18384 for2 j 18385 *((int *)p + i + j) = a[i][j]; 18386 18387 The access function of the pointer access is '{0, + 4B}_for2' 18388 relative to 'p + i'. The access functions of the array are 18389 '{i_init, + i_step}_for1' and '{j_init, +, j_step}_for2' relative 18390 to 'a'. 18391 18392 Usually, the object the pointer refers to is either unknown, or we 18393 can't prove that the access is confined to the boundaries of a 18394 certain object. 18395 18396 Two data references can be compared only if at least one of these 18397 two representations has all its fields filled for both data 18398 references. 18399 18400 The current strategy for data dependence tests is as follows: If 18401 both 'a' and 'b' are represented as arrays, compare 'a.base_object' 18402 and 'b.base_object'; if they are equal, apply dependence tests (use 18403 access functions based on base_objects). Else if both 'a' and 'b' 18404 are represented as pointers, compare 'a.first_location' and 18405 'b.first_location'; if they are equal, apply dependence tests (use 18406 access functions based on first location). However, if 'a' and 'b' 18407 are represented differently, only try to prove that the bases are 18408 definitely different. 18409 18410 * Aliasing information. 18411 * Alignment information. 18412 18413 The structure describing the relation between two data references is 18414'data_dependence_relation' and the shorter name for a pointer to such a 18415structure is 'ddr_p'. This structure contains: 18416 18417 * a pointer to each data reference, 18418 * a tree node 'are_dependent' that is set to 'chrec_known' if the 18419 analysis has proved that there is no dependence between these two 18420 data references, 'chrec_dont_know' if the analysis was not able to 18421 determine any useful result and potentially there could exist a 18422 dependence between these data references, and 'are_dependent' is 18423 set to 'NULL_TREE' if there exist a dependence relation between the 18424 data references, and the description of this dependence relation is 18425 given in the 'subscripts', 'dir_vects', and 'dist_vects' arrays, 18426 * a boolean that determines whether the dependence relation can be 18427 represented by a classical distance vector, 18428 * an array 'subscripts' that contains a description of each subscript 18429 of the data references. Given two array accesses a subscript is 18430 the tuple composed of the access functions for a given dimension. 18431 For example, given 'A[f1][f2][f3]' and 'B[g1][g2][g3]', there are 18432 three subscripts: '(f1, g1), (f2, g2), (f3, g3)'. 18433 * two arrays 'dir_vects' and 'dist_vects' that contain classical 18434 representations of the data dependences under the form of direction 18435 and distance dependence vectors, 18436 * an array of loops 'loop_nest' that contains the loops to which the 18437 distance and direction vectors refer to. 18438 18439 Several functions for pretty printing the information extracted by the 18440data dependence analysis are available: 'dump_ddrs' prints with a 18441maximum verbosity the details of a data dependence relations array, 18442'dump_dist_dir_vectors' prints only the classical distance and direction 18443vectors for a data dependence relations array, and 18444'dump_data_references' prints the details of the data references 18445contained in a data reference array. 18446 18447 18448File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 18449 1845016 Machine Descriptions 18451*********************** 18452 18453A machine description has two parts: a file of instruction patterns 18454('.md' file) and a C header file of macro definitions. 18455 18456 The '.md' file for a target machine contains a pattern for each 18457instruction that the target machine supports (or at least each 18458instruction that is worth telling the compiler about). It may also 18459contain comments. A semicolon causes the rest of the line to be a 18460comment, unless the semicolon is inside a quoted string. 18461 18462 See the next chapter for information on the C header file. 18463 18464* Menu: 18465 18466* Overview:: How the machine description is used. 18467* Patterns:: How to write instruction patterns. 18468* Example:: An explained example of a 'define_insn' pattern. 18469* RTL Template:: The RTL template defines what insns match a pattern. 18470* Output Template:: The output template says how to make assembler code 18471 from such an insn. 18472* Output Statement:: For more generality, write C code to output 18473 the assembler code. 18474* Predicates:: Controlling what kinds of operands can be used 18475 for an insn. 18476* Constraints:: Fine-tuning operand selection. 18477* Standard Names:: Names mark patterns to use for code generation. 18478* Pattern Ordering:: When the order of patterns makes a difference. 18479* Dependent Patterns:: Having one pattern may make you need another. 18480* Jump Patterns:: Special considerations for patterns for jump insns. 18481* Looping Patterns:: How to define patterns for special looping insns. 18482* Insn Canonicalizations::Canonicalization of Instructions 18483* Expander Definitions::Generating a sequence of several RTL insns 18484 for a standard operation. 18485* Insn Splitting:: Splitting Instructions into Multiple Instructions. 18486* Including Patterns:: Including Patterns in Machine Descriptions. 18487* Peephole Definitions::Defining machine-specific peephole optimizations. 18488* Insn Attributes:: Specifying the value of attributes for generated insns. 18489* Conditional Execution::Generating 'define_insn' patterns for 18490 predication. 18491* Define Subst:: Generating 'define_insn' and 'define_expand' 18492 patterns from other patterns. 18493* Constant Definitions::Defining symbolic constants that can be used in the 18494 md file. 18495* Iterators:: Using iterators to generate patterns from a template. 18496 18497 18498File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 18499 1850016.1 Overview of How the Machine Description is Used 18501==================================================== 18502 18503There are three main conversions that happen in the compiler: 18504 18505 1. The front end reads the source code and builds a parse tree. 18506 18507 2. The parse tree is used to generate an RTL insn list based on named 18508 instruction patterns. 18509 18510 3. The insn list is matched against the RTL templates to produce 18511 assembler code. 18512 18513 For the generate pass, only the names of the insns matter, from either 18514a named 'define_insn' or a 'define_expand'. The compiler will choose 18515the pattern with the right name and apply the operands according to the 18516documentation later in this chapter, without regard for the RTL template 18517or operand constraints. Note that the names the compiler looks for are 18518hard-coded in the compiler--it will ignore unnamed patterns and patterns 18519with names it doesn't know about, but if you don't provide a named 18520pattern it needs, it will abort. 18521 18522 If a 'define_insn' is used, the template given is inserted into the 18523insn list. If a 'define_expand' is used, one of three things happens, 18524based on the condition logic. The condition logic may manually create 18525new insns for the insn list, say via 'emit_insn()', and invoke 'DONE'. 18526For certain named patterns, it may invoke 'FAIL' to tell the compiler to 18527use an alternate way of performing that task. If it invokes neither 18528'DONE' nor 'FAIL', the template given in the pattern is inserted, as if 18529the 'define_expand' were a 'define_insn'. 18530 18531 Once the insn list is generated, various optimization passes convert, 18532replace, and rearrange the insns in the insn list. This is where the 18533'define_split' and 'define_peephole' patterns get used, for example. 18534 18535 Finally, the insn list's RTL is matched up with the RTL templates in 18536the 'define_insn' patterns, and those patterns are used to emit the 18537final assembly code. For this purpose, each named 'define_insn' acts 18538like it's unnamed, since the names are ignored. 18539 18540 18541File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 18542 1854316.2 Everything about Instruction Patterns 18544========================================== 18545 18546A 'define_insn' expression is used to define instruction patterns to 18547which insns may be matched. A 'define_insn' expression contains an 18548incomplete RTL expression, with pieces to be filled in later, operand 18549constraints that restrict how the pieces can be filled in, and an output 18550template or C code to generate the assembler output. 18551 18552 A 'define_insn' is an RTL expression containing four or five operands: 18553 18554 1. An optional name. The presence of a name indicate that this 18555 instruction pattern can perform a certain standard job for the 18556 RTL-generation pass of the compiler. This pass knows certain names 18557 and will use the instruction patterns with those names, if the 18558 names are defined in the machine description. 18559 18560 The absence of a name is indicated by writing an empty string where 18561 the name should go. Nameless instruction patterns are never used 18562 for generating RTL code, but they may permit several simpler insns 18563 to be combined later on. 18564 18565 Names that are not thus known and used in RTL-generation have no 18566 effect; they are equivalent to no name at all. 18567 18568 For the purpose of debugging the compiler, you may also specify a 18569 name beginning with the '*' character. Such a name is used only 18570 for identifying the instruction in RTL dumps; it is equivalent to 18571 having a nameless pattern for all other purposes. Names beginning 18572 with the '*' character are not required to be unique. 18573 18574 2. The "RTL template": This is a vector of incomplete RTL expressions 18575 which describe the semantics of the instruction (*note RTL 18576 Template::). It is incomplete because it may contain 18577 'match_operand', 'match_operator', and 'match_dup' expressions that 18578 stand for operands of the instruction. 18579 18580 If the vector has multiple elements, the RTL template is treated as 18581 a 'parallel' expression. 18582 18583 3. The condition: This is a string which contains a C expression. 18584 When the compiler attempts to match RTL against a pattern, the 18585 condition is evaluated. If the condition evaluates to 'true', the 18586 match is permitted. The condition may be an empty string, which is 18587 treated as always 'true'. 18588 18589 For a named pattern, the condition may not depend on the data in 18590 the insn being matched, but only the target-machine-type flags. 18591 The compiler needs to test these conditions during initialization 18592 in order to learn exactly which named instructions are available in 18593 a particular run. 18594 18595 For nameless patterns, the condition is applied only when matching 18596 an individual insn, and only after the insn has matched the 18597 pattern's recognition template. The insn's operands may be found 18598 in the vector 'operands'. 18599 18600 For an insn where the condition has once matched, it cannot later 18601 be used to control register allocation by excluding certain 18602 register or value combinations. 18603 18604 4. The "output template" or "output statement": This is either a 18605 string, or a fragment of C code which returns a string. 18606 18607 When simple substitution isn't general enough, you can specify a 18608 piece of C code to compute the output. *Note Output Statement::. 18609 18610 5. The "insn attributes": This is an optional vector containing the 18611 values of attributes for insns matching this pattern (*note Insn 18612 Attributes::). 18613 18614 18615File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 18616 1861716.3 Example of 'define_insn' 18618============================= 18619 18620Here is an example of an instruction pattern, taken from the machine 18621description for the 68000/68020. 18622 18623 (define_insn "tstsi" 18624 [(set (cc0) 18625 (match_operand:SI 0 "general_operand" "rm"))] 18626 "" 18627 "* 18628 { 18629 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 18630 return \"tstl %0\"; 18631 return \"cmpl #0,%0\"; 18632 }") 18633 18634This can also be written using braced strings: 18635 18636 (define_insn "tstsi" 18637 [(set (cc0) 18638 (match_operand:SI 0 "general_operand" "rm"))] 18639 "" 18640 { 18641 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 18642 return "tstl %0"; 18643 return "cmpl #0,%0"; 18644 }) 18645 18646 This describes an instruction which sets the condition codes based on 18647the value of a general operand. It has no condition, so any insn with 18648an RTL description of the form shown may be matched to this pattern. 18649The name 'tstsi' means "test a 'SImode' value" and tells the RTL 18650generation pass that, when it is necessary to test such a value, an insn 18651to do so can be constructed using this pattern. 18652 18653 The output control string is a piece of C code which chooses which 18654output template to return based on the kind of operand and the specific 18655type of CPU for which code is being generated. 18656 18657 '"rm"' is an operand constraint. Its meaning is explained below. 18658 18659 18660File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 18661 1866216.4 RTL Template 18663================= 18664 18665The RTL template is used to define which insns match the particular 18666pattern and how to find their operands. For named patterns, the RTL 18667template also says how to construct an insn from specified operands. 18668 18669 Construction involves substituting specified operands into a copy of 18670the template. Matching involves determining the values that serve as 18671the operands in the insn being matched. Both of these activities are 18672controlled by special expression types that direct matching and 18673substitution of the operands. 18674 18675'(match_operand:M N PREDICATE CONSTRAINT)' 18676 This expression is a placeholder for operand number N of the insn. 18677 When constructing an insn, operand number N will be substituted at 18678 this point. When matching an insn, whatever appears at this 18679 position in the insn will be taken as operand number N; but it must 18680 satisfy PREDICATE or this instruction pattern will not match at 18681 all. 18682 18683 Operand numbers must be chosen consecutively counting from zero in 18684 each instruction pattern. There may be only one 'match_operand' 18685 expression in the pattern for each operand number. Usually 18686 operands are numbered in the order of appearance in 'match_operand' 18687 expressions. In the case of a 'define_expand', any operand numbers 18688 used only in 'match_dup' expressions have higher values than all 18689 other operand numbers. 18690 18691 PREDICATE is a string that is the name of a function that accepts 18692 two arguments, an expression and a machine mode. *Note 18693 Predicates::. During matching, the function will be called with 18694 the putative operand as the expression and M as the mode argument 18695 (if M is not specified, 'VOIDmode' will be used, which normally 18696 causes PREDICATE to accept any mode). If it returns zero, this 18697 instruction pattern fails to match. PREDICATE may be an empty 18698 string; then it means no test is to be done on the operand, so 18699 anything which occurs in this position is valid. 18700 18701 Most of the time, PREDICATE will reject modes other than M--but not 18702 always. For example, the predicate 'address_operand' uses M as the 18703 mode of memory ref that the address should be valid for. Many 18704 predicates accept 'const_int' nodes even though their mode is 18705 'VOIDmode'. 18706 18707 CONSTRAINT controls reloading and the choice of the best register 18708 class to use for a value, as explained later (*note Constraints::). 18709 If the constraint would be an empty string, it can be omitted. 18710 18711 People are often unclear on the difference between the constraint 18712 and the predicate. The predicate helps decide whether a given insn 18713 matches the pattern. The constraint plays no role in this 18714 decision; instead, it controls various decisions in the case of an 18715 insn which does match. 18716 18717'(match_scratch:M N CONSTRAINT)' 18718 This expression is also a placeholder for operand number N and 18719 indicates that operand must be a 'scratch' or 'reg' expression. 18720 18721 When matching patterns, this is equivalent to 18722 18723 (match_operand:M N "scratch_operand" CONSTRAINT) 18724 18725 but, when generating RTL, it produces a ('scratch':M) expression. 18726 18727 If the last few expressions in a 'parallel' are 'clobber' 18728 expressions whose operands are either a hard register or 18729 'match_scratch', the combiner can add or delete them when 18730 necessary. *Note Side Effects::. 18731 18732'(match_dup N)' 18733 This expression is also a placeholder for operand number N. It is 18734 used when the operand needs to appear more than once in the insn. 18735 18736 In construction, 'match_dup' acts just like 'match_operand': the 18737 operand is substituted into the insn being constructed. But in 18738 matching, 'match_dup' behaves differently. It assumes that operand 18739 number N has already been determined by a 'match_operand' appearing 18740 earlier in the recognition template, and it matches only an 18741 identical-looking expression. 18742 18743 Note that 'match_dup' should not be used to tell the compiler that 18744 a particular register is being used for two operands (example: 18745 'add' that adds one register to another; the second register is 18746 both an input operand and the output operand). Use a matching 18747 constraint (*note Simple Constraints::) for those. 'match_dup' is 18748 for the cases where one operand is used in two places in the 18749 template, such as an instruction that computes both a quotient and 18750 a remainder, where the opcode takes two input operands but the RTL 18751 template has to refer to each of those twice; once for the quotient 18752 pattern and once for the remainder pattern. 18753 18754'(match_operator:M N PREDICATE [OPERANDS...])' 18755 This pattern is a kind of placeholder for a variable RTL expression 18756 code. 18757 18758 When constructing an insn, it stands for an RTL expression whose 18759 expression code is taken from that of operand N, and whose operands 18760 are constructed from the patterns OPERANDS. 18761 18762 When matching an expression, it matches an expression if the 18763 function PREDICATE returns nonzero on that expression _and_ the 18764 patterns OPERANDS match the operands of the expression. 18765 18766 Suppose that the function 'commutative_operator' is defined as 18767 follows, to match any expression whose operator is one of the 18768 commutative arithmetic operators of RTL and whose mode is MODE: 18769 18770 int 18771 commutative_integer_operator (x, mode) 18772 rtx x; 18773 machine_mode mode; 18774 { 18775 enum rtx_code code = GET_CODE (x); 18776 if (GET_MODE (x) != mode) 18777 return 0; 18778 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 18779 || code == EQ || code == NE); 18780 } 18781 18782 Then the following pattern will match any RTL expression consisting 18783 of a commutative operator applied to two general operands: 18784 18785 (match_operator:SI 3 "commutative_operator" 18786 [(match_operand:SI 1 "general_operand" "g") 18787 (match_operand:SI 2 "general_operand" "g")]) 18788 18789 Here the vector '[OPERANDS...]' contains two patterns because the 18790 expressions to be matched all contain two operands. 18791 18792 When this pattern does match, the two operands of the commutative 18793 operator are recorded as operands 1 and 2 of the insn. (This is 18794 done by the two instances of 'match_operand'.) Operand 3 of the 18795 insn will be the entire commutative expression: use 'GET_CODE 18796 (operands[3])' to see which commutative operator was used. 18797 18798 The machine mode M of 'match_operator' works like that of 18799 'match_operand': it is passed as the second argument to the 18800 predicate function, and that function is solely responsible for 18801 deciding whether the expression to be matched "has" that mode. 18802 18803 When constructing an insn, argument 3 of the gen-function will 18804 specify the operation (i.e. the expression code) for the expression 18805 to be made. It should be an RTL expression, whose expression code 18806 is copied into a new expression whose operands are arguments 1 and 18807 2 of the gen-function. The subexpressions of argument 3 are not 18808 used; only its expression code matters. 18809 18810 When 'match_operator' is used in a pattern for matching an insn, it 18811 usually best if the operand number of the 'match_operator' is 18812 higher than that of the actual operands of the insn. This improves 18813 register allocation because the register allocator often looks at 18814 operands 1 and 2 of insns to see if it can do register tying. 18815 18816 There is no way to specify constraints in 'match_operator'. The 18817 operand of the insn which corresponds to the 'match_operator' never 18818 has any constraints because it is never reloaded as a whole. 18819 However, if parts of its OPERANDS are matched by 'match_operand' 18820 patterns, those parts may have constraints of their own. 18821 18822'(match_op_dup:M N[OPERANDS...])' 18823 Like 'match_dup', except that it applies to operators instead of 18824 operands. When constructing an insn, operand number N will be 18825 substituted at this point. But in matching, 'match_op_dup' behaves 18826 differently. It assumes that operand number N has already been 18827 determined by a 'match_operator' appearing earlier in the 18828 recognition template, and it matches only an identical-looking 18829 expression. 18830 18831'(match_parallel N PREDICATE [SUBPAT...])' 18832 This pattern is a placeholder for an insn that consists of a 18833 'parallel' expression with a variable number of elements. This 18834 expression should only appear at the top level of an insn pattern. 18835 18836 When constructing an insn, operand number N will be substituted at 18837 this point. When matching an insn, it matches if the body of the 18838 insn is a 'parallel' expression with at least as many elements as 18839 the vector of SUBPAT expressions in the 'match_parallel', if each 18840 SUBPAT matches the corresponding element of the 'parallel', _and_ 18841 the function PREDICATE returns nonzero on the 'parallel' that is 18842 the body of the insn. It is the responsibility of the predicate to 18843 validate elements of the 'parallel' beyond those listed in the 18844 'match_parallel'. 18845 18846 A typical use of 'match_parallel' is to match load and store 18847 multiple expressions, which can contain a variable number of 18848 elements in a 'parallel'. For example, 18849 18850 (define_insn "" 18851 [(match_parallel 0 "load_multiple_operation" 18852 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 18853 (match_operand:SI 2 "memory_operand" "m")) 18854 (use (reg:SI 179)) 18855 (clobber (reg:SI 179))])] 18856 "" 18857 "loadm 0,0,%1,%2") 18858 18859 This example comes from 'a29k.md'. The function 18860 'load_multiple_operation' is defined in 'a29k.c' and checks that 18861 subsequent elements in the 'parallel' are the same as the 'set' in 18862 the pattern, except that they are referencing subsequent registers 18863 and memory locations. 18864 18865 An insn that matches this pattern might look like: 18866 18867 (parallel 18868 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 18869 (use (reg:SI 179)) 18870 (clobber (reg:SI 179)) 18871 (set (reg:SI 21) 18872 (mem:SI (plus:SI (reg:SI 100) 18873 (const_int 4)))) 18874 (set (reg:SI 22) 18875 (mem:SI (plus:SI (reg:SI 100) 18876 (const_int 8))))]) 18877 18878'(match_par_dup N [SUBPAT...])' 18879 Like 'match_op_dup', but for 'match_parallel' instead of 18880 'match_operator'. 18881 18882 18883File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 18884 1888516.5 Output Templates and Operand Substitution 18886============================================== 18887 18888The "output template" is a string which specifies how to output the 18889assembler code for an instruction pattern. Most of the template is a 18890fixed string which is output literally. The character '%' is used to 18891specify where to substitute an operand; it can also be used to identify 18892places where different variants of the assembler require different 18893syntax. 18894 18895 In the simplest case, a '%' followed by a digit N says to output 18896operand N at that point in the string. 18897 18898 '%' followed by a letter and a digit says to output an operand in an 18899alternate fashion. Four letters have standard, built-in meanings 18900described below. The machine description macro 'PRINT_OPERAND' can 18901define additional letters with nonstandard meanings. 18902 18903 '%cDIGIT' can be used to substitute an operand that is a constant value 18904without the syntax that normally indicates an immediate operand. 18905 18906 '%nDIGIT' is like '%cDIGIT' except that the value of the constant is 18907negated before printing. 18908 18909 '%aDIGIT' can be used to substitute an operand as if it were a memory 18910reference, with the actual operand treated as the address. This may be 18911useful when outputting a "load address" instruction, because often the 18912assembler syntax for such an instruction requires you to write the 18913operand as if it were a memory reference. 18914 18915 '%lDIGIT' is used to substitute a 'label_ref' into a jump instruction. 18916 18917 '%=' outputs a number which is unique to each instruction in the entire 18918compilation. This is useful for making local labels to be referred to 18919more than once in a single template that generates multiple assembler 18920instructions. 18921 18922 '%' followed by a punctuation character specifies a substitution that 18923does not use an operand. Only one case is standard: '%%' outputs a '%' 18924into the assembler code. Other nonstandard cases can be defined in the 18925'PRINT_OPERAND' macro. You must also define which punctuation 18926characters are valid with the 'PRINT_OPERAND_PUNCT_VALID_P' macro. 18927 18928 The template may generate multiple assembler instructions. Write the 18929text for the instructions, with '\;' between them. 18930 18931 When the RTL contains two operands which are required by constraint to 18932match each other, the output template must refer only to the 18933lower-numbered operand. Matching operands are not always identical, and 18934the rest of the compiler arranges to put the proper RTL expression for 18935printing into the lower-numbered operand. 18936 18937 One use of nonstandard letters or punctuation following '%' is to 18938distinguish between different assembler languages for the same machine; 18939for example, Motorola syntax versus MIT syntax for the 68000. Motorola 18940syntax requires periods in most opcode names, while MIT syntax does not. 18941For example, the opcode 'movel' in MIT syntax is 'move.l' in Motorola 18942syntax. The same file of patterns is used for both kinds of output 18943syntax, but the character sequence '%.' is used in each place where 18944Motorola syntax wants a period. The 'PRINT_OPERAND' macro for Motorola 18945syntax defines the sequence to output a period; the macro for MIT syntax 18946defines it to do nothing. 18947 18948 As a special case, a template consisting of the single character '#' 18949instructs the compiler to first split the insn, and then output the 18950resulting instructions separately. This helps eliminate redundancy in 18951the output templates. If you have a 'define_insn' that needs to emit 18952multiple assembler instructions, and there is a matching 'define_split' 18953already defined, then you can simply use '#' as the output template 18954instead of writing an output template that emits the multiple assembler 18955instructions. 18956 18957 If the macro 'ASSEMBLER_DIALECT' is defined, you can use construct of 18958the form '{option0|option1|option2}' in the templates. These describe 18959multiple variants of assembler language syntax. *Note Instruction 18960Output::. 18961 18962 18963File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 18964 1896516.6 C Statements for Assembler Output 18966====================================== 18967 18968Often a single fixed template string cannot produce correct and 18969efficient assembler code for all the cases that are recognized by a 18970single instruction pattern. For example, the opcodes may depend on the 18971kinds of operands; or some unfortunate combinations of operands may 18972require extra machine instructions. 18973 18974 If the output control string starts with a '@', then it is actually a 18975series of templates, each on a separate line. (Blank lines and leading 18976spaces and tabs are ignored.) The templates correspond to the pattern's 18977constraint alternatives (*note Multi-Alternative::). For example, if a 18978target machine has a two-address add instruction 'addr' to add into a 18979register and another 'addm' to add a register to memory, you might write 18980this pattern: 18981 18982 (define_insn "addsi3" 18983 [(set (match_operand:SI 0 "general_operand" "=r,m") 18984 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 18985 (match_operand:SI 2 "general_operand" "g,r")))] 18986 "" 18987 "@ 18988 addr %2,%0 18989 addm %2,%0") 18990 18991 If the output control string starts with a '*', then it is not an 18992output template but rather a piece of C program that should compute a 18993template. It should execute a 'return' statement to return the 18994template-string you want. Most such templates use C string literals, 18995which require doublequote characters to delimit them. To include these 18996doublequote characters in the string, prefix each one with '\'. 18997 18998 If the output control string is written as a brace block instead of a 18999double-quoted string, it is automatically assumed to be C code. In that 19000case, it is not necessary to put in a leading asterisk, or to escape the 19001doublequotes surrounding C string literals. 19002 19003 The operands may be found in the array 'operands', whose C data type is 19004'rtx []'. 19005 19006 It is very common to select different ways of generating assembler code 19007based on whether an immediate operand is within a certain range. Be 19008careful when doing this, because the result of 'INTVAL' is an integer on 19009the host machine. If the host machine has more bits in an 'int' than 19010the target machine has in the mode in which the constant will be used, 19011then some of the bits you get from 'INTVAL' will be superfluous. For 19012proper results, you must carefully disregard the values of those bits. 19013 19014 It is possible to output an assembler instruction and then go on to 19015output or compute more of them, using the subroutine 'output_asm_insn'. 19016This receives two arguments: a template-string and a vector of operands. 19017The vector may be 'operands', or it may be another array of 'rtx' that 19018you declare locally and initialize yourself. 19019 19020 When an insn pattern has multiple alternatives in its constraints, 19021often the appearance of the assembler code is determined mostly by which 19022alternative was matched. When this is so, the C code can test the 19023variable 'which_alternative', which is the ordinal number of the 19024alternative that was actually satisfied (0 for the first, 1 for the 19025second alternative, etc.). 19026 19027 For example, suppose there are two opcodes for storing zero, 'clrreg' 19028for registers and 'clrmem' for memory locations. Here is how a pattern 19029could use 'which_alternative' to choose between them: 19030 19031 (define_insn "" 19032 [(set (match_operand:SI 0 "general_operand" "=r,m") 19033 (const_int 0))] 19034 "" 19035 { 19036 return (which_alternative == 0 19037 ? "clrreg %0" : "clrmem %0"); 19038 }) 19039 19040 The example above, where the assembler code to generate was _solely_ 19041determined by the alternative, could also have been specified as 19042follows, having the output control string start with a '@': 19043 19044 (define_insn "" 19045 [(set (match_operand:SI 0 "general_operand" "=r,m") 19046 (const_int 0))] 19047 "" 19048 "@ 19049 clrreg %0 19050 clrmem %0") 19051 19052 If you just need a little bit of C code in one (or a few) alternatives, 19053you can use '*' inside of a '@' multi-alternative template: 19054 19055 (define_insn "" 19056 [(set (match_operand:SI 0 "general_operand" "=r,<,m") 19057 (const_int 0))] 19058 "" 19059 "@ 19060 clrreg %0 19061 * return stack_mem_p (operands[0]) ? \"push 0\" : \"clrmem %0\"; 19062 clrmem %0") 19063 19064 19065File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 19066 1906716.7 Predicates 19068=============== 19069 19070A predicate determines whether a 'match_operand' or 'match_operator' 19071expression matches, and therefore whether the surrounding instruction 19072pattern will be used for that combination of operands. GCC has a number 19073of machine-independent predicates, and you can define machine-specific 19074predicates as needed. By convention, predicates used with 19075'match_operand' have names that end in '_operand', and those used with 19076'match_operator' have names that end in '_operator'. 19077 19078 All predicates are Boolean functions (in the mathematical sense) of two 19079arguments: the RTL expression that is being considered at that position 19080in the instruction pattern, and the machine mode that the 19081'match_operand' or 'match_operator' specifies. In this section, the 19082first argument is called OP and the second argument MODE. Predicates 19083can be called from C as ordinary two-argument functions; this can be 19084useful in output templates or other machine-specific code. 19085 19086 Operand predicates can allow operands that are not actually acceptable 19087to the hardware, as long as the constraints give reload the ability to 19088fix them up (*note Constraints::). However, GCC will usually generate 19089better code if the predicates specify the requirements of the machine 19090instructions as closely as possible. Reload cannot fix up operands that 19091must be constants ("immediate operands"); you must use a predicate that 19092allows only constants, or else enforce the requirement in the extra 19093condition. 19094 19095 Most predicates handle their MODE argument in a uniform manner. If 19096MODE is 'VOIDmode' (unspecified), then OP can have any mode. If MODE is 19097anything else, then OP must have the same mode, unless OP is a 19098'CONST_INT' or integer 'CONST_DOUBLE'. These RTL expressions always 19099have 'VOIDmode', so it would be counterproductive to check that their 19100mode matches. Instead, predicates that accept 'CONST_INT' and/or 19101integer 'CONST_DOUBLE' check that the value stored in the constant will 19102fit in the requested mode. 19103 19104 Predicates with this behavior are called "normal". 'genrecog' can 19105optimize the instruction recognizer based on knowledge of how normal 19106predicates treat modes. It can also diagnose certain kinds of common 19107errors in the use of normal predicates; for instance, it is almost 19108always an error to use a normal predicate without specifying a mode. 19109 19110 Predicates that do something different with their MODE argument are 19111called "special". The generic predicates 'address_operand' and 19112'pmode_register_operand' are special predicates. 'genrecog' does not do 19113any optimizations or diagnosis when special predicates are used. 19114 19115* Menu: 19116 19117* Machine-Independent Predicates:: Predicates available to all back ends. 19118* Defining Predicates:: How to write machine-specific predicate 19119 functions. 19120 19121 19122File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 19123 1912416.7.1 Machine-Independent Predicates 19125------------------------------------- 19126 19127These are the generic predicates available to all back ends. They are 19128defined in 'recog.c'. The first category of predicates allow only 19129constant, or "immediate", operands. 19130 19131 -- Function: immediate_operand 19132 This predicate allows any sort of constant that fits in MODE. It 19133 is an appropriate choice for instructions that take operands that 19134 must be constant. 19135 19136 -- Function: const_int_operand 19137 This predicate allows any 'CONST_INT' expression that fits in MODE. 19138 It is an appropriate choice for an immediate operand that does not 19139 allow a symbol or label. 19140 19141 -- Function: const_double_operand 19142 This predicate accepts any 'CONST_DOUBLE' expression that has 19143 exactly MODE. If MODE is 'VOIDmode', it will also accept 19144 'CONST_INT'. It is intended for immediate floating point 19145 constants. 19146 19147The second category of predicates allow only some kind of machine 19148register. 19149 19150 -- Function: register_operand 19151 This predicate allows any 'REG' or 'SUBREG' expression that is 19152 valid for MODE. It is often suitable for arithmetic instruction 19153 operands on a RISC machine. 19154 19155 -- Function: pmode_register_operand 19156 This is a slight variant on 'register_operand' which works around a 19157 limitation in the machine-description reader. 19158 19159 (match_operand N "pmode_register_operand" CONSTRAINT) 19160 19161 means exactly what 19162 19163 (match_operand:P N "register_operand" CONSTRAINT) 19164 19165 would mean, if the machine-description reader accepted ':P' mode 19166 suffixes. Unfortunately, it cannot, because 'Pmode' is an alias 19167 for some other mode, and might vary with machine-specific options. 19168 *Note Misc::. 19169 19170 -- Function: scratch_operand 19171 This predicate allows hard registers and 'SCRATCH' expressions, but 19172 not pseudo-registers. It is used internally by 'match_scratch'; it 19173 should not be used directly. 19174 19175The third category of predicates allow only some kind of memory 19176reference. 19177 19178 -- Function: memory_operand 19179 This predicate allows any valid reference to a quantity of mode 19180 MODE in memory, as determined by the weak form of 19181 'GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 19182 19183 -- Function: address_operand 19184 This predicate is a little unusual; it allows any operand that is a 19185 valid expression for the _address_ of a quantity of mode MODE, 19186 again determined by the weak form of 'GO_IF_LEGITIMATE_ADDRESS'. 19187 To first order, if '(mem:MODE (EXP))' is acceptable to 19188 'memory_operand', then EXP is acceptable to 'address_operand'. 19189 Note that EXP does not necessarily have the mode MODE. 19190 19191 -- Function: indirect_operand 19192 This is a stricter form of 'memory_operand' which allows only 19193 memory references with a 'general_operand' as the address 19194 expression. New uses of this predicate are discouraged, because 19195 'general_operand' is very permissive, so it's hard to tell what an 19196 'indirect_operand' does or does not allow. If a target has 19197 different requirements for memory operands for different 19198 instructions, it is better to define target-specific predicates 19199 which enforce the hardware's requirements explicitly. 19200 19201 -- Function: push_operand 19202 This predicate allows a memory reference suitable for pushing a 19203 value onto the stack. This will be a 'MEM' which refers to 19204 'stack_pointer_rtx', with a side-effect in its address expression 19205 (*note Incdec::); which one is determined by the 'STACK_PUSH_CODE' 19206 macro (*note Frame Layout::). 19207 19208 -- Function: pop_operand 19209 This predicate allows a memory reference suitable for popping a 19210 value off the stack. Again, this will be a 'MEM' referring to 19211 'stack_pointer_rtx', with a side-effect in its address expression. 19212 However, this time 'STACK_POP_CODE' is expected. 19213 19214The fourth category of predicates allow some combination of the above 19215operands. 19216 19217 -- Function: nonmemory_operand 19218 This predicate allows any immediate or register operand valid for 19219 MODE. 19220 19221 -- Function: nonimmediate_operand 19222 This predicate allows any register or memory operand valid for 19223 MODE. 19224 19225 -- Function: general_operand 19226 This predicate allows any immediate, register, or memory operand 19227 valid for MODE. 19228 19229Finally, there are two generic operator predicates. 19230 19231 -- Function: comparison_operator 19232 This predicate matches any expression which performs an arithmetic 19233 comparison in MODE; that is, 'COMPARISON_P' is true for the 19234 expression code. 19235 19236 -- Function: ordered_comparison_operator 19237 This predicate matches any expression which performs an arithmetic 19238 comparison in MODE and whose expression code is valid for integer 19239 modes; that is, the expression code will be one of 'eq', 'ne', 19240 'lt', 'ltu', 'le', 'leu', 'gt', 'gtu', 'ge', 'geu'. 19241 19242 19243File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 19244 1924516.7.2 Defining Machine-Specific Predicates 19246------------------------------------------- 19247 19248Many machines have requirements for their operands that cannot be 19249expressed precisely using the generic predicates. You can define 19250additional predicates using 'define_predicate' and 19251'define_special_predicate' expressions. These expressions have three 19252operands: 19253 19254 * The name of the predicate, as it will be referred to in 19255 'match_operand' or 'match_operator' expressions. 19256 19257 * An RTL expression which evaluates to true if the predicate allows 19258 the operand OP, false if it does not. This expression can only use 19259 the following RTL codes: 19260 19261 'MATCH_OPERAND' 19262 When written inside a predicate expression, a 'MATCH_OPERAND' 19263 expression evaluates to true if the predicate it names would 19264 allow OP. The operand number and constraint are ignored. Due 19265 to limitations in 'genrecog', you can only refer to generic 19266 predicates and predicates that have already been defined. 19267 19268 'MATCH_CODE' 19269 This expression evaluates to true if OP or a specified 19270 subexpression of OP has one of a given list of RTX codes. 19271 19272 The first operand of this expression is a string constant 19273 containing a comma-separated list of RTX code names (in lower 19274 case). These are the codes for which the 'MATCH_CODE' will be 19275 true. 19276 19277 The second operand is a string constant which indicates what 19278 subexpression of OP to examine. If it is absent or the empty 19279 string, OP itself is examined. Otherwise, the string constant 19280 must be a sequence of digits and/or lowercase letters. Each 19281 character indicates a subexpression to extract from the 19282 current expression; for the first character this is OP, for 19283 the second and subsequent characters it is the result of the 19284 previous character. A digit N extracts 'XEXP (E, N)'; a 19285 letter L extracts 'XVECEXP (E, 0, N)' where N is the 19286 alphabetic ordinal of L (0 for 'a', 1 for 'b', and so on). 19287 The 'MATCH_CODE' then examines the RTX code of the 19288 subexpression extracted by the complete string. It is not 19289 possible to extract components of an 'rtvec' that is not at 19290 position 0 within its RTX object. 19291 19292 'MATCH_TEST' 19293 This expression has one operand, a string constant containing 19294 a C expression. The predicate's arguments, OP and MODE, are 19295 available with those names in the C expression. The 19296 'MATCH_TEST' evaluates to true if the C expression evaluates 19297 to a nonzero value. 'MATCH_TEST' expressions must not have 19298 side effects. 19299 19300 'AND' 19301 'IOR' 19302 'NOT' 19303 'IF_THEN_ELSE' 19304 The basic 'MATCH_' expressions can be combined using these 19305 logical operators, which have the semantics of the C operators 19306 '&&', '||', '!', and '? :' respectively. As in Common Lisp, 19307 you may give an 'AND' or 'IOR' expression an arbitrary number 19308 of arguments; this has exactly the same effect as writing a 19309 chain of two-argument 'AND' or 'IOR' expressions. 19310 19311 * An optional block of C code, which should execute 'return true' if 19312 the predicate is found to match and 'return false' if it does not. 19313 It must not have any side effects. The predicate arguments, OP and 19314 MODE, are available with those names. 19315 19316 If a code block is present in a predicate definition, then the RTL 19317 expression must evaluate to true _and_ the code block must execute 19318 'return true' for the predicate to allow the operand. The RTL 19319 expression is evaluated first; do not re-check anything in the code 19320 block that was checked in the RTL expression. 19321 19322 The program 'genrecog' scans 'define_predicate' and 19323'define_special_predicate' expressions to determine which RTX codes are 19324possibly allowed. You should always make this explicit in the RTL 19325predicate expression, using 'MATCH_OPERAND' and 'MATCH_CODE'. 19326 19327 Here is an example of a simple predicate definition, from the IA64 19328machine description: 19329 19330 ;; True if OP is a 'SYMBOL_REF' which refers to the sdata section. 19331 (define_predicate "small_addr_symbolic_operand" 19332 (and (match_code "symbol_ref") 19333 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 19334 19335And here is another, showing the use of the C block. 19336 19337 ;; True if OP is a register operand that is (or could be) a GR reg. 19338 (define_predicate "gr_register_operand" 19339 (match_operand 0 "register_operand") 19340 { 19341 unsigned int regno; 19342 if (GET_CODE (op) == SUBREG) 19343 op = SUBREG_REG (op); 19344 19345 regno = REGNO (op); 19346 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 19347 }) 19348 19349 Predicates written with 'define_predicate' automatically include a test 19350that MODE is 'VOIDmode', or OP has the same mode as MODE, or OP is a 19351'CONST_INT' or 'CONST_DOUBLE'. They do _not_ check specifically for 19352integer 'CONST_DOUBLE', nor do they test that the value of either kind 19353of constant fits in the requested mode. This is because target-specific 19354predicates that take constants usually have to do more stringent value 19355checks anyway. If you need the exact same treatment of 'CONST_INT' or 19356'CONST_DOUBLE' that the generic predicates provide, use a 19357'MATCH_OPERAND' subexpression to call 'const_int_operand', 19358'const_double_operand', or 'immediate_operand'. 19359 19360 Predicates written with 'define_special_predicate' do not get any 19361automatic mode checks, and are treated as having special mode handling 19362by 'genrecog'. 19363 19364 The program 'genpreds' is responsible for generating code to test 19365predicates. It also writes a header file containing function 19366declarations for all machine-specific predicates. It is not necessary 19367to declare these predicates in 'CPU-protos.h'. 19368 19369 19370File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 19371 1937216.8 Operand Constraints 19373======================== 19374 19375Each 'match_operand' in an instruction pattern can specify constraints 19376for the operands allowed. The constraints allow you to fine-tune 19377matching within the set of operands allowed by the predicate. 19378 19379 Constraints can say whether an operand may be in a register, and which 19380kinds of register; whether the operand can be a memory reference, and 19381which kinds of address; whether the operand may be an immediate 19382constant, and which possible values it may have. Constraints can also 19383require two operands to match. Side-effects aren't allowed in operands 19384of inline 'asm', unless '<' or '>' constraints are used, because there 19385is no guarantee that the side-effects will happen exactly once in an 19386instruction that can update the addressing register. 19387 19388* Menu: 19389 19390* Simple Constraints:: Basic use of constraints. 19391* Multi-Alternative:: When an insn has two alternative constraint-patterns. 19392* Class Preferences:: Constraints guide which hard register to put things in. 19393* Modifiers:: More precise control over effects of constraints. 19394* Machine Constraints:: Existing constraints for some particular machines. 19395* Disable Insn Alternatives:: Disable insn alternatives using attributes. 19396* Define Constraints:: How to define machine-specific constraints. 19397* C Constraint Interface:: How to test constraints from C code. 19398 19399 19400File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 19401 1940216.8.1 Simple Constraints 19403------------------------- 19404 19405The simplest kind of constraint is a string full of letters, each of 19406which describes one kind of operand that is permitted. Here are the 19407letters that are allowed: 19408 19409whitespace 19410 Whitespace characters are ignored and can be inserted at any 19411 position except the first. This enables each alternative for 19412 different operands to be visually aligned in the machine 19413 description even if they have different number of constraints and 19414 modifiers. 19415 19416'm' 19417 A memory operand is allowed, with any kind of address that the 19418 machine supports in general. Note that the letter used for the 19419 general memory constraint can be re-defined by a back end using the 19420 'TARGET_MEM_CONSTRAINT' macro. 19421 19422'o' 19423 A memory operand is allowed, but only if the address is 19424 "offsettable". This means that adding a small integer (actually, 19425 the width in bytes of the operand, as determined by its machine 19426 mode) may be added to the address and the result is also a valid 19427 memory address. 19428 19429 For example, an address which is constant is offsettable; so is an 19430 address that is the sum of a register and a constant (as long as a 19431 slightly larger constant is also within the range of 19432 address-offsets supported by the machine); but an autoincrement or 19433 autodecrement address is not offsettable. More complicated 19434 indirect/indexed addresses may or may not be offsettable depending 19435 on the other addressing modes that the machine supports. 19436 19437 Note that in an output operand which can be matched by another 19438 operand, the constraint letter 'o' is valid only when accompanied 19439 by both '<' (if the target machine has predecrement addressing) and 19440 '>' (if the target machine has preincrement addressing). 19441 19442'V' 19443 A memory operand that is not offsettable. In other words, anything 19444 that would fit the 'm' constraint but not the 'o' constraint. 19445 19446'<' 19447 A memory operand with autodecrement addressing (either predecrement 19448 or postdecrement) is allowed. In inline 'asm' this constraint is 19449 only allowed if the operand is used exactly once in an instruction 19450 that can handle the side-effects. Not using an operand with '<' in 19451 constraint string in the inline 'asm' pattern at all or using it in 19452 multiple instructions isn't valid, because the side-effects 19453 wouldn't be performed or would be performed more than once. 19454 Furthermore, on some targets the operand with '<' in constraint 19455 string must be accompanied by special instruction suffixes like 19456 '%U0' instruction suffix on PowerPC or '%P0' on IA-64. 19457 19458'>' 19459 A memory operand with autoincrement addressing (either preincrement 19460 or postincrement) is allowed. In inline 'asm' the same 19461 restrictions as for '<' apply. 19462 19463'r' 19464 A register operand is allowed provided that it is in a general 19465 register. 19466 19467'i' 19468 An immediate integer operand (one with constant value) is allowed. 19469 This includes symbolic constants whose values will be known only at 19470 assembly time or later. 19471 19472'n' 19473 An immediate integer operand with a known numeric value is allowed. 19474 Many systems cannot support assembly-time constants for operands 19475 less than a word wide. Constraints for these operands should use 19476 'n' rather than 'i'. 19477 19478'I', 'J', 'K', ... 'P' 19479 Other letters in the range 'I' through 'P' may be defined in a 19480 machine-dependent fashion to permit immediate integer operands with 19481 explicit integer values in specified ranges. For example, on the 19482 68000, 'I' is defined to stand for the range of values 1 to 8. 19483 This is the range permitted as a shift count in the shift 19484 instructions. 19485 19486'E' 19487 An immediate floating operand (expression code 'const_double') is 19488 allowed, but only if the target floating point format is the same 19489 as that of the host machine (on which the compiler is running). 19490 19491'F' 19492 An immediate floating operand (expression code 'const_double' or 19493 'const_vector') is allowed. 19494 19495'G', 'H' 19496 'G' and 'H' may be defined in a machine-dependent fashion to permit 19497 immediate floating operands in particular ranges of values. 19498 19499's' 19500 An immediate integer operand whose value is not an explicit integer 19501 is allowed. 19502 19503 This might appear strange; if an insn allows a constant operand 19504 with a value not known at compile time, it certainly must allow any 19505 known value. So why use 's' instead of 'i'? Sometimes it allows 19506 better code to be generated. 19507 19508 For example, on the 68000 in a fullword instruction it is possible 19509 to use an immediate operand; but if the immediate value is between 19510 -128 and 127, better code results from loading the value into a 19511 register and using the register. This is because the load into the 19512 register can be done with a 'moveq' instruction. We arrange for 19513 this to happen by defining the letter 'K' to mean "any integer 19514 outside the range -128 to 127", and then specifying 'Ks' in the 19515 operand constraints. 19516 19517'g' 19518 Any register, memory or immediate integer operand is allowed, 19519 except for registers that are not general registers. 19520 19521'X' 19522 Any operand whatsoever is allowed, even if it does not satisfy 19523 'general_operand'. This is normally used in the constraint of a 19524 'match_scratch' when certain alternatives will not actually require 19525 a scratch register. 19526 19527'0', '1', '2', ... '9' 19528 An operand that matches the specified operand number is allowed. 19529 If a digit is used together with letters within the same 19530 alternative, the digit should come last. 19531 19532 This number is allowed to be more than a single digit. If multiple 19533 digits are encountered consecutively, they are interpreted as a 19534 single decimal integer. There is scant chance for ambiguity, since 19535 to-date it has never been desirable that '10' be interpreted as 19536 matching either operand 1 _or_ operand 0. Should this be desired, 19537 one can use multiple alternatives instead. 19538 19539 This is called a "matching constraint" and what it really means is 19540 that the assembler has only a single operand that fills two roles 19541 considered separate in the RTL insn. For example, an add insn has 19542 two input operands and one output operand in the RTL, but on most 19543 CISC machines an add instruction really has only two operands, one 19544 of them an input-output operand: 19545 19546 addl #35,r12 19547 19548 Matching constraints are used in these circumstances. More 19549 precisely, the two operands that match must include one input-only 19550 operand and one output-only operand. Moreover, the digit must be a 19551 smaller number than the number of the operand that uses it in the 19552 constraint. 19553 19554 For operands to match in a particular case usually means that they 19555 are identical-looking RTL expressions. But in a few special cases 19556 specific kinds of dissimilarity are allowed. For example, '*x' as 19557 an input operand will match '*x++' as an output operand. For 19558 proper results in such cases, the output template should always use 19559 the output-operand's number when printing the operand. 19560 19561'p' 19562 An operand that is a valid memory address is allowed. This is for 19563 "load address" and "push address" instructions. 19564 19565 'p' in the constraint must be accompanied by 'address_operand' as 19566 the predicate in the 'match_operand'. This predicate interprets 19567 the mode specified in the 'match_operand' as the mode of the memory 19568 reference for which the address would be valid. 19569 19570OTHER-LETTERS 19571 Other letters can be defined in machine-dependent fashion to stand 19572 for particular classes of registers or other arbitrary operand 19573 types. 'd', 'a' and 'f' are defined on the 68000/68020 to stand 19574 for data, address and floating point registers. 19575 19576 In order to have valid assembler code, each operand must satisfy its 19577constraint. But a failure to do so does not prevent the pattern from 19578applying to an insn. Instead, it directs the compiler to modify the 19579code so that the constraint will be satisfied. Usually this is done by 19580copying an operand into a register. 19581 19582 Contrast, therefore, the two instruction patterns that follow: 19583 19584 (define_insn "" 19585 [(set (match_operand:SI 0 "general_operand" "=r") 19586 (plus:SI (match_dup 0) 19587 (match_operand:SI 1 "general_operand" "r")))] 19588 "" 19589 "...") 19590 19591which has two operands, one of which must appear in two places, and 19592 19593 (define_insn "" 19594 [(set (match_operand:SI 0 "general_operand" "=r") 19595 (plus:SI (match_operand:SI 1 "general_operand" "0") 19596 (match_operand:SI 2 "general_operand" "r")))] 19597 "" 19598 "...") 19599 19600which has three operands, two of which are required by a constraint to 19601be identical. If we are considering an insn of the form 19602 19603 (insn N PREV NEXT 19604 (set (reg:SI 3) 19605 (plus:SI (reg:SI 6) (reg:SI 109))) 19606 ...) 19607 19608the first pattern would not apply at all, because this insn does not 19609contain two identical subexpressions in the right place. The pattern 19610would say, "That does not look like an add instruction; try other 19611patterns". The second pattern would say, "Yes, that's an add 19612instruction, but there is something wrong with it". It would direct the 19613reload pass of the compiler to generate additional insns to make the 19614constraint true. The results might look like this: 19615 19616 (insn N2 PREV N 19617 (set (reg:SI 3) (reg:SI 6)) 19618 ...) 19619 19620 (insn N N2 NEXT 19621 (set (reg:SI 3) 19622 (plus:SI (reg:SI 3) (reg:SI 109))) 19623 ...) 19624 19625 It is up to you to make sure that each operand, in each pattern, has 19626constraints that can handle any RTL expression that could be present for 19627that operand. (When multiple alternatives are in use, each pattern 19628must, for each possible combination of operand expressions, have at 19629least one alternative which can handle that combination of operands.) 19630The constraints don't need to _allow_ any possible operand--when this is 19631the case, they do not constrain--but they must at least point the way to 19632reloading any possible operand so that it will fit. 19633 19634 * If the constraint accepts whatever operands the predicate permits, 19635 there is no problem: reloading is never necessary for this operand. 19636 19637 For example, an operand whose constraints permit everything except 19638 registers is safe provided its predicate rejects registers. 19639 19640 An operand whose predicate accepts only constant values is safe 19641 provided its constraints include the letter 'i'. If any possible 19642 constant value is accepted, then nothing less than 'i' will do; if 19643 the predicate is more selective, then the constraints may also be 19644 more selective. 19645 19646 * Any operand expression can be reloaded by copying it into a 19647 register. So if an operand's constraints allow some kind of 19648 register, it is certain to be safe. It need not permit all classes 19649 of registers; the compiler knows how to copy a register into 19650 another register of the proper class in order to make an 19651 instruction valid. 19652 19653 * A nonoffsettable memory reference can be reloaded by copying the 19654 address into a register. So if the constraint uses the letter 'o', 19655 all memory references are taken care of. 19656 19657 * A constant operand can be reloaded by allocating space in memory to 19658 hold it as preinitialized data. Then the memory reference can be 19659 used in place of the constant. So if the constraint uses the 19660 letters 'o' or 'm', constant operands are not a problem. 19661 19662 * If the constraint permits a constant and a pseudo register used in 19663 an insn was not allocated to a hard register and is equivalent to a 19664 constant, the register will be replaced with the constant. If the 19665 predicate does not permit a constant and the insn is re-recognized 19666 for some reason, the compiler will crash. Thus the predicate must 19667 always recognize any objects allowed by the constraint. 19668 19669 If the operand's predicate can recognize registers, but the constraint 19670does not permit them, it can make the compiler crash. When this operand 19671happens to be a register, the reload pass will be stymied, because it 19672does not know how to copy a register temporarily into memory. 19673 19674 If the predicate accepts a unary operator, the constraint applies to 19675the operand. For example, the MIPS processor at ISA level 3 supports an 19676instruction which adds two registers in 'SImode' to produce a 'DImode' 19677result, but only if the registers are correctly sign extended. This 19678predicate for the input operands accepts a 'sign_extend' of an 'SImode' 19679register. Write the constraint to indicate the type of register that is 19680required for the operand of the 'sign_extend'. 19681 19682 19683File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 19684 1968516.8.2 Multiple Alternative Constraints 19686--------------------------------------- 19687 19688Sometimes a single instruction has multiple alternative sets of possible 19689operands. For example, on the 68000, a logical-or instruction can 19690combine register or an immediate value into memory, or it can combine 19691any kind of operand into a register; but it cannot combine one memory 19692location into another. 19693 19694 These constraints are represented as multiple alternatives. An 19695alternative can be described by a series of letters for each operand. 19696The overall constraint for an operand is made from the letters for this 19697operand from the first alternative, a comma, the letters for this 19698operand from the second alternative, a comma, and so on until the last 19699alternative. All operands for a single instruction must have the same 19700number of alternatives. Here is how it is done for fullword logical-or 19701on the 68000: 19702 19703 (define_insn "iorsi3" 19704 [(set (match_operand:SI 0 "general_operand" "=m,d") 19705 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 19706 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 19707 ...) 19708 19709 The first alternative has 'm' (memory) for operand 0, '0' for operand 1 19710(meaning it must match operand 0), and 'dKs' for operand 2. The second 19711alternative has 'd' (data register) for operand 0, '0' for operand 1, 19712and 'dmKs' for operand 2. The '=' and '%' in the constraints apply to 19713all the alternatives; their meaning is explained in the next section 19714(*note Class Preferences::). 19715 19716 If all the operands fit any one alternative, the instruction is valid. 19717Otherwise, for each alternative, the compiler counts how many 19718instructions must be added to copy the operands so that that alternative 19719applies. The alternative requiring the least copying is chosen. If two 19720alternatives need the same amount of copying, the one that comes first 19721is chosen. These choices can be altered with the '?' and '!' 19722characters: 19723 19724'?' 19725 Disparage slightly the alternative that the '?' appears in, as a 19726 choice when no alternative applies exactly. The compiler regards 19727 this alternative as one unit more costly for each '?' that appears 19728 in it. 19729 19730'!' 19731 Disparage severely the alternative that the '!' appears in. This 19732 alternative can still be used if it fits without reloading, but if 19733 reloading is needed, some other alternative will be used. 19734 19735'^' 19736 This constraint is analogous to '?' but it disparages slightly the 19737 alternative only if the operand with the '^' needs a reload. 19738 19739'$' 19740 This constraint is analogous to '!' but it disparages severely the 19741 alternative only if the operand with the '$' needs a reload. 19742 19743 When an insn pattern has multiple alternatives in its constraints, 19744often the appearance of the assembler code is determined mostly by which 19745alternative was matched. When this is so, the C code for writing the 19746assembler code can use the variable 'which_alternative', which is the 19747ordinal number of the alternative that was actually satisfied (0 for the 19748first, 1 for the second alternative, etc.). *Note Output Statement::. 19749 19750 19751File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 19752 1975316.8.3 Register Class Preferences 19754--------------------------------- 19755 19756The operand constraints have another function: they enable the compiler 19757to decide which kind of hardware register a pseudo register is best 19758allocated to. The compiler examines the constraints that apply to the 19759insns that use the pseudo register, looking for the machine-dependent 19760letters such as 'd' and 'a' that specify classes of registers. The 19761pseudo register is put in whichever class gets the most "votes". The 19762constraint letters 'g' and 'r' also vote: they vote in favor of a 19763general register. The machine description says which registers are 19764considered general. 19765 19766 Of course, on some machines all registers are equivalent, and no 19767register classes are defined. Then none of this complexity is relevant. 19768 19769 19770File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 19771 1977216.8.4 Constraint Modifier Characters 19773------------------------------------- 19774 19775Here are constraint modifier characters. 19776 19777'=' 19778 Means that this operand is written to by this instruction: the 19779 previous value is discarded and replaced by new data. 19780 19781'+' 19782 Means that this operand is both read and written by the 19783 instruction. 19784 19785 When the compiler fixes up the operands to satisfy the constraints, 19786 it needs to know which operands are read by the instruction and 19787 which are written by it. '=' identifies an operand which is only 19788 written; '+' identifies an operand that is both read and written; 19789 all other operands are assumed to only be read. 19790 19791 If you specify '=' or '+' in a constraint, you put it in the first 19792 character of the constraint string. 19793 19794'&' 19795 Means (in a particular alternative) that this operand is an 19796 "earlyclobber" operand, which is written before the instruction is 19797 finished using the input operands. Therefore, this operand may not 19798 lie in a register that is read by the instruction or as part of any 19799 memory address. 19800 19801 '&' applies only to the alternative in which it is written. In 19802 constraints with multiple alternatives, sometimes one alternative 19803 requires '&' while others do not. See, for example, the 'movdf' 19804 insn of the 68000. 19805 19806 A operand which is read by the instruction can be tied to an 19807 earlyclobber operand if its only use as an input occurs before the 19808 early result is written. Adding alternatives of this form often 19809 allows GCC to produce better code when only some of the read 19810 operands can be affected by the earlyclobber. See, for example, 19811 the 'mulsi3' insn of the ARM. 19812 19813 Furthermore, if the "earlyclobber" operand is also a read/write 19814 operand, then that operand is written only after it's used. 19815 19816 '&' does not obviate the need to write '=' or '+'. As 19817 "earlyclobber" operands are always written, a read-only 19818 "earlyclobber" operand is ill-formed and will be rejected by the 19819 compiler. 19820 19821'%' 19822 Declares the instruction to be commutative for this operand and the 19823 following operand. This means that the compiler may interchange 19824 the two operands if that is the cheapest way to make all operands 19825 fit the constraints. '%' applies to all alternatives and must 19826 appear as the first character in the constraint. Only read-only 19827 operands can use '%'. 19828 19829 This is often used in patterns for addition instructions that 19830 really have only two operands: the result must go in one of the 19831 arguments. Here for example, is how the 68000 halfword-add 19832 instruction is defined: 19833 19834 (define_insn "addhi3" 19835 [(set (match_operand:HI 0 "general_operand" "=m,r") 19836 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 19837 (match_operand:HI 2 "general_operand" "di,g")))] 19838 ...) 19839 GCC can only handle one commutative pair in an asm; if you use 19840 more, the compiler may fail. Note that you need not use the 19841 modifier if the two alternatives are strictly identical; this would 19842 only waste time in the reload pass. The modifier is not 19843 operational after register allocation, so the result of 19844 'define_peephole2' and 'define_split's performed after reload 19845 cannot rely on '%' to make the intended insn match. 19846 19847'#' 19848 Says that all following characters, up to the next comma, are to be 19849 ignored as a constraint. They are significant only for choosing 19850 register preferences. 19851 19852'*' 19853 Says that the following character should be ignored when choosing 19854 register preferences. '*' has no effect on the meaning of the 19855 constraint as a constraint, and no effect on reloading. For LRA 19856 '*' additionally disparages slightly the alternative if the 19857 following character matches the operand. 19858 19859 Here is an example: the 68000 has an instruction to sign-extend a 19860 halfword in a data register, and can also sign-extend a value by 19861 copying it into an address register. While either kind of register 19862 is acceptable, the constraints on an address-register destination 19863 are less strict, so it is best if register allocation makes an 19864 address register its goal. Therefore, '*' is used so that the 'd' 19865 constraint letter (for data register) is ignored when computing 19866 register preferences. 19867 19868 (define_insn "extendhisi2" 19869 [(set (match_operand:SI 0 "general_operand" "=*d,a") 19870 (sign_extend:SI 19871 (match_operand:HI 1 "general_operand" "0,g")))] 19872 ...) 19873 19874 19875File: gccint.info, Node: Machine Constraints, Next: Disable Insn Alternatives, Prev: Modifiers, Up: Constraints 19876 1987716.8.5 Constraints for Particular Machines 19878------------------------------------------ 19879 19880Whenever possible, you should use the general-purpose constraint letters 19881in 'asm' arguments, since they will convey meaning more readily to 19882people reading your code. Failing that, use the constraint letters that 19883usually have very similar meanings across architectures. The most 19884commonly used constraints are 'm' and 'r' (for memory and 19885general-purpose registers respectively; *note Simple Constraints::), and 19886'I', usually the letter indicating the most common immediate-constant 19887format. 19888 19889 Each architecture defines additional constraints. These constraints 19890are used by the compiler itself for instruction generation, as well as 19891for 'asm' statements; therefore, some of the constraints are not 19892particularly useful for 'asm'. Here is a summary of some of the 19893machine-dependent constraints available on some particular machines; it 19894includes both constraints that are useful for 'asm' and constraints that 19895aren't. The compiler source file mentioned in the table heading for 19896each architecture is the definitive reference for the meanings of that 19897architecture's constraints. 19898 19899_AArch64 family--'config/aarch64/constraints.md'_ 19900 'k' 19901 The stack pointer register ('SP') 19902 19903 'w' 19904 Floating point or SIMD vector register 19905 19906 'I' 19907 Integer constant that is valid as an immediate operand in an 19908 'ADD' instruction 19909 19910 'J' 19911 Integer constant that is valid as an immediate operand in a 19912 'SUB' instruction (once negated) 19913 19914 'K' 19915 Integer constant that can be used with a 32-bit logical 19916 instruction 19917 19918 'L' 19919 Integer constant that can be used with a 64-bit logical 19920 instruction 19921 19922 'M' 19923 Integer constant that is valid as an immediate operand in a 19924 32-bit 'MOV' pseudo instruction. The 'MOV' may be assembled 19925 to one of several different machine instructions depending on 19926 the value 19927 19928 'N' 19929 Integer constant that is valid as an immediate operand in a 19930 64-bit 'MOV' pseudo instruction 19931 19932 'S' 19933 An absolute symbolic address or a label reference 19934 19935 'Y' 19936 Floating point constant zero 19937 19938 'Z' 19939 Integer constant zero 19940 19941 'Ush' 19942 The high part (bits 12 and upwards) of the pc-relative address 19943 of a symbol within 4GB of the instruction 19944 19945 'Q' 19946 A memory address which uses a single base register with no 19947 offset 19948 19949 'Ump' 19950 A memory address suitable for a load/store pair instruction in 19951 SI, DI, SF and DF modes 19952 19953_ARC --'config/arc/constraints.md'_ 19954 'q' 19955 Registers usable in ARCompact 16-bit instructions: 'r0'-'r3', 19956 'r12'-'r15'. This constraint can only match when the '-mq' 19957 option is in effect. 19958 19959 'e' 19960 Registers usable as base-regs of memory addresses in ARCompact 19961 16-bit memory instructions: 'r0'-'r3', 'r12'-'r15', 'sp'. 19962 This constraint can only match when the '-mq' option is in 19963 effect. 19964 'D' 19965 ARC FPX (dpfp) 64-bit registers. 'D0', 'D1'. 19966 19967 'I' 19968 A signed 12-bit integer constant. 19969 19970 'Cal' 19971 constant for arithmetic/logical operations. This might be any 19972 constant that can be put into a long immediate by the assmbler 19973 or linker without involving a PIC relocation. 19974 19975 'K' 19976 A 3-bit unsigned integer constant. 19977 19978 'L' 19979 A 6-bit unsigned integer constant. 19980 19981 'CnL' 19982 One's complement of a 6-bit unsigned integer constant. 19983 19984 'CmL' 19985 Two's complement of a 6-bit unsigned integer constant. 19986 19987 'M' 19988 A 5-bit unsigned integer constant. 19989 19990 'O' 19991 A 7-bit unsigned integer constant. 19992 19993 'P' 19994 A 8-bit unsigned integer constant. 19995 19996 'H' 19997 Any const_double value. 19998 19999_ARM family--'config/arm/constraints.md'_ 20000 20001 'h' 20002 In Thumb state, the core registers 'r8'-'r15'. 20003 20004 'k' 20005 The stack pointer register. 20006 20007 'l' 20008 In Thumb State the core registers 'r0'-'r7'. In ARM state 20009 this is an alias for the 'r' constraint. 20010 20011 't' 20012 VFP floating-point registers 's0'-'s31'. Used for 32 bit 20013 values. 20014 20015 'w' 20016 VFP floating-point registers 'd0'-'d31' and the appropriate 20017 subset 'd0'-'d15' based on command line options. Used for 64 20018 bit values only. Not valid for Thumb1. 20019 20020 'y' 20021 The iWMMX co-processor registers. 20022 20023 'z' 20024 The iWMMX GR registers. 20025 20026 'G' 20027 The floating-point constant 0.0 20028 20029 'I' 20030 Integer that is valid as an immediate operand in a data 20031 processing instruction. That is, an integer in the range 0 to 20032 255 rotated by a multiple of 2 20033 20034 'J' 20035 Integer in the range -4095 to 4095 20036 20037 'K' 20038 Integer that satisfies constraint 'I' when inverted (ones 20039 complement) 20040 20041 'L' 20042 Integer that satisfies constraint 'I' when negated (twos 20043 complement) 20044 20045 'M' 20046 Integer in the range 0 to 32 20047 20048 'Q' 20049 A memory reference where the exact address is in a single 20050 register (''m'' is preferable for 'asm' statements) 20051 20052 'R' 20053 An item in the constant pool 20054 20055 'S' 20056 A symbol in the text segment of the current file 20057 20058 'Uv' 20059 A memory reference suitable for VFP load/store insns 20060 (reg+constant offset) 20061 20062 'Uy' 20063 A memory reference suitable for iWMMXt load/store 20064 instructions. 20065 20066 'Uq' 20067 A memory reference suitable for the ARMv4 ldrsb instruction. 20068 20069_AVR family--'config/avr/constraints.md'_ 20070 'l' 20071 Registers from r0 to r15 20072 20073 'a' 20074 Registers from r16 to r23 20075 20076 'd' 20077 Registers from r16 to r31 20078 20079 'w' 20080 Registers from r24 to r31. These registers can be used in 20081 'adiw' command 20082 20083 'e' 20084 Pointer register (r26-r31) 20085 20086 'b' 20087 Base pointer register (r28-r31) 20088 20089 'q' 20090 Stack pointer register (SPH:SPL) 20091 20092 't' 20093 Temporary register r0 20094 20095 'x' 20096 Register pair X (r27:r26) 20097 20098 'y' 20099 Register pair Y (r29:r28) 20100 20101 'z' 20102 Register pair Z (r31:r30) 20103 20104 'I' 20105 Constant greater than -1, less than 64 20106 20107 'J' 20108 Constant greater than -64, less than 1 20109 20110 'K' 20111 Constant integer 2 20112 20113 'L' 20114 Constant integer 0 20115 20116 'M' 20117 Constant that fits in 8 bits 20118 20119 'N' 20120 Constant integer -1 20121 20122 'O' 20123 Constant integer 8, 16, or 24 20124 20125 'P' 20126 Constant integer 1 20127 20128 'G' 20129 A floating point constant 0.0 20130 20131 'Q' 20132 A memory address based on Y or Z pointer with displacement. 20133 20134_Blackfin family--'config/bfin/constraints.md'_ 20135 'a' 20136 P register 20137 20138 'd' 20139 D register 20140 20141 'z' 20142 A call clobbered P register. 20143 20144 'qN' 20145 A single register. If N is in the range 0 to 7, the 20146 corresponding D register. If it is 'A', then the register P0. 20147 20148 'D' 20149 Even-numbered D register 20150 20151 'W' 20152 Odd-numbered D register 20153 20154 'e' 20155 Accumulator register. 20156 20157 'A' 20158 Even-numbered accumulator register. 20159 20160 'B' 20161 Odd-numbered accumulator register. 20162 20163 'b' 20164 I register 20165 20166 'v' 20167 B register 20168 20169 'f' 20170 M register 20171 20172 'c' 20173 Registers used for circular buffering, i.e. I, B, or L 20174 registers. 20175 20176 'C' 20177 The CC register. 20178 20179 't' 20180 LT0 or LT1. 20181 20182 'k' 20183 LC0 or LC1. 20184 20185 'u' 20186 LB0 or LB1. 20187 20188 'x' 20189 Any D, P, B, M, I or L register. 20190 20191 'y' 20192 Additional registers typically used only in prologues and 20193 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 20194 USP. 20195 20196 'w' 20197 Any register except accumulators or CC. 20198 20199 'Ksh' 20200 Signed 16 bit integer (in the range -32768 to 32767) 20201 20202 'Kuh' 20203 Unsigned 16 bit integer (in the range 0 to 65535) 20204 20205 'Ks7' 20206 Signed 7 bit integer (in the range -64 to 63) 20207 20208 'Ku7' 20209 Unsigned 7 bit integer (in the range 0 to 127) 20210 20211 'Ku5' 20212 Unsigned 5 bit integer (in the range 0 to 31) 20213 20214 'Ks4' 20215 Signed 4 bit integer (in the range -8 to 7) 20216 20217 'Ks3' 20218 Signed 3 bit integer (in the range -3 to 4) 20219 20220 'Ku3' 20221 Unsigned 3 bit integer (in the range 0 to 7) 20222 20223 'PN' 20224 Constant N, where N is a single-digit constant in the range 0 20225 to 4. 20226 20227 'PA' 20228 An integer equal to one of the MACFLAG_XXX constants that is 20229 suitable for use with either accumulator. 20230 20231 'PB' 20232 An integer equal to one of the MACFLAG_XXX constants that is 20233 suitable for use only with accumulator A1. 20234 20235 'M1' 20236 Constant 255. 20237 20238 'M2' 20239 Constant 65535. 20240 20241 'J' 20242 An integer constant with exactly a single bit set. 20243 20244 'L' 20245 An integer constant with all bits set except exactly one. 20246 20247 'H' 20248 20249 'Q' 20250 Any SYMBOL_REF. 20251 20252_CR16 Architecture--'config/cr16/cr16.h'_ 20253 20254 'b' 20255 Registers from r0 to r14 (registers without stack pointer) 20256 20257 't' 20258 Register from r0 to r11 (all 16-bit registers) 20259 20260 'p' 20261 Register from r12 to r15 (all 32-bit registers) 20262 20263 'I' 20264 Signed constant that fits in 4 bits 20265 20266 'J' 20267 Signed constant that fits in 5 bits 20268 20269 'K' 20270 Signed constant that fits in 6 bits 20271 20272 'L' 20273 Unsigned constant that fits in 4 bits 20274 20275 'M' 20276 Signed constant that fits in 32 bits 20277 20278 'N' 20279 Check for 64 bits wide constants for add/sub instructions 20280 20281 'G' 20282 Floating point constant that is legal for store immediate 20283 20284_Epiphany--'config/epiphany/constraints.md'_ 20285 'U16' 20286 An unsigned 16-bit constant. 20287 20288 'K' 20289 An unsigned 5-bit constant. 20290 20291 'L' 20292 A signed 11-bit constant. 20293 20294 'Cm1' 20295 A signed 11-bit constant added to -1. Can only match when the 20296 '-m1reg-REG' option is active. 20297 20298 'Cl1' 20299 Left-shift of -1, i.e., a bit mask with a block of leading 20300 ones, the rest being a block of trailing zeroes. Can only 20301 match when the '-m1reg-REG' option is active. 20302 20303 'Cr1' 20304 Right-shift of -1, i.e., a bit mask with a trailing block of 20305 ones, the rest being zeroes. Or to put it another way, one 20306 less than a power of two. Can only match when the 20307 '-m1reg-REG' option is active. 20308 20309 'Cal' 20310 Constant for arithmetic/logical operations. This is like 'i', 20311 except that for position independent code, no symbols / 20312 expressions needing relocations are allowed. 20313 20314 'Csy' 20315 Symbolic constant for call/jump instruction. 20316 20317 'Rcs' 20318 The register class usable in short insns. This is a register 20319 class constraint, and can thus drive register allocation. 20320 This constraint won't match unless '-mprefer-short-insn-regs' 20321 is in effect. 20322 20323 'Rsc' 20324 The the register class of registers that can be used to hold a 20325 sibcall call address. I.e., a caller-saved register. 20326 20327 'Rct' 20328 Core control register class. 20329 20330 'Rgs' 20331 The register group usable in short insns. This constraint 20332 does not use a register class, so that it only passively 20333 matches suitable registers, and doesn't drive register 20334 allocation. 20335 20336 'Car' 20337 Constant suitable for the addsi3_r pattern. This is a valid 20338 offset For byte, halfword, or word addressing. 20339 20340 'Rra' 20341 Matches the return address if it can be replaced with the link 20342 register. 20343 20344 'Rcc' 20345 Matches the integer condition code register. 20346 20347 'Sra' 20348 Matches the return address if it is in a stack slot. 20349 20350 'Cfm' 20351 Matches control register values to switch fp mode, which are 20352 encapsulated in 'UNSPEC_FP_MODE'. 20353 20354_FRV--'config/frv/frv.h'_ 20355 'a' 20356 Register in the class 'ACC_REGS' ('acc0' to 'acc7'). 20357 20358 'b' 20359 Register in the class 'EVEN_ACC_REGS' ('acc0' to 'acc7'). 20360 20361 'c' 20362 Register in the class 'CC_REGS' ('fcc0' to 'fcc3' and 'icc0' 20363 to 'icc3'). 20364 20365 'd' 20366 Register in the class 'GPR_REGS' ('gr0' to 'gr63'). 20367 20368 'e' 20369 Register in the class 'EVEN_REGS' ('gr0' to 'gr63'). Odd 20370 registers are excluded not in the class but through the use of 20371 a machine mode larger than 4 bytes. 20372 20373 'f' 20374 Register in the class 'FPR_REGS' ('fr0' to 'fr63'). 20375 20376 'h' 20377 Register in the class 'FEVEN_REGS' ('fr0' to 'fr63'). Odd 20378 registers are excluded not in the class but through the use of 20379 a machine mode larger than 4 bytes. 20380 20381 'l' 20382 Register in the class 'LR_REG' (the 'lr' register). 20383 20384 'q' 20385 Register in the class 'QUAD_REGS' ('gr2' to 'gr63'). Register 20386 numbers not divisible by 4 are excluded not in the class but 20387 through the use of a machine mode larger than 8 bytes. 20388 20389 't' 20390 Register in the class 'ICC_REGS' ('icc0' to 'icc3'). 20391 20392 'u' 20393 Register in the class 'FCC_REGS' ('fcc0' to 'fcc3'). 20394 20395 'v' 20396 Register in the class 'ICR_REGS' ('cc4' to 'cc7'). 20397 20398 'w' 20399 Register in the class 'FCR_REGS' ('cc0' to 'cc3'). 20400 20401 'x' 20402 Register in the class 'QUAD_FPR_REGS' ('fr0' to 'fr63'). 20403 Register numbers not divisible by 4 are excluded not in the 20404 class but through the use of a machine mode larger than 8 20405 bytes. 20406 20407 'z' 20408 Register in the class 'SPR_REGS' ('lcr' and 'lr'). 20409 20410 'A' 20411 Register in the class 'QUAD_ACC_REGS' ('acc0' to 'acc7'). 20412 20413 'B' 20414 Register in the class 'ACCG_REGS' ('accg0' to 'accg7'). 20415 20416 'C' 20417 Register in the class 'CR_REGS' ('cc0' to 'cc7'). 20418 20419 'G' 20420 Floating point constant zero 20421 20422 'I' 20423 6-bit signed integer constant 20424 20425 'J' 20426 10-bit signed integer constant 20427 20428 'L' 20429 16-bit signed integer constant 20430 20431 'M' 20432 16-bit unsigned integer constant 20433 20434 'N' 20435 12-bit signed integer constant that is negative--i.e. in the 20436 range of -2048 to -1 20437 20438 'O' 20439 Constant zero 20440 20441 'P' 20442 12-bit signed integer constant that is greater than zero--i.e. 20443 in the range of 1 to 2047. 20444 20445_FT32--'config/ft32/constraints.md'_ 20446 'A' 20447 An absolute address 20448 20449 'B' 20450 An offset address 20451 20452 'W' 20453 A register indirect memory operand 20454 20455 'e' 20456 An offset address. 20457 20458 'f' 20459 An offset address. 20460 20461 'O' 20462 The constant zero or one 20463 20464 'I' 20465 A 16-bit signed constant (-32768 ... 32767) 20466 20467 'w' 20468 A bitfield mask suitable for bext or bins 20469 20470 'x' 20471 An inverted bitfield mask suitable for bext or bins 20472 20473 'L' 20474 A 16-bit unsigned constant, multiple of 4 (0 ... 65532) 20475 20476 'S' 20477 A 20-bit signed constant (-524288 ... 524287) 20478 20479 'b' 20480 A constant for a bitfield width (1 ... 16) 20481 20482 'KA' 20483 A 10-bit signed constant (-512 ... 511) 20484 20485_Hewlett-Packard PA-RISC--'config/pa/pa.h'_ 20486 'a' 20487 General register 1 20488 20489 'f' 20490 Floating point register 20491 20492 'q' 20493 Shift amount register 20494 20495 'x' 20496 Floating point register (deprecated) 20497 20498 'y' 20499 Upper floating point register (32-bit), floating point 20500 register (64-bit) 20501 20502 'Z' 20503 Any register 20504 20505 'I' 20506 Signed 11-bit integer constant 20507 20508 'J' 20509 Signed 14-bit integer constant 20510 20511 'K' 20512 Integer constant that can be deposited with a 'zdepi' 20513 instruction 20514 20515 'L' 20516 Signed 5-bit integer constant 20517 20518 'M' 20519 Integer constant 0 20520 20521 'N' 20522 Integer constant that can be loaded with a 'ldil' instruction 20523 20524 'O' 20525 Integer constant whose value plus one is a power of 2 20526 20527 'P' 20528 Integer constant that can be used for 'and' operations in 20529 'depi' and 'extru' instructions 20530 20531 'S' 20532 Integer constant 31 20533 20534 'U' 20535 Integer constant 63 20536 20537 'G' 20538 Floating-point constant 0.0 20539 20540 'A' 20541 A 'lo_sum' data-linkage-table memory operand 20542 20543 'Q' 20544 A memory operand that can be used as the destination operand 20545 of an integer store instruction 20546 20547 'R' 20548 A scaled or unscaled indexed memory operand 20549 20550 'T' 20551 A memory operand for floating-point loads and stores 20552 20553 'W' 20554 A register indirect memory operand 20555 20556_Intel IA-64--'config/ia64/ia64.h'_ 20557 'a' 20558 General register 'r0' to 'r3' for 'addl' instruction 20559 20560 'b' 20561 Branch register 20562 20563 'c' 20564 Predicate register ('c' as in "conditional") 20565 20566 'd' 20567 Application register residing in M-unit 20568 20569 'e' 20570 Application register residing in I-unit 20571 20572 'f' 20573 Floating-point register 20574 20575 'm' 20576 Memory operand. If used together with '<' or '>', the operand 20577 can have postincrement and postdecrement which require 20578 printing with '%Pn' on IA-64. 20579 20580 'G' 20581 Floating-point constant 0.0 or 1.0 20582 20583 'I' 20584 14-bit signed integer constant 20585 20586 'J' 20587 22-bit signed integer constant 20588 20589 'K' 20590 8-bit signed integer constant for logical instructions 20591 20592 'L' 20593 8-bit adjusted signed integer constant for compare pseudo-ops 20594 20595 'M' 20596 6-bit unsigned integer constant for shift counts 20597 20598 'N' 20599 9-bit signed integer constant for load and store 20600 postincrements 20601 20602 'O' 20603 The constant zero 20604 20605 'P' 20606 0 or -1 for 'dep' instruction 20607 20608 'Q' 20609 Non-volatile memory for floating-point loads and stores 20610 20611 'R' 20612 Integer constant in the range 1 to 4 for 'shladd' instruction 20613 20614 'S' 20615 Memory operand except postincrement and postdecrement. This 20616 is now roughly the same as 'm' when not used together with '<' 20617 or '>'. 20618 20619_M32C--'config/m32c/m32c.c'_ 20620 'Rsp' 20621 'Rfb' 20622 'Rsb' 20623 '$sp', '$fb', '$sb'. 20624 20625 'Rcr' 20626 Any control register, when they're 16 bits wide (nothing if 20627 control registers are 24 bits wide) 20628 20629 'Rcl' 20630 Any control register, when they're 24 bits wide. 20631 20632 'R0w' 20633 'R1w' 20634 'R2w' 20635 'R3w' 20636 $r0, $r1, $r2, $r3. 20637 20638 'R02' 20639 $r0 or $r2, or $r2r0 for 32 bit values. 20640 20641 'R13' 20642 $r1 or $r3, or $r3r1 for 32 bit values. 20643 20644 'Rdi' 20645 A register that can hold a 64 bit value. 20646 20647 'Rhl' 20648 $r0 or $r1 (registers with addressable high/low bytes) 20649 20650 'R23' 20651 $r2 or $r3 20652 20653 'Raa' 20654 Address registers 20655 20656 'Raw' 20657 Address registers when they're 16 bits wide. 20658 20659 'Ral' 20660 Address registers when they're 24 bits wide. 20661 20662 'Rqi' 20663 Registers that can hold QI values. 20664 20665 'Rad' 20666 Registers that can be used with displacements ($a0, $a1, $sb). 20667 20668 'Rsi' 20669 Registers that can hold 32 bit values. 20670 20671 'Rhi' 20672 Registers that can hold 16 bit values. 20673 20674 'Rhc' 20675 Registers chat can hold 16 bit values, including all control 20676 registers. 20677 20678 'Rra' 20679 $r0 through R1, plus $a0 and $a1. 20680 20681 'Rfl' 20682 The flags register. 20683 20684 'Rmm' 20685 The memory-based pseudo-registers $mem0 through $mem15. 20686 20687 'Rpi' 20688 Registers that can hold pointers (16 bit registers for r8c, 20689 m16c; 24 bit registers for m32cm, m32c). 20690 20691 'Rpa' 20692 Matches multiple registers in a PARALLEL to form a larger 20693 register. Used to match function return values. 20694 20695 'Is3' 20696 -8 ... 7 20697 20698 'IS1' 20699 -128 ... 127 20700 20701 'IS2' 20702 -32768 ... 32767 20703 20704 'IU2' 20705 0 ... 65535 20706 20707 'In4' 20708 -8 ... -1 or 1 ... 8 20709 20710 'In5' 20711 -16 ... -1 or 1 ... 16 20712 20713 'In6' 20714 -32 ... -1 or 1 ... 32 20715 20716 'IM2' 20717 -65536 ... -1 20718 20719 'Ilb' 20720 An 8 bit value with exactly one bit set. 20721 20722 'Ilw' 20723 A 16 bit value with exactly one bit set. 20724 20725 'Sd' 20726 The common src/dest memory addressing modes. 20727 20728 'Sa' 20729 Memory addressed using $a0 or $a1. 20730 20731 'Si' 20732 Memory addressed with immediate addresses. 20733 20734 'Ss' 20735 Memory addressed using the stack pointer ($sp). 20736 20737 'Sf' 20738 Memory addressed using the frame base register ($fb). 20739 20740 'Ss' 20741 Memory addressed using the small base register ($sb). 20742 20743 'S1' 20744 $r1h 20745 20746_MeP--'config/mep/constraints.md'_ 20747 20748 'a' 20749 The $sp register. 20750 20751 'b' 20752 The $tp register. 20753 20754 'c' 20755 Any control register. 20756 20757 'd' 20758 Either the $hi or the $lo register. 20759 20760 'em' 20761 Coprocessor registers that can be directly loaded ($c0-$c15). 20762 20763 'ex' 20764 Coprocessor registers that can be moved to each other. 20765 20766 'er' 20767 Coprocessor registers that can be moved to core registers. 20768 20769 'h' 20770 The $hi register. 20771 20772 'j' 20773 The $rpc register. 20774 20775 'l' 20776 The $lo register. 20777 20778 't' 20779 Registers which can be used in $tp-relative addressing. 20780 20781 'v' 20782 The $gp register. 20783 20784 'x' 20785 The coprocessor registers. 20786 20787 'y' 20788 The coprocessor control registers. 20789 20790 'z' 20791 The $0 register. 20792 20793 'A' 20794 User-defined register set A. 20795 20796 'B' 20797 User-defined register set B. 20798 20799 'C' 20800 User-defined register set C. 20801 20802 'D' 20803 User-defined register set D. 20804 20805 'I' 20806 Offsets for $gp-rel addressing. 20807 20808 'J' 20809 Constants that can be used directly with boolean insns. 20810 20811 'K' 20812 Constants that can be moved directly to registers. 20813 20814 'L' 20815 Small constants that can be added to registers. 20816 20817 'M' 20818 Long shift counts. 20819 20820 'N' 20821 Small constants that can be compared to registers. 20822 20823 'O' 20824 Constants that can be loaded into the top half of registers. 20825 20826 'S' 20827 Signed 8-bit immediates. 20828 20829 'T' 20830 Symbols encoded for $tp-rel or $gp-rel addressing. 20831 20832 'U' 20833 Non-constant addresses for loading/saving coprocessor 20834 registers. 20835 20836 'W' 20837 The top half of a symbol's value. 20838 20839 'Y' 20840 A register indirect address without offset. 20841 20842 'Z' 20843 Symbolic references to the control bus. 20844 20845_MicroBlaze--'config/microblaze/constraints.md'_ 20846 'd' 20847 A general register ('r0' to 'r31'). 20848 20849 'z' 20850 A status register ('rmsr', '$fcc1' to '$fcc7'). 20851 20852_MIPS--'config/mips/constraints.md'_ 20853 'd' 20854 An address register. This is equivalent to 'r' unless 20855 generating MIPS16 code. 20856 20857 'f' 20858 A floating-point register (if available). 20859 20860 'h' 20861 Formerly the 'hi' register. This constraint is no longer 20862 supported. 20863 20864 'l' 20865 The 'lo' register. Use this register to store values that are 20866 no bigger than a word. 20867 20868 'x' 20869 The concatenated 'hi' and 'lo' registers. Use this register 20870 to store doubleword values. 20871 20872 'c' 20873 A register suitable for use in an indirect jump. This will 20874 always be '$25' for '-mabicalls'. 20875 20876 'v' 20877 Register '$3'. Do not use this constraint in new code; it is 20878 retained only for compatibility with glibc. 20879 20880 'y' 20881 Equivalent to 'r'; retained for backwards compatibility. 20882 20883 'z' 20884 A floating-point condition code register. 20885 20886 'I' 20887 A signed 16-bit constant (for arithmetic instructions). 20888 20889 'J' 20890 Integer zero. 20891 20892 'K' 20893 An unsigned 16-bit constant (for logic instructions). 20894 20895 'L' 20896 A signed 32-bit constant in which the lower 16 bits are zero. 20897 Such constants can be loaded using 'lui'. 20898 20899 'M' 20900 A constant that cannot be loaded using 'lui', 'addiu' or 20901 'ori'. 20902 20903 'N' 20904 A constant in the range -65535 to -1 (inclusive). 20905 20906 'O' 20907 A signed 15-bit constant. 20908 20909 'P' 20910 A constant in the range 1 to 65535 (inclusive). 20911 20912 'G' 20913 Floating-point zero. 20914 20915 'R' 20916 An address that can be used in a non-macro load or store. 20917 20918 'ZC' 20919 A memory operand whose address is formed by a base register 20920 and offset that is suitable for use in instructions with the 20921 same addressing mode as 'll' and 'sc'. 20922 20923 'ZD' 20924 An address suitable for a 'prefetch' instruction, or for any 20925 other instruction with the same addressing mode as 'prefetch'. 20926 20927_Motorola 680x0--'config/m68k/constraints.md'_ 20928 'a' 20929 Address register 20930 20931 'd' 20932 Data register 20933 20934 'f' 20935 68881 floating-point register, if available 20936 20937 'I' 20938 Integer in the range 1 to 8 20939 20940 'J' 20941 16-bit signed number 20942 20943 'K' 20944 Signed number whose magnitude is greater than 0x80 20945 20946 'L' 20947 Integer in the range -8 to -1 20948 20949 'M' 20950 Signed number whose magnitude is greater than 0x100 20951 20952 'N' 20953 Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate 20954 20955 'O' 20956 16 (for rotate using swap) 20957 20958 'P' 20959 Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate 20960 20961 'R' 20962 Numbers that mov3q can handle 20963 20964 'G' 20965 Floating point constant that is not a 68881 constant 20966 20967 'S' 20968 Operands that satisfy 'm' when -mpcrel is in effect 20969 20970 'T' 20971 Operands that satisfy 's' when -mpcrel is not in effect 20972 20973 'Q' 20974 Address register indirect addressing mode 20975 20976 'U' 20977 Register offset addressing 20978 20979 'W' 20980 const_call_operand 20981 20982 'Cs' 20983 symbol_ref or const 20984 20985 'Ci' 20986 const_int 20987 20988 'C0' 20989 const_int 0 20990 20991 'Cj' 20992 Range of signed numbers that don't fit in 16 bits 20993 20994 'Cmvq' 20995 Integers valid for mvq 20996 20997 'Capsw' 20998 Integers valid for a moveq followed by a swap 20999 21000 'Cmvz' 21001 Integers valid for mvz 21002 21003 'Cmvs' 21004 Integers valid for mvs 21005 21006 'Ap' 21007 push_operand 21008 21009 'Ac' 21010 Non-register operands allowed in clr 21011 21012_Moxie--'config/moxie/constraints.md'_ 21013 'A' 21014 An absolute address 21015 21016 'B' 21017 An offset address 21018 21019 'W' 21020 A register indirect memory operand 21021 21022 'I' 21023 A constant in the range of 0 to 255. 21024 21025 'N' 21026 A constant in the range of 0 to -255. 21027 21028_MSP430-'config/msp430/constraints.md'_ 21029 21030 'R12' 21031 Register R12. 21032 21033 'R13' 21034 Register R13. 21035 21036 'K' 21037 Integer constant 1. 21038 21039 'L' 21040 Integer constant -1^20..1^19. 21041 21042 'M' 21043 Integer constant 1-4. 21044 21045 'Ya' 21046 Memory references which do not require an extended MOVX 21047 instruction. 21048 21049 'Yl' 21050 Memory reference, labels only. 21051 21052 'Ys' 21053 Memory reference, stack only. 21054 21055_NDS32--'config/nds32/constraints.md'_ 21056 'w' 21057 LOW register class $r0 to $r7 constraint for V3/V3M ISA. 21058 'l' 21059 LOW register class $r0 to $r7. 21060 'd' 21061 MIDDLE register class $r0 to $r11, $r16 to $r19. 21062 'h' 21063 HIGH register class $r12 to $r14, $r20 to $r31. 21064 't' 21065 Temporary assist register $ta (i.e. $r15). 21066 'k' 21067 Stack register $sp. 21068 'Iu03' 21069 Unsigned immediate 3-bit value. 21070 'In03' 21071 Negative immediate 3-bit value in the range of -7-0. 21072 'Iu04' 21073 Unsigned immediate 4-bit value. 21074 'Is05' 21075 Signed immediate 5-bit value. 21076 'Iu05' 21077 Unsigned immediate 5-bit value. 21078 'In05' 21079 Negative immediate 5-bit value in the range of -31-0. 21080 'Ip05' 21081 Unsigned immediate 5-bit value for movpi45 instruction with 21082 range 16-47. 21083 'Iu06' 21084 Unsigned immediate 6-bit value constraint for addri36.sp 21085 instruction. 21086 'Iu08' 21087 Unsigned immediate 8-bit value. 21088 'Iu09' 21089 Unsigned immediate 9-bit value. 21090 'Is10' 21091 Signed immediate 10-bit value. 21092 'Is11' 21093 Signed immediate 11-bit value. 21094 'Is15' 21095 Signed immediate 15-bit value. 21096 'Iu15' 21097 Unsigned immediate 15-bit value. 21098 'Ic15' 21099 A constant which is not in the range of imm15u but ok for bclr 21100 instruction. 21101 'Ie15' 21102 A constant which is not in the range of imm15u but ok for bset 21103 instruction. 21104 'It15' 21105 A constant which is not in the range of imm15u but ok for btgl 21106 instruction. 21107 'Ii15' 21108 A constant whose compliment value is in the range of imm15u 21109 and ok for bitci instruction. 21110 'Is16' 21111 Signed immediate 16-bit value. 21112 'Is17' 21113 Signed immediate 17-bit value. 21114 'Is19' 21115 Signed immediate 19-bit value. 21116 'Is20' 21117 Signed immediate 20-bit value. 21118 'Ihig' 21119 The immediate value that can be simply set high 20-bit. 21120 'Izeb' 21121 The immediate value 0xff. 21122 'Izeh' 21123 The immediate value 0xffff. 21124 'Ixls' 21125 The immediate value 0x01. 21126 'Ix11' 21127 The immediate value 0x7ff. 21128 'Ibms' 21129 The immediate value with power of 2. 21130 'Ifex' 21131 The immediate value with power of 2 minus 1. 21132 'U33' 21133 Memory constraint for 333 format. 21134 'U45' 21135 Memory constraint for 45 format. 21136 'U37' 21137 Memory constraint for 37 format. 21138 21139_Nios II family--'config/nios2/constraints.md'_ 21140 21141 'I' 21142 Integer that is valid as an immediate operand in an 21143 instruction taking a signed 16-bit number. Range -32768 to 21144 32767. 21145 21146 'J' 21147 Integer that is valid as an immediate operand in an 21148 instruction taking an unsigned 16-bit number. Range 0 to 21149 65535. 21150 21151 'K' 21152 Integer that is valid as an immediate operand in an 21153 instruction taking only the upper 16-bits of a 32-bit number. 21154 Range 32-bit numbers with the lower 16-bits being 0. 21155 21156 'L' 21157 Integer that is valid as an immediate operand for a shift 21158 instruction. Range 0 to 31. 21159 21160 'M' 21161 Integer that is valid as an immediate operand for only the 21162 value 0. Can be used in conjunction with the format modifier 21163 'z' to use 'r0' instead of '0' in the assembly output. 21164 21165 'N' 21166 Integer that is valid as an immediate operand for a custom 21167 instruction opcode. Range 0 to 255. 21168 21169 'P' 21170 An immediate operand for R2 andchi/andci instructions. 21171 21172 'S' 21173 Matches immediates which are addresses in the small data 21174 section and therefore can be added to 'gp' as a 16-bit 21175 immediate to re-create their 32-bit value. 21176 21177 'U' 21178 Matches constants suitable as an operand for the rdprs and 21179 cache instructions. 21180 21181 'v' 21182 A memory operand suitable for Nios II R2 load/store exclusive 21183 instructions. 21184 21185 'w' 21186 A memory operand suitable for load/store IO and cache 21187 instructions. 21188 21189 'T' 21190 A 'const' wrapped 'UNSPEC' expression, representing a 21191 supported PIC or TLS relocation. 21192 21193_PDP-11--'config/pdp11/constraints.md'_ 21194 'a' 21195 Floating point registers AC0 through AC3. These can be loaded 21196 from/to memory with a single instruction. 21197 21198 'd' 21199 Odd numbered general registers (R1, R3, R5). These are used 21200 for 16-bit multiply operations. 21201 21202 'f' 21203 Any of the floating point registers (AC0 through AC5). 21204 21205 'G' 21206 Floating point constant 0. 21207 21208 'I' 21209 An integer constant that fits in 16 bits. 21210 21211 'J' 21212 An integer constant whose low order 16 bits are zero. 21213 21214 'K' 21215 An integer constant that does not meet the constraints for 21216 codes 'I' or 'J'. 21217 21218 'L' 21219 The integer constant 1. 21220 21221 'M' 21222 The integer constant -1. 21223 21224 'N' 21225 The integer constant 0. 21226 21227 'O' 21228 Integer constants -4 through -1 and 1 through 4; shifts by 21229 these amounts are handled as multiple single-bit shifts rather 21230 than a single variable-length shift. 21231 21232 'Q' 21233 A memory reference which requires an additional word (address 21234 or offset) after the opcode. 21235 21236 'R' 21237 A memory reference that is encoded within the opcode. 21238 21239_PowerPC and IBM RS6000--'config/rs6000/constraints.md'_ 21240 'b' 21241 Address base register 21242 21243 'd' 21244 Floating point register (containing 64-bit value) 21245 21246 'f' 21247 Floating point register (containing 32-bit value) 21248 21249 'v' 21250 Altivec vector register 21251 21252 'wa' 21253 Any VSX register if the -mvsx option was used or NO_REGS. 21254 21255 When using any of the register constraints ('wa', 'wd', 'wf', 21256 'wg', 'wh', 'wi', 'wj', 'wk', 'wl', 'wm', 'wo', 'wp', 'wq', 21257 'ws', 'wt', 'wu', 'wv', 'ww', or 'wy') that take VSX 21258 registers, you must use '%x<n>' in the template so that the 21259 correct register is used. Otherwise the register number 21260 output in the assembly file will be incorrect if an Altivec 21261 register is an operand of a VSX instruction that expects VSX 21262 register numbering. 21263 21264 asm ("xvadddp %x0,%x1,%x2" : "=wa" (v1) : "wa" (v2), "wa" (v3)); 21265 21266 is correct, but: 21267 21268 asm ("xvadddp %0,%1,%2" : "=wa" (v1) : "wa" (v2), "wa" (v3)); 21269 21270 is not correct. 21271 21272 If an instruction only takes Altivec registers, you do not 21273 want to use '%x<n>'. 21274 21275 asm ("xsaddqp %0,%1,%2" : "=v" (v1) : "v" (v2), "v" (v3)); 21276 21277 is correct because the 'xsaddqp' instruction only takes 21278 Altivec registers, while: 21279 21280 asm ("xsaddqp %x0,%x1,%x2" : "=v" (v1) : "v" (v2), "v" (v3)); 21281 21282 is incorrect. 21283 21284 'wb' 21285 Altivec register if '-mcpu=power9' is used or NO_REGS. 21286 21287 'wd' 21288 VSX vector register to hold vector double data or NO_REGS. 21289 21290 'we' 21291 VSX register if the '-mcpu=power9' and '-m64' options were 21292 used or NO_REGS. 21293 21294 'wf' 21295 VSX vector register to hold vector float data or NO_REGS. 21296 21297 'wg' 21298 If '-mmfpgpr' was used, a floating point register or NO_REGS. 21299 21300 'wh' 21301 Floating point register if direct moves are available, or 21302 NO_REGS. 21303 21304 'wi' 21305 FP or VSX register to hold 64-bit integers for VSX insns or 21306 NO_REGS. 21307 21308 'wj' 21309 FP or VSX register to hold 64-bit integers for direct moves or 21310 NO_REGS. 21311 21312 'wk' 21313 FP or VSX register to hold 64-bit doubles for direct moves or 21314 NO_REGS. 21315 21316 'wl' 21317 Floating point register if the LFIWAX instruction is enabled 21318 or NO_REGS. 21319 21320 'wm' 21321 VSX register if direct move instructions are enabled, or 21322 NO_REGS. 21323 21324 'wn' 21325 No register (NO_REGS). 21326 21327 'wo' 21328 VSX register to use for ISA 3.0 vector instructions, or 21329 NO_REGS. 21330 21331 'wp' 21332 VSX register to use for IEEE 128-bit floating point TFmode, or 21333 NO_REGS. 21334 21335 'wq' 21336 VSX register to use for IEEE 128-bit floating point, or 21337 NO_REGS. 21338 21339 'wr' 21340 General purpose register if 64-bit instructions are enabled or 21341 NO_REGS. 21342 21343 'ws' 21344 VSX vector register to hold scalar double values or NO_REGS. 21345 21346 'wt' 21347 VSX vector register to hold 128 bit integer or NO_REGS. 21348 21349 'wu' 21350 Altivec register to use for float/32-bit int loads/stores or 21351 NO_REGS. 21352 21353 'wv' 21354 Altivec register to use for double loads/stores or NO_REGS. 21355 21356 'ww' 21357 FP or VSX register to perform float operations under '-mvsx' 21358 or NO_REGS. 21359 21360 'wx' 21361 Floating point register if the STFIWX instruction is enabled 21362 or NO_REGS. 21363 21364 'wy' 21365 FP or VSX register to perform ISA 2.07 float ops or NO_REGS. 21366 21367 'wz' 21368 Floating point register if the LFIWZX instruction is enabled 21369 or NO_REGS. 21370 21371 'wA' 21372 Address base register if 64-bit instructions are enabled or 21373 NO_REGS. 21374 21375 'wD' 21376 Int constant that is the element number of the 64-bit scalar 21377 in a vector. 21378 21379 'wE' 21380 Vector constant that can be loaded with the XXSPLTIB 21381 instruction. 21382 21383 'wF' 21384 Memory operand suitable for power9 fusion load/stores. 21385 21386 'wG' 21387 Memory operand suitable for TOC fusion memory references. 21388 21389 'wL' 21390 Int constant that is the element number that the MFVSRLD 21391 instruction. targets. 21392 21393 'wM' 21394 Match vector constant with all 1's if the XXLORC instruction 21395 is available. 21396 21397 'wO' 21398 A memory operand suitable for the ISA 3.0 vector d-form 21399 instructions. 21400 21401 'wQ' 21402 A memory address that will work with the 'lq' and 'stq' 21403 instructions. 21404 21405 'wS' 21406 Vector constant that can be loaded with XXSPLTIB & sign 21407 extension. 21408 21409 'h' 21410 'MQ', 'CTR', or 'LINK' register 21411 21412 'c' 21413 'CTR' register 21414 21415 'l' 21416 'LINK' register 21417 21418 'x' 21419 'CR' register (condition register) number 0 21420 21421 'y' 21422 'CR' register (condition register) 21423 21424 'z' 21425 'XER[CA]' carry bit (part of the XER register) 21426 21427 'I' 21428 Signed 16-bit constant 21429 21430 'J' 21431 Unsigned 16-bit constant shifted left 16 bits (use 'L' instead 21432 for 'SImode' constants) 21433 21434 'K' 21435 Unsigned 16-bit constant 21436 21437 'L' 21438 Signed 16-bit constant shifted left 16 bits 21439 21440 'M' 21441 Constant larger than 31 21442 21443 'N' 21444 Exact power of 2 21445 21446 'O' 21447 Zero 21448 21449 'P' 21450 Constant whose negation is a signed 16-bit constant 21451 21452 'G' 21453 Floating point constant that can be loaded into a register 21454 with one instruction per word 21455 21456 'H' 21457 Integer/Floating point constant that can be loaded into a 21458 register using three instructions 21459 21460 'm' 21461 Memory operand. Normally, 'm' does not allow addresses that 21462 update the base register. If '<' or '>' constraint is also 21463 used, they are allowed and therefore on PowerPC targets in 21464 that case it is only safe to use 'm<>' in an 'asm' statement 21465 if that 'asm' statement accesses the operand exactly once. 21466 The 'asm' statement must also use '%U<OPNO>' as a placeholder 21467 for the "update" flag in the corresponding load or store 21468 instruction. For example: 21469 21470 asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); 21471 21472 is correct but: 21473 21474 asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); 21475 21476 is not. 21477 21478 'es' 21479 A "stable" memory operand; that is, one which does not include 21480 any automodification of the base register. This used to be 21481 useful when 'm' allowed automodification of the base register, 21482 but as those are now only allowed when '<' or '>' is used, 21483 'es' is basically the same as 'm' without '<' and '>'. 21484 21485 'Q' 21486 Memory operand that is an offset from a register (it is 21487 usually better to use 'm' or 'es' in 'asm' statements) 21488 21489 'Z' 21490 Memory operand that is an indexed or indirect from a register 21491 (it is usually better to use 'm' or 'es' in 'asm' statements) 21492 21493 'R' 21494 AIX TOC entry 21495 21496 'a' 21497 Address operand that is an indexed or indirect from a register 21498 ('p' is preferable for 'asm' statements) 21499 21500 'U' 21501 System V Release 4 small data area reference 21502 21503 'W' 21504 Vector constant that does not require memory 21505 21506 'j' 21507 Vector constant that is all zeros. 21508 21509_RL78--'config/rl78/constraints.md'_ 21510 21511 'Int3' 21512 An integer constant in the range 1 ... 7. 21513 'Int8' 21514 An integer constant in the range 0 ... 255. 21515 'J' 21516 An integer constant in the range -255 ... 0 21517 'K' 21518 The integer constant 1. 21519 'L' 21520 The integer constant -1. 21521 'M' 21522 The integer constant 0. 21523 'N' 21524 The integer constant 2. 21525 'O' 21526 The integer constant -2. 21527 'P' 21528 An integer constant in the range 1 ... 15. 21529 'Qbi' 21530 The built-in compare types-eq, ne, gtu, ltu, geu, and leu. 21531 'Qsc' 21532 The synthetic compare types-gt, lt, ge, and le. 21533 'Wab' 21534 A memory reference with an absolute address. 21535 'Wbc' 21536 A memory reference using 'BC' as a base register, with an 21537 optional offset. 21538 'Wca' 21539 A memory reference using 'AX', 'BC', 'DE', or 'HL' for the 21540 address, for calls. 21541 'Wcv' 21542 A memory reference using any 16-bit register pair for the 21543 address, for calls. 21544 'Wd2' 21545 A memory reference using 'DE' as a base register, with an 21546 optional offset. 21547 'Wde' 21548 A memory reference using 'DE' as a base register, without any 21549 offset. 21550 'Wfr' 21551 Any memory reference to an address in the far address space. 21552 'Wh1' 21553 A memory reference using 'HL' as a base register, with an 21554 optional one-byte offset. 21555 'Whb' 21556 A memory reference using 'HL' as a base register, with 'B' or 21557 'C' as the index register. 21558 'Whl' 21559 A memory reference using 'HL' as a base register, without any 21560 offset. 21561 'Ws1' 21562 A memory reference using 'SP' as a base register, with an 21563 optional one-byte offset. 21564 'Y' 21565 Any memory reference to an address in the near address space. 21566 'A' 21567 The 'AX' register. 21568 'B' 21569 The 'BC' register. 21570 'D' 21571 The 'DE' register. 21572 'R' 21573 'A' through 'L' registers. 21574 'S' 21575 The 'SP' register. 21576 'T' 21577 The 'HL' register. 21578 'Z08W' 21579 The 16-bit 'R8' register. 21580 'Z10W' 21581 The 16-bit 'R10' register. 21582 'Zint' 21583 The registers reserved for interrupts ('R24' to 'R31'). 21584 'a' 21585 The 'A' register. 21586 'b' 21587 The 'B' register. 21588 'c' 21589 The 'C' register. 21590 'd' 21591 The 'D' register. 21592 'e' 21593 The 'E' register. 21594 'h' 21595 The 'H' register. 21596 'l' 21597 The 'L' register. 21598 'v' 21599 The virtual registers. 21600 'w' 21601 The 'PSW' register. 21602 'x' 21603 The 'X' register. 21604 21605_RX--'config/rx/constraints.md'_ 21606 'Q' 21607 An address which does not involve register indirect addressing 21608 or pre/post increment/decrement addressing. 21609 21610 'Symbol' 21611 A symbol reference. 21612 21613 'Int08' 21614 A constant in the range -256 to 255, inclusive. 21615 21616 'Sint08' 21617 A constant in the range -128 to 127, inclusive. 21618 21619 'Sint16' 21620 A constant in the range -32768 to 32767, inclusive. 21621 21622 'Sint24' 21623 A constant in the range -8388608 to 8388607, inclusive. 21624 21625 'Uint04' 21626 A constant in the range 0 to 15, inclusive. 21627 21628_S/390 and zSeries--'config/s390/s390.h'_ 21629 'a' 21630 Address register (general purpose register except r0) 21631 21632 'c' 21633 Condition code register 21634 21635 'd' 21636 Data register (arbitrary general purpose register) 21637 21638 'f' 21639 Floating-point register 21640 21641 'I' 21642 Unsigned 8-bit constant (0-255) 21643 21644 'J' 21645 Unsigned 12-bit constant (0-4095) 21646 21647 'K' 21648 Signed 16-bit constant (-32768-32767) 21649 21650 'L' 21651 Value appropriate as displacement. 21652 '(0..4095)' 21653 for short displacement 21654 '(-524288..524287)' 21655 for long displacement 21656 21657 'M' 21658 Constant integer with a value of 0x7fffffff. 21659 21660 'N' 21661 Multiple letter constraint followed by 4 parameter letters. 21662 '0..9:' 21663 number of the part counting from most to least 21664 significant 21665 'H,Q:' 21666 mode of the part 21667 'D,S,H:' 21668 mode of the containing operand 21669 '0,F:' 21670 value of the other parts (F--all bits set) 21671 The constraint matches if the specified part of a constant has 21672 a value different from its other parts. 21673 21674 'Q' 21675 Memory reference without index register and with short 21676 displacement. 21677 21678 'R' 21679 Memory reference with index register and short displacement. 21680 21681 'S' 21682 Memory reference without index register but with long 21683 displacement. 21684 21685 'T' 21686 Memory reference with index register and long displacement. 21687 21688 'U' 21689 Pointer with short displacement. 21690 21691 'W' 21692 Pointer with long displacement. 21693 21694 'Y' 21695 Shift count operand. 21696 21697_SPARC--'config/sparc/sparc.h'_ 21698 'f' 21699 Floating-point register on the SPARC-V8 architecture and lower 21700 floating-point register on the SPARC-V9 architecture. 21701 21702 'e' 21703 Floating-point register. It is equivalent to 'f' on the 21704 SPARC-V8 architecture and contains both lower and upper 21705 floating-point registers on the SPARC-V9 architecture. 21706 21707 'c' 21708 Floating-point condition code register. 21709 21710 'd' 21711 Lower floating-point register. It is only valid on the 21712 SPARC-V9 architecture when the Visual Instruction Set is 21713 available. 21714 21715 'b' 21716 Floating-point register. It is only valid on the SPARC-V9 21717 architecture when the Visual Instruction Set is available. 21718 21719 'h' 21720 64-bit global or out register for the SPARC-V8+ architecture. 21721 21722 'C' 21723 The constant all-ones, for floating-point. 21724 21725 'A' 21726 Signed 5-bit constant 21727 21728 'D' 21729 A vector constant 21730 21731 'I' 21732 Signed 13-bit constant 21733 21734 'J' 21735 Zero 21736 21737 'K' 21738 32-bit constant with the low 12 bits clear (a constant that 21739 can be loaded with the 'sethi' instruction) 21740 21741 'L' 21742 A constant in the range supported by 'movcc' instructions 21743 (11-bit signed immediate) 21744 21745 'M' 21746 A constant in the range supported by 'movrcc' instructions 21747 (10-bit signed immediate) 21748 21749 'N' 21750 Same as 'K', except that it verifies that bits that are not in 21751 the lower 32-bit range are all zero. Must be used instead of 21752 'K' for modes wider than 'SImode' 21753 21754 'O' 21755 The constant 4096 21756 21757 'G' 21758 Floating-point zero 21759 21760 'H' 21761 Signed 13-bit constant, sign-extended to 32 or 64 bits 21762 21763 'P' 21764 The constant -1 21765 21766 'Q' 21767 Floating-point constant whose integral representation can be 21768 moved into an integer register using a single sethi 21769 instruction 21770 21771 'R' 21772 Floating-point constant whose integral representation can be 21773 moved into an integer register using a single mov instruction 21774 21775 'S' 21776 Floating-point constant whose integral representation can be 21777 moved into an integer register using a high/lo_sum instruction 21778 sequence 21779 21780 'T' 21781 Memory address aligned to an 8-byte boundary 21782 21783 'U' 21784 Even register 21785 21786 'W' 21787 Memory address for 'e' constraint registers 21788 21789 'w' 21790 Memory address with only a base register 21791 21792 'Y' 21793 Vector zero 21794 21795_SPU--'config/spu/spu.h'_ 21796 'a' 21797 An immediate which can be loaded with the il/ila/ilh/ilhu 21798 instructions. const_int is treated as a 64 bit value. 21799 21800 'c' 21801 An immediate for and/xor/or instructions. const_int is 21802 treated as a 64 bit value. 21803 21804 'd' 21805 An immediate for the 'iohl' instruction. const_int is treated 21806 as a 64 bit value. 21807 21808 'f' 21809 An immediate which can be loaded with 'fsmbi'. 21810 21811 'A' 21812 An immediate which can be loaded with the il/ila/ilh/ilhu 21813 instructions. const_int is treated as a 32 bit value. 21814 21815 'B' 21816 An immediate for most arithmetic instructions. const_int is 21817 treated as a 32 bit value. 21818 21819 'C' 21820 An immediate for and/xor/or instructions. const_int is 21821 treated as a 32 bit value. 21822 21823 'D' 21824 An immediate for the 'iohl' instruction. const_int is treated 21825 as a 32 bit value. 21826 21827 'I' 21828 A constant in the range [-64, 63] for shift/rotate 21829 instructions. 21830 21831 'J' 21832 An unsigned 7-bit constant for conversion/nop/channel 21833 instructions. 21834 21835 'K' 21836 A signed 10-bit constant for most arithmetic instructions. 21837 21838 'M' 21839 A signed 16 bit immediate for 'stop'. 21840 21841 'N' 21842 An unsigned 16-bit constant for 'iohl' and 'fsmbi'. 21843 21844 'O' 21845 An unsigned 7-bit constant whose 3 least significant bits are 21846 0. 21847 21848 'P' 21849 An unsigned 3-bit constant for 16-byte rotates and shifts 21850 21851 'R' 21852 Call operand, reg, for indirect calls 21853 21854 'S' 21855 Call operand, symbol, for relative calls. 21856 21857 'T' 21858 Call operand, const_int, for absolute calls. 21859 21860 'U' 21861 An immediate which can be loaded with the il/ila/ilh/ilhu 21862 instructions. const_int is sign extended to 128 bit. 21863 21864 'W' 21865 An immediate for shift and rotate instructions. const_int is 21866 treated as a 32 bit value. 21867 21868 'Y' 21869 An immediate for and/xor/or instructions. const_int is sign 21870 extended as a 128 bit. 21871 21872 'Z' 21873 An immediate for the 'iohl' instruction. const_int is sign 21874 extended to 128 bit. 21875 21876_TI C6X family--'config/c6x/constraints.md'_ 21877 'a' 21878 Register file A (A0-A31). 21879 21880 'b' 21881 Register file B (B0-B31). 21882 21883 'A' 21884 Predicate registers in register file A (A0-A2 on C64X and 21885 higher, A1 and A2 otherwise). 21886 21887 'B' 21888 Predicate registers in register file B (B0-B2). 21889 21890 'C' 21891 A call-used register in register file B (B0-B9, B16-B31). 21892 21893 'Da' 21894 Register file A, excluding predicate registers (A3-A31, plus 21895 A0 if not C64X or higher). 21896 21897 'Db' 21898 Register file B, excluding predicate registers (B3-B31). 21899 21900 'Iu4' 21901 Integer constant in the range 0 ... 15. 21902 21903 'Iu5' 21904 Integer constant in the range 0 ... 31. 21905 21906 'In5' 21907 Integer constant in the range -31 ... 0. 21908 21909 'Is5' 21910 Integer constant in the range -16 ... 15. 21911 21912 'I5x' 21913 Integer constant that can be the operand of an ADDA or a SUBA 21914 insn. 21915 21916 'IuB' 21917 Integer constant in the range 0 ... 65535. 21918 21919 'IsB' 21920 Integer constant in the range -32768 ... 32767. 21921 21922 'IsC' 21923 Integer constant in the range -2^{20} ... 2^{20} - 1. 21924 21925 'Jc' 21926 Integer constant that is a valid mask for the clr instruction. 21927 21928 'Js' 21929 Integer constant that is a valid mask for the set instruction. 21930 21931 'Q' 21932 Memory location with A base register. 21933 21934 'R' 21935 Memory location with B base register. 21936 21937 'S0' 21938 On C64x+ targets, a GP-relative small data reference. 21939 21940 'S1' 21941 Any kind of 'SYMBOL_REF', for use in a call address. 21942 21943 'Si' 21944 Any kind of immediate operand, unless it matches the S0 21945 constraint. 21946 21947 'T' 21948 Memory location with B base register, but not using a long 21949 offset. 21950 21951 'W' 21952 A memory operand with an address that can't be used in an 21953 unaligned access. 21954 21955 'Z' 21956 Register B14 (aka DP). 21957 21958_TILE-Gx--'config/tilegx/constraints.md'_ 21959 'R00' 21960 'R01' 21961 'R02' 21962 'R03' 21963 'R04' 21964 'R05' 21965 'R06' 21966 'R07' 21967 'R08' 21968 'R09' 21969 'R10' 21970 Each of these represents a register constraint for an 21971 individual register, from r0 to r10. 21972 21973 'I' 21974 Signed 8-bit integer constant. 21975 21976 'J' 21977 Signed 16-bit integer constant. 21978 21979 'K' 21980 Unsigned 16-bit integer constant. 21981 21982 'L' 21983 Integer constant that fits in one signed byte when incremented 21984 by one (-129 ... 126). 21985 21986 'm' 21987 Memory operand. If used together with '<' or '>', the operand 21988 can have postincrement which requires printing with '%In' and 21989 '%in' on TILE-Gx. For example: 21990 21991 asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val)); 21992 21993 'M' 21994 A bit mask suitable for the BFINS instruction. 21995 21996 'N' 21997 Integer constant that is a byte tiled out eight times. 21998 21999 'O' 22000 The integer zero constant. 22001 22002 'P' 22003 Integer constant that is a sign-extended byte tiled out as 22004 four shorts. 22005 22006 'Q' 22007 Integer constant that fits in one signed byte when incremented 22008 (-129 ... 126), but excluding -1. 22009 22010 'S' 22011 Integer constant that has all 1 bits consecutive and starting 22012 at bit 0. 22013 22014 'T' 22015 A 16-bit fragment of a got, tls, or pc-relative reference. 22016 22017 'U' 22018 Memory operand except postincrement. This is roughly the same 22019 as 'm' when not used together with '<' or '>'. 22020 22021 'W' 22022 An 8-element vector constant with identical elements. 22023 22024 'Y' 22025 A 4-element vector constant with identical elements. 22026 22027 'Z0' 22028 The integer constant 0xffffffff. 22029 22030 'Z1' 22031 The integer constant 0xffffffff00000000. 22032 22033_TILEPro--'config/tilepro/constraints.md'_ 22034 'R00' 22035 'R01' 22036 'R02' 22037 'R03' 22038 'R04' 22039 'R05' 22040 'R06' 22041 'R07' 22042 'R08' 22043 'R09' 22044 'R10' 22045 Each of these represents a register constraint for an 22046 individual register, from r0 to r10. 22047 22048 'I' 22049 Signed 8-bit integer constant. 22050 22051 'J' 22052 Signed 16-bit integer constant. 22053 22054 'K' 22055 Nonzero integer constant with low 16 bits zero. 22056 22057 'L' 22058 Integer constant that fits in one signed byte when incremented 22059 by one (-129 ... 126). 22060 22061 'm' 22062 Memory operand. If used together with '<' or '>', the operand 22063 can have postincrement which requires printing with '%In' and 22064 '%in' on TILEPro. For example: 22065 22066 asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val)); 22067 22068 'M' 22069 A bit mask suitable for the MM instruction. 22070 22071 'N' 22072 Integer constant that is a byte tiled out four times. 22073 22074 'O' 22075 The integer zero constant. 22076 22077 'P' 22078 Integer constant that is a sign-extended byte tiled out as two 22079 shorts. 22080 22081 'Q' 22082 Integer constant that fits in one signed byte when incremented 22083 (-129 ... 126), but excluding -1. 22084 22085 'T' 22086 A symbolic operand, or a 16-bit fragment of a got, tls, or 22087 pc-relative reference. 22088 22089 'U' 22090 Memory operand except postincrement. This is roughly the same 22091 as 'm' when not used together with '<' or '>'. 22092 22093 'W' 22094 A 4-element vector constant with identical elements. 22095 22096 'Y' 22097 A 2-element vector constant with identical elements. 22098 22099_Visium--'config/visium/constraints.md'_ 22100 'b' 22101 EAM register 'mdb' 22102 22103 'c' 22104 EAM register 'mdc' 22105 22106 'f' 22107 Floating point register 22108 22109 'k' 22110 Register for sibcall optimization 22111 22112 'l' 22113 General register, but not 'r29', 'r30' and 'r31' 22114 22115 't' 22116 Register 'r1' 22117 22118 'u' 22119 Register 'r2' 22120 22121 'v' 22122 Register 'r3' 22123 22124 'G' 22125 Floating-point constant 0.0 22126 22127 'J' 22128 Integer constant in the range 0 .. 65535 (16-bit immediate) 22129 22130 'K' 22131 Integer constant in the range 1 .. 31 (5-bit immediate) 22132 22133 'L' 22134 Integer constant in the range -65535 .. -1 (16-bit negative 22135 immediate) 22136 22137 'M' 22138 Integer constant -1 22139 22140 'O' 22141 Integer constant 0 22142 22143 'P' 22144 Integer constant 32 22145 22146_x86 family--'config/i386/constraints.md'_ 22147 'R' 22148 Legacy register--the eight integer registers available on all 22149 i386 processors ('a', 'b', 'c', 'd', 'si', 'di', 'bp', 'sp'). 22150 22151 'q' 22152 Any register accessible as 'Rl'. In 32-bit mode, 'a', 'b', 22153 'c', and 'd'; in 64-bit mode, any integer register. 22154 22155 'Q' 22156 Any register accessible as 'Rh': 'a', 'b', 'c', and 'd'. 22157 22158 'l' 22159 Any register that can be used as the index in a base+index 22160 memory access: that is, any general register except the stack 22161 pointer. 22162 22163 'a' 22164 The 'a' register. 22165 22166 'b' 22167 The 'b' register. 22168 22169 'c' 22170 The 'c' register. 22171 22172 'd' 22173 The 'd' register. 22174 22175 'S' 22176 The 'si' register. 22177 22178 'D' 22179 The 'di' register. 22180 22181 'A' 22182 The 'a' and 'd' registers. This class is used for 22183 instructions that return double word results in the 'ax:dx' 22184 register pair. Single word values will be allocated either in 22185 'ax' or 'dx'. For example on i386 the following implements 22186 'rdtsc': 22187 22188 unsigned long long rdtsc (void) 22189 { 22190 unsigned long long tick; 22191 __asm__ __volatile__("rdtsc":"=A"(tick)); 22192 return tick; 22193 } 22194 22195 This is not correct on x86-64 as it would allocate tick in 22196 either 'ax' or 'dx'. You have to use the following variant 22197 instead: 22198 22199 unsigned long long rdtsc (void) 22200 { 22201 unsigned int tickl, tickh; 22202 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); 22203 return ((unsigned long long)tickh << 32)|tickl; 22204 } 22205 22206 'f' 22207 Any 80387 floating-point (stack) register. 22208 22209 't' 22210 Top of 80387 floating-point stack ('%st(0)'). 22211 22212 'u' 22213 Second from top of 80387 floating-point stack ('%st(1)'). 22214 22215 'y' 22216 Any MMX register. 22217 22218 'x' 22219 Any SSE register. 22220 22221 'Yz' 22222 First SSE register ('%xmm0'). 22223 22224 'Y2' 22225 Any SSE register, when SSE2 is enabled. 22226 22227 'Yi' 22228 Any SSE register, when SSE2 and inter-unit moves are enabled. 22229 22230 'Ym' 22231 Any MMX register, when inter-unit moves are enabled. 22232 22233 'I' 22234 Integer constant in the range 0 ... 31, for 32-bit shifts. 22235 22236 'J' 22237 Integer constant in the range 0 ... 63, for 64-bit shifts. 22238 22239 'K' 22240 Signed 8-bit integer constant. 22241 22242 'L' 22243 '0xFF' or '0xFFFF', for andsi as a zero-extending move. 22244 22245 'M' 22246 0, 1, 2, or 3 (shifts for the 'lea' instruction). 22247 22248 'N' 22249 Unsigned 8-bit integer constant (for 'in' and 'out' 22250 instructions). 22251 22252 'O' 22253 Integer constant in the range 0 ... 127, for 128-bit shifts. 22254 22255 'G' 22256 Standard 80387 floating point constant. 22257 22258 'C' 22259 SSE constant zero operand. 22260 22261 'e' 22262 32-bit signed integer constant, or a symbolic reference known 22263 to fit that range (for immediate operands in sign-extending 22264 x86-64 instructions). 22265 22266 'Z' 22267 32-bit unsigned integer constant, or a symbolic reference 22268 known to fit that range (for immediate operands in 22269 zero-extending x86-64 instructions). 22270 22271_Xstormy16--'config/stormy16/stormy16.h'_ 22272 'a' 22273 Register r0. 22274 22275 'b' 22276 Register r1. 22277 22278 'c' 22279 Register r2. 22280 22281 'd' 22282 Register r8. 22283 22284 'e' 22285 Registers r0 through r7. 22286 22287 't' 22288 Registers r0 and r1. 22289 22290 'y' 22291 The carry register. 22292 22293 'z' 22294 Registers r8 and r9. 22295 22296 'I' 22297 A constant between 0 and 3 inclusive. 22298 22299 'J' 22300 A constant that has exactly one bit set. 22301 22302 'K' 22303 A constant that has exactly one bit clear. 22304 22305 'L' 22306 A constant between 0 and 255 inclusive. 22307 22308 'M' 22309 A constant between -255 and 0 inclusive. 22310 22311 'N' 22312 A constant between -3 and 0 inclusive. 22313 22314 'O' 22315 A constant between 1 and 4 inclusive. 22316 22317 'P' 22318 A constant between -4 and -1 inclusive. 22319 22320 'Q' 22321 A memory reference that is a stack push. 22322 22323 'R' 22324 A memory reference that is a stack pop. 22325 22326 'S' 22327 A memory reference that refers to a constant address of known 22328 value. 22329 22330 'T' 22331 The register indicated by Rx (not implemented yet). 22332 22333 'U' 22334 A constant that is not between 2 and 15 inclusive. 22335 22336 'Z' 22337 The constant 0. 22338 22339_Xtensa--'config/xtensa/constraints.md'_ 22340 'a' 22341 General-purpose 32-bit register 22342 22343 'b' 22344 One-bit boolean register 22345 22346 'A' 22347 MAC16 40-bit accumulator register 22348 22349 'I' 22350 Signed 12-bit integer constant, for use in MOVI instructions 22351 22352 'J' 22353 Signed 8-bit integer constant, for use in ADDI instructions 22354 22355 'K' 22356 Integer constant valid for BccI instructions 22357 22358 'L' 22359 Unsigned constant valid for BccUI instructions 22360 22361 22362File: gccint.info, Node: Disable Insn Alternatives, Next: Define Constraints, Prev: Machine Constraints, Up: Constraints 22363 2236416.8.6 Disable insn alternatives using the 'enabled' attribute 22365-------------------------------------------------------------- 22366 22367There are three insn attributes that may be used to selectively disable 22368instruction alternatives: 22369 22370'enabled' 22371 Says whether an alternative is available on the current subtarget. 22372 22373'preferred_for_size' 22374 Says whether an enabled alternative should be used in code that is 22375 optimized for size. 22376 22377'preferred_for_speed' 22378 Says whether an enabled alternative should be used in code that is 22379 optimized for speed. 22380 22381 All these attributes should use '(const_int 1)' to allow an alternative 22382or '(const_int 0)' to disallow it. The attributes must be a static 22383property of the subtarget; they cannot for example depend on the current 22384operands, on the current optimization level, on the location of the insn 22385within the body of a loop, on whether register allocation has finished, 22386or on the current compiler pass. 22387 22388 The 'enabled' attribute is a correctness property. It tells GCC to act 22389as though the disabled alternatives were never defined in the first 22390place. This is useful when adding new instructions to an existing 22391pattern in cases where the new instructions are only available for 22392certain cpu architecture levels (typically mapped to the '-march=' 22393command-line option). 22394 22395 In contrast, the 'preferred_for_size' and 'preferred_for_speed' 22396attributes are strong optimization hints rather than correctness 22397properties. 'preferred_for_size' tells GCC which alternatives to 22398consider when adding or modifying an instruction that GCC wants to 22399optimize for size. 'preferred_for_speed' does the same thing for speed. 22400Note that things like code motion can lead to cases where code optimized 22401for size uses alternatives that are not preferred for size, and 22402similarly for speed. 22403 22404 Although 'define_insn's can in principle specify the 'enabled' 22405attribute directly, it is often clearer to have subsiduary attributes 22406for each architectural feature of interest. The 'define_insn's can then 22407use these subsiduary attributes to say which alternatives require which 22408features. The example below does this for 'cpu_facility'. 22409 22410 E.g. the following two patterns could easily be merged using the 22411'enabled' attribute: 22412 22413 22414 (define_insn "*movdi_old" 22415 [(set (match_operand:DI 0 "register_operand" "=d") 22416 (match_operand:DI 1 "register_operand" " d"))] 22417 "!TARGET_NEW" 22418 "lgr %0,%1") 22419 22420 (define_insn "*movdi_new" 22421 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 22422 (match_operand:DI 1 "register_operand" " d,d,f"))] 22423 "TARGET_NEW" 22424 "@ 22425 lgr %0,%1 22426 ldgr %0,%1 22427 lgdr %0,%1") 22428 22429 22430 to: 22431 22432 22433 (define_insn "*movdi_combined" 22434 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 22435 (match_operand:DI 1 "register_operand" " d,d,f"))] 22436 "" 22437 "@ 22438 lgr %0,%1 22439 ldgr %0,%1 22440 lgdr %0,%1" 22441 [(set_attr "cpu_facility" "*,new,new")]) 22442 22443 22444 with the 'enabled' attribute defined like this: 22445 22446 22447 (define_attr "cpu_facility" "standard,new" (const_string "standard")) 22448 22449 (define_attr "enabled" "" 22450 (cond [(eq_attr "cpu_facility" "standard") (const_int 1) 22451 (and (eq_attr "cpu_facility" "new") 22452 (ne (symbol_ref "TARGET_NEW") (const_int 0))) 22453 (const_int 1)] 22454 (const_int 0))) 22455 22456 22457 22458File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Disable Insn Alternatives, Up: Constraints 22459 2246016.8.7 Defining Machine-Specific Constraints 22461-------------------------------------------- 22462 22463Machine-specific constraints fall into two categories: register and 22464non-register constraints. Within the latter category, constraints which 22465allow subsets of all possible memory or address operands should be 22466specially marked, to give 'reload' more information. 22467 22468 Machine-specific constraints can be given names of arbitrary length, 22469but they must be entirely composed of letters, digits, underscores 22470('_'), and angle brackets ('< >'). Like C identifiers, they must begin 22471with a letter or underscore. 22472 22473 In order to avoid ambiguity in operand constraint strings, no 22474constraint can have a name that begins with any other constraint's name. 22475For example, if 'x' is defined as a constraint name, 'xy' may not be, 22476and vice versa. As a consequence of this rule, no constraint may begin 22477with one of the generic constraint letters: 'E F V X g i m n o p r s'. 22478 22479 Register constraints correspond directly to register classes. *Note 22480Register Classes::. There is thus not much flexibility in their 22481definitions. 22482 22483 -- MD Expression: define_register_constraint name regclass docstring 22484 All three arguments are string constants. NAME is the name of the 22485 constraint, as it will appear in 'match_operand' expressions. If 22486 NAME is a multi-letter constraint its length shall be the same for 22487 all constraints starting with the same letter. REGCLASS can be 22488 either the name of the corresponding register class (*note Register 22489 Classes::), or a C expression which evaluates to the appropriate 22490 register class. If it is an expression, it must have no side 22491 effects, and it cannot look at the operand. The usual use of 22492 expressions is to map some register constraints to 'NO_REGS' when 22493 the register class is not available on a given subarchitecture. 22494 22495 DOCSTRING is a sentence documenting the meaning of the constraint. 22496 Docstrings are explained further below. 22497 22498 Non-register constraints are more like predicates: the constraint 22499definition gives a Boolean expression which indicates whether the 22500constraint matches. 22501 22502 -- MD Expression: define_constraint name docstring exp 22503 The NAME and DOCSTRING arguments are the same as for 22504 'define_register_constraint', but note that the docstring comes 22505 immediately after the name for these expressions. EXP is an RTL 22506 expression, obeying the same rules as the RTL expressions in 22507 predicate definitions. *Note Defining Predicates::, for details. 22508 If it evaluates true, the constraint matches; if it evaluates 22509 false, it doesn't. Constraint expressions should indicate which 22510 RTL codes they might match, just like predicate expressions. 22511 22512 'match_test' C expressions have access to the following variables: 22513 22514 OP 22515 The RTL object defining the operand. 22516 MODE 22517 The machine mode of OP. 22518 IVAL 22519 'INTVAL (OP)', if OP is a 'const_int'. 22520 HVAL 22521 'CONST_DOUBLE_HIGH (OP)', if OP is an integer 'const_double'. 22522 LVAL 22523 'CONST_DOUBLE_LOW (OP)', if OP is an integer 'const_double'. 22524 RVAL 22525 'CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 22526 'const_double'. 22527 22528 The *VAL variables should only be used once another piece of the 22529 expression has verified that OP is the appropriate kind of RTL 22530 object. 22531 22532 Most non-register constraints should be defined with 22533'define_constraint'. The remaining two definition expressions are only 22534appropriate for constraints that should be handled specially by 'reload' 22535if they fail to match. 22536 22537 -- MD Expression: define_memory_constraint name docstring exp 22538 Use this expression for constraints that match a subset of all 22539 memory operands: that is, 'reload' can make them match by 22540 converting the operand to the form '(mem (reg X))', where X is a 22541 base register (from the register class specified by 22542 'BASE_REG_CLASS', *note Register Classes::). 22543 22544 For example, on the S/390, some instructions do not accept 22545 arbitrary memory references, but only those that do not make use of 22546 an index register. The constraint letter 'Q' is defined to 22547 represent a memory address of this type. If 'Q' is defined with 22548 'define_memory_constraint', a 'Q' constraint can handle any memory 22549 operand, because 'reload' knows it can simply copy the memory 22550 address into a base register if required. This is analogous to the 22551 way an 'o' constraint can handle any memory operand. 22552 22553 The syntax and semantics are otherwise identical to 22554 'define_constraint'. 22555 22556 -- MD Expression: define_special_memory_constraint name docstring exp 22557 Use this expression for constraints that match a subset of all 22558 memory operands: that is, 'reload' can not make them match by 22559 reloading the address as it is described for 22560 'define_memory_constraint' or such address reload is undesirable 22561 with the performance point of view. 22562 22563 For example, 'define_special_memory_constraint' can be useful if 22564 specifically aligned memory is necessary or desirable for some insn 22565 operand. 22566 22567 The syntax and semantics are otherwise identical to 22568 'define_constraint'. 22569 22570 -- MD Expression: define_address_constraint name docstring exp 22571 Use this expression for constraints that match a subset of all 22572 address operands: that is, 'reload' can make the constraint match 22573 by converting the operand to the form '(reg X)', again with X a 22574 base register. 22575 22576 Constraints defined with 'define_address_constraint' can only be 22577 used with the 'address_operand' predicate, or machine-specific 22578 predicates that work the same way. They are treated analogously to 22579 the generic 'p' constraint. 22580 22581 The syntax and semantics are otherwise identical to 22582 'define_constraint'. 22583 22584 For historical reasons, names beginning with the letters 'G H' are 22585reserved for constraints that match only 'const_double's, and names 22586beginning with the letters 'I J K L M N O P' are reserved for 22587constraints that match only 'const_int's. This may change in the 22588future. For the time being, constraints with these names must be 22589written in a stylized form, so that 'genpreds' can tell you did it 22590correctly: 22591 22592 (define_constraint "[GHIJKLMNOP]..." 22593 "DOC..." 22594 (and (match_code "const_int") ; 'const_double' for G/H 22595 CONDITION...)) ; usually a 'match_test' 22596 22597 It is fine to use names beginning with other letters for constraints 22598that match 'const_double's or 'const_int's. 22599 22600 Each docstring in a constraint definition should be one or more 22601complete sentences, marked up in Texinfo format. _They are currently 22602unused._ In the future they will be copied into the GCC manual, in 22603*note Machine Constraints::, replacing the hand-maintained tables 22604currently found in that section. Also, in the future the compiler may 22605use this to give more helpful diagnostics when poor choice of 'asm' 22606constraints causes a reload failure. 22607 22608 If you put the pseudo-Texinfo directive '@internal' at the beginning of 22609a docstring, then (in the future) it will appear only in the internals 22610manual's version of the machine-specific constraint tables. Use this 22611for constraints that should not appear in 'asm' statements. 22612 22613 22614File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 22615 2261616.8.8 Testing constraints from C 22617--------------------------------- 22618 22619It is occasionally useful to test a constraint from C code rather than 22620implicitly via the constraint string in a 'match_operand'. The 22621generated file 'tm_p.h' declares a few interfaces for working with 22622constraints. At present these are defined for all constraints except 22623'g' (which is equivalent to 'general_operand'). 22624 22625 Some valid constraint names are not valid C identifiers, so there is a 22626mangling scheme for referring to them from C. Constraint names that do 22627not contain angle brackets or underscores are left unchanged. 22628Underscores are doubled, each '<' is replaced with '_l', and each '>' 22629with '_g'. Here are some examples: 22630 22631 *Original* *Mangled* 22632 x x 22633 P42x P42x 22634 P4_x P4__x 22635 P4>x P4_gx 22636 P4>> P4_g_g 22637 P4_g> P4__g_g 22638 22639 Throughout this section, the variable C is either a constraint in the 22640abstract sense, or a constant from 'enum constraint_num'; the variable M 22641is a mangled constraint name (usually as part of a larger identifier). 22642 22643 -- Enum: constraint_num 22644 For each constraint except 'g', there is a corresponding 22645 enumeration constant: 'CONSTRAINT_' plus the mangled name of the 22646 constraint. Functions that take an 'enum constraint_num' as an 22647 argument expect one of these constants. 22648 22649 -- Function: inline bool satisfies_constraint_M (rtx EXP) 22650 For each non-register constraint M except 'g', there is one of 22651 these functions; it returns 'true' if EXP satisfies the constraint. 22652 These functions are only visible if 'rtl.h' was included before 22653 'tm_p.h'. 22654 22655 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 22656 C) 22657 Like the 'satisfies_constraint_M' functions, but the constraint to 22658 test is given as an argument, C. If C specifies a register 22659 constraint, this function will always return 'false'. 22660 22661 -- Function: enum reg_class reg_class_for_constraint (enum 22662 constraint_num C) 22663 Returns the register class associated with C. If C is not a 22664 register constraint, or those registers are not available for the 22665 currently selected subtarget, returns 'NO_REGS'. 22666 22667 Here is an example use of 'satisfies_constraint_M'. In peephole 22668optimizations (*note Peephole Definitions::), operand constraint strings 22669are ignored, so if there are relevant constraints, they must be tested 22670in the C condition. In the example, the optimization is applied if 22671operand 2 does _not_ satisfy the 'K' constraint. (This is a simplified 22672version of a peephole definition from the i386 machine description.) 22673 22674 (define_peephole2 22675 [(match_scratch:SI 3 "r") 22676 (set (match_operand:SI 0 "register_operand" "") 22677 (mult:SI (match_operand:SI 1 "memory_operand" "") 22678 (match_operand:SI 2 "immediate_operand" "")))] 22679 22680 "!satisfies_constraint_K (operands[2])" 22681 22682 [(set (match_dup 3) (match_dup 1)) 22683 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 22684 22685 "") 22686 22687 22688File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 22689 2269016.9 Standard Pattern Names For Generation 22691========================================== 22692 22693Here is a table of the instruction names that are meaningful in the RTL 22694generation pass of the compiler. Giving one of these names to an 22695instruction pattern tells the RTL generation pass that it can use the 22696pattern to accomplish a certain task. 22697 22698'movM' 22699 Here M stands for a two-letter machine mode name, in lowercase. 22700 This instruction pattern moves data with that machine mode from 22701 operand 1 to operand 0. For example, 'movsi' moves full-word data. 22702 22703 If operand 0 is a 'subreg' with mode M of a register whose own mode 22704 is wider than M, the effect of this instruction is to store the 22705 specified value in the part of the register that corresponds to 22706 mode M. Bits outside of M, but which are within the same target 22707 word as the 'subreg' are undefined. Bits which are outside the 22708 target word are left unchanged. 22709 22710 This class of patterns is special in several ways. First of all, 22711 each of these names up to and including full word size _must_ be 22712 defined, because there is no other way to copy a datum from one 22713 place to another. If there are patterns accepting operands in 22714 larger modes, 'movM' must be defined for integer modes of those 22715 sizes. 22716 22717 Second, these patterns are not used solely in the RTL generation 22718 pass. Even the reload pass can generate move insns to copy values 22719 from stack slots into temporary registers. When it does so, one of 22720 the operands is a hard register and the other is an operand that 22721 can need to be reloaded into a register. 22722 22723 Therefore, when given such a pair of operands, the pattern must 22724 generate RTL which needs no reloading and needs no temporary 22725 registers--no registers other than the operands. For example, if 22726 you support the pattern with a 'define_expand', then in such a case 22727 the 'define_expand' mustn't call 'force_reg' or any other such 22728 function which might generate new pseudo registers. 22729 22730 This requirement exists even for subword modes on a RISC machine 22731 where fetching those modes from memory normally requires several 22732 insns and some temporary registers. 22733 22734 During reload a memory reference with an invalid address may be 22735 passed as an operand. Such an address will be replaced with a 22736 valid address later in the reload pass. In this case, nothing may 22737 be done with the address except to use it as it stands. If it is 22738 copied, it will not be replaced with a valid address. No attempt 22739 should be made to make such an address into a valid address and no 22740 routine (such as 'change_address') that will do so may be called. 22741 Note that 'general_operand' will fail when applied to such an 22742 address. 22743 22744 The global variable 'reload_in_progress' (which must be explicitly 22745 declared if required) can be used to determine whether such special 22746 handling is required. 22747 22748 The variety of operands that have reloads depends on the rest of 22749 the machine description, but typically on a RISC machine these can 22750 only be pseudo registers that did not get hard registers, while on 22751 other machines explicit memory references will get optional 22752 reloads. 22753 22754 If a scratch register is required to move an object to or from 22755 memory, it can be allocated using 'gen_reg_rtx' prior to life 22756 analysis. 22757 22758 If there are cases which need scratch registers during or after 22759 reload, you must provide an appropriate secondary_reload target 22760 hook. 22761 22762 The macro 'can_create_pseudo_p' can be used to determine if it is 22763 unsafe to create new pseudo registers. If this variable is 22764 nonzero, then it is unsafe to call 'gen_reg_rtx' to allocate a new 22765 pseudo. 22766 22767 The constraints on a 'movM' must permit moving any hard register to 22768 any other hard register provided that 'HARD_REGNO_MODE_OK' permits 22769 mode M in both registers and 'TARGET_REGISTER_MOVE_COST' applied to 22770 their classes returns a value of 2. 22771 22772 It is obligatory to support floating point 'movM' instructions into 22773 and out of any registers that can hold fixed point values, because 22774 unions and structures (which have modes 'SImode' or 'DImode') can 22775 be in those registers and they may have floating point members. 22776 22777 There may also be a need to support fixed point 'movM' instructions 22778 in and out of floating point registers. Unfortunately, I have 22779 forgotten why this was so, and I don't know whether it is still 22780 true. If 'HARD_REGNO_MODE_OK' rejects fixed point values in 22781 floating point registers, then the constraints of the fixed point 22782 'movM' instructions must be designed to avoid ever trying to reload 22783 into a floating point register. 22784 22785'reload_inM' 22786'reload_outM' 22787 These named patterns have been obsoleted by the target hook 22788 'secondary_reload'. 22789 22790 Like 'movM', but used when a scratch register is required to move 22791 between operand 0 and operand 1. Operand 2 describes the scratch 22792 register. See the discussion of the 'SECONDARY_RELOAD_CLASS' macro 22793 in *note Register Classes::. 22794 22795 There are special restrictions on the form of the 'match_operand's 22796 used in these patterns. First, only the predicate for the reload 22797 operand is examined, i.e., 'reload_in' examines operand 1, but not 22798 the predicates for operand 0 or 2. Second, there may be only one 22799 alternative in the constraints. Third, only a single register 22800 class letter may be used for the constraint; subsequent constraint 22801 letters are ignored. As a special exception, an empty constraint 22802 string matches the 'ALL_REGS' register class. This may relieve 22803 ports of the burden of defining an 'ALL_REGS' constraint letter 22804 just for these patterns. 22805 22806'movstrictM' 22807 Like 'movM' except that if operand 0 is a 'subreg' with mode M of a 22808 register whose natural mode is wider, the 'movstrictM' instruction 22809 is guaranteed not to alter any of the register except the part 22810 which belongs to mode M. 22811 22812'movmisalignM' 22813 This variant of a move pattern is designed to load or store a value 22814 from a memory address that is not naturally aligned for its mode. 22815 For a store, the memory will be in operand 0; for a load, the 22816 memory will be in operand 1. The other operand is guaranteed not 22817 to be a memory, so that it's easy to tell whether this is a load or 22818 store. 22819 22820 This pattern is used by the autovectorizer, and when expanding a 22821 'MISALIGNED_INDIRECT_REF' expression. 22822 22823'load_multiple' 22824 Load several consecutive memory locations into consecutive 22825 registers. Operand 0 is the first of the consecutive registers, 22826 operand 1 is the first memory location, and operand 2 is a 22827 constant: the number of consecutive registers. 22828 22829 Define this only if the target machine really has such an 22830 instruction; do not define this if the most efficient way of 22831 loading consecutive registers from memory is to do them one at a 22832 time. 22833 22834 On some machines, there are restrictions as to which consecutive 22835 registers can be stored into memory, such as particular starting or 22836 ending register numbers or only a range of valid counts. For those 22837 machines, use a 'define_expand' (*note Expander Definitions::) and 22838 make the pattern fail if the restrictions are not met. 22839 22840 Write the generated insn as a 'parallel' with elements being a 22841 'set' of one register from the appropriate memory location (you may 22842 also need 'use' or 'clobber' elements). Use a 'match_parallel' 22843 (*note RTL Template::) to recognize the insn. See 'rs6000.md' for 22844 examples of the use of this insn pattern. 22845 22846'store_multiple' 22847 Similar to 'load_multiple', but store several consecutive registers 22848 into consecutive memory locations. Operand 0 is the first of the 22849 consecutive memory locations, operand 1 is the first register, and 22850 operand 2 is a constant: the number of consecutive registers. 22851 22852'vec_load_lanesMN' 22853 Perform an interleaved load of several vectors from memory operand 22854 1 into register operand 0. Both operands have mode M. The 22855 register operand is viewed as holding consecutive vectors of mode 22856 N, while the memory operand is a flat array that contains the same 22857 number of elements. The operation is equivalent to: 22858 22859 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 22860 for (j = 0; j < GET_MODE_NUNITS (N); j++) 22861 for (i = 0; i < c; i++) 22862 operand0[i][j] = operand1[j * c + i]; 22863 22864 For example, 'vec_load_lanestiv4hi' loads 8 16-bit values from 22865 memory into a register of mode 'TI'. The register contains two 22866 consecutive vectors of mode 'V4HI'. 22867 22868 This pattern can only be used if: 22869 TARGET_ARRAY_MODE_SUPPORTED_P (N, C) 22870 is true. GCC assumes that, if a target supports this kind of 22871 instruction for some mode N, it also supports unaligned loads for 22872 vectors of mode N. 22873 22874 This pattern is not allowed to 'FAIL'. 22875 22876'vec_store_lanesMN' 22877 Equivalent to 'vec_load_lanesMN', with the memory and register 22878 operands reversed. That is, the instruction is equivalent to: 22879 22880 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 22881 for (j = 0; j < GET_MODE_NUNITS (N); j++) 22882 for (i = 0; i < c; i++) 22883 operand0[j * c + i] = operand1[i][j]; 22884 22885 for a memory operand 0 and register operand 1. 22886 22887 This pattern is not allowed to 'FAIL'. 22888 22889'vec_setM' 22890 Set given field in the vector value. Operand 0 is the vector to 22891 modify, operand 1 is new value of field and operand 2 specify the 22892 field index. 22893 22894'vec_extractM' 22895 Extract given field from the vector value. Operand 1 is the 22896 vector, operand 2 specify field index and operand 0 place to store 22897 value into. 22898 22899'vec_initM' 22900 Initialize the vector to given values. Operand 0 is the vector to 22901 initialize and operand 1 is parallel containing values for 22902 individual fields. 22903 22904'vec_cmpMN' 22905 Output a vector comparison. Operand 0 of mode N is the destination 22906 for predicate in operand 1 which is a signed vector comparison with 22907 operands of mode M in operands 2 and 3. Predicate is computed by 22908 element-wise evaluation of the vector comparison with a truth value 22909 of all-ones and a false value of all-zeros. 22910 22911'vec_cmpuMN' 22912 Similar to 'vec_cmpMN' but perform unsigned vector comparison. 22913 22914'vcondMN' 22915 Output a conditional vector move. Operand 0 is the destination to 22916 receive a combination of operand 1 and operand 2, which are of mode 22917 M, dependent on the outcome of the predicate in operand 3 which is 22918 a signed vector comparison with operands of mode N in operands 4 22919 and 5. The modes M and N should have the same size. Operand 0 22920 will be set to the value OP1 & MSK | OP2 & ~MSK where MSK is 22921 computed by element-wise evaluation of the vector comparison with a 22922 truth value of all-ones and a false value of all-zeros. 22923 22924'vconduMN' 22925 Similar to 'vcondMN' but performs unsigned vector comparison. 22926 22927'vcond_mask_MN' 22928 Similar to 'vcondMN' but operand 3 holds a pre-computed result of 22929 vector comparison. 22930 22931'maskloadMN' 22932 Perform a masked load of vector from memory operand 1 of mode M 22933 into register operand 0. Mask is provided in register operand 2 of 22934 mode N. 22935 22936 This pattern is not allowed to 'FAIL'. 22937 22938'maskstoreMN' 22939 Perform a masked store of vector from register operand 1 of mode M 22940 into memory operand 0. Mask is provided in register operand 2 of 22941 mode N. 22942 22943 This pattern is not allowed to 'FAIL'. 22944 22945'vec_permM' 22946 Output a (variable) vector permutation. Operand 0 is the 22947 destination to receive elements from operand 1 and operand 2, which 22948 are of mode M. Operand 3 is the "selector". It is an integral 22949 mode vector of the same width and number of elements as mode M. 22950 22951 The input elements are numbered from 0 in operand 1 through 2*N-1 22952 in operand 2. The elements of the selector must be computed modulo 22953 2*N. Note that if 'rtx_equal_p(operand1, operand2)', this can be 22954 implemented with just operand 1 and selector elements modulo N. 22955 22956 In order to make things easy for a number of targets, if there is 22957 no 'vec_perm' pattern for mode M, but there is for mode Q where Q 22958 is a vector of 'QImode' of the same width as M, the middle-end will 22959 lower the mode M 'VEC_PERM_EXPR' to mode Q. 22960 22961'vec_perm_constM' 22962 Like 'vec_perm' except that the permutation is a compile-time 22963 constant. That is, operand 3, the "selector", is a 'CONST_VECTOR'. 22964 22965 Some targets cannot perform a permutation with a variable selector, 22966 but can efficiently perform a constant permutation. Further, the 22967 target hook 'vec_perm_ok' is queried to determine if the specific 22968 constant permutation is available efficiently; the named pattern is 22969 never expanded without 'vec_perm_ok' returning true. 22970 22971 There is no need for a target to supply both 'vec_permM' and 22972 'vec_perm_constM' if the former can trivially implement the 22973 operation with, say, the vector constant loaded into a register. 22974 22975'pushM1' 22976 Output a push instruction. Operand 0 is value to push. Used only 22977 when 'PUSH_ROUNDING' is defined. For historical reason, this 22978 pattern may be missing and in such case an 'mov' expander is used 22979 instead, with a 'MEM' expression forming the push operation. The 22980 'mov' expander method is deprecated. 22981 22982'addM3' 22983 Add operand 2 and operand 1, storing the result in operand 0. All 22984 operands must have mode M. This can be used even on two-address 22985 machines, by means of constraints requiring operands 1 and 0 to be 22986 the same location. 22987 22988'ssaddM3', 'usaddM3' 22989'subM3', 'sssubM3', 'ussubM3' 22990'mulM3', 'ssmulM3', 'usmulM3' 22991'divM3', 'ssdivM3' 22992'udivM3', 'usdivM3' 22993'modM3', 'umodM3' 22994'uminM3', 'umaxM3' 22995'andM3', 'iorM3', 'xorM3' 22996 Similar, for other arithmetic operations. 22997 22998'addvM4' 22999 Like 'addM3' but takes a 'code_label' as operand 3 and emits code 23000 to jump to it if signed overflow occurs during the addition. This 23001 pattern is used to implement the built-in functions performing 23002 signed integer addition with overflow checking. 23003 23004'subvM4', 'mulvM4' 23005 Similar, for other signed arithmetic operations. 23006 23007'uaddvM4' 23008 Like 'addvM4' but for unsigned addition. That is to say, the 23009 operation is the same as signed addition but the jump is taken only 23010 on unsigned overflow. 23011 23012'usubvM4', 'umulvM4' 23013 Similar, for other unsigned arithmetic operations. 23014 23015'addptrM3' 23016 Like 'addM3' but is guaranteed to only be used for address 23017 calculations. The expanded code is not allowed to clobber the 23018 condition code. It only needs to be defined if 'addM3' sets the 23019 condition code. If adds used for address calculations and normal 23020 adds are not compatible it is required to expand a distinct pattern 23021 (e.g. using an unspec). The pattern is used by LRA to emit 23022 address calculations. 'addM3' is used if 'addptrM3' is not 23023 defined. 23024 23025'fmaM4' 23026 Multiply operand 2 and operand 1, then add operand 3, storing the 23027 result in operand 0 without doing an intermediate rounding step. 23028 All operands must have mode M. This pattern is used to implement 23029 the 'fma', 'fmaf', and 'fmal' builtin functions from the ISO C99 23030 standard. 23031 23032'fmsM4' 23033 Like 'fmaM4', except operand 3 subtracted from the product instead 23034 of added to the product. This is represented in the rtl as 23035 23036 (fma:M OP1 OP2 (neg:M OP3)) 23037 23038'fnmaM4' 23039 Like 'fmaM4' except that the intermediate product is negated before 23040 being added to operand 3. This is represented in the rtl as 23041 23042 (fma:M (neg:M OP1) OP2 OP3) 23043 23044'fnmsM4' 23045 Like 'fmsM4' except that the intermediate product is negated before 23046 subtracting operand 3. This is represented in the rtl as 23047 23048 (fma:M (neg:M OP1) OP2 (neg:M OP3)) 23049 23050'sminM3', 'smaxM3' 23051 Signed minimum and maximum operations. When used with floating 23052 point, if both operands are zeros, or if either operand is 'NaN', 23053 then it is unspecified which of the two operands is returned as the 23054 result. 23055 23056'fminM3', 'fmaxM3' 23057 IEEE-conformant minimum and maximum operations. If one operand is 23058 a quiet 'NaN', then the other operand is returned. If both 23059 operands are quiet 'NaN', then a quiet 'NaN' is returned. In the 23060 case when gcc supports signalling 'NaN' (-fsignaling-nans) an 23061 invalid floating point exception is raised and a quiet 'NaN' is 23062 returned. 23063 23064 All operands have mode M, which is a scalar or vector 23065 floating-point mode. These patterns are not allowed to 'FAIL'. 23066 23067'reduc_smin_scal_M', 'reduc_smax_scal_M' 23068 Find the signed minimum/maximum of the elements of a vector. The 23069 vector is operand 1, and operand 0 is the scalar result, with mode 23070 equal to the mode of the elements of the input vector. 23071 23072'reduc_umin_scal_M', 'reduc_umax_scal_M' 23073 Find the unsigned minimum/maximum of the elements of a vector. The 23074 vector is operand 1, and operand 0 is the scalar result, with mode 23075 equal to the mode of the elements of the input vector. 23076 23077'reduc_plus_scal_M' 23078 Compute the sum of the elements of a vector. The vector is operand 23079 1, and operand 0 is the scalar result, with mode equal to the mode 23080 of the elements of the input vector. 23081 23082'sdot_prodM' 23083'udot_prodM' 23084 Compute the sum of the products of two signed/unsigned elements. 23085 Operand 1 and operand 2 are of the same mode. Their product, which 23086 is of a wider mode, is computed and added to operand 3. Operand 3 23087 is of a mode equal or wider than the mode of the product. The 23088 result is placed in operand 0, which is of the same mode as operand 23089 3. 23090 23091'ssadM' 23092'usadM' 23093 Compute the sum of absolute differences of two signed/unsigned 23094 elements. Operand 1 and operand 2 are of the same mode. Their 23095 absolute difference, which is of a wider mode, is computed and 23096 added to operand 3. Operand 3 is of a mode equal or wider than the 23097 mode of the absolute difference. The result is placed in operand 23098 0, which is of the same mode as operand 3. 23099 23100'widen_ssumM3' 23101'widen_usumM3' 23102 Operands 0 and 2 are of the same mode, which is wider than the mode 23103 of operand 1. Add operand 1 to operand 2 and place the widened 23104 result in operand 0. (This is used express accumulation of 23105 elements into an accumulator of a wider mode.) 23106 23107'vec_shr_M' 23108 Whole vector right shift in bits, i.e. towards element 0. Operand 23109 1 is a vector to be shifted. Operand 2 is an integer shift amount 23110 in bits. Operand 0 is where the resulting shifted vector is 23111 stored. The output and input vectors should have the same modes. 23112 23113'vec_pack_trunc_M' 23114 Narrow (demote) and merge the elements of two vectors. Operands 1 23115 and 2 are vectors of the same mode having N integral or floating 23116 point elements of size S. Operand 0 is the resulting vector in 23117 which 2*N elements of size N/2 are concatenated after narrowing 23118 them down using truncation. 23119 23120'vec_pack_ssat_M', 'vec_pack_usat_M' 23121 Narrow (demote) and merge the elements of two vectors. Operands 1 23122 and 2 are vectors of the same mode having N integral elements of 23123 size S. Operand 0 is the resulting vector in which the elements of 23124 the two input vectors are concatenated after narrowing them down 23125 using signed/unsigned saturating arithmetic. 23126 23127'vec_pack_sfix_trunc_M', 'vec_pack_ufix_trunc_M' 23128 Narrow, convert to signed/unsigned integral type and merge the 23129 elements of two vectors. Operands 1 and 2 are vectors of the same 23130 mode having N floating point elements of size S. Operand 0 is the 23131 resulting vector in which 2*N elements of size N/2 are 23132 concatenated. 23133 23134'vec_unpacks_hi_M', 'vec_unpacks_lo_M' 23135 Extract and widen (promote) the high/low part of a vector of signed 23136 integral or floating point elements. The input vector (operand 1) 23137 has N elements of size S. Widen (promote) the high/low elements of 23138 the vector using signed or floating point extension and place the 23139 resulting N/2 values of size 2*S in the output vector (operand 0). 23140 23141'vec_unpacku_hi_M', 'vec_unpacku_lo_M' 23142 Extract and widen (promote) the high/low part of a vector of 23143 unsigned integral elements. The input vector (operand 1) has N 23144 elements of size S. Widen (promote) the high/low elements of the 23145 vector using zero extension and place the resulting N/2 values of 23146 size 2*S in the output vector (operand 0). 23147 23148'vec_unpacks_float_hi_M', 'vec_unpacks_float_lo_M' 23149'vec_unpacku_float_hi_M', 'vec_unpacku_float_lo_M' 23150 Extract, convert to floating point type and widen the high/low part 23151 of a vector of signed/unsigned integral elements. The input vector 23152 (operand 1) has N elements of size S. Convert the high/low 23153 elements of the vector using floating point conversion and place 23154 the resulting N/2 values of size 2*S in the output vector (operand 23155 0). 23156 23157'vec_widen_umult_hi_M', 'vec_widen_umult_lo_M' 23158'vec_widen_smult_hi_M', 'vec_widen_smult_lo_M' 23159'vec_widen_umult_even_M', 'vec_widen_umult_odd_M' 23160'vec_widen_smult_even_M', 'vec_widen_smult_odd_M' 23161 Signed/Unsigned widening multiplication. The two inputs (operands 23162 1 and 2) are vectors with N signed/unsigned elements of size S. 23163 Multiply the high/low or even/odd elements of the two vectors, and 23164 put the N/2 products of size 2*S in the output vector (operand 0). 23165 A target shouldn't implement even/odd pattern pair if it is less 23166 efficient than lo/hi one. 23167 23168'vec_widen_ushiftl_hi_M', 'vec_widen_ushiftl_lo_M' 23169'vec_widen_sshiftl_hi_M', 'vec_widen_sshiftl_lo_M' 23170 Signed/Unsigned widening shift left. The first input (operand 1) 23171 is a vector with N signed/unsigned elements of size S. Operand 2 23172 is a constant. Shift the high/low elements of operand 1, and put 23173 the N/2 results of size 2*S in the output vector (operand 0). 23174 23175'mulhisi3' 23176 Multiply operands 1 and 2, which have mode 'HImode', and store a 23177 'SImode' product in operand 0. 23178 23179'mulqihi3', 'mulsidi3' 23180 Similar widening-multiplication instructions of other widths. 23181 23182'umulqihi3', 'umulhisi3', 'umulsidi3' 23183 Similar widening-multiplication instructions that do unsigned 23184 multiplication. 23185 23186'usmulqihi3', 'usmulhisi3', 'usmulsidi3' 23187 Similar widening-multiplication instructions that interpret the 23188 first operand as unsigned and the second operand as signed, then do 23189 a signed multiplication. 23190 23191'smulM3_highpart' 23192 Perform a signed multiplication of operands 1 and 2, which have 23193 mode M, and store the most significant half of the product in 23194 operand 0. The least significant half of the product is discarded. 23195 23196'umulM3_highpart' 23197 Similar, but the multiplication is unsigned. 23198 23199'maddMN4' 23200 Multiply operands 1 and 2, sign-extend them to mode N, add operand 23201 3, and store the result in operand 0. Operands 1 and 2 have mode M 23202 and operands 0 and 3 have mode N. Both modes must be integer or 23203 fixed-point modes and N must be twice the size of M. 23204 23205 In other words, 'maddMN4' is like 'mulMN3' except that it also adds 23206 operand 3. 23207 23208 These instructions are not allowed to 'FAIL'. 23209 23210'umaddMN4' 23211 Like 'maddMN4', but zero-extend the multiplication operands instead 23212 of sign-extending them. 23213 23214'ssmaddMN4' 23215 Like 'maddMN4', but all involved operations must be 23216 signed-saturating. 23217 23218'usmaddMN4' 23219 Like 'umaddMN4', but all involved operations must be 23220 unsigned-saturating. 23221 23222'msubMN4' 23223 Multiply operands 1 and 2, sign-extend them to mode N, subtract the 23224 result from operand 3, and store the result in operand 0. Operands 23225 1 and 2 have mode M and operands 0 and 3 have mode N. Both modes 23226 must be integer or fixed-point modes and N must be twice the size 23227 of M. 23228 23229 In other words, 'msubMN4' is like 'mulMN3' except that it also 23230 subtracts the result from operand 3. 23231 23232 These instructions are not allowed to 'FAIL'. 23233 23234'umsubMN4' 23235 Like 'msubMN4', but zero-extend the multiplication operands instead 23236 of sign-extending them. 23237 23238'ssmsubMN4' 23239 Like 'msubMN4', but all involved operations must be 23240 signed-saturating. 23241 23242'usmsubMN4' 23243 Like 'umsubMN4', but all involved operations must be 23244 unsigned-saturating. 23245 23246'divmodM4' 23247 Signed division that produces both a quotient and a remainder. 23248 Operand 1 is divided by operand 2 to produce a quotient stored in 23249 operand 0 and a remainder stored in operand 3. 23250 23251 For machines with an instruction that produces both a quotient and 23252 a remainder, provide a pattern for 'divmodM4' but do not provide 23253 patterns for 'divM3' and 'modM3'. This allows optimization in the 23254 relatively common case when both the quotient and remainder are 23255 computed. 23256 23257 If an instruction that just produces a quotient or just a remainder 23258 exists and is more efficient than the instruction that produces 23259 both, write the output routine of 'divmodM4' to call 23260 'find_reg_note' and look for a 'REG_UNUSED' note on the quotient or 23261 remainder and generate the appropriate instruction. 23262 23263'udivmodM4' 23264 Similar, but does unsigned division. 23265 23266'ashlM3', 'ssashlM3', 'usashlM3' 23267 Arithmetic-shift operand 1 left by a number of bits specified by 23268 operand 2, and store the result in operand 0. Here M is the mode 23269 of operand 0 and operand 1; operand 2's mode is specified by the 23270 instruction pattern, and the compiler will convert the operand to 23271 that mode before generating the instruction. The shift or rotate 23272 expander or instruction pattern should explicitly specify the mode 23273 of the operand 2, it should never be 'VOIDmode'. The meaning of 23274 out-of-range shift counts can optionally be specified by 23275 'TARGET_SHIFT_TRUNCATION_MASK'. *Note 23276 TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type. 23277 23278'ashrM3', 'lshrM3', 'rotlM3', 'rotrM3' 23279 Other shift and rotate instructions, analogous to the 'ashlM3' 23280 instructions. Operand 2 is always a scalar type. 23281 23282'vashlM3', 'vashrM3', 'vlshrM3', 'vrotlM3', 'vrotrM3' 23283 Vector shift and rotate instructions that take vectors as operand 2 23284 instead of a scalar type. 23285 23286'bswapM2' 23287 Reverse the order of bytes of operand 1 and store the result in 23288 operand 0. 23289 23290'negM2', 'ssnegM2', 'usnegM2' 23291 Negate operand 1 and store the result in operand 0. 23292 23293'negvM3' 23294 Like 'negM2' but takes a 'code_label' as operand 2 and emits code 23295 to jump to it if signed overflow occurs during the negation. 23296 23297'absM2' 23298 Store the absolute value of operand 1 into operand 0. 23299 23300'sqrtM2' 23301 Store the square root of operand 1 into operand 0. Both operands 23302 have mode M, which is a scalar or vector floating-point mode. 23303 23304 This pattern is not allowed to 'FAIL'. 23305 23306'rsqrtM2' 23307 Store the reciprocal of the square root of operand 1 into operand 23308 0. Both operands have mode M, which is a scalar or vector 23309 floating-point mode. 23310 23311 On most architectures this pattern is only approximate, so either 23312 its C condition or the 'TARGET_OPTAB_SUPPORTED_P' hook should check 23313 for the appropriate math flags. (Using the C condition is more 23314 direct, but using 'TARGET_OPTAB_SUPPORTED_P' can be useful if a 23315 target-specific built-in also uses the 'rsqrtM2' pattern.) 23316 23317 This pattern is not allowed to 'FAIL'. 23318 23319'fmodM3' 23320 Store the remainder of dividing operand 1 by operand 2 into operand 23321 0, rounded towards zero to an integer. All operands have mode M, 23322 which is a scalar or vector floating-point mode. 23323 23324 This pattern is not allowed to 'FAIL'. 23325 23326'remainderM3' 23327 Store the remainder of dividing operand 1 by operand 2 into operand 23328 0, rounded to the nearest integer. All operands have mode M, which 23329 is a scalar or vector floating-point mode. 23330 23331 This pattern is not allowed to 'FAIL'. 23332 23333'scalbM3' 23334 Raise 'FLT_RADIX' to the power of operand 2, multiply it by operand 23335 1, and store the result in operand 0. All operands have mode M, 23336 which is a scalar or vector floating-point mode. 23337 23338 This pattern is not allowed to 'FAIL'. 23339 23340'ldexpM3' 23341 Raise 2 to the power of operand 2, multiply it by operand 1, and 23342 store the result in operand 0. Operands 0 and 1 have mode M, which 23343 is a scalar or vector floating-point mode. Operand 2's mode has 23344 the same number of elements as M and each element is wide enough to 23345 store an 'int'. The integers are signed. 23346 23347 This pattern is not allowed to 'FAIL'. 23348 23349'cosM2' 23350 Store the cosine of operand 1 into operand 0. Both operands have 23351 mode M, which is a scalar or vector floating-point mode. 23352 23353 This pattern is not allowed to 'FAIL'. 23354 23355'sinM2' 23356 Store the sine of operand 1 into operand 0. Both operands have 23357 mode M, which is a scalar or vector floating-point mode. 23358 23359 This pattern is not allowed to 'FAIL'. 23360 23361'sincosM3' 23362 Store the cosine of operand 2 into operand 0 and the sine of 23363 operand 2 into operand 1. All operands have mode M, which is a 23364 scalar or vector floating-point mode. 23365 23366 Targets that can calculate the sine and cosine simultaneously can 23367 implement this pattern as opposed to implementing individual 23368 'sinM2' and 'cosM2' patterns. The 'sin' and 'cos' built-in 23369 functions will then be expanded to the 'sincosM3' pattern, with one 23370 of the output values left unused. 23371 23372'tanM2' 23373 Store the tangent of operand 1 into operand 0. Both operands have 23374 mode M, which is a scalar or vector floating-point mode. 23375 23376 This pattern is not allowed to 'FAIL'. 23377 23378'asinM2' 23379 Store the arc sine of operand 1 into operand 0. Both operands have 23380 mode M, which is a scalar or vector floating-point mode. 23381 23382 This pattern is not allowed to 'FAIL'. 23383 23384'acosM2' 23385 Store the arc cosine of operand 1 into operand 0. Both operands 23386 have mode M, which is a scalar or vector floating-point mode. 23387 23388 This pattern is not allowed to 'FAIL'. 23389 23390'atanM2' 23391 Store the arc tangent of operand 1 into operand 0. Both operands 23392 have mode M, which is a scalar or vector floating-point mode. 23393 23394 This pattern is not allowed to 'FAIL'. 23395 23396'expM2' 23397 Raise e (the base of natural logarithms) to the power of operand 1 23398 and store the result in operand 0. Both operands have mode M, 23399 which is a scalar or vector floating-point mode. 23400 23401 This pattern is not allowed to 'FAIL'. 23402 23403'expm1M2' 23404 Raise e (the base of natural logarithms) to the power of operand 1, 23405 subtract 1, and store the result in operand 0. Both operands have 23406 mode M, which is a scalar or vector floating-point mode. 23407 23408 For inputs close to zero, the pattern is expected to be more 23409 accurate than a separate 'expM2' and 'subM3' would be. 23410 23411 This pattern is not allowed to 'FAIL'. 23412 23413'exp10M2' 23414 Raise 10 to the power of operand 1 and store the result in operand 23415 0. Both operands have mode M, which is a scalar or vector 23416 floating-point mode. 23417 23418 This pattern is not allowed to 'FAIL'. 23419 23420'exp2M2' 23421 Raise 2 to the power of operand 1 and store the result in operand 23422 0. Both operands have mode M, which is a scalar or vector 23423 floating-point mode. 23424 23425 This pattern is not allowed to 'FAIL'. 23426 23427'logM2' 23428 Store the natural logarithm of operand 1 into operand 0. Both 23429 operands have mode M, which is a scalar or vector floating-point 23430 mode. 23431 23432 This pattern is not allowed to 'FAIL'. 23433 23434'log1pM2' 23435 Add 1 to operand 1, compute the natural logarithm, and store the 23436 result in operand 0. Both operands have mode M, which is a scalar 23437 or vector floating-point mode. 23438 23439 For inputs close to zero, the pattern is expected to be more 23440 accurate than a separate 'addM3' and 'logM2' would be. 23441 23442 This pattern is not allowed to 'FAIL'. 23443 23444'log10M2' 23445 Store the base-10 logarithm of operand 1 into operand 0. Both 23446 operands have mode M, which is a scalar or vector floating-point 23447 mode. 23448 23449 This pattern is not allowed to 'FAIL'. 23450 23451'log2M2' 23452 Store the base-2 logarithm of operand 1 into operand 0. Both 23453 operands have mode M, which is a scalar or vector floating-point 23454 mode. 23455 23456 This pattern is not allowed to 'FAIL'. 23457 23458'logbM2' 23459 Store the base-'FLT_RADIX' logarithm of operand 1 into operand 0. 23460 Both operands have mode M, which is a scalar or vector 23461 floating-point mode. 23462 23463 This pattern is not allowed to 'FAIL'. 23464 23465'significandM2' 23466 Store the significand of floating-point operand 1 in operand 0. 23467 Both operands have mode M, which is a scalar or vector 23468 floating-point mode. 23469 23470 This pattern is not allowed to 'FAIL'. 23471 23472'powM3' 23473 Store the value of operand 1 raised to the exponent operand 2 into 23474 operand 0. All operands have mode M, which is a scalar or vector 23475 floating-point mode. 23476 23477 This pattern is not allowed to 'FAIL'. 23478 23479'atan2M3' 23480 Store the arc tangent (inverse tangent) of operand 1 divided by 23481 operand 2 into operand 0, using the signs of both arguments to 23482 determine the quadrant of the result. All operands have mode M, 23483 which is a scalar or vector floating-point mode. 23484 23485 This pattern is not allowed to 'FAIL'. 23486 23487'floorM2' 23488 Store the largest integral value not greater than operand 1 in 23489 operand 0. Both operands have mode M, which is a scalar or vector 23490 floating-point mode. 23491 23492 This pattern is not allowed to 'FAIL'. 23493 23494'btruncM2' 23495 Round operand 1 to an integer, towards zero, and store the result 23496 in operand 0. Both operands have mode M, which is a scalar or 23497 vector floating-point mode. 23498 23499 This pattern is not allowed to 'FAIL'. 23500 23501'roundM2' 23502 Round operand 1 to the nearest integer, rounding away from zero in 23503 the event of a tie, and store the result in operand 0. Both 23504 operands have mode M, which is a scalar or vector floating-point 23505 mode. 23506 23507 This pattern is not allowed to 'FAIL'. 23508 23509'ceilM2' 23510 Store the smallest integral value not less than operand 1 in 23511 operand 0. Both operands have mode M, which is a scalar or vector 23512 floating-point mode. 23513 23514 This pattern is not allowed to 'FAIL'. 23515 23516'nearbyintM2' 23517 Round operand 1 to an integer, using the current rounding mode, and 23518 store the result in operand 0. Do not raise an inexact condition 23519 when the result is different from the argument. Both operands have 23520 mode M, which is a scalar or vector floating-point mode. 23521 23522 This pattern is not allowed to 'FAIL'. 23523 23524'rintM2' 23525 Round operand 1 to an integer, using the current rounding mode, and 23526 store the result in operand 0. Raise an inexact condition when the 23527 result is different from the argument. Both operands have mode M, 23528 which is a scalar or vector floating-point mode. 23529 23530 This pattern is not allowed to 'FAIL'. 23531 23532'lrintMN2' 23533 Convert operand 1 (valid for floating point mode M) to fixed point 23534 mode N as a signed number according to the current rounding mode 23535 and store in operand 0 (which has mode N). 23536 23537'lroundMN2' 23538 Convert operand 1 (valid for floating point mode M) to fixed point 23539 mode N as a signed number rounding to nearest and away from zero 23540 and store in operand 0 (which has mode N). 23541 23542'lfloorMN2' 23543 Convert operand 1 (valid for floating point mode M) to fixed point 23544 mode N as a signed number rounding down and store in operand 0 23545 (which has mode N). 23546 23547'lceilMN2' 23548 Convert operand 1 (valid for floating point mode M) to fixed point 23549 mode N as a signed number rounding up and store in operand 0 (which 23550 has mode N). 23551 23552'copysignM3' 23553 Store a value with the magnitude of operand 1 and the sign of 23554 operand 2 into operand 0. All operands have mode M, which is a 23555 scalar or vector floating-point mode. 23556 23557 This pattern is not allowed to 'FAIL'. 23558 23559'ffsM2' 23560 Store into operand 0 one plus the index of the least significant 23561 1-bit of operand 1. If operand 1 is zero, store zero. 23562 23563 M is either a scalar or vector integer mode. When it is a scalar, 23564 operand 1 has mode M but operand 0 can have whatever scalar integer 23565 mode is suitable for the target. The compiler will insert 23566 conversion instructions as necessary (typically to convert the 23567 result to the same width as 'int'). When M is a vector, both 23568 operands must have mode M. 23569 23570 This pattern is not allowed to 'FAIL'. 23571 23572'clrsbM2' 23573 Count leading redundant sign bits. Store into operand 0 the number 23574 of redundant sign bits in operand 1, starting at the most 23575 significant bit position. A redundant sign bit is defined as any 23576 sign bit after the first. As such, this count will be one less 23577 than the count of leading sign bits. 23578 23579 M is either a scalar or vector integer mode. When it is a scalar, 23580 operand 1 has mode M but operand 0 can have whatever scalar integer 23581 mode is suitable for the target. The compiler will insert 23582 conversion instructions as necessary (typically to convert the 23583 result to the same width as 'int'). When M is a vector, both 23584 operands must have mode M. 23585 23586 This pattern is not allowed to 'FAIL'. 23587 23588'clzM2' 23589 Store into operand 0 the number of leading 0-bits in operand 1, 23590 starting at the most significant bit position. If operand 1 is 0, 23591 the 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 23592 result is undefined or has a useful value. 23593 23594 M is either a scalar or vector integer mode. When it is a scalar, 23595 operand 1 has mode M but operand 0 can have whatever scalar integer 23596 mode is suitable for the target. The compiler will insert 23597 conversion instructions as necessary (typically to convert the 23598 result to the same width as 'int'). When M is a vector, both 23599 operands must have mode M. 23600 23601 This pattern is not allowed to 'FAIL'. 23602 23603'ctzM2' 23604 Store into operand 0 the number of trailing 0-bits in operand 1, 23605 starting at the least significant bit position. If operand 1 is 0, 23606 the 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 23607 result is undefined or has a useful value. 23608 23609 M is either a scalar or vector integer mode. When it is a scalar, 23610 operand 1 has mode M but operand 0 can have whatever scalar integer 23611 mode is suitable for the target. The compiler will insert 23612 conversion instructions as necessary (typically to convert the 23613 result to the same width as 'int'). When M is a vector, both 23614 operands must have mode M. 23615 23616 This pattern is not allowed to 'FAIL'. 23617 23618'popcountM2' 23619 Store into operand 0 the number of 1-bits in operand 1. 23620 23621 M is either a scalar or vector integer mode. When it is a scalar, 23622 operand 1 has mode M but operand 0 can have whatever scalar integer 23623 mode is suitable for the target. The compiler will insert 23624 conversion instructions as necessary (typically to convert the 23625 result to the same width as 'int'). When M is a vector, both 23626 operands must have mode M. 23627 23628 This pattern is not allowed to 'FAIL'. 23629 23630'parityM2' 23631 Store into operand 0 the parity of operand 1, i.e. the number of 23632 1-bits in operand 1 modulo 2. 23633 23634 M is either a scalar or vector integer mode. When it is a scalar, 23635 operand 1 has mode M but operand 0 can have whatever scalar integer 23636 mode is suitable for the target. The compiler will insert 23637 conversion instructions as necessary (typically to convert the 23638 result to the same width as 'int'). When M is a vector, both 23639 operands must have mode M. 23640 23641 This pattern is not allowed to 'FAIL'. 23642 23643'one_cmplM2' 23644 Store the bitwise-complement of operand 1 into operand 0. 23645 23646'movmemM' 23647 Block move instruction. The destination and source blocks of 23648 memory are the first two operands, and both are 'mem:BLK's with an 23649 address in mode 'Pmode'. 23650 23651 The number of bytes to move is the third operand, in mode M. 23652 Usually, you specify 'Pmode' for M. However, if you can generate 23653 better code knowing the range of valid lengths is smaller than 23654 those representable in a full Pmode pointer, you should provide a 23655 pattern with a mode corresponding to the range of values you can 23656 handle efficiently (e.g., 'QImode' for values in the range 0-127; 23657 note we avoid numbers that appear negative) and also a pattern with 23658 'Pmode'. 23659 23660 The fourth operand is the known shared alignment of the source and 23661 destination, in the form of a 'const_int' rtx. Thus, if the 23662 compiler knows that both source and destination are word-aligned, 23663 it may provide the value 4 for this operand. 23664 23665 Optional operands 5 and 6 specify expected alignment and size of 23666 block respectively. The expected alignment differs from alignment 23667 in operand 4 in a way that the blocks are not required to be 23668 aligned according to it in all cases. This expected alignment is 23669 also in bytes, just like operand 4. Expected size, when unknown, 23670 is set to '(const_int -1)'. 23671 23672 Descriptions of multiple 'movmemM' patterns can only be beneficial 23673 if the patterns for smaller modes have fewer restrictions on their 23674 first, second and fourth operands. Note that the mode M in 23675 'movmemM' does not impose any restriction on the mode of 23676 individually moved data units in the block. 23677 23678 These patterns need not give special consideration to the 23679 possibility that the source and destination strings might overlap. 23680 23681'movstr' 23682 String copy instruction, with 'stpcpy' semantics. Operand 0 is an 23683 output operand in mode 'Pmode'. The addresses of the destination 23684 and source strings are operands 1 and 2, and both are 'mem:BLK's 23685 with addresses in mode 'Pmode'. The execution of the expansion of 23686 this pattern should store in operand 0 the address in which the 23687 'NUL' terminator was stored in the destination string. 23688 23689 This patern has also several optional operands that are same as in 23690 'setmem'. 23691 23692'setmemM' 23693 Block set instruction. The destination string is the first 23694 operand, given as a 'mem:BLK' whose address is in mode 'Pmode'. 23695 The number of bytes to set is the second operand, in mode M. The 23696 value to initialize the memory with is the third operand. Targets 23697 that only support the clearing of memory should reject any value 23698 that is not the constant 0. See 'movmemM' for a discussion of the 23699 choice of mode. 23700 23701 The fourth operand is the known alignment of the destination, in 23702 the form of a 'const_int' rtx. Thus, if the compiler knows that 23703 the destination is word-aligned, it may provide the value 4 for 23704 this operand. 23705 23706 Optional operands 5 and 6 specify expected alignment and size of 23707 block respectively. The expected alignment differs from alignment 23708 in operand 4 in a way that the blocks are not required to be 23709 aligned according to it in all cases. This expected alignment is 23710 also in bytes, just like operand 4. Expected size, when unknown, 23711 is set to '(const_int -1)'. Operand 7 is the minimal size of the 23712 block and operand 8 is the maximal size of the block (NULL if it 23713 can not be represented as CONST_INT). Operand 9 is the probable 23714 maximal size (i.e. we can not rely on it for correctness, but it 23715 can be used for choosing proper code sequence for a given size). 23716 23717 The use for multiple 'setmemM' is as for 'movmemM'. 23718 23719'cmpstrnM' 23720 String compare instruction, with five operands. Operand 0 is the 23721 output; it has mode M. The remaining four operands are like the 23722 operands of 'movmemM'. The two memory blocks specified are 23723 compared byte by byte in lexicographic order starting at the 23724 beginning of each string. The instruction is not allowed to 23725 prefetch more than one byte at a time since either string may end 23726 in the first byte and reading past that may access an invalid page 23727 or segment and cause a fault. The comparison terminates early if 23728 the fetched bytes are different or if they are equal to zero. The 23729 effect of the instruction is to store a value in operand 0 whose 23730 sign indicates the result of the comparison. 23731 23732'cmpstrM' 23733 String compare instruction, without known maximum length. Operand 23734 0 is the output; it has mode M. The second and third operand are 23735 the blocks of memory to be compared; both are 'mem:BLK' with an 23736 address in mode 'Pmode'. 23737 23738 The fourth operand is the known shared alignment of the source and 23739 destination, in the form of a 'const_int' rtx. Thus, if the 23740 compiler knows that both source and destination are word-aligned, 23741 it may provide the value 4 for this operand. 23742 23743 The two memory blocks specified are compared byte by byte in 23744 lexicographic order starting at the beginning of each string. The 23745 instruction is not allowed to prefetch more than one byte at a time 23746 since either string may end in the first byte and reading past that 23747 may access an invalid page or segment and cause a fault. The 23748 comparison will terminate when the fetched bytes are different or 23749 if they are equal to zero. The effect of the instruction is to 23750 store a value in operand 0 whose sign indicates the result of the 23751 comparison. 23752 23753'cmpmemM' 23754 Block compare instruction, with five operands like the operands of 23755 'cmpstrM'. The two memory blocks specified are compared byte by 23756 byte in lexicographic order starting at the beginning of each 23757 block. Unlike 'cmpstrM' the instruction can prefetch any bytes in 23758 the two memory blocks. Also unlike 'cmpstrM' the comparison will 23759 not stop if both bytes are zero. The effect of the instruction is 23760 to store a value in operand 0 whose sign indicates the result of 23761 the comparison. 23762 23763'strlenM' 23764 Compute the length of a string, with three operands. Operand 0 is 23765 the result (of mode M), operand 1 is a 'mem' referring to the first 23766 character of the string, operand 2 is the character to search for 23767 (normally zero), and operand 3 is a constant describing the known 23768 alignment of the beginning of the string. 23769 23770'floatMN2' 23771 Convert signed integer operand 1 (valid for fixed point mode M) to 23772 floating point mode N and store in operand 0 (which has mode N). 23773 23774'floatunsMN2' 23775 Convert unsigned integer operand 1 (valid for fixed point mode M) 23776 to floating point mode N and store in operand 0 (which has mode N). 23777 23778'fixMN2' 23779 Convert operand 1 (valid for floating point mode M) to fixed point 23780 mode N as a signed number and store in operand 0 (which has mode 23781 N). This instruction's result is defined only when the value of 23782 operand 1 is an integer. 23783 23784 If the machine description defines this pattern, it also needs to 23785 define the 'ftrunc' pattern. 23786 23787'fixunsMN2' 23788 Convert operand 1 (valid for floating point mode M) to fixed point 23789 mode N as an unsigned number and store in operand 0 (which has mode 23790 N). This instruction's result is defined only when the value of 23791 operand 1 is an integer. 23792 23793'ftruncM2' 23794 Convert operand 1 (valid for floating point mode M) to an integer 23795 value, still represented in floating point mode M, and store it in 23796 operand 0 (valid for floating point mode M). 23797 23798'fix_truncMN2' 23799 Like 'fixMN2' but works for any floating point value of mode M by 23800 converting the value to an integer. 23801 23802'fixuns_truncMN2' 23803 Like 'fixunsMN2' but works for any floating point value of mode M 23804 by converting the value to an integer. 23805 23806'truncMN2' 23807 Truncate operand 1 (valid for mode M) to mode N and store in 23808 operand 0 (which has mode N). Both modes must be fixed point or 23809 both floating point. 23810 23811'extendMN2' 23812 Sign-extend operand 1 (valid for mode M) to mode N and store in 23813 operand 0 (which has mode N). Both modes must be fixed point or 23814 both floating point. 23815 23816'zero_extendMN2' 23817 Zero-extend operand 1 (valid for mode M) to mode N and store in 23818 operand 0 (which has mode N). Both modes must be fixed point. 23819 23820'fractMN2' 23821 Convert operand 1 of mode M to mode N and store in operand 0 (which 23822 has mode N). Mode M and mode N could be fixed-point to 23823 fixed-point, signed integer to fixed-point, fixed-point to signed 23824 integer, floating-point to fixed-point, or fixed-point to 23825 floating-point. When overflows or underflows happen, the results 23826 are undefined. 23827 23828'satfractMN2' 23829 Convert operand 1 of mode M to mode N and store in operand 0 (which 23830 has mode N). Mode M and mode N could be fixed-point to 23831 fixed-point, signed integer to fixed-point, or floating-point to 23832 fixed-point. When overflows or underflows happen, the instruction 23833 saturates the results to the maximum or the minimum. 23834 23835'fractunsMN2' 23836 Convert operand 1 of mode M to mode N and store in operand 0 (which 23837 has mode N). Mode M and mode N could be unsigned integer to 23838 fixed-point, or fixed-point to unsigned integer. When overflows or 23839 underflows happen, the results are undefined. 23840 23841'satfractunsMN2' 23842 Convert unsigned integer operand 1 of mode M to fixed-point mode N 23843 and store in operand 0 (which has mode N). When overflows or 23844 underflows happen, the instruction saturates the results to the 23845 maximum or the minimum. 23846 23847'extvM' 23848 Extract a bit-field from register operand 1, sign-extend it, and 23849 store it in operand 0. Operand 2 specifies the width of the field 23850 in bits and operand 3 the starting bit, which counts from the most 23851 significant bit if 'BITS_BIG_ENDIAN' is true and from the least 23852 significant bit otherwise. 23853 23854 Operands 0 and 1 both have mode M. Operands 2 and 3 have a 23855 target-specific mode. 23856 23857'extvmisalignM' 23858 Extract a bit-field from memory operand 1, sign extend it, and 23859 store it in operand 0. Operand 2 specifies the width in bits and 23860 operand 3 the starting bit. The starting bit is always somewhere 23861 in the first byte of operand 1; it counts from the most significant 23862 bit if 'BITS_BIG_ENDIAN' is true and from the least significant bit 23863 otherwise. 23864 23865 Operand 0 has mode M while operand 1 has 'BLK' mode. Operands 2 23866 and 3 have a target-specific mode. 23867 23868 The instruction must not read beyond the last byte of the 23869 bit-field. 23870 23871'extzvM' 23872 Like 'extvM' except that the bit-field value is zero-extended. 23873 23874'extzvmisalignM' 23875 Like 'extvmisalignM' except that the bit-field value is 23876 zero-extended. 23877 23878'insvM' 23879 Insert operand 3 into a bit-field of register operand 0. Operand 1 23880 specifies the width of the field in bits and operand 2 the starting 23881 bit, which counts from the most significant bit if 23882 'BITS_BIG_ENDIAN' is true and from the least significant bit 23883 otherwise. 23884 23885 Operands 0 and 3 both have mode M. Operands 1 and 2 have a 23886 target-specific mode. 23887 23888'insvmisalignM' 23889 Insert operand 3 into a bit-field of memory operand 0. Operand 1 23890 specifies the width of the field in bits and operand 2 the starting 23891 bit. The starting bit is always somewhere in the first byte of 23892 operand 0; it counts from the most significant bit if 23893 'BITS_BIG_ENDIAN' is true and from the least significant bit 23894 otherwise. 23895 23896 Operand 3 has mode M while operand 0 has 'BLK' mode. Operands 1 23897 and 2 have a target-specific mode. 23898 23899 The instruction must not read or write beyond the last byte of the 23900 bit-field. 23901 23902'extv' 23903 Extract a bit-field from operand 1 (a register or memory operand), 23904 where operand 2 specifies the width in bits and operand 3 the 23905 starting bit, and store it in operand 0. Operand 0 must have mode 23906 'word_mode'. Operand 1 may have mode 'byte_mode' or 'word_mode'; 23907 often 'word_mode' is allowed only for registers. Operands 2 and 3 23908 must be valid for 'word_mode'. 23909 23910 The RTL generation pass generates this instruction only with 23911 constants for operands 2 and 3 and the constant is never zero for 23912 operand 2. 23913 23914 The bit-field value is sign-extended to a full word integer before 23915 it is stored in operand 0. 23916 23917 This pattern is deprecated; please use 'extvM' and 'extvmisalignM' 23918 instead. 23919 23920'extzv' 23921 Like 'extv' except that the bit-field value is zero-extended. 23922 23923 This pattern is deprecated; please use 'extzvM' and 23924 'extzvmisalignM' instead. 23925 23926'insv' 23927 Store operand 3 (which must be valid for 'word_mode') into a 23928 bit-field in operand 0, where operand 1 specifies the width in bits 23929 and operand 2 the starting bit. Operand 0 may have mode 23930 'byte_mode' or 'word_mode'; often 'word_mode' is allowed only for 23931 registers. Operands 1 and 2 must be valid for 'word_mode'. 23932 23933 The RTL generation pass generates this instruction only with 23934 constants for operands 1 and 2 and the constant is never zero for 23935 operand 1. 23936 23937 This pattern is deprecated; please use 'insvM' and 'insvmisalignM' 23938 instead. 23939 23940'movMODEcc' 23941 Conditionally move operand 2 or operand 3 into operand 0 according 23942 to the comparison in operand 1. If the comparison is true, operand 23943 2 is moved into operand 0, otherwise operand 3 is moved. 23944 23945 The mode of the operands being compared need not be the same as the 23946 operands being moved. Some machines, sparc64 for example, have 23947 instructions that conditionally move an integer value based on the 23948 floating point condition codes and vice versa. 23949 23950 If the machine does not have conditional move instructions, do not 23951 define these patterns. 23952 23953'addMODEcc' 23954 Similar to 'movMODEcc' but for conditional addition. Conditionally 23955 move operand 2 or (operands 2 + operand 3) into operand 0 according 23956 to the comparison in operand 1. If the comparison is false, 23957 operand 2 is moved into operand 0, otherwise (operand 2 + operand 23958 3) is moved. 23959 23960'negMODEcc' 23961 Similar to 'movMODEcc' but for conditional negation. Conditionally 23962 move the negation of operand 2 or the unchanged operand 3 into 23963 operand 0 according to the comparison in operand 1. If the 23964 comparison is true, the negation of operand 2 is moved into operand 23965 0, otherwise operand 3 is moved. 23966 23967'notMODEcc' 23968 Similar to 'negMODEcc' but for conditional complement. 23969 Conditionally move the bitwise complement of operand 2 or the 23970 unchanged operand 3 into operand 0 according to the comparison in 23971 operand 1. If the comparison is true, the complement of operand 2 23972 is moved into operand 0, otherwise operand 3 is moved. 23973 23974'cstoreMODE4' 23975 Store zero or nonzero in operand 0 according to whether a 23976 comparison is true. Operand 1 is a comparison operator. Operand 2 23977 and operand 3 are the first and second operand of the comparison, 23978 respectively. You specify the mode that operand 0 must have when 23979 you write the 'match_operand' expression. The compiler 23980 automatically sees which mode you have used and supplies an operand 23981 of that mode. 23982 23983 The value stored for a true condition must have 1 as its low bit, 23984 or else must be negative. Otherwise the instruction is not 23985 suitable and you should omit it from the machine description. You 23986 describe to the compiler exactly which value is stored by defining 23987 the macro 'STORE_FLAG_VALUE' (*note Misc::). If a description 23988 cannot be found that can be used for all the possible comparison 23989 operators, you should pick one and use a 'define_expand' to map all 23990 results onto the one you chose. 23991 23992 These operations may 'FAIL', but should do so only in relatively 23993 uncommon cases; if they would 'FAIL' for common cases involving 23994 integer comparisons, it is best to restrict the predicates to not 23995 allow these operands. Likewise if a given comparison operator will 23996 always fail, independent of the operands (for floating-point modes, 23997 the 'ordered_comparison_operator' predicate is often useful in this 23998 case). 23999 24000 If this pattern is omitted, the compiler will generate a 24001 conditional branch--for example, it may copy a constant one to the 24002 target and branching around an assignment of zero to the target--or 24003 a libcall. If the predicate for operand 1 only rejects some 24004 operators, it will also try reordering the operands and/or 24005 inverting the result value (e.g. by an exclusive OR). These 24006 possibilities could be cheaper or equivalent to the instructions 24007 used for the 'cstoreMODE4' pattern followed by those required to 24008 convert a positive result from 'STORE_FLAG_VALUE' to 1; in this 24009 case, you can and should make operand 1's predicate reject some 24010 operators in the 'cstoreMODE4' pattern, or remove the pattern 24011 altogether from the machine description. 24012 24013'cbranchMODE4' 24014 Conditional branch instruction combined with a compare instruction. 24015 Operand 0 is a comparison operator. Operand 1 and operand 2 are 24016 the first and second operands of the comparison, respectively. 24017 Operand 3 is the 'code_label' to jump to. 24018 24019'jump' 24020 A jump inside a function; an unconditional branch. Operand 0 is 24021 the 'code_label' to jump to. This pattern name is mandatory on all 24022 machines. 24023 24024'call' 24025 Subroutine call instruction returning no value. Operand 0 is the 24026 function to call; operand 1 is the number of bytes of arguments 24027 pushed as a 'const_int'; operand 2 is the number of registers used 24028 as operands. 24029 24030 On most machines, operand 2 is not actually stored into the RTL 24031 pattern. It is supplied for the sake of some RISC machines which 24032 need to put this information into the assembler code; they can put 24033 it in the RTL instead of operand 1. 24034 24035 Operand 0 should be a 'mem' RTX whose address is the address of the 24036 function. Note, however, that this address can be a 'symbol_ref' 24037 expression even if it would not be a legitimate memory address on 24038 the target machine. If it is also not a valid argument for a call 24039 instruction, the pattern for this operation should be a 24040 'define_expand' (*note Expander Definitions::) that places the 24041 address into a register and uses that register in the call 24042 instruction. 24043 24044'call_value' 24045 Subroutine call instruction returning a value. Operand 0 is the 24046 hard register in which the value is returned. There are three more 24047 operands, the same as the three operands of the 'call' instruction 24048 (but with numbers increased by one). 24049 24050 Subroutines that return 'BLKmode' objects use the 'call' insn. 24051 24052'call_pop', 'call_value_pop' 24053 Similar to 'call' and 'call_value', except used if defined and if 24054 'RETURN_POPS_ARGS' is nonzero. They should emit a 'parallel' that 24055 contains both the function call and a 'set' to indicate the 24056 adjustment made to the frame pointer. 24057 24058 For machines where 'RETURN_POPS_ARGS' can be nonzero, the use of 24059 these patterns increases the number of functions for which the 24060 frame pointer can be eliminated, if desired. 24061 24062'untyped_call' 24063 Subroutine call instruction returning a value of any type. Operand 24064 0 is the function to call; operand 1 is a memory location where the 24065 result of calling the function is to be stored; operand 2 is a 24066 'parallel' expression where each element is a 'set' expression that 24067 indicates the saving of a function return value into the result 24068 block. 24069 24070 This instruction pattern should be defined to support 24071 '__builtin_apply' on machines where special instructions are needed 24072 to call a subroutine with arbitrary arguments or to save the value 24073 returned. This instruction pattern is required on machines that 24074 have multiple registers that can hold a return value (i.e. 24075 'FUNCTION_VALUE_REGNO_P' is true for more than one register). 24076 24077'return' 24078 Subroutine return instruction. This instruction pattern name 24079 should be defined only if a single instruction can do all the work 24080 of returning from a function. 24081 24082 Like the 'movM' patterns, this pattern is also used after the RTL 24083 generation phase. In this case it is to support machines where 24084 multiple instructions are usually needed to return from a function, 24085 but some class of functions only requires one instruction to 24086 implement a return. Normally, the applicable functions are those 24087 which do not need to save any registers or allocate stack space. 24088 24089 It is valid for this pattern to expand to an instruction using 24090 'simple_return' if no epilogue is required. 24091 24092'simple_return' 24093 Subroutine return instruction. This instruction pattern name 24094 should be defined only if a single instruction can do all the work 24095 of returning from a function on a path where no epilogue is 24096 required. This pattern is very similar to the 'return' instruction 24097 pattern, but it is emitted only by the shrink-wrapping optimization 24098 on paths where the function prologue has not been executed, and a 24099 function return should occur without any of the effects of the 24100 epilogue. Additional uses may be introduced on paths where both 24101 the prologue and the epilogue have executed. 24102 24103 For such machines, the condition specified in this pattern should 24104 only be true when 'reload_completed' is nonzero and the function's 24105 epilogue would only be a single instruction. For machines with 24106 register windows, the routine 'leaf_function_p' may be used to 24107 determine if a register window push is required. 24108 24109 Machines that have conditional return instructions should define 24110 patterns such as 24111 24112 (define_insn "" 24113 [(set (pc) 24114 (if_then_else (match_operator 24115 0 "comparison_operator" 24116 [(cc0) (const_int 0)]) 24117 (return) 24118 (pc)))] 24119 "CONDITION" 24120 "...") 24121 24122 where CONDITION would normally be the same condition specified on 24123 the named 'return' pattern. 24124 24125'untyped_return' 24126 Untyped subroutine return instruction. This instruction pattern 24127 should be defined to support '__builtin_return' on machines where 24128 special instructions are needed to return a value of any type. 24129 24130 Operand 0 is a memory location where the result of calling a 24131 function with '__builtin_apply' is stored; operand 1 is a 24132 'parallel' expression where each element is a 'set' expression that 24133 indicates the restoring of a function return value from the result 24134 block. 24135 24136'nop' 24137 No-op instruction. This instruction pattern name should always be 24138 defined to output a no-op in assembler code. '(const_int 0)' will 24139 do as an RTL pattern. 24140 24141'indirect_jump' 24142 An instruction to jump to an address which is operand zero. This 24143 pattern name is mandatory on all machines. 24144 24145'casesi' 24146 Instruction to jump through a dispatch table, including bounds 24147 checking. This instruction takes five operands: 24148 24149 1. The index to dispatch on, which has mode 'SImode'. 24150 24151 2. The lower bound for indices in the table, an integer constant. 24152 24153 3. The total range of indices in the table--the largest index 24154 minus the smallest one (both inclusive). 24155 24156 4. A label that precedes the table itself. 24157 24158 5. A label to jump to if the index has a value outside the 24159 bounds. 24160 24161 The table is an 'addr_vec' or 'addr_diff_vec' inside of a 24162 'jump_table_data'. The number of elements in the table is one plus 24163 the difference between the upper bound and the lower bound. 24164 24165'tablejump' 24166 Instruction to jump to a variable address. This is a low-level 24167 capability which can be used to implement a dispatch table when 24168 there is no 'casesi' pattern. 24169 24170 This pattern requires two operands: the address or offset, and a 24171 label which should immediately precede the jump table. If the 24172 macro 'CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 24173 the first operand is an offset which counts from the address of the 24174 table; otherwise, it is an absolute address to jump to. In either 24175 case, the first operand has mode 'Pmode'. 24176 24177 The 'tablejump' insn is always the last insn before the jump table 24178 it uses. Its assembler code normally has no need to use the second 24179 operand, but you should incorporate it in the RTL pattern so that 24180 the jump optimizer will not delete the table as unreachable code. 24181 24182'decrement_and_branch_until_zero' 24183 Conditional branch instruction that decrements a register and jumps 24184 if the register is nonzero. Operand 0 is the register to decrement 24185 and test; operand 1 is the label to jump to if the register is 24186 nonzero. *Note Looping Patterns::. 24187 24188 This optional instruction pattern is only used by the combiner, 24189 typically for loops reversed by the loop optimizer when strength 24190 reduction is enabled. 24191 24192'doloop_end' 24193 Conditional branch instruction that decrements a register and jumps 24194 if the register is nonzero. Operand 0 is the register to decrement 24195 and test; operand 1 is the label to jump to if the register is 24196 nonzero. *Note Looping Patterns::. 24197 24198 This optional instruction pattern should be defined for machines 24199 with low-overhead looping instructions as the loop optimizer will 24200 try to modify suitable loops to utilize it. The target hook 24201 'TARGET_CAN_USE_DOLOOP_P' controls the conditions under which 24202 low-overhead loops can be used. 24203 24204'doloop_begin' 24205 Companion instruction to 'doloop_end' required for machines that 24206 need to perform some initialization, such as loading a special 24207 counter register. Operand 1 is the associated 'doloop_end' pattern 24208 and operand 0 is the register that it decrements. 24209 24210 If initialization insns do not always need to be emitted, use a 24211 'define_expand' (*note Expander Definitions::) and make it fail. 24212 24213'canonicalize_funcptr_for_compare' 24214 Canonicalize the function pointer in operand 1 and store the result 24215 into operand 0. 24216 24217 Operand 0 is always a 'reg' and has mode 'Pmode'; operand 1 may be 24218 a 'reg', 'mem', 'symbol_ref', 'const_int', etc and also has mode 24219 'Pmode'. 24220 24221 Canonicalization of a function pointer usually involves computing 24222 the address of the function which would be called if the function 24223 pointer were used in an indirect call. 24224 24225 Only define this pattern if function pointers on the target machine 24226 can have different values but still call the same function when 24227 used in an indirect call. 24228 24229'save_stack_block' 24230'save_stack_function' 24231'save_stack_nonlocal' 24232'restore_stack_block' 24233'restore_stack_function' 24234'restore_stack_nonlocal' 24235 Most machines save and restore the stack pointer by copying it to 24236 or from an object of mode 'Pmode'. Do not define these patterns on 24237 such machines. 24238 24239 Some machines require special handling for stack pointer saves and 24240 restores. On those machines, define the patterns corresponding to 24241 the non-standard cases by using a 'define_expand' (*note Expander 24242 Definitions::) that produces the required insns. The three types 24243 of saves and restores are: 24244 24245 1. 'save_stack_block' saves the stack pointer at the start of a 24246 block that allocates a variable-sized object, and 24247 'restore_stack_block' restores the stack pointer when the 24248 block is exited. 24249 24250 2. 'save_stack_function' and 'restore_stack_function' do a 24251 similar job for the outermost block of a function and are used 24252 when the function allocates variable-sized objects or calls 24253 'alloca'. Only the epilogue uses the restored stack pointer, 24254 allowing a simpler save or restore sequence on some machines. 24255 24256 3. 'save_stack_nonlocal' is used in functions that contain labels 24257 branched to by nested functions. It saves the stack pointer 24258 in such a way that the inner function can use 24259 'restore_stack_nonlocal' to restore the stack pointer. The 24260 compiler generates code to restore the frame and argument 24261 pointer registers, but some machines require saving and 24262 restoring additional data such as register window information 24263 or stack backchains. Place insns in these patterns to save 24264 and restore any such required data. 24265 24266 When saving the stack pointer, operand 0 is the save area and 24267 operand 1 is the stack pointer. The mode used to allocate the save 24268 area defaults to 'Pmode' but you can override that choice by 24269 defining the 'STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 24270 You must specify an integral mode, or 'VOIDmode' if no save area is 24271 needed for a particular type of save (either because no save is 24272 needed or because a machine-specific save area can be used). 24273 Operand 0 is the stack pointer and operand 1 is the save area for 24274 restore operations. If 'save_stack_block' is defined, operand 0 24275 must not be 'VOIDmode' since these saves can be arbitrarily nested. 24276 24277 A save area is a 'mem' that is at a constant offset from 24278 'virtual_stack_vars_rtx' when the stack pointer is saved for use by 24279 nonlocal gotos and a 'reg' in the other two cases. 24280 24281'allocate_stack' 24282 Subtract (or add if 'STACK_GROWS_DOWNWARD' is undefined) operand 1 24283 from the stack pointer to create space for dynamically allocated 24284 data. 24285 24286 Store the resultant pointer to this space into operand 0. If you 24287 are allocating space from the main stack, do this by emitting a 24288 move insn to copy 'virtual_stack_dynamic_rtx' to operand 0. If you 24289 are allocating the space elsewhere, generate code to copy the 24290 location of the space to operand 0. In the latter case, you must 24291 ensure this space gets freed when the corresponding space on the 24292 main stack is free. 24293 24294 Do not define this pattern if all that must be done is the 24295 subtraction. Some machines require other operations such as stack 24296 probes or maintaining the back chain. Define this pattern to emit 24297 those operations in addition to updating the stack pointer. 24298 24299'check_stack' 24300 If stack checking (*note Stack Checking::) cannot be done on your 24301 system by probing the stack, define this pattern to perform the 24302 needed check and signal an error if the stack has overflowed. The 24303 single operand is the address in the stack farthest from the 24304 current stack pointer that you need to validate. Normally, on 24305 platforms where this pattern is needed, you would obtain the stack 24306 limit from a global or thread-specific variable or register. 24307 24308'probe_stack_address' 24309 If stack checking (*note Stack Checking::) can be done on your 24310 system by probing the stack but without the need to actually access 24311 it, define this pattern and signal an error if the stack has 24312 overflowed. The single operand is the memory address in the stack 24313 that needs to be probed. 24314 24315'probe_stack' 24316 If stack checking (*note Stack Checking::) can be done on your 24317 system by probing the stack but doing it with a "store zero" 24318 instruction is not valid or optimal, define this pattern to do the 24319 probing differently and signal an error if the stack has 24320 overflowed. The single operand is the memory reference in the 24321 stack that needs to be probed. 24322 24323'nonlocal_goto' 24324 Emit code to generate a non-local goto, e.g., a jump from one 24325 function to a label in an outer function. This pattern has four 24326 arguments, each representing a value to be used in the jump. The 24327 first argument is to be loaded into the frame pointer, the second 24328 is the address to branch to (code to dispatch to the actual label), 24329 the third is the address of a location where the stack is saved, 24330 and the last is the address of the label, to be placed in the 24331 location for the incoming static chain. 24332 24333 On most machines you need not define this pattern, since GCC will 24334 already generate the correct code, which is to load the frame 24335 pointer and static chain, restore the stack (using the 24336 'restore_stack_nonlocal' pattern, if defined), and jump indirectly 24337 to the dispatcher. You need only define this pattern if this code 24338 will not work on your machine. 24339 24340'nonlocal_goto_receiver' 24341 This pattern, if defined, contains code needed at the target of a 24342 nonlocal goto after the code already generated by GCC. You will 24343 not normally need to define this pattern. A typical reason why you 24344 might need this pattern is if some value, such as a pointer to a 24345 global table, must be restored when the frame pointer is restored. 24346 Note that a nonlocal goto only occurs within a unit-of-translation, 24347 so a global table pointer that is shared by all functions of a 24348 given module need not be restored. There are no arguments. 24349 24350'exception_receiver' 24351 This pattern, if defined, contains code needed at the site of an 24352 exception handler that isn't needed at the site of a nonlocal goto. 24353 You will not normally need to define this pattern. A typical 24354 reason why you might need this pattern is if some value, such as a 24355 pointer to a global table, must be restored after control flow is 24356 branched to the handler of an exception. There are no arguments. 24357 24358'builtin_setjmp_setup' 24359 This pattern, if defined, contains additional code needed to 24360 initialize the 'jmp_buf'. You will not normally need to define 24361 this pattern. A typical reason why you might need this pattern is 24362 if some value, such as a pointer to a global table, must be 24363 restored. Though it is preferred that the pointer value be 24364 recalculated if possible (given the address of a label for 24365 instance). The single argument is a pointer to the 'jmp_buf'. 24366 Note that the buffer is five words long and that the first three 24367 are normally used by the generic mechanism. 24368 24369'builtin_setjmp_receiver' 24370 This pattern, if defined, contains code needed at the site of a 24371 built-in setjmp that isn't needed at the site of a nonlocal goto. 24372 You will not normally need to define this pattern. A typical 24373 reason why you might need this pattern is if some value, such as a 24374 pointer to a global table, must be restored. It takes one 24375 argument, which is the label to which builtin_longjmp transferred 24376 control; this pattern may be emitted at a small offset from that 24377 label. 24378 24379'builtin_longjmp' 24380 This pattern, if defined, performs the entire action of the 24381 longjmp. You will not normally need to define this pattern unless 24382 you also define 'builtin_setjmp_setup'. The single argument is a 24383 pointer to the 'jmp_buf'. 24384 24385'eh_return' 24386 This pattern, if defined, affects the way '__builtin_eh_return', 24387 and thence the call frame exception handling library routines, are 24388 built. It is intended to handle non-trivial actions needed along 24389 the abnormal return path. 24390 24391 The address of the exception handler to which the function should 24392 return is passed as operand to this pattern. It will normally need 24393 to copied by the pattern to some special register or memory 24394 location. If the pattern needs to determine the location of the 24395 target call frame in order to do so, it may use 24396 'EH_RETURN_STACKADJ_RTX', if defined; it will have already been 24397 assigned. 24398 24399 If this pattern is not defined, the default action will be to 24400 simply copy the return address to 'EH_RETURN_HANDLER_RTX'. Either 24401 that macro or this pattern needs to be defined if call frame 24402 exception handling is to be used. 24403 24404'prologue' 24405 This pattern, if defined, emits RTL for entry to a function. The 24406 function entry is responsible for setting up the stack frame, 24407 initializing the frame pointer register, saving callee saved 24408 registers, etc. 24409 24410 Using a prologue pattern is generally preferred over defining 24411 'TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 24412 prologue. 24413 24414 The 'prologue' pattern is particularly useful for targets which 24415 perform instruction scheduling. 24416 24417'window_save' 24418 This pattern, if defined, emits RTL for a register window save. It 24419 should be defined if the target machine has register windows but 24420 the window events are decoupled from calls to subroutines. The 24421 canonical example is the SPARC architecture. 24422 24423'epilogue' 24424 This pattern emits RTL for exit from a function. The function exit 24425 is responsible for deallocating the stack frame, restoring callee 24426 saved registers and emitting the return instruction. 24427 24428 Using an epilogue pattern is generally preferred over defining 24429 'TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 24430 epilogue. 24431 24432 The 'epilogue' pattern is particularly useful for targets which 24433 perform instruction scheduling or which have delay slots for their 24434 return instruction. 24435 24436'sibcall_epilogue' 24437 This pattern, if defined, emits RTL for exit from a function 24438 without the final branch back to the calling function. This 24439 pattern will be emitted before any sibling call (aka tail call) 24440 sites. 24441 24442 The 'sibcall_epilogue' pattern must not clobber any arguments used 24443 for parameter passing or any stack slots for arguments passed to 24444 the current function. 24445 24446'trap' 24447 This pattern, if defined, signals an error, typically by causing 24448 some kind of signal to be raised. Among other places, it is used 24449 by the Java front end to signal 'invalid array index' exceptions. 24450 24451'ctrapMM4' 24452 Conditional trap instruction. Operand 0 is a piece of RTL which 24453 performs a comparison, and operands 1 and 2 are the arms of the 24454 comparison. Operand 3 is the trap code, an integer. 24455 24456 A typical 'ctrap' pattern looks like 24457 24458 (define_insn "ctrapsi4" 24459 [(trap_if (match_operator 0 "trap_operator" 24460 [(match_operand 1 "register_operand") 24461 (match_operand 2 "immediate_operand")]) 24462 (match_operand 3 "const_int_operand" "i"))] 24463 "" 24464 "...") 24465 24466'prefetch' 24467 This pattern, if defined, emits code for a non-faulting data 24468 prefetch instruction. Operand 0 is the address of the memory to 24469 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 24470 for a write to the memory address, or a constant 0 otherwise. 24471 Operand 2 is the expected degree of temporal locality of the data 24472 and is a value between 0 and 3, inclusive; 0 means that the data 24473 has no temporal locality, so it need not be left in the cache after 24474 the access; 3 means that the data has a high degree of temporal 24475 locality and should be left in all levels of cache possible; 1 and 24476 2 mean, respectively, a low or moderate degree of temporal 24477 locality. 24478 24479 Targets that do not support write prefetches or locality hints can 24480 ignore the values of operands 1 and 2. 24481 24482'blockage' 24483 This pattern defines a pseudo insn that prevents the instruction 24484 scheduler and other passes from moving instructions and using 24485 register equivalences across the boundary defined by the blockage 24486 insn. This needs to be an UNSPEC_VOLATILE pattern or a volatile 24487 ASM. 24488 24489'memory_barrier' 24490 If the target memory model is not fully synchronous, then this 24491 pattern should be defined to an instruction that orders both loads 24492 and stores before the instruction with respect to loads and stores 24493 after the instruction. This pattern has no operands. 24494 24495'sync_compare_and_swapMODE' 24496 This pattern, if defined, emits code for an atomic compare-and-swap 24497 operation. Operand 1 is the memory on which the atomic operation 24498 is performed. Operand 2 is the "old" value to be compared against 24499 the current contents of the memory location. Operand 3 is the 24500 "new" value to store in the memory if the compare succeeds. 24501 Operand 0 is the result of the operation; it should contain the 24502 contents of the memory before the operation. If the compare 24503 succeeds, this should obviously be a copy of operand 2. 24504 24505 This pattern must show that both operand 0 and operand 1 are 24506 modified. 24507 24508 This pattern must issue any memory barrier instructions such that 24509 all memory operations before the atomic operation occur before the 24510 atomic operation and all memory operations after the atomic 24511 operation occur after the atomic operation. 24512 24513 For targets where the success or failure of the compare-and-swap 24514 operation is available via the status flags, it is possible to 24515 avoid a separate compare operation and issue the subsequent branch 24516 or store-flag operation immediately after the compare-and-swap. To 24517 this end, GCC will look for a 'MODE_CC' set in the output of 24518 'sync_compare_and_swapMODE'; if the machine description includes 24519 such a set, the target should also define special 'cbranchcc4' 24520 and/or 'cstorecc4' instructions. GCC will then be able to take the 24521 destination of the 'MODE_CC' set and pass it to the 'cbranchcc4' or 24522 'cstorecc4' pattern as the first operand of the comparison (the 24523 second will be '(const_int 0)'). 24524 24525 For targets where the operating system may provide support for this 24526 operation via library calls, the 'sync_compare_and_swap_optab' may 24527 be initialized to a function with the same interface as the 24528 '__sync_val_compare_and_swap_N' built-in. If the entire set of 24529 __SYNC builtins are supported via library calls, the target can 24530 initialize all of the optabs at once with 'init_sync_libfuncs'. 24531 For the purposes of C++11 'std::atomic::is_lock_free', it is 24532 assumed that these library calls do _not_ use any kind of 24533 interruptable locking. 24534 24535'sync_addMODE', 'sync_subMODE' 24536'sync_iorMODE', 'sync_andMODE' 24537'sync_xorMODE', 'sync_nandMODE' 24538 These patterns emit code for an atomic operation on memory. 24539 Operand 0 is the memory on which the atomic operation is performed. 24540 Operand 1 is the second operand to the binary operator. 24541 24542 This pattern must issue any memory barrier instructions such that 24543 all memory operations before the atomic operation occur before the 24544 atomic operation and all memory operations after the atomic 24545 operation occur after the atomic operation. 24546 24547 If these patterns are not defined, the operation will be 24548 constructed from a compare-and-swap operation, if defined. 24549 24550'sync_old_addMODE', 'sync_old_subMODE' 24551'sync_old_iorMODE', 'sync_old_andMODE' 24552'sync_old_xorMODE', 'sync_old_nandMODE' 24553 These patterns emit code for an atomic operation on memory, and 24554 return the value that the memory contained before the operation. 24555 Operand 0 is the result value, operand 1 is the memory on which the 24556 atomic operation is performed, and operand 2 is the second operand 24557 to the binary operator. 24558 24559 This pattern must issue any memory barrier instructions such that 24560 all memory operations before the atomic operation occur before the 24561 atomic operation and all memory operations after the atomic 24562 operation occur after the atomic operation. 24563 24564 If these patterns are not defined, the operation will be 24565 constructed from a compare-and-swap operation, if defined. 24566 24567'sync_new_addMODE', 'sync_new_subMODE' 24568'sync_new_iorMODE', 'sync_new_andMODE' 24569'sync_new_xorMODE', 'sync_new_nandMODE' 24570 These patterns are like their 'sync_old_OP' counterparts, except 24571 that they return the value that exists in the memory location after 24572 the operation, rather than before the operation. 24573 24574'sync_lock_test_and_setMODE' 24575 This pattern takes two forms, based on the capabilities of the 24576 target. In either case, operand 0 is the result of the operand, 24577 operand 1 is the memory on which the atomic operation is performed, 24578 and operand 2 is the value to set in the lock. 24579 24580 In the ideal case, this operation is an atomic exchange operation, 24581 in which the previous value in memory operand is copied into the 24582 result operand, and the value operand is stored in the memory 24583 operand. 24584 24585 For less capable targets, any value operand that is not the 24586 constant 1 should be rejected with 'FAIL'. In this case the target 24587 may use an atomic test-and-set bit operation. The result operand 24588 should contain 1 if the bit was previously set and 0 if the bit was 24589 previously clear. The true contents of the memory operand are 24590 implementation defined. 24591 24592 This pattern must issue any memory barrier instructions such that 24593 the pattern as a whole acts as an acquire barrier, that is all 24594 memory operations after the pattern do not occur until the lock is 24595 acquired. 24596 24597 If this pattern is not defined, the operation will be constructed 24598 from a compare-and-swap operation, if defined. 24599 24600'sync_lock_releaseMODE' 24601 This pattern, if defined, releases a lock set by 24602 'sync_lock_test_and_setMODE'. Operand 0 is the memory that 24603 contains the lock; operand 1 is the value to store in the lock. 24604 24605 If the target doesn't implement full semantics for 24606 'sync_lock_test_and_setMODE', any value operand which is not the 24607 constant 0 should be rejected with 'FAIL', and the true contents of 24608 the memory operand are implementation defined. 24609 24610 This pattern must issue any memory barrier instructions such that 24611 the pattern as a whole acts as a release barrier, that is the lock 24612 is released only after all previous memory operations have 24613 completed. 24614 24615 If this pattern is not defined, then a 'memory_barrier' pattern 24616 will be emitted, followed by a store of the value to the memory 24617 operand. 24618 24619'atomic_compare_and_swapMODE' 24620 This pattern, if defined, emits code for an atomic compare-and-swap 24621 operation with memory model semantics. Operand 2 is the memory on 24622 which the atomic operation is performed. Operand 0 is an output 24623 operand which is set to true or false based on whether the 24624 operation succeeded. Operand 1 is an output operand which is set 24625 to the contents of the memory before the operation was attempted. 24626 Operand 3 is the value that is expected to be in memory. Operand 4 24627 is the value to put in memory if the expected value is found there. 24628 Operand 5 is set to 1 if this compare and swap is to be treated as 24629 a weak operation. Operand 6 is the memory model to be used if the 24630 operation is a success. Operand 7 is the memory model to be used 24631 if the operation fails. 24632 24633 If memory referred to in operand 2 contains the value in operand 3, 24634 then operand 4 is stored in memory pointed to by operand 2 and 24635 fencing based on the memory model in operand 6 is issued. 24636 24637 If memory referred to in operand 2 does not contain the value in 24638 operand 3, then fencing based on the memory model in operand 7 is 24639 issued. 24640 24641 If a target does not support weak compare-and-swap operations, or 24642 the port elects not to implement weak operations, the argument in 24643 operand 5 can be ignored. Note a strong implementation must be 24644 provided. 24645 24646 If this pattern is not provided, the '__atomic_compare_exchange' 24647 built-in functions will utilize the legacy 'sync_compare_and_swap' 24648 pattern with an '__ATOMIC_SEQ_CST' memory model. 24649 24650'atomic_loadMODE' 24651 This pattern implements an atomic load operation with memory model 24652 semantics. Operand 1 is the memory address being loaded from. 24653 Operand 0 is the result of the load. Operand 2 is the memory model 24654 to be used for the load operation. 24655 24656 If not present, the '__atomic_load' built-in function will either 24657 resort to a normal load with memory barriers, or a compare-and-swap 24658 operation if a normal load would not be atomic. 24659 24660'atomic_storeMODE' 24661 This pattern implements an atomic store operation with memory model 24662 semantics. Operand 0 is the memory address being stored to. 24663 Operand 1 is the value to be written. Operand 2 is the memory 24664 model to be used for the operation. 24665 24666 If not present, the '__atomic_store' built-in function will attempt 24667 to perform a normal store and surround it with any required memory 24668 fences. If the store would not be atomic, then an 24669 '__atomic_exchange' is attempted with the result being ignored. 24670 24671'atomic_exchangeMODE' 24672 This pattern implements an atomic exchange operation with memory 24673 model semantics. Operand 1 is the memory location the operation is 24674 performed on. Operand 0 is an output operand which is set to the 24675 original value contained in the memory pointed to by operand 1. 24676 Operand 2 is the value to be stored. Operand 3 is the memory model 24677 to be used. 24678 24679 If this pattern is not present, the built-in function 24680 '__atomic_exchange' will attempt to preform the operation with a 24681 compare and swap loop. 24682 24683'atomic_addMODE', 'atomic_subMODE' 24684'atomic_orMODE', 'atomic_andMODE' 24685'atomic_xorMODE', 'atomic_nandMODE' 24686 These patterns emit code for an atomic operation on memory with 24687 memory model semantics. Operand 0 is the memory on which the 24688 atomic operation is performed. Operand 1 is the second operand to 24689 the binary operator. Operand 2 is the memory model to be used by 24690 the operation. 24691 24692 If these patterns are not defined, attempts will be made to use 24693 legacy 'sync' patterns, or equivalent patterns which return a 24694 result. If none of these are available a compare-and-swap loop 24695 will be used. 24696 24697'atomic_fetch_addMODE', 'atomic_fetch_subMODE' 24698'atomic_fetch_orMODE', 'atomic_fetch_andMODE' 24699'atomic_fetch_xorMODE', 'atomic_fetch_nandMODE' 24700 These patterns emit code for an atomic operation on memory with 24701 memory model semantics, and return the original value. Operand 0 24702 is an output operand which contains the value of the memory 24703 location before the operation was performed. Operand 1 is the 24704 memory on which the atomic operation is performed. Operand 2 is 24705 the second operand to the binary operator. Operand 3 is the memory 24706 model to be used by the operation. 24707 24708 If these patterns are not defined, attempts will be made to use 24709 legacy 'sync' patterns. If none of these are available a 24710 compare-and-swap loop will be used. 24711 24712'atomic_add_fetchMODE', 'atomic_sub_fetchMODE' 24713'atomic_or_fetchMODE', 'atomic_and_fetchMODE' 24714'atomic_xor_fetchMODE', 'atomic_nand_fetchMODE' 24715 These patterns emit code for an atomic operation on memory with 24716 memory model semantics and return the result after the operation is 24717 performed. Operand 0 is an output operand which contains the value 24718 after the operation. Operand 1 is the memory on which the atomic 24719 operation is performed. Operand 2 is the second operand to the 24720 binary operator. Operand 3 is the memory model to be used by the 24721 operation. 24722 24723 If these patterns are not defined, attempts will be made to use 24724 legacy 'sync' patterns, or equivalent patterns which return the 24725 result before the operation followed by the arithmetic operation 24726 required to produce the result. If none of these are available a 24727 compare-and-swap loop will be used. 24728 24729'atomic_test_and_set' 24730 This pattern emits code for '__builtin_atomic_test_and_set'. 24731 Operand 0 is an output operand which is set to true if the previous 24732 previous contents of the byte was "set", and false otherwise. 24733 Operand 1 is the 'QImode' memory to be modified. Operand 2 is the 24734 memory model to be used. 24735 24736 The specific value that defines "set" is implementation defined, 24737 and is normally based on what is performed by the native atomic 24738 test and set instruction. 24739 24740'mem_thread_fenceMODE' 24741 This pattern emits code required to implement a thread fence with 24742 memory model semantics. Operand 0 is the memory model to be used. 24743 24744 If this pattern is not specified, all memory models except 24745 '__ATOMIC_RELAXED' will result in issuing a 'sync_synchronize' 24746 barrier pattern. 24747 24748'mem_signal_fenceMODE' 24749 This pattern emits code required to implement a signal fence with 24750 memory model semantics. Operand 0 is the memory model to be used. 24751 24752 This pattern should impact the compiler optimizers the same way 24753 that mem_signal_fence does, but it does not need to issue any 24754 barrier instructions. 24755 24756 If this pattern is not specified, all memory models except 24757 '__ATOMIC_RELAXED' will result in issuing a 'sync_synchronize' 24758 barrier pattern. 24759 24760'get_thread_pointerMODE' 24761'set_thread_pointerMODE' 24762 These patterns emit code that reads/sets the TLS thread pointer. 24763 Currently, these are only needed if the target needs to support the 24764 '__builtin_thread_pointer' and '__builtin_set_thread_pointer' 24765 builtins. 24766 24767 The get/set patterns have a single output/input operand 24768 respectively, with MODE intended to be 'Pmode'. 24769 24770'stack_protect_set' 24771 This pattern, if defined, moves a 'ptr_mode' value from the memory 24772 in operand 1 to the memory in operand 0 without leaving the value 24773 in a register afterward. This is to avoid leaking the value some 24774 place that an attacker might use to rewrite the stack guard slot 24775 after having clobbered it. 24776 24777 If this pattern is not defined, then a plain move pattern is 24778 generated. 24779 24780'stack_protect_test' 24781 This pattern, if defined, compares a 'ptr_mode' value from the 24782 memory in operand 1 with the memory in operand 0 without leaving 24783 the value in a register afterward and branches to operand 2 if the 24784 values were equal. 24785 24786 If this pattern is not defined, then a plain compare pattern and 24787 conditional branch pattern is used. 24788 24789'clear_cache' 24790 This pattern, if defined, flushes the instruction cache for a 24791 region of memory. The region is bounded to by the Pmode pointers 24792 in operand 0 inclusive and operand 1 exclusive. 24793 24794 If this pattern is not defined, a call to the library function 24795 '__clear_cache' is used. 24796 24797 24798File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 24799 2480016.10 When the Order of Patterns Matters 24801======================================== 24802 24803Sometimes an insn can match more than one instruction pattern. Then the 24804pattern that appears first in the machine description is the one used. 24805Therefore, more specific patterns (patterns that will match fewer 24806things) and faster instructions (those that will produce better code 24807when they do match) should usually go first in the description. 24808 24809 In some cases the effect of ordering the patterns can be used to hide a 24810pattern when it is not valid. For example, the 68000 has an instruction 24811for converting a fullword to floating point and another for converting a 24812byte to floating point. An instruction converting an integer to 24813floating point could match either one. We put the pattern to convert 24814the fullword first to make sure that one will be used rather than the 24815other. (Otherwise a large integer might be generated as a single-byte 24816immediate quantity, which would not work.) Instead of using this 24817pattern ordering it would be possible to make the pattern for 24818convert-a-byte smart enough to deal properly with any constant value. 24819 24820 24821File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 24822 2482316.11 Interdependence of Patterns 24824================================= 24825 24826In some cases machines support instructions identical except for the 24827machine mode of one or more operands. For example, there may be 24828"sign-extend halfword" and "sign-extend byte" instructions whose 24829patterns are 24830 24831 (set (match_operand:SI 0 ...) 24832 (extend:SI (match_operand:HI 1 ...))) 24833 24834 (set (match_operand:SI 0 ...) 24835 (extend:SI (match_operand:QI 1 ...))) 24836 24837Constant integers do not specify a machine mode, so an instruction to 24838extend a constant value could match either pattern. The pattern it 24839actually will match is the one that appears first in the file. For 24840correct results, this must be the one for the widest possible mode 24841('HImode', here). If the pattern matches the 'QImode' instruction, the 24842results will be incorrect if the constant value does not actually fit 24843that mode. 24844 24845 Such instructions to extend constants are rarely generated because they 24846are optimized away, but they do occasionally happen in nonoptimized 24847compilations. 24848 24849 If a constraint in a pattern allows a constant, the reload pass may 24850replace a register with a constant permitted by the constraint in some 24851cases. Similarly for memory references. Because of this substitution, 24852you should not provide separate patterns for increment and decrement 24853instructions. Instead, they should be generated from the same pattern 24854that supports register-register add insns by examining the operands and 24855generating the appropriate machine instruction. 24856 24857 24858File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 24859 2486016.12 Defining Jump Instruction Patterns 24861======================================== 24862 24863GCC does not assume anything about how the machine realizes jumps. The 24864machine description should define a single pattern, usually a 24865'define_expand', which expands to all the required insns. 24866 24867 Usually, this would be a comparison insn to set the condition code and 24868a separate branch insn testing the condition code and branching or not 24869according to its value. For many machines, however, separating compares 24870and branches is limiting, which is why the more flexible approach with 24871one 'define_expand' is used in GCC. The machine description becomes 24872clearer for architectures that have compare-and-branch instructions but 24873no condition code. It also works better when different sets of 24874comparison operators are supported by different kinds of conditional 24875branches (e.g. integer vs. floating-point), or by conditional branches 24876with respect to conditional stores. 24877 24878 Two separate insns are always used if the machine description 24879represents a condition code register using the legacy RTL expression 24880'(cc0)', and on most machines that use a separate condition code 24881register (*note Condition Code::). For machines that use '(cc0)', in 24882fact, the set and use of the condition code must be separate and 24883adjacent(1), thus allowing flags in 'cc_status' to be used (*note 24884Condition Code::) and so that the comparison and branch insns could be 24885located from each other by using the functions 'prev_cc0_setter' and 24886'next_cc0_user'. 24887 24888 Even in this case having a single entry point for conditional branches 24889is advantageous, because it handles equally well the case where a single 24890comparison instruction records the results of both signed and unsigned 24891comparison of the given operands (with the branch insns coming in 24892distinct signed and unsigned flavors) as in the x86 or SPARC, and the 24893case where there are distinct signed and unsigned compare instructions 24894and only one set of conditional branch instructions as in the PowerPC. 24895 24896 ---------- Footnotes ---------- 24897 24898 (1) 'note' insns can separate them, though. 24899 24900 24901File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 24902 2490316.13 Defining Looping Instruction Patterns 24904=========================================== 24905 24906Some machines have special jump instructions that can be utilized to 24907make loops more efficient. A common example is the 68000 'dbra' 24908instruction which performs a decrement of a register and a branch if the 24909result was greater than zero. Other machines, in particular digital 24910signal processors (DSPs), have special block repeat instructions to 24911provide low-overhead loop support. For example, the TI TMS320C3x/C4x 24912DSPs have a block repeat instruction that loads special registers to 24913mark the top and end of a loop and to count the number of loop 24914iterations. This avoids the need for fetching and executing a 24915'dbra'-like instruction and avoids pipeline stalls associated with the 24916jump. 24917 24918 GCC has three special named patterns to support low overhead looping. 24919They are 'decrement_and_branch_until_zero', 'doloop_begin', and 24920'doloop_end'. The first pattern, 'decrement_and_branch_until_zero', is 24921not emitted during RTL generation but may be emitted during the 24922instruction combination phase. This requires the assistance of the loop 24923optimizer, using information collected during strength reduction, to 24924reverse a loop to count down to zero. Some targets also require the 24925loop optimizer to add a 'REG_NONNEG' note to indicate that the iteration 24926count is always positive. This is needed if the target performs a 24927signed loop termination test. For example, the 68000 uses a pattern 24928similar to the following for its 'dbra' instruction: 24929 24930 (define_insn "decrement_and_branch_until_zero" 24931 [(set (pc) 24932 (if_then_else 24933 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am") 24934 (const_int -1)) 24935 (const_int 0)) 24936 (label_ref (match_operand 1 "" "")) 24937 (pc))) 24938 (set (match_dup 0) 24939 (plus:SI (match_dup 0) 24940 (const_int -1)))] 24941 "find_reg_note (insn, REG_NONNEG, 0)" 24942 "...") 24943 24944 Note that since the insn is both a jump insn and has an output, it must 24945deal with its own reloads, hence the 'm' constraints. Also note that 24946since this insn is generated by the instruction combination phase 24947combining two sequential insns together into an implicit parallel insn, 24948the iteration counter needs to be biased by the same amount as the 24949decrement operation, in this case -1. Note that the following similar 24950pattern will not be matched by the combiner. 24951 24952 (define_insn "decrement_and_branch_until_zero" 24953 [(set (pc) 24954 (if_then_else 24955 (ge (match_operand:SI 0 "general_operand" "+d*am") 24956 (const_int 1)) 24957 (label_ref (match_operand 1 "" "")) 24958 (pc))) 24959 (set (match_dup 0) 24960 (plus:SI (match_dup 0) 24961 (const_int -1)))] 24962 "find_reg_note (insn, REG_NONNEG, 0)" 24963 "...") 24964 24965 The other two special looping patterns, 'doloop_begin' and 24966'doloop_end', are emitted by the loop optimizer for certain well-behaved 24967loops with a finite number of loop iterations using information 24968collected during strength reduction. 24969 24970 The 'doloop_end' pattern describes the actual looping instruction (or 24971the implicit looping operation) and the 'doloop_begin' pattern is an 24972optional companion pattern that can be used for initialization needed 24973for some low-overhead looping instructions. 24974 24975 Note that some machines require the actual looping instruction to be 24976emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 24977the true RTL for a looping instruction at the top of the loop can cause 24978problems with flow analysis. So instead, a dummy 'doloop' insn is 24979emitted at the end of the loop. The machine dependent reorg pass checks 24980for the presence of this 'doloop' insn and then searches back to the top 24981of the loop, where it inserts the true looping insn (provided there are 24982no instructions in the loop which would cause problems). Any additional 24983labels can be emitted at this point. In addition, if the desired 24984special iteration counter register was not allocated, this machine 24985dependent reorg pass could emit a traditional compare and jump 24986instruction pair. 24987 24988 The essential difference between the 'decrement_and_branch_until_zero' 24989and the 'doloop_end' patterns is that the loop optimizer allocates an 24990additional pseudo register for the latter as an iteration counter. This 24991pseudo register cannot be used within the loop (i.e., general induction 24992variables cannot be derived from it), however, in many cases the loop 24993induction variable may become redundant and removed by the flow pass. 24994 24995 24996File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 24997 2499816.14 Canonicalization of Instructions 24999====================================== 25000 25001There are often cases where multiple RTL expressions could represent an 25002operation performed by a single machine instruction. This situation is 25003most commonly encountered with logical, branch, and multiply-accumulate 25004instructions. In such cases, the compiler attempts to convert these 25005multiple RTL expressions into a single canonical form to reduce the 25006number of insn patterns required. 25007 25008 In addition to algebraic simplifications, following canonicalizations 25009are performed: 25010 25011 * For commutative and comparison operators, a constant is always made 25012 the second operand. If a machine only supports a constant as the 25013 second operand, only patterns that match a constant in the second 25014 operand need be supplied. 25015 25016 * For associative operators, a sequence of operators will always 25017 chain to the left; for instance, only the left operand of an 25018 integer 'plus' can itself be a 'plus'. 'and', 'ior', 'xor', 25019 'plus', 'mult', 'smin', 'smax', 'umin', and 'umax' are associative 25020 when applied to integers, and sometimes to floating-point. 25021 25022 * For these operators, if only one operand is a 'neg', 'not', 'mult', 25023 'plus', or 'minus' expression, it will be the first operand. 25024 25025 * In combinations of 'neg', 'mult', 'plus', and 'minus', the 'neg' 25026 operations (if any) will be moved inside the operations as far as 25027 possible. For instance, '(neg (mult A B))' is canonicalized as 25028 '(mult (neg A) B)', but '(plus (mult (neg B) C) A)' is 25029 canonicalized as '(minus A (mult B C))'. 25030 25031 * For the 'compare' operator, a constant is always the second operand 25032 if the first argument is a condition code register or '(cc0)'. 25033 25034 * An operand of 'neg', 'not', 'mult', 'plus', or 'minus' is made the 25035 first operand under the same conditions as above. 25036 25037 * '(ltu (plus A B) B)' is converted to '(ltu (plus A B) A)'. 25038 Likewise with 'geu' instead of 'ltu'. 25039 25040 * '(minus X (const_int N))' is converted to '(plus X (const_int 25041 -N))'. 25042 25043 * Within address computations (i.e., inside 'mem'), a left shift is 25044 converted into the appropriate multiplication by a power of two. 25045 25046 * De Morgan's Law is used to move bitwise negation inside a bitwise 25047 logical-and or logical-or operation. If this results in only one 25048 operand being a 'not' expression, it will be the first one. 25049 25050 A machine that has an instruction that performs a bitwise 25051 logical-and of one operand with the bitwise negation of the other 25052 should specify the pattern for that instruction as 25053 25054 (define_insn "" 25055 [(set (match_operand:M 0 ...) 25056 (and:M (not:M (match_operand:M 1 ...)) 25057 (match_operand:M 2 ...)))] 25058 "..." 25059 "...") 25060 25061 Similarly, a pattern for a "NAND" instruction should be written 25062 25063 (define_insn "" 25064 [(set (match_operand:M 0 ...) 25065 (ior:M (not:M (match_operand:M 1 ...)) 25066 (not:M (match_operand:M 2 ...))))] 25067 "..." 25068 "...") 25069 25070 In both cases, it is not necessary to include patterns for the many 25071 logically equivalent RTL expressions. 25072 25073 * The only possible RTL expressions involving both bitwise 25074 exclusive-or and bitwise negation are '(xor:M X Y)' and '(not:M 25075 (xor:M X Y))'. 25076 25077 * The sum of three items, one of which is a constant, will only 25078 appear in the form 25079 25080 (plus:M (plus:M X Y) CONSTANT) 25081 25082 * Equality comparisons of a group of bits (usually a single bit) with 25083 zero will be written using 'zero_extract' rather than the 25084 equivalent 'and' or 'sign_extract' operations. 25085 25086 * '(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))' 25087 is converted to '(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))', 25088 and likewise for 'zero_extend'. 25089 25090 * '(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))' 25091 is converted to '(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S)) 25092 (sign_extend:M1 Y))', and likewise for patterns using 'zero_extend' 25093 and 'lshiftrt'. If the second operand of 'mult' is also a shift, 25094 then that is extended also. This transformation is only applied 25095 when it can be proven that the original operation had sufficient 25096 precision to prevent overflow. 25097 25098 Further canonicalization rules are defined in the function 25099'commutative_operand_precedence' in 'gcc/rtlanal.c'. 25100 25101 25102File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 25103 2510416.15 Defining RTL Sequences for Code Generation 25105================================================ 25106 25107On some target machines, some standard pattern names for RTL generation 25108cannot be handled with single insn, but a sequence of RTL insns can 25109represent them. For these target machines, you can write a 25110'define_expand' to specify how to generate the sequence of RTL. 25111 25112 A 'define_expand' is an RTL expression that looks almost like a 25113'define_insn'; but, unlike the latter, a 'define_expand' is used only 25114for RTL generation and it can produce more than one RTL insn. 25115 25116 A 'define_expand' RTX has four operands: 25117 25118 * The name. Each 'define_expand' must have a name, since the only 25119 use for it is to refer to it by name. 25120 25121 * The RTL template. This is a vector of RTL expressions representing 25122 a sequence of separate instructions. Unlike 'define_insn', there 25123 is no implicit surrounding 'PARALLEL'. 25124 25125 * The condition, a string containing a C expression. This expression 25126 is used to express how the availability of this pattern depends on 25127 subclasses of target machine, selected by command-line options when 25128 GCC is run. This is just like the condition of a 'define_insn' 25129 that has a standard name. Therefore, the condition (if present) 25130 may not depend on the data in the insn being matched, but only the 25131 target-machine-type flags. The compiler needs to test these 25132 conditions during initialization in order to learn exactly which 25133 named instructions are available in a particular run. 25134 25135 * The preparation statements, a string containing zero or more C 25136 statements which are to be executed before RTL code is generated 25137 from the RTL template. 25138 25139 Usually these statements prepare temporary registers for use as 25140 internal operands in the RTL template, but they can also generate 25141 RTL insns directly by calling routines such as 'emit_insn', etc. 25142 Any such insns precede the ones that come from the RTL template. 25143 25144 * Optionally, a vector containing the values of attributes. *Note 25145 Insn Attributes::. 25146 25147 Every RTL insn emitted by a 'define_expand' must match some 25148'define_insn' in the machine description. Otherwise, the compiler will 25149crash when trying to generate code for the insn or trying to optimize 25150it. 25151 25152 The RTL template, in addition to controlling generation of RTL insns, 25153also describes the operands that need to be specified when this pattern 25154is used. In particular, it gives a predicate for each operand. 25155 25156 A true operand, which needs to be specified in order to generate RTL 25157from the pattern, should be described with a 'match_operand' in its 25158first occurrence in the RTL template. This enters information on the 25159operand's predicate into the tables that record such things. GCC uses 25160the information to preload the operand into a register if that is 25161required for valid RTL code. If the operand is referred to more than 25162once, subsequent references should use 'match_dup'. 25163 25164 The RTL template may also refer to internal "operands" which are 25165temporary registers or labels used only within the sequence made by the 25166'define_expand'. Internal operands are substituted into the RTL 25167template with 'match_dup', never with 'match_operand'. The values of 25168the internal operands are not passed in as arguments by the compiler 25169when it requests use of this pattern. Instead, they are computed within 25170the pattern, in the preparation statements. These statements compute 25171the values and store them into the appropriate elements of 'operands' so 25172that 'match_dup' can find them. 25173 25174 There are two special macros defined for use in the preparation 25175statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 25176a statement. 25177 25178'DONE' 25179 Use the 'DONE' macro to end RTL generation for the pattern. The 25180 only RTL insns resulting from the pattern on this occasion will be 25181 those already emitted by explicit calls to 'emit_insn' within the 25182 preparation statements; the RTL template will not be generated. 25183 25184'FAIL' 25185 Make the pattern fail on this occasion. When a pattern fails, it 25186 means that the pattern was not truly available. The calling 25187 routines in the compiler will try other strategies for code 25188 generation using other patterns. 25189 25190 Failure is currently supported only for binary (addition, 25191 multiplication, shifting, etc.) and bit-field ('extv', 'extzv', 25192 and 'insv') operations. 25193 25194 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 25195then the 'define_expand' acts like a 'define_insn' in that the RTL 25196template is used to generate the insn. 25197 25198 The RTL template is not used for matching, only for generating the 25199initial insn list. If the preparation statement always invokes 'DONE' 25200or 'FAIL', the RTL template may be reduced to a simple list of operands, 25201such as this example: 25202 25203 (define_expand "addsi3" 25204 [(match_operand:SI 0 "register_operand" "") 25205 (match_operand:SI 1 "register_operand" "") 25206 (match_operand:SI 2 "register_operand" "")] 25207 "" 25208 " 25209 { 25210 handle_add (operands[0], operands[1], operands[2]); 25211 DONE; 25212 }") 25213 25214 Here is an example, the definition of left-shift for the SPUR chip: 25215 25216 (define_expand "ashlsi3" 25217 [(set (match_operand:SI 0 "register_operand" "") 25218 (ashift:SI 25219 (match_operand:SI 1 "register_operand" "") 25220 (match_operand:SI 2 "nonmemory_operand" "")))] 25221 "" 25222 " 25223 25224 { 25225 if (GET_CODE (operands[2]) != CONST_INT 25226 || (unsigned) INTVAL (operands[2]) > 3) 25227 FAIL; 25228 }") 25229 25230This example uses 'define_expand' so that it can generate an RTL insn 25231for shifting when the shift-count is in the supported range of 0 to 3 25232but fail in other cases where machine insns aren't available. When it 25233fails, the compiler tries another strategy using different patterns 25234(such as, a library call). 25235 25236 If the compiler were able to handle nontrivial condition-strings in 25237patterns with names, then it would be possible to use a 'define_insn' in 25238that case. Here is another case (zero-extension on the 68000) which 25239makes more use of the power of 'define_expand': 25240 25241 (define_expand "zero_extendhisi2" 25242 [(set (match_operand:SI 0 "general_operand" "") 25243 (const_int 0)) 25244 (set (strict_low_part 25245 (subreg:HI 25246 (match_dup 0) 25247 0)) 25248 (match_operand:HI 1 "general_operand" ""))] 25249 "" 25250 "operands[1] = make_safe_from (operands[1], operands[0]);") 25251 25252Here two RTL insns are generated, one to clear the entire output operand 25253and the other to copy the input operand into its low half. This 25254sequence is incorrect if the input operand refers to [the old value of] 25255the output operand, so the preparation statement makes sure this isn't 25256so. The function 'make_safe_from' copies the 'operands[1]' into a 25257temporary register if it refers to 'operands[0]'. It does this by 25258emitting another RTL insn. 25259 25260 Finally, a third example shows the use of an internal operand. 25261Zero-extension on the SPUR chip is done by 'and'-ing the result against 25262a halfword mask. But this mask cannot be represented by a 'const_int' 25263because the constant value is too large to be legitimate on this 25264machine. So it must be copied into a register with 'force_reg' and then 25265the register used in the 'and'. 25266 25267 (define_expand "zero_extendhisi2" 25268 [(set (match_operand:SI 0 "register_operand" "") 25269 (and:SI (subreg:SI 25270 (match_operand:HI 1 "register_operand" "") 25271 0) 25272 (match_dup 2)))] 25273 "" 25274 "operands[2] 25275 = force_reg (SImode, GEN_INT (65535)); ") 25276 25277 _Note:_ If the 'define_expand' is used to serve a standard binary or 25278unary arithmetic operation or a bit-field operation, then the last insn 25279it generates must not be a 'code_label', 'barrier' or 'note'. It must 25280be an 'insn', 'jump_insn' or 'call_insn'. If you don't need a real insn 25281at the end, emit an insn to copy the result of the operation into 25282itself. Such an insn will generate no code, but it can avoid problems 25283in the compiler. 25284 25285 25286File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 25287 2528816.16 Defining How to Split Instructions 25289======================================== 25290 25291There are two cases where you should specify how to split a pattern into 25292multiple insns. On machines that have instructions requiring delay 25293slots (*note Delay Slots::) or that have instructions whose output is 25294not available for multiple cycles (*note Processor pipeline 25295description::), the compiler phases that optimize these cases need to be 25296able to move insns into one-instruction delay slots. However, some 25297insns may generate more than one machine instruction. These insns 25298cannot be placed into a delay slot. 25299 25300 Often you can rewrite the single insn as a list of individual insns, 25301each corresponding to one machine instruction. The disadvantage of 25302doing so is that it will cause the compilation to be slower and require 25303more space. If the resulting insns are too complex, it may also 25304suppress some optimizations. The compiler splits the insn if there is a 25305reason to believe that it might improve instruction or delay slot 25306scheduling. 25307 25308 The insn combiner phase also splits putative insns. If three insns are 25309merged into one insn with a complex expression that cannot be matched by 25310some 'define_insn' pattern, the combiner phase attempts to split the 25311complex pattern into two insns that are recognized. Usually it can 25312break the complex pattern into two patterns by splitting out some 25313subexpression. However, in some other cases, such as performing an 25314addition of a large constant in two insns on a RISC machine, the way to 25315split the addition into two insns is machine-dependent. 25316 25317 The 'define_split' definition tells the compiler how to split a complex 25318insn into several simpler insns. It looks like this: 25319 25320 (define_split 25321 [INSN-PATTERN] 25322 "CONDITION" 25323 [NEW-INSN-PATTERN-1 25324 NEW-INSN-PATTERN-2 25325 ...] 25326 "PREPARATION-STATEMENTS") 25327 25328 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 25329final condition to be tested, as in a 'define_insn'. When an insn 25330matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 25331in the insn list with the insns given by NEW-INSN-PATTERN-1, 25332NEW-INSN-PATTERN-2, etc. 25333 25334 The PREPARATION-STATEMENTS are similar to those statements that are 25335specified for 'define_expand' (*note Expander Definitions::) and are 25336executed before the new RTL is generated to prepare for the generated 25337code or emit some insns whose pattern is not fixed. Unlike those in 25338'define_expand', however, these statements must not generate any new 25339pseudo-registers. Once reload has completed, they also must not 25340allocate any space in the stack frame. 25341 25342 Patterns are matched against INSN-PATTERN in two different 25343circumstances. If an insn needs to be split for delay slot scheduling 25344or insn scheduling, the insn is already known to be valid, which means 25345that it must have been matched by some 'define_insn' and, if 25346'reload_completed' is nonzero, is known to satisfy the constraints of 25347that 'define_insn'. In that case, the new insn patterns must also be 25348insns that are matched by some 'define_insn' and, if 'reload_completed' 25349is nonzero, must also satisfy the constraints of those definitions. 25350 25351 As an example of this usage of 'define_split', consider the following 25352example from 'a29k.md', which splits a 'sign_extend' from 'HImode' to 25353'SImode' into a pair of shift insns: 25354 25355 (define_split 25356 [(set (match_operand:SI 0 "gen_reg_operand" "") 25357 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 25358 "" 25359 [(set (match_dup 0) 25360 (ashift:SI (match_dup 1) 25361 (const_int 16))) 25362 (set (match_dup 0) 25363 (ashiftrt:SI (match_dup 0) 25364 (const_int 16)))] 25365 " 25366 { operands[1] = gen_lowpart (SImode, operands[1]); }") 25367 25368 When the combiner phase tries to split an insn pattern, it is always 25369the case that the pattern is _not_ matched by any 'define_insn'. The 25370combiner pass first tries to split a single 'set' expression and then 25371the same 'set' expression inside a 'parallel', but followed by a 25372'clobber' of a pseudo-reg to use as a scratch register. In these cases, 25373the combiner expects exactly two new insn patterns to be generated. It 25374will verify that these patterns match some 'define_insn' definitions, so 25375you need not do this test in the 'define_split' (of course, there is no 25376point in writing a 'define_split' that will never produce insns that 25377match). 25378 25379 Here is an example of this use of 'define_split', taken from 25380'rs6000.md': 25381 25382 (define_split 25383 [(set (match_operand:SI 0 "gen_reg_operand" "") 25384 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 25385 (match_operand:SI 2 "non_add_cint_operand" "")))] 25386 "" 25387 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 25388 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 25389 " 25390 { 25391 int low = INTVAL (operands[2]) & 0xffff; 25392 int high = (unsigned) INTVAL (operands[2]) >> 16; 25393 25394 if (low & 0x8000) 25395 high++, low |= 0xffff0000; 25396 25397 operands[3] = GEN_INT (high << 16); 25398 operands[4] = GEN_INT (low); 25399 }") 25400 25401 Here the predicate 'non_add_cint_operand' matches any 'const_int' that 25402is _not_ a valid operand of a single add insn. The add with the smaller 25403displacement is written so that it can be substituted into the address 25404of a subsequent operation. 25405 25406 An example that uses a scratch register, from the same file, generates 25407an equality comparison of a register and a large constant: 25408 25409 (define_split 25410 [(set (match_operand:CC 0 "cc_reg_operand" "") 25411 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 25412 (match_operand:SI 2 "non_short_cint_operand" ""))) 25413 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 25414 "find_single_use (operands[0], insn, 0) 25415 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 25416 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 25417 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 25418 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 25419 " 25420 { 25421 /* Get the constant we are comparing against, C, and see what it 25422 looks like sign-extended to 16 bits. Then see what constant 25423 could be XOR'ed with C to get the sign-extended value. */ 25424 25425 int c = INTVAL (operands[2]); 25426 int sextc = (c << 16) >> 16; 25427 int xorv = c ^ sextc; 25428 25429 operands[4] = GEN_INT (xorv); 25430 operands[5] = GEN_INT (sextc); 25431 }") 25432 25433 To avoid confusion, don't write a single 'define_split' that accepts 25434some insns that match some 'define_insn' as well as some insns that 25435don't. Instead, write two separate 'define_split' definitions, one for 25436the insns that are valid and one for the insns that are not valid. 25437 25438 The splitter is allowed to split jump instructions into sequence of 25439jumps or create new jumps in while splitting non-jump instructions. As 25440the central flowgraph and branch prediction information needs to be 25441updated, several restriction apply. 25442 25443 Splitting of jump instruction into sequence that over by another jump 25444instruction is always valid, as compiler expect identical behavior of 25445new jump. When new sequence contains multiple jump instructions or new 25446labels, more assistance is needed. Splitter is required to create only 25447unconditional jumps, or simple conditional jump instructions. 25448Additionally it must attach a 'REG_BR_PROB' note to each conditional 25449jump. A global variable 'split_branch_probability' holds the 25450probability of the original branch in case it was a simple conditional 25451jump, -1 otherwise. To simplify recomputing of edge frequencies, the 25452new sequence is required to have only forward jumps to the newly created 25453labels. 25454 25455 For the common case where the pattern of a define_split exactly matches 25456the pattern of a define_insn, use 'define_insn_and_split'. It looks 25457like this: 25458 25459 (define_insn_and_split 25460 [INSN-PATTERN] 25461 "CONDITION" 25462 "OUTPUT-TEMPLATE" 25463 "SPLIT-CONDITION" 25464 [NEW-INSN-PATTERN-1 25465 NEW-INSN-PATTERN-2 25466 ...] 25467 "PREPARATION-STATEMENTS" 25468 [INSN-ATTRIBUTES]) 25469 25470 25471 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 25472as in 'define_insn'. The NEW-INSN-PATTERN vector and the 25473PREPARATION-STATEMENTS are used as in a 'define_split'. The 25474SPLIT-CONDITION is also used as in 'define_split', with the additional 25475behavior that if the condition starts with '&&', the condition used for 25476the split will be the constructed as a logical "and" of the split 25477condition with the insn condition. For example, from i386.md: 25478 25479 (define_insn_and_split "zero_extendhisi2_and" 25480 [(set (match_operand:SI 0 "register_operand" "=r") 25481 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 25482 (clobber (reg:CC 17))] 25483 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 25484 "#" 25485 "&& reload_completed" 25486 [(parallel [(set (match_dup 0) 25487 (and:SI (match_dup 0) (const_int 65535))) 25488 (clobber (reg:CC 17))])] 25489 "" 25490 [(set_attr "type" "alu1")]) 25491 25492 25493 In this case, the actual split condition will be 25494'TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 25495 25496 The 'define_insn_and_split' construction provides exactly the same 25497functionality as two separate 'define_insn' and 'define_split' patterns. 25498It exists for compactness, and as a maintenance tool to prevent having 25499to ensure the two patterns' templates match. 25500 25501 25502File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 25503 2550416.17 Including Patterns in Machine Descriptions. 25505================================================= 25506 25507The 'include' pattern tells the compiler tools where to look for 25508patterns that are in files other than in the file '.md'. This is used 25509only at build time and there is no preprocessing allowed. 25510 25511 It looks like: 25512 25513 25514 (include 25515 PATHNAME) 25516 25517 For example: 25518 25519 25520 (include "filestuff") 25521 25522 25523 Where PATHNAME is a string that specifies the location of the file, 25524specifies the include file to be in 'gcc/config/target/filestuff'. The 25525directory 'gcc/config/target' is regarded as the default directory. 25526 25527 Machine descriptions may be split up into smaller more manageable 25528subsections and placed into subdirectories. 25529 25530 By specifying: 25531 25532 25533 (include "BOGUS/filestuff") 25534 25535 25536 the include file is specified to be in 25537'gcc/config/TARGET/BOGUS/filestuff'. 25538 25539 Specifying an absolute path for the include file such as; 25540 25541 (include "/u2/BOGUS/filestuff") 25542 25543 is permitted but is not encouraged. 25544 2554516.17.1 RTL Generation Tool Options for Directory Search 25546-------------------------------------------------------- 25547 25548The '-IDIR' option specifies directories to search for machine 25549descriptions. For example: 25550 25551 25552 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 25553 25554 25555 Add the directory DIR to the head of the list of directories to be 25556searched for header files. This can be used to override a system 25557machine definition file, substituting your own version, since these 25558directories are searched before the default machine description file 25559directories. If you use more than one '-I' option, the directories are 25560scanned in left-to-right order; the standard default directory come 25561after. 25562 25563 25564File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 25565 2556616.18 Machine-Specific Peephole Optimizers 25567========================================== 25568 25569In addition to instruction patterns the 'md' file may contain 25570definitions of machine-specific peephole optimizations. 25571 25572 The combiner does not notice certain peephole optimizations when the 25573data flow in the program does not suggest that it should try them. For 25574example, sometimes two consecutive insns related in purpose can be 25575combined even though the second one does not appear to use a register 25576computed in the first one. A machine-specific peephole optimizer can 25577detect such opportunities. 25578 25579 There are two forms of peephole definitions that may be used. The 25580original 'define_peephole' is run at assembly output time to match insns 25581and substitute assembly text. Use of 'define_peephole' is deprecated. 25582 25583 A newer 'define_peephole2' matches insns and substitutes new insns. 25584The 'peephole2' pass is run after register allocation but before 25585scheduling, which may result in much better code for targets that do 25586scheduling. 25587 25588* Menu: 25589 25590* define_peephole:: RTL to Text Peephole Optimizers 25591* define_peephole2:: RTL to RTL Peephole Optimizers 25592 25593 25594File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 25595 2559616.18.1 RTL to Text Peephole Optimizers 25597--------------------------------------- 25598 25599A definition looks like this: 25600 25601 (define_peephole 25602 [INSN-PATTERN-1 25603 INSN-PATTERN-2 25604 ...] 25605 "CONDITION" 25606 "TEMPLATE" 25607 "OPTIONAL-INSN-ATTRIBUTES") 25608 25609The last string operand may be omitted if you are not using any 25610machine-specific information in this machine description. If present, 25611it must obey the same rules as in a 'define_insn'. 25612 25613 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 25614consecutive insns. The optimization applies to a sequence of insns when 25615INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 25616and so on. 25617 25618 Each of the insns matched by a peephole must also match a 25619'define_insn'. Peepholes are checked only at the last stage just before 25620code generation, and only optionally. Therefore, any insn which would 25621match a peephole but no 'define_insn' will cause a crash in code 25622generation in an unoptimized compilation, or at various optimization 25623stages. 25624 25625 The operands of the insns are matched with 'match_operands', 25626'match_operator', and 'match_dup', as usual. What is not usual is that 25627the operand numbers apply to all the insn patterns in the definition. 25628So, you can check for identical operands in two insns by using 25629'match_operand' in one insn and 'match_dup' in the other. 25630 25631 The operand constraints used in 'match_operand' patterns do not have 25632any direct effect on the applicability of the peephole, but they will be 25633validated afterward, so make sure your constraints are general enough to 25634apply whenever the peephole matches. If the peephole matches but the 25635constraints are not satisfied, the compiler will crash. 25636 25637 It is safe to omit constraints in all the operands of the peephole; or 25638you can write constraints which serve as a double-check on the criteria 25639previously tested. 25640 25641 Once a sequence of insns matches the patterns, the CONDITION is 25642checked. This is a C expression which makes the final decision whether 25643to perform the optimization (we do so if the expression is nonzero). If 25644CONDITION is omitted (in other words, the string is empty) then the 25645optimization is applied to every sequence of insns that matches the 25646patterns. 25647 25648 The defined peephole optimizations are applied after register 25649allocation is complete. Therefore, the peephole definition can check 25650which operands have ended up in which kinds of registers, just by 25651looking at the operands. 25652 25653 The way to refer to the operands in CONDITION is to write 'operands[I]' 25654for operand number I (as matched by '(match_operand I ...)'). Use the 25655variable 'insn' to refer to the last of the insns being matched; use 25656'prev_active_insn' to find the preceding insns. 25657 25658 When optimizing computations with intermediate results, you can use 25659CONDITION to match only when the intermediate results are not used 25660elsewhere. Use the C expression 'dead_or_set_p (INSN, OP)', where INSN 25661is the insn in which you expect the value to be used for the last time 25662(from the value of 'insn', together with use of 'prev_nonnote_insn'), 25663and OP is the intermediate value (from 'operands[I]'). 25664 25665 Applying the optimization means replacing the sequence of insns with 25666one new insn. The TEMPLATE controls ultimate output of assembler code 25667for this combined insn. It works exactly like the template of a 25668'define_insn'. Operand numbers in this template are the same ones used 25669in matching the original sequence of insns. 25670 25671 The result of a defined peephole optimizer does not need to match any 25672of the insn patterns in the machine description; it does not even have 25673an opportunity to match them. The peephole optimizer definition itself 25674serves as the insn pattern to control how the insn is output. 25675 25676 Defined peephole optimizers are run as assembler code is being output, 25677so the insns they produce are never combined or rearranged in any way. 25678 25679 Here is an example, taken from the 68000 machine description: 25680 25681 (define_peephole 25682 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 25683 (set (match_operand:DF 0 "register_operand" "=f") 25684 (match_operand:DF 1 "register_operand" "ad"))] 25685 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 25686 { 25687 rtx xoperands[2]; 25688 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 25689 #ifdef MOTOROLA 25690 output_asm_insn ("move.l %1,(sp)", xoperands); 25691 output_asm_insn ("move.l %1,-(sp)", operands); 25692 return "fmove.d (sp)+,%0"; 25693 #else 25694 output_asm_insn ("movel %1,sp@", xoperands); 25695 output_asm_insn ("movel %1,sp@-", operands); 25696 return "fmoved sp@+,%0"; 25697 #endif 25698 }) 25699 25700 The effect of this optimization is to change 25701 25702 jbsr _foobar 25703 addql #4,sp 25704 movel d1,sp@- 25705 movel d0,sp@- 25706 fmoved sp@+,fp0 25707 25708into 25709 25710 jbsr _foobar 25711 movel d1,sp@ 25712 movel d0,sp@- 25713 fmoved sp@+,fp0 25714 25715 INSN-PATTERN-1 and so on look _almost_ like the second operand of 25716'define_insn'. There is one important difference: the second operand of 25717'define_insn' consists of one or more RTX's enclosed in square brackets. 25718Usually, there is only one: then the same action can be written as an 25719element of a 'define_peephole'. But when there are multiple actions in 25720a 'define_insn', they are implicitly enclosed in a 'parallel'. Then you 25721must explicitly write the 'parallel', and the square brackets within it, 25722in the 'define_peephole'. Thus, if an insn pattern looks like this, 25723 25724 (define_insn "divmodsi4" 25725 [(set (match_operand:SI 0 "general_operand" "=d") 25726 (div:SI (match_operand:SI 1 "general_operand" "0") 25727 (match_operand:SI 2 "general_operand" "dmsK"))) 25728 (set (match_operand:SI 3 "general_operand" "=d") 25729 (mod:SI (match_dup 1) (match_dup 2)))] 25730 "TARGET_68020" 25731 "divsl%.l %2,%3:%0") 25732 25733then the way to mention this insn in a peephole is as follows: 25734 25735 (define_peephole 25736 [... 25737 (parallel 25738 [(set (match_operand:SI 0 "general_operand" "=d") 25739 (div:SI (match_operand:SI 1 "general_operand" "0") 25740 (match_operand:SI 2 "general_operand" "dmsK"))) 25741 (set (match_operand:SI 3 "general_operand" "=d") 25742 (mod:SI (match_dup 1) (match_dup 2)))]) 25743 ...] 25744 ...) 25745 25746 25747File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 25748 2574916.18.2 RTL to RTL Peephole Optimizers 25750-------------------------------------- 25751 25752The 'define_peephole2' definition tells the compiler how to substitute 25753one sequence of instructions for another sequence, what additional 25754scratch registers may be needed and what their lifetimes must be. 25755 25756 (define_peephole2 25757 [INSN-PATTERN-1 25758 INSN-PATTERN-2 25759 ...] 25760 "CONDITION" 25761 [NEW-INSN-PATTERN-1 25762 NEW-INSN-PATTERN-2 25763 ...] 25764 "PREPARATION-STATEMENTS") 25765 25766 The definition is almost identical to 'define_split' (*note Insn 25767Splitting::) except that the pattern to match is not a single 25768instruction, but a sequence of instructions. 25769 25770 It is possible to request additional scratch registers for use in the 25771output template. If appropriate registers are not free, the pattern 25772will simply not match. 25773 25774 Scratch registers are requested with a 'match_scratch' pattern at the 25775top level of the input pattern. The allocated register (initially) will 25776be dead at the point requested within the original sequence. If the 25777scratch is used at more than a single point, a 'match_dup' pattern at 25778the top level of the input pattern marks the last position in the input 25779sequence at which the register must be available. 25780 25781 Here is an example from the IA-32 machine description: 25782 25783 (define_peephole2 25784 [(match_scratch:SI 2 "r") 25785 (parallel [(set (match_operand:SI 0 "register_operand" "") 25786 (match_operator:SI 3 "arith_or_logical_operator" 25787 [(match_dup 0) 25788 (match_operand:SI 1 "memory_operand" "")])) 25789 (clobber (reg:CC 17))])] 25790 "! optimize_size && ! TARGET_READ_MODIFY" 25791 [(set (match_dup 2) (match_dup 1)) 25792 (parallel [(set (match_dup 0) 25793 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 25794 (clobber (reg:CC 17))])] 25795 "") 25796 25797This pattern tries to split a load from its use in the hopes that we'll 25798be able to schedule around the memory load latency. It allocates a 25799single 'SImode' register of class 'GENERAL_REGS' ('"r"') that needs to 25800be live only at the point just before the arithmetic. 25801 25802 A real example requiring extended scratch lifetimes is harder to come 25803by, so here's a silly made-up example: 25804 25805 (define_peephole2 25806 [(match_scratch:SI 4 "r") 25807 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 25808 (set (match_operand:SI 2 "" "") (match_dup 1)) 25809 (match_dup 4) 25810 (set (match_operand:SI 3 "" "") (match_dup 1))] 25811 "/* determine 1 does not overlap 0 and 2 */" 25812 [(set (match_dup 4) (match_dup 1)) 25813 (set (match_dup 0) (match_dup 4)) 25814 (set (match_dup 2) (match_dup 4)) 25815 (set (match_dup 3) (match_dup 4))] 25816 "") 25817 25818If we had not added the '(match_dup 4)' in the middle of the input 25819sequence, it might have been the case that the register we chose at the 25820beginning of the sequence is killed by the first or second 'set'. 25821 25822 25823File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 25824 2582516.19 Instruction Attributes 25826============================ 25827 25828In addition to describing the instruction supported by the target 25829machine, the 'md' file also defines a group of "attributes" and a set of 25830values for each. Every generated insn is assigned a value for each 25831attribute. One possible attribute would be the effect that the insn has 25832on the machine's condition code. This attribute can then be used by 25833'NOTICE_UPDATE_CC' to track the condition codes. 25834 25835* Menu: 25836 25837* Defining Attributes:: Specifying attributes and their values. 25838* Expressions:: Valid expressions for attribute values. 25839* Tagging Insns:: Assigning attribute values to insns. 25840* Attr Example:: An example of assigning attributes. 25841* Insn Lengths:: Computing the length of insns. 25842* Constant Attributes:: Defining attributes that are constant. 25843* Mnemonic Attribute:: Obtain the instruction mnemonic as attribute value. 25844* Delay Slots:: Defining delay slots required for a machine. 25845* Processor pipeline description:: Specifying information for insn scheduling. 25846 25847 25848File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 25849 2585016.19.1 Defining Attributes and their Values 25851-------------------------------------------- 25852 25853The 'define_attr' expression is used to define each attribute required 25854by the target machine. It looks like: 25855 25856 (define_attr NAME LIST-OF-VALUES DEFAULT) 25857 25858 NAME is a string specifying the name of the attribute being defined. 25859Some attributes are used in a special way by the rest of the compiler. 25860The 'enabled' attribute can be used to conditionally enable or disable 25861insn alternatives (*note Disable Insn Alternatives::). The 'predicable' 25862attribute, together with a suitable 'define_cond_exec' (*note 25863Conditional Execution::), can be used to automatically generate 25864conditional variants of instruction patterns. The 'mnemonic' attribute 25865can be used to check for the instruction mnemonic (*note Mnemonic 25866Attribute::). The compiler internally uses the names 'ce_enabled' and 25867'nonce_enabled', so they should not be used elsewhere as alternative 25868names. 25869 25870 LIST-OF-VALUES is either a string that specifies a comma-separated list 25871of values that can be assigned to the attribute, or a null string to 25872indicate that the attribute takes numeric values. 25873 25874 DEFAULT is an attribute expression that gives the value of this 25875attribute for insns that match patterns whose definition does not 25876include an explicit value for this attribute. *Note Attr Example::, for 25877more information on the handling of defaults. *Note Constant 25878Attributes::, for information on attributes that do not depend on any 25879particular insn. 25880 25881 For each defined attribute, a number of definitions are written to the 25882'insn-attr.h' file. For cases where an explicit set of values is 25883specified for an attribute, the following are defined: 25884 25885 * A '#define' is written for the symbol 'HAVE_ATTR_NAME'. 25886 25887 * An enumerated class is defined for 'attr_NAME' with elements of the 25888 form 'UPPER-NAME_UPPER-VALUE' where the attribute name and value 25889 are first converted to uppercase. 25890 25891 * A function 'get_attr_NAME' is defined that is passed an insn and 25892 returns the attribute value for that insn. 25893 25894 For example, if the following is present in the 'md' file: 25895 25896 (define_attr "type" "branch,fp,load,store,arith" ...) 25897 25898the following lines will be written to the file 'insn-attr.h'. 25899 25900 #define HAVE_ATTR_type 1 25901 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 25902 TYPE_STORE, TYPE_ARITH}; 25903 extern enum attr_type get_attr_type (); 25904 25905 If the attribute takes numeric values, no 'enum' type will be defined 25906and the function to obtain the attribute's value will return 'int'. 25907 25908 There are attributes which are tied to a specific meaning. These 25909attributes are not free to use for other purposes: 25910 25911'length' 25912 The 'length' attribute is used to calculate the length of emitted 25913 code chunks. This is especially important when verifying branch 25914 distances. *Note Insn Lengths::. 25915 25916'enabled' 25917 The 'enabled' attribute can be defined to prevent certain 25918 alternatives of an insn definition from being used during code 25919 generation. *Note Disable Insn Alternatives::. 25920 25921'mnemonic' 25922 The 'mnemonic' attribute can be defined to implement instruction 25923 specific checks in e.g. the pipeline description. *Note Mnemonic 25924 Attribute::. 25925 25926 For each of these special attributes, the corresponding 25927'HAVE_ATTR_NAME' '#define' is also written when the attribute is not 25928defined; in that case, it is defined as '0'. 25929 25930 Another way of defining an attribute is to use: 25931 25932 (define_enum_attr "ATTR" "ENUM" DEFAULT) 25933 25934 This works in just the same way as 'define_attr', except that the list 25935of values is taken from a separate enumeration called ENUM (*note 25936define_enum::). This form allows you to use the same list of values for 25937several attributes without having to repeat the list each time. For 25938example: 25939 25940 (define_enum "processor" [ 25941 model_a 25942 model_b 25943 ... 25944 ]) 25945 (define_enum_attr "arch" "processor" 25946 (const (symbol_ref "target_arch"))) 25947 (define_enum_attr "tune" "processor" 25948 (const (symbol_ref "target_tune"))) 25949 25950 defines the same attributes as: 25951 25952 (define_attr "arch" "model_a,model_b,..." 25953 (const (symbol_ref "target_arch"))) 25954 (define_attr "tune" "model_a,model_b,..." 25955 (const (symbol_ref "target_tune"))) 25956 25957 but without duplicating the processor list. The second example defines 25958two separate C enums ('attr_arch' and 'attr_tune') whereas the first 25959defines a single C enum ('processor'). 25960 25961 25962File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 25963 2596416.19.2 Attribute Expressions 25965----------------------------- 25966 25967RTL expressions used to define attributes use the codes described above 25968plus a few specific to attribute definitions, to be discussed below. 25969Attribute value expressions must have one of the following forms: 25970 25971'(const_int I)' 25972 The integer I specifies the value of a numeric attribute. I must 25973 be non-negative. 25974 25975 The value of a numeric attribute can be specified either with a 25976 'const_int', or as an integer represented as a string in 25977 'const_string', 'eq_attr' (see below), 'attr', 'symbol_ref', simple 25978 arithmetic expressions, and 'set_attr' overrides on specific 25979 instructions (*note Tagging Insns::). 25980 25981'(const_string VALUE)' 25982 The string VALUE specifies a constant attribute value. If VALUE is 25983 specified as '"*"', it means that the default value of the 25984 attribute is to be used for the insn containing this expression. 25985 '"*"' obviously cannot be used in the DEFAULT expression of a 25986 'define_attr'. 25987 25988 If the attribute whose value is being specified is numeric, VALUE 25989 must be a string containing a non-negative integer (normally 25990 'const_int' would be used in this case). Otherwise, it must 25991 contain one of the valid values for the attribute. 25992 25993'(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 25994 TEST specifies an attribute test, whose format is defined below. 25995 The value of this expression is TRUE-VALUE if TEST is true, 25996 otherwise it is FALSE-VALUE. 25997 25998'(cond [TEST1 VALUE1 ...] DEFAULT)' 25999 The first operand of this expression is a vector containing an even 26000 number of expressions and consisting of pairs of TEST and VALUE 26001 expressions. The value of the 'cond' expression is that of the 26002 VALUE corresponding to the first true TEST expression. If none of 26003 the TEST expressions are true, the value of the 'cond' expression 26004 is that of the DEFAULT expression. 26005 26006 TEST expressions can have one of the following forms: 26007 26008'(const_int I)' 26009 This test is true if I is nonzero and false otherwise. 26010 26011'(not TEST)' 26012'(ior TEST1 TEST2)' 26013'(and TEST1 TEST2)' 26014 These tests are true if the indicated logical function is true. 26015 26016'(match_operand:M N PRED CONSTRAINTS)' 26017 This test is true if operand N of the insn whose attribute value is 26018 being determined has mode M (this part of the test is ignored if M 26019 is 'VOIDmode') and the function specified by the string PRED 26020 returns a nonzero value when passed operand N and mode M (this part 26021 of the test is ignored if PRED is the null string). 26022 26023 The CONSTRAINTS operand is ignored and should be the null string. 26024 26025'(match_test C-EXPR)' 26026 The test is true if C expression C-EXPR is true. In non-constant 26027 attributes, C-EXPR has access to the following variables: 26028 26029 INSN 26030 The rtl instruction under test. 26031 WHICH_ALTERNATIVE 26032 The 'define_insn' alternative that INSN matches. *Note Output 26033 Statement::. 26034 OPERANDS 26035 An array of INSN's rtl operands. 26036 26037 C-EXPR behaves like the condition in a C 'if' statement, so there 26038 is no need to explicitly convert the expression into a boolean 0 or 26039 1 value. For example, the following two tests are equivalent: 26040 26041 (match_test "x & 2") 26042 (match_test "(x & 2) != 0") 26043 26044'(le ARITH1 ARITH2)' 26045'(leu ARITH1 ARITH2)' 26046'(lt ARITH1 ARITH2)' 26047'(ltu ARITH1 ARITH2)' 26048'(gt ARITH1 ARITH2)' 26049'(gtu ARITH1 ARITH2)' 26050'(ge ARITH1 ARITH2)' 26051'(geu ARITH1 ARITH2)' 26052'(ne ARITH1 ARITH2)' 26053'(eq ARITH1 ARITH2)' 26054 These tests are true if the indicated comparison of the two 26055 arithmetic expressions is true. Arithmetic expressions are formed 26056 with 'plus', 'minus', 'mult', 'div', 'mod', 'abs', 'neg', 'and', 26057 'ior', 'xor', 'not', 'ashift', 'lshiftrt', and 'ashiftrt' 26058 expressions. 26059 26060 'const_int' and 'symbol_ref' are always valid terms (*note Insn 26061 Lengths::,for additional forms). 'symbol_ref' is a string denoting 26062 a C expression that yields an 'int' when evaluated by the 26063 'get_attr_...' routine. It should normally be a global variable. 26064 26065'(eq_attr NAME VALUE)' 26066 NAME is a string specifying the name of an attribute. 26067 26068 VALUE is a string that is either a valid value for attribute NAME, 26069 a comma-separated list of values, or '!' followed by a value or 26070 list. If VALUE does not begin with a '!', this test is true if the 26071 value of the NAME attribute of the current insn is in the list 26072 specified by VALUE. If VALUE begins with a '!', this test is true 26073 if the attribute's value is _not_ in the specified list. 26074 26075 For example, 26076 26077 (eq_attr "type" "load,store") 26078 26079 is equivalent to 26080 26081 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 26082 26083 If NAME specifies an attribute of 'alternative', it refers to the 26084 value of the compiler variable 'which_alternative' (*note Output 26085 Statement::) and the values must be small integers. For example, 26086 26087 (eq_attr "alternative" "2,3") 26088 26089 is equivalent to 26090 26091 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 26092 (eq (symbol_ref "which_alternative") (const_int 3))) 26093 26094 Note that, for most attributes, an 'eq_attr' test is simplified in 26095 cases where the value of the attribute being tested is known for 26096 all insns matching a particular pattern. This is by far the most 26097 common case. 26098 26099'(attr_flag NAME)' 26100 The value of an 'attr_flag' expression is true if the flag 26101 specified by NAME is true for the 'insn' currently being scheduled. 26102 26103 NAME is a string specifying one of a fixed set of flags to test. 26104 Test the flags 'forward' and 'backward' to determine the direction 26105 of a conditional branch. 26106 26107 This example describes a conditional branch delay slot which can be 26108 nullified for forward branches that are taken (annul-true) or for 26109 backward branches which are not taken (annul-false). 26110 26111 (define_delay (eq_attr "type" "cbranch") 26112 [(eq_attr "in_branch_delay" "true") 26113 (and (eq_attr "in_branch_delay" "true") 26114 (attr_flag "forward")) 26115 (and (eq_attr "in_branch_delay" "true") 26116 (attr_flag "backward"))]) 26117 26118 The 'forward' and 'backward' flags are false if the current 'insn' 26119 being scheduled is not a conditional branch. 26120 26121 'attr_flag' is only used during delay slot scheduling and has no 26122 meaning to other passes of the compiler. 26123 26124'(attr NAME)' 26125 The value of another attribute is returned. This is most useful 26126 for numeric attributes, as 'eq_attr' and 'attr_flag' produce more 26127 efficient code for non-numeric attributes. 26128 26129 26130File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 26131 2613216.19.3 Assigning Attribute Values to Insns 26133------------------------------------------- 26134 26135The value assigned to an attribute of an insn is primarily determined by 26136which pattern is matched by that insn (or which 'define_peephole' 26137generated it). Every 'define_insn' and 'define_peephole' can have an 26138optional last argument to specify the values of attributes for matching 26139insns. The value of any attribute not specified in a particular insn is 26140set to the default value for that attribute, as specified in its 26141'define_attr'. Extensive use of default values for attributes permits 26142the specification of the values for only one or two attributes in the 26143definition of most insn patterns, as seen in the example in the next 26144section. 26145 26146 The optional last argument of 'define_insn' and 'define_peephole' is a 26147vector of expressions, each of which defines the value for a single 26148attribute. The most general way of assigning an attribute's value is to 26149use a 'set' expression whose first operand is an 'attr' expression 26150giving the name of the attribute being set. The second operand of the 26151'set' is an attribute expression (*note Expressions::) giving the value 26152of the attribute. 26153 26154 When the attribute value depends on the 'alternative' attribute (i.e., 26155which is the applicable alternative in the constraint of the insn), the 26156'set_attr_alternative' expression can be used. It allows the 26157specification of a vector of attribute expressions, one for each 26158alternative. 26159 26160 When the generality of arbitrary attribute expressions is not required, 26161the simpler 'set_attr' expression can be used, which allows specifying a 26162string giving either a single attribute value or a list of attribute 26163values, one for each alternative. 26164 26165 The form of each of the above specifications is shown below. In each 26166case, NAME is a string specifying the attribute to be set. 26167 26168'(set_attr NAME VALUE-STRING)' 26169 VALUE-STRING is either a string giving the desired attribute value, 26170 or a string containing a comma-separated list giving the values for 26171 succeeding alternatives. The number of elements must match the 26172 number of alternatives in the constraint of the insn pattern. 26173 26174 Note that it may be useful to specify '*' for some alternative, in 26175 which case the attribute will assume its default value for insns 26176 matching that alternative. 26177 26178'(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 26179 Depending on the alternative of the insn, the value will be one of 26180 the specified values. This is a shorthand for using a 'cond' with 26181 tests on the 'alternative' attribute. 26182 26183'(set (attr NAME) VALUE)' 26184 The first operand of this 'set' must be the special RTL expression 26185 'attr', whose sole operand is a string giving the name of the 26186 attribute being set. VALUE is the value of the attribute. 26187 26188 The following shows three different ways of representing the same 26189attribute value specification: 26190 26191 (set_attr "type" "load,store,arith") 26192 26193 (set_attr_alternative "type" 26194 [(const_string "load") (const_string "store") 26195 (const_string "arith")]) 26196 26197 (set (attr "type") 26198 (cond [(eq_attr "alternative" "1") (const_string "load") 26199 (eq_attr "alternative" "2") (const_string "store")] 26200 (const_string "arith"))) 26201 26202 The 'define_asm_attributes' expression provides a mechanism to specify 26203the attributes assigned to insns produced from an 'asm' statement. It 26204has the form: 26205 26206 (define_asm_attributes [ATTR-SETS]) 26207 26208where ATTR-SETS is specified the same as for both the 'define_insn' and 26209the 'define_peephole' expressions. 26210 26211 These values will typically be the "worst case" attribute values. For 26212example, they might indicate that the condition code will be clobbered. 26213 26214 A specification for a 'length' attribute is handled specially. The way 26215to compute the length of an 'asm' insn is to multiply the length 26216specified in the expression 'define_asm_attributes' by the number of 26217machine instructions specified in the 'asm' statement, determined by 26218counting the number of semicolons and newlines in the string. 26219Therefore, the value of the 'length' attribute specified in a 26220'define_asm_attributes' should be the maximum possible length of a 26221single machine instruction. 26222 26223 26224File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 26225 2622616.19.4 Example of Attribute Specifications 26227------------------------------------------- 26228 26229The judicious use of defaulting is important in the efficient use of 26230insn attributes. Typically, insns are divided into "types" and an 26231attribute, customarily called 'type', is used to represent this value. 26232This attribute is normally used only to define the default value for 26233other attributes. An example will clarify this usage. 26234 26235 Assume we have a RISC machine with a condition code and in which only 26236full-word operations are performed in registers. Let us assume that we 26237can divide all insns into loads, stores, (integer) arithmetic 26238operations, floating point operations, and branches. 26239 26240 Here we will concern ourselves with determining the effect of an insn 26241on the condition code and will limit ourselves to the following possible 26242effects: The condition code can be set unpredictably (clobbered), not be 26243changed, be set to agree with the results of the operation, or only 26244changed if the item previously set into the condition code has been 26245modified. 26246 26247 Here is part of a sample 'md' file for such a machine: 26248 26249 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 26250 26251 (define_attr "cc" "clobber,unchanged,set,change0" 26252 (cond [(eq_attr "type" "load") 26253 (const_string "change0") 26254 (eq_attr "type" "store,branch") 26255 (const_string "unchanged") 26256 (eq_attr "type" "arith") 26257 (if_then_else (match_operand:SI 0 "" "") 26258 (const_string "set") 26259 (const_string "clobber"))] 26260 (const_string "clobber"))) 26261 26262 (define_insn "" 26263 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 26264 (match_operand:SI 1 "general_operand" "r,m,r"))] 26265 "" 26266 "@ 26267 move %0,%1 26268 load %0,%1 26269 store %0,%1" 26270 [(set_attr "type" "arith,load,store")]) 26271 26272 Note that we assume in the above example that arithmetic operations 26273performed on quantities smaller than a machine word clobber the 26274condition code since they will set the condition code to a value 26275corresponding to the full-word result. 26276 26277 26278File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 26279 2628016.19.5 Computing the Length of an Insn 26281--------------------------------------- 26282 26283For many machines, multiple types of branch instructions are provided, 26284each for different length branch displacements. In most cases, the 26285assembler will choose the correct instruction to use. However, when the 26286assembler cannot do so, GCC can when a special attribute, the 'length' 26287attribute, is defined. This attribute must be defined to have numeric 26288values by specifying a null string in its 'define_attr'. 26289 26290 In the case of the 'length' attribute, two additional forms of 26291arithmetic terms are allowed in test expressions: 26292 26293'(match_dup N)' 26294 This refers to the address of operand N of the current insn, which 26295 must be a 'label_ref'. 26296 26297'(pc)' 26298 For non-branch instructions and backward branch instructions, this 26299 refers to the address of the current insn. But for forward branch 26300 instructions, this refers to the address of the next insn, because 26301 the length of the current insn is to be computed. 26302 26303 For normal insns, the length will be determined by value of the 26304'length' attribute. In the case of 'addr_vec' and 'addr_diff_vec' insn 26305patterns, the length is computed as the number of vectors multiplied by 26306the size of each vector. 26307 26308 Lengths are measured in addressable storage units (bytes). 26309 26310 Note that it is possible to call functions via the 'symbol_ref' 26311mechanism to compute the length of an insn. However, if you use this 26312mechanism you must provide dummy clauses to express the maximum length 26313without using the function call. You can an example of this in the 'pa' 26314machine description for the 'call_symref' pattern. 26315 26316 The following macros can be used to refine the length computation: 26317 26318'ADJUST_INSN_LENGTH (INSN, LENGTH)' 26319 If defined, modifies the length assigned to instruction INSN as a 26320 function of the context in which it is used. LENGTH is an lvalue 26321 that contains the initially computed length of the insn and should 26322 be updated with the correct length of the insn. 26323 26324 This macro will normally not be required. A case in which it is 26325 required is the ROMP. On this machine, the size of an 'addr_vec' 26326 insn must be increased by two to compensate for the fact that 26327 alignment may be required. 26328 26329 The routine that returns 'get_attr_length' (the value of the 'length' 26330attribute) can be used by the output routine to determine the form of 26331the branch instruction to be written, as the example below illustrates. 26332 26333 As an example of the specification of variable-length branches, 26334consider the IBM 360. If we adopt the convention that a register will 26335be set to the starting address of a function, we can jump to labels 26336within 4k of the start using a four-byte instruction. Otherwise, we 26337need a six-byte sequence to load the address from memory and then branch 26338to it. 26339 26340 On such a machine, a pattern for a branch instruction might be 26341specified as follows: 26342 26343 (define_insn "jump" 26344 [(set (pc) 26345 (label_ref (match_operand 0 "" "")))] 26346 "" 26347 { 26348 return (get_attr_length (insn) == 4 26349 ? "b %l0" : "l r15,=a(%l0); br r15"); 26350 } 26351 [(set (attr "length") 26352 (if_then_else (lt (match_dup 0) (const_int 4096)) 26353 (const_int 4) 26354 (const_int 6)))]) 26355 26356 26357File: gccint.info, Node: Constant Attributes, Next: Mnemonic Attribute, Prev: Insn Lengths, Up: Insn Attributes 26358 2635916.19.6 Constant Attributes 26360--------------------------- 26361 26362A special form of 'define_attr', where the expression for the default 26363value is a 'const' expression, indicates an attribute that is constant 26364for a given run of the compiler. Constant attributes may be used to 26365specify which variety of processor is used. For example, 26366 26367 (define_attr "cpu" "m88100,m88110,m88000" 26368 (const 26369 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 26370 (symbol_ref "TARGET_88110") (const_string "m88110")] 26371 (const_string "m88000")))) 26372 26373 (define_attr "memory" "fast,slow" 26374 (const 26375 (if_then_else (symbol_ref "TARGET_FAST_MEM") 26376 (const_string "fast") 26377 (const_string "slow")))) 26378 26379 The routine generated for constant attributes has no parameters as it 26380does not depend on any particular insn. RTL expressions used to define 26381the value of a constant attribute may use the 'symbol_ref' form, but may 26382not use either the 'match_operand' form or 'eq_attr' forms involving 26383insn attributes. 26384 26385 26386File: gccint.info, Node: Mnemonic Attribute, Next: Delay Slots, Prev: Constant Attributes, Up: Insn Attributes 26387 2638816.19.7 Mnemonic Attribute 26389-------------------------- 26390 26391The 'mnemonic' attribute is a string type attribute holding the 26392instruction mnemonic for an insn alternative. The attribute values will 26393automatically be generated by the machine description parser if there is 26394an attribute definition in the md file: 26395 26396 (define_attr "mnemonic" "unknown" (const_string "unknown")) 26397 26398 The default value can be freely chosen as long as it does not collide 26399with any of the instruction mnemonics. This value will be used whenever 26400the machine description parser is not able to determine the mnemonic 26401string. This might be the case for output templates containing more 26402than a single instruction as in '"mvcle\t%0,%1,0\;jo\t.-4"'. 26403 26404 The 'mnemonic' attribute set is not generated automatically if the 26405instruction string is generated via C code. 26406 26407 An existing 'mnemonic' attribute set in an insn definition will not be 26408overriden by the md file parser. That way it is possible to manually 26409set the instruction mnemonics for the cases where the md file parser 26410fails to determine it automatically. 26411 26412 The 'mnemonic' attribute is useful for dealing with instruction 26413specific properties in the pipeline description without defining 26414additional insn attributes. 26415 26416 (define_attr "ooo_expanded" "" 26417 (cond [(eq_attr "mnemonic" "dlr,dsgr,d,dsgf,stam,dsgfr,dlgr") 26418 (const_int 1)] 26419 (const_int 0))) 26420 26421 26422File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Mnemonic Attribute, Up: Insn Attributes 26423 2642416.19.8 Delay Slot Scheduling 26425----------------------------- 26426 26427The insn attribute mechanism can be used to specify the requirements for 26428delay slots, if any, on a target machine. An instruction is said to 26429require a "delay slot" if some instructions that are physically after 26430the instruction are executed as if they were located before it. Classic 26431examples are branch and call instructions, which often execute the 26432following instruction before the branch or call is performed. 26433 26434 On some machines, conditional branch instructions can optionally 26435"annul" instructions in the delay slot. This means that the instruction 26436will not be executed for certain branch outcomes. Both instructions 26437that annul if the branch is true and instructions that annul if the 26438branch is false are supported. 26439 26440 Delay slot scheduling differs from instruction scheduling in that 26441determining whether an instruction needs a delay slot is dependent only 26442on the type of instruction being generated, not on data flow between the 26443instructions. See the next section for a discussion of data-dependent 26444instruction scheduling. 26445 26446 The requirement of an insn needing one or more delay slots is indicated 26447via the 'define_delay' expression. It has the following form: 26448 26449 (define_delay TEST 26450 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 26451 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 26452 ...]) 26453 26454 TEST is an attribute test that indicates whether this 'define_delay' 26455applies to a particular insn. If so, the number of required delay slots 26456is determined by the length of the vector specified as the second 26457argument. An insn placed in delay slot N must satisfy attribute test 26458DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 26459may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 26460specifies which insns in the delay slot may be annulled if the branch is 26461false. If annulling is not supported for that delay slot, '(nil)' 26462should be coded. 26463 26464 For example, in the common case where branch and call insns require a 26465single delay slot, which may contain any insn other than a branch or 26466call, the following would be placed in the 'md' file: 26467 26468 (define_delay (eq_attr "type" "branch,call") 26469 [(eq_attr "type" "!branch,call") (nil) (nil)]) 26470 26471 Multiple 'define_delay' expressions may be specified. In this case, 26472each such expression specifies different delay slot requirements and 26473there must be no insn for which tests in two 'define_delay' expressions 26474are both true. 26475 26476 For example, if we have a machine that requires one delay slot for 26477branches but two for calls, no delay slot can contain a branch or call 26478insn, and any valid insn in the delay slot for the branch can be 26479annulled if the branch is true, we might represent this as follows: 26480 26481 (define_delay (eq_attr "type" "branch") 26482 [(eq_attr "type" "!branch,call") 26483 (eq_attr "type" "!branch,call") 26484 (nil)]) 26485 26486 (define_delay (eq_attr "type" "call") 26487 [(eq_attr "type" "!branch,call") (nil) (nil) 26488 (eq_attr "type" "!branch,call") (nil) (nil)]) 26489 26490 26491File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 26492 2649316.19.9 Specifying processor pipeline description 26494------------------------------------------------- 26495 26496To achieve better performance, most modern processors (super-pipelined, 26497superscalar RISC, and VLIW processors) have many "functional units" on 26498which several instructions can be executed simultaneously. An 26499instruction starts execution if its issue conditions are satisfied. If 26500not, the instruction is stalled until its conditions are satisfied. 26501Such "interlock (pipeline) delay" causes interruption of the fetching of 26502successor instructions (or demands nop instructions, e.g. for some MIPS 26503processors). 26504 26505 There are two major kinds of interlock delays in modern processors. 26506The first one is a data dependence delay determining "instruction 26507latency time". The instruction execution is not started until all 26508source data have been evaluated by prior instructions (there are more 26509complex cases when the instruction execution starts even when the data 26510are not available but will be ready in given time after the instruction 26511execution start). Taking the data dependence delays into account is 26512simple. The data dependence (true, output, and anti-dependence) delay 26513between two instructions is given by a constant. In most cases this 26514approach is adequate. The second kind of interlock delays is a 26515reservation delay. The reservation delay means that two instructions 26516under execution will be in need of shared processors resources, i.e. 26517buses, internal registers, and/or functional units, which are reserved 26518for some time. Taking this kind of delay into account is complex 26519especially for modern RISC processors. 26520 26521 The task of exploiting more processor parallelism is solved by an 26522instruction scheduler. For a better solution to this problem, the 26523instruction scheduler has to have an adequate description of the 26524processor parallelism (or "pipeline description"). GCC machine 26525descriptions describe processor parallelism and functional unit 26526reservations for groups of instructions with the aid of "regular 26527expressions". 26528 26529 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 26530figure out the possibility of the instruction issue by the processor on 26531a given simulated processor cycle. The pipeline hazard recognizer is 26532automatically generated from the processor pipeline description. The 26533pipeline hazard recognizer generated from the machine description is 26534based on a deterministic finite state automaton (DFA): the instruction 26535issue is possible if there is a transition from one automaton state to 26536another one. This algorithm is very fast, and furthermore, its speed is 26537not dependent on processor complexity(1). 26538 26539 The rest of this section describes the directives that constitute an 26540automaton-based processor pipeline description. The order of these 26541constructions within the machine description file is not important. 26542 26543 The following optional construction describes names of automata 26544generated and used for the pipeline hazards recognition. Sometimes the 26545generated finite state automaton used by the pipeline hazard recognizer 26546is large. If we use more than one automaton and bind functional units 26547to the automata, the total size of the automata is usually less than the 26548size of the single automaton. If there is no one such construction, 26549only one finite state automaton is generated. 26550 26551 (define_automaton AUTOMATA-NAMES) 26552 26553 AUTOMATA-NAMES is a string giving names of the automata. The names are 26554separated by commas. All the automata should have unique names. The 26555automaton name is used in the constructions 'define_cpu_unit' and 26556'define_query_cpu_unit'. 26557 26558 Each processor functional unit used in the description of instruction 26559reservations should be described by the following construction. 26560 26561 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 26562 26563 UNIT-NAMES is a string giving the names of the functional units 26564separated by commas. Don't use name 'nothing', it is reserved for other 26565goals. 26566 26567 AUTOMATON-NAME is a string giving the name of the automaton with which 26568the unit is bound. The automaton should be described in construction 26569'define_automaton'. You should give "automaton-name", if there is a 26570defined automaton. 26571 26572 The assignment of units to automata are constrained by the uses of the 26573units in insn reservations. The most important constraint is: if a unit 26574reservation is present on a particular cycle of an alternative for an 26575insn reservation, then some unit from the same automaton must be present 26576on the same cycle for the other alternatives of the insn reservation. 26577The rest of the constraints are mentioned in the description of the 26578subsequent constructions. 26579 26580 The following construction describes CPU functional units analogously 26581to 'define_cpu_unit'. The reservation of such units can be queried for 26582an automaton state. The instruction scheduler never queries reservation 26583of functional units for given automaton state. So as a rule, you don't 26584need this construction. This construction could be used for future code 26585generation goals (e.g. to generate VLIW insn templates). 26586 26587 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 26588 26589 UNIT-NAMES is a string giving names of the functional units separated 26590by commas. 26591 26592 AUTOMATON-NAME is a string giving the name of the automaton with which 26593the unit is bound. 26594 26595 The following construction is the major one to describe pipeline 26596characteristics of an instruction. 26597 26598 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 26599 CONDITION REGEXP) 26600 26601 DEFAULT_LATENCY is a number giving latency time of the instruction. 26602There is an important difference between the old description and the 26603automaton based pipeline description. The latency time is used for all 26604dependencies when we use the old description. In the automaton based 26605pipeline description, the given latency time is only used for true 26606dependencies. The cost of anti-dependencies is always zero and the cost 26607of output dependencies is the difference between latency times of the 26608producing and consuming insns (if the difference is negative, the cost 26609is considered to be zero). You can always change the default costs for 26610any description by using the target hook 'TARGET_SCHED_ADJUST_COST' 26611(*note Scheduling::). 26612 26613 INSN-NAME is a string giving the internal name of the insn. The 26614internal names are used in constructions 'define_bypass' and in the 26615automaton description file generated for debugging. The internal name 26616has nothing in common with the names in 'define_insn'. It is a good 26617practice to use insn classes described in the processor manual. 26618 26619 CONDITION defines what RTL insns are described by this construction. 26620You should remember that you will be in trouble if CONDITION for two or 26621more different 'define_insn_reservation' constructions is TRUE for an 26622insn. In this case what reservation will be used for the insn is not 26623defined. Such cases are not checked during generation of the pipeline 26624hazards recognizer because in general recognizing that two conditions 26625may have the same value is quite difficult (especially if the conditions 26626contain 'symbol_ref'). It is also not checked during the pipeline 26627hazard recognizer work because it would slow down the recognizer 26628considerably. 26629 26630 REGEXP is a string describing the reservation of the cpu's functional 26631units by the instruction. The reservations are described by a regular 26632expression according to the following syntax: 26633 26634 regexp = regexp "," oneof 26635 | oneof 26636 26637 oneof = oneof "|" allof 26638 | allof 26639 26640 allof = allof "+" repeat 26641 | repeat 26642 26643 repeat = element "*" number 26644 | element 26645 26646 element = cpu_function_unit_name 26647 | reservation_name 26648 | result_name 26649 | "nothing" 26650 | "(" regexp ")" 26651 26652 * ',' is used for describing the start of the next cycle in the 26653 reservation. 26654 26655 * '|' is used for describing a reservation described by the first 26656 regular expression *or* a reservation described by the second 26657 regular expression *or* etc. 26658 26659 * '+' is used for describing a reservation described by the first 26660 regular expression *and* a reservation described by the second 26661 regular expression *and* etc. 26662 26663 * '*' is used for convenience and simply means a sequence in which 26664 the regular expression are repeated NUMBER times with cycle 26665 advancing (see ','). 26666 26667 * 'cpu_function_unit_name' denotes reservation of the named 26668 functional unit. 26669 26670 * 'reservation_name' -- see description of construction 26671 'define_reservation'. 26672 26673 * 'nothing' denotes no unit reservations. 26674 26675 Sometimes unit reservations for different insns contain common parts. 26676In such case, you can simplify the pipeline description by describing 26677the common part by the following construction 26678 26679 (define_reservation RESERVATION-NAME REGEXP) 26680 26681 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 26682names and reservation names are in the same name space. So the 26683reservation names should be different from the functional unit names and 26684can not be the reserved name 'nothing'. 26685 26686 The following construction is used to describe exceptions in the 26687latency time for given instruction pair. This is so called bypasses. 26688 26689 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 26690 [GUARD]) 26691 26692 NUMBER defines when the result generated by the instructions given in 26693string OUT_INSN_NAMES will be ready for the instructions given in string 26694IN_INSN_NAMES. Each of these strings is a comma-separated list of 26695filename-style globs and they refer to the names of 26696'define_insn_reservation's. For example: 26697 (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*") 26698 defines a bypass between instructions that start with 'cpu1_load_' or 26699'cpu1_store_' and those that start with 'cpu1_load_'. 26700 26701 GUARD is an optional string giving the name of a C function which 26702defines an additional guard for the bypass. The function will get the 26703two insns as parameters. If the function returns zero the bypass will 26704be ignored for this case. The additional guard is necessary to 26705recognize complicated bypasses, e.g. when the consumer is only an 26706address of insn 'store' (not a stored value). 26707 26708 If there are more one bypass with the same output and input insns, the 26709chosen bypass is the first bypass with a guard in description whose 26710guard function returns nonzero. If there is no such bypass, then bypass 26711without the guard function is chosen. 26712 26713 The following five constructions are usually used to describe VLIW 26714processors, or more precisely, to describe a placement of small 26715instructions into VLIW instruction slots. They can be used for RISC 26716processors, too. 26717 26718 (exclusion_set UNIT-NAMES UNIT-NAMES) 26719 (presence_set UNIT-NAMES PATTERNS) 26720 (final_presence_set UNIT-NAMES PATTERNS) 26721 (absence_set UNIT-NAMES PATTERNS) 26722 (final_absence_set UNIT-NAMES PATTERNS) 26723 26724 UNIT-NAMES is a string giving names of functional units separated by 26725commas. 26726 26727 PATTERNS is a string giving patterns of functional units separated by 26728comma. Currently pattern is one unit or units separated by 26729white-spaces. 26730 26731 The first construction ('exclusion_set') means that each functional 26732unit in the first string can not be reserved simultaneously with a unit 26733whose name is in the second string and vice versa. For example, the 26734construction is useful for describing processors (e.g. some SPARC 26735processors) with a fully pipelined floating point functional unit which 26736can execute simultaneously only single floating point insns or only 26737double floating point insns. 26738 26739 The second construction ('presence_set') means that each functional 26740unit in the first string can not be reserved unless at least one of 26741pattern of units whose names are in the second string is reserved. This 26742is an asymmetric relation. For example, it is useful for description 26743that VLIW 'slot1' is reserved after 'slot0' reservation. We could 26744describe it by the following construction 26745 26746 (presence_set "slot1" "slot0") 26747 26748 Or 'slot1' is reserved only after 'slot0' and unit 'b0' reservation. 26749In this case we could write 26750 26751 (presence_set "slot1" "slot0 b0") 26752 26753 The third construction ('final_presence_set') is analogous to 26754'presence_set'. The difference between them is when checking is done. 26755When an instruction is issued in given automaton state reflecting all 26756current and planned unit reservations, the automaton state is changed. 26757The first state is a source state, the second one is a result state. 26758Checking for 'presence_set' is done on the source state reservation, 26759checking for 'final_presence_set' is done on the result reservation. 26760This construction is useful to describe a reservation which is actually 26761two subsequent reservations. For example, if we use 26762 26763 (presence_set "slot1" "slot0") 26764 26765 the following insn will be never issued (because 'slot1' requires 26766'slot0' which is absent in the source state). 26767 26768 (define_reservation "insn_and_nop" "slot0 + slot1") 26769 26770 but it can be issued if we use analogous 'final_presence_set'. 26771 26772 The forth construction ('absence_set') means that each functional unit 26773in the first string can be reserved only if each pattern of units whose 26774names are in the second string is not reserved. This is an asymmetric 26775relation (actually 'exclusion_set' is analogous to this one but it is 26776symmetric). For example it might be useful in a VLIW description to say 26777that 'slot0' cannot be reserved after either 'slot1' or 'slot2' have 26778been reserved. This can be described as: 26779 26780 (absence_set "slot0" "slot1, slot2") 26781 26782 Or 'slot2' can not be reserved if 'slot0' and unit 'b0' are reserved or 26783'slot1' and unit 'b1' are reserved. In this case we could write 26784 26785 (absence_set "slot2" "slot0 b0, slot1 b1") 26786 26787 All functional units mentioned in a set should belong to the same 26788automaton. 26789 26790 The last construction ('final_absence_set') is analogous to 26791'absence_set' but checking is done on the result (state) reservation. 26792See comments for 'final_presence_set'. 26793 26794 You can control the generator of the pipeline hazard recognizer with 26795the following construction. 26796 26797 (automata_option OPTIONS) 26798 26799 OPTIONS is a string giving options which affect the generated code. 26800Currently there are the following options: 26801 26802 * "no-minimization" makes no minimization of the automaton. This is 26803 only worth to do when we are debugging the description and need to 26804 look more accurately at reservations of states. 26805 26806 * "time" means printing time statistics about the generation of 26807 automata. 26808 26809 * "stats" means printing statistics about the generated automata such 26810 as the number of DFA states, NDFA states and arcs. 26811 26812 * "v" means a generation of the file describing the result automata. 26813 The file has suffix '.dfa' and can be used for the description 26814 verification and debugging. 26815 26816 * "w" means a generation of warning instead of error for non-critical 26817 errors. 26818 26819 * "no-comb-vect" prevents the automaton generator from generating two 26820 data structures and comparing them for space efficiency. Using a 26821 comb vector to represent transitions may be better, but it can be 26822 very expensive to construct. This option is useful if the build 26823 process spends an unacceptably long time in genautomata. 26824 26825 * "ndfa" makes nondeterministic finite state automata. This affects 26826 the treatment of operator '|' in the regular expressions. The 26827 usual treatment of the operator is to try the first alternative 26828 and, if the reservation is not possible, the second alternative. 26829 The nondeterministic treatment means trying all alternatives, some 26830 of them may be rejected by reservations in the subsequent insns. 26831 26832 * "collapse-ndfa" modifies the behavior of the generator when 26833 producing an automaton. An additional state transition to collapse 26834 a nondeterministic NDFA state to a deterministic DFA state is 26835 generated. It can be triggered by passing 'const0_rtx' to 26836 state_transition. In such an automaton, cycle advance transitions 26837 are available only for these collapsed states. This option is 26838 useful for ports that want to use the 'ndfa' option, but also want 26839 to use 'define_query_cpu_unit' to assign units to insns issued in a 26840 cycle. 26841 26842 * "progress" means output of a progress bar showing how many states 26843 were generated so far for automaton being processed. This is 26844 useful during debugging a DFA description. If you see too many 26845 generated states, you could interrupt the generator of the pipeline 26846 hazard recognizer and try to figure out a reason for generation of 26847 the huge automaton. 26848 26849 As an example, consider a superscalar RISC machine which can issue 26850three insns (two integer insns and one floating point insn) on the cycle 26851but can finish only two insns. To describe this, we define the 26852following functional units. 26853 26854 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 26855 (define_cpu_unit "port0, port1") 26856 26857 All simple integer insns can be executed in any integer pipeline and 26858their result is ready in two cycles. The simple integer insns are 26859issued into the first pipeline unless it is reserved, otherwise they are 26860issued into the second pipeline. Integer division and multiplication 26861insns can be executed only in the second integer pipeline and their 26862results are ready correspondingly in 8 and 4 cycles. The integer 26863division is not pipelined, i.e. the subsequent integer division insn can 26864not be issued until the current division insn finished. Floating point 26865insns are fully pipelined and their results are ready in 3 cycles. 26866Where the result of a floating point insn is used by an integer insn, an 26867additional delay of one cycle is incurred. To describe all of this we 26868could specify 26869 26870 (define_cpu_unit "div") 26871 26872 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 26873 "(i0_pipeline | i1_pipeline), (port0 | port1)") 26874 26875 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 26876 "i1_pipeline, nothing*2, (port0 | port1)") 26877 26878 (define_insn_reservation "div" 8 (eq_attr "type" "div") 26879 "i1_pipeline, div*7, div + (port0 | port1)") 26880 26881 (define_insn_reservation "float" 3 (eq_attr "type" "float") 26882 "f_pipeline, nothing, (port0 | port1)) 26883 26884 (define_bypass 4 "float" "simple,mult,div") 26885 26886 To simplify the description we could describe the following reservation 26887 26888 (define_reservation "finish" "port0|port1") 26889 26890 and use it in all 'define_insn_reservation' as in the following 26891construction 26892 26893 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 26894 "(i0_pipeline | i1_pipeline), finish") 26895 26896 ---------- Footnotes ---------- 26897 26898 (1) However, the size of the automaton depends on processor 26899complexity. To limit this effect, machine descriptions can split 26900orthogonal parts of the machine description among several automata: but 26901then, since each of these must be stepped independently, this does cause 26902a small decrease in the algorithm's performance. 26903 26904 26905File: gccint.info, Node: Conditional Execution, Next: Define Subst, Prev: Insn Attributes, Up: Machine Desc 26906 2690716.20 Conditional Execution 26908=========================== 26909 26910A number of architectures provide for some form of conditional 26911execution, or predication. The hallmark of this feature is the ability 26912to nullify most of the instructions in the instruction set. When the 26913instruction set is large and not entirely symmetric, it can be quite 26914tedious to describe these forms directly in the '.md' file. An 26915alternative is the 'define_cond_exec' template. 26916 26917 (define_cond_exec 26918 [PREDICATE-PATTERN] 26919 "CONDITION" 26920 "OUTPUT-TEMPLATE" 26921 "OPTIONAL-INSN-ATTRIBUES") 26922 26923 PREDICATE-PATTERN is the condition that must be true for the insn to be 26924executed at runtime and should match a relational operator. One can use 26925'match_operator' to match several relational operators at once. Any 26926'match_operand' operands must have no more than one alternative. 26927 26928 CONDITION is a C expression that must be true for the generated pattern 26929to match. 26930 26931 OUTPUT-TEMPLATE is a string similar to the 'define_insn' output 26932template (*note Output Template::), except that the '*' and '@' special 26933cases do not apply. This is only useful if the assembly text for the 26934predicate is a simple prefix to the main insn. In order to handle the 26935general case, there is a global variable 'current_insn_predicate' that 26936will contain the entire predicate if the current insn is predicated, and 26937will otherwise be 'NULL'. 26938 26939 OPTIONAL-INSN-ATTRIBUTES is an optional vector of attributes that gets 26940appended to the insn attributes of the produced cond_exec rtx. It can 26941be used to add some distinguishing attribute to cond_exec rtxs produced 26942that way. An example usage would be to use this attribute in 26943conjunction with attributes on the main pattern to disable particular 26944alternatives under certain conditions. 26945 26946 When 'define_cond_exec' is used, an implicit reference to the 26947'predicable' instruction attribute is made. *Note Insn Attributes::. 26948This attribute must be a boolean (i.e. have exactly two elements in its 26949LIST-OF-VALUES), with the possible values being 'no' and 'yes'. The 26950default and all uses in the insns must be a simple constant, not a 26951complex expressions. It may, however, depend on the alternative, by 26952using a comma-separated list of values. If that is the case, the port 26953should also define an 'enabled' attribute (*note Disable Insn 26954Alternatives::), which should also allow only 'no' and 'yes' as its 26955values. 26956 26957 For each 'define_insn' for which the 'predicable' attribute is true, a 26958new 'define_insn' pattern will be generated that matches a predicated 26959version of the instruction. For example, 26960 26961 (define_insn "addsi" 26962 [(set (match_operand:SI 0 "register_operand" "r") 26963 (plus:SI (match_operand:SI 1 "register_operand" "r") 26964 (match_operand:SI 2 "register_operand" "r")))] 26965 "TEST1" 26966 "add %2,%1,%0") 26967 26968 (define_cond_exec 26969 [(ne (match_operand:CC 0 "register_operand" "c") 26970 (const_int 0))] 26971 "TEST2" 26972 "(%0)") 26973 26974generates a new pattern 26975 26976 (define_insn "" 26977 [(cond_exec 26978 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 26979 (set (match_operand:SI 0 "register_operand" "r") 26980 (plus:SI (match_operand:SI 1 "register_operand" "r") 26981 (match_operand:SI 2 "register_operand" "r"))))] 26982 "(TEST2) && (TEST1)" 26983 "(%3) add %2,%1,%0") 26984 26985 26986File: gccint.info, Node: Define Subst, Next: Constant Definitions, Prev: Conditional Execution, Up: Machine Desc 26987 2698816.21 RTL Templates Transformations 26989=================================== 26990 26991For some hardware architectures there are common cases when the RTL 26992templates for the instructions can be derived from the other RTL 26993templates using simple transformations. E.g., 'i386.md' contains an RTL 26994template for the ordinary 'sub' instruction-- '*subsi_1', and for the 26995'sub' instruction with subsequent zero-extension--'*subsi_1_zext'. Such 26996cases can be easily implemented by a single meta-template capable of 26997generating a modified case based on the initial one: 26998 26999 (define_subst "NAME" 27000 [INPUT-TEMPLATE] 27001 "CONDITION" 27002 [OUTPUT-TEMPLATE]) 27003 INPUT-TEMPLATE is a pattern describing the source RTL template, which 27004will be transformed. 27005 27006 CONDITION is a C expression that is conjunct with the condition from 27007the input-template to generate a condition to be used in the 27008output-template. 27009 27010 OUTPUT-TEMPLATE is a pattern that will be used in the resulting 27011template. 27012 27013 'define_subst' mechanism is tightly coupled with the notion of the 27014subst attribute (*note Subst Iterators::). The use of 'define_subst' is 27015triggered by a reference to a subst attribute in the transforming RTL 27016template. This reference initiates duplication of the source RTL 27017template and substitution of the attributes with their values. The 27018source RTL template is left unchanged, while the copy is transformed by 27019'define_subst'. This transformation can fail in the case when the 27020source RTL template is not matched against the input-template of the 27021'define_subst'. In such case the copy is deleted. 27022 27023 'define_subst' can be used only in 'define_insn' and 'define_expand', 27024it cannot be used in other expressions (e.g. in 27025'define_insn_and_split'). 27026 27027* Menu: 27028 27029* Define Subst Example:: Example of 'define_subst' work. 27030* Define Subst Pattern Matching:: Process of template comparison. 27031* Define Subst Output Template:: Generation of output template. 27032 27033 27034File: gccint.info, Node: Define Subst Example, Next: Define Subst Pattern Matching, Up: Define Subst 27035 2703616.21.1 'define_subst' Example 27037------------------------------ 27038 27039To illustrate how 'define_subst' works, let us examine a simple template 27040transformation. 27041 27042 Suppose there are two kinds of instructions: one that touches flags and 27043the other that does not. The instructions of the second type could be 27044generated with the following 'define_subst': 27045 27046 (define_subst "add_clobber_subst" 27047 [(set (match_operand:SI 0 "" "") 27048 (match_operand:SI 1 "" ""))] 27049 "" 27050 [(set (match_dup 0) 27051 (match_dup 1)) 27052 (clobber (reg:CC FLAGS_REG))] 27053 27054 This 'define_subst' can be applied to any RTL pattern containing 'set' 27055of mode SI and generates a copy with clobber when it is applied. 27056 27057 Assume there is an RTL template for a 'max' instruction to be used in 27058'define_subst' mentioned above: 27059 27060 (define_insn "maxsi" 27061 [(set (match_operand:SI 0 "register_operand" "=r") 27062 (max:SI 27063 (match_operand:SI 1 "register_operand" "r") 27064 (match_operand:SI 2 "register_operand" "r")))] 27065 "" 27066 "max\t{%2, %1, %0|%0, %1, %2}" 27067 [...]) 27068 27069 To mark the RTL template for 'define_subst' application, 27070subst-attributes are used. They should be declared in advance: 27071 27072 (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber") 27073 27074 Here 'add_clobber_name' is the attribute name, 'add_clobber_subst' is 27075the name of the corresponding 'define_subst', the third argument 27076('_noclobber') is the attribute value that would be substituted into the 27077unchanged version of the source RTL template, and the last argument 27078('_clobber') is the value that would be substituted into the second, 27079transformed, version of the RTL template. 27080 27081 Once the subst-attribute has been defined, it should be used in RTL 27082templates which need to be processed by the 'define_subst'. So, the 27083original RTL template should be changed: 27084 27085 (define_insn "maxsi<add_clobber_name>" 27086 [(set (match_operand:SI 0 "register_operand" "=r") 27087 (max:SI 27088 (match_operand:SI 1 "register_operand" "r") 27089 (match_operand:SI 2 "register_operand" "r")))] 27090 "" 27091 "max\t{%2, %1, %0|%0, %1, %2}" 27092 [...]) 27093 27094 The result of the 'define_subst' usage would look like the following: 27095 27096 (define_insn "maxsi_noclobber" 27097 [(set (match_operand:SI 0 "register_operand" "=r") 27098 (max:SI 27099 (match_operand:SI 1 "register_operand" "r") 27100 (match_operand:SI 2 "register_operand" "r")))] 27101 "" 27102 "max\t{%2, %1, %0|%0, %1, %2}" 27103 [...]) 27104 (define_insn "maxsi_clobber" 27105 [(set (match_operand:SI 0 "register_operand" "=r") 27106 (max:SI 27107 (match_operand:SI 1 "register_operand" "r") 27108 (match_operand:SI 2 "register_operand" "r"))) 27109 (clobber (reg:CC FLAGS_REG))] 27110 "" 27111 "max\t{%2, %1, %0|%0, %1, %2}" 27112 [...]) 27113 27114 27115File: gccint.info, Node: Define Subst Pattern Matching, Next: Define Subst Output Template, Prev: Define Subst Example, Up: Define Subst 27116 2711716.21.2 Pattern Matching in 'define_subst' 27118------------------------------------------ 27119 27120All expressions, allowed in 'define_insn' or 'define_expand', are 27121allowed in the input-template of 'define_subst', except 'match_par_dup', 27122'match_scratch', 'match_parallel'. The meanings of expressions in the 27123input-template were changed: 27124 27125 'match_operand' matches any expression (possibly, a subtree in 27126RTL-template), if modes of the 'match_operand' and this expression are 27127the same, or mode of the 'match_operand' is 'VOIDmode', or this 27128expression is 'match_dup', 'match_op_dup'. If the expression is 27129'match_operand' too, and predicate of 'match_operand' from the input 27130pattern is not empty, then the predicates are compared. That can be 27131used for more accurate filtering of accepted RTL-templates. 27132 27133 'match_operator' matches common operators (like 'plus', 'minus'), 27134'unspec', 'unspec_volatile' operators and 'match_operator's from the 27135original pattern if the modes match and 'match_operator' from the input 27136pattern has the same number of operands as the operator from the 27137original pattern. 27138 27139 27140File: gccint.info, Node: Define Subst Output Template, Prev: Define Subst Pattern Matching, Up: Define Subst 27141 2714216.21.3 Generation of output template in 'define_subst' 27143------------------------------------------------------- 27144 27145If all necessary checks for 'define_subst' application pass, a new 27146RTL-pattern, based on the output-template, is created to replace the old 27147template. Like in input-patterns, meanings of some RTL expressions are 27148changed when they are used in output-patterns of a 'define_subst'. 27149Thus, 'match_dup' is used for copying the whole expression from the 27150original pattern, which matched corresponding 'match_operand' from the 27151input pattern. 27152 27153 'match_dup N' is used in the output template to be replaced with the 27154expression from the original pattern, which matched 'match_operand N' 27155from the input pattern. As a consequence, 'match_dup' cannot be used to 27156point to 'match_operand's from the output pattern, it should always 27157refer to a 'match_operand' from the input pattern. 27158 27159 In the output template one can refer to the expressions from the 27160original pattern and create new ones. For instance, some operands could 27161be added by means of standard 'match_operand'. 27162 27163 After replacing 'match_dup' with some RTL-subtree from the original 27164pattern, it could happen that several 'match_operand's in the output 27165pattern have the same indexes. It is unknown, how many and what indexes 27166would be used in the expression which would replace 'match_dup', so such 27167conflicts in indexes are inevitable. To overcome this issue, 27168'match_operands' and 'match_operators', which were introduced into the 27169output pattern, are renumerated when all 'match_dup's are replaced. 27170 27171 Number of alternatives in 'match_operand's introduced into the output 27172template 'M' could differ from the number of alternatives in the 27173original pattern 'N', so in the resultant pattern there would be 'N*M' 27174alternatives. Thus, constraints from the original pattern would be 27175duplicated 'N' times, constraints from the output pattern would be 27176duplicated 'M' times, producing all possible combinations. 27177 27178 27179File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Define Subst, Up: Machine Desc 27180 2718116.22 Constant Definitions 27182========================== 27183 27184Using literal constants inside instruction patterns reduces legibility 27185and can be a maintenance problem. 27186 27187 To overcome this problem, you may use the 'define_constants' 27188expression. It contains a vector of name-value pairs. From that point 27189on, wherever any of the names appears in the MD file, it is as if the 27190corresponding value had been written instead. You may use 27191'define_constants' multiple times; each appearance adds more constants 27192to the table. It is an error to redefine a constant with a different 27193value. 27194 27195 To come back to the a29k load multiple example, instead of 27196 27197 (define_insn "" 27198 [(match_parallel 0 "load_multiple_operation" 27199 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 27200 (match_operand:SI 2 "memory_operand" "m")) 27201 (use (reg:SI 179)) 27202 (clobber (reg:SI 179))])] 27203 "" 27204 "loadm 0,0,%1,%2") 27205 27206 You could write: 27207 27208 (define_constants [ 27209 (R_BP 177) 27210 (R_FC 178) 27211 (R_CR 179) 27212 (R_Q 180) 27213 ]) 27214 27215 (define_insn "" 27216 [(match_parallel 0 "load_multiple_operation" 27217 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 27218 (match_operand:SI 2 "memory_operand" "m")) 27219 (use (reg:SI R_CR)) 27220 (clobber (reg:SI R_CR))])] 27221 "" 27222 "loadm 0,0,%1,%2") 27223 27224 The constants that are defined with a define_constant are also output 27225in the insn-codes.h header file as #defines. 27226 27227 You can also use the machine description file to define enumerations. 27228Like the constants defined by 'define_constant', these enumerations are 27229visible to both the machine description file and the main C code. 27230 27231 The syntax is as follows: 27232 27233 (define_c_enum "NAME" [ 27234 VALUE0 27235 VALUE1 27236 ... 27237 VALUEN 27238 ]) 27239 27240 This definition causes the equivalent of the following C code to appear 27241in 'insn-constants.h': 27242 27243 enum NAME { 27244 VALUE0 = 0, 27245 VALUE1 = 1, 27246 ... 27247 VALUEN = N 27248 }; 27249 #define NUM_CNAME_VALUES (N + 1) 27250 27251 where CNAME is the capitalized form of NAME. It also makes each VALUEI 27252available in the machine description file, just as if it had been 27253declared with: 27254 27255 (define_constants [(VALUEI I)]) 27256 27257 Each VALUEI is usually an upper-case identifier and usually begins with 27258CNAME. 27259 27260 You can split the enumeration definition into as many statements as you 27261like. The above example is directly equivalent to: 27262 27263 (define_c_enum "NAME" [VALUE0]) 27264 (define_c_enum "NAME" [VALUE1]) 27265 ... 27266 (define_c_enum "NAME" [VALUEN]) 27267 27268 Splitting the enumeration helps to improve the modularity of each 27269individual '.md' file. For example, if a port defines its 27270synchronization instructions in a separate 'sync.md' file, it is 27271convenient to define all synchronization-specific enumeration values in 27272'sync.md' rather than in the main '.md' file. 27273 27274 Some enumeration names have special significance to GCC: 27275 27276'unspecv' 27277 If an enumeration called 'unspecv' is defined, GCC will use it when 27278 printing out 'unspec_volatile' expressions. For example: 27279 27280 (define_c_enum "unspecv" [ 27281 UNSPECV_BLOCKAGE 27282 ]) 27283 27284 causes GCC to print '(unspec_volatile ... 0)' as: 27285 27286 (unspec_volatile ... UNSPECV_BLOCKAGE) 27287 27288'unspec' 27289 If an enumeration called 'unspec' is defined, GCC will use it when 27290 printing out 'unspec' expressions. GCC will also use it when 27291 printing out 'unspec_volatile' expressions unless an 'unspecv' 27292 enumeration is also defined. You can therefore decide whether to 27293 keep separate enumerations for volatile and non-volatile 27294 expressions or whether to use the same enumeration for both. 27295 27296 Another way of defining an enumeration is to use 'define_enum': 27297 27298 (define_enum "NAME" [ 27299 VALUE0 27300 VALUE1 27301 ... 27302 VALUEN 27303 ]) 27304 27305 This directive implies: 27306 27307 (define_c_enum "NAME" [ 27308 CNAME_CVALUE0 27309 CNAME_CVALUE1 27310 ... 27311 CNAME_CVALUEN 27312 ]) 27313 27314 where CVALUEI is the capitalized form of VALUEI. However, unlike 27315'define_c_enum', the enumerations defined by 'define_enum' can be used 27316in attribute specifications (*note define_enum_attr::). 27317 27318 27319File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc 27320 2732116.23 Iterators 27322=============== 27323 27324Ports often need to define similar patterns for more than one machine 27325mode or for more than one rtx code. GCC provides some simple iterator 27326facilities to make this process easier. 27327 27328* Menu: 27329 27330* Mode Iterators:: Generating variations of patterns for different modes. 27331* Code Iterators:: Doing the same for codes. 27332* Int Iterators:: Doing the same for integers. 27333* Subst Iterators:: Generating variations of patterns for define_subst. 27334 27335 27336File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators 27337 2733816.23.1 Mode Iterators 27339---------------------- 27340 27341Ports often need to define similar patterns for two or more different 27342modes. For example: 27343 27344 * If a processor has hardware support for both single and double 27345 floating-point arithmetic, the 'SFmode' patterns tend to be very 27346 similar to the 'DFmode' ones. 27347 27348 * If a port uses 'SImode' pointers in one configuration and 'DImode' 27349 pointers in another, it will usually have very similar 'SImode' and 27350 'DImode' patterns for manipulating pointers. 27351 27352 Mode iterators allow several patterns to be instantiated from one '.md' 27353file template. They can be used with any type of rtx-based construct, 27354such as a 'define_insn', 'define_split', or 'define_peephole2'. 27355 27356* Menu: 27357 27358* Defining Mode Iterators:: Defining a new mode iterator. 27359* Substitutions:: Combining mode iterators with substitutions 27360* Examples:: Examples 27361 27362 27363File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators 27364 2736516.23.1.1 Defining Mode Iterators 27366................................. 27367 27368The syntax for defining a mode iterator is: 27369 27370 (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 27371 27372 This allows subsequent '.md' file constructs to use the mode suffix 27373':NAME'. Every construct that does so will be expanded N times, once 27374with every use of ':NAME' replaced by ':MODE1', once with every use 27375replaced by ':MODE2', and so on. In the expansion for a particular 27376MODEI, every C condition will also require that CONDI be true. 27377 27378 For example: 27379 27380 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 27381 27382 defines a new mode suffix ':P'. Every construct that uses ':P' will be 27383expanded twice, once with every ':P' replaced by ':SI' and once with 27384every ':P' replaced by ':DI'. The ':SI' version will only apply if 27385'Pmode == SImode' and the ':DI' version will only apply if 'Pmode == 27386DImode'. 27387 27388 As with other '.md' conditions, an empty string is treated as "always 27389true". '(MODE "")' can also be abbreviated to 'MODE'. For example: 27390 27391 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 27392 27393 means that the ':DI' expansion only applies if 'TARGET_64BIT' but that 27394the ':SI' expansion has no such constraint. 27395 27396 Iterators are applied in the order they are defined. This can be 27397significant if two iterators are used in a construct that requires 27398substitutions. *Note Substitutions::. 27399 27400 27401File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators 27402 2740316.23.1.2 Substitution in Mode Iterators 27404........................................ 27405 27406If an '.md' file construct uses mode iterators, each version of the 27407construct will often need slightly different strings or modes. For 27408example: 27409 27410 * When a 'define_expand' defines several 'addM3' patterns (*note 27411 Standard Names::), each expander will need to use the appropriate 27412 mode name for M. 27413 27414 * When a 'define_insn' defines several instruction patterns, each 27415 instruction will often use a different assembler mnemonic. 27416 27417 * When a 'define_insn' requires operands with different modes, using 27418 an iterator for one of the operand modes usually requires a 27419 specific mode for the other operand(s). 27420 27421 GCC supports such variations through a system of "mode attributes". 27422There are two standard attributes: 'mode', which is the name of the mode 27423in lower case, and 'MODE', which is the same thing in upper case. You 27424can define other attributes using: 27425 27426 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 27427 27428 where NAME is the name of the attribute and VALUEI is the value 27429associated with MODEI. 27430 27431 When GCC replaces some :ITERATOR with :MODE, it will scan each string 27432and mode in the pattern for sequences of the form '<ITERATOR:ATTR>', 27433where ATTR is the name of a mode attribute. If the attribute is defined 27434for MODE, the whole '<...>' sequence will be replaced by the appropriate 27435attribute value. 27436 27437 For example, suppose an '.md' file has: 27438 27439 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 27440 (define_mode_attr load [(SI "lw") (DI "ld")]) 27441 27442 If one of the patterns that uses ':P' contains the string 27443'"<P:load>\t%0,%1"', the 'SI' version of that pattern will use 27444'"lw\t%0,%1"' and the 'DI' version will use '"ld\t%0,%1"'. 27445 27446 Here is an example of using an attribute for a mode: 27447 27448 (define_mode_iterator LONG [SI DI]) 27449 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 27450 (define_insn ... 27451 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 27452 27453 The 'ITERATOR:' prefix may be omitted, in which case the substitution 27454will be attempted for every iterator expansion. 27455 27456 27457File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators 27458 2745916.23.1.3 Mode Iterator Examples 27460................................ 27461 27462Here is an example from the MIPS port. It defines the following modes 27463and attributes (among others): 27464 27465 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 27466 (define_mode_attr d [(SI "") (DI "d")]) 27467 27468 and uses the following template to define both 'subsi3' and 'subdi3': 27469 27470 (define_insn "sub<mode>3" 27471 [(set (match_operand:GPR 0 "register_operand" "=d") 27472 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 27473 (match_operand:GPR 2 "register_operand" "d")))] 27474 "" 27475 "<d>subu\t%0,%1,%2" 27476 [(set_attr "type" "arith") 27477 (set_attr "mode" "<MODE>")]) 27478 27479 This is exactly equivalent to: 27480 27481 (define_insn "subsi3" 27482 [(set (match_operand:SI 0 "register_operand" "=d") 27483 (minus:SI (match_operand:SI 1 "register_operand" "d") 27484 (match_operand:SI 2 "register_operand" "d")))] 27485 "" 27486 "subu\t%0,%1,%2" 27487 [(set_attr "type" "arith") 27488 (set_attr "mode" "SI")]) 27489 27490 (define_insn "subdi3" 27491 [(set (match_operand:DI 0 "register_operand" "=d") 27492 (minus:DI (match_operand:DI 1 "register_operand" "d") 27493 (match_operand:DI 2 "register_operand" "d")))] 27494 "" 27495 "dsubu\t%0,%1,%2" 27496 [(set_attr "type" "arith") 27497 (set_attr "mode" "DI")]) 27498 27499 27500File: gccint.info, Node: Code Iterators, Next: Int Iterators, Prev: Mode Iterators, Up: Iterators 27501 2750216.23.2 Code Iterators 27503---------------------- 27504 27505Code iterators operate in a similar way to mode iterators. *Note Mode 27506Iterators::. 27507 27508 The construct: 27509 27510 (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 27511 27512 defines a pseudo rtx code NAME that can be instantiated as CODEI if 27513condition CONDI is true. Each CODEI must have the same rtx format. 27514*Note RTL Classes::. 27515 27516 As with mode iterators, each pattern that uses NAME will be expanded N 27517times, once with all uses of NAME replaced by CODE1, once with all uses 27518replaced by CODE2, and so on. *Note Defining Mode Iterators::. 27519 27520 It is possible to define attributes for codes as well as for modes. 27521There are two standard code attributes: 'code', the name of the code in 27522lower case, and 'CODE', the name of the code in upper case. Other 27523attributes are defined using: 27524 27525 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 27526 27527 Here's an example of code iterators in action, taken from the MIPS 27528port: 27529 27530 (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt 27531 eq ne gt ge lt le gtu geu ltu leu]) 27532 27533 (define_expand "b<code>" 27534 [(set (pc) 27535 (if_then_else (any_cond:CC (cc0) 27536 (const_int 0)) 27537 (label_ref (match_operand 0 "")) 27538 (pc)))] 27539 "" 27540 { 27541 gen_conditional_branch (operands, <CODE>); 27542 DONE; 27543 }) 27544 27545 This is equivalent to: 27546 27547 (define_expand "bunordered" 27548 [(set (pc) 27549 (if_then_else (unordered:CC (cc0) 27550 (const_int 0)) 27551 (label_ref (match_operand 0 "")) 27552 (pc)))] 27553 "" 27554 { 27555 gen_conditional_branch (operands, UNORDERED); 27556 DONE; 27557 }) 27558 27559 (define_expand "bordered" 27560 [(set (pc) 27561 (if_then_else (ordered:CC (cc0) 27562 (const_int 0)) 27563 (label_ref (match_operand 0 "")) 27564 (pc)))] 27565 "" 27566 { 27567 gen_conditional_branch (operands, ORDERED); 27568 DONE; 27569 }) 27570 27571 ... 27572 27573 27574File: gccint.info, Node: Int Iterators, Next: Subst Iterators, Prev: Code Iterators, Up: Iterators 27575 2757616.23.3 Int Iterators 27577--------------------- 27578 27579Int iterators operate in a similar way to code iterators. *Note Code 27580Iterators::. 27581 27582 The construct: 27583 27584 (define_int_iterator NAME [(INT1 "COND1") ... (INTN "CONDN")]) 27585 27586 defines a pseudo integer constant NAME that can be instantiated as INTI 27587if condition CONDI is true. Each INT must have the same rtx format. 27588*Note RTL Classes::. Int iterators can appear in only those rtx fields 27589that have 'i' as the specifier. This means that each INT has to be a 27590constant defined using define_constant or define_c_enum. 27591 27592 As with mode and code iterators, each pattern that uses NAME will be 27593expanded N times, once with all uses of NAME replaced by INT1, once with 27594all uses replaced by INT2, and so on. *Note Defining Mode Iterators::. 27595 27596 It is possible to define attributes for ints as well as for codes and 27597modes. Attributes are defined using: 27598 27599 (define_int_attr NAME [(INT1 "VALUE1") ... (INTN "VALUEN")]) 27600 27601 Here's an example of int iterators in action, taken from the ARM port: 27602 27603 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 27604 27605 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 27606 27607 (define_insn "neon_vq<absneg><mode>" 27608 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 27609 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 27610 (match_operand:SI 2 "immediate_operand" "i")] 27611 QABSNEG))] 27612 "TARGET_NEON" 27613 "vq<absneg>.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 27614 [(set_attr "type" "neon_vqneg_vqabs")] 27615 ) 27616 27617 27618 This is equivalent to: 27619 27620 (define_insn "neon_vqabs<mode>" 27621 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 27622 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 27623 (match_operand:SI 2 "immediate_operand" "i")] 27624 UNSPEC_VQABS))] 27625 "TARGET_NEON" 27626 "vqabs.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 27627 [(set_attr "type" "neon_vqneg_vqabs")] 27628 ) 27629 27630 (define_insn "neon_vqneg<mode>" 27631 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 27632 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 27633 (match_operand:SI 2 "immediate_operand" "i")] 27634 UNSPEC_VQNEG))] 27635 "TARGET_NEON" 27636 "vqneg.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 27637 [(set_attr "type" "neon_vqneg_vqabs")] 27638 ) 27639 27640 27641 27642File: gccint.info, Node: Subst Iterators, Prev: Int Iterators, Up: Iterators 27643 2764416.23.4 Subst Iterators 27645----------------------- 27646 27647Subst iterators are special type of iterators with the following 27648restrictions: they could not be declared explicitly, they always have 27649only two values, and they do not have explicit dedicated name. 27650Subst-iterators are triggered only when corresponding subst-attribute is 27651used in RTL-pattern. 27652 27653 Subst iterators transform templates in the following way: the templates 27654are duplicated, the subst-attributes in these templates are replaced 27655with the corresponding values, and a new attribute is implicitly added 27656to the given 'define_insn'/'define_expand'. The name of the added 27657attribute matches the name of 'define_subst'. Such attributes are 27658declared implicitly, and it is not allowed to have a 'define_attr' named 27659as a 'define_subst'. 27660 27661 Each subst iterator is linked to a 'define_subst'. It is declared 27662implicitly by the first appearance of the corresponding 27663'define_subst_attr', and it is not allowed to define it explicitly. 27664 27665 Declarations of subst-attributes have the following syntax: 27666 27667 (define_subst_attr "NAME" 27668 "SUBST-NAME" 27669 "NO-SUBST-VALUE" 27670 "SUBST-APPLIED-VALUE") 27671 27672 NAME is a string with which the given subst-attribute could be referred 27673to. 27674 27675 SUBST-NAME shows which 'define_subst' should be applied to an 27676RTL-template if the given subst-attribute is present in the 27677RTL-template. 27678 27679 NO-SUBST-VALUE is a value with which subst-attribute would be replaced 27680in the first copy of the original RTL-template. 27681 27682 SUBST-APPLIED-VALUE is a value with which subst-attribute would be 27683replaced in the second copy of the original RTL-template. 27684 27685 27686File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 27687 2768817 Target Description Macros and Functions 27689****************************************** 27690 27691In addition to the file 'MACHINE.md', a machine description includes a C 27692header file conventionally given the name 'MACHINE.h' and a C source 27693file named 'MACHINE.c'. The header file defines numerous macros that 27694convey the information about the target machine that does not fit into 27695the scheme of the '.md' file. The file 'tm.h' should be a link to 27696'MACHINE.h'. The header file 'config.h' includes 'tm.h' and most 27697compiler source files include 'config.h'. The source file defines a 27698variable 'targetm', which is a structure containing pointers to 27699functions and data relating to the target machine. 'MACHINE.c' should 27700also contain their definitions, if they are not defined elsewhere in 27701GCC, and other functions called through the macros defined in the '.h' 27702file. 27703 27704* Menu: 27705 27706* Target Structure:: The 'targetm' variable. 27707* Driver:: Controlling how the driver runs the compilation passes. 27708* Run-time Target:: Defining '-m' options like '-m68000' and '-m68020'. 27709* Per-Function Data:: Defining data structures for per-function information. 27710* Storage Layout:: Defining sizes and alignments of data. 27711* Type Layout:: Defining sizes and properties of basic user data types. 27712* Registers:: Naming and describing the hardware registers. 27713* Register Classes:: Defining the classes of hardware registers. 27714* Stack and Calling:: Defining which way the stack grows and by how much. 27715* Varargs:: Defining the varargs macros. 27716* Trampolines:: Code set up at run time to enter a nested function. 27717* Library Calls:: Controlling how library routines are implicitly called. 27718* Addressing Modes:: Defining addressing modes valid for memory operands. 27719* Anchored Addresses:: Defining how '-fsection-anchors' should work. 27720* Condition Code:: Defining how insns update the condition code. 27721* Costs:: Defining relative costs of different operations. 27722* Scheduling:: Adjusting the behavior of the instruction scheduler. 27723* Sections:: Dividing storage into text, data, and other sections. 27724* PIC:: Macros for position independent code. 27725* Assembler Format:: Defining how to write insns and pseudo-ops to output. 27726* Debugging Info:: Defining the format of debugging output. 27727* Floating Point:: Handling floating point for cross-compilers. 27728* Mode Switching:: Insertion of mode-switching instructions. 27729* Target Attributes:: Defining target-specific uses of '__attribute__'. 27730* Emulated TLS:: Emulated TLS support. 27731* MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 27732* PCH Target:: Validity checking for precompiled headers. 27733* C++ ABI:: Controlling C++ ABI changes. 27734* Named Address Spaces:: Adding support for named address spaces 27735* Misc:: Everything else. 27736 27737 27738File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 27739 2774017.1 The Global 'targetm' Variable 27741================================== 27742 27743 -- Variable: struct gcc_target targetm 27744 The target '.c' file must define the global 'targetm' variable 27745 which contains pointers to functions and data relating to the 27746 target machine. The variable is declared in 'target.h'; 27747 'target-def.h' defines the macro 'TARGET_INITIALIZER' which is used 27748 to initialize the variable, and macros for the default initializers 27749 for elements of the structure. The '.c' file should override those 27750 macros for which the default definition is inappropriate. For 27751 example: 27752 #include "target.h" 27753 #include "target-def.h" 27754 27755 /* Initialize the GCC target structure. */ 27756 27757 #undef TARGET_COMP_TYPE_ATTRIBUTES 27758 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 27759 27760 struct gcc_target targetm = TARGET_INITIALIZER; 27761 27762 Where a macro should be defined in the '.c' file in this manner to form 27763part of the 'targetm' structure, it is documented below as a "Target 27764Hook" with a prototype. Many macros will change in future from being 27765defined in the '.h' file to being part of the 'targetm' structure. 27766 27767 Similarly, there is a 'targetcm' variable for hooks that are specific 27768to front ends for C-family languages, documented as "C Target Hook". 27769This is declared in 'c-family/c-target.h', the initializer 27770'TARGETCM_INITIALIZER' in 'c-family/c-target-def.h'. If targets 27771initialize 'targetcm' themselves, they should set 27772'target_has_targetcm=yes' in 'config.gcc'; otherwise a default 27773definition is used. 27774 27775 Similarly, there is a 'targetm_common' variable for hooks that are 27776shared between the compiler driver and the compilers proper, documented 27777as "Common Target Hook". This is declared in 'common/common-target.h', 27778the initializer 'TARGETM_COMMON_INITIALIZER' in 27779'common/common-target-def.h'. If targets initialize 'targetm_common' 27780themselves, they should set 'target_has_targetm_common=yes' in 27781'config.gcc'; otherwise a default definition is used. 27782 27783 27784File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 27785 2778617.2 Controlling the Compilation Driver, 'gcc' 27787============================================== 27788 27789You can control the compilation driver. 27790 27791 -- Macro: DRIVER_SELF_SPECS 27792 A list of specs for the driver itself. It should be a suitable 27793 initializer for an array of strings, with no surrounding braces. 27794 27795 The driver applies these specs to its own command line between 27796 loading default 'specs' files (but not command-line specified ones) 27797 and choosing the multilib directory or running any subcommands. It 27798 applies them in the order given, so each spec can depend on the 27799 options added by earlier ones. It is also possible to remove 27800 options using '%<OPTION' in the usual way. 27801 27802 This macro can be useful when a port has several interdependent 27803 target options. It provides a way of standardizing the command 27804 line so that the other specs are easier to write. 27805 27806 Do not define this macro if it does not need to do anything. 27807 27808 -- Macro: OPTION_DEFAULT_SPECS 27809 A list of specs used to support configure-time default options 27810 (i.e. '--with' options) in the driver. It should be a suitable 27811 initializer for an array of structures, each containing two 27812 strings, without the outermost pair of surrounding braces. 27813 27814 The first item in the pair is the name of the default. This must 27815 match the code in 'config.gcc' for the target. The second item is 27816 a spec to apply if a default with this name was specified. The 27817 string '%(VALUE)' in the spec will be replaced by the value of the 27818 default everywhere it occurs. 27819 27820 The driver will apply these specs to its own command line between 27821 loading default 'specs' files and processing 'DRIVER_SELF_SPECS', 27822 using the same mechanism as 'DRIVER_SELF_SPECS'. 27823 27824 Do not define this macro if it does not need to do anything. 27825 27826 -- Macro: CPP_SPEC 27827 A C string constant that tells the GCC driver program options to 27828 pass to CPP. It can also specify how to translate options you give 27829 to GCC into options for GCC to pass to the CPP. 27830 27831 Do not define this macro if it does not need to do anything. 27832 27833 -- Macro: CPLUSPLUS_CPP_SPEC 27834 This macro is just like 'CPP_SPEC', but is used for C++, rather 27835 than C. If you do not define this macro, then the value of 27836 'CPP_SPEC' (if any) will be used instead. 27837 27838 -- Macro: CC1_SPEC 27839 A C string constant that tells the GCC driver program options to 27840 pass to 'cc1', 'cc1plus', 'f771', and the other language front 27841 ends. It can also specify how to translate options you give to GCC 27842 into options for GCC to pass to front ends. 27843 27844 Do not define this macro if it does not need to do anything. 27845 27846 -- Macro: CC1PLUS_SPEC 27847 A C string constant that tells the GCC driver program options to 27848 pass to 'cc1plus'. It can also specify how to translate options 27849 you give to GCC into options for GCC to pass to the 'cc1plus'. 27850 27851 Do not define this macro if it does not need to do anything. Note 27852 that everything defined in CC1_SPEC is already passed to 'cc1plus' 27853 so there is no need to duplicate the contents of CC1_SPEC in 27854 CC1PLUS_SPEC. 27855 27856 -- Macro: ASM_SPEC 27857 A C string constant that tells the GCC driver program options to 27858 pass to the assembler. It can also specify how to translate 27859 options you give to GCC into options for GCC to pass to the 27860 assembler. See the file 'sun3.h' for an example of this. 27861 27862 Do not define this macro if it does not need to do anything. 27863 27864 -- Macro: ASM_FINAL_SPEC 27865 A C string constant that tells the GCC driver program how to run 27866 any programs which cleanup after the normal assembler. Normally, 27867 this is not needed. See the file 'mips.h' for an example of this. 27868 27869 Do not define this macro if it does not need to do anything. 27870 27871 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 27872 Define this macro, with no value, if the driver should give the 27873 assembler an argument consisting of a single dash, '-', to instruct 27874 it to read from its standard input (which will be a pipe connected 27875 to the output of the compiler proper). This argument is given 27876 after any '-o' option specifying the name of the output file. 27877 27878 If you do not define this macro, the assembler is assumed to read 27879 its standard input if given no non-option arguments. If your 27880 assembler cannot read standard input at all, use a '%{pipe:%e}' 27881 construct; see 'mips.h' for instance. 27882 27883 -- Macro: LINK_SPEC 27884 A C string constant that tells the GCC driver program options to 27885 pass to the linker. It can also specify how to translate options 27886 you give to GCC into options for GCC to pass to the linker. 27887 27888 Do not define this macro if it does not need to do anything. 27889 27890 -- Macro: LIB_SPEC 27891 Another C string constant used much like 'LINK_SPEC'. The 27892 difference between the two is that 'LIB_SPEC' is used at the end of 27893 the command given to the linker. 27894 27895 If this macro is not defined, a default is provided that loads the 27896 standard C library from the usual place. See 'gcc.c'. 27897 27898 -- Macro: LIBGCC_SPEC 27899 Another C string constant that tells the GCC driver program how and 27900 when to place a reference to 'libgcc.a' into the linker command 27901 line. This constant is placed both before and after the value of 27902 'LIB_SPEC'. 27903 27904 If this macro is not defined, the GCC driver provides a default 27905 that passes the string '-lgcc' to the linker. 27906 27907 -- Macro: REAL_LIBGCC_SPEC 27908 By default, if 'ENABLE_SHARED_LIBGCC' is defined, the 'LIBGCC_SPEC' 27909 is not directly used by the driver program but is instead modified 27910 to refer to different versions of 'libgcc.a' depending on the 27911 values of the command line flags '-static', '-shared', 27912 '-static-libgcc', and '-shared-libgcc'. On targets where these 27913 modifications are inappropriate, define 'REAL_LIBGCC_SPEC' instead. 27914 'REAL_LIBGCC_SPEC' tells the driver how to place a reference to 27915 'libgcc' on the link command line, but, unlike 'LIBGCC_SPEC', it is 27916 used unmodified. 27917 27918 -- Macro: USE_LD_AS_NEEDED 27919 A macro that controls the modifications to 'LIBGCC_SPEC' mentioned 27920 in 'REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 27921 uses '--as-needed' or equivalent options and the shared 'libgcc' in 27922 place of the static exception handler library, when linking without 27923 any of '-static', '-static-libgcc', or '-shared-libgcc'. 27924 27925 -- Macro: LINK_EH_SPEC 27926 If defined, this C string constant is added to 'LINK_SPEC'. When 27927 'USE_LD_AS_NEEDED' is zero or undefined, it also affects the 27928 modifications to 'LIBGCC_SPEC' mentioned in 'REAL_LIBGCC_SPEC'. 27929 27930 -- Macro: STARTFILE_SPEC 27931 Another C string constant used much like 'LINK_SPEC'. The 27932 difference between the two is that 'STARTFILE_SPEC' is used at the 27933 very beginning of the command given to the linker. 27934 27935 If this macro is not defined, a default is provided that loads the 27936 standard C startup file from the usual place. See 'gcc.c'. 27937 27938 -- Macro: ENDFILE_SPEC 27939 Another C string constant used much like 'LINK_SPEC'. The 27940 difference between the two is that 'ENDFILE_SPEC' is used at the 27941 very end of the command given to the linker. 27942 27943 Do not define this macro if it does not need to do anything. 27944 27945 -- Macro: THREAD_MODEL_SPEC 27946 GCC '-v' will print the thread model GCC was configured to use. 27947 However, this doesn't work on platforms that are multilibbed on 27948 thread models, such as AIX 4.3. On such platforms, define 27949 'THREAD_MODEL_SPEC' such that it evaluates to a string without 27950 blanks that names one of the recognized thread models. '%*', the 27951 default value of this macro, will expand to the value of 27952 'thread_file' set in 'config.gcc'. 27953 27954 -- Macro: SYSROOT_SUFFIX_SPEC 27955 Define this macro to add a suffix to the target sysroot when GCC is 27956 configured with a sysroot. This will cause GCC to search for 27957 usr/lib, et al, within sysroot+suffix. 27958 27959 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 27960 Define this macro to add a headers_suffix to the target sysroot 27961 when GCC is configured with a sysroot. This will cause GCC to pass 27962 the updated sysroot+headers_suffix to CPP, causing it to search for 27963 usr/include, et al, within sysroot+headers_suffix. 27964 27965 -- Macro: EXTRA_SPECS 27966 Define this macro to provide additional specifications to put in 27967 the 'specs' file that can be used in various specifications like 27968 'CC1_SPEC'. 27969 27970 The definition should be an initializer for an array of structures, 27971 containing a string constant, that defines the specification name, 27972 and a string constant that provides the specification. 27973 27974 Do not define this macro if it does not need to do anything. 27975 27976 'EXTRA_SPECS' is useful when an architecture contains several 27977 related targets, which have various '..._SPECS' which are similar 27978 to each other, and the maintainer would like one central place to 27979 keep these definitions. 27980 27981 For example, the PowerPC System V.4 targets use 'EXTRA_SPECS' to 27982 define either '_CALL_SYSV' when the System V calling sequence is 27983 used or '_CALL_AIX' when the older AIX-based calling sequence is 27984 used. 27985 27986 The 'config/rs6000/rs6000.h' target file defines: 27987 27988 #define EXTRA_SPECS \ 27989 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 27990 27991 #define CPP_SYS_DEFAULT "" 27992 27993 The 'config/rs6000/sysv.h' target file defines: 27994 #undef CPP_SPEC 27995 #define CPP_SPEC \ 27996 "%{posix: -D_POSIX_SOURCE } \ 27997 %{mcall-sysv: -D_CALL_SYSV } \ 27998 %{!mcall-sysv: %(cpp_sysv_default) } \ 27999 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 28000 28001 #undef CPP_SYSV_DEFAULT 28002 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 28003 28004 while the 'config/rs6000/eabiaix.h' target file defines 28005 'CPP_SYSV_DEFAULT' as: 28006 28007 #undef CPP_SYSV_DEFAULT 28008 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 28009 28010 -- Macro: LINK_LIBGCC_SPECIAL_1 28011 Define this macro if the driver program should find the library 28012 'libgcc.a'. If you do not define this macro, the driver program 28013 will pass the argument '-lgcc' to tell the linker to do the search. 28014 28015 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 28016 The sequence in which libgcc and libc are specified to the linker. 28017 By default this is '%G %L %G'. 28018 28019 -- Macro: POST_LINK_SPEC 28020 Define this macro to add additional steps to be executed after 28021 linker. The default value of this macro is empty string. 28022 28023 -- Macro: LINK_COMMAND_SPEC 28024 A C string constant giving the complete command line need to 28025 execute the linker. When you do this, you will need to update your 28026 port each time a change is made to the link command line within 28027 'gcc.c'. Therefore, define this macro only if you need to 28028 completely redefine the command line for invoking the linker and 28029 there is no other way to accomplish the effect you need. 28030 Overriding this macro may be avoidable by overriding 28031 'LINK_GCC_C_SEQUENCE_SPEC' instead. 28032 28033 -- Common Target Hook: bool TARGET_ALWAYS_STRIP_DOTDOT 28034 True if '..' components should always be removed from directory 28035 names computed relative to GCC's internal directories, false 28036 (default) if such components should be preserved and directory 28037 names containing them passed to other tools such as the linker. 28038 28039 -- Macro: MULTILIB_DEFAULTS 28040 Define this macro as a C expression for the initializer of an array 28041 of string to tell the driver program which options are defaults for 28042 this target and thus do not need to be handled specially when using 28043 'MULTILIB_OPTIONS'. 28044 28045 Do not define this macro if 'MULTILIB_OPTIONS' is not defined in 28046 the target makefile fragment or if none of the options listed in 28047 'MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 28048 28049 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 28050 Define this macro to tell 'gcc' that it should only translate a 28051 '-B' prefix into a '-L' linker option if the prefix indicates an 28052 absolute file name. 28053 28054 -- Macro: MD_EXEC_PREFIX 28055 If defined, this macro is an additional prefix to try after 28056 'STANDARD_EXEC_PREFIX'. 'MD_EXEC_PREFIX' is not searched when the 28057 compiler is built as a cross compiler. If you define 28058 'MD_EXEC_PREFIX', then be sure to add it to the list of directories 28059 used to find the assembler in 'configure.ac'. 28060 28061 -- Macro: STANDARD_STARTFILE_PREFIX 28062 Define this macro as a C string constant if you wish to override 28063 the standard choice of 'libdir' as the default prefix to try when 28064 searching for startup files such as 'crt0.o'. 28065 'STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 28066 built as a cross compiler. 28067 28068 -- Macro: STANDARD_STARTFILE_PREFIX_1 28069 Define this macro as a C string constant if you wish to override 28070 the standard choice of '/lib' as a prefix to try after the default 28071 prefix when searching for startup files such as 'crt0.o'. 28072 'STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 28073 built as a cross compiler. 28074 28075 -- Macro: STANDARD_STARTFILE_PREFIX_2 28076 Define this macro as a C string constant if you wish to override 28077 the standard choice of '/lib' as yet another prefix to try after 28078 the default prefix when searching for startup files such as 28079 'crt0.o'. 'STANDARD_STARTFILE_PREFIX_2' is not searched when the 28080 compiler is built as a cross compiler. 28081 28082 -- Macro: MD_STARTFILE_PREFIX 28083 If defined, this macro supplies an additional prefix to try after 28084 the standard prefixes. 'MD_EXEC_PREFIX' is not searched when the 28085 compiler is built as a cross compiler. 28086 28087 -- Macro: MD_STARTFILE_PREFIX_1 28088 If defined, this macro supplies yet another prefix to try after the 28089 standard prefixes. It is not searched when the compiler is built 28090 as a cross compiler. 28091 28092 -- Macro: INIT_ENVIRONMENT 28093 Define this macro as a C string constant if you wish to set 28094 environment variables for programs called by the driver, such as 28095 the assembler and loader. The driver passes the value of this 28096 macro to 'putenv' to initialize the necessary environment 28097 variables. 28098 28099 -- Macro: LOCAL_INCLUDE_DIR 28100 Define this macro as a C string constant if you wish to override 28101 the standard choice of '/usr/local/include' as the default prefix 28102 to try when searching for local header files. 'LOCAL_INCLUDE_DIR' 28103 comes before 'NATIVE_SYSTEM_HEADER_DIR' (set in 'config.gcc', 28104 normally '/usr/include') in the search order. 28105 28106 Cross compilers do not search either '/usr/local/include' or its 28107 replacement. 28108 28109 -- Macro: NATIVE_SYSTEM_HEADER_COMPONENT 28110 The "component" corresponding to 'NATIVE_SYSTEM_HEADER_DIR'. See 28111 'INCLUDE_DEFAULTS', below, for the description of components. If 28112 you do not define this macro, no component is used. 28113 28114 -- Macro: INCLUDE_DEFAULTS 28115 Define this macro if you wish to override the entire default search 28116 path for include files. For a native compiler, the default search 28117 path usually consists of 'GCC_INCLUDE_DIR', 'LOCAL_INCLUDE_DIR', 28118 'GPLUSPLUS_INCLUDE_DIR', and 'NATIVE_SYSTEM_HEADER_DIR'. In 28119 addition, 'GPLUSPLUS_INCLUDE_DIR' and 'GCC_INCLUDE_DIR' are defined 28120 automatically by 'Makefile', and specify private search areas for 28121 GCC. The directory 'GPLUSPLUS_INCLUDE_DIR' is used only for C++ 28122 programs. 28123 28124 The definition should be an initializer for an array of structures. 28125 Each array element should have four elements: the directory name (a 28126 string constant), the component name (also a string constant), a 28127 flag for C++-only directories, and a flag showing that the includes 28128 in the directory don't need to be wrapped in 'extern 'C'' when 28129 compiling C++. Mark the end of the array with a null element. 28130 28131 The component name denotes what GNU package the include file is 28132 part of, if any, in all uppercase letters. For example, it might 28133 be 'GCC' or 'BINUTILS'. If the package is part of a 28134 vendor-supplied operating system, code the component name as '0'. 28135 28136 For example, here is the definition used for VAX/VMS: 28137 28138 #define INCLUDE_DEFAULTS \ 28139 { \ 28140 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 28141 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 28142 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 28143 { ".", 0, 0, 0}, \ 28144 { 0, 0, 0, 0} \ 28145 } 28146 28147 Here is the order of prefixes tried for exec files: 28148 28149 1. Any prefixes specified by the user with '-B'. 28150 28151 2. The environment variable 'GCC_EXEC_PREFIX' or, if 'GCC_EXEC_PREFIX' 28152 is not set and the compiler has not been installed in the 28153 configure-time PREFIX, the location in which the compiler has 28154 actually been installed. 28155 28156 3. The directories specified by the environment variable 28157 'COMPILER_PATH'. 28158 28159 4. The macro 'STANDARD_EXEC_PREFIX', if the compiler has been 28160 installed in the configured-time PREFIX. 28161 28162 5. The location '/usr/libexec/gcc/', but only if this is a native 28163 compiler. 28164 28165 6. The location '/usr/lib/gcc/', but only if this is a native 28166 compiler. 28167 28168 7. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 28169 native compiler. 28170 28171 Here is the order of prefixes tried for startfiles: 28172 28173 1. Any prefixes specified by the user with '-B'. 28174 28175 2. The environment variable 'GCC_EXEC_PREFIX' or its automatically 28176 determined value based on the installed toolchain location. 28177 28178 3. The directories specified by the environment variable 28179 'LIBRARY_PATH' (or port-specific name; native only, cross compilers 28180 do not use this). 28181 28182 4. The macro 'STANDARD_EXEC_PREFIX', but only if the toolchain is 28183 installed in the configured PREFIX or this is a native compiler. 28184 28185 5. The location '/usr/lib/gcc/', but only if this is a native 28186 compiler. 28187 28188 6. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 28189 native compiler. 28190 28191 7. The macro 'MD_STARTFILE_PREFIX', if defined, but only if this is a 28192 native compiler, or we have a target system root. 28193 28194 8. The macro 'MD_STARTFILE_PREFIX_1', if defined, but only if this is 28195 a native compiler, or we have a target system root. 28196 28197 9. The macro 'STANDARD_STARTFILE_PREFIX', with any sysroot 28198 modifications. If this path is relative it will be prefixed by 28199 'GCC_EXEC_PREFIX' and the machine suffix or 'STANDARD_EXEC_PREFIX' 28200 and the machine suffix. 28201 28202 10. The macro 'STANDARD_STARTFILE_PREFIX_1', but only if this is a 28203 native compiler, or we have a target system root. The default for 28204 this macro is '/lib/'. 28205 28206 11. The macro 'STANDARD_STARTFILE_PREFIX_2', but only if this is a 28207 native compiler, or we have a target system root. The default for 28208 this macro is '/usr/lib/'. 28209 28210 28211File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 28212 2821317.3 Run-time Target Specification 28214================================== 28215 28216Here are run-time target specifications. 28217 28218 -- Macro: TARGET_CPU_CPP_BUILTINS () 28219 This function-like macro expands to a block of code that defines 28220 built-in preprocessor macros and assertions for the target CPU, 28221 using the functions 'builtin_define', 'builtin_define_std' and 28222 'builtin_assert'. When the front end calls this macro it provides 28223 a trailing semicolon, and since it has finished command line option 28224 processing your code can use those results freely. 28225 28226 'builtin_assert' takes a string in the form you pass to the 28227 command-line option '-A', such as 'cpu=mips', and creates the 28228 assertion. 'builtin_define' takes a string in the form accepted by 28229 option '-D' and unconditionally defines the macro. 28230 28231 'builtin_define_std' takes a string representing the name of an 28232 object-like macro. If it doesn't lie in the user's namespace, 28233 'builtin_define_std' defines it unconditionally. Otherwise, it 28234 defines a version with two leading underscores, and another version 28235 with two leading and trailing underscores, and defines the original 28236 only if an ISO standard was not requested on the command line. For 28237 example, passing 'unix' defines '__unix', '__unix__' and possibly 28238 'unix'; passing '_mips' defines '__mips', '__mips__' and possibly 28239 '_mips', and passing '_ABI64' defines only '_ABI64'. 28240 28241 You can also test for the C dialect being compiled. The variable 28242 'c_language' is set to one of 'clk_c', 'clk_cplusplus' or 28243 'clk_objective_c'. Note that if we are preprocessing assembler, 28244 this variable will be 'clk_c' but the function-like macro 28245 'preprocessing_asm_p()' will return true, so you might want to 28246 check for that first. If you need to check for strict ANSI, the 28247 variable 'flag_iso' can be used. The function-like macro 28248 'preprocessing_trad_p()' can be used to check for traditional 28249 preprocessing. 28250 28251 -- Macro: TARGET_OS_CPP_BUILTINS () 28252 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 28253 and is used for the target operating system instead. 28254 28255 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 28256 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 28257 and is used for the target object format. 'elfos.h' uses this 28258 macro to define '__ELF__', so you probably do not need to define it 28259 yourself. 28260 28261 -- Variable: extern int target_flags 28262 This variable is declared in 'options.h', which is included before 28263 any target-specific headers. 28264 28265 -- Common Target Hook: int TARGET_DEFAULT_TARGET_FLAGS 28266 This variable specifies the initial value of 'target_flags'. Its 28267 default setting is 0. 28268 28269 -- Common Target Hook: bool TARGET_HANDLE_OPTION (struct gcc_options 28270 *OPTS, struct gcc_options *OPTS_SET, const struct 28271 cl_decoded_option *DECODED, location_t LOC) 28272 This hook is called whenever the user specifies one of the 28273 target-specific options described by the '.opt' definition files 28274 (*note Options::). It has the opportunity to do some 28275 option-specific processing and should return true if the option is 28276 valid. The default definition does nothing but return true. 28277 28278 DECODED specifies the option and its arguments. OPTS and OPTS_SET 28279 are the 'gcc_options' structures to be used for storing option 28280 state, and LOC is the location at which the option was passed 28281 ('UNKNOWN_LOCATION' except for options passed via attributes). 28282 28283 -- C Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char 28284 *ARG, int VALUE) 28285 This target hook is called whenever the user specifies one of the 28286 target-specific C language family options described by the '.opt' 28287 definition files(*note Options::). It has the opportunity to do 28288 some option-specific processing and should return true if the 28289 option is valid. The arguments are like for 28290 'TARGET_HANDLE_OPTION'. The default definition does nothing but 28291 return false. 28292 28293 In general, you should use 'TARGET_HANDLE_OPTION' to handle 28294 options. However, if processing an option requires routines that 28295 are only available in the C (and related language) front ends, then 28296 you should use 'TARGET_HANDLE_C_OPTION' instead. 28297 28298 -- C Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree 28299 STRING) 28300 Targets may provide a string object type that can be used within 28301 and between C, C++ and their respective Objective-C dialects. A 28302 string object might, for example, embed encoding and length 28303 information. These objects are considered opaque to the compiler 28304 and handled as references. An ideal implementation makes the 28305 composition of the string object match that of the Objective-C 28306 'NSString' ('NXString' for GNUStep), allowing efficient 28307 interworking between C-only and Objective-C code. If a target 28308 implements string objects then this hook should return a reference 28309 to such an object constructed from the normal 'C' string 28310 representation provided in STRING. At present, the hook is used by 28311 Objective-C only, to obtain a common-format string object when the 28312 target provides one. 28313 28314 -- C Target Hook: void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE 28315 (const char *CLASSNAME) 28316 Declare that Objective C class CLASSNAME is referenced by the 28317 current TU. 28318 28319 -- C Target Hook: void TARGET_OBJC_DECLARE_CLASS_DEFINITION (const char 28320 *CLASSNAME) 28321 Declare that Objective C class CLASSNAME is defined by the current 28322 TU. 28323 28324 -- C Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree 28325 STRINGREF) 28326 If a target implements string objects then this hook should return 28327 'true' if STRINGREF is a valid reference to such an object. 28328 28329 -- C Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree 28330 FORMAT_ARG, tree ARGS_LIST) 28331 If a target implements string objects then this hook should should 28332 provide a facility to check the function arguments in ARGS_LIST 28333 against the format specifiers in FORMAT_ARG where the type of 28334 FORMAT_ARG is one recognized as a valid string reference type. 28335 28336 -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void) 28337 This target function is similar to the hook 28338 'TARGET_OPTION_OVERRIDE' but is called when the optimize level is 28339 changed via an attribute or pragma or when it is reset at the end 28340 of the code affected by the attribute or pragma. It is not called 28341 at the beginning of compilation when 'TARGET_OPTION_OVERRIDE' is 28342 called so if you want to perform these actions then, you should 28343 have 'TARGET_OPTION_OVERRIDE' call 28344 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'. 28345 28346 -- Macro: C_COMMON_OVERRIDE_OPTIONS 28347 This is similar to the 'TARGET_OPTION_OVERRIDE' hook but is only 28348 used in the C language frontends (C, Objective-C, C++, 28349 Objective-C++) and so can be used to alter option flag variables 28350 which only exist in those frontends. 28351 28352 -- Common Target Hook: const struct default_options * 28353 TARGET_OPTION_OPTIMIZATION_TABLE 28354 Some machines may desire to change what optimizations are performed 28355 for various optimization levels. This variable, if defined, 28356 describes options to enable at particular sets of optimization 28357 levels. These options are processed once just after the 28358 optimization level is determined and before the remainder of the 28359 command options have been parsed, so may be overridden by other 28360 options passed explicitly. 28361 28362 This processing is run once at program startup and when the 28363 optimization options are changed via '#pragma GCC optimize' or by 28364 using the 'optimize' attribute. 28365 28366 -- Common Target Hook: void TARGET_OPTION_INIT_STRUCT (struct 28367 gcc_options *OPTS) 28368 Set target-dependent initial values of fields in OPTS. 28369 28370 -- Common Target Hook: void TARGET_OPTION_DEFAULT_PARAMS (void) 28371 Set target-dependent default values for '--param' settings, using 28372 calls to 'set_default_param_value'. 28373 28374 -- Macro: SWITCHABLE_TARGET 28375 Some targets need to switch between substantially different 28376 subtargets during compilation. For example, the MIPS target has 28377 one subtarget for the traditional MIPS architecture and another for 28378 MIPS16. Source code can switch between these two subarchitectures 28379 using the 'mips16' and 'nomips16' attributes. 28380 28381 Such subtargets can differ in things like the set of available 28382 registers, the set of available instructions, the costs of various 28383 operations, and so on. GCC caches a lot of this type of 28384 information in global variables, and recomputing them for each 28385 subtarget takes a significant amount of time. The compiler 28386 therefore provides a facility for maintaining several versions of 28387 the global variables and quickly switching between them; see 28388 'target-globals.h' for details. 28389 28390 Define this macro to 1 if your target needs this facility. The 28391 default is 0. 28392 28393 -- Target Hook: bool TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P 28394 (void) 28395 Returns true if the target supports IEEE 754 floating-point 28396 exceptions and rounding modes, false otherwise. This is intended 28397 to relate to the 'float' and 'double' types, but not necessarily 28398 'long double'. By default, returns true if the 'adddf3' 28399 instruction pattern is available and false otherwise, on the 28400 assumption that hardware floating point supports exceptions and 28401 rounding modes but software floating point does not. 28402 28403 28404File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 28405 2840617.4 Defining data structures for per-function information. 28407=========================================================== 28408 28409If the target needs to store information on a per-function basis, GCC 28410provides a macro and a couple of variables to allow this. Note, just 28411using statics to store the information is a bad idea, since GCC supports 28412nested functions, so you can be halfway through encoding one function 28413when another one comes along. 28414 28415 GCC defines a data structure called 'struct function' which contains 28416all of the data specific to an individual function. This structure 28417contains a field called 'machine' whose type is 'struct machine_function 28418*', which can be used by targets to point to their own specific data. 28419 28420 If a target needs per-function specific data it should define the type 28421'struct machine_function' and also the macro 'INIT_EXPANDERS'. This 28422macro should be used to initialize the function pointer 28423'init_machine_status'. This pointer is explained below. 28424 28425 One typical use of per-function, target specific data is to create an 28426RTX to hold the register containing the function's return address. This 28427RTX can then be used to implement the '__builtin_return_address' 28428function, for level 0. 28429 28430 Note--earlier implementations of GCC used a single data area to hold 28431all of the per-function information. Thus when processing of a nested 28432function began the old per-function data had to be pushed onto a stack, 28433and when the processing was finished, it had to be popped off the stack. 28434GCC used to provide function pointers called 'save_machine_status' and 28435'restore_machine_status' to handle the saving and restoring of the 28436target specific information. Since the single data area approach is no 28437longer used, these pointers are no longer supported. 28438 28439 -- Macro: INIT_EXPANDERS 28440 Macro called to initialize any target specific information. This 28441 macro is called once per function, before generation of any RTL has 28442 begun. The intention of this macro is to allow the initialization 28443 of the function pointer 'init_machine_status'. 28444 28445 -- Variable: void (*)(struct function *) init_machine_status 28446 If this function pointer is non-'NULL' it will be called once per 28447 function, before function compilation starts, in order to allow the 28448 target to perform any target specific initialization of the 'struct 28449 function' structure. It is intended that this would be used to 28450 initialize the 'machine' of that structure. 28451 28452 'struct machine_function' structures are expected to be freed by 28453 GC. Generally, any memory that they reference must be allocated by 28454 using GC allocation, including the structure itself. 28455 28456 28457File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 28458 2845917.5 Storage Layout 28460=================== 28461 28462Note that the definitions of the macros in this table which are sizes or 28463alignments measured in bits do not need to be constant. They can be C 28464expressions that refer to static variables, such as the 'target_flags'. 28465*Note Run-time Target::. 28466 28467 -- Macro: BITS_BIG_ENDIAN 28468 Define this macro to have the value 1 if the most significant bit 28469 in a byte has the lowest number; otherwise define it to have the 28470 value zero. This means that bit-field instructions count from the 28471 most significant bit. If the machine has no bit-field 28472 instructions, then this must still be defined, but it doesn't 28473 matter which value it is defined to. This macro need not be a 28474 constant. 28475 28476 This macro does not affect the way structure fields are packed into 28477 bytes or words; that is controlled by 'BYTES_BIG_ENDIAN'. 28478 28479 -- Macro: BYTES_BIG_ENDIAN 28480 Define this macro to have the value 1 if the most significant byte 28481 in a word has the lowest number. This macro need not be a 28482 constant. 28483 28484 -- Macro: WORDS_BIG_ENDIAN 28485 Define this macro to have the value 1 if, in a multiword object, 28486 the most significant word has the lowest number. This applies to 28487 both memory locations and registers; see 'REG_WORDS_BIG_ENDIAN' if 28488 the order of words in memory is not the same as the order in 28489 registers. This macro need not be a constant. 28490 28491 -- Macro: REG_WORDS_BIG_ENDIAN 28492 On some machines, the order of words in a multiword object differs 28493 between registers in memory. In such a situation, define this 28494 macro to describe the order of words in a register. The macro 28495 'WORDS_BIG_ENDIAN' controls the order of words in memory. 28496 28497 -- Macro: FLOAT_WORDS_BIG_ENDIAN 28498 Define this macro to have the value 1 if 'DFmode', 'XFmode' or 28499 'TFmode' floating point numbers are stored in memory with the word 28500 containing the sign bit at the lowest address; otherwise define it 28501 to have the value 0. This macro need not be a constant. 28502 28503 You need not define this macro if the ordering is the same as for 28504 multi-word integers. 28505 28506 -- Macro: BITS_PER_WORD 28507 Number of bits in a word. If you do not define this macro, the 28508 default is 'BITS_PER_UNIT * UNITS_PER_WORD'. 28509 28510 -- Macro: MAX_BITS_PER_WORD 28511 Maximum number of bits in a word. If this is undefined, the 28512 default is 'BITS_PER_WORD'. Otherwise, it is the constant value 28513 that is the largest value that 'BITS_PER_WORD' can have at 28514 run-time. 28515 28516 -- Macro: UNITS_PER_WORD 28517 Number of storage units in a word; normally the size of a 28518 general-purpose register, a power of two from 1 or 8. 28519 28520 -- Macro: MIN_UNITS_PER_WORD 28521 Minimum number of units in a word. If this is undefined, the 28522 default is 'UNITS_PER_WORD'. Otherwise, it is the constant value 28523 that is the smallest value that 'UNITS_PER_WORD' can have at 28524 run-time. 28525 28526 -- Macro: POINTER_SIZE 28527 Width of a pointer, in bits. You must specify a value no wider 28528 than the width of 'Pmode'. If it is not equal to the width of 28529 'Pmode', you must define 'POINTERS_EXTEND_UNSIGNED'. If you do not 28530 specify a value the default is 'BITS_PER_WORD'. 28531 28532 -- Macro: POINTERS_EXTEND_UNSIGNED 28533 A C expression that determines how pointers should be extended from 28534 'ptr_mode' to either 'Pmode' or 'word_mode'. It is greater than 28535 zero if pointers should be zero-extended, zero if they should be 28536 sign-extended, and negative if some other sort of conversion is 28537 needed. In the last case, the extension is done by the target's 28538 'ptr_extend' instruction. 28539 28540 You need not define this macro if the 'ptr_mode', 'Pmode' and 28541 'word_mode' are all the same width. 28542 28543 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 28544 A macro to update M and UNSIGNEDP when an object whose type is TYPE 28545 and which has the specified mode and signedness is to be stored in 28546 a register. This macro is only called when TYPE is a scalar type. 28547 28548 On most RISC machines, which only have operations that operate on a 28549 full register, define this macro to set M to 'word_mode' if M is an 28550 integer mode narrower than 'BITS_PER_WORD'. In most cases, only 28551 integer modes should be widened because wider-precision 28552 floating-point operations are usually more expensive than their 28553 narrower counterparts. 28554 28555 For most machines, the macro definition does not change UNSIGNEDP. 28556 However, some machines, have instructions that preferentially 28557 handle either signed or unsigned quantities of certain modes. For 28558 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 28559 instructions sign-extend the result to 64 bits. On such machines, 28560 set UNSIGNEDP according to which kind of extension is more 28561 efficient. 28562 28563 Do not define this macro if it would never modify M. 28564 28565 -- Target Hook: machine_mode TARGET_PROMOTE_FUNCTION_MODE (const_tree 28566 TYPE, machine_mode MODE, int *PUNSIGNEDP, const_tree FUNTYPE, 28567 int FOR_RETURN) 28568 Like 'PROMOTE_MODE', but it is applied to outgoing function 28569 arguments or function return values. The target hook should return 28570 the new mode and possibly change '*PUNSIGNEDP' if the promotion 28571 should change signedness. This function is called only for scalar 28572 _or pointer_ types. 28573 28574 FOR_RETURN allows to distinguish the promotion of arguments and 28575 return values. If it is '1', a return value is being promoted and 28576 'TARGET_FUNCTION_VALUE' must perform the same promotions done here. 28577 If it is '2', the returned mode should be that of the register in 28578 which an incoming parameter is copied, or the outgoing result is 28579 computed; then the hook should return the same mode as 28580 'promote_mode', though the signedness may be different. 28581 28582 TYPE can be NULL when promoting function arguments of libcalls. 28583 28584 The default is to not promote arguments and return values. You can 28585 also define the hook to 28586 'default_promote_function_mode_always_promote' if you would like to 28587 apply the same rules given by 'PROMOTE_MODE'. 28588 28589 -- Macro: PARM_BOUNDARY 28590 Normal alignment required for function parameters on the stack, in 28591 bits. All stack parameters receive at least this much alignment 28592 regardless of data type. On most machines, this is the same as the 28593 size of an integer. 28594 28595 -- Macro: STACK_BOUNDARY 28596 Define this macro to the minimum alignment enforced by hardware for 28597 the stack pointer on this machine. The definition is a C 28598 expression for the desired alignment (measured in bits). This 28599 value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not 28600 defined. On most machines, this should be the same as 28601 'PARM_BOUNDARY'. 28602 28603 -- Macro: PREFERRED_STACK_BOUNDARY 28604 Define this macro if you wish to preserve a certain alignment for 28605 the stack pointer, greater than what the hardware enforces. The 28606 definition is a C expression for the desired alignment (measured in 28607 bits). This macro must evaluate to a value equal to or larger than 28608 'STACK_BOUNDARY'. 28609 28610 -- Macro: INCOMING_STACK_BOUNDARY 28611 Define this macro if the incoming stack boundary may be different 28612 from 'PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a 28613 value equal to or larger than 'STACK_BOUNDARY'. 28614 28615 -- Macro: FUNCTION_BOUNDARY 28616 Alignment required for a function entry point, in bits. 28617 28618 -- Macro: BIGGEST_ALIGNMENT 28619 Biggest alignment that any data type can require on this machine, 28620 in bits. Note that this is not the biggest alignment that is 28621 supported, just the biggest alignment that, when violated, may 28622 cause a fault. 28623 28624 -- Target Hook: HOST_WIDE_INT TARGET_ABSOLUTE_BIGGEST_ALIGNMENT 28625 If defined, this target hook specifies the absolute biggest 28626 alignment that a type or variable can have on this machine, 28627 otherwise, 'BIGGEST_ALIGNMENT' is used. 28628 28629 -- Macro: MALLOC_ABI_ALIGNMENT 28630 Alignment, in bits, a C conformant malloc implementation has to 28631 provide. If not defined, the default value is 'BITS_PER_WORD'. 28632 28633 -- Macro: ATTRIBUTE_ALIGNED_VALUE 28634 Alignment used by the '__attribute__ ((aligned))' construct. If 28635 not defined, the default value is 'BIGGEST_ALIGNMENT'. 28636 28637 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 28638 If defined, the smallest alignment, in bits, that can be given to 28639 an object that can be referenced in one operation, without 28640 disturbing any nearby object. Normally, this is 'BITS_PER_UNIT', 28641 but may be larger on machines that don't have byte or half-word 28642 store operations. 28643 28644 -- Macro: BIGGEST_FIELD_ALIGNMENT 28645 Biggest alignment that any structure or union field can require on 28646 this machine, in bits. If defined, this overrides 28647 'BIGGEST_ALIGNMENT' for structure and union fields only, unless the 28648 field alignment has been set by the '__attribute__ ((aligned (N)))' 28649 construct. 28650 28651 -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED) 28652 An expression for the alignment of a structure field FIELD if the 28653 alignment computed in the usual way (including applying of 28654 'BIGGEST_ALIGNMENT' and 'BIGGEST_FIELD_ALIGNMENT' to the alignment) 28655 is COMPUTED. It overrides alignment only if the field alignment 28656 has not been set by the '__attribute__ ((aligned (N)))' construct. 28657 28658 -- Macro: MAX_STACK_ALIGNMENT 28659 Biggest stack alignment guaranteed by the backend. Use this macro 28660 to specify the maximum alignment of a variable on stack. 28661 28662 If not defined, the default value is 'STACK_BOUNDARY'. 28663 28664 -- Macro: MAX_OFILE_ALIGNMENT 28665 Biggest alignment supported by the object file format of this 28666 machine. Use this macro to limit the alignment which can be 28667 specified using the '__attribute__ ((aligned (N)))' construct. If 28668 not defined, the default value is 'BIGGEST_ALIGNMENT'. 28669 28670 On systems that use ELF, the default (in 'config/elfos.h') is the 28671 largest supported 32-bit ELF section alignment representable on a 28672 32-bit host e.g. '(((uint64_t) 1 << 28) * 8)'. On 32-bit ELF the 28673 largest supported section alignment in bits is '(0x80000000 * 8)', 28674 but this is not representable on 32-bit hosts. 28675 28676 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 28677 If defined, a C expression to compute the alignment for a variable 28678 in the static store. TYPE is the data type, and BASIC-ALIGN is the 28679 alignment that the object would ordinarily have. The value of this 28680 macro is used instead of that alignment to align the object. 28681 28682 If this macro is not defined, then BASIC-ALIGN is used. 28683 28684 One use of this macro is to increase alignment of medium-size data 28685 to make it all fit in fewer cache lines. Another is to cause 28686 character arrays to be word-aligned so that 'strcpy' calls that 28687 copy constants to character arrays can be done inline. 28688 28689 -- Macro: DATA_ABI_ALIGNMENT (TYPE, BASIC-ALIGN) 28690 Similar to 'DATA_ALIGNMENT', but for the cases where the ABI 28691 mandates some alignment increase, instead of optimization only 28692 purposes. E.g. AMD x86-64 psABI says that variables with array 28693 type larger than 15 bytes must be aligned to 16 byte boundaries. 28694 28695 If this macro is not defined, then BASIC-ALIGN is used. 28696 28697 -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN) 28698 If defined, a C expression to compute the alignment given to a 28699 constant that is being placed in memory. CONSTANT is the constant 28700 and BASIC-ALIGN is the alignment that the object would ordinarily 28701 have. The value of this macro is used instead of that alignment to 28702 align the object. 28703 28704 The default definition just returns BASIC-ALIGN. 28705 28706 The typical use of this macro is to increase alignment for string 28707 constants to be word aligned so that 'strcpy' calls that copy 28708 constants can be done inline. 28709 28710 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 28711 If defined, a C expression to compute the alignment for a variable 28712 in the local store. TYPE is the data type, and BASIC-ALIGN is the 28713 alignment that the object would ordinarily have. The value of this 28714 macro is used instead of that alignment to align the object. 28715 28716 If this macro is not defined, then BASIC-ALIGN is used. 28717 28718 One use of this macro is to increase alignment of medium-size data 28719 to make it all fit in fewer cache lines. 28720 28721 If the value of this macro has a type, it should be an unsigned 28722 type. 28723 28724 -- Target Hook: HOST_WIDE_INT TARGET_VECTOR_ALIGNMENT (const_tree TYPE) 28725 This hook can be used to define the alignment for a vector of type 28726 TYPE, in order to comply with a platform ABI. The default is to 28727 require natural alignment for vector types. The alignment returned 28728 by this hook must be a power-of-two multiple of the default 28729 alignment of the vector element type. 28730 28731 -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN) 28732 If defined, a C expression to compute the alignment for stack slot. 28733 TYPE is the data type, MODE is the widest mode available, and 28734 BASIC-ALIGN is the alignment that the slot would ordinarily have. 28735 The value of this macro is used instead of that alignment to align 28736 the slot. 28737 28738 If this macro is not defined, then BASIC-ALIGN is used when TYPE is 28739 'NULL'. Otherwise, 'LOCAL_ALIGNMENT' will be used. 28740 28741 This macro is to set alignment of stack slot to the maximum 28742 alignment of all possible modes which the slot may have. 28743 28744 If the value of this macro has a type, it should be an unsigned 28745 type. 28746 28747 -- Macro: LOCAL_DECL_ALIGNMENT (DECL) 28748 If defined, a C expression to compute the alignment for a local 28749 variable DECL. 28750 28751 If this macro is not defined, then 'LOCAL_ALIGNMENT (TREE_TYPE 28752 (DECL), DECL_ALIGN (DECL))' is used. 28753 28754 One use of this macro is to increase alignment of medium-size data 28755 to make it all fit in fewer cache lines. 28756 28757 If the value of this macro has a type, it should be an unsigned 28758 type. 28759 28760 -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN) 28761 If defined, a C expression to compute the minimum required 28762 alignment for dynamic stack realignment purposes for EXP (a type or 28763 decl), MODE, assuming normal alignment ALIGN. 28764 28765 If this macro is not defined, then ALIGN will be used. 28766 28767 -- Macro: EMPTY_FIELD_BOUNDARY 28768 Alignment in bits to be given to a structure bit-field that follows 28769 an empty field such as 'int : 0;'. 28770 28771 If 'PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 28772 28773 -- Macro: STRUCTURE_SIZE_BOUNDARY 28774 Number of bits which any structure or union's size must be a 28775 multiple of. Each structure or union's size is rounded up to a 28776 multiple of this. 28777 28778 If you do not define this macro, the default is the same as 28779 'BITS_PER_UNIT'. 28780 28781 -- Macro: STRICT_ALIGNMENT 28782 Define this macro to be the value 1 if instructions will fail to 28783 work if given data not on the nominal alignment. If instructions 28784 will merely go slower in that case, define this macro as 0. 28785 28786 -- Macro: PCC_BITFIELD_TYPE_MATTERS 28787 Define this if you wish to imitate the way many other C compilers 28788 handle alignment of bit-fields and the structures that contain 28789 them. 28790 28791 The behavior is that the type written for a named bit-field ('int', 28792 'short', or other integer type) imposes an alignment for the entire 28793 structure, as if the structure really did contain an ordinary field 28794 of that type. In addition, the bit-field is placed within the 28795 structure so that it would fit within such a field, not crossing a 28796 boundary for it. 28797 28798 Thus, on most machines, a named bit-field whose type is written as 28799 'int' would not cross a four-byte boundary, and would force 28800 four-byte alignment for the whole structure. (The alignment used 28801 may not be four bytes; it is controlled by the other alignment 28802 parameters.) 28803 28804 An unnamed bit-field will not affect the alignment of the 28805 containing structure. 28806 28807 If the macro is defined, its definition should be a C expression; a 28808 nonzero value for the expression enables this behavior. 28809 28810 Note that if this macro is not defined, or its value is zero, some 28811 bit-fields may cross more than one alignment boundary. The 28812 compiler can support such references if there are 'insv', 'extv', 28813 and 'extzv' insns that can directly reference memory. 28814 28815 The other known way of making bit-fields work is to define 28816 'STRUCTURE_SIZE_BOUNDARY' as large as 'BIGGEST_ALIGNMENT'. Then 28817 every structure can be accessed with fullwords. 28818 28819 Unless the machine has bit-field instructions or you define 28820 'STRUCTURE_SIZE_BOUNDARY' that way, you must define 28821 'PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 28822 28823 If your aim is to make GCC use the same conventions for laying out 28824 bit-fields as are used by another compiler, here is how to 28825 investigate what the other compiler does. Compile and run this 28826 program: 28827 28828 struct foo1 28829 { 28830 char x; 28831 char :0; 28832 char y; 28833 }; 28834 28835 struct foo2 28836 { 28837 char x; 28838 int :0; 28839 char y; 28840 }; 28841 28842 main () 28843 { 28844 printf ("Size of foo1 is %d\n", 28845 sizeof (struct foo1)); 28846 printf ("Size of foo2 is %d\n", 28847 sizeof (struct foo2)); 28848 exit (0); 28849 } 28850 28851 If this prints 2 and 5, then the compiler's behavior is what you 28852 would get from 'PCC_BITFIELD_TYPE_MATTERS'. 28853 28854 -- Macro: BITFIELD_NBYTES_LIMITED 28855 Like 'PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 28856 to aligning a bit-field within the structure. 28857 28858 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void) 28859 When 'PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 28860 whether unnamed bitfields affect the alignment of the containing 28861 structure. The hook should return true if the structure should 28862 inherit the alignment requirements of an unnamed bitfield's type. 28863 28864 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void) 28865 This target hook should return 'true' if accesses to volatile 28866 bitfields should use the narrowest mode possible. It should return 28867 'false' if these accesses should use the bitfield container type. 28868 28869 The default is 'false'. 28870 28871 -- Target Hook: bool TARGET_MEMBER_TYPE_FORCES_BLK (const_tree FIELD, 28872 machine_mode MODE) 28873 Return true if a structure, union or array containing FIELD should 28874 be accessed using 'BLKMODE'. 28875 28876 If FIELD is the only field in the structure, MODE is its mode, 28877 otherwise MODE is VOIDmode. MODE is provided in the case where 28878 structures of one field would require the structure's mode to 28879 retain the field's mode. 28880 28881 Normally, this is not needed. 28882 28883 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 28884 Define this macro as an expression for the alignment of a type 28885 (given by TYPE as a tree node) if the alignment computed in the 28886 usual way is COMPUTED and the alignment explicitly specified was 28887 SPECIFIED. 28888 28889 The default is to use SPECIFIED if it is larger; otherwise, use the 28890 smaller of COMPUTED and 'BIGGEST_ALIGNMENT' 28891 28892 -- Macro: MAX_FIXED_MODE_SIZE 28893 An integer expression for the size in bits of the largest integer 28894 machine mode that should actually be used. All integer machine 28895 modes of this size or smaller can be used for structures and unions 28896 with the appropriate sizes. If this macro is undefined, 28897 'GET_MODE_BITSIZE (DImode)' is assumed. 28898 28899 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 28900 If defined, an expression of type 'machine_mode' that specifies the 28901 mode of the save area operand of a 'save_stack_LEVEL' named pattern 28902 (*note Standard Names::). SAVE_LEVEL is one of 'SAVE_BLOCK', 28903 'SAVE_FUNCTION', or 'SAVE_NONLOCAL' and selects which of the three 28904 named patterns is having its mode specified. 28905 28906 You need not define this macro if it always returns 'Pmode'. You 28907 would most commonly define this macro if the 'save_stack_LEVEL' 28908 patterns need to support both a 32- and a 64-bit mode. 28909 28910 -- Macro: STACK_SIZE_MODE 28911 If defined, an expression of type 'machine_mode' that specifies the 28912 mode of the size increment operand of an 'allocate_stack' named 28913 pattern (*note Standard Names::). 28914 28915 You need not define this macro if it always returns 'word_mode'. 28916 You would most commonly define this macro if the 'allocate_stack' 28917 pattern needs to support both a 32- and a 64-bit mode. 28918 28919 -- Target Hook: machine_mode TARGET_LIBGCC_CMP_RETURN_MODE (void) 28920 This target hook should return the mode to be used for the return 28921 value of compare instructions expanded to libgcc calls. If not 28922 defined 'word_mode' is returned which is the right choice for a 28923 majority of targets. 28924 28925 -- Target Hook: machine_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void) 28926 This target hook should return the mode to be used for the shift 28927 count operand of shift instructions expanded to libgcc calls. If 28928 not defined 'word_mode' is returned which is the right choice for a 28929 majority of targets. 28930 28931 -- Target Hook: machine_mode TARGET_UNWIND_WORD_MODE (void) 28932 Return machine mode to be used for '_Unwind_Word' type. The 28933 default is to use 'word_mode'. 28934 28935 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 28936 RECORD_TYPE) 28937 This target hook returns 'true' if bit-fields in the given 28938 RECORD_TYPE are to be laid out following the rules of Microsoft 28939 Visual C/C++, namely: (i) a bit-field won't share the same storage 28940 unit with the previous bit-field if their underlying types have 28941 different sizes, and the bit-field will be aligned to the highest 28942 alignment of the underlying types of itself and of the previous 28943 bit-field; (ii) a zero-sized bit-field will affect the alignment of 28944 the whole enclosing structure, even if it is unnamed; except that 28945 (iii) a zero-sized bit-field will be disregarded unless it follows 28946 another bit-field of nonzero size. If this hook returns 'true', 28947 other macros that control bit-field layout are ignored. 28948 28949 When a bit-field is inserted into a packed record, the whole size 28950 of the underlying type is used by one or more same-size adjacent 28951 bit-fields (that is, if its long:3, 32 bits is used in the record, 28952 and any additional adjacent long bit-fields are packed into the 28953 same chunk of 32 bits. However, if the size changes, a new field 28954 of that size is allocated). In an unpacked record, this is the 28955 same as using alignment, but not equivalent when packing. 28956 28957 If both MS bit-fields and '__attribute__((packed))' are used, the 28958 latter will take precedence. If '__attribute__((packed))' is used 28959 on a single field when MS bit-fields are in use, it will take 28960 precedence for that field, but the alignment of the rest of the 28961 structure may affect its placement. 28962 28963 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 28964 Returns true if the target supports decimal floating point. 28965 28966 -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void) 28967 Returns true if the target supports fixed-point arithmetic. 28968 28969 -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void) 28970 This hook is called just before expansion into rtl, allowing the 28971 target to perform additional initializations or analysis before the 28972 expansion. For example, the rs6000 port uses it to allocate a 28973 scratch stack slot for use in copying SDmode values between memory 28974 and floating point registers whenever the function being expanded 28975 has any SDmode usage. 28976 28977 -- Target Hook: void TARGET_INSTANTIATE_DECLS (void) 28978 This hook allows the backend to perform additional instantiations 28979 on rtl that are not actually in any insns yet, but will be later. 28980 28981 -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE) 28982 If your target defines any fundamental types, or any types your 28983 target uses should be mangled differently from the default, define 28984 this hook to return the appropriate encoding for these types as 28985 part of a C++ mangled name. The TYPE argument is the tree 28986 structure representing the type to be mangled. The hook may be 28987 applied to trees which are not target-specific fundamental types; 28988 it should return 'NULL' for all such types, as well as arguments it 28989 does not recognize. If the return value is not 'NULL', it must 28990 point to a statically-allocated string constant. 28991 28992 Target-specific fundamental types might be new fundamental types or 28993 qualified versions of ordinary fundamental types. Encode new 28994 fundamental types as 'u N NAME', where NAME is the name used for 28995 the type in source code, and N is the length of NAME in decimal. 28996 Encode qualified versions of ordinary types as 'U N NAME CODE', 28997 where NAME is the name used for the type qualifier in source code, 28998 N is the length of NAME as above, and CODE is the code used to 28999 represent the unqualified version of this type. (See 29000 'write_builtin_type' in 'cp/mangle.c' for the list of codes.) In 29001 both cases the spaces are for clarity; do not include any spaces in 29002 your string. 29003 29004 This hook is applied to types prior to typedef resolution. If the 29005 mangled name for a particular type depends only on that type's main 29006 variant, you can perform typedef resolution yourself using 29007 'TYPE_MAIN_VARIANT' before mangling. 29008 29009 The default version of this hook always returns 'NULL', which is 29010 appropriate for a target that does not define any new fundamental 29011 types. 29012 29013 29014File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 29015 2901617.6 Layout of Source Language Data Types 29017========================================= 29018 29019These macros define the sizes and other characteristics of the standard 29020basic data types used in programs being compiled. Unlike the macros in 29021the previous section, these apply to specific features of C and related 29022languages, rather than to fundamental aspects of storage layout. 29023 29024 -- Macro: INT_TYPE_SIZE 29025 A C expression for the size in bits of the type 'int' on the target 29026 machine. If you don't define this, the default is one word. 29027 29028 -- Macro: SHORT_TYPE_SIZE 29029 A C expression for the size in bits of the type 'short' on the 29030 target machine. If you don't define this, the default is half a 29031 word. (If this would be less than one storage unit, it is rounded 29032 up to one unit.) 29033 29034 -- Macro: LONG_TYPE_SIZE 29035 A C expression for the size in bits of the type 'long' on the 29036 target machine. If you don't define this, the default is one word. 29037 29038 -- Macro: ADA_LONG_TYPE_SIZE 29039 On some machines, the size used for the Ada equivalent of the type 29040 'long' by a native Ada compiler differs from that used by C. In 29041 that situation, define this macro to be a C expression to be used 29042 for the size of that type. If you don't define this, the default 29043 is the value of 'LONG_TYPE_SIZE'. 29044 29045 -- Macro: LONG_LONG_TYPE_SIZE 29046 A C expression for the size in bits of the type 'long long' on the 29047 target machine. If you don't define this, the default is two 29048 words. If you want to support GNU Ada on your machine, the value 29049 of this macro must be at least 64. 29050 29051 -- Macro: CHAR_TYPE_SIZE 29052 A C expression for the size in bits of the type 'char' on the 29053 target machine. If you don't define this, the default is 29054 'BITS_PER_UNIT'. 29055 29056 -- Macro: BOOL_TYPE_SIZE 29057 A C expression for the size in bits of the C++ type 'bool' and C99 29058 type '_Bool' on the target machine. If you don't define this, and 29059 you probably shouldn't, the default is 'CHAR_TYPE_SIZE'. 29060 29061 -- Macro: FLOAT_TYPE_SIZE 29062 A C expression for the size in bits of the type 'float' on the 29063 target machine. If you don't define this, the default is one word. 29064 29065 -- Macro: DOUBLE_TYPE_SIZE 29066 A C expression for the size in bits of the type 'double' on the 29067 target machine. If you don't define this, the default is two 29068 words. 29069 29070 -- Macro: LONG_DOUBLE_TYPE_SIZE 29071 A C expression for the size in bits of the type 'long double' on 29072 the target machine. If you don't define this, the default is two 29073 words. 29074 29075 -- Macro: SHORT_FRACT_TYPE_SIZE 29076 A C expression for the size in bits of the type 'short _Fract' on 29077 the target machine. If you don't define this, the default is 29078 'BITS_PER_UNIT'. 29079 29080 -- Macro: FRACT_TYPE_SIZE 29081 A C expression for the size in bits of the type '_Fract' on the 29082 target machine. If you don't define this, the default is 29083 'BITS_PER_UNIT * 2'. 29084 29085 -- Macro: LONG_FRACT_TYPE_SIZE 29086 A C expression for the size in bits of the type 'long _Fract' on 29087 the target machine. If you don't define this, the default is 29088 'BITS_PER_UNIT * 4'. 29089 29090 -- Macro: LONG_LONG_FRACT_TYPE_SIZE 29091 A C expression for the size in bits of the type 'long long _Fract' 29092 on the target machine. If you don't define this, the default is 29093 'BITS_PER_UNIT * 8'. 29094 29095 -- Macro: SHORT_ACCUM_TYPE_SIZE 29096 A C expression for the size in bits of the type 'short _Accum' on 29097 the target machine. If you don't define this, the default is 29098 'BITS_PER_UNIT * 2'. 29099 29100 -- Macro: ACCUM_TYPE_SIZE 29101 A C expression for the size in bits of the type '_Accum' on the 29102 target machine. If you don't define this, the default is 29103 'BITS_PER_UNIT * 4'. 29104 29105 -- Macro: LONG_ACCUM_TYPE_SIZE 29106 A C expression for the size in bits of the type 'long _Accum' on 29107 the target machine. If you don't define this, the default is 29108 'BITS_PER_UNIT * 8'. 29109 29110 -- Macro: LONG_LONG_ACCUM_TYPE_SIZE 29111 A C expression for the size in bits of the type 'long long _Accum' 29112 on the target machine. If you don't define this, the default is 29113 'BITS_PER_UNIT * 16'. 29114 29115 -- Macro: LIBGCC2_GNU_PREFIX 29116 This macro corresponds to the 'TARGET_LIBFUNC_GNU_PREFIX' target 29117 hook and should be defined if that hook is overriden to be true. 29118 It causes function names in libgcc to be changed to use a '__gnu_' 29119 prefix for their name rather than the default '__'. A port which 29120 uses this macro should also arrange to use 't-gnu-prefix' in the 29121 libgcc 'config.host'. 29122 29123 -- Macro: TARGET_FLT_EVAL_METHOD 29124 A C expression for the value for 'FLT_EVAL_METHOD' in 'float.h', 29125 assuming, if applicable, that the floating-point control word is in 29126 its default state. If you do not define this macro the value of 29127 'FLT_EVAL_METHOD' will be zero. 29128 29129 -- Macro: WIDEST_HARDWARE_FP_SIZE 29130 A C expression for the size in bits of the widest floating-point 29131 format supported by the hardware. If you define this macro, you 29132 must specify a value less than or equal to the value of 29133 'LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 29134 value of 'LONG_DOUBLE_TYPE_SIZE' is the default. 29135 29136 -- Macro: DEFAULT_SIGNED_CHAR 29137 An expression whose value is 1 or 0, according to whether the type 29138 'char' should be signed or unsigned by default. The user can 29139 always override this default with the options '-fsigned-char' and 29140 '-funsigned-char'. 29141 29142 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 29143 This target hook should return true if the compiler should give an 29144 'enum' type only as many bytes as it takes to represent the range 29145 of possible values of that type. It should return false if all 29146 'enum' types should be allocated like 'int'. 29147 29148 The default is to return false. 29149 29150 -- Macro: SIZE_TYPE 29151 A C expression for a string describing the name of the data type to 29152 use for size values. The typedef name 'size_t' is defined using 29153 the contents of the string. 29154 29155 The string can contain more than one keyword. If so, separate them 29156 with spaces, and write first any length keyword, then 'unsigned' if 29157 appropriate, and finally 'int'. The string must exactly match one 29158 of the data type names defined in the function 29159 'c_common_nodes_and_builtins' in the file 'c-family/c-common.c'. 29160 You may not omit 'int' or change the order--that would cause the 29161 compiler to crash on startup. 29162 29163 If you don't define this macro, the default is '"long unsigned 29164 int"'. 29165 29166 -- Macro: SIZETYPE 29167 GCC defines internal types ('sizetype', 'ssizetype', 'bitsizetype' 29168 and 'sbitsizetype') for expressions dealing with size. This macro 29169 is a C expression for a string describing the name of the data type 29170 from which the precision of 'sizetype' is extracted. 29171 29172 The string has the same restrictions as 'SIZE_TYPE' string. 29173 29174 If you don't define this macro, the default is 'SIZE_TYPE'. 29175 29176 -- Macro: PTRDIFF_TYPE 29177 A C expression for a string describing the name of the data type to 29178 use for the result of subtracting two pointers. The typedef name 29179 'ptrdiff_t' is defined using the contents of the string. See 29180 'SIZE_TYPE' above for more information. 29181 29182 If you don't define this macro, the default is '"long int"'. 29183 29184 -- Macro: WCHAR_TYPE 29185 A C expression for a string describing the name of the data type to 29186 use for wide characters. The typedef name 'wchar_t' is defined 29187 using the contents of the string. See 'SIZE_TYPE' above for more 29188 information. 29189 29190 If you don't define this macro, the default is '"int"'. 29191 29192 -- Macro: WCHAR_TYPE_SIZE 29193 A C expression for the size in bits of the data type for wide 29194 characters. This is used in 'cpp', which cannot make use of 29195 'WCHAR_TYPE'. 29196 29197 -- Macro: WINT_TYPE 29198 A C expression for a string describing the name of the data type to 29199 use for wide characters passed to 'printf' and returned from 29200 'getwc'. The typedef name 'wint_t' is defined using the contents 29201 of the string. See 'SIZE_TYPE' above for more information. 29202 29203 If you don't define this macro, the default is '"unsigned int"'. 29204 29205 -- Macro: INTMAX_TYPE 29206 A C expression for a string describing the name of the data type 29207 that can represent any value of any standard or extended signed 29208 integer type. The typedef name 'intmax_t' is defined using the 29209 contents of the string. See 'SIZE_TYPE' above for more 29210 information. 29211 29212 If you don't define this macro, the default is the first of 29213 '"int"', '"long int"', or '"long long int"' that has as much 29214 precision as 'long long int'. 29215 29216 -- Macro: UINTMAX_TYPE 29217 A C expression for a string describing the name of the data type 29218 that can represent any value of any standard or extended unsigned 29219 integer type. The typedef name 'uintmax_t' is defined using the 29220 contents of the string. See 'SIZE_TYPE' above for more 29221 information. 29222 29223 If you don't define this macro, the default is the first of 29224 '"unsigned int"', '"long unsigned int"', or '"long long unsigned 29225 int"' that has as much precision as 'long long unsigned int'. 29226 29227 -- Macro: SIG_ATOMIC_TYPE 29228 -- Macro: INT8_TYPE 29229 -- Macro: INT16_TYPE 29230 -- Macro: INT32_TYPE 29231 -- Macro: INT64_TYPE 29232 -- Macro: UINT8_TYPE 29233 -- Macro: UINT16_TYPE 29234 -- Macro: UINT32_TYPE 29235 -- Macro: UINT64_TYPE 29236 -- Macro: INT_LEAST8_TYPE 29237 -- Macro: INT_LEAST16_TYPE 29238 -- Macro: INT_LEAST32_TYPE 29239 -- Macro: INT_LEAST64_TYPE 29240 -- Macro: UINT_LEAST8_TYPE 29241 -- Macro: UINT_LEAST16_TYPE 29242 -- Macro: UINT_LEAST32_TYPE 29243 -- Macro: UINT_LEAST64_TYPE 29244 -- Macro: INT_FAST8_TYPE 29245 -- Macro: INT_FAST16_TYPE 29246 -- Macro: INT_FAST32_TYPE 29247 -- Macro: INT_FAST64_TYPE 29248 -- Macro: UINT_FAST8_TYPE 29249 -- Macro: UINT_FAST16_TYPE 29250 -- Macro: UINT_FAST32_TYPE 29251 -- Macro: UINT_FAST64_TYPE 29252 -- Macro: INTPTR_TYPE 29253 -- Macro: UINTPTR_TYPE 29254 C expressions for the standard types 'sig_atomic_t', 'int8_t', 29255 'int16_t', 'int32_t', 'int64_t', 'uint8_t', 'uint16_t', 'uint32_t', 29256 'uint64_t', 'int_least8_t', 'int_least16_t', 'int_least32_t', 29257 'int_least64_t', 'uint_least8_t', 'uint_least16_t', 29258 'uint_least32_t', 'uint_least64_t', 'int_fast8_t', 'int_fast16_t', 29259 'int_fast32_t', 'int_fast64_t', 'uint_fast8_t', 'uint_fast16_t', 29260 'uint_fast32_t', 'uint_fast64_t', 'intptr_t', and 'uintptr_t'. See 29261 'SIZE_TYPE' above for more information. 29262 29263 If any of these macros evaluates to a null pointer, the 29264 corresponding type is not supported; if GCC is configured to 29265 provide '<stdint.h>' in such a case, the header provided may not 29266 conform to C99, depending on the type in question. The defaults 29267 for all of these macros are null pointers. 29268 29269 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 29270 The C++ compiler represents a pointer-to-member-function with a 29271 struct that looks like: 29272 29273 struct { 29274 union { 29275 void (*fn)(); 29276 ptrdiff_t vtable_index; 29277 }; 29278 ptrdiff_t delta; 29279 }; 29280 29281 The C++ compiler must use one bit to indicate whether the function 29282 that will be called through a pointer-to-member-function is 29283 virtual. Normally, we assume that the low-order bit of a function 29284 pointer must always be zero. Then, by ensuring that the 29285 vtable_index is odd, we can distinguish which variant of the union 29286 is in use. But, on some platforms function pointers can be odd, 29287 and so this doesn't work. In that case, we use the low-order bit 29288 of the 'delta' field, and shift the remainder of the 'delta' field 29289 to the left. 29290 29291 GCC will automatically make the right selection about where to 29292 store this bit using the 'FUNCTION_BOUNDARY' setting for your 29293 platform. However, some platforms such as ARM/Thumb have 29294 'FUNCTION_BOUNDARY' set such that functions always start at even 29295 addresses, but the lowest bit of pointers to functions indicate 29296 whether the function at that address is in ARM or Thumb mode. If 29297 this is the case of your architecture, you should define this macro 29298 to 'ptrmemfunc_vbit_in_delta'. 29299 29300 In general, you should not have to define this macro. On 29301 architectures in which function addresses are always even, 29302 according to 'FUNCTION_BOUNDARY', GCC will automatically define 29303 this macro to 'ptrmemfunc_vbit_in_pfn'. 29304 29305 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 29306 Normally, the C++ compiler uses function pointers in vtables. This 29307 macro allows the target to change to use "function descriptors" 29308 instead. Function descriptors are found on targets for whom a 29309 function pointer is actually a small data structure. Normally the 29310 data structure consists of the actual code address plus a data 29311 pointer to which the function's data is relative. 29312 29313 If vtables are used, the value of this macro should be the number 29314 of words that the function descriptor occupies. 29315 29316 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 29317 By default, the vtable entries are void pointers, the so the 29318 alignment is the same as pointer alignment. The value of this 29319 macro specifies the alignment of the vtable entry in bits. It 29320 should be defined only when special alignment is necessary. */ 29321 29322 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 29323 There are a few non-descriptor entries in the vtable at offsets 29324 below zero. If these entries must be padded (say, to preserve the 29325 alignment specified by 'TARGET_VTABLE_ENTRY_ALIGN'), set this to 29326 the number of words in each data entry. 29327 29328 29329File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 29330 2933117.7 Register Usage 29332=================== 29333 29334This section explains how to describe what registers the target machine 29335has, and how (in general) they can be used. 29336 29337 The description of which registers a specific instruction can use is 29338done with register classes; see *note Register Classes::. For 29339information on using registers to access a stack frame, see *note Frame 29340Registers::. For passing values in registers, see *note Register 29341Arguments::. For returning values in registers, see *note Scalar 29342Return::. 29343 29344* Menu: 29345 29346* Register Basics:: Number and kinds of registers. 29347* Allocation Order:: Order in which registers are allocated. 29348* Values in Registers:: What kinds of values each reg can hold. 29349* Leaf Functions:: Renumbering registers for leaf functions. 29350* Stack Registers:: Handling a register stack such as 80387. 29351 29352 29353File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 29354 2935517.7.1 Basic Characteristics of Registers 29356----------------------------------------- 29357 29358Registers have various characteristics. 29359 29360 -- Macro: FIRST_PSEUDO_REGISTER 29361 Number of hardware registers known to the compiler. They receive 29362 numbers 0 through 'FIRST_PSEUDO_REGISTER-1'; thus, the first pseudo 29363 register's number really is assigned the number 29364 'FIRST_PSEUDO_REGISTER'. 29365 29366 -- Macro: FIXED_REGISTERS 29367 An initializer that says which registers are used for fixed 29368 purposes all throughout the compiled code and are therefore not 29369 available for general allocation. These would include the stack 29370 pointer, the frame pointer (except on machines where that can be 29371 used as a general register when no frame pointer is needed), the 29372 program counter on machines where that is considered one of the 29373 addressable registers, and any other numbered register with a 29374 standard use. 29375 29376 This information is expressed as a sequence of numbers, separated 29377 by commas and surrounded by braces. The Nth number is 1 if 29378 register N is fixed, 0 otherwise. 29379 29380 The table initialized from this macro, and the table initialized by 29381 the following one, may be overridden at run time either 29382 automatically, by the actions of the macro 29383 'CONDITIONAL_REGISTER_USAGE', or by the user with the command 29384 options '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG'. 29385 29386 -- Macro: CALL_USED_REGISTERS 29387 Like 'FIXED_REGISTERS' but has 1 for each register that is 29388 clobbered (in general) by function calls as well as for fixed 29389 registers. This macro therefore identifies the registers that are 29390 not available for general allocation of values that must live 29391 across function calls. 29392 29393 If a register has 0 in 'CALL_USED_REGISTERS', the compiler 29394 automatically saves it on function entry and restores it on 29395 function exit, if the register is used within the function. 29396 29397 -- Macro: CALL_REALLY_USED_REGISTERS 29398 Like 'CALL_USED_REGISTERS' except this macro doesn't require that 29399 the entire set of 'FIXED_REGISTERS' be included. 29400 ('CALL_USED_REGISTERS' must be a superset of 'FIXED_REGISTERS'). 29401 This macro is optional. If not specified, it defaults to the value 29402 of 'CALL_USED_REGISTERS'. 29403 29404 -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE) 29405 A C expression that is nonzero if it is not permissible to store a 29406 value of mode MODE in hard register number REGNO across a call 29407 without some part of it being clobbered. For most machines this 29408 macro need not be defined. It is only required for machines that 29409 do not preserve the entire contents of a register across a call. 29410 29411 -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void) 29412 This hook may conditionally modify five variables 'fixed_regs', 29413 'call_used_regs', 'global_regs', 'reg_names', and 29414 'reg_class_contents', to take into account any dependence of these 29415 register sets on target flags. The first three of these are of 29416 type 'char []' (interpreted as Boolean vectors). 'global_regs' is 29417 a 'const char *[]', and 'reg_class_contents' is a 'HARD_REG_SET'. 29418 Before the macro is called, 'fixed_regs', 'call_used_regs', 29419 'reg_class_contents', and 'reg_names' have been initialized from 29420 'FIXED_REGISTERS', 'CALL_USED_REGISTERS', 'REG_CLASS_CONTENTS', and 29421 'REGISTER_NAMES', respectively. 'global_regs' has been cleared, 29422 and any '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG' 29423 command options have been applied. 29424 29425 If the usage of an entire class of registers depends on the target 29426 flags, you may indicate this to GCC by using this macro to modify 29427 'fixed_regs' and 'call_used_regs' to 1 for each of the registers in 29428 the classes which should not be used by GCC. Also make 29429 'define_register_constraint's return 'NO_REGS' for constraints that 29430 shouldn't be used. 29431 29432 (However, if this class is not included in 'GENERAL_REGS' and all 29433 of the insn patterns whose constraints permit this class are 29434 controlled by target switches, then GCC will automatically avoid 29435 using these registers when the target switches are opposed to 29436 them.) 29437 29438 -- Macro: INCOMING_REGNO (OUT) 29439 Define this macro if the target machine has register windows. This 29440 C expression returns the register number as seen by the called 29441 function corresponding to the register number OUT as seen by the 29442 calling function. Return OUT if register number OUT is not an 29443 outbound register. 29444 29445 -- Macro: OUTGOING_REGNO (IN) 29446 Define this macro if the target machine has register windows. This 29447 C expression returns the register number as seen by the calling 29448 function corresponding to the register number IN as seen by the 29449 called function. Return IN if register number IN is not an inbound 29450 register. 29451 29452 -- Macro: LOCAL_REGNO (REGNO) 29453 Define this macro if the target machine has register windows. This 29454 C expression returns true if the register is call-saved but is in 29455 the register window. Unlike most call-saved registers, such 29456 registers need not be explicitly restored on function exit or 29457 during non-local gotos. 29458 29459 -- Macro: PC_REGNUM 29460 If the program counter has a register number, define this as that 29461 register number. Otherwise, do not define it. 29462 29463 29464File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 29465 2946617.7.2 Order of Allocation of Registers 29467--------------------------------------- 29468 29469Registers are allocated in order. 29470 29471 -- Macro: REG_ALLOC_ORDER 29472 If defined, an initializer for a vector of integers, containing the 29473 numbers of hard registers in the order in which GCC should prefer 29474 to use them (from most preferred to least). 29475 29476 If this macro is not defined, registers are used lowest numbered 29477 first (all else being equal). 29478 29479 One use of this macro is on machines where the highest numbered 29480 registers must always be saved and the save-multiple-registers 29481 instruction supports only sequences of consecutive registers. On 29482 such machines, define 'REG_ALLOC_ORDER' to be an initializer that 29483 lists the highest numbered allocable register first. 29484 29485 -- Macro: ADJUST_REG_ALLOC_ORDER 29486 A C statement (sans semicolon) to choose the order in which to 29487 allocate hard registers for pseudo-registers local to a basic 29488 block. 29489 29490 Store the desired register order in the array 'reg_alloc_order'. 29491 Element 0 should be the register to allocate first; element 1, the 29492 next register; and so on. 29493 29494 The macro body should not assume anything about the contents of 29495 'reg_alloc_order' before execution of the macro. 29496 29497 On most machines, it is not necessary to define this macro. 29498 29499 -- Macro: HONOR_REG_ALLOC_ORDER 29500 Normally, IRA tries to estimate the costs for saving a register in 29501 the prologue and restoring it in the epilogue. This discourages it 29502 from using call-saved registers. If a machine wants to ensure that 29503 IRA allocates registers in the order given by REG_ALLOC_ORDER even 29504 if some call-saved registers appear earlier than call-used ones, 29505 then define this macro as a C expression to nonzero. Default is 0. 29506 29507 -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO) 29508 In some case register allocation order is not enough for the 29509 Integrated Register Allocator (IRA) to generate a good code. If 29510 this macro is defined, it should return a floating point value 29511 based on REGNO. The cost of using REGNO for a pseudo will be 29512 increased by approximately the pseudo's usage frequency times the 29513 value returned by this macro. Not defining this macro is 29514 equivalent to having it always return '0.0'. 29515 29516 On most machines, it is not necessary to define this macro. 29517 29518 29519File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 29520 2952117.7.3 How Values Fit in Registers 29522---------------------------------- 29523 29524This section discusses the macros that describe which kinds of values 29525(specifically, which machine modes) each register can hold, and how many 29526consecutive registers are needed for a given mode. 29527 29528 -- Macro: HARD_REGNO_NREGS (REGNO, MODE) 29529 A C expression for the number of consecutive hard registers, 29530 starting at register number REGNO, required to hold a value of mode 29531 MODE. This macro must never return zero, even if a register cannot 29532 hold the requested mode - indicate that with HARD_REGNO_MODE_OK 29533 and/or CANNOT_CHANGE_MODE_CLASS instead. 29534 29535 On a machine where all registers are exactly one word, a suitable 29536 definition of this macro is 29537 29538 #define HARD_REGNO_NREGS(REGNO, MODE) \ 29539 ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ 29540 / UNITS_PER_WORD) 29541 29542 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 29543 A C expression that is nonzero if a value of mode MODE, stored in 29544 memory, ends with padding that causes it to take up more space than 29545 in registers starting at register number REGNO (as determined by 29546 multiplying GCC's notion of the size of the register when 29547 containing this mode by the number of registers returned by 29548 'HARD_REGNO_NREGS'). By default this is zero. 29549 29550 For example, if a floating-point value is stored in three 32-bit 29551 registers but takes up 128 bits in memory, then this would be 29552 nonzero. 29553 29554 This macros only needs to be defined if there are cases where 29555 'subreg_get_info' would otherwise wrongly determine that a 'subreg' 29556 can be represented by an offset to the register number, when in 29557 fact such a 'subreg' would contain some of the padding not stored 29558 in registers and so not be representable. 29559 29560 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 29561 For values of REGNO and MODE for which 29562 'HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 29563 returning the greater number of registers required to hold the 29564 value including any padding. In the example above, the value would 29565 be four. 29566 29567 -- Macro: REGMODE_NATURAL_SIZE (MODE) 29568 Define this macro if the natural size of registers that hold values 29569 of mode MODE is not the word size. It is a C expression that 29570 should give the natural size in bytes for the specified mode. It 29571 is used by the register allocator to try to optimize its results. 29572 This happens for example on SPARC 64-bit where the natural size of 29573 floating-point registers is still 32-bit. 29574 29575 -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE) 29576 A C expression that is nonzero if it is permissible to store a 29577 value of mode MODE in hard register number REGNO (or in several 29578 registers starting with that one). For a machine where all 29579 registers are equivalent, a suitable definition is 29580 29581 #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 29582 29583 You need not include code to check for the numbers of fixed 29584 registers, because the allocation mechanism considers them to be 29585 always occupied. 29586 29587 On some machines, double-precision values must be kept in even/odd 29588 register pairs. You can implement that by defining this macro to 29589 reject odd register numbers for such modes. 29590 29591 The minimum requirement for a mode to be OK in a register is that 29592 the 'movMODE' instruction pattern support moves between the 29593 register and other hard register in the same class and that moving 29594 a value into the register and back out not alter it. 29595 29596 Since the same instruction used to move 'word_mode' will work for 29597 all narrower integer modes, it is not necessary on any machine for 29598 'HARD_REGNO_MODE_OK' to distinguish between these modes, provided 29599 you define patterns 'movhi', etc., to take advantage of this. This 29600 is useful because of the interaction between 'HARD_REGNO_MODE_OK' 29601 and 'MODES_TIEABLE_P'; it is very desirable for all integer modes 29602 to be tieable. 29603 29604 Many machines have special registers for floating point arithmetic. 29605 Often people assume that floating point machine modes are allowed 29606 only in floating point registers. This is not true. Any registers 29607 that can hold integers can safely _hold_ a floating point machine 29608 mode, whether or not floating arithmetic can be done on it in those 29609 registers. Integer move instructions can be used to move the 29610 values. 29611 29612 On some machines, though, the converse is true: fixed-point machine 29613 modes may not go in floating registers. This is true if the 29614 floating registers normalize any value stored in them, because 29615 storing a non-floating value there would garble it. In this case, 29616 'HARD_REGNO_MODE_OK' should reject fixed-point machine modes in 29617 floating registers. But if the floating registers do not 29618 automatically normalize, if you can store any bit pattern in one 29619 and retrieve it unchanged without a trap, then any machine mode may 29620 go in a floating register, so you can define this macro to say so. 29621 29622 The primary significance of special floating registers is rather 29623 that they are the registers acceptable in floating point arithmetic 29624 instructions. However, this is of no concern to 29625 'HARD_REGNO_MODE_OK'. You handle it by writing the proper 29626 constraints for those instructions. 29627 29628 On some machines, the floating registers are especially slow to 29629 access, so that it is better to store a value in a stack frame than 29630 in such a register if floating point arithmetic is not being done. 29631 As long as the floating registers are not in class 'GENERAL_REGS', 29632 they will not be used unless some pattern's constraint asks for 29633 one. 29634 29635 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 29636 A C expression that is nonzero if it is OK to rename a hard 29637 register FROM to another hard register TO. 29638 29639 One common use of this macro is to prevent renaming of a register 29640 to another register that is not saved by a prologue in an interrupt 29641 handler. 29642 29643 The default is always nonzero. 29644 29645 -- Macro: MODES_TIEABLE_P (MODE1, MODE2) 29646 A C expression that is nonzero if a value of mode MODE1 is 29647 accessible in mode MODE2 without copying. 29648 29649 If 'HARD_REGNO_MODE_OK (R, MODE1)' and 'HARD_REGNO_MODE_OK (R, 29650 MODE2)' are always the same for any R, then 'MODES_TIEABLE_P 29651 (MODE1, MODE2)' should be nonzero. If they differ for any R, you 29652 should define this macro to return zero unless some other mechanism 29653 ensures the accessibility of the value in a narrower mode. 29654 29655 You should define this macro to return nonzero in as many cases as 29656 possible since doing so will allow GCC to perform better register 29657 allocation. 29658 29659 -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO) 29660 This target hook should return 'true' if it is OK to use a hard 29661 register REGNO as scratch reg in peephole2. 29662 29663 One common use of this macro is to prevent using of a register that 29664 is not saved by a prologue in an interrupt handler. 29665 29666 The default version of this hook always returns 'true'. 29667 29668 -- Macro: AVOID_CCMODE_COPIES 29669 Define this macro if the compiler should avoid copies to/from 29670 'CCmode' registers. You should only define this macro if support 29671 for copying to/from 'CCmode' is incomplete. 29672 29673 29674File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 29675 2967617.7.4 Handling Leaf Functions 29677------------------------------ 29678 29679On some machines, a leaf function (i.e., one which makes no calls) can 29680run more efficiently if it does not make its own register window. Often 29681this means it is required to receive its arguments in the registers 29682where they are passed by the caller, instead of the registers where they 29683would normally arrive. 29684 29685 The special treatment for leaf functions generally applies only when 29686other conditions are met; for example, often they may use only those 29687registers for its own variables and temporaries. We use the term "leaf 29688function" to mean a function that is suitable for this special handling, 29689so that functions with no calls are not necessarily "leaf functions". 29690 29691 GCC assigns register numbers before it knows whether the function is 29692suitable for leaf function treatment. So it needs to renumber the 29693registers in order to output a leaf function. The following macros 29694accomplish this. 29695 29696 -- Macro: LEAF_REGISTERS 29697 Name of a char vector, indexed by hard register number, which 29698 contains 1 for a register that is allowable in a candidate for leaf 29699 function treatment. 29700 29701 If leaf function treatment involves renumbering the registers, then 29702 the registers marked here should be the ones before 29703 renumbering--those that GCC would ordinarily allocate. The 29704 registers which will actually be used in the assembler code, after 29705 renumbering, should not be marked with 1 in this vector. 29706 29707 Define this macro only if the target machine offers a way to 29708 optimize the treatment of leaf functions. 29709 29710 -- Macro: LEAF_REG_REMAP (REGNO) 29711 A C expression whose value is the register number to which REGNO 29712 should be renumbered, when a function is treated as a leaf 29713 function. 29714 29715 If REGNO is a register number which should not appear in a leaf 29716 function before renumbering, then the expression should yield -1, 29717 which will cause the compiler to abort. 29718 29719 Define this macro only if the target machine offers a way to 29720 optimize the treatment of leaf functions, and registers need to be 29721 renumbered to do this. 29722 29723 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' must 29724usually treat leaf functions specially. They can test the C variable 29725'current_function_is_leaf' which is nonzero for leaf functions. 29726'current_function_is_leaf' is set prior to local register allocation and 29727is valid for the remaining compiler passes. They can also test the C 29728variable 'current_function_uses_only_leaf_regs' which is nonzero for 29729leaf functions which only use leaf registers. 29730'current_function_uses_only_leaf_regs' is valid after all passes that 29731modify the instructions have been run and is only useful if 29732'LEAF_REGISTERS' is defined. 29733 29734 29735File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 29736 2973717.7.5 Registers That Form a Stack 29738---------------------------------- 29739 29740There are special features to handle computers where some of the 29741"registers" form a stack. Stack registers are normally written by 29742pushing onto the stack, and are numbered relative to the top of the 29743stack. 29744 29745 Currently, GCC can only handle one group of stack-like registers, and 29746they must be consecutively numbered. Furthermore, the existing support 29747for stack-like registers is specific to the 80387 floating point 29748coprocessor. If you have a new architecture that uses stack-like 29749registers, you will need to do substantial work on 'reg-stack.c' and 29750write your machine description to cooperate with it, as well as defining 29751these macros. 29752 29753 -- Macro: STACK_REGS 29754 Define this if the machine has any stack-like registers. 29755 29756 -- Macro: STACK_REG_COVER_CLASS 29757 This is a cover class containing the stack registers. Define this 29758 if the machine has any stack-like registers. 29759 29760 -- Macro: FIRST_STACK_REG 29761 The number of the first stack-like register. This one is the top 29762 of the stack. 29763 29764 -- Macro: LAST_STACK_REG 29765 The number of the last stack-like register. This one is the bottom 29766 of the stack. 29767 29768 29769File: gccint.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros 29770 2977117.8 Register Classes 29772===================== 29773 29774On many machines, the numbered registers are not all equivalent. For 29775example, certain registers may not be allowed for indexed addressing; 29776certain registers may not be allowed in some instructions. These 29777machine restrictions are described to the compiler using "register 29778classes". 29779 29780 You define a number of register classes, giving each one a name and 29781saying which of the registers belong to it. Then you can specify 29782register classes that are allowed as operands to particular instruction 29783patterns. 29784 29785 In general, each register will belong to several classes. In fact, one 29786class must be named 'ALL_REGS' and contain all the registers. Another 29787class must be named 'NO_REGS' and contain no registers. Often the union 29788of two classes will be another class; however, this is not required. 29789 29790 One of the classes must be named 'GENERAL_REGS'. There is nothing 29791terribly special about the name, but the operand constraint letters 'r' 29792and 'g' specify this class. If 'GENERAL_REGS' is the same as 29793'ALL_REGS', just define it as a macro which expands to 'ALL_REGS'. 29794 29795 Order the classes so that if class X is contained in class Y then X has 29796a lower class number than Y. 29797 29798 The way classes other than 'GENERAL_REGS' are specified in operand 29799constraints is through machine-dependent operand constraint letters. 29800You can define such letters to correspond to various classes, then use 29801them in operand constraints. 29802 29803 You must define the narrowest register classes for allocatable 29804registers, so that each class either has no subclasses, or that for some 29805mode, the move cost between registers within the class is cheaper than 29806moving a register in the class to or from memory (*note Costs::). 29807 29808 You should define a class for the union of two classes whenever some 29809instruction allows both classes. For example, if an instruction allows 29810either a floating point (coprocessor) register or a general register for 29811a certain operand, you should define a class 'FLOAT_OR_GENERAL_REGS' 29812which includes both of them. Otherwise you will get suboptimal code, or 29813even internal compiler errors when reload cannot find a register in the 29814class computed via 'reg_class_subunion'. 29815 29816 You must also specify certain redundant information about the register 29817classes: for each class, which classes contain it and which ones are 29818contained in it; for each pair of classes, the largest class contained 29819in their union. 29820 29821 When a value occupying several consecutive registers is expected in a 29822certain class, all the registers used must belong to that class. 29823Therefore, register classes cannot be used to enforce a requirement for 29824a register pair to start with an even-numbered register. The way to 29825specify this requirement is with 'HARD_REGNO_MODE_OK'. 29826 29827 Register classes used for input-operands of bitwise-and or shift 29828instructions have a special requirement: each such class must have, for 29829each fixed-point machine mode, a subclass whose registers can transfer 29830that mode to or from memory. For example, on some machines, the 29831operations for single-byte values ('QImode') are limited to certain 29832registers. When this is so, each register class that is used in a 29833bitwise-and or shift instruction must have a subclass consisting of 29834registers from which single-byte values can be loaded or stored. This 29835is so that 'PREFERRED_RELOAD_CLASS' can always have a possible value to 29836return. 29837 29838 -- Data type: enum reg_class 29839 An enumerated type that must be defined with all the register class 29840 names as enumerated values. 'NO_REGS' must be first. 'ALL_REGS' 29841 must be the last register class, followed by one more enumerated 29842 value, 'LIM_REG_CLASSES', which is not a register class but rather 29843 tells how many classes there are. 29844 29845 Each register class has a number, which is the value of casting the 29846 class name to type 'int'. The number serves as an index in many of 29847 the tables described below. 29848 29849 -- Macro: N_REG_CLASSES 29850 The number of distinct register classes, defined as follows: 29851 29852 #define N_REG_CLASSES (int) LIM_REG_CLASSES 29853 29854 -- Macro: REG_CLASS_NAMES 29855 An initializer containing the names of the register classes as C 29856 string constants. These names are used in writing some of the 29857 debugging dumps. 29858 29859 -- Macro: REG_CLASS_CONTENTS 29860 An initializer containing the contents of the register classes, as 29861 integers which are bit masks. The Nth integer specifies the 29862 contents of class N. The way the integer MASK is interpreted is 29863 that register R is in the class if 'MASK & (1 << R)' is 1. 29864 29865 When the machine has more than 32 registers, an integer does not 29866 suffice. Then the integers are replaced by sub-initializers, 29867 braced groupings containing several integers. Each sub-initializer 29868 must be suitable as an initializer for the type 'HARD_REG_SET' 29869 which is defined in 'hard-reg-set.h'. In this situation, the first 29870 integer in each sub-initializer corresponds to registers 0 through 29871 31, the second integer to registers 32 through 63, and so on. 29872 29873 -- Macro: REGNO_REG_CLASS (REGNO) 29874 A C expression whose value is a register class containing hard 29875 register REGNO. In general there is more than one such class; 29876 choose a class which is "minimal", meaning that no smaller class 29877 also contains the register. 29878 29879 -- Macro: BASE_REG_CLASS 29880 A macro whose definition is the name of the class to which a valid 29881 base register must belong. A base register is one used in an 29882 address which is the register value plus a displacement. 29883 29884 -- Macro: MODE_BASE_REG_CLASS (MODE) 29885 This is a variation of the 'BASE_REG_CLASS' macro which allows the 29886 selection of a base register in a mode dependent manner. If MODE 29887 is VOIDmode then it should return the same value as 29888 'BASE_REG_CLASS'. 29889 29890 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 29891 A C expression whose value is the register class to which a valid 29892 base register must belong in order to be used in a base plus index 29893 register address. You should define this macro if base plus index 29894 addresses have different requirements than other base register 29895 uses. 29896 29897 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, ADDRESS_SPACE, OUTER_CODE, 29898 INDEX_CODE) 29899 A C expression whose value is the register class to which a valid 29900 base register for a memory reference in mode MODE to address space 29901 ADDRESS_SPACE must belong. OUTER_CODE and INDEX_CODE define the 29902 context in which the base register occurs. OUTER_CODE is the code 29903 of the immediately enclosing expression ('MEM' for the top level of 29904 an address, 'ADDRESS' for something that occurs in an 29905 'address_operand'). INDEX_CODE is the code of the corresponding 29906 index expression if OUTER_CODE is 'PLUS'; 'SCRATCH' otherwise. 29907 29908 -- Macro: INDEX_REG_CLASS 29909 A macro whose definition is the name of the class to which a valid 29910 index register must belong. An index register is one used in an 29911 address where its value is either multiplied by a scale factor or 29912 added to another register (as well as added to a displacement). 29913 29914 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 29915 A C expression which is nonzero if register number NUM is suitable 29916 for use as a base register in operand addresses. 29917 29918 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 29919 A C expression that is just like 'REGNO_OK_FOR_BASE_P', except that 29920 that expression may examine the mode of the memory reference in 29921 MODE. You should define this macro if the mode of the memory 29922 reference affects whether a register may be used as a base 29923 register. If you define this macro, the compiler will use it 29924 instead of 'REGNO_OK_FOR_BASE_P'. The mode may be 'VOIDmode' for 29925 addresses that appear outside a 'MEM', i.e., as an 29926 'address_operand'. 29927 29928 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 29929 A C expression which is nonzero if register number NUM is suitable 29930 for use as a base register in base plus index operand addresses, 29931 accessing memory in mode MODE. It may be either a suitable hard 29932 register or a pseudo register that has been allocated such a hard 29933 register. You should define this macro if base plus index 29934 addresses have different requirements than other base register 29935 uses. 29936 29937 Use of this macro is deprecated; please use the more general 29938 'REGNO_MODE_CODE_OK_FOR_BASE_P'. 29939 29940 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE, 29941 OUTER_CODE, INDEX_CODE) 29942 A C expression which is nonzero if register number NUM is suitable 29943 for use as a base register in operand addresses, accessing memory 29944 in mode MODE in address space ADDRESS_SPACE. This is similar to 29945 'REGNO_MODE_OK_FOR_BASE_P', except that that expression may examine 29946 the context in which the register appears in the memory reference. 29947 OUTER_CODE is the code of the immediately enclosing expression 29948 ('MEM' if at the top level of the address, 'ADDRESS' for something 29949 that occurs in an 'address_operand'). INDEX_CODE is the code of 29950 the corresponding index expression if OUTER_CODE is 'PLUS'; 29951 'SCRATCH' otherwise. The mode may be 'VOIDmode' for addresses that 29952 appear outside a 'MEM', i.e., as an 'address_operand'. 29953 29954 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 29955 A C expression which is nonzero if register number NUM is suitable 29956 for use as an index register in operand addresses. It may be 29957 either a suitable hard register or a pseudo register that has been 29958 allocated such a hard register. 29959 29960 The difference between an index register and a base register is 29961 that the index register may be scaled. If an address involves the 29962 sum of two registers, neither one of them scaled, then either one 29963 may be labeled the "base" and the other the "index"; but whichever 29964 labeling is used must fit the machine's constraints of which 29965 registers may serve in each capacity. The compiler will try both 29966 labelings, looking for one that is valid, and will reload one or 29967 both registers only if neither labeling works. 29968 29969 -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t 29970 RCLASS) 29971 A target hook that places additional preference on the register 29972 class to use when it is necessary to rename a register in class 29973 RCLASS to another class, or perhaps NO_REGS, if no preferred 29974 register class is found or hook 'preferred_rename_class' is not 29975 implemented. Sometimes returning a more restrictive class makes 29976 better code. For example, on ARM, thumb-2 instructions using 29977 'LO_REGS' may be smaller than instructions using 'GENERIC_REGS'. 29978 By returning 'LO_REGS' from 'preferred_rename_class', code size can 29979 be reduced. 29980 29981 -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X, 29982 reg_class_t RCLASS) 29983 A target hook that places additional restrictions on the register 29984 class to use when it is necessary to copy value X into a register 29985 in class RCLASS. The value is a register class; perhaps RCLASS, or 29986 perhaps another, smaller class. 29987 29988 The default version of this hook always returns value of 'rclass' 29989 argument. 29990 29991 Sometimes returning a more restrictive class makes better code. 29992 For example, on the 68000, when X is an integer constant that is in 29993 range for a 'moveq' instruction, the value of this macro is always 29994 'DATA_REGS' as long as RCLASS includes the data registers. 29995 Requiring a data register guarantees that a 'moveq' will be used. 29996 29997 One case where 'TARGET_PREFERRED_RELOAD_CLASS' must not return 29998 RCLASS is if X is a legitimate constant which cannot be loaded into 29999 some register class. By returning 'NO_REGS' you can force X into a 30000 memory location. For example, rs6000 can load immediate values 30001 into general-purpose registers, but does not have an instruction 30002 for loading an immediate value into a floating-point register, so 30003 'TARGET_PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 30004 floating-point constant. If the constant can't be loaded into any 30005 kind of register, code generation will be better if 30006 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 30007 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 30008 30009 If an insn has pseudos in it after register allocation, reload will 30010 go through the alternatives and call repeatedly 30011 'TARGET_PREFERRED_RELOAD_CLASS' to find the best one. Returning 30012 'NO_REGS', in this case, makes reload add a '!' in front of the 30013 constraint: the x86 back-end uses this feature to discourage usage 30014 of 387 registers when math is done in the SSE registers (and vice 30015 versa). 30016 30017 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 30018 A C expression that places additional restrictions on the register 30019 class to use when it is necessary to copy value X into a register 30020 in class CLASS. The value is a register class; perhaps CLASS, or 30021 perhaps another, smaller class. On many machines, the following 30022 definition is safe: 30023 30024 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 30025 30026 Sometimes returning a more restrictive class makes better code. 30027 For example, on the 68000, when X is an integer constant that is in 30028 range for a 'moveq' instruction, the value of this macro is always 30029 'DATA_REGS' as long as CLASS includes the data registers. 30030 Requiring a data register guarantees that a 'moveq' will be used. 30031 30032 One case where 'PREFERRED_RELOAD_CLASS' must not return CLASS is if 30033 X is a legitimate constant which cannot be loaded into some 30034 register class. By returning 'NO_REGS' you can force X into a 30035 memory location. For example, rs6000 can load immediate values 30036 into general-purpose registers, but does not have an instruction 30037 for loading an immediate value into a floating-point register, so 30038 'PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 30039 floating-point constant. If the constant can't be loaded into any 30040 kind of register, code generation will be better if 30041 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 30042 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 30043 30044 If an insn has pseudos in it after register allocation, reload will 30045 go through the alternatives and call repeatedly 30046 'PREFERRED_RELOAD_CLASS' to find the best one. Returning 30047 'NO_REGS', in this case, makes reload add a '!' in front of the 30048 constraint: the x86 back-end uses this feature to discourage usage 30049 of 387 registers when math is done in the SSE registers (and vice 30050 versa). 30051 30052 -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx 30053 X, reg_class_t RCLASS) 30054 Like 'TARGET_PREFERRED_RELOAD_CLASS', but for output reloads 30055 instead of input reloads. 30056 30057 The default version of this hook always returns value of 'rclass' 30058 argument. 30059 30060 You can also use 'TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to 30061 discourage reload from using some alternatives, like 30062 'TARGET_PREFERRED_RELOAD_CLASS'. 30063 30064 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 30065 A C expression that places additional restrictions on the register 30066 class to use when it is necessary to be able to hold a value of 30067 mode MODE in a reload register for which class CLASS would 30068 ordinarily be used. 30069 30070 Unlike 'PREFERRED_RELOAD_CLASS', this macro should be used when 30071 there are certain modes that simply can't go in certain reload 30072 classes. 30073 30074 The value is a register class; perhaps CLASS, or perhaps another, 30075 smaller class. 30076 30077 Don't define this macro unless the target machine has limitations 30078 which require the macro to do something nontrivial. 30079 30080 -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X, 30081 reg_class_t RELOAD_CLASS, machine_mode RELOAD_MODE, 30082 secondary_reload_info *SRI) 30083 Many machines have some registers that cannot be copied directly to 30084 or from memory or even from other types of registers. An example 30085 is the 'MQ' register, which on most machines, can only be copied to 30086 or from general registers, but not memory. Below, we shall be 30087 using the term 'intermediate register' when a move operation cannot 30088 be performed directly, but has to be done by copying the source 30089 into the intermediate register first, and then copying the 30090 intermediate register to the destination. An intermediate register 30091 always has the same mode as source and destination. Since it holds 30092 the actual value being copied, reload might apply optimizations to 30093 re-use an intermediate register and eliding the copy from the 30094 source when it can determine that the intermediate register still 30095 holds the required value. 30096 30097 Another kind of secondary reload is required on some machines which 30098 allow copying all registers to and from memory, but require a 30099 scratch register for stores to some memory locations (e.g., those 30100 with symbolic address on the RT, and those with certain symbolic 30101 address on the SPARC when compiling PIC). Scratch registers need 30102 not have the same mode as the value being copied, and usually hold 30103 a different value than that being copied. Special patterns in the 30104 md file are needed to describe how the copy is performed with the 30105 help of the scratch register; these patterns also describe the 30106 number, register class(es) and mode(s) of the scratch register(s). 30107 30108 In some cases, both an intermediate and a scratch register are 30109 required. 30110 30111 For input reloads, this target hook is called with nonzero IN_P, 30112 and X is an rtx that needs to be copied to a register of class 30113 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 30114 is called with zero IN_P, and a register of class RELOAD_CLASS 30115 needs to be copied to rtx X in RELOAD_MODE. 30116 30117 If copying a register of RELOAD_CLASS from/to X requires an 30118 intermediate register, the hook 'secondary_reload' should return 30119 the register class required for this intermediate register. If no 30120 intermediate register is required, it should return NO_REGS. If 30121 more than one intermediate register is required, describe the one 30122 that is closest in the copy chain to the reload register. 30123 30124 If scratch registers are needed, you also have to describe how to 30125 perform the copy from/to the reload register to/from this closest 30126 intermediate register. Or if no intermediate register is required, 30127 but still a scratch register is needed, describe the copy from/to 30128 the reload register to/from the reload operand X. 30129 30130 You do this by setting 'sri->icode' to the instruction code of a 30131 pattern in the md file which performs the move. Operands 0 and 1 30132 are the output and input of this copy, respectively. Operands from 30133 operand 2 onward are for scratch operands. These scratch operands 30134 must have a mode, and a single-register-class output constraint. 30135 30136 When an intermediate register is used, the 'secondary_reload' hook 30137 will be called again to determine how to copy the intermediate 30138 register to/from the reload operand X, so your hook must also have 30139 code to handle the register class of the intermediate operand. 30140 30141 X might be a pseudo-register or a 'subreg' of a pseudo-register, 30142 which could either be in a hard register or in memory. Use 30143 'true_regnum' to find out; it will return -1 if the pseudo is in 30144 memory and the hard register number if it is in a register. 30145 30146 Scratch operands in memory (constraint '"=m"' / '"=&m"') are 30147 currently not supported. For the time being, you will have to 30148 continue to use 'SECONDARY_MEMORY_NEEDED' for that purpose. 30149 30150 'copy_cost' also uses this target hook to find out how values are 30151 copied. If you want it to include some extra cost for the need to 30152 allocate (a) scratch register(s), set 'sri->extra_cost' to the 30153 additional cost. Or if two dependent moves are supposed to have a 30154 lower cost than the sum of the individual moves due to expected 30155 fortuitous scheduling and/or special forwarding logic, you can set 30156 'sri->extra_cost' to a negative amount. 30157 30158 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 30159 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 30160 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 30161 These macros are obsolete, new ports should use the target hook 30162 'TARGET_SECONDARY_RELOAD' instead. 30163 30164 These are obsolete macros, replaced by the 30165 'TARGET_SECONDARY_RELOAD' target hook. Older ports still define 30166 these macros to indicate to the reload phase that it may need to 30167 allocate at least one register for a reload in addition to the 30168 register to contain the data. Specifically, if copying X to a 30169 register CLASS in MODE requires an intermediate register, you were 30170 supposed to define 'SECONDARY_INPUT_RELOAD_CLASS' to return the 30171 largest register class all of whose registers can be used as 30172 intermediate registers or scratch registers. 30173 30174 If copying a register CLASS in MODE to X requires an intermediate 30175 or scratch register, 'SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 30176 to be defined be defined to return the largest register class 30177 required. If the requirements for input and output reloads were 30178 the same, the macro 'SECONDARY_RELOAD_CLASS' should have been used 30179 instead of defining both macros identically. 30180 30181 The values returned by these macros are often 'GENERAL_REGS'. 30182 Return 'NO_REGS' if no spare register is needed; i.e., if X can be 30183 directly copied to or from a register of CLASS in MODE without 30184 requiring a scratch register. Do not define this macro if it would 30185 always return 'NO_REGS'. 30186 30187 If a scratch register is required (either with or without an 30188 intermediate register), you were supposed to define patterns for 30189 'reload_inM' or 'reload_outM', as required (*note Standard Names::. 30190 These patterns, which were normally implemented with a 30191 'define_expand', should be similar to the 'movM' patterns, except 30192 that operand 2 is the scratch register. 30193 30194 These patterns need constraints for the reload register and scratch 30195 register that contain a single register class. If the original 30196 reload register (whose class is CLASS) can meet the constraint 30197 given in the pattern, the value returned by these macros is used 30198 for the class of the scratch register. Otherwise, two additional 30199 reload registers are required. Their classes are obtained from the 30200 constraints in the insn pattern. 30201 30202 X might be a pseudo-register or a 'subreg' of a pseudo-register, 30203 which could either be in a hard register or in memory. Use 30204 'true_regnum' to find out; it will return -1 if the pseudo is in 30205 memory and the hard register number if it is in a register. 30206 30207 These macros should not be used in the case where a particular 30208 class of registers can only be copied to memory and not to another 30209 class of registers. In that case, secondary reload registers are 30210 not needed and would not be helpful. Instead, a stack location 30211 must be used to perform the copy and the 'movM' pattern should use 30212 memory as an intermediate storage. This case often occurs between 30213 floating-point and general registers. 30214 30215 -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M) 30216 Certain machines have the property that some registers cannot be 30217 copied to some other registers without using memory. Define this 30218 macro on those machines to be a C expression that is nonzero if 30219 objects of mode M in registers of CLASS1 can only be copied to 30220 registers of class CLASS2 by storing a register of CLASS1 into 30221 memory and loading that memory location into a register of CLASS2. 30222 30223 Do not define this macro if its value would always be zero. 30224 30225 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 30226 Normally when 'SECONDARY_MEMORY_NEEDED' is defined, the compiler 30227 allocates a stack slot for a memory location needed for register 30228 copies. If this macro is defined, the compiler instead uses the 30229 memory location defined by this macro. 30230 30231 Do not define this macro if you do not define 30232 'SECONDARY_MEMORY_NEEDED'. 30233 30234 -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE) 30235 When the compiler needs a secondary memory location to copy between 30236 two registers of mode MODE, it normally allocates sufficient memory 30237 to hold a quantity of 'BITS_PER_WORD' bits and performs the store 30238 and load operations in a mode that many bits wide and whose class 30239 is the same as that of MODE. 30240 30241 This is right thing to do on most machines because it ensures that 30242 all bits of the register are copied and prevents accesses to the 30243 registers in a narrower mode, which some machines prohibit for 30244 floating-point registers. 30245 30246 However, this default behavior is not correct on some machines, 30247 such as the DEC Alpha, that store short integers in floating-point 30248 registers differently than in integer registers. On those 30249 machines, the default widening will not work correctly and you must 30250 define this macro to suppress that widening in some cases. See the 30251 file 'alpha.h' for details. 30252 30253 Do not define this macro if you do not define 30254 'SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is 30255 'BITS_PER_WORD' bits wide is correct for your machine. 30256 30257 -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS) 30258 A target hook which returns 'true' if pseudos that have been 30259 assigned to registers of class RCLASS would likely be spilled 30260 because registers of RCLASS are needed for spill registers. 30261 30262 The default version of this target hook returns 'true' if RCLASS 30263 has exactly one register and 'false' otherwise. On most machines, 30264 this default should be used. For generally register-starved 30265 machines, such as i386, or machines with right register 30266 constraints, such as SH, this hook can be used to avoid excessive 30267 spilling. 30268 30269 This hook is also used by some of the global intra-procedural code 30270 transformations to throtle code motion, to avoid increasing 30271 register pressure. 30272 30273 -- Target Hook: unsigned char TARGET_CLASS_MAX_NREGS (reg_class_t 30274 RCLASS, machine_mode MODE) 30275 A target hook returns the maximum number of consecutive registers 30276 of class RCLASS needed to hold a value of mode MODE. 30277 30278 This is closely related to the macro 'HARD_REGNO_NREGS'. In fact, 30279 the value returned by 'TARGET_CLASS_MAX_NREGS (RCLASS, MODE)' 30280 target hook should be the maximum value of 'HARD_REGNO_NREGS 30281 (REGNO, MODE)' for all REGNO values in the class RCLASS. 30282 30283 This target hook helps control the handling of multiple-word values 30284 in the reload pass. 30285 30286 The default version of this target hook returns the size of MODE in 30287 words. 30288 30289 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 30290 A C expression for the maximum number of consecutive registers of 30291 class CLASS needed to hold a value of mode MODE. 30292 30293 This is closely related to the macro 'HARD_REGNO_NREGS'. In fact, 30294 the value of the macro 'CLASS_MAX_NREGS (CLASS, MODE)' should be 30295 the maximum value of 'HARD_REGNO_NREGS (REGNO, MODE)' for all REGNO 30296 values in the class CLASS. 30297 30298 This macro helps control the handling of multiple-word values in 30299 the reload pass. 30300 30301 -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS) 30302 If defined, a C expression that returns nonzero for a CLASS for 30303 which a change from mode FROM to mode TO is invalid. 30304 30305 For example, loading 32-bit integer or floating-point objects into 30306 floating-point registers on Alpha extends them to 64 bits. 30307 Therefore loading a 64-bit object and then storing it as a 32-bit 30308 object does not store the low-order 32 bits, as would be the case 30309 for a normal register. Therefore, 'alpha.h' defines 30310 'CANNOT_CHANGE_MODE_CLASS' as below: 30311 30312 #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ 30313 (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ 30314 ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0) 30315 30316 Even if storing from a register in mode TO would be valid, if both 30317 FROM and 'raw_reg_mode' for CLASS are wider than 'word_mode', then 30318 we must prevent TO narrowing the mode. This happens when the 30319 middle-end assumes that it can load or store pieces of an N-word 30320 pseudo, and that the pseudo will eventually be allocated to N 30321 'word_mode' hard registers. Failure to prevent this kind of mode 30322 change will result in the entire 'raw_reg_mode' being modified 30323 instead of the partial value that the middle-end intended. 30324 30325 -- Target Hook: reg_class_t TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS 30326 (int, REG_CLASS_T, REG_CLASS_T) 30327 A target hook which can change allocno class for given pseudo from 30328 allocno and best class calculated by IRA. 30329 30330 The default version of this target hook always returns given class. 30331 30332 -- Target Hook: bool TARGET_LRA_P (void) 30333 A target hook which returns true if we use LRA instead of reload 30334 pass. The default version of this target hook returns always 30335 false, but new ports should use LRA. 30336 30337 -- Target Hook: int TARGET_REGISTER_PRIORITY (int) 30338 A target hook which returns the register priority number to which 30339 the register HARD_REGNO belongs to. The bigger the number, the 30340 more preferable the hard register usage (when all other conditions 30341 are the same). This hook can be used to prefer some hard register 30342 over others in LRA. For example, some x86-64 register usage needs 30343 additional prefix which makes instructions longer. The hook can 30344 return lower priority number for such registers make them less 30345 favorable and as result making the generated code smaller. The 30346 default version of this target hook returns always zero. 30347 30348 -- Target Hook: bool TARGET_REGISTER_USAGE_LEVELING_P (void) 30349 A target hook which returns true if we need register usage 30350 leveling. That means if a few hard registers are equally good for 30351 the assignment, we choose the least used hard register. The 30352 register usage leveling may be profitable for some targets. Don't 30353 use the usage leveling for targets with conditional execution or 30354 targets with big register files as it hurts if-conversion and 30355 cross-jumping optimizations. The default version of this target 30356 hook returns always false. 30357 30358 -- Target Hook: bool TARGET_DIFFERENT_ADDR_DISPLACEMENT_P (void) 30359 A target hook which returns true if an address with the same 30360 structure can have different maximal legitimate displacement. For 30361 example, the displacement can depend on memory mode or on operand 30362 combinations in the insn. The default version of this target hook 30363 returns always false. 30364 30365 -- Target Hook: bool TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P (rtx SUBST) 30366 A target hook which returns 'true' if SUBST can't substitute safely 30367 pseudos with equivalent memory values during register allocation. 30368 The default version of this target hook returns 'false'. On most 30369 machines, this default should be used. For generally machines with 30370 non orthogonal register usage for addressing, such as SH, this hook 30371 can be used to avoid excessive spilling. 30372 30373 -- Target Hook: bool TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT (rtx *DISP, 30374 rtx *OFFSET, machine_mode MODE) 30375 A target hook which returns 'true' if *DISP is legitimezed to valid 30376 address displacement with subtracting *OFFSET at memory mode MODE. 30377 The default version of this target hook returns 'false'. This hook 30378 will benefit machines with limited base plus displacement 30379 addressing. 30380 30381 -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t, 30382 MACHINE_MODE) 30383 This hook defines a class of registers which could be used for 30384 spilling pseudos of the given mode and class, or 'NO_REGS' if only 30385 memory should be used. Not defining this hook is equivalent to 30386 returning 'NO_REGS' for all inputs. 30387 30388 -- Target Hook: machine_mode TARGET_CSTORE_MODE (enum insn_code ICODE) 30389 This hook defines the machine mode to use for the boolean result of 30390 conditional store patterns. The ICODE argument is the instruction 30391 code for the cstore being performed. Not definiting this hook is 30392 the same as accepting the mode encoded into operand 0 of the cstore 30393 expander patterns. 30394 30395 30396File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros 30397 3039817.9 Stack Layout and Calling Conventions 30399========================================= 30400 30401This describes the stack layout and calling conventions. 30402 30403* Menu: 30404 30405* Frame Layout:: 30406* Exception Handling:: 30407* Stack Checking:: 30408* Frame Registers:: 30409* Elimination:: 30410* Stack Arguments:: 30411* Register Arguments:: 30412* Scalar Return:: 30413* Aggregate Return:: 30414* Caller Saves:: 30415* Function Entry:: 30416* Profiling:: 30417* Tail Calls:: 30418* Stack Smashing Protection:: 30419* Miscellaneous Register Hooks:: 30420 30421 30422File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 30423 3042417.9.1 Basic Stack Layout 30425------------------------- 30426 30427Here is the basic stack layout. 30428 30429 -- Macro: STACK_GROWS_DOWNWARD 30430 Define this macro to be true if pushing a word onto the stack moves 30431 the stack pointer to a smaller address, and false otherwise. 30432 30433 -- Macro: STACK_PUSH_CODE 30434 This macro defines the operation used when something is pushed on 30435 the stack. In RTL, a push operation will be '(set (mem 30436 (STACK_PUSH_CODE (reg sp))) ...)' 30437 30438 The choices are 'PRE_DEC', 'POST_DEC', 'PRE_INC', and 'POST_INC'. 30439 Which of these is correct depends on the stack direction and on 30440 whether the stack pointer points to the last item on the stack or 30441 whether it points to the space for the next item on the stack. 30442 30443 The default is 'PRE_DEC' when 'STACK_GROWS_DOWNWARD' is true, which 30444 is almost always right, and 'PRE_INC' otherwise, which is often 30445 wrong. 30446 30447 -- Macro: FRAME_GROWS_DOWNWARD 30448 Define this macro to nonzero value if the addresses of local 30449 variable slots are at negative offsets from the frame pointer. 30450 30451 -- Macro: ARGS_GROW_DOWNWARD 30452 Define this macro if successive arguments to a function occupy 30453 decreasing addresses on the stack. 30454 30455 -- Macro: STARTING_FRAME_OFFSET 30456 Offset from the frame pointer to the first local variable slot to 30457 be allocated. 30458 30459 If 'FRAME_GROWS_DOWNWARD', find the next slot's offset by 30460 subtracting the first slot's length from 'STARTING_FRAME_OFFSET'. 30461 Otherwise, it is found by adding the length of the first slot to 30462 the value 'STARTING_FRAME_OFFSET'. 30463 30464 -- Macro: STACK_ALIGNMENT_NEEDED 30465 Define to zero to disable final alignment of the stack during 30466 reload. The nonzero default for this macro is suitable for most 30467 ports. 30468 30469 On ports where 'STARTING_FRAME_OFFSET' is nonzero or where there is 30470 a register save block following the local block that doesn't 30471 require alignment to 'STACK_BOUNDARY', it may be beneficial to 30472 disable stack alignment and do it in the backend. 30473 30474 -- Macro: STACK_POINTER_OFFSET 30475 Offset from the stack pointer register to the first location at 30476 which outgoing arguments are placed. If not specified, the default 30477 value of zero is used. This is the proper value for most machines. 30478 30479 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 30480 the first location at which outgoing arguments are placed. 30481 30482 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 30483 Offset from the argument pointer register to the first argument's 30484 address. On some machines it may depend on the data type of the 30485 function. 30486 30487 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 30488 the first argument's address. 30489 30490 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 30491 Offset from the stack pointer register to an item dynamically 30492 allocated on the stack, e.g., by 'alloca'. 30493 30494 The default value for this macro is 'STACK_POINTER_OFFSET' plus the 30495 length of the outgoing arguments. The default is correct for most 30496 machines. See 'function.c' for details. 30497 30498 -- Macro: INITIAL_FRAME_ADDRESS_RTX 30499 A C expression whose value is RTL representing the address of the 30500 initial stack frame. This address is passed to 'RETURN_ADDR_RTX' 30501 and 'DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 30502 reasonable default value will be used. Define this macro in order 30503 to make frame pointer elimination work in the presence of 30504 '__builtin_frame_address (count)' and '__builtin_return_address 30505 (count)' for 'count' not equal to zero. 30506 30507 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 30508 A C expression whose value is RTL representing the address in a 30509 stack frame where the pointer to the caller's frame is stored. 30510 Assume that FRAMEADDR is an RTL expression for the address of the 30511 stack frame itself. 30512 30513 If you don't define this macro, the default is to return the value 30514 of FRAMEADDR--that is, the stack frame address is also the address 30515 of the stack word that points to the previous frame. 30516 30517 -- Macro: SETUP_FRAME_ADDRESSES 30518 A C expression that produces the machine-specific code to setup the 30519 stack so that arbitrary frames can be accessed. For example, on 30520 the SPARC, we must flush all of the register windows to the stack 30521 before we can access arbitrary stack frames. You will seldom need 30522 to define this macro. The default is to do nothing. 30523 30524 -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void) 30525 This target hook should return an rtx that is used to store the 30526 address of the current frame into the built in 'setjmp' buffer. 30527 The default value, 'virtual_stack_vars_rtx', is correct for most 30528 machines. One reason you may need to define this target hook is if 30529 'hard_frame_pointer_rtx' is the appropriate value on your machine. 30530 30531 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 30532 A C expression whose value is RTL representing the value of the 30533 frame address for the current frame. FRAMEADDR is the frame 30534 pointer of the current frame. This is used for 30535 __builtin_frame_address. You need only define this macro if the 30536 frame address is not the same as the frame pointer. Most machines 30537 do not need to define it. 30538 30539 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 30540 A C expression whose value is RTL representing the value of the 30541 return address for the frame COUNT steps up from the current frame, 30542 after the prologue. FRAMEADDR is the frame pointer of the COUNT 30543 frame, or the frame pointer of the COUNT - 1 frame if 30544 'RETURN_ADDR_IN_PREVIOUS_FRAME' is nonzero. 30545 30546 The value of the expression must always be the correct address when 30547 COUNT is zero, but may be 'NULL_RTX' if there is no way to 30548 determine the return address of other frames. 30549 30550 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 30551 Define this macro to nonzero value if the return address of a 30552 particular stack frame is accessed from the frame pointer of the 30553 previous stack frame. The zero default for this macro is suitable 30554 for most ports. 30555 30556 -- Macro: INCOMING_RETURN_ADDR_RTX 30557 A C expression whose value is RTL representing the location of the 30558 incoming return address at the beginning of any function, before 30559 the prologue. This RTL is either a 'REG', indicating that the 30560 return value is saved in 'REG', or a 'MEM' representing a location 30561 in the stack. 30562 30563 You only need to define this macro if you want to support call 30564 frame debugging information like that provided by DWARF 2. 30565 30566 If this RTL is a 'REG', you should also define 30567 'DWARF_FRAME_RETURN_COLUMN' to 'DWARF_FRAME_REGNUM (REGNO)'. 30568 30569 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 30570 A C expression whose value is an integer giving a DWARF 2 column 30571 number that may be used as an alternative return column. The 30572 column must not correspond to any gcc hard register (that is, it 30573 must not be in the range of 'DWARF_FRAME_REGNUM'). 30574 30575 This macro can be useful if 'DWARF_FRAME_RETURN_COLUMN' is set to a 30576 general register, but an alternative column needs to be used for 30577 signal frames. Some targets have also used different frame return 30578 columns over time. 30579 30580 -- Macro: DWARF_ZERO_REG 30581 A C expression whose value is an integer giving a DWARF 2 register 30582 number that is considered to always have the value zero. This 30583 should only be defined if the target has an architected zero 30584 register, and someone decided it was a good idea to use that 30585 register number to terminate the stack backtrace. New ports should 30586 avoid this. 30587 30588 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 30589 *LABEL, rtx PATTERN, int INDEX) 30590 This target hook allows the backend to emit frame-related insns 30591 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 30592 debugging info engine will invoke it on insns of the form 30593 (set (reg) (unspec [...] UNSPEC_INDEX)) 30594 and 30595 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 30596 to let the backend emit the call frame instructions. LABEL is the 30597 CFI label attached to the insn, PATTERN is the pattern of the insn 30598 and INDEX is 'UNSPEC_INDEX' or 'UNSPECV_INDEX'. 30599 30600 -- Macro: INCOMING_FRAME_SP_OFFSET 30601 A C expression whose value is an integer giving the offset, in 30602 bytes, from the value of the stack pointer register to the top of 30603 the stack frame at the beginning of any function, before the 30604 prologue. The top of the frame is defined to be the value of the 30605 stack pointer in the previous frame, just before the call 30606 instruction. 30607 30608 You only need to define this macro if you want to support call 30609 frame debugging information like that provided by DWARF 2. 30610 30611 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 30612 A C expression whose value is an integer giving the offset, in 30613 bytes, from the argument pointer to the canonical frame address 30614 (cfa). The final value should coincide with that calculated by 30615 'INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 30616 during virtual register instantiation. 30617 30618 The default value for this macro is 'FIRST_PARM_OFFSET (fundecl) + 30619 crtl->args.pretend_args_size', which is correct for most machines; 30620 in general, the arguments are found immediately before the stack 30621 frame. Note that this is not the case on some targets that save 30622 registers into the caller's frame, such as SPARC and rs6000, and so 30623 such targets need to define this macro. 30624 30625 You only need to define this macro if the default is incorrect, and 30626 you want to support call frame debugging information like that 30627 provided by DWARF 2. 30628 30629 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 30630 If defined, a C expression whose value is an integer giving the 30631 offset in bytes from the frame pointer to the canonical frame 30632 address (cfa). The final value should coincide with that 30633 calculated by 'INCOMING_FRAME_SP_OFFSET'. 30634 30635 Normally the CFA is calculated as an offset from the argument 30636 pointer, via 'ARG_POINTER_CFA_OFFSET', but if the argument pointer 30637 is variable due to the ABI, this may not be possible. If this 30638 macro is defined, it implies that the virtual register 30639 instantiation should be based on the frame pointer instead of the 30640 argument pointer. Only one of 'FRAME_POINTER_CFA_OFFSET' and 30641 'ARG_POINTER_CFA_OFFSET' should be defined. 30642 30643 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 30644 If defined, a C expression whose value is an integer giving the 30645 offset in bytes from the canonical frame address (cfa) to the frame 30646 base used in DWARF 2 debug information. The default is zero. A 30647 different value may reduce the size of debug information on some 30648 ports. 30649 30650 30651File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 30652 3065317.9.2 Exception Handling Support 30654--------------------------------- 30655 30656 -- Macro: EH_RETURN_DATA_REGNO (N) 30657 A C expression whose value is the Nth register number used for data 30658 by exception handlers, or 'INVALID_REGNUM' if fewer than N 30659 registers are usable. 30660 30661 The exception handling library routines communicate with the 30662 exception handlers via a set of agreed upon registers. Ideally 30663 these registers should be call-clobbered; it is possible to use 30664 call-saved registers, but may negatively impact code size. The 30665 target must support at least 2 data registers, but should define 4 30666 if there are enough free registers. 30667 30668 You must define this macro if you want to support call frame 30669 exception handling like that provided by DWARF 2. 30670 30671 -- Macro: EH_RETURN_STACKADJ_RTX 30672 A C expression whose value is RTL representing a location in which 30673 to store a stack adjustment to be applied before function return. 30674 This is used to unwind the stack to an exception handler's call 30675 frame. It will be assigned zero on code paths that return 30676 normally. 30677 30678 Typically this is a call-clobbered hard register that is otherwise 30679 untouched by the epilogue, but could also be a stack slot. 30680 30681 Do not define this macro if the stack pointer is saved and restored 30682 by the regular prolog and epilog code in the call frame itself; in 30683 this case, the exception handling library routines will update the 30684 stack location to be restored in place. Otherwise, you must define 30685 this macro if you want to support call frame exception handling 30686 like that provided by DWARF 2. 30687 30688 -- Macro: EH_RETURN_HANDLER_RTX 30689 A C expression whose value is RTL representing a location in which 30690 to store the address of an exception handler to which we should 30691 return. It will not be assigned on code paths that return 30692 normally. 30693 30694 Typically this is the location in the call frame at which the 30695 normal return address is stored. For targets that return by 30696 popping an address off the stack, this might be a memory address 30697 just below the _target_ call frame rather than inside the current 30698 call frame. If defined, 'EH_RETURN_STACKADJ_RTX' will have already 30699 been assigned, so it may be used to calculate the location of the 30700 target call frame. 30701 30702 Some targets have more complex requirements than storing to an 30703 address calculable during initial code generation. In that case 30704 the 'eh_return' instruction pattern should be used instead. 30705 30706 If you want to support call frame exception handling, you must 30707 define either this macro or the 'eh_return' instruction pattern. 30708 30709 -- Macro: RETURN_ADDR_OFFSET 30710 If defined, an integer-valued C expression for which rtl will be 30711 generated to add it to the exception handler address before it is 30712 searched in the exception handling tables, and to subtract it again 30713 from the address before using it to return to the exception 30714 handler. 30715 30716 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 30717 This macro chooses the encoding of pointers embedded in the 30718 exception handling sections. If at all possible, this should be 30719 defined such that the exception handling section will not require 30720 dynamic relocations, and so may be read-only. 30721 30722 CODE is 0 for data, 1 for code labels, 2 for function pointers. 30723 GLOBAL is true if the symbol may be affected by dynamic 30724 relocations. The macro should return a combination of the 30725 'DW_EH_PE_*' defines as found in 'dwarf2.h'. 30726 30727 If this macro is not defined, pointers will not be encoded but 30728 represented directly. 30729 30730 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 30731 ADDR, DONE) 30732 This macro allows the target to emit whatever special magic is 30733 required to represent the encoding chosen by 30734 'ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 30735 pc-relative and indirect encodings; this must be defined if the 30736 target uses text-relative or data-relative encodings. 30737 30738 This is a C statement that branches to DONE if the format was 30739 handled. ENCODING is the format chosen, SIZE is the number of 30740 bytes that the format occupies, ADDR is the 'SYMBOL_REF' to be 30741 emitted. 30742 30743 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 30744 This macro allows the target to add CPU and operating system 30745 specific code to the call-frame unwinder for use when there is no 30746 unwind data available. The most common reason to implement this 30747 macro is to unwind through signal frames. 30748 30749 This macro is called from 'uw_frame_state_for' in 'unwind-dw2.c', 30750 'unwind-dw2-xtensa.c' and 'unwind-ia64.c'. CONTEXT is an 30751 '_Unwind_Context'; FS is an '_Unwind_FrameState'. Examine 30752 'context->ra' for the address of the code being executed and 30753 'context->cfa' for the stack pointer value. If the frame can be 30754 decoded, the register save addresses should be updated in FS and 30755 the macro should evaluate to '_URC_NO_REASON'. If the frame cannot 30756 be decoded, the macro should evaluate to '_URC_END_OF_STACK'. 30757 30758 For proper signal handling in Java this macro is accompanied by 30759 'MAKE_THROW_FRAME', defined in 'libjava/include/*-signal.h' 30760 headers. 30761 30762 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 30763 This macro allows the target to add operating system specific code 30764 to the call-frame unwinder to handle the IA-64 '.unwabi' unwinding 30765 directive, usually used for signal or interrupt frames. 30766 30767 This macro is called from 'uw_update_context' in libgcc's 30768 'unwind-ia64.c'. CONTEXT is an '_Unwind_Context'; FS is an 30769 '_Unwind_FrameState'. Examine 'fs->unwabi' for the abi and context 30770 in the '.unwabi' directive. If the '.unwabi' directive can be 30771 handled, the register save addresses should be updated in FS. 30772 30773 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 30774 A C expression that evaluates to true if the target requires unwind 30775 info to be given comdat linkage. Define it to be '1' if comdat 30776 linkage is necessary. The default is '0'. 30777 30778 30779File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 30780 3078117.9.3 Specifying How Stack Checking is Done 30782-------------------------------------------- 30783 30784GCC will check that stack references are within the boundaries of the 30785stack, if the option '-fstack-check' is specified, in one of three ways: 30786 30787 1. If the value of the 'STACK_CHECK_BUILTIN' macro is nonzero, GCC 30788 will assume that you have arranged for full stack checking to be 30789 done at appropriate places in the configuration files. GCC will 30790 not do other special processing. 30791 30792 2. If 'STACK_CHECK_BUILTIN' is zero and the value of the 30793 'STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume that 30794 you have arranged for static stack checking (checking of the static 30795 stack frame of functions) to be done at appropriate places in the 30796 configuration files. GCC will only emit code to do dynamic stack 30797 checking (checking on dynamic stack allocations) using the third 30798 approach below. 30799 30800 3. If neither of the above are true, GCC will generate code to 30801 periodically "probe" the stack pointer using the values of the 30802 macros defined below. 30803 30804 If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is 30805defined, GCC will change its allocation strategy for large objects if 30806the option '-fstack-check' is specified: they will always be allocated 30807dynamically if their size exceeds 'STACK_CHECK_MAX_VAR_SIZE' bytes. 30808 30809 -- Macro: STACK_CHECK_BUILTIN 30810 A nonzero value if stack checking is done by the configuration 30811 files in a machine-dependent manner. You should define this macro 30812 if stack checking is required by the ABI of your machine or if you 30813 would like to do stack checking in some more efficient way than the 30814 generic approach. The default value of this macro is zero. 30815 30816 -- Macro: STACK_CHECK_STATIC_BUILTIN 30817 A nonzero value if static stack checking is done by the 30818 configuration files in a machine-dependent manner. You should 30819 define this macro if you would like to do static stack checking in 30820 some more efficient way than the generic approach. The default 30821 value of this macro is zero. 30822 30823 -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP 30824 An integer specifying the interval at which GCC must generate stack 30825 probe instructions, defined as 2 raised to this integer. You will 30826 normally define this macro so that the interval be no larger than 30827 the size of the "guard pages" at the end of a stack area. The 30828 default value of 12 (4096-byte interval) is suitable for most 30829 systems. 30830 30831 -- Macro: STACK_CHECK_MOVING_SP 30832 An integer which is nonzero if GCC should move the stack pointer 30833 page by page when doing probes. This can be necessary on systems 30834 where the stack pointer contains the bottom address of the memory 30835 area accessible to the executing thread at any point in time. In 30836 this situation an alternate signal stack is required in order to be 30837 able to recover from a stack overflow. The default value of this 30838 macro is zero. 30839 30840 -- Macro: STACK_CHECK_PROTECT 30841 The number of bytes of stack needed to recover from a stack 30842 overflow, for languages where such a recovery is supported. The 30843 default value of 4KB/8KB with the 'setjmp'/'longjmp'-based 30844 exception handling mechanism and 8KB/12KB with other exception 30845 handling mechanisms should be adequate for most architectures and 30846 operating systems. 30847 30848 The following macros are relevant only if neither STACK_CHECK_BUILTIN 30849nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether 30850in the opposite case. 30851 30852 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 30853 The maximum size of a stack frame, in bytes. GCC will generate 30854 probe instructions in non-leaf functions to ensure at least this 30855 many bytes of stack are available. If a stack frame is larger than 30856 this size, stack checking will not be reliable and GCC will issue a 30857 warning. The default is chosen so that GCC only generates one 30858 instruction on most systems. You should normally not change the 30859 default value of this macro. 30860 30861 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 30862 GCC uses this value to generate the above warning message. It 30863 represents the amount of fixed frame used by a function, not 30864 including space for any callee-saved registers, temporaries and 30865 user variables. You need only specify an upper bound for this 30866 amount and will normally use the default of four words. 30867 30868 -- Macro: STACK_CHECK_MAX_VAR_SIZE 30869 The maximum size, in bytes, of an object that GCC will place in the 30870 fixed area of the stack frame when the user specifies 30871 '-fstack-check'. GCC computed the default from the values of the 30872 above macros and you will normally not need to override that 30873 default. 30874 30875 30876File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 30877 3087817.9.4 Registers That Address the Stack Frame 30879--------------------------------------------- 30880 30881This discusses registers that address the stack frame. 30882 30883 -- Macro: STACK_POINTER_REGNUM 30884 The register number of the stack pointer register, which must also 30885 be a fixed register according to 'FIXED_REGISTERS'. On most 30886 machines, the hardware determines which register this is. 30887 30888 -- Macro: FRAME_POINTER_REGNUM 30889 The register number of the frame pointer register, which is used to 30890 access automatic variables in the stack frame. On some machines, 30891 the hardware determines which register this is. On other machines, 30892 you can choose any register you wish for this purpose. 30893 30894 -- Macro: HARD_FRAME_POINTER_REGNUM 30895 On some machines the offset between the frame pointer and starting 30896 offset of the automatic variables is not known until after register 30897 allocation has been done (for example, because the saved registers 30898 are between these two locations). On those machines, define 30899 'FRAME_POINTER_REGNUM' the number of a special, fixed register to 30900 be used internally until the offset is known, and define 30901 'HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 30902 used for the frame pointer. 30903 30904 You should define this macro only in the very rare circumstances 30905 when it is not possible to calculate the offset between the frame 30906 pointer and the automatic variables until after register allocation 30907 has been completed. When this macro is defined, you must also 30908 indicate in your definition of 'ELIMINABLE_REGS' how to eliminate 30909 'FRAME_POINTER_REGNUM' into either 'HARD_FRAME_POINTER_REGNUM' or 30910 'STACK_POINTER_REGNUM'. 30911 30912 Do not define this macro if it would be the same as 30913 'FRAME_POINTER_REGNUM'. 30914 30915 -- Macro: ARG_POINTER_REGNUM 30916 The register number of the arg pointer register, which is used to 30917 access the function's argument list. On some machines, this is the 30918 same as the frame pointer register. On some machines, the hardware 30919 determines which register this is. On other machines, you can 30920 choose any register you wish for this purpose. If this is not the 30921 same register as the frame pointer register, then you must mark it 30922 as a fixed register according to 'FIXED_REGISTERS', or arrange to 30923 be able to eliminate it (*note Elimination::). 30924 30925 -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER 30926 Define this to a preprocessor constant that is nonzero if 30927 'hard_frame_pointer_rtx' and 'frame_pointer_rtx' should be the 30928 same. The default definition is '(HARD_FRAME_POINTER_REGNUM == 30929 FRAME_POINTER_REGNUM)'; you only need to define this macro if that 30930 definition is not suitable for use in preprocessor conditionals. 30931 30932 -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER 30933 Define this to a preprocessor constant that is nonzero if 30934 'hard_frame_pointer_rtx' and 'arg_pointer_rtx' should be the same. 30935 The default definition is '(HARD_FRAME_POINTER_REGNUM == 30936 ARG_POINTER_REGNUM)'; you only need to define this macro if that 30937 definition is not suitable for use in preprocessor conditionals. 30938 30939 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 30940 The register number of the return address pointer register, which 30941 is used to access the current function's return address from the 30942 stack. On some machines, the return address is not at a fixed 30943 offset from the frame pointer or stack pointer or argument pointer. 30944 This register can be defined to point to the return address on the 30945 stack, and then be converted by 'ELIMINABLE_REGS' into either the 30946 frame pointer or stack pointer. 30947 30948 Do not define this macro unless there is no other way to get the 30949 return address from the stack. 30950 30951 -- Macro: STATIC_CHAIN_REGNUM 30952 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 30953 Register numbers used for passing a function's static chain 30954 pointer. If register windows are used, the register number as seen 30955 by the called function is 'STATIC_CHAIN_INCOMING_REGNUM', while the 30956 register number as seen by the calling function is 30957 'STATIC_CHAIN_REGNUM'. If these registers are the same, 30958 'STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 30959 30960 The static chain register need not be a fixed register. 30961 30962 If the static chain is passed in memory, these macros should not be 30963 defined; instead, the 'TARGET_STATIC_CHAIN' hook should be used. 30964 30965 -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL_OR_TYPE, 30966 bool INCOMING_P) 30967 This hook replaces the use of 'STATIC_CHAIN_REGNUM' et al for 30968 targets that may use different static chain locations for different 30969 nested functions. This may be required if the target has function 30970 attributes that affect the calling conventions of the function and 30971 those calling conventions use different static chain locations. 30972 30973 The default version of this hook uses 'STATIC_CHAIN_REGNUM' et al. 30974 30975 If the static chain is passed in memory, this hook should be used 30976 to provide rtx giving 'mem' expressions that denote where they are 30977 stored. Often the 'mem' expression as seen by the caller will be 30978 at an offset from the stack pointer and the 'mem' expression as 30979 seen by the callee will be at an offset from the frame pointer. 30980 The variables 'stack_pointer_rtx', 'frame_pointer_rtx', and 30981 'arg_pointer_rtx' will have been initialized and should be used to 30982 refer to those items. 30983 30984 -- Macro: DWARF_FRAME_REGISTERS 30985 This macro specifies the maximum number of hard registers that can 30986 be saved in a call frame. This is used to size data structures 30987 used in DWARF2 exception handling. 30988 30989 Prior to GCC 3.0, this macro was needed in order to establish a 30990 stable exception handling ABI in the face of adding new hard 30991 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 30992 insulated from changes in the number of hard registers. 30993 Nevertheless, this macro can still be used to reduce the runtime 30994 memory requirements of the exception handling routines, which can 30995 be substantial if the ISA contains a lot of registers that are not 30996 call-saved. 30997 30998 If this macro is not defined, it defaults to 30999 'FIRST_PSEUDO_REGISTER'. 31000 31001 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 31002 31003 This macro is similar to 'DWARF_FRAME_REGISTERS', but is provided 31004 for backward compatibility in pre GCC 3.0 compiled code. 31005 31006 If this macro is not defined, it defaults to 31007 'DWARF_FRAME_REGISTERS'. 31008 31009 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 31010 31011 Define this macro if the target's representation for dwarf 31012 registers is different than the internal representation for unwind 31013 column. Given a dwarf register, this macro should return the 31014 internal unwind column number to use instead. 31015 31016 See the PowerPC's SPE target for an example. 31017 31018 -- Macro: DWARF_FRAME_REGNUM (REGNO) 31019 31020 Define this macro if the target's representation for dwarf 31021 registers used in .eh_frame or .debug_frame is different from that 31022 used in other debug info sections. Given a GCC hard register 31023 number, this macro should return the .eh_frame register number. 31024 The default is 'DBX_REGISTER_NUMBER (REGNO)'. 31025 31026 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 31027 31028 Define this macro to map register numbers held in the call frame 31029 info that GCC has collected using 'DWARF_FRAME_REGNUM' to those 31030 that should be output in .debug_frame ('FOR_EH' is zero) and 31031 .eh_frame ('FOR_EH' is nonzero). The default is to return 'REGNO'. 31032 31033 -- Macro: REG_VALUE_IN_UNWIND_CONTEXT 31034 31035 Define this macro if the target stores register values as 31036 '_Unwind_Word' type in unwind context. It should be defined if 31037 target register size is larger than the size of 'void *'. The 31038 default is to store register values as 'void *' type. 31039 31040 -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT 31041 31042 Define this macro to be 1 if the target always uses extended unwind 31043 context with version, args_size and by_value fields. If it is 31044 undefined, it will be defined to 1 when 31045 'REG_VALUE_IN_UNWIND_CONTEXT' is defined and 0 otherwise. 31046 31047 31048File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 31049 3105017.9.5 Eliminating Frame Pointer and Arg Pointer 31051------------------------------------------------ 31052 31053This is about eliminating the frame pointer and arg pointer. 31054 31055 -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void) 31056 This target hook should return 'true' if a function must have and 31057 use a frame pointer. This target hook is called in the reload 31058 pass. If its return value is 'true' the function will have a frame 31059 pointer. 31060 31061 This target hook can in principle examine the current function and 31062 decide according to the facts, but on most machines the constant 31063 'false' or the constant 'true' suffices. Use 'false' when the 31064 machine allows code to be generated with no frame pointer, and 31065 doing so saves some time or space. Use 'true' when there is no 31066 possible advantage to avoiding a frame pointer. 31067 31068 In certain cases, the compiler does not know how to produce valid 31069 code without a frame pointer. The compiler recognizes those cases 31070 and automatically gives the function a frame pointer regardless of 31071 what 'TARGET_FRAME_POINTER_REQUIRED' returns. You don't need to 31072 worry about them. 31073 31074 In a function that does not require a frame pointer, the frame 31075 pointer register can be allocated for ordinary usage, unless you 31076 mark it as a fixed register. See 'FIXED_REGISTERS' for more 31077 information. 31078 31079 Default return value is 'false'. 31080 31081 -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR) 31082 A C statement to store in the variable DEPTH-VAR the difference 31083 between the frame pointer and the stack pointer values immediately 31084 after the function prologue. The value would be computed from 31085 information such as the result of 'get_frame_size ()' and the 31086 tables of registers 'regs_ever_live' and 'call_used_regs'. 31087 31088 If 'ELIMINABLE_REGS' is defined, this macro will be not be used and 31089 need not be defined. Otherwise, it must be defined even if 31090 'TARGET_FRAME_POINTER_REQUIRED' always returns true; in that case, 31091 you may set DEPTH-VAR to anything. 31092 31093 -- Macro: ELIMINABLE_REGS 31094 If defined, this macro specifies a table of register pairs used to 31095 eliminate unneeded registers that point into the stack frame. If 31096 it is not defined, the only elimination attempted by the compiler 31097 is to replace references to the frame pointer with references to 31098 the stack pointer. 31099 31100 The definition of this macro is a list of structure 31101 initializations, each of which specifies an original and 31102 replacement register. 31103 31104 On some machines, the position of the argument pointer is not known 31105 until the compilation is completed. In such a case, a separate 31106 hard register must be used for the argument pointer. This register 31107 can be eliminated by replacing it with either the frame pointer or 31108 the argument pointer, depending on whether or not the frame pointer 31109 has been eliminated. 31110 31111 In this case, you might specify: 31112 #define ELIMINABLE_REGS \ 31113 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 31114 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 31115 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 31116 31117 Note that the elimination of the argument pointer with the stack 31118 pointer is specified first since that is the preferred elimination. 31119 31120 -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const 31121 int TO_REG) 31122 This target hook should returns 'true' if the compiler is allowed 31123 to try to replace register number FROM_REG with register number 31124 TO_REG. This target hook need only be defined if 'ELIMINABLE_REGS' 31125 is defined, and will usually be 'true', since most of the cases 31126 preventing register elimination are things that the compiler 31127 already knows about. 31128 31129 Default return value is 'true'. 31130 31131 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 31132 This macro is similar to 'INITIAL_FRAME_POINTER_OFFSET'. It 31133 specifies the initial difference between the specified pair of 31134 registers. This macro must be defined if 'ELIMINABLE_REGS' is 31135 defined. 31136 31137 31138File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 31139 3114017.9.6 Passing Function Arguments on the Stack 31141---------------------------------------------- 31142 31143The macros in this section control how arguments are passed on the 31144stack. See the following section for other macros that control passing 31145certain arguments in registers. 31146 31147 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE) 31148 This target hook returns 'true' if an argument declared in a 31149 prototype as an integral type smaller than 'int' should actually be 31150 passed as an 'int'. In addition to avoiding errors in certain 31151 cases of mismatch, it also makes for better code on certain 31152 machines. The default is to not promote prototypes. 31153 31154 -- Macro: PUSH_ARGS 31155 A C expression. If nonzero, push insns will be used to pass 31156 outgoing arguments. If the target machine does not have a push 31157 instruction, set it to zero. That directs GCC to use an alternate 31158 strategy: to allocate the entire argument block and then store the 31159 arguments into it. When 'PUSH_ARGS' is nonzero, 'PUSH_ROUNDING' 31160 must be defined too. 31161 31162 -- Macro: PUSH_ARGS_REVERSED 31163 A C expression. If nonzero, function arguments will be evaluated 31164 from last to first, rather than from first to last. If this macro 31165 is not defined, it defaults to 'PUSH_ARGS' on targets where the 31166 stack and args grow in opposite directions, and 0 otherwise. 31167 31168 -- Macro: PUSH_ROUNDING (NPUSHED) 31169 A C expression that is the number of bytes actually pushed onto the 31170 stack when an instruction attempts to push NPUSHED bytes. 31171 31172 On some machines, the definition 31173 31174 #define PUSH_ROUNDING(BYTES) (BYTES) 31175 31176 will suffice. But on other machines, instructions that appear to 31177 push one byte actually push two bytes in an attempt to maintain 31178 alignment. Then the definition should be 31179 31180 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 31181 31182 If the value of this macro has a type, it should be an unsigned 31183 type. 31184 31185 -- Macro: ACCUMULATE_OUTGOING_ARGS 31186 A C expression. If nonzero, the maximum amount of space required 31187 for outgoing arguments will be computed and placed into 31188 'crtl->outgoing_args_size'. No space will be pushed onto the stack 31189 for each call; instead, the function prologue should increase the 31190 stack frame size by this amount. 31191 31192 Setting both 'PUSH_ARGS' and 'ACCUMULATE_OUTGOING_ARGS' is not 31193 proper. 31194 31195 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 31196 Define this macro if functions should assume that stack space has 31197 been allocated for arguments even when their values are passed in 31198 registers. 31199 31200 The value of this macro is the size, in bytes, of the area reserved 31201 for arguments passed in registers for the function represented by 31202 FNDECL, which can be zero if GCC is calling a library function. 31203 The argument FNDECL can be the FUNCTION_DECL, or the type itself of 31204 the function. 31205 31206 This space can be allocated by the caller, or be a part of the 31207 machine-dependent stack frame: 'OUTGOING_REG_PARM_STACK_SPACE' says 31208 which. 31209 31210 -- Macro: INCOMING_REG_PARM_STACK_SPACE (FNDECL) 31211 Like 'REG_PARM_STACK_SPACE', but for incoming register arguments. 31212 Define this macro if space guaranteed when compiling a function 31213 body is different to space required when making a call, a situation 31214 that can arise with K&R style function definitions. 31215 31216 -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE) 31217 Define this to a nonzero value if it is the responsibility of the 31218 caller to allocate the area reserved for arguments passed in 31219 registers when calling a function of FNTYPE. FNTYPE may be NULL if 31220 the function called is a library function. 31221 31222 If 'ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 31223 whether the space for these arguments counts in the value of 31224 'crtl->outgoing_args_size'. 31225 31226 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 31227 Define this macro if 'REG_PARM_STACK_SPACE' is defined, but the 31228 stack parameters don't skip the area specified by it. 31229 31230 Normally, when a parameter is not passed in registers, it is placed 31231 on the stack beyond the 'REG_PARM_STACK_SPACE' area. Defining this 31232 macro suppresses this behavior and causes the parameter to be 31233 passed on the stack in its natural location. 31234 31235 -- Target Hook: int TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree 31236 FUNTYPE, int SIZE) 31237 This target hook returns the number of bytes of its own arguments 31238 that a function pops on returning, or 0 if the function pops no 31239 arguments and the caller must therefore pop them all after the 31240 function returns. 31241 31242 FUNDECL is a C variable whose value is a tree node that describes 31243 the function in question. Normally it is a node of type 31244 'FUNCTION_DECL' that describes the declaration of the function. 31245 From this you can obtain the 'DECL_ATTRIBUTES' of the function. 31246 31247 FUNTYPE is a C variable whose value is a tree node that describes 31248 the function in question. Normally it is a node of type 31249 'FUNCTION_TYPE' that describes the data type of the function. From 31250 this it is possible to obtain the data types of the value and 31251 arguments (if known). 31252 31253 When a call to a library function is being considered, FUNDECL will 31254 contain an identifier node for the library function. Thus, if you 31255 need to distinguish among various library functions, you can do so 31256 by their names. Note that "library function" in this context means 31257 a function used to perform arithmetic, whose name is known 31258 specially in the compiler and was not mentioned in the C code being 31259 compiled. 31260 31261 SIZE is the number of bytes of arguments passed on the stack. If a 31262 variable number of bytes is passed, it is zero, and argument 31263 popping will always be the responsibility of the calling function. 31264 31265 On the VAX, all functions always pop their arguments, so the 31266 definition of this macro is SIZE. On the 68000, using the standard 31267 calling convention, no functions pop their arguments, so the value 31268 of the macro is always 0 in this case. But an alternative calling 31269 convention is available in which functions that take a fixed number 31270 of arguments pop them but other functions (such as 'printf') pop 31271 nothing (the caller pops all). When this convention is in use, 31272 FUNTYPE is examined to determine whether a function takes a fixed 31273 number of arguments. 31274 31275 -- Macro: CALL_POPS_ARGS (CUM) 31276 A C expression that should indicate the number of bytes a call 31277 sequence pops off the stack. It is added to the value of 31278 'RETURN_POPS_ARGS' when compiling a function call. 31279 31280 CUM is the variable in which all arguments to the called function 31281 have been accumulated. 31282 31283 On certain architectures, such as the SH5, a call trampoline is 31284 used that pops certain registers off the stack, depending on the 31285 arguments that have been passed to the function. Since this is a 31286 property of the call site, not of the called function, 31287 'RETURN_POPS_ARGS' is not appropriate. 31288 31289 31290File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 31291 3129217.9.7 Passing Arguments in Registers 31293------------------------------------- 31294 31295This section describes the macros which let you control how various 31296types of arguments are passed in registers or how they are arranged in 31297the stack. 31298 31299 -- Target Hook: rtx TARGET_FUNCTION_ARG (cumulative_args_t CA, 31300 machine_mode MODE, const_tree TYPE, bool NAMED) 31301 Return an RTX indicating whether a function argument is passed in a 31302 register and if so, which register. 31303 31304 The arguments are CA, which summarizes all the previous arguments; 31305 MODE, the machine mode of the argument; TYPE, the data type of the 31306 argument as a tree node or 0 if that is not known (which happens 31307 for C support library functions); and NAMED, which is 'true' for an 31308 ordinary argument and 'false' for nameless arguments that 31309 correspond to '...' in the called function's prototype. TYPE can 31310 be an incomplete type if a syntax error has previously occurred. 31311 31312 The return value is usually either a 'reg' RTX for the hard 31313 register in which to pass the argument, or zero to pass the 31314 argument on the stack. 31315 31316 The return value can be a 'const_int' which means argument is 31317 passed in a target specific slot with specified number. Target 31318 hooks should be used to store or load argument in such case. See 31319 'TARGET_STORE_BOUNDS_FOR_ARG' and 'TARGET_LOAD_BOUNDS_FOR_ARG' for 31320 more information. 31321 31322 The value of the expression can also be a 'parallel' RTX. This is 31323 used when an argument is passed in multiple locations. The mode of 31324 the 'parallel' should be the mode of the entire argument. The 31325 'parallel' holds any number of 'expr_list' pairs; each one 31326 describes where part of the argument is passed. In each 31327 'expr_list' the first operand must be a 'reg' RTX for the hard 31328 register in which to pass this part of the argument, and the mode 31329 of the register RTX indicates how large this part of the argument 31330 is. The second operand of the 'expr_list' is a 'const_int' which 31331 gives the offset in bytes into the entire argument of where this 31332 part starts. As a special exception the first 'expr_list' in the 31333 'parallel' RTX may have a first operand of zero. This indicates 31334 that the entire argument is also stored on the stack. 31335 31336 The last time this hook is called, it is called with 'MODE == 31337 VOIDmode', and its result is passed to the 'call' or 'call_value' 31338 pattern as operands 2 and 3 respectively. 31339 31340 The usual way to make the ISO library 'stdarg.h' work on a machine 31341 where some arguments are usually passed in registers, is to cause 31342 nameless arguments to be passed on the stack instead. This is done 31343 by making 'TARGET_FUNCTION_ARG' return 0 whenever NAMED is 'false'. 31344 31345 You may use the hook 'targetm.calls.must_pass_in_stack' in the 31346 definition of this macro to determine if this argument is of a type 31347 that must be passed in the stack. If 'REG_PARM_STACK_SPACE' is not 31348 defined and 'TARGET_FUNCTION_ARG' returns nonzero for such an 31349 argument, the compiler will abort. If 'REG_PARM_STACK_SPACE' is 31350 defined, the argument will be computed in the stack and then loaded 31351 into a register. 31352 31353 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (machine_mode MODE, 31354 const_tree TYPE) 31355 This target hook should return 'true' if we should not pass TYPE 31356 solely in registers. The file 'expr.h' defines a definition that 31357 is usually appropriate, refer to 'expr.h' for additional 31358 documentation. 31359 31360 -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t CA, 31361 machine_mode MODE, const_tree TYPE, bool NAMED) 31362 Define this hook if the target machine has "register windows", so 31363 that the register in which a function sees an arguments is not 31364 necessarily the same as the one in which the caller passed the 31365 argument. 31366 31367 For such machines, 'TARGET_FUNCTION_ARG' computes the register in 31368 which the caller passes the value, and 31369 'TARGET_FUNCTION_INCOMING_ARG' should be defined in a similar 31370 fashion to tell the function being called where the arguments will 31371 arrive. 31372 31373 If 'TARGET_FUNCTION_INCOMING_ARG' is not defined, 31374 'TARGET_FUNCTION_ARG' serves both purposes. 31375 31376 -- Target Hook: bool TARGET_USE_PSEUDO_PIC_REG (void) 31377 This hook should return 1 in case pseudo register should be created 31378 for pic_offset_table_rtx during function expand. 31379 31380 -- Target Hook: void TARGET_INIT_PIC_REG (void) 31381 Perform a target dependent initialization of pic_offset_table_rtx. 31382 This hook is called at the start of register allocation. 31383 31384 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (cumulative_args_t CUM, 31385 machine_mode MODE, tree TYPE, bool NAMED) 31386 This target hook returns the number of bytes at the beginning of an 31387 argument that must be put in registers. The value must be zero for 31388 arguments that are passed entirely in registers or that are 31389 entirely pushed on the stack. 31390 31391 On some machines, certain arguments must be passed partially in 31392 registers and partially in memory. On these machines, typically 31393 the first few words of arguments are passed in registers, and the 31394 rest on the stack. If a multi-word argument (a 'double' or a 31395 structure) crosses that boundary, its first few words must be 31396 passed in registers and the rest must be pushed. This macro tells 31397 the compiler when this occurs, and how many bytes should go in 31398 registers. 31399 31400 'TARGET_FUNCTION_ARG' for these arguments should return the first 31401 register to be used by the caller for this argument; likewise 31402 'TARGET_FUNCTION_INCOMING_ARG', for the called function. 31403 31404 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM, 31405 machine_mode MODE, const_tree TYPE, bool NAMED) 31406 This target hook should return 'true' if an argument at the 31407 position indicated by CUM should be passed by reference. This 31408 predicate is queried after target independent reasons for being 31409 passed by reference, such as 'TREE_ADDRESSABLE (type)'. 31410 31411 If the hook returns true, a copy of that argument is made in memory 31412 and a pointer to the argument is passed instead of the argument 31413 itself. The pointer is passed in whatever way is appropriate for 31414 passing a pointer to that type. 31415 31416 -- Target Hook: bool TARGET_CALLEE_COPIES (cumulative_args_t CUM, 31417 machine_mode MODE, const_tree TYPE, bool NAMED) 31418 The function argument described by the parameters to this hook is 31419 known to be passed by reference. The hook should return true if 31420 the function argument should be copied by the callee instead of 31421 copied by the caller. 31422 31423 For any argument for which the hook returns true, if it can be 31424 determined that the argument is not modified, then a copy need not 31425 be generated. 31426 31427 The default version of this hook always returns false. 31428 31429 -- Macro: CUMULATIVE_ARGS 31430 A C type for declaring a variable that is used as the first 31431 argument of 'TARGET_FUNCTION_ARG' and other related values. For 31432 some target machines, the type 'int' suffices and can hold the 31433 number of bytes of argument so far. 31434 31435 There is no need to record in 'CUMULATIVE_ARGS' anything about the 31436 arguments that have been passed on the stack. The compiler has 31437 other variables to keep track of that. For target machines on 31438 which all arguments are passed on the stack, there is no need to 31439 store anything in 'CUMULATIVE_ARGS'; however, the data structure 31440 must exist and should not be empty, so use 'int'. 31441 31442 -- Macro: OVERRIDE_ABI_FORMAT (FNDECL) 31443 If defined, this macro is called before generating any code for a 31444 function, but after the CFUN descriptor for the function has been 31445 created. The back end may use this macro to update CFUN to reflect 31446 an ABI other than that which would normally be used by default. If 31447 the compiler is generating code for a compiler-generated function, 31448 FNDECL may be 'NULL'. 31449 31450 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 31451 N_NAMED_ARGS) 31452 A C statement (sans semicolon) for initializing the variable CUM 31453 for the state at the beginning of the argument list. The variable 31454 has type 'CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 31455 for the data type of the function which will receive the args, or 0 31456 if the args are to a compiler support library function. For direct 31457 calls that are not libcalls, FNDECL contain the declaration node of 31458 the function. FNDECL is also set when 'INIT_CUMULATIVE_ARGS' is 31459 used to find arguments for the function being compiled. 31460 N_NAMED_ARGS is set to the number of named arguments, including a 31461 structure return address if it is passed as a parameter, when 31462 making a call. When processing incoming arguments, N_NAMED_ARGS is 31463 set to -1. 31464 31465 When processing a call to a compiler support library function, 31466 LIBNAME identifies which one. It is a 'symbol_ref' rtx which 31467 contains the name of the function, as a string. LIBNAME is 0 when 31468 an ordinary C function call is being processed. Thus, each time 31469 this macro is called, either LIBNAME or FNTYPE is nonzero, but 31470 never both of them at once. 31471 31472 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 31473 Like 'INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, it 31474 gets a 'MODE' argument instead of FNTYPE, that would be 'NULL'. 31475 INDIRECT would always be zero, too. If this macro is not defined, 31476 'INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead. 31477 31478 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 31479 Like 'INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 31480 finding the arguments for the function being compiled. If this 31481 macro is undefined, 'INIT_CUMULATIVE_ARGS' is used instead. 31482 31483 The value passed for LIBNAME is always 0, since library routines 31484 with special calling conventions are never compiled with GCC. The 31485 argument LIBNAME exists for symmetry with 'INIT_CUMULATIVE_ARGS'. 31486 31487 -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t CA, 31488 machine_mode MODE, const_tree TYPE, bool NAMED) 31489 This hook updates the summarizer variable pointed to by CA to 31490 advance past an argument in the argument list. The values MODE, 31491 TYPE and NAMED describe that argument. Once this is done, the 31492 variable CUM is suitable for analyzing the _following_ argument 31493 with 'TARGET_FUNCTION_ARG', etc. 31494 31495 This hook need not do anything if the argument in question was 31496 passed on the stack. The compiler knows how to track the amount of 31497 stack space used for arguments without any special help. 31498 31499 -- Macro: FUNCTION_ARG_OFFSET (MODE, TYPE) 31500 If defined, a C expression that is the number of bytes to add to 31501 the offset of the argument passed in memory. This is needed for 31502 the SPU, which passes 'char' and 'short' arguments in the preferred 31503 slot that is in the middle of the quad word instead of starting at 31504 the top. 31505 31506 -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE) 31507 If defined, a C expression which determines whether, and in which 31508 direction, to pad out an argument with extra space. The value 31509 should be of type 'enum direction': either 'upward' to pad above 31510 the argument, 'downward' to pad below, or 'none' to inhibit 31511 padding. 31512 31513 The _amount_ of padding is not controlled by this macro, but by the 31514 target hook 'TARGET_FUNCTION_ARG_ROUND_BOUNDARY'. It is always 31515 just enough to reach the next multiple of that boundary. 31516 31517 This macro has a default definition which is right for most 31518 systems. For little-endian machines, the default is to pad upward. 31519 For big-endian machines, the default is to pad downward for an 31520 argument of constant size shorter than an 'int', and upward 31521 otherwise. 31522 31523 -- Macro: PAD_VARARGS_DOWN 31524 If defined, a C expression which determines whether the default 31525 implementation of va_arg will attempt to pad down before reading 31526 the next argument, if that argument is smaller than its aligned 31527 space as controlled by 'PARM_BOUNDARY'. If this macro is not 31528 defined, all such arguments are padded down if 'BYTES_BIG_ENDIAN' 31529 is true. 31530 31531 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 31532 Specify padding for the last element of a block move between 31533 registers and memory. FIRST is nonzero if this is the only 31534 element. Defining this macro allows better control of register 31535 function parameters on big-endian machines, without using 31536 'PARALLEL' rtl. In particular, 'MUST_PASS_IN_STACK' need not test 31537 padding and mode of types in registers, as there is no longer a 31538 "wrong" part of a register; For example, a three byte aggregate may 31539 be passed in the high part of a register if so required. 31540 31541 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY (machine_mode 31542 MODE, const_tree TYPE) 31543 This hook returns the alignment boundary, in bits, of an argument 31544 with the specified mode and type. The default hook returns 31545 'PARM_BOUNDARY' for all arguments. 31546 31547 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY 31548 (machine_mode MODE, const_tree TYPE) 31549 Normally, the size of an argument is rounded up to 'PARM_BOUNDARY', 31550 which is the default value for this hook. You can define this hook 31551 to return a different value if an argument size must be rounded to 31552 a larger value. 31553 31554 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 31555 A C expression that is nonzero if REGNO is the number of a hard 31556 register in which function arguments are sometimes passed. This 31557 does _not_ include implicit arguments such as the static chain and 31558 the structure-value address. On many machines, no registers can be 31559 used for this purpose since all function arguments are pushed on 31560 the stack. 31561 31562 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE) 31563 This hook should return true if parameter of type TYPE are passed 31564 as two scalar parameters. By default, GCC will attempt to pack 31565 complex arguments into the target's word size. Some ABIs require 31566 complex arguments to be split and treated as their individual 31567 components. For example, on AIX64, complex floats should be passed 31568 in a pair of floating point registers, even though a complex float 31569 would fit in one 64-bit floating point register. 31570 31571 The default value of this hook is 'NULL', which is treated as 31572 always false. 31573 31574 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 31575 This hook returns a type node for 'va_list' for the target. The 31576 default version of the hook returns 'void*'. 31577 31578 -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char **PNAME, 31579 tree *PTREE) 31580 This target hook is used in function 'c_common_nodes_and_builtins' 31581 to iterate through the target specific builtin types for va_list. 31582 The variable IDX is used as iterator. PNAME has to be a pointer to 31583 a 'const char *' and PTREE a pointer to a 'tree' typed variable. 31584 The arguments PNAME and PTREE are used to store the result of this 31585 macro and are set to the name of the va_list builtin type and its 31586 internal type. If the return value of this macro is zero, then 31587 there is no more element. Otherwise the IDX should be increased 31588 for the next call of this macro to iterate through all types. 31589 31590 -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL) 31591 This hook returns the va_list type of the calling convention 31592 specified by FNDECL. The default version of this hook returns 31593 'va_list_type_node'. 31594 31595 -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE) 31596 This hook returns the va_list type of the calling convention 31597 specified by the type of TYPE. If TYPE is not a valid va_list 31598 type, it returns 'NULL_TREE'. 31599 31600 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 31601 TYPE, gimple_seq *PRE_P, gimple_seq *POST_P) 31602 This hook performs target-specific gimplification of 'VA_ARG_EXPR'. 31603 The first two parameters correspond to the arguments to 'va_arg'; 31604 the latter two are as in 'gimplify.c:gimplify_expr'. 31605 31606 -- Target Hook: bool TARGET_VALID_POINTER_MODE (machine_mode MODE) 31607 Define this to return nonzero if the port can handle pointers with 31608 machine mode MODE. The default version of this hook returns true 31609 for both 'ptr_mode' and 'Pmode'. 31610 31611 -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (struct ao_ref *REF) 31612 Define this to return nonzero if the memory reference REF may alias 31613 with the system C library errno location. The default version of 31614 this hook assumes the system C library errno location is either a 31615 declaration of type int or accessed by dereferencing a pointer to 31616 int. 31617 31618 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (machine_mode MODE) 31619 Define this to return nonzero if the port is prepared to handle 31620 insns involving scalar mode MODE. For a scalar mode to be 31621 considered supported, all the basic arithmetic and comparisons must 31622 work. 31623 31624 The default version of this hook returns true for any mode required 31625 to handle the basic C types (as defined by the port). Included 31626 here are the double-word arithmetic supported by the code in 31627 'optabs.c'. 31628 31629 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE) 31630 Define this to return nonzero if the port is prepared to handle 31631 insns involving vector mode MODE. At the very least, it must have 31632 move patterns for this mode. 31633 31634 -- Target Hook: bool TARGET_ARRAY_MODE_SUPPORTED_P (machine_mode MODE, 31635 unsigned HOST_WIDE_INT NELEMS) 31636 Return true if GCC should try to use a scalar mode to store an 31637 array of NELEMS elements, given that each element has mode MODE. 31638 Returning true here overrides the usual 'MAX_FIXED_MODE' limit and 31639 allows GCC to use any defined integer mode. 31640 31641 One use of this hook is to support vector load and store operations 31642 that operate on several homogeneous vectors. For example, ARM NEON 31643 has operations like: 31644 31645 int8x8x3_t vld3_s8 (const int8_t *) 31646 31647 where the return type is defined as: 31648 31649 typedef struct int8x8x3_t 31650 { 31651 int8x8_t val[3]; 31652 } int8x8x3_t; 31653 31654 If this hook allows 'val' to have a scalar mode, then 'int8x8x3_t' 31655 can have the same mode. GCC can then store 'int8x8x3_t's in 31656 registers rather than forcing them onto the stack. 31657 31658 -- Target Hook: bool TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 31659 (machine_mode MODE) 31660 Define this to return nonzero if libgcc provides support for the 31661 floating-point mode MODE, which is known to pass 31662 'TARGET_SCALAR_MODE_SUPPORTED_P'. The default version of this hook 31663 returns true for all of 'SFmode', 'DFmode', 'XFmode' and 'TFmode', 31664 if such modes exist. 31665 31666 -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P 31667 (machine_mode MODE) 31668 Define this to return nonzero for machine modes for which the port 31669 has small register classes. If this target hook returns nonzero 31670 for a given MODE, the compiler will try to minimize the lifetime of 31671 registers in MODE. The hook may be called with 'VOIDmode' as 31672 argument. In this case, the hook is expected to return nonzero if 31673 it returns nonzero for any mode. 31674 31675 On some machines, it is risky to let hard registers live across 31676 arbitrary insns. Typically, these machines have instructions that 31677 require values to be in specific registers (like an accumulator), 31678 and reload will fail if the required hard register is used for 31679 another purpose across such an insn. 31680 31681 Passes before reload do not know which hard registers will be used 31682 in an instruction, but the machine modes of the registers set or 31683 used in the instruction are already known. And for some machines, 31684 register classes are small for, say, integer registers but not for 31685 floating point registers. For example, the AMD x86-64 architecture 31686 requires specific registers for the legacy x86 integer 31687 instructions, but there are many SSE registers for floating point 31688 operations. On such targets, a good strategy may be to return 31689 nonzero from this hook for 'INTEGRAL_MODE_P' machine modes but zero 31690 for the SSE register classes. 31691 31692 The default version of this hook returns false for any mode. It is 31693 always safe to redefine this hook to return with a nonzero value. 31694 But if you unnecessarily define it, you will reduce the amount of 31695 optimizations that can be performed in some cases. If you do not 31696 define this hook to return a nonzero value when it is required, the 31697 compiler will run out of spill registers and print a fatal error 31698 message. 31699 31700 31701File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 31702 3170317.9.8 How Scalar Function Values Are Returned 31704---------------------------------------------- 31705 31706This section discusses the macros that control returning scalars as 31707values--values that can fit in registers. 31708 31709 -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE, 31710 const_tree FN_DECL_OR_TYPE, bool OUTGOING) 31711 31712 Define this to return an RTX representing the place where a 31713 function returns or receives a value of data type RET_TYPE, a tree 31714 node representing a data type. FN_DECL_OR_TYPE is a tree node 31715 representing 'FUNCTION_DECL' or 'FUNCTION_TYPE' of a function being 31716 called. If OUTGOING is false, the hook should compute the register 31717 in which the caller will see the return value. Otherwise, the hook 31718 should return an RTX representing the place where a function 31719 returns a value. 31720 31721 On many machines, only 'TYPE_MODE (RET_TYPE)' is relevant. 31722 (Actually, on most machines, scalar values are returned in the same 31723 place regardless of mode.) The value of the expression is usually 31724 a 'reg' RTX for the hard register where the return value is stored. 31725 The value can also be a 'parallel' RTX, if the return value is in 31726 multiple places. See 'TARGET_FUNCTION_ARG' for an explanation of 31727 the 'parallel' form. Note that the callee will populate every 31728 location specified in the 'parallel', but if the first element of 31729 the 'parallel' contains the whole return value, callers will use 31730 that element as the canonical location and ignore the others. The 31731 m68k port uses this type of 'parallel' to return pointers in both 31732 '%a0' (the canonical location) and '%d0'. 31733 31734 If 'TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 31735 the same promotion rules specified in 'PROMOTE_MODE' if VALTYPE is 31736 a scalar type. 31737 31738 If the precise function being called is known, FUNC is a tree node 31739 ('FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 31740 makes it possible to use a different value-returning convention for 31741 specific functions when all their calls are known. 31742 31743 Some target machines have "register windows" so that the register 31744 in which a function returns its value is not the same as the one in 31745 which the caller sees the value. For such machines, you should 31746 return different RTX depending on OUTGOING. 31747 31748 'TARGET_FUNCTION_VALUE' is not used for return values with 31749 aggregate data types, because these are returned in another way. 31750 See 'TARGET_STRUCT_VALUE_RTX' and related macros, below. 31751 31752 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 31753 This macro has been deprecated. Use 'TARGET_FUNCTION_VALUE' for a 31754 new target instead. 31755 31756 -- Macro: LIBCALL_VALUE (MODE) 31757 A C expression to create an RTX representing the place where a 31758 library function returns a value of mode MODE. 31759 31760 Note that "library function" in this context means a compiler 31761 support routine, used to perform arithmetic, whose name is known 31762 specially by the compiler and was not mentioned in the C code being 31763 compiled. 31764 31765 -- Target Hook: rtx TARGET_LIBCALL_VALUE (machine_mode MODE, const_rtx 31766 FUN) 31767 Define this hook if the back-end needs to know the name of the 31768 libcall function in order to determine where the result should be 31769 returned. 31770 31771 The mode of the result is given by MODE and the name of the called 31772 library function is given by FUN. The hook should return an RTX 31773 representing the place where the library function result will be 31774 returned. 31775 31776 If this hook is not defined, then LIBCALL_VALUE will be used. 31777 31778 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 31779 A C expression that is nonzero if REGNO is the number of a hard 31780 register in which the values of called function may come back. 31781 31782 A register whose use for returning values is limited to serving as 31783 the second of a pair (for a value of type 'double', say) need not 31784 be recognized by this macro. So for most machines, this definition 31785 suffices: 31786 31787 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 31788 31789 If the machine has register windows, so that the caller and the 31790 called function use different registers for the return value, this 31791 macro should recognize only the caller's register numbers. 31792 31793 This macro has been deprecated. Use 31794 'TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead. 31795 31796 -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int 31797 REGNO) 31798 A target hook that return 'true' if REGNO is the number of a hard 31799 register in which the values of called function may come back. 31800 31801 A register whose use for returning values is limited to serving as 31802 the second of a pair (for a value of type 'double', say) need not 31803 be recognized by this target hook. 31804 31805 If the machine has register windows, so that the caller and the 31806 called function use different registers for the return value, this 31807 target hook should recognize only the caller's register numbers. 31808 31809 If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be 31810 used. 31811 31812 -- Macro: APPLY_RESULT_SIZE 31813 Define this macro if 'untyped_call' and 'untyped_return' need more 31814 space than is implied by 'FUNCTION_VALUE_REGNO_P' for saving and 31815 restoring an arbitrary return value. 31816 31817 -- Target Hook: bool TARGET_OMIT_STRUCT_RETURN_REG 31818 Normally, when a function returns a structure by memory, the 31819 address is passed as an invisible pointer argument, but the 31820 compiler also arranges to return the address from the function like 31821 it would a normal pointer return value. Define this to true if 31822 that behavior is undesirable on your target. 31823 31824 -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE) 31825 This hook should return true if values of type TYPE are returned at 31826 the most significant end of a register (in other words, if they are 31827 padded at the least significant end). You can assume that TYPE is 31828 returned in a register; the caller is required to check this. 31829 31830 Note that the register provided by 'TARGET_FUNCTION_VALUE' must be 31831 able to hold the complete return value. For example, if a 1-, 2- 31832 or 3-byte structure is returned at the most significant end of a 31833 4-byte register, 'TARGET_FUNCTION_VALUE' should provide an 'SImode' 31834 rtx. 31835 31836 31837File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 31838 3183917.9.9 How Large Values Are Returned 31840------------------------------------ 31841 31842When a function value's mode is 'BLKmode' (and in some other cases), the 31843value is not returned according to 'TARGET_FUNCTION_VALUE' (*note Scalar 31844Return::). Instead, the caller passes the address of a block of memory 31845in which the value should be stored. This address is called the 31846"structure value address". 31847 31848 This section describes how to control returning structure values in 31849memory. 31850 31851 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE, 31852 const_tree FNTYPE) 31853 This target hook should return a nonzero value to say to return the 31854 function value in memory, just as large structures are always 31855 returned. Here TYPE will be the data type of the value, and FNTYPE 31856 will be the type of the function doing the returning, or 'NULL' for 31857 libcalls. 31858 31859 Note that values of mode 'BLKmode' must be explicitly handled by 31860 this function. Also, the option '-fpcc-struct-return' takes effect 31861 regardless of this macro. On most systems, it is possible to leave 31862 the hook undefined; this causes a default definition to be used, 31863 whose value is the constant 1 for 'BLKmode' values, and 0 31864 otherwise. 31865 31866 Do not use this hook to indicate that structures and unions should 31867 always be returned in memory. You should instead use 31868 'DEFAULT_PCC_STRUCT_RETURN' to indicate this. 31869 31870 -- Macro: DEFAULT_PCC_STRUCT_RETURN 31871 Define this macro to be 1 if all structure and union return values 31872 must be in memory. Since this results in slower code, this should 31873 be defined only if needed for compatibility with other compilers or 31874 with an ABI. If you define this macro to be 0, then the 31875 conventions used for structure and union return values are decided 31876 by the 'TARGET_RETURN_IN_MEMORY' target hook. 31877 31878 If not defined, this defaults to the value 1. 31879 31880 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 31881 This target hook should return the location of the structure value 31882 address (normally a 'mem' or 'reg'), or 0 if the address is passed 31883 as an "invisible" first argument. Note that FNDECL may be 'NULL', 31884 for libcalls. You do not need to define this target hook if the 31885 address is always passed as an "invisible" first argument. 31886 31887 On some architectures the place where the structure value address 31888 is found by the called function is not the same place that the 31889 caller put it. This can be due to register windows, or it could be 31890 because the function prologue moves it to a different place. 31891 INCOMING is '1' or '2' when the location is needed in the context 31892 of the called function, and '0' in the context of the caller. 31893 31894 If INCOMING is nonzero and the address is to be found on the stack, 31895 return a 'mem' which refers to the frame pointer. If INCOMING is 31896 '2', the result is being used to fetch the structure value address 31897 at the beginning of a function. If you need to emit adjusting 31898 code, you should do it at this point. 31899 31900 -- Macro: PCC_STATIC_STRUCT_RETURN 31901 Define this macro if the usual system convention on the target 31902 machine for returning structures and unions is for the called 31903 function to return the address of a static variable containing the 31904 value. 31905 31906 Do not define this if the usual system convention is for the caller 31907 to pass an address to the subroutine. 31908 31909 This macro has effect in '-fpcc-struct-return' mode, but it does 31910 nothing when you use '-freg-struct-return' mode. 31911 31912 -- Target Hook: machine_mode TARGET_GET_RAW_RESULT_MODE (int REGNO) 31913 This target hook returns the mode to be used when accessing raw 31914 return registers in '__builtin_return'. Define this macro if the 31915 value in REG_RAW_MODE is not correct. 31916 31917 -- Target Hook: machine_mode TARGET_GET_RAW_ARG_MODE (int REGNO) 31918 This target hook returns the mode to be used when accessing raw 31919 argument registers in '__builtin_apply_args'. Define this macro if 31920 the value in REG_RAW_MODE is not correct. 31921 31922 31923File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 31924 3192517.9.10 Caller-Saves Register Allocation 31926---------------------------------------- 31927 31928If you enable it, GCC can save registers around function calls. This 31929makes it possible to use call-clobbered registers to hold variables that 31930must live across calls. 31931 31932 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 31933 A C expression specifying which mode is required for saving NREGS 31934 of a pseudo-register in call-clobbered hard register REGNO. If 31935 REGNO is unsuitable for caller save, 'VOIDmode' should be returned. 31936 For most machines this macro need not be defined since GCC will 31937 select the smallest suitable mode. 31938 31939 31940File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 31941 3194217.9.11 Function Entry and Exit 31943------------------------------- 31944 31945This section describes the macros that output function entry 31946("prologue") and exit ("epilogue") code. 31947 31948 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE, 31949 HOST_WIDE_INT SIZE) 31950 If defined, a function that outputs the assembler code for entry to 31951 a function. The prologue is responsible for setting up the stack 31952 frame, initializing the frame pointer register, saving registers 31953 that must be saved, and allocating SIZE additional bytes of storage 31954 for the local variables. SIZE is an integer. FILE is a stdio 31955 stream to which the assembler code should be output. 31956 31957 The label for the beginning of the function need not be output by 31958 this macro. That has already been done when the macro is run. 31959 31960 To determine which registers to save, the macro can refer to the 31961 array 'regs_ever_live': element R is nonzero if hard register R is 31962 used anywhere within the function. This implies the function 31963 prologue should save register R, provided it is not one of the 31964 call-used registers. ('TARGET_ASM_FUNCTION_EPILOGUE' must likewise 31965 use 'regs_ever_live'.) 31966 31967 On machines that have "register windows", the function entry code 31968 does not save on the stack the registers that are in the windows, 31969 even if they are supposed to be preserved by function calls; 31970 instead it takes appropriate steps to "push" the register stack, if 31971 any non-call-used registers are used in the function. 31972 31973 On machines where functions may or may not have frame-pointers, the 31974 function entry code must vary accordingly; it must set up the frame 31975 pointer if one is wanted, and not otherwise. To determine whether 31976 a frame pointer is in wanted, the macro can refer to the variable 31977 'frame_pointer_needed'. The variable's value will be 1 at run time 31978 in a function that needs a frame pointer. *Note Elimination::. 31979 31980 The function entry code is responsible for allocating any stack 31981 space required for the function. This stack space consists of the 31982 regions listed below. In most cases, these regions are allocated 31983 in the order listed, with the last listed region closest to the top 31984 of the stack (the lowest address if 'STACK_GROWS_DOWNWARD' is 31985 defined, and the highest address if it is not defined). You can 31986 use a different order for a machine if doing so is more convenient 31987 or required for compatibility reasons. Except in cases where 31988 required by standard or by a debugger, there is no reason why the 31989 stack layout used by GCC need agree with that used by other 31990 compilers for a machine. 31991 31992 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 31993 If defined, a function that outputs assembler code at the end of a 31994 prologue. This should be used when the function prologue is being 31995 emitted as RTL, and you have some extra assembler that needs to be 31996 emitted. *Note prologue instruction pattern::. 31997 31998 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 31999 If defined, a function that outputs assembler code at the start of 32000 an epilogue. This should be used when the function epilogue is 32001 being emitted as RTL, and you have some extra assembler that needs 32002 to be emitted. *Note epilogue instruction pattern::. 32003 32004 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE, 32005 HOST_WIDE_INT SIZE) 32006 If defined, a function that outputs the assembler code for exit 32007 from a function. The epilogue is responsible for restoring the 32008 saved registers and stack pointer to their values when the function 32009 was called, and returning control to the caller. This macro takes 32010 the same arguments as the macro 'TARGET_ASM_FUNCTION_PROLOGUE', and 32011 the registers to restore are determined from 'regs_ever_live' and 32012 'CALL_USED_REGISTERS' in the same way. 32013 32014 On some machines, there is a single instruction that does all the 32015 work of returning from the function. On these machines, give that 32016 instruction the name 'return' and do not define the macro 32017 'TARGET_ASM_FUNCTION_EPILOGUE' at all. 32018 32019 Do not define a pattern named 'return' if you want the 32020 'TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 32021 switches to control whether return instructions or epilogues are 32022 used, define a 'return' pattern with a validity condition that 32023 tests the target switches appropriately. If the 'return' pattern's 32024 validity condition is false, epilogues will be used. 32025 32026 On machines where functions may or may not have frame-pointers, the 32027 function exit code must vary accordingly. Sometimes the code for 32028 these two cases is completely different. To determine whether a 32029 frame pointer is wanted, the macro can refer to the variable 32030 'frame_pointer_needed'. The variable's value will be 1 when 32031 compiling a function that needs a frame pointer. 32032 32033 Normally, 'TARGET_ASM_FUNCTION_PROLOGUE' and 32034 'TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 32035 The C variable 'current_function_is_leaf' is nonzero for such a 32036 function. *Note Leaf Functions::. 32037 32038 On some machines, some functions pop their arguments on exit while 32039 others leave that for the caller to do. For example, the 68020 32040 when given '-mrtd' pops arguments in functions that take a fixed 32041 number of arguments. 32042 32043 Your definition of the macro 'RETURN_POPS_ARGS' decides which 32044 functions pop their own arguments. 'TARGET_ASM_FUNCTION_EPILOGUE' 32045 needs to know what was decided. The number of bytes of the current 32046 function's arguments that this function should pop is available in 32047 'crtl->args.pops_args'. *Note Scalar Return::. 32048 32049 * A region of 'crtl->args.pretend_args_size' bytes of uninitialized 32050 space just underneath the first argument arriving on the stack. 32051 (This may not be at the very start of the allocated stack region if 32052 the calling sequence has pushed anything else since pushing the 32053 stack arguments. But usually, on such machines, nothing else has 32054 been pushed yet, because the function prologue itself does all the 32055 pushing.) This region is used on machines where an argument may be 32056 passed partly in registers and partly in memory, and, in some cases 32057 to support the features in '<stdarg.h>'. 32058 32059 * An area of memory used to save certain registers used by the 32060 function. The size of this area, which may also include space for 32061 such things as the return address and pointers to previous stack 32062 frames, is machine-specific and usually depends on which registers 32063 have been used in the function. Machines with register windows 32064 often do not require a save area. 32065 32066 * A region of at least SIZE bytes, possibly rounded up to an 32067 allocation boundary, to contain the local variables of the 32068 function. On some machines, this region and the save area may 32069 occur in the opposite order, with the save area closer to the top 32070 of the stack. 32071 32072 * Optionally, when 'ACCUMULATE_OUTGOING_ARGS' is defined, a region of 32073 'crtl->outgoing_args_size' bytes to be used for outgoing argument 32074 lists of the function. *Note Stack Arguments::. 32075 32076 -- Macro: EXIT_IGNORE_STACK 32077 Define this macro as a C expression that is nonzero if the return 32078 instruction or the function epilogue ignores the value of the stack 32079 pointer; in other words, if it is safe to delete an instruction to 32080 adjust the stack pointer before a return from the function. The 32081 default is 0. 32082 32083 Note that this macro's value is relevant only for functions for 32084 which frame pointers are maintained. It is never safe to delete a 32085 final stack adjustment in a function that has no frame pointer, and 32086 the compiler knows this regardless of 'EXIT_IGNORE_STACK'. 32087 32088 -- Macro: EPILOGUE_USES (REGNO) 32089 Define this macro as a C expression that is nonzero for registers 32090 that are used by the epilogue or the 'return' pattern. The stack 32091 and frame pointer registers are already assumed to be used as 32092 needed. 32093 32094 -- Macro: EH_USES (REGNO) 32095 Define this macro as a C expression that is nonzero for registers 32096 that are used by the exception handling mechanism, and so should be 32097 considered live on entry to an exception edge. 32098 32099 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 32100 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 32101 tree FUNCTION) 32102 A function that outputs the assembler code for a thunk function, 32103 used to implement C++ virtual function calls with multiple 32104 inheritance. The thunk acts as a wrapper around a virtual 32105 function, adjusting the implicit object parameter before handing 32106 control off to the real function. 32107 32108 First, emit code to add the integer DELTA to the location that 32109 contains the incoming first argument. Assume that this argument 32110 contains a pointer, and is the one used to pass the 'this' pointer 32111 in C++. This is the incoming argument _before_ the function 32112 prologue, e.g. '%o0' on a sparc. The addition must preserve the 32113 values of all other incoming arguments. 32114 32115 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 32116 be made after adding 'delta'. In particular, if P is the adjusted 32117 pointer, the following adjustment should be made: 32118 32119 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 32120 32121 After the additions, emit code to jump to FUNCTION, which is a 32122 'FUNCTION_DECL'. This is a direct pure jump, not a call, and does 32123 not touch the return address. Hence returning from FUNCTION will 32124 return to whoever called the current 'thunk'. 32125 32126 The effect must be as if FUNCTION had been called directly with the 32127 adjusted first argument. This macro is responsible for emitting 32128 all of the code for a thunk function; 32129 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' 32130 are not invoked. 32131 32132 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 32133 been extracted from it.) It might possibly be useful on some 32134 targets, but probably not. 32135 32136 If you do not define this macro, the target-independent code in the 32137 C++ front end will generate a less efficient heavyweight thunk that 32138 calls FUNCTION instead of jumping to it. The generic approach does 32139 not support varargs. 32140 32141 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree 32142 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 32143 const_tree FUNCTION) 32144 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would be 32145 able to output the assembler code for the thunk function specified 32146 by the arguments it is passed, and false otherwise. In the latter 32147 case, the generic approach will be used by the C++ front end, with 32148 the limitations previously exposed. 32149 32150 32151File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 32152 3215317.9.12 Generating Code for Profiling 32154------------------------------------- 32155 32156These macros will help you generate code for profiling. 32157 32158 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 32159 A C statement or compound statement to output to FILE some 32160 assembler code to call the profiling subroutine 'mcount'. 32161 32162 The details of how 'mcount' expects to be called are determined by 32163 your operating system environment, not by GCC. To figure them out, 32164 compile a small program for profiling using the system's installed 32165 C compiler and look at the assembler code that results. 32166 32167 Older implementations of 'mcount' expect the address of a counter 32168 variable to be loaded into some register. The name of this 32169 variable is 'LP' followed by the number LABELNO, so you would 32170 generate the name using 'LP%d' in a 'fprintf'. 32171 32172 -- Macro: PROFILE_HOOK 32173 A C statement or compound statement to output to FILE some assembly 32174 code to call the profiling subroutine 'mcount' even the target does 32175 not support profiling. 32176 32177 -- Macro: NO_PROFILE_COUNTERS 32178 Define this macro to be an expression with a nonzero value if the 32179 'mcount' subroutine on your system does not need a counter variable 32180 allocated for each function. This is true for almost all modern 32181 implementations. If you define this macro, you must not use the 32182 LABELNO argument to 'FUNCTION_PROFILER'. 32183 32184 -- Macro: PROFILE_BEFORE_PROLOGUE 32185 Define this macro if the code for function profiling should come 32186 before the function prologue. Normally, the profiling code comes 32187 after. 32188 32189 -- Target Hook: bool TARGET_KEEP_LEAF_WHEN_PROFILED (void) 32190 This target hook returns true if the target wants the leaf flag for 32191 the current function to stay true even if it calls mcount. This 32192 might make sense for targets using the leaf flag only to determine 32193 whether a stack frame needs to be generated or not and for which 32194 the call to mcount is generated before the function prologue. 32195 32196 32197File: gccint.info, Node: Tail Calls, Next: Stack Smashing Protection, Prev: Profiling, Up: Stack and Calling 32198 3219917.9.13 Permitting tail calls 32200----------------------------- 32201 32202 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 32203 EXP) 32204 True if it is OK to do sibling call optimization for the specified 32205 call expression EXP. DECL will be the called function, or 'NULL' 32206 if this is an indirect call. 32207 32208 It is not uncommon for limitations of calling conventions to 32209 prevent tail calls to functions outside the current unit of 32210 translation, or during PIC compilation. The hook is used to 32211 enforce these restrictions, as the 'sibcall' md pattern can not 32212 fail, or fall over to a "normal" call. The criteria for successful 32213 sibling call optimization may vary greatly between different 32214 architectures. 32215 32216 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS) 32217 Add any hard registers to REGS that are live on entry to the 32218 function. This hook only needs to be defined to provide registers 32219 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 32220 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 32221 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, FRAME_POINTER_REGNUM, 32222 EH_USES, FRAME_POINTER_REGNUM, ARG_POINTER_REGNUM, and the 32223 PIC_OFFSET_TABLE_REGNUM. 32224 32225 -- Target Hook: void TARGET_SET_UP_BY_PROLOGUE (struct 32226 hard_reg_set_container *) 32227 This hook should add additional registers that are computed by the 32228 prologue to the hard regset for shrink-wrapping optimization 32229 purposes. 32230 32231 -- Target Hook: bool TARGET_WARN_FUNC_RETURN (tree) 32232 True if a function's return statements should be checked for 32233 matching the function's return type. This includes checking for 32234 falling off the end of a non-void function. Return false if no 32235 such check should be made. 32236 32237 32238File: gccint.info, Node: Stack Smashing Protection, Next: Miscellaneous Register Hooks, Prev: Tail Calls, Up: Stack and Calling 32239 3224017.9.14 Stack smashing protection 32241--------------------------------- 32242 32243 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 32244 This hook returns a 'DECL' node for the external variable to use 32245 for the stack protection guard. This variable is initialized by 32246 the runtime to some random value and is used to initialize the 32247 guard value that is placed at the top of the local stack frame. 32248 The type of this variable must be 'ptr_type_node'. 32249 32250 The default version of this hook creates a variable called 32251 '__stack_chk_guard', which is normally defined in 'libgcc2.c'. 32252 32253 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 32254 This hook returns a 'CALL_EXPR' that alerts the runtime that the 32255 stack protect guard variable has been modified. This expression 32256 should involve a call to a 'noreturn' function. 32257 32258 The default version of this hook invokes a function called 32259 '__stack_chk_fail', taking no arguments. This function is normally 32260 defined in 'libgcc2.c'. 32261 32262 -- Common Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT, 32263 struct gcc_options *OPTS) 32264 Whether this target supports splitting the stack when the options 32265 described in OPTS have been passed. This is called after options 32266 have been parsed, so the target may reject splitting the stack in 32267 some configurations. The default version of this hook returns 32268 false. If REPORT is true, this function may issue a warning or 32269 error; if REPORT is false, it must simply return a value 32270 32271 32272File: gccint.info, Node: Miscellaneous Register Hooks, Prev: Stack Smashing Protection, Up: Stack and Calling 32273 3227417.9.15 Miscellaneous register hooks 32275------------------------------------ 32276 32277 -- Target Hook: bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS 32278 Set to true if each call that binds to a local definition 32279 explicitly clobbers or sets all non-fixed registers modified by 32280 performing the call. That is, by the call pattern itself, or by 32281 code that might be inserted by the linker (e.g. stubs, veneers, 32282 branch islands), but not including those modifiable by the callee. 32283 The affected registers may be mentioned explicitly in the call 32284 pattern, or included as clobbers in CALL_INSN_FUNCTION_USAGE. The 32285 default version of this hook is set to false. The purpose of this 32286 hook is to enable the fipa-ra optimization. 32287 32288 32289File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 32290 3229117.10 Implementing the Varargs Macros 32292===================================== 32293 32294GCC comes with an implementation of '<varargs.h>' and '<stdarg.h>' that 32295work without change on machines that pass arguments on the stack. Other 32296machines require their own implementations of varargs, and the two 32297machine independent header files must have conditionals to include it. 32298 32299 ISO '<stdarg.h>' differs from traditional '<varargs.h>' mainly in the 32300calling convention for 'va_start'. The traditional implementation takes 32301just one argument, which is the variable in which to store the argument 32302pointer. The ISO implementation of 'va_start' takes an additional 32303second argument. The user is supposed to write the last named argument 32304of the function here. 32305 32306 However, 'va_start' should not use this argument. The way to find the 32307end of the named arguments is with the built-in functions described 32308below. 32309 32310 -- Macro: __builtin_saveregs () 32311 Use this built-in function to save the argument registers in memory 32312 so that the varargs mechanism can access them. Both ISO and 32313 traditional versions of 'va_start' must use '__builtin_saveregs', 32314 unless you use 'TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 32315 32316 On some machines, '__builtin_saveregs' is open-coded under the 32317 control of the target hook 'TARGET_EXPAND_BUILTIN_SAVEREGS'. On 32318 other machines, it calls a routine written in assembler language, 32319 found in 'libgcc2.c'. 32320 32321 Code generated for the call to '__builtin_saveregs' appears at the 32322 beginning of the function, as opposed to where the call to 32323 '__builtin_saveregs' is written, regardless of what the code is. 32324 This is because the registers must be saved before the function 32325 starts to use them for its own purposes. 32326 32327 -- Macro: __builtin_next_arg (LASTARG) 32328 This builtin returns the address of the first anonymous stack 32329 argument, as type 'void *'. If 'ARGS_GROW_DOWNWARD', it returns 32330 the address of the location above the first anonymous stack 32331 argument. Use it in 'va_start' to initialize the pointer for 32332 fetching arguments from the stack. Also use it in 'va_start' to 32333 verify that the second parameter LASTARG is the last named argument 32334 of the current function. 32335 32336 -- Macro: __builtin_classify_type (OBJECT) 32337 Since each machine has its own conventions for which data types are 32338 passed in which kind of register, your implementation of 'va_arg' 32339 has to embody these conventions. The easiest way to categorize the 32340 specified data type is to use '__builtin_classify_type' together 32341 with 'sizeof' and '__alignof__'. 32342 32343 '__builtin_classify_type' ignores the value of OBJECT, considering 32344 only its data type. It returns an integer describing what kind of 32345 type that is--integer, floating, pointer, structure, and so on. 32346 32347 The file 'typeclass.h' defines an enumeration that you can use to 32348 interpret the values of '__builtin_classify_type'. 32349 32350 These machine description macros help implement varargs: 32351 32352 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 32353 If defined, this hook produces the machine-specific code for a call 32354 to '__builtin_saveregs'. This code will be moved to the very 32355 beginning of the function, before any parameter access are made. 32356 The return value of this function should be an RTX that contains 32357 the value to use as the return of '__builtin_saveregs'. 32358 32359 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t 32360 ARGS_SO_FAR, machine_mode MODE, tree TYPE, int 32361 *PRETEND_ARGS_SIZE, int SECOND_TIME) 32362 This target hook offers an alternative to using 32363 '__builtin_saveregs' and defining the hook 32364 'TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 32365 register arguments into the stack so that all the arguments appear 32366 to have been passed consecutively on the stack. Once this is done, 32367 you can use the standard implementation of varargs that works for 32368 machines that pass all their arguments on the stack. 32369 32370 The argument ARGS_SO_FAR points to the 'CUMULATIVE_ARGS' data 32371 structure, containing the values that are obtained after processing 32372 the named arguments. The arguments MODE and TYPE describe the last 32373 named argument--its machine mode and its data type as a tree node. 32374 32375 The target hook should do two things: first, push onto the stack 32376 all the argument registers _not_ used for the named arguments, and 32377 second, store the size of the data thus pushed into the 32378 'int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 32379 that you store here will serve as additional offset for setting up 32380 the stack frame. 32381 32382 Because you must generate code to push the anonymous arguments at 32383 compile time without knowing their data types, 32384 'TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 32385 have just a single category of argument register and use it 32386 uniformly for all data types. 32387 32388 If the argument SECOND_TIME is nonzero, it means that the arguments 32389 of the function are being analyzed for the second time. This 32390 happens for an inline function, which is not actually compiled 32391 until the end of the source file. The hook 32392 'TARGET_SETUP_INCOMING_VARARGS' should not generate any 32393 instructions in this case. 32394 32395 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t 32396 CA) 32397 Define this hook to return 'true' if the location where a function 32398 argument is passed depends on whether or not it is a named 32399 argument. 32400 32401 This hook controls how the NAMED argument to 'TARGET_FUNCTION_ARG' 32402 is set for varargs and stdarg functions. If this hook returns 32403 'true', the NAMED argument is always true for named arguments, and 32404 false for unnamed arguments. If it returns 'false', but 32405 'TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns 'true', then all 32406 arguments are treated as named. Otherwise, all named arguments 32407 except the last are treated as named. 32408 32409 You need not define this hook if it always returns 'false'. 32410 32411 -- Target Hook: void TARGET_CALL_ARGS (rtx, TREE) 32412 While generating RTL for a function call, this target hook is 32413 invoked once for each argument passed to the function, either a 32414 register returned by 'TARGET_FUNCTION_ARG' or a memory location. 32415 It is called just before the point where argument registers are 32416 stored. The type of the function to be called is also passed as 32417 the second argument; it is 'NULL_TREE' for libcalls. The 32418 'TARGET_END_CALL_ARGS' hook is invoked just after the code to copy 32419 the return reg has been emitted. This functionality can be used to 32420 perform special setup of call argument registers if a target needs 32421 it. For functions without arguments, the hook is called once with 32422 'pc_rtx' passed instead of an argument register. Most ports do not 32423 need to implement anything for this hook. 32424 32425 -- Target Hook: void TARGET_END_CALL_ARGS (void) 32426 This target hook is invoked while generating RTL for a function 32427 call, just after the point where the return reg is copied into a 32428 pseudo. It signals that all the call argument and return registers 32429 for the just emitted call are now no longer in use. Most ports do 32430 not need to implement anything for this hook. 32431 32432 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 32433 (cumulative_args_t CA) 32434 If you need to conditionally change ABIs so that one works with 32435 'TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 32436 'TARGET_SETUP_INCOMING_VARARGS' nor 'TARGET_STRICT_ARGUMENT_NAMING' 32437 was defined, then define this hook to return 'true' if 32438 'TARGET_SETUP_INCOMING_VARARGS' is used, 'false' otherwise. 32439 Otherwise, you should not define this hook. 32440 32441 -- Target Hook: rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx SLOT, rtx ARG, rtx 32442 SLOT_NO) 32443 This hook is used by expand pass to emit insn to load bounds of ARG 32444 passed in SLOT. Expand pass uses this hook in case bounds of ARG 32445 are not passed in register. If SLOT is a memory, then bounds are 32446 loaded as for regular pointer loaded from memory. If SLOT is not a 32447 memory then SLOT_NO is an integer constant holding number of the 32448 target dependent special slot which should be used to obtain 32449 bounds. Hook returns RTX holding loaded bounds. 32450 32451 -- Target Hook: void TARGET_STORE_BOUNDS_FOR_ARG (rtx ARG, rtx SLOT, 32452 rtx BOUNDS, rtx SLOT_NO) 32453 This hook is used by expand pass to emit insns to store BOUNDS of 32454 ARG passed in SLOT. Expand pass uses this hook in case BOUNDS of 32455 ARG are not passed in register. If SLOT is a memory, then BOUNDS 32456 are stored as for regular pointer stored in memory. If SLOT is not 32457 a memory then SLOT_NO is an integer constant holding number of the 32458 target dependent special slot which should be used to store BOUNDS. 32459 32460 -- Target Hook: rtx TARGET_LOAD_RETURNED_BOUNDS (rtx SLOT) 32461 This hook is used by expand pass to emit insn to load bounds 32462 returned by function call in SLOT. Hook returns RTX holding loaded 32463 bounds. 32464 32465 -- Target Hook: void TARGET_STORE_RETURNED_BOUNDS (rtx SLOT, rtx 32466 BOUNDS) 32467 This hook is used by expand pass to emit insn to store BOUNDS 32468 returned by function call into SLOT. 32469 32470 -- Target Hook: rtx TARGET_CHKP_FUNCTION_VALUE_BOUNDS (const_tree 32471 RET_TYPE, const_tree FN_DECL_OR_TYPE, bool OUTGOING) 32472 Define this to return an RTX representing the place where a 32473 function returns bounds for returned pointers. Arguments meaning 32474 is similar to 'TARGET_FUNCTION_VALUE'. 32475 32476 -- Target Hook: void TARGET_SETUP_INCOMING_VARARG_BOUNDS 32477 (cumulative_args_t ARGS_SO_FAR, enum machine_mode MODE, tree 32478 TYPE, int *PRETEND_ARGS_SIZE, int SECOND_TIME) 32479 Use it to store bounds for anonymous register arguments stored into 32480 the stack. Arguments meaning is similar to 32481 'TARGET_SETUP_INCOMING_VARARGS'. 32482 32483 32484File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 32485 3248617.11 Trampolines for Nested Functions 32487====================================== 32488 32489A "trampoline" is a small piece of code that is created at run time when 32490the address of a nested function is taken. It normally resides on the 32491stack, in the stack frame of the containing function. These macros tell 32492GCC how to generate code to allocate and initialize a trampoline. 32493 32494 The instructions in the trampoline must do two things: load a constant 32495address into the static chain register, and jump to the real address of 32496the nested function. On CISC machines such as the m68k, this requires 32497two instructions, a move immediate and a jump. Then the two addresses 32498exist in the trampoline as word-long immediate operands. On RISC 32499machines, it is often necessary to load each address into a register in 32500two parts. Then pieces of each address form separate immediate 32501operands. 32502 32503 The code generated to initialize the trampoline must store the variable 32504parts--the static chain value and the function address--into the 32505immediate operands of the instructions. On a CISC machine, this is 32506simply a matter of copying each address to a memory reference at the 32507proper offset from the start of the trampoline. On a RISC machine, it 32508may be necessary to take out pieces of the address and store them 32509separately. 32510 32511 -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F) 32512 This hook is called by 'assemble_trampoline_template' to output, on 32513 the stream F, assembler code for a block of data that contains the 32514 constant parts of a trampoline. This code should not include a 32515 label--the label is taken care of automatically. 32516 32517 If you do not define this hook, it means no template is needed for 32518 the target. Do not define this hook on systems where the block 32519 move code to copy the trampoline into place would be larger than 32520 the code to generate it on the spot. 32521 32522 -- Macro: TRAMPOLINE_SECTION 32523 Return the section into which the trampoline template is to be 32524 placed (*note Sections::). The default value is 32525 'readonly_data_section'. 32526 32527 -- Macro: TRAMPOLINE_SIZE 32528 A C expression for the size in bytes of the trampoline, as an 32529 integer. 32530 32531 -- Macro: TRAMPOLINE_ALIGNMENT 32532 Alignment required for trampolines, in bits. 32533 32534 If you don't define this macro, the value of 'FUNCTION_ALIGNMENT' 32535 is used for aligning trampolines. 32536 32537 -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL, 32538 rtx STATIC_CHAIN) 32539 This hook is called to initialize a trampoline. M_TRAMP is an RTX 32540 for the memory block for the trampoline; FNDECL is the 32541 'FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX for 32542 the static chain value that should be passed to the function when 32543 it is called. 32544 32545 If the target defines 'TARGET_ASM_TRAMPOLINE_TEMPLATE', then the 32546 first thing this hook should do is emit a block move into M_TRAMP 32547 from the memory block returned by 'assemble_trampoline_template'. 32548 Note that the block move need only cover the constant parts of the 32549 trampoline. If the target isolates the variable parts of the 32550 trampoline to the end, not all 'TRAMPOLINE_SIZE' bytes need be 32551 copied. 32552 32553 If the target requires any other actions, such as flushing caches 32554 or enabling stack execution, these actions should be performed 32555 after initializing the trampoline proper. 32556 32557 -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR) 32558 This hook should perform any machine-specific adjustment in the 32559 address of the trampoline. Its argument contains the address of 32560 the memory block that was passed to 'TARGET_TRAMPOLINE_INIT'. In 32561 case the address to be used for a function call should be different 32562 from the address at which the template was stored, the different 32563 address should be returned; otherwise ADDR should be returned 32564 unchanged. If this hook is not defined, ADDR will be used for 32565 function calls. 32566 32567 Implementing trampolines is difficult on many machines because they 32568have separate instruction and data caches. Writing into a stack 32569location fails to clear the memory in the instruction cache, so when the 32570program jumps to that location, it executes the old contents. 32571 32572 Here are two possible solutions. One is to clear the relevant parts of 32573the instruction cache whenever a trampoline is set up. The other is to 32574make all trampolines identical, by having them jump to a standard 32575subroutine. The former technique makes trampoline execution faster; the 32576latter makes initialization faster. 32577 32578 To clear the instruction cache when a trampoline is initialized, define 32579the following macro. 32580 32581 -- Macro: CLEAR_INSN_CACHE (BEG, END) 32582 If defined, expands to a C expression clearing the _instruction 32583 cache_ in the specified interval. The definition of this macro 32584 would typically be a series of 'asm' statements. Both BEG and END 32585 are both pointer expressions. 32586 32587 To use a standard subroutine, define the following macro. In addition, 32588you must make sure that the instructions in a trampoline fill an entire 32589cache line with identical instructions, or else ensure that the 32590beginning of the trampoline code is always aligned at the same point in 32591its cache line. Look in 'm68k.h' as a guide. 32592 32593 -- Macro: TRANSFER_FROM_TRAMPOLINE 32594 Define this macro if trampolines need a special subroutine to do 32595 their work. The macro should expand to a series of 'asm' 32596 statements which will be compiled with GCC. They go in a library 32597 function named '__transfer_from_trampoline'. 32598 32599 If you need to avoid executing the ordinary prologue code of a 32600 compiled C function when you jump to the subroutine, you can do so 32601 by placing a special label of your own in the assembler code. Use 32602 one 'asm' statement to generate an assembler label, and another to 32603 make the label global. Then trampolines can use that label to jump 32604 directly to your special assembler code. 32605 32606 32607File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 32608 3260917.12 Implicit Calls to Library Routines 32610======================================== 32611 32612Here is an explanation of implicit calls to library routines. 32613 32614 -- Macro: DECLARE_LIBRARY_RENAMES 32615 This macro, if defined, should expand to a piece of C code that 32616 will get expanded when compiling functions for libgcc.a. It can be 32617 used to provide alternate names for GCC's internal library 32618 functions if there are ABI-mandated names that the compiler should 32619 provide. 32620 32621 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 32622 This hook should declare additional library routines or rename 32623 existing ones, using the functions 'set_optab_libfunc' and 32624 'init_one_libfunc' defined in 'optabs.c'. 'init_optabs' calls this 32625 macro after initializing all the normal library routines. 32626 32627 The default is to do nothing. Most ports don't need to define this 32628 hook. 32629 32630 -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX 32631 If false (the default), internal library routines start with two 32632 underscores. If set to true, these routines start with '__gnu_' 32633 instead. E.g., '__muldi3' changes to '__gnu_muldi3'. This 32634 currently only affects functions defined in 'libgcc2.c'. If this 32635 is set to true, the 'tm.h' file must also '#define 32636 LIBGCC2_GNU_PREFIX'. 32637 32638 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 32639 This macro should return 'true' if the library routine that 32640 implements the floating point comparison operator COMPARISON in 32641 mode MODE will return a boolean, and FALSE if it will return a 32642 tristate. 32643 32644 GCC's own floating point libraries return tristates from the 32645 comparison operators, so the default returns false always. Most 32646 ports don't need to define this macro. 32647 32648 -- Macro: TARGET_LIB_INT_CMP_BIASED 32649 This macro should evaluate to 'true' if the integer comparison 32650 functions (like '__cmpdi2') return 0 to indicate that the first 32651 operand is smaller than the second, 1 to indicate that they are 32652 equal, and 2 to indicate that the first operand is greater than the 32653 second. If this macro evaluates to 'false' the comparison 32654 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 32655 target uses the routines in 'libgcc.a', you do not need to define 32656 this macro. 32657 32658 -- Macro: TARGET_HAS_NO_HW_DIVIDE 32659 This macro should be defined if the target has no hardware divide 32660 instructions. If this macro is defined, GCC will use an algorithm 32661 which make use of simple logical and arithmetic operations for 32662 64-bit division. If the macro is not defined, GCC will use an 32663 algorithm which make use of a 64-bit by 32-bit divide primitive. 32664 32665 -- Macro: TARGET_EDOM 32666 The value of 'EDOM' on the target machine, as a C integer constant 32667 expression. If you don't define this macro, GCC does not attempt 32668 to deposit the value of 'EDOM' into 'errno' directly. Look in 32669 '/usr/include/errno.h' to find the value of 'EDOM' on your system. 32670 32671 If you do not define 'TARGET_EDOM', then compiled code reports 32672 domain errors by calling the library function and letting it report 32673 the error. If mathematical functions on your system use 'matherr' 32674 when there is an error, then you should leave 'TARGET_EDOM' 32675 undefined so that 'matherr' is used normally. 32676 32677 -- Macro: GEN_ERRNO_RTX 32678 Define this macro as a C expression to create an rtl expression 32679 that refers to the global "variable" 'errno'. (On certain systems, 32680 'errno' may not actually be a variable.) If you don't define this 32681 macro, a reasonable default is used. 32682 32683 -- Target Hook: bool TARGET_LIBC_HAS_FUNCTION (enum function_class 32684 FN_CLASS) 32685 This hook determines whether a function from a class of functions 32686 FN_CLASS is present at the runtime. 32687 32688 -- Macro: NEXT_OBJC_RUNTIME 32689 Set this macro to 1 to use the "NeXT" Objective-C message sending 32690 conventions by default. This calling convention involves passing 32691 the object, the selector and the method arguments all at once to 32692 the method-lookup library function. This is the usual setting when 32693 targeting Darwin/Mac OS X systems, which have the NeXT runtime 32694 installed. 32695 32696 If the macro is set to 0, the "GNU" Objective-C message sending 32697 convention will be used by default. This convention passes just 32698 the object and the selector to the method-lookup function, which 32699 returns a pointer to the method. 32700 32701 In either case, it remains possible to select code-generation for 32702 the alternate scheme, by means of compiler command line switches. 32703 32704 32705File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 32706 3270717.13 Addressing Modes 32708====================== 32709 32710This is about addressing modes. 32711 32712 -- Macro: HAVE_PRE_INCREMENT 32713 -- Macro: HAVE_PRE_DECREMENT 32714 -- Macro: HAVE_POST_INCREMENT 32715 -- Macro: HAVE_POST_DECREMENT 32716 A C expression that is nonzero if the machine supports 32717 pre-increment, pre-decrement, post-increment, or post-decrement 32718 addressing respectively. 32719 32720 -- Macro: HAVE_PRE_MODIFY_DISP 32721 -- Macro: HAVE_POST_MODIFY_DISP 32722 A C expression that is nonzero if the machine supports pre- or 32723 post-address side-effect generation involving constants other than 32724 the size of the memory operand. 32725 32726 -- Macro: HAVE_PRE_MODIFY_REG 32727 -- Macro: HAVE_POST_MODIFY_REG 32728 A C expression that is nonzero if the machine supports pre- or 32729 post-address side-effect generation involving a register 32730 displacement. 32731 32732 -- Macro: CONSTANT_ADDRESS_P (X) 32733 A C expression that is 1 if the RTX X is a constant which is a 32734 valid address. On most machines the default definition of 32735 '(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable, 32736 but a few machines are more restrictive as to which constant 32737 addresses are supported. 32738 32739 -- Macro: CONSTANT_P (X) 32740 'CONSTANT_P', which is defined by target-independent code, accepts 32741 integer-values expressions whose values are not explicitly known, 32742 such as 'symbol_ref', 'label_ref', and 'high' expressions and 32743 'const' arithmetic expressions, in addition to 'const_int' and 32744 'const_double' expressions. 32745 32746 -- Macro: MAX_REGS_PER_ADDRESS 32747 A number, the maximum number of registers that can appear in a 32748 valid memory address. Note that it is up to you to specify a value 32749 equal to the maximum number that 'TARGET_LEGITIMATE_ADDRESS_P' 32750 would ever accept. 32751 32752 -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (machine_mode MODE, 32753 rtx X, bool STRICT) 32754 A function that returns whether X (an RTX) is a legitimate memory 32755 address on the target machine for a memory operand of mode MODE. 32756 32757 Legitimate addresses are defined in two variants: a strict variant 32758 and a non-strict one. The STRICT parameter chooses which variant 32759 is desired by the caller. 32760 32761 The strict variant is used in the reload pass. It must be defined 32762 so that any pseudo-register that has not been allocated a hard 32763 register is considered a memory reference. This is because in 32764 contexts where some kind of register is required, a pseudo-register 32765 with no hard register must be rejected. For non-hard registers, 32766 the strict variant should look up the 'reg_renumber' array; it 32767 should then proceed using the hard register number in the array, or 32768 treat the pseudo as a memory reference if the array holds '-1'. 32769 32770 The non-strict variant is used in other passes. It must be defined 32771 to accept all pseudo-registers in every context where some kind of 32772 register is required. 32773 32774 Normally, constant addresses which are the sum of a 'symbol_ref' 32775 and an integer are stored inside a 'const' RTX to mark them as 32776 constant. Therefore, there is no need to recognize such sums 32777 specifically as legitimate addresses. Normally you would simply 32778 recognize any 'const' as legitimate. 32779 32780 Usually 'PRINT_OPERAND_ADDRESS' is not prepared to handle constant 32781 sums that are not marked with 'const'. It assumes that a naked 32782 'plus' indicates indexing. If so, then you _must_ reject such 32783 naked constant sums as illegitimate addresses, so that none of them 32784 will be given to 'PRINT_OPERAND_ADDRESS'. 32785 32786 On some machines, whether a symbolic address is legitimate depends 32787 on the section that the address refers to. On these machines, 32788 define the target hook 'TARGET_ENCODE_SECTION_INFO' to store the 32789 information into the 'symbol_ref', and then check for it here. 32790 When you see a 'const', you will have to look inside it to find the 32791 'symbol_ref' in order to determine the section. *Note Assembler 32792 Format::. 32793 32794 Some ports are still using a deprecated legacy substitute for this 32795 hook, the 'GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this 32796 syntax: 32797 32798 #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 32799 32800 and should 'goto LABEL' if the address X is a valid address on the 32801 target machine for a memory operand of mode MODE. 32802 32803 Compiler source files that want to use the strict variant of this 32804 macro define the macro 'REG_OK_STRICT'. You should use an '#ifdef 32805 REG_OK_STRICT' conditional to define the strict variant in that 32806 case and the non-strict variant otherwise. 32807 32808 Using the hook is usually simpler because it limits the number of 32809 files that are recompiled when changes are made. 32810 32811 -- Macro: TARGET_MEM_CONSTRAINT 32812 A single character to be used instead of the default ''m'' 32813 character for general memory addresses. This defines the 32814 constraint letter which matches the memory addresses accepted by 32815 'TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to 32816 support new address formats in your back end without changing the 32817 semantics of the ''m'' constraint. This is necessary in order to 32818 preserve functionality of inline assembly constructs using the 32819 ''m'' constraint. 32820 32821 -- Macro: FIND_BASE_TERM (X) 32822 A C expression to determine the base term of address X, or to 32823 provide a simplified version of X from which 'alias.c' can easily 32824 find the base term. This macro is used in only two places: 32825 'find_base_value' and 'find_base_term' in 'alias.c'. 32826 32827 It is always safe for this macro to not be defined. It exists so 32828 that alias analysis can understand machine-dependent addresses. 32829 32830 The typical use of this macro is to handle addresses containing a 32831 label_ref or symbol_ref within an UNSPEC. 32832 32833 -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, 32834 machine_mode MODE) 32835 This hook is given an invalid memory address X for an operand of 32836 mode MODE and should try to return a valid memory address. 32837 32838 X will always be the result of a call to 'break_out_memory_refs', 32839 and OLDX will be the operand that was given to that function to 32840 produce X. 32841 32842 The code of the hook should not alter the substructure of X. If it 32843 transforms X into a more legitimate form, it should return the new 32844 X. 32845 32846 It is not necessary for this hook to come up with a legitimate 32847 address, with the exception of native TLS addresses (*note Emulated 32848 TLS::). The compiler has standard ways of doing so in all cases. 32849 In fact, if the target supports only emulated TLS, it is safe to 32850 omit this hook or make it return X if it cannot find a valid way to 32851 legitimize the address. But often a machine-dependent strategy can 32852 generate better code. 32853 32854 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 32855 WIN) 32856 A C compound statement that attempts to replace X, which is an 32857 address that needs reloading, with a valid memory address for an 32858 operand of mode MODE. WIN will be a C statement label elsewhere in 32859 the code. It is not necessary to define this macro, but it might 32860 be useful for performance reasons. 32861 32862 For example, on the i386, it is sometimes possible to use a single 32863 reload register instead of two by reloading a sum of two pseudo 32864 registers into a register. On the other hand, for number of RISC 32865 processors offsets are limited so that often an intermediate 32866 address needs to be generated in order to address a stack slot. By 32867 defining 'LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 32868 intermediate addresses generated for adjacent some stack slots can 32869 be made identical, and thus be shared. 32870 32871 _Note_: This macro should be used with caution. It is necessary to 32872 know something of how reload works in order to effectively use 32873 this, and it is quite easy to produce macros that build in too much 32874 knowledge of reload internals. 32875 32876 _Note_: This macro must be able to reload an address created by a 32877 previous invocation of this macro. If it fails to handle such 32878 addresses then the compiler may generate incorrect code or abort. 32879 32880 The macro definition should use 'push_reload' to indicate parts 32881 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 32882 suitable to be passed unaltered to 'push_reload'. 32883 32884 The code generated by this macro must not alter the substructure of 32885 X. If it transforms X into a more legitimate form, it should 32886 assign X (which will always be a C variable) a new value. This 32887 also applies to parts that you change indirectly by calling 32888 'push_reload'. 32889 32890 The macro definition may use 'strict_memory_address_p' to test if 32891 the address has become legitimate. 32892 32893 If you want to change only a part of X, one standard way of doing 32894 this is to use 'copy_rtx'. Note, however, that it unshares only a 32895 single level of rtl. Thus, if the part to be changed is not at the 32896 top level, you'll need to replace first the top level. It is not 32897 necessary for this macro to come up with a legitimate address; but 32898 often a machine-dependent strategy can generate better code. 32899 32900 -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR, 32901 addr_space_t ADDRSPACE) 32902 This hook returns 'true' if memory address ADDR in address space 32903 ADDRSPACE can have different meanings depending on the machine mode 32904 of the memory reference it is used for or if the address is valid 32905 for some modes but not others. 32906 32907 Autoincrement and autodecrement addresses typically have 32908 mode-dependent effects because the amount of the increment or 32909 decrement is the size of the operand being addressed. Some 32910 machines have other mode-dependent addresses. Many RISC machines 32911 have no mode-dependent addresses. 32912 32913 You may assume that ADDR is a valid address for the machine. 32914 32915 The default version of this hook returns 'false'. 32916 32917 -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (machine_mode MODE, 32918 rtx X) 32919 This hook returns true if X is a legitimate constant for a 32920 MODE-mode immediate operand on the target machine. You can assume 32921 that X satisfies 'CONSTANT_P', so you need not check this. 32922 32923 The default definition returns true. 32924 32925 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 32926 This hook is used to undo the possibly obfuscating effects of the 32927 'LEGITIMIZE_ADDRESS' and 'LEGITIMIZE_RELOAD_ADDRESS' target macros. 32928 Some backend implementations of these macros wrap symbol references 32929 inside an 'UNSPEC' rtx to represent PIC or similar addressing 32930 modes. This target hook allows GCC's optimizers to understand the 32931 semantics of these opaque 'UNSPEC's by converting them back into 32932 their original form. 32933 32934 -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X) 32935 This hook should return true if X should not be emitted into debug 32936 sections. 32937 32938 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (machine_mode MODE, 32939 rtx X) 32940 This hook should return true if X is of a form that cannot (or 32941 should not) be spilled to the constant pool. MODE is the mode of 32942 X. 32943 32944 The default version of this hook returns false. 32945 32946 The primary reason to define this hook is to prevent reload from 32947 deciding that a non-legitimate constant would be better reloaded 32948 from the constant pool instead of spilling and reloading a register 32949 holding the constant. This restriction is often true of addresses 32950 of TLS symbols for various targets. 32951 32952 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (machine_mode 32953 MODE, const_rtx X) 32954 This hook should return true if pool entries for constant X can be 32955 placed in an 'object_block' structure. MODE is the mode of X. 32956 32957 The default version returns false for all constants. 32958 32959 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL) 32960 This hook should return true if pool entries for DECL should be 32961 placed in an 'object_block' structure. 32962 32963 The default version returns true for all decls. 32964 32965 -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (tree FNDECL) 32966 This hook should return the DECL of a function that implements the 32967 reciprocal of the machine-specific builtin function FNDECL, or 32968 'NULL_TREE' if such a function is not available. 32969 32970 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 32971 This hook should return the DECL of a function F that given an 32972 address ADDR as an argument returns a mask M that can be used to 32973 extract from two vectors the relevant data that resides in ADDR in 32974 case ADDR is not properly aligned. 32975 32976 The autovectorizer, when vectorizing a load operation from an 32977 address ADDR that may be unaligned, will generate two vector loads 32978 from the two aligned addresses around ADDR. It then generates a 32979 'REALIGN_LOAD' operation to extract the relevant data from the two 32980 loaded vectors. The first two arguments to 'REALIGN_LOAD', V1 and 32981 V2, are the two vectors, each of size VS, and the third argument, 32982 OFF, defines how the data will be extracted from these two vectors: 32983 if OFF is 0, then the returned vector is V2; otherwise, the 32984 returned vector is composed from the last VS-OFF elements of V1 32985 concatenated to the first OFF elements of V2. 32986 32987 If this hook is defined, the autovectorizer will generate a call to 32988 F (using the DECL tree that this hook returns) and will use the 32989 return value of F as the argument OFF to 'REALIGN_LOAD'. 32990 Therefore, the mask M returned by F should comply with the 32991 semantics expected by 'REALIGN_LOAD' described above. If this hook 32992 is not defined, then ADDR will be used as the argument OFF to 32993 'REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR 32994 will be considered. 32995 32996 -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum 32997 vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN) 32998 Returns cost of different scalar or vector statements for 32999 vectorization cost model. For vector memory operations the cost 33000 may depend on type (VECTYPE) and misalignment value (MISALIGN). 33001 33002 -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE 33003 (const_tree TYPE, bool IS_PACKED) 33004 Return true if vector alignment is reachable (by peeling N 33005 iterations) for the given scalar type TYPE. IS_PACKED is false if 33006 the scalar access using TYPE is known to be naturally aligned. 33007 33008 -- Target Hook: bool TARGET_VECTORIZE_VEC_PERM_CONST_OK (machine_mode, 33009 const unsigned char *SEL) 33010 Return true if a vector created for 'vec_perm_const' is valid. 33011 33012 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (unsigned 33013 CODE, tree DEST_TYPE, tree SRC_TYPE) 33014 This hook should return the DECL of a function that implements 33015 conversion of the input vector of type SRC_TYPE to type DEST_TYPE. 33016 The value of CODE is one of the enumerators in 'enum tree_code' and 33017 specifies how the conversion is to be applied (truncation, 33018 rounding, etc.). 33019 33020 If this hook is defined, the autovectorizer will use the 33021 'TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing 33022 conversion. Otherwise, it will return 'NULL_TREE'. 33023 33024 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION 33025 (unsigned CODE, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 33026 This hook should return the decl of a function that implements the 33027 vectorized variant of the function with the 'combined_fn' code CODE 33028 or 'NULL_TREE' if such a function is not available. The return 33029 type of the vectorized function shall be of vector type 33030 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 33031 33032 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION 33033 (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 33034 This hook should return the decl of a function that implements the 33035 vectorized variant of target built-in function 'fndecl'. The 33036 return type of the vectorized function shall be of vector type 33037 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 33038 33039 -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT 33040 (machine_mode MODE, const_tree TYPE, int MISALIGNMENT, bool 33041 IS_PACKED) 33042 This hook should return true if the target supports misaligned 33043 vector store/load of a specific factor denoted in the MISALIGNMENT 33044 parameter. The vector store/load should be of machine mode MODE 33045 and the elements in the vectors should be of type TYPE. IS_PACKED 33046 parameter is true if the memory access is defined in a packed 33047 struct. 33048 33049 -- Target Hook: machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE 33050 (machine_mode MODE) 33051 This hook should return the preferred mode for vectorizing scalar 33052 mode MODE. The default is equal to 'word_mode', because the 33053 vectorizer can do some transformations even in absence of 33054 specialized SIMD hardware. 33055 33056 -- Target Hook: unsigned int 33057 TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES (void) 33058 This hook should return a mask of sizes that should be iterated 33059 over after trying to autovectorize using the vector size derived 33060 from the mode returned by 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE'. 33061 The default is zero which means to not iterate over other vector 33062 sizes. 33063 33064 -- Target Hook: machine_mode TARGET_VECTORIZE_GET_MASK_MODE (unsigned 33065 NUNITS, unsigned LENGTH) 33066 This hook returns mode to be used for a mask to be used for a 33067 vector of specified LENGTH with NUNITS elements. By default an 33068 integer vector mode of a proper size is returned. 33069 33070 -- Target Hook: void * TARGET_VECTORIZE_INIT_COST (struct loop 33071 *LOOP_INFO) 33072 This hook should initialize target-specific data structures in 33073 preparation for modeling the costs of vectorizing a loop or basic 33074 block. The default allocates three unsigned integers for 33075 accumulating costs for the prologue, body, and epilogue of the loop 33076 or basic block. If LOOP_INFO is non-NULL, it identifies the loop 33077 being vectorized; otherwise a single block is being vectorized. 33078 33079 -- Target Hook: unsigned TARGET_VECTORIZE_ADD_STMT_COST (void *DATA, 33080 int COUNT, enum vect_cost_for_stmt KIND, struct _stmt_vec_info 33081 *STMT_INFO, int MISALIGN, enum vect_cost_model_location WHERE) 33082 This hook should update the target-specific DATA in response to 33083 adding COUNT copies of the given KIND of statement to a loop or 33084 basic block. The default adds the builtin vectorizer cost for the 33085 copies of the statement to the accumulator specified by WHERE, (the 33086 prologue, body, or epilogue) and returns the amount added. The 33087 return value should be viewed as a tentative cost that may later be 33088 revised. 33089 33090 -- Target Hook: void TARGET_VECTORIZE_FINISH_COST (void *DATA, unsigned 33091 *PROLOGUE_COST, unsigned *BODY_COST, unsigned *EPILOGUE_COST) 33092 This hook should complete calculations of the cost of vectorizing a 33093 loop or basic block based on DATA, and return the prologue, body, 33094 and epilogue costs as unsigned integers. The default returns the 33095 value of the three accumulators. 33096 33097 -- Target Hook: void TARGET_VECTORIZE_DESTROY_COST_DATA (void *DATA) 33098 This hook should release DATA and any related data structures 33099 allocated by TARGET_VECTORIZE_INIT_COST. The default releases the 33100 accumulator. 33101 33102 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_GATHER (const_tree 33103 MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE) 33104 Target builtin that implements vector gather operation. 33105 MEM_VECTYPE is the vector type of the load and INDEX_TYPE is scalar 33106 type of the index, scaled by SCALE. The default is 'NULL_TREE' 33107 which means to not vectorize gather loads. 33108 33109 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_SCATTER (const_tree 33110 VECTYPE, const_tree INDEX_TYPE, int SCALE) 33111 Target builtin that implements vector scatter operation. VECTYPE 33112 is the vector type of the store and INDEX_TYPE is scalar type of 33113 the index, scaled by SCALE. The default is 'NULL_TREE' which means 33114 to not vectorize scatter stores. 33115 33116 -- Target Hook: int TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN 33117 (struct cgraph_node *, struct cgraph_simd_clone *, TREE, INT) 33118 This hook should set VECSIZE_MANGLE, VECSIZE_INT, VECSIZE_FLOAT 33119 fields in SIMD_CLONE structure pointed by CLONE_INFO argument and 33120 also SIMDLEN field if it was previously 0. The hook should return 33121 0 if SIMD clones shouldn't be emitted, or number of VECSIZE_MANGLE 33122 variants that should be emitted. 33123 33124 -- Target Hook: void TARGET_SIMD_CLONE_ADJUST (struct cgraph_node *) 33125 This hook should add implicit 'attribute(target("..."))' attribute 33126 to SIMD clone NODE if needed. 33127 33128 -- Target Hook: int TARGET_SIMD_CLONE_USABLE (struct cgraph_node *) 33129 This hook should return -1 if SIMD clone NODE shouldn't be used in 33130 vectorized loops in current function, or non-negative number if it 33131 is usable. In that case, the smaller the number is, the more 33132 desirable it is to use it. 33133 33134 -- Target Hook: bool TARGET_GOACC_VALIDATE_DIMS (tree DECL, int *DIMS, 33135 int FN_LEVEL) 33136 This hook should check the launch dimensions provided for an 33137 OpenACC compute region, or routine. Defaulted values are 33138 represented as -1 and non-constant values as 0. The FN_LEVEL is 33139 negative for the function corresponding to the compute region. For 33140 a routine is is the outermost level at which partitioned execution 33141 may be spawned. The hook should verify non-default values. If 33142 DECL is NULL, global defaults are being validated and unspecified 33143 defaults should be filled in. Diagnostics should be issued as 33144 appropriate. Return true, if changes have been made. You must 33145 override this hook to provide dimensions larger than 1. 33146 33147 -- Target Hook: int TARGET_GOACC_DIM_LIMIT (int AXIS) 33148 This hook should return the maximum size of a particular dimension, 33149 or zero if unbounded. 33150 33151 -- Target Hook: bool TARGET_GOACC_FORK_JOIN (gcall *CALL, const int 33152 *DIMS, bool IS_FORK) 33153 This hook can be used to convert IFN_GOACC_FORK and IFN_GOACC_JOIN 33154 function calls to target-specific gimple, or indicate whether they 33155 should be retained. It is executed during the oacc_device_lower 33156 pass. It should return true, if the call should be retained. It 33157 should return false, if it is to be deleted (either because 33158 target-specific gimple has been inserted before it, or there is no 33159 need for it). The default hook returns false, if there are no RTL 33160 expanders for them. 33161 33162 -- Target Hook: void TARGET_GOACC_REDUCTION (gcall *CALL) 33163 This hook is used by the oacc_transform pass to expand calls to the 33164 GOACC_REDUCTION internal function, into a sequence of gimple 33165 instructions. CALL is gimple statement containing the call to the 33166 function. This hook removes statement CALL after the expanded 33167 sequence has been inserted. This hook is also responsible for 33168 allocating any storage for reductions when necessary. 33169 33170 33171File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 33172 3317317.14 Anchored Addresses 33174======================== 33175 33176GCC usually addresses every static object as a separate entity. For 33177example, if we have: 33178 33179 static int a, b, c; 33180 int foo (void) { return a + b + c; } 33181 33182 the code for 'foo' will usually calculate three separate symbolic 33183addresses: those of 'a', 'b' and 'c'. On some targets, it would be 33184better to calculate just one symbolic address and access the three 33185variables relative to it. The equivalent pseudocode would be something 33186like: 33187 33188 int foo (void) 33189 { 33190 register int *xr = &x; 33191 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 33192 } 33193 33194 (which isn't valid C). We refer to shared addresses like 'x' as 33195"section anchors". Their use is controlled by '-fsection-anchors'. 33196 33197 The hooks below describe the target properties that GCC needs to know 33198in order to make effective use of section anchors. It won't use section 33199anchors at all unless either 'TARGET_MIN_ANCHOR_OFFSET' or 33200'TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 33201 33202 -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 33203 The minimum offset that should be applied to a section anchor. On 33204 most targets, it should be the smallest offset that can be applied 33205 to a base register while still giving a legitimate address for 33206 every mode. The default value is 0. 33207 33208 -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 33209 Like 'TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) offset 33210 that should be applied to section anchors. The default value is 0. 33211 33212 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 33213 Write the assembly code to define section anchor X, which is a 33214 'SYMBOL_REF' for which 'SYMBOL_REF_ANCHOR_P (X)' is true. The hook 33215 is called with the assembly output position set to the beginning of 33216 'SYMBOL_REF_BLOCK (X)'. 33217 33218 If 'ASM_OUTPUT_DEF' is available, the hook's default definition 33219 uses it to define the symbol as '. + SYMBOL_REF_BLOCK_OFFSET (X)'. 33220 If 'ASM_OUTPUT_DEF' is not available, the hook's default definition 33221 is 'NULL', which disables the use of section anchors altogether. 33222 33223 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X) 33224 Return true if GCC should attempt to use anchors to access 33225 'SYMBOL_REF' X. You can assume 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 33226 and '!SYMBOL_REF_ANCHOR_P (X)'. 33227 33228 The default version is correct for most targets, but you might need 33229 to intercept this hook to handle things like target-specific 33230 attributes or target-specific sections. 33231 33232 33233File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 33234 3323517.15 Condition Code Status 33236=========================== 33237 33238The macros in this section can be split in two families, according to 33239the two ways of representing condition codes in GCC. 33240 33241 The first representation is the so called '(cc0)' representation (*note 33242Jump Patterns::), where all instructions can have an implicit clobber of 33243the condition codes. The second is the condition code register 33244representation, which provides better schedulability for architectures 33245that do have a condition code register, but on which most instructions 33246do not affect it. The latter category includes most RISC machines. 33247 33248 The implicit clobbering poses a strong restriction on the placement of 33249the definition and use of the condition code. In the past the 33250definition and use were always adjacent. However, recent changes to 33251support trapping arithmatic may result in the definition and user being 33252in different blocks. Thus, there may be a 'NOTE_INSN_BASIC_BLOCK' 33253between them. Additionally, the definition may be the source of 33254exception handling edges. 33255 33256 These restrictions can prevent important optimizations on some 33257machines. For example, on the IBM RS/6000, there is a delay for taken 33258branches unless the condition code register is set three instructions 33259earlier than the conditional branch. The instruction scheduler cannot 33260perform this optimization if it is not permitted to separate the 33261definition and use of the condition code register. 33262 33263 For this reason, it is possible and suggested to use a register to 33264represent the condition code for new ports. If there is a specific 33265condition code register in the machine, use a hard register. If the 33266condition code or comparison result can be placed in any general 33267register, or if there are multiple condition registers, use a pseudo 33268register. Registers used to store the condition code value will usually 33269have a mode that is in class 'MODE_CC'. 33270 33271 Alternatively, you can use 'BImode' if the comparison operator is 33272specified already in the compare instruction. In this case, you are not 33273interested in most macros in this section. 33274 33275* Menu: 33276 33277* CC0 Condition Codes:: Old style representation of condition codes. 33278* MODE_CC Condition Codes:: Modern representation of condition codes. 33279 33280 33281File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code 33282 3328317.15.1 Representation of condition codes using '(cc0)' 33284------------------------------------------------------- 33285 33286The file 'conditions.h' defines a variable 'cc_status' to describe how 33287the condition code was computed (in case the interpretation of the 33288condition code depends on the instruction that it was set by). This 33289variable contains the RTL expressions on which the condition code is 33290currently based, and several standard flags. 33291 33292 Sometimes additional machine-specific flags must be defined in the 33293machine description header file. It can also add additional 33294machine-specific information by defining 'CC_STATUS_MDEP'. 33295 33296 -- Macro: CC_STATUS_MDEP 33297 C code for a data type which is used for declaring the 'mdep' 33298 component of 'cc_status'. It defaults to 'int'. 33299 33300 This macro is not used on machines that do not use 'cc0'. 33301 33302 -- Macro: CC_STATUS_MDEP_INIT 33303 A C expression to initialize the 'mdep' field to "empty". The 33304 default definition does nothing, since most machines don't use the 33305 field anyway. If you want to use the field, you should probably 33306 define this macro to initialize it. 33307 33308 This macro is not used on machines that do not use 'cc0'. 33309 33310 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 33311 A C compound statement to set the components of 'cc_status' 33312 appropriately for an insn INSN whose body is EXP. It is this 33313 macro's responsibility to recognize insns that set the condition 33314 code as a byproduct of other activity as well as those that 33315 explicitly set '(cc0)'. 33316 33317 This macro is not used on machines that do not use 'cc0'. 33318 33319 If there are insns that do not set the condition code but do alter 33320 other machine registers, this macro must check to see whether they 33321 invalidate the expressions that the condition code is recorded as 33322 reflecting. For example, on the 68000, insns that store in address 33323 registers do not set the condition code, which means that usually 33324 'NOTICE_UPDATE_CC' can leave 'cc_status' unaltered for such insns. 33325 But suppose that the previous insn set the condition code based on 33326 location 'a4@(102)' and the current insn stores a new value in 33327 'a4'. Although the condition code is not changed by this, it will 33328 no longer be true that it reflects the contents of 'a4@(102)'. 33329 Therefore, 'NOTICE_UPDATE_CC' must alter 'cc_status' in this case 33330 to say that nothing is known about the condition code value. 33331 33332 The definition of 'NOTICE_UPDATE_CC' must be prepared to deal with 33333 the results of peephole optimization: insns whose patterns are 33334 'parallel' RTXs containing various 'reg', 'mem' or constants which 33335 are just the operands. The RTL structure of these insns is not 33336 sufficient to indicate what the insns actually do. What 33337 'NOTICE_UPDATE_CC' should do when it sees one is just to run 33338 'CC_STATUS_INIT'. 33339 33340 A possible definition of 'NOTICE_UPDATE_CC' is to call a function 33341 that looks at an attribute (*note Insn Attributes::) named, for 33342 example, 'cc'. This avoids having detailed information about 33343 patterns in two places, the 'md' file and in 'NOTICE_UPDATE_CC'. 33344 33345 33346File: gccint.info, Node: MODE_CC Condition Codes, Prev: CC0 Condition Codes, Up: Condition Code 33347 3334817.15.2 Representation of condition codes using registers 33349--------------------------------------------------------- 33350 33351 -- Macro: SELECT_CC_MODE (OP, X, Y) 33352 On many machines, the condition code may be produced by other 33353 instructions than compares, for example the branch can use directly 33354 the condition code set by a subtract instruction. However, on some 33355 machines when the condition code is set this way some bits (such as 33356 the overflow bit) are not set in the same way as a test 33357 instruction, so that a different branch instruction must be used 33358 for some conditional branches. When this happens, use the machine 33359 mode of the condition code register to record different formats of 33360 the condition code register. Modes can also be used to record 33361 which compare instruction (e.g. a signed or an unsigned 33362 comparison) produced the condition codes. 33363 33364 If other modes than 'CCmode' are required, add them to 33365 'MACHINE-modes.def' and define 'SELECT_CC_MODE' to choose a mode 33366 given an operand of a compare. This is needed because the modes 33367 have to be chosen not only during RTL generation but also, for 33368 example, by instruction combination. The result of 33369 'SELECT_CC_MODE' should be consistent with the mode used in the 33370 patterns; for example to support the case of the add on the SPARC 33371 discussed above, we have the pattern 33372 33373 (define_insn "" 33374 [(set (reg:CC_NOOV 0) 33375 (compare:CC_NOOV 33376 (plus:SI (match_operand:SI 0 "register_operand" "%r") 33377 (match_operand:SI 1 "arith_operand" "rI")) 33378 (const_int 0)))] 33379 "" 33380 "...") 33381 33382 together with a 'SELECT_CC_MODE' that returns 'CC_NOOVmode' for 33383 comparisons whose argument is a 'plus': 33384 33385 #define SELECT_CC_MODE(OP,X,Y) \ 33386 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 33387 ? ((OP == LT || OP == LE || OP == GT || OP == GE) \ 33388 ? CCFPEmode : CCFPmode) \ 33389 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 33390 || GET_CODE (X) == NEG || GET_CODE (x) == ASHIFT) \ 33391 ? CC_NOOVmode : CCmode)) 33392 33393 Another reason to use modes is to retain information on which 33394 operands were used by the comparison; see 'REVERSIBLE_CC_MODE' 33395 later in this section. 33396 33397 You should define this macro if and only if you define extra CC 33398 modes in 'MACHINE-modes.def'. 33399 33400 -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx 33401 *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE) 33402 On some machines not all possible comparisons are defined, but you 33403 can convert an invalid comparison into a valid one. For example, 33404 the Alpha does not have a 'GT' comparison, but you can use an 'LT' 33405 comparison instead and swap the order of the operands. 33406 33407 On such machines, implement this hook to do any required 33408 conversions. CODE is the initial comparison code and OP0 and OP1 33409 are the left and right operands of the comparison, respectively. 33410 If OP0_PRESERVE_VALUE is 'true' the implementation is not allowed 33411 to change the value of OP0 since the value might be used in RTXs 33412 which aren't comparisons. E.g. the implementation is not allowed 33413 to swap operands in that case. 33414 33415 GCC will not assume that the comparison resulting from this macro 33416 is valid but will see if the resulting insn matches a pattern in 33417 the 'md' file. 33418 33419 You need not to implement this hook if it would never change the 33420 comparison code or operands. 33421 33422 -- Macro: REVERSIBLE_CC_MODE (MODE) 33423 A C expression whose value is one if it is always safe to reverse a 33424 comparison whose mode is MODE. If 'SELECT_CC_MODE' can ever return 33425 MODE for a floating-point inequality comparison, then 33426 'REVERSIBLE_CC_MODE (MODE)' must be zero. 33427 33428 You need not define this macro if it would always returns zero or 33429 if the floating-point format is anything other than 33430 'IEEE_FLOAT_FORMAT'. For example, here is the definition used on 33431 the SPARC, where floating-point inequality comparisons are given 33432 either 'CCFPEmode' or 'CCFPmode': 33433 33434 #define REVERSIBLE_CC_MODE(MODE) \ 33435 ((MODE) != CCFPEmode && (MODE) != CCFPmode) 33436 33437 -- Macro: REVERSE_CONDITION (CODE, MODE) 33438 A C expression whose value is reversed condition code of the CODE 33439 for comparison done in CC_MODE MODE. The macro is used only in 33440 case 'REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 33441 case machine has some non-standard way how to reverse certain 33442 conditionals. For instance in case all floating point conditions 33443 are non-trapping, compiler may freely convert unordered compares to 33444 ordered ones. Then definition may look like: 33445 33446 #define REVERSE_CONDITION(CODE, MODE) \ 33447 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 33448 : reverse_condition_maybe_unordered (CODE)) 33449 33450 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int 33451 *P1, unsigned int *P2) 33452 On targets which do not use '(cc0)', and which use a hard register 33453 rather than a pseudo-register to hold condition codes, the regular 33454 CSE passes are often not able to identify cases in which the hard 33455 register is set to a common value. Use this hook to enable a small 33456 pass which optimizes such cases. This hook should return true to 33457 enable this pass, and it should set the integers to which its 33458 arguments point to the hard register numbers used for condition 33459 codes. When there is only one such register, as is true on most 33460 systems, the integer pointed to by P2 should be set to 33461 'INVALID_REGNUM'. 33462 33463 The default version of this hook returns false. 33464 33465 -- Target Hook: machine_mode TARGET_CC_MODES_COMPATIBLE (machine_mode 33466 M1, machine_mode M2) 33467 On targets which use multiple condition code modes in class 33468 'MODE_CC', it is sometimes the case that a comparison can be 33469 validly done in more than one mode. On such a system, define this 33470 target hook to take two mode arguments and to return a mode in 33471 which both comparisons may be validly done. If there is no such 33472 mode, return 'VOIDmode'. 33473 33474 The default version of this hook checks whether the modes are the 33475 same. If they are, it returns that mode. If they are different, 33476 it returns 'VOIDmode'. 33477 33478 -- Target Hook: unsigned int TARGET_FLAGS_REGNUM 33479 If the target has a dedicated flags register, and it needs to use 33480 the post-reload comparison elimination pass, then this value should 33481 be set appropriately. 33482 33483 33484File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 33485 3348617.16 Describing Relative Costs of Operations 33487============================================= 33488 33489These macros let you describe the relative speed of various operations 33490on the target machine. 33491 33492 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 33493 A C expression for the cost of moving data of mode MODE from a 33494 register in class FROM to one in class TO. The classes are 33495 expressed using the enumeration values such as 'GENERAL_REGS'. A 33496 value of 2 is the default; other values are interpreted relative to 33497 that. 33498 33499 It is not required that the cost always equal 2 when FROM is the 33500 same as TO; on some machines it is expensive to move between 33501 registers if they are not general registers. 33502 33503 If reload sees an insn consisting of a single 'set' between two 33504 hard registers, and if 'REGISTER_MOVE_COST' applied to their 33505 classes returns a value of 2, reload does not check to ensure that 33506 the constraints of the insn are met. Setting a cost of other than 33507 2 will allow reload to verify that the constraints are met. You 33508 should do this if the 'movM' pattern's constraints do not allow 33509 such copying. 33510 33511 These macros are obsolete, new ports should use the target hook 33512 'TARGET_REGISTER_MOVE_COST' instead. 33513 33514 -- Target Hook: int TARGET_REGISTER_MOVE_COST (machine_mode MODE, 33515 reg_class_t FROM, reg_class_t TO) 33516 This target hook should return the cost of moving data of mode MODE 33517 from a register in class FROM to one in class TO. The classes are 33518 expressed using the enumeration values such as 'GENERAL_REGS'. A 33519 value of 2 is the default; other values are interpreted relative to 33520 that. 33521 33522 It is not required that the cost always equal 2 when FROM is the 33523 same as TO; on some machines it is expensive to move between 33524 registers if they are not general registers. 33525 33526 If reload sees an insn consisting of a single 'set' between two 33527 hard registers, and if 'TARGET_REGISTER_MOVE_COST' applied to their 33528 classes returns a value of 2, reload does not check to ensure that 33529 the constraints of the insn are met. Setting a cost of other than 33530 2 will allow reload to verify that the constraints are met. You 33531 should do this if the 'movM' pattern's constraints do not allow 33532 such copying. 33533 33534 The default version of this function returns 2. 33535 33536 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 33537 A C expression for the cost of moving data of mode MODE between a 33538 register of class CLASS and memory; IN is zero if the value is to 33539 be written to memory, nonzero if it is to be read in. This cost is 33540 relative to those in 'REGISTER_MOVE_COST'. If moving between 33541 registers and memory is more expensive than between two registers, 33542 you should define this macro to express the relative cost. 33543 33544 If you do not define this macro, GCC uses a default cost of 4 plus 33545 the cost of copying via a secondary reload register, if one is 33546 needed. If your machine requires a secondary reload register to 33547 copy between memory and a register of CLASS but the reload 33548 mechanism is more complex than copying via an intermediate, define 33549 this macro to reflect the actual cost of the move. 33550 33551 GCC defines the function 'memory_move_secondary_cost' if secondary 33552 reloads are needed. It computes the costs due to copying via a 33553 secondary register. If your machine copies from memory using a 33554 secondary register in the conventional way but the default base 33555 value of 4 is not correct for your machine, define this macro to 33556 add some other value to the result of that function. The arguments 33557 to that function are the same as to this macro. 33558 33559 These macros are obsolete, new ports should use the target hook 33560 'TARGET_MEMORY_MOVE_COST' instead. 33561 33562 -- Target Hook: int TARGET_MEMORY_MOVE_COST (machine_mode MODE, 33563 reg_class_t RCLASS, bool IN) 33564 This target hook should return the cost of moving data of mode MODE 33565 between a register of class RCLASS and memory; IN is 'false' if the 33566 value is to be written to memory, 'true' if it is to be read in. 33567 This cost is relative to those in 'TARGET_REGISTER_MOVE_COST'. If 33568 moving between registers and memory is more expensive than between 33569 two registers, you should add this target hook to express the 33570 relative cost. 33571 33572 If you do not add this target hook, GCC uses a default cost of 4 33573 plus the cost of copying via a secondary reload register, if one is 33574 needed. If your machine requires a secondary reload register to 33575 copy between memory and a register of RCLASS but the reload 33576 mechanism is more complex than copying via an intermediate, use 33577 this target hook to reflect the actual cost of the move. 33578 33579 GCC defines the function 'memory_move_secondary_cost' if secondary 33580 reloads are needed. It computes the costs due to copying via a 33581 secondary register. If your machine copies from memory using a 33582 secondary register in the conventional way but the default base 33583 value of 4 is not correct for your machine, use this target hook to 33584 add some other value to the result of that function. The arguments 33585 to that function are the same as to this target hook. 33586 33587 -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P) 33588 A C expression for the cost of a branch instruction. A value of 1 33589 is the default; other values are interpreted relative to that. 33590 Parameter SPEED_P is true when the branch in question should be 33591 optimized for speed. When it is false, 'BRANCH_COST' should return 33592 a value optimal for code size rather than performance. 33593 PREDICTABLE_P is true for well-predicted branches. On many 33594 architectures the 'BRANCH_COST' can be reduced then. 33595 33596 Here are additional macros which do not specify precise relative costs, 33597but only that certain actions are more expensive than GCC would 33598ordinarily expect. 33599 33600 -- Macro: SLOW_BYTE_ACCESS 33601 Define this macro as a C expression which is nonzero if accessing 33602 less than a word of memory (i.e. a 'char' or a 'short') is no 33603 faster than accessing a word of memory, i.e., if such access 33604 require more than one instruction or if there is no difference in 33605 cost between byte and (aligned) word loads. 33606 33607 When this macro is not defined, the compiler will access a field by 33608 finding the smallest containing object; when it is defined, a 33609 fullword load will be used if alignment permits. Unless bytes 33610 accesses are faster than word accesses, using word accesses is 33611 preferable since it may eliminate subsequent memory access if 33612 subsequent accesses occur to other fields in the same word of the 33613 structure, but to different bytes. 33614 33615 -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT) 33616 Define this macro to be the value 1 if memory accesses described by 33617 the MODE and ALIGNMENT parameters have a cost many times greater 33618 than aligned accesses, for example if they are emulated in a trap 33619 handler. 33620 33621 When this macro is nonzero, the compiler will act as if 33622 'STRICT_ALIGNMENT' were nonzero when generating code for block 33623 moves. This can cause significantly more instructions to be 33624 produced. Therefore, do not set this macro nonzero if unaligned 33625 accesses only add a cycle or two to the time for a memory access. 33626 33627 If the value of this macro is always zero, it need not be defined. 33628 If this macro is defined, it should produce a nonzero value when 33629 'STRICT_ALIGNMENT' is nonzero. 33630 33631 -- Macro: MOVE_RATIO (SPEED) 33632 The threshold of number of scalar memory-to-memory move insns, 33633 _below_ which a sequence of insns should be generated instead of a 33634 string move insn or a library call. Increasing the value will 33635 always make code faster, but eventually incurs high cost in 33636 increased code size. 33637 33638 Note that on machines where the corresponding move insn is a 33639 'define_expand' that emits a sequence of insns, this macro counts 33640 the number of such sequences. 33641 33642 The parameter SPEED is true if the code is currently being 33643 optimized for speed rather than size. 33644 33645 If you don't define this, a reasonable default is used. 33646 33647 -- Target Hook: bool TARGET_USE_BY_PIECES_INFRASTRUCTURE_P (unsigned 33648 HOST_WIDE_INT SIZE, unsigned int ALIGNMENT, enum 33649 by_pieces_operation OP, bool SPEED_P) 33650 GCC will attempt several strategies when asked to copy between two 33651 areas of memory, or to set, clear or store to memory, for example 33652 when copying a 'struct'. The 'by_pieces' infrastructure implements 33653 such memory operations as a sequence of load, store or move insns. 33654 Alternate strategies are to expand the 'movmem' or 'setmem' optabs, 33655 to emit a library call, or to emit unit-by-unit, loop-based 33656 operations. 33657 33658 This target hook should return true if, for a memory operation with 33659 a given SIZE and ALIGNMENT, using the 'by_pieces' infrastructure is 33660 expected to result in better code generation. Both SIZE and 33661 ALIGNMENT are measured in terms of storage units. 33662 33663 The parameter OP is one of: 'CLEAR_BY_PIECES', 'MOVE_BY_PIECES', 33664 'SET_BY_PIECES', 'STORE_BY_PIECES'. These describe the type of 33665 memory operation under consideration. 33666 33667 The parameter SPEED_P is true if the code is currently being 33668 optimized for speed rather than size. 33669 33670 Returning true for higher values of SIZE can improve code 33671 generation for speed if the target does not provide an 33672 implementation of the 'movmem' or 'setmem' standard names, if the 33673 'movmem' or 'setmem' implementation would be more expensive than a 33674 sequence of insns, or if the overhead of a library call would 33675 dominate that of the body of the memory operation. 33676 33677 Returning true for higher values of 'size' may also cause an 33678 increase in code size, for example where the number of insns 33679 emitted to perform a move would be greater than that of a library 33680 call. 33681 33682 -- Macro: MOVE_MAX_PIECES 33683 A C expression used by 'move_by_pieces' to determine the largest 33684 unit a load or store used to copy memory is. Defaults to 33685 'MOVE_MAX'. 33686 33687 -- Macro: CLEAR_RATIO (SPEED) 33688 The threshold of number of scalar move insns, _below_ which a 33689 sequence of insns should be generated to clear memory instead of a 33690 string clear insn or a library call. Increasing the value will 33691 always make code faster, but eventually incurs high cost in 33692 increased code size. 33693 33694 The parameter SPEED is true if the code is currently being 33695 optimized for speed rather than size. 33696 33697 If you don't define this, a reasonable default is used. 33698 33699 -- Macro: SET_RATIO (SPEED) 33700 The threshold of number of scalar move insns, _below_ which a 33701 sequence of insns should be generated to set memory to a constant 33702 value, instead of a block set insn or a library call. Increasing 33703 the value will always make code faster, but eventually incurs high 33704 cost in increased code size. 33705 33706 The parameter SPEED is true if the code is currently being 33707 optimized for speed rather than size. 33708 33709 If you don't define this, it defaults to the value of 'MOVE_RATIO'. 33710 33711 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 33712 A C expression used to determine whether a load postincrement is a 33713 good thing to use for a given mode. Defaults to the value of 33714 'HAVE_POST_INCREMENT'. 33715 33716 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 33717 A C expression used to determine whether a load postdecrement is a 33718 good thing to use for a given mode. Defaults to the value of 33719 'HAVE_POST_DECREMENT'. 33720 33721 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 33722 A C expression used to determine whether a load preincrement is a 33723 good thing to use for a given mode. Defaults to the value of 33724 'HAVE_PRE_INCREMENT'. 33725 33726 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 33727 A C expression used to determine whether a load predecrement is a 33728 good thing to use for a given mode. Defaults to the value of 33729 'HAVE_PRE_DECREMENT'. 33730 33731 -- Macro: USE_STORE_POST_INCREMENT (MODE) 33732 A C expression used to determine whether a store postincrement is a 33733 good thing to use for a given mode. Defaults to the value of 33734 'HAVE_POST_INCREMENT'. 33735 33736 -- Macro: USE_STORE_POST_DECREMENT (MODE) 33737 A C expression used to determine whether a store postdecrement is a 33738 good thing to use for a given mode. Defaults to the value of 33739 'HAVE_POST_DECREMENT'. 33740 33741 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 33742 This macro is used to determine whether a store preincrement is a 33743 good thing to use for a given mode. Defaults to the value of 33744 'HAVE_PRE_INCREMENT'. 33745 33746 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 33747 This macro is used to determine whether a store predecrement is a 33748 good thing to use for a given mode. Defaults to the value of 33749 'HAVE_PRE_DECREMENT'. 33750 33751 -- Macro: NO_FUNCTION_CSE 33752 Define this macro to be true if it is as good or better to call a 33753 constant function address than to call an address kept in a 33754 register. 33755 33756 -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT 33757 Define this macro if a non-short-circuit operation produced by 33758 'fold_range_test ()' is optimal. This macro defaults to true if 33759 'BRANCH_COST' is greater than or equal to the value 2. 33760 33761 -- Target Hook: bool TARGET_OPTAB_SUPPORTED_P (int OP, machine_mode 33762 MODE1, machine_mode MODE2, optimization_type OPT_TYPE) 33763 Return true if the optimizers should use optab OP with modes MODE1 33764 and MODE2 for optimization type OPT_TYPE. The optab is known to 33765 have an associated '.md' instruction whose C condition is true. 33766 MODE2 is only meaningful for conversion optabs; for direct optabs 33767 it is a copy of MODE1. 33768 33769 For example, when called with OP equal to 'rint_optab' and MODE1 33770 equal to 'DFmode', the hook should say whether the optimizers 33771 should use optab 'rintdf2'. 33772 33773 The default hook returns true for all inputs. 33774 33775 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, machine_mode MODE, int 33776 OUTER_CODE, int OPNO, int *TOTAL, bool SPEED) 33777 This target hook describes the relative costs of RTL expressions. 33778 33779 The cost may depend on the precise form of the expression, which is 33780 available for examination in X, and the fact that X appears as 33781 operand OPNO of an expression with rtx code OUTER_CODE. That is, 33782 the hook can assume that there is some rtx Y such that 'GET_CODE 33783 (Y) == OUTER_CODE' and such that either (a) 'XEXP (Y, OPNO) == X' 33784 or (b) 'XVEC (Y, OPNO)' contains X. 33785 33786 MODE is X's machine mode, or for cases like 'const_int' that do not 33787 have a mode, the mode in which X is used. 33788 33789 In implementing this hook, you can use the construct 'COSTS_N_INSNS 33790 (N)' to specify a cost equal to N fast instructions. 33791 33792 On entry to the hook, '*TOTAL' contains a default estimate for the 33793 cost of the expression. The hook should modify this value as 33794 necessary. Traditionally, the default costs are 'COSTS_N_INSNS 33795 (5)' for multiplications, 'COSTS_N_INSNS (7)' for division and 33796 modulus operations, and 'COSTS_N_INSNS (1)' for all other 33797 operations. 33798 33799 When optimizing for code size, i.e. when 'speed' is false, this 33800 target hook should be used to estimate the relative size cost of an 33801 expression, again relative to 'COSTS_N_INSNS'. 33802 33803 The hook returns true when all subexpressions of X have been 33804 processed, and false when 'rtx_cost' should recurse. 33805 33806 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, machine_mode 33807 MODE, addr_space_t AS, bool SPEED) 33808 This hook computes the cost of an addressing mode that contains 33809 ADDRESS. If not defined, the cost is computed from the ADDRESS 33810 expression and the 'TARGET_RTX_COST' hook. 33811 33812 For most CISC machines, the default cost is a good approximation of 33813 the true cost of the addressing mode. However, on RISC machines, 33814 all instructions normally have the same length and execution time. 33815 Hence all addresses will have equal costs. 33816 33817 In cases where more than one form of an address is known, the form 33818 with the lowest cost will be used. If multiple forms have the 33819 same, lowest, cost, the one that is the most complex will be used. 33820 33821 For example, suppose an address that is equal to the sum of a 33822 register and a constant is used twice in the same basic block. 33823 When this macro is not defined, the address will be computed in a 33824 register and memory references will be indirect through that 33825 register. On machines where the cost of the addressing mode 33826 containing the sum is no higher than that of a simple indirect 33827 reference, this will produce an additional instruction and possibly 33828 require an additional register. Proper specification of this macro 33829 eliminates this overhead for such machines. 33830 33831 This hook is never called with an invalid address. 33832 33833 On machines where an address involving more than one register is as 33834 cheap as an address computation involving only one register, 33835 defining 'TARGET_ADDRESS_COST' to reflect this can cause two 33836 registers to be live over a region of code where only one would 33837 have been if 'TARGET_ADDRESS_COST' were not defined in that manner. 33838 This effect should be considered in the definition of this macro. 33839 Equivalent costs should probably only be given to addresses with 33840 different numbers of registers on machines with lots of registers. 33841 33842 -- Target Hook: bool TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P (void) 33843 This predicate controls the use of the eager delay slot filler to 33844 disallow speculatively executed instructions being placed in delay 33845 slots. Targets such as certain MIPS architectures possess both 33846 branches with and without delay slots. As the eager delay slot 33847 filler can decrease performance, disabling it is beneficial when 33848 ordinary branches are available. Use of delay slot branches filled 33849 using the basic filler is often still desirable as the delay slot 33850 can hide a pipeline bubble. 33851 33852 33853File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 33854 3385517.17 Adjusting the Instruction Scheduler 33856========================================= 33857 33858The instruction scheduler may need a fair amount of machine-specific 33859adjustment in order to produce good code. GCC provides several target 33860hooks for this purpose. It is usually enough to define just a few of 33861them: try the first ones in this list first. 33862 33863 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 33864 This hook returns the maximum number of instructions that can ever 33865 issue at the same time on the target machine. The default is one. 33866 Although the insn scheduler can define itself the possibility of 33867 issue an insn on the same cycle, the value can serve as an 33868 additional constraint to issue insns on the same simulated 33869 processor cycle (see hooks 'TARGET_SCHED_REORDER' and 33870 'TARGET_SCHED_REORDER2'). This value must be constant over the 33871 entire compilation. If you need it to vary depending on what the 33872 instructions are, you must use 'TARGET_SCHED_VARIABLE_ISSUE'. 33873 33874 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 33875 VERBOSE, rtx_insn *INSN, int MORE) 33876 This hook is executed by the scheduler after it has scheduled an 33877 insn from the ready list. It should return the number of insns 33878 which can still be issued in the current cycle. The default is 33879 'MORE - 1' for insns other than 'CLOBBER' and 'USE', which normally 33880 are not counted against the issue rate. You should define this 33881 hook if some insns take more machine resources than others, so that 33882 fewer insns can follow them in the same cycle. FILE is either a 33883 null pointer, or a stdio stream to write any debug output to. 33884 VERBOSE is the verbose level provided by '-fsched-verbose-N'. INSN 33885 is the instruction that was scheduled. 33886 33887 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx_insn *INSN, rtx LINK, 33888 rtx_insn *DEP_INSN, int COST) 33889 This function corrects the value of COST based on the relationship 33890 between INSN and DEP_INSN through the dependence LINK. It should 33891 return the new value. The default is to make no adjustment to 33892 COST. This can be used for example to specify to the scheduler 33893 using the traditional pipeline description that an output- or 33894 anti-dependence does not incur the same cost as a data-dependence. 33895 If the scheduler using the automaton based pipeline description, 33896 the cost of anti-dependence is zero and the cost of 33897 output-dependence is maximum of one and the difference of latency 33898 times of the first and the second insns. If these values are not 33899 acceptable, you could use the hook to modify them too. See also 33900 *note Processor pipeline description::. 33901 33902 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx_insn *INSN, int 33903 PRIORITY) 33904 This hook adjusts the integer scheduling priority PRIORITY of INSN. 33905 It should return the new priority. Increase the priority to 33906 execute INSN earlier, reduce the priority to execute INSN later. 33907 Do not define this hook if you do not need to adjust the scheduling 33908 priorities of insns. 33909 33910 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, 33911 rtx_insn **READY, int *N_READYP, int CLOCK) 33912 This hook is executed by the scheduler after it has scheduled the 33913 ready list, to allow the machine description to reorder it (for 33914 example to combine two small instructions together on 'VLIW' 33915 machines). FILE is either a null pointer, or a stdio stream to 33916 write any debug output to. VERBOSE is the verbose level provided 33917 by '-fsched-verbose-N'. READY is a pointer to the ready list of 33918 instructions that are ready to be scheduled. N_READYP is a pointer 33919 to the number of elements in the ready list. The scheduler reads 33920 the ready list in reverse order, starting with READY[*N_READYP - 1] 33921 and going to READY[0]. CLOCK is the timer tick of the scheduler. 33922 You may modify the ready list and the number of ready insns. The 33923 return value is the number of insns that can issue this cycle; 33924 normally this is just 'issue_rate'. See also 33925 'TARGET_SCHED_REORDER2'. 33926 33927 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 33928 rtx_insn **READY, int *N_READYP, int CLOCK) 33929 Like 'TARGET_SCHED_REORDER', but called at a different time. That 33930 function is called whenever the scheduler starts a new cycle. This 33931 one is called once per iteration over a cycle, immediately after 33932 'TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list and 33933 return the number of insns to be scheduled in the same cycle. 33934 Defining this hook can be useful if there are frequent situations 33935 where scheduling one insn causes other insns to become ready in the 33936 same cycle. These other insns can then be taken into account 33937 properly. 33938 33939 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_P (void) 33940 This hook is used to check whether target platform supports macro 33941 fusion. 33942 33943 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_PAIR_P (rtx_insn *PREV, 33944 rtx_insn *CURR) 33945 This hook is used to check whether two insns should be macro fused 33946 for a target microarchitecture. If this hook returns true for the 33947 given insn pair (PREV and CURR), the scheduler will put them into a 33948 sched group, and they will not be scheduled apart. The two insns 33949 will be either two SET insns or a compare and a conditional jump 33950 and this hook should validate any dependencies needed to fuse the 33951 two insns together. 33952 33953 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK 33954 (rtx_insn *HEAD, rtx_insn *TAIL) 33955 This hook is called after evaluation forward dependencies of insns 33956 in chain given by two parameter values (HEAD and TAIL 33957 correspondingly) but before insns scheduling of the insn chain. 33958 For example, it can be used for better insn classification if it 33959 requires analysis of dependencies. This hook can use backward and 33960 forward dependencies of the insn scheduler because they are already 33961 calculated. 33962 33963 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 33964 MAX_READY) 33965 This hook is executed by the scheduler at the beginning of each 33966 block of instructions that are to be scheduled. FILE is either a 33967 null pointer, or a stdio stream to write any debug output to. 33968 VERBOSE is the verbose level provided by '-fsched-verbose-N'. 33969 MAX_READY is the maximum number of insns in the current scheduling 33970 region that can be live at the same time. This can be used to 33971 allocate scratch space if it is needed, e.g. by 33972 'TARGET_SCHED_REORDER'. 33973 33974 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 33975 This hook is executed by the scheduler at the end of each block of 33976 instructions that are to be scheduled. It can be used to perform 33977 cleanup of any actions done by the other scheduling hooks. FILE is 33978 either a null pointer, or a stdio stream to write any debug output 33979 to. VERBOSE is the verbose level provided by '-fsched-verbose-N'. 33980 33981 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int VERBOSE, 33982 int OLD_MAX_UID) 33983 This hook is executed by the scheduler after function level 33984 initializations. FILE is either a null pointer, or a stdio stream 33985 to write any debug output to. VERBOSE is the verbose level 33986 provided by '-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 33987 uid when scheduling begins. 33988 33989 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 33990 VERBOSE) 33991 This is the cleanup hook corresponding to 33992 'TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 33993 stdio stream to write any debug output to. VERBOSE is the verbose 33994 level provided by '-fsched-verbose-N'. 33995 33996 -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 33997 The hook returns an RTL insn. The automaton state used in the 33998 pipeline hazard recognizer is changed as if the insn were scheduled 33999 when the new simulated processor cycle starts. Usage of the hook 34000 may simplify the automaton pipeline description for some VLIW 34001 processors. If the hook is defined, it is used only for the 34002 automaton based pipeline description. The default is not to change 34003 the state when the new simulated processor cycle starts. 34004 34005 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 34006 The hook can be used to initialize data used by the previous hook. 34007 34008 -- Target Hook: rtx_insn * TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 34009 The hook is analogous to 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 34010 to changed the state as if the insn were scheduled when the new 34011 simulated processor cycle finishes. 34012 34013 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 34014 The hook is analogous to 'TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 34015 used to initialize data used by the previous hook. 34016 34017 -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void) 34018 The hook to notify target that the current simulated cycle is about 34019 to finish. The hook is analogous to 34020 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in 34021 more complicated situations - e.g., when advancing state on a 34022 single insn is not enough. 34023 34024 -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void) 34025 The hook to notify target that new simulated cycle has just 34026 started. The hook is analogous to 34027 'TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in 34028 more complicated situations - e.g., when advancing state on a 34029 single insn is not enough. 34030 34031 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 34032 (void) 34033 This hook controls better choosing an insn from the ready insn 34034 queue for the DFA-based insn scheduler. Usually the scheduler 34035 chooses the first insn from the queue. If the hook returns a 34036 positive value, an additional scheduler code tries all permutations 34037 of 'TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD ()' subsequent 34038 ready insns to choose an insn whose issue will result in maximal 34039 number of issued insns on the same cycle. For the VLIW processor, 34040 the code could actually solve the problem of packing simple insns 34041 into the VLIW insn. Of course, if the rules of VLIW packing are 34042 described in the automaton. 34043 34044 This code also could be used for superscalar RISC processors. Let 34045 us consider a superscalar RISC processor with 3 pipelines. Some 34046 insns can be executed in pipelines A or B, some insns can be 34047 executed only in pipelines B or C, and one insn can be executed in 34048 pipeline B. The processor may issue the 1st insn into A and the 34049 2nd one into B. In this case, the 3rd insn will wait for freeing B 34050 until the next cycle. If the scheduler issues the 3rd insn the 34051 first, the processor could issue all 3 insns per cycle. 34052 34053 Actually this code demonstrates advantages of the automaton based 34054 pipeline hazard recognizer. We try quickly and easy many insn 34055 schedules to choose the best one. 34056 34057 The default is no multipass scheduling. 34058 34059 -- Target Hook: int 34060 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD 34061 (rtx_insn *INSN, int READY_INDEX) 34062 34063 This hook controls what insns from the ready insn queue will be 34064 considered for the multipass insn scheduling. If the hook returns 34065 zero for INSN, the insn will be considered in multipass scheduling. 34066 Positive return values will remove INSN from consideration on the 34067 current round of multipass scheduling. Negative return values will 34068 remove INSN from consideration for given number of cycles. 34069 Backends should be careful about returning non-zero for highest 34070 priority instruction at position 0 in the ready list. READY_INDEX 34071 is passed to allow backends make correct judgements. 34072 34073 The default is that any ready insns can be chosen to be issued. 34074 34075 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void 34076 *DATA, signed char *READY_TRY, int N_READY, bool 34077 FIRST_CYCLE_INSN_P) 34078 This hook prepares the target backend for a new round of multipass 34079 scheduling. 34080 34081 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void 34082 *DATA, signed char *READY_TRY, int N_READY, rtx_insn *INSN, 34083 const void *PREV_DATA) 34084 This hook is called when multipass scheduling evaluates instruction 34085 INSN. 34086 34087 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK 34088 (const void *DATA, signed char *READY_TRY, int N_READY) 34089 This is called when multipass scheduling backtracks from evaluation 34090 of an instruction. 34091 34092 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const void 34093 *DATA) 34094 This hook notifies the target about the result of the concluded 34095 current round of multipass scheduling. 34096 34097 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void 34098 *DATA) 34099 This hook initializes target-specific data used in multipass 34100 scheduling. 34101 34102 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void 34103 *DATA) 34104 This hook finalizes target-specific data used in multipass 34105 scheduling. 34106 34107 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int 34108 VERBOSE, rtx_insn *INSN, int LAST_CLOCK, int CLOCK, int 34109 *SORT_P) 34110 This hook is called by the insn scheduler before issuing INSN on 34111 cycle CLOCK. If the hook returns nonzero, INSN is not issued on 34112 this processor cycle. Instead, the processor cycle is advanced. 34113 If *SORT_P is zero, the insn ready queue is not sorted on the new 34114 cycle start as usually. DUMP and VERBOSE specify the file and 34115 verbosity level to use for debugging output. LAST_CLOCK and CLOCK 34116 are, respectively, the processor cycle on which the previous insn 34117 has been issued, and the current processor cycle. 34118 34119 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep 34120 *_DEP, int COST, int DISTANCE) 34121 This hook is used to define which dependences are considered costly 34122 by the target, so costly that it is not advisable to schedule the 34123 insns that are involved in the dependence too close to one another. 34124 The parameters to this hook are as follows: The first parameter 34125 _DEP is the dependence being evaluated. The second parameter COST 34126 is the cost of the dependence as estimated by the scheduler, and 34127 the third parameter DISTANCE is the distance in cycles between the 34128 two insns. The hook returns 'true' if considering the distance 34129 between the two insns the dependence between them is considered 34130 costly by the target, and 'false' otherwise. 34131 34132 Defining this hook can be useful in multiple-issue out-of-order 34133 machines, where (a) it's practically hopeless to predict the actual 34134 data/resource delays, however: (b) there's a better chance to 34135 predict the actual grouping that will be formed, and (c) correctly 34136 emulating the grouping can be very important. In such targets one 34137 may want to allow issuing dependent insns closer to one 34138 another--i.e., closer than the dependence distance; however, not in 34139 cases of "costly dependences", which this hooks allows to define. 34140 34141 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 34142 This hook is called by the insn scheduler after emitting a new 34143 instruction to the instruction stream. The hook notifies a target 34144 backend to extend its per instruction data structures. 34145 34146 -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void) 34147 Return a pointer to a store large enough to hold target scheduling 34148 context. 34149 34150 -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool 34151 CLEAN_P) 34152 Initialize store pointed to by TC to hold target scheduling 34153 context. It CLEAN_P is true then initialize TC as if scheduler is 34154 at the beginning of the block. Otherwise, copy the current context 34155 into TC. 34156 34157 -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC) 34158 Copy target scheduling context pointed to by TC to the current 34159 context. 34160 34161 -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC) 34162 Deallocate internal data in target scheduling context pointed to by 34163 TC. 34164 34165 -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC) 34166 Deallocate a store for target scheduling context pointed to by TC. 34167 34168 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx_insn *INSN, 34169 unsigned int DEP_STATUS, rtx *NEW_PAT) 34170 This hook is called by the insn scheduler when INSN has only 34171 speculative dependencies and therefore can be scheduled 34172 speculatively. The hook is used to check if the pattern of INSN 34173 has a speculative version and, in case of successful check, to 34174 generate that speculative pattern. The hook should return 1, if 34175 the instruction has a speculative form, or -1, if it doesn't. 34176 REQUEST describes the type of requested speculation. If the return 34177 value equals 1 then NEW_PAT is assigned the generated speculative 34178 pattern. 34179 34180 -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (unsigned int 34181 DEP_STATUS) 34182 This hook is called by the insn scheduler during generation of 34183 recovery code for INSN. It should return 'true', if the 34184 corresponding check instruction should branch to recovery code, or 34185 'false' otherwise. 34186 34187 -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx_insn *INSN, 34188 rtx_insn *LABEL, unsigned int DS) 34189 This hook is called by the insn scheduler to generate a pattern for 34190 recovery check instruction. If MUTATE_P is zero, then INSN is a 34191 speculative instruction for which the check should be generated. 34192 LABEL is either a label of a basic block, where recovery code 34193 should be emitted, or a null pointer, when requested check doesn't 34194 branch to recovery code (a simple check). If MUTATE_P is nonzero, 34195 then a pattern for a branchy check corresponding to a simple check 34196 denoted by INSN should be generated. In this case LABEL can't be 34197 null. 34198 34199 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct spec_info_def 34200 *SPEC_INFO) 34201 This hook is used by the insn scheduler to find out what features 34202 should be enabled/used. The structure *SPEC_INFO should be filled 34203 in by the target. The structure describes speculation types that 34204 can be used in the scheduler. 34205 34206 -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G) 34207 This hook is called by the swing modulo scheduler to calculate a 34208 resource-based lower bound which is based on the resources 34209 available in the machine and the resources required by each 34210 instruction. The target backend can use G to calculate such bound. 34211 A very simple lower bound will be used in case this hook is not 34212 implemented: the total number of instructions divided by the issue 34213 rate. 34214 34215 -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx_insn *INSN, int X) 34216 This hook is called by Haifa Scheduler. It returns true if 34217 dispatch scheduling is supported in hardware and the condition 34218 specified in the parameter is true. 34219 34220 -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx_insn *INSN, int X) 34221 This hook is called by Haifa Scheduler. It performs the operation 34222 specified in its second parameter. 34223 34224 -- Target Hook: bool TARGET_SCHED_EXPOSED_PIPELINE 34225 True if the processor has an exposed pipeline, which means that not 34226 just the order of instructions is important for correctness when 34227 scheduling, but also the latencies of operations. 34228 34229 -- Target Hook: int TARGET_SCHED_REASSOCIATION_WIDTH (unsigned int OPC, 34230 machine_mode MODE) 34231 This hook is called by tree reassociator to determine a level of 34232 parallelism required in output calculations chain. 34233 34234 -- Target Hook: void TARGET_SCHED_FUSION_PRIORITY (rtx_insn *INSN, int 34235 MAX_PRI, int *FUSION_PRI, int *PRI) 34236 This hook is called by scheduling fusion pass. It calculates 34237 fusion priorities for each instruction passed in by parameter. The 34238 priorities are returned via pointer parameters. 34239 34240 INSN is the instruction whose priorities need to be calculated. 34241 MAX_PRI is the maximum priority can be returned in any cases. 34242 FUSION_PRI is the pointer parameter through which INSN's fusion 34243 priority should be calculated and returned. PRI is the pointer 34244 parameter through which INSN's priority should be calculated and 34245 returned. 34246 34247 Same FUSION_PRI should be returned for instructions which should be 34248 scheduled together. Different PRI should be returned for 34249 instructions with same FUSION_PRI. FUSION_PRI is the major sort 34250 key, PRI is the minor sort key. All instructions will be scheduled 34251 according to the two priorities. All priorities calculated should 34252 be between 0 (exclusive) and MAX_PRI (inclusive). To avoid false 34253 dependencies, FUSION_PRI of instructions which need to be scheduled 34254 together should be smaller than FUSION_PRI of irrelevant 34255 instructions. 34256 34257 Given below example: 34258 34259 ldr r10, [r1, 4] 34260 add r4, r4, r10 34261 ldr r15, [r2, 8] 34262 sub r5, r5, r15 34263 ldr r11, [r1, 0] 34264 add r4, r4, r11 34265 ldr r16, [r2, 12] 34266 sub r5, r5, r16 34267 34268 On targets like ARM/AArch64, the two pairs of consecutive loads 34269 should be merged. Since peephole2 pass can't help in this case 34270 unless consecutive loads are actually next to each other in 34271 instruction flow. That's where this scheduling fusion pass works. 34272 This hook calculates priority for each instruction based on its 34273 fustion type, like: 34274 34275 ldr r10, [r1, 4] ; fusion_pri=99, pri=96 34276 add r4, r4, r10 ; fusion_pri=100, pri=100 34277 ldr r15, [r2, 8] ; fusion_pri=98, pri=92 34278 sub r5, r5, r15 ; fusion_pri=100, pri=100 34279 ldr r11, [r1, 0] ; fusion_pri=99, pri=100 34280 add r4, r4, r11 ; fusion_pri=100, pri=100 34281 ldr r16, [r2, 12] ; fusion_pri=98, pri=88 34282 sub r5, r5, r16 ; fusion_pri=100, pri=100 34283 34284 Scheduling fusion pass then sorts all ready to issue instructions 34285 according to the priorities. As a result, instructions of same 34286 fusion type will be pushed together in instruction flow, like: 34287 34288 ldr r11, [r1, 0] 34289 ldr r10, [r1, 4] 34290 ldr r15, [r2, 8] 34291 ldr r16, [r2, 12] 34292 add r4, r4, r10 34293 sub r5, r5, r15 34294 add r4, r4, r11 34295 sub r5, r5, r16 34296 34297 Now peephole2 pass can simply merge the two pairs of loads. 34298 34299 Since scheduling fusion pass relies on peephole2 to do real fusion 34300 work, it is only enabled by default when peephole2 is in effect. 34301 34302 This is firstly introduced on ARM/AArch64 targets, please refer to 34303 the hook implementation for how different fusion types are 34304 supported. 34305 34306 34307File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 34308 3430917.18 Dividing the Output into Sections (Texts, Data, ...) 34310========================================================== 34311 34312An object file is divided into sections containing different types of 34313data. In the most common case, there are three sections: the "text 34314section", which holds instructions and read-only data; the "data 34315section", which holds initialized writable data; and the "bss section", 34316which holds uninitialized data. Some systems have other kinds of 34317sections. 34318 34319 'varasm.c' provides several well-known sections, such as 34320'text_section', 'data_section' and 'bss_section'. The normal way of 34321controlling a 'FOO_section' variable is to define the associated 34322'FOO_SECTION_ASM_OP' macro, as described below. The macros are only 34323read once, when 'varasm.c' initializes itself, so their values must be 34324run-time constants. They may however depend on command-line flags. 34325 34326 _Note:_ Some run-time files, such 'crtstuff.c', also make use of the 34327'FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 34328 34329 Some assemblers require a different string to be written every time a 34330section is selected. If your assembler falls into this category, you 34331should define the 'TARGET_ASM_INIT_SECTIONS' hook and use 34332'get_unnamed_section' to set up the sections. 34333 34334 You must always create a 'text_section', either by defining 34335'TEXT_SECTION_ASM_OP' or by initializing 'text_section' in 34336'TARGET_ASM_INIT_SECTIONS'. The same is true of 'data_section' and 34337'DATA_SECTION_ASM_OP'. If you do not create a distinct 34338'readonly_data_section', the default is to reuse 'text_section'. 34339 34340 All the other 'varasm.c' sections are optional, and are null if the 34341target does not provide them. 34342 34343 -- Macro: TEXT_SECTION_ASM_OP 34344 A C expression whose value is a string, including spacing, 34345 containing the assembler operation that should precede instructions 34346 and read-only data. Normally '"\t.text"' is right. 34347 34348 -- Macro: HOT_TEXT_SECTION_NAME 34349 If defined, a C string constant for the name of the section 34350 containing most frequently executed functions of the program. If 34351 not defined, GCC will provide a default definition if the target 34352 supports named sections. 34353 34354 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 34355 If defined, a C string constant for the name of the section 34356 containing unlikely executed functions in the program. 34357 34358 -- Macro: DATA_SECTION_ASM_OP 34359 A C expression whose value is a string, including spacing, 34360 containing the assembler operation to identify the following data 34361 as writable initialized data. Normally '"\t.data"' is right. 34362 34363 -- Macro: SDATA_SECTION_ASM_OP 34364 If defined, a C expression whose value is a string, including 34365 spacing, containing the assembler operation to identify the 34366 following data as initialized, writable small data. 34367 34368 -- Macro: READONLY_DATA_SECTION_ASM_OP 34369 A C expression whose value is a string, including spacing, 34370 containing the assembler operation to identify the following data 34371 as read-only initialized data. 34372 34373 -- Macro: BSS_SECTION_ASM_OP 34374 If defined, a C expression whose value is a string, including 34375 spacing, containing the assembler operation to identify the 34376 following data as uninitialized global data. If not defined, and 34377 'ASM_OUTPUT_ALIGNED_BSS' not defined, uninitialized global data 34378 will be output in the data section if '-fno-common' is passed, 34379 otherwise 'ASM_OUTPUT_COMMON' will be used. 34380 34381 -- Macro: SBSS_SECTION_ASM_OP 34382 If defined, a C expression whose value is a string, including 34383 spacing, containing the assembler operation to identify the 34384 following data as uninitialized, writable small data. 34385 34386 -- Macro: TLS_COMMON_ASM_OP 34387 If defined, a C expression whose value is a string containing the 34388 assembler operation to identify the following data as thread-local 34389 common data. The default is '".tls_common"'. 34390 34391 -- Macro: TLS_SECTION_ASM_FLAG 34392 If defined, a C expression whose value is a character constant 34393 containing the flag used to mark a section as a TLS section. The 34394 default is ''T''. 34395 34396 -- Macro: INIT_SECTION_ASM_OP 34397 If defined, a C expression whose value is a string, including 34398 spacing, containing the assembler operation to identify the 34399 following data as initialization code. If not defined, GCC will 34400 assume such a section does not exist. This section has no 34401 corresponding 'init_section' variable; it is used entirely in 34402 runtime code. 34403 34404 -- Macro: FINI_SECTION_ASM_OP 34405 If defined, a C expression whose value is a string, including 34406 spacing, containing the assembler operation to identify the 34407 following data as finalization code. If not defined, GCC will 34408 assume such a section does not exist. This section has no 34409 corresponding 'fini_section' variable; it is used entirely in 34410 runtime code. 34411 34412 -- Macro: INIT_ARRAY_SECTION_ASM_OP 34413 If defined, a C expression whose value is a string, including 34414 spacing, containing the assembler operation to identify the 34415 following data as part of the '.init_array' (or equivalent) 34416 section. If not defined, GCC will assume such a section does not 34417 exist. Do not define both this macro and 'INIT_SECTION_ASM_OP'. 34418 34419 -- Macro: FINI_ARRAY_SECTION_ASM_OP 34420 If defined, a C expression whose value is a string, including 34421 spacing, containing the assembler operation to identify the 34422 following data as part of the '.fini_array' (or equivalent) 34423 section. If not defined, GCC will assume such a section does not 34424 exist. Do not define both this macro and 'FINI_SECTION_ASM_OP'. 34425 34426 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 34427 If defined, an ASM statement that switches to a different section 34428 via SECTION_OP, calls FUNCTION, and switches back to the text 34429 section. This is used in 'crtstuff.c' if 'INIT_SECTION_ASM_OP' or 34430 'FINI_SECTION_ASM_OP' to calls to initialization and finalization 34431 functions from the init and fini sections. By default, this macro 34432 uses a simple function call. Some ports need hand-crafted assembly 34433 code to avoid dependencies on registers initialized in the function 34434 prologue or to ensure that constant pools don't end up too far way 34435 in the text section. 34436 34437 -- Macro: TARGET_LIBGCC_SDATA_SECTION 34438 If defined, a string which names the section into which small 34439 variables defined in crtstuff and libgcc should go. This is useful 34440 when the target has options for optimizing access to small data, 34441 and you want the crtstuff and libgcc routines to be conservative in 34442 what they expect of your application yet liberal in what your 34443 application expects. For example, for targets with a '.sdata' 34444 section (like MIPS), you could compile crtstuff with '-G 0' so that 34445 it doesn't require small data support from your application, but 34446 use this macro to put small data into '.sdata' so that your 34447 application can access these variables whether it uses small data 34448 or not. 34449 34450 -- Macro: FORCE_CODE_SECTION_ALIGN 34451 If defined, an ASM statement that aligns a code section to some 34452 arbitrary boundary. This is used to force all fragments of the 34453 '.init' and '.fini' sections to have to same alignment and thus 34454 prevent the linker from having to add any padding. 34455 34456 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 34457 Define this macro to be an expression with a nonzero value if jump 34458 tables (for 'tablejump' insns) should be output in the text 34459 section, along with the assembler instructions. Otherwise, the 34460 readonly data section is used. 34461 34462 This macro is irrelevant if there is no separate readonly data 34463 section. 34464 34465 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 34466 Define this hook if you need to do something special to set up the 34467 'varasm.c' sections, or if your target has some special sections of 34468 its own that you need to create. 34469 34470 GCC calls this hook after processing the command line, but before 34471 writing any assembly code, and before calling any of the 34472 section-returning hooks described below. 34473 34474 -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void) 34475 Return a mask describing how relocations should be treated when 34476 selecting sections. Bit 1 should be set if global relocations 34477 should be placed in a read-write section; bit 0 should be set if 34478 local relocations should be placed in a read-write section. 34479 34480 The default version of this function returns 3 when '-fpic' is in 34481 effect, and 0 otherwise. The hook is typically redefined when the 34482 target cannot support (some kinds of) dynamic relocations in 34483 read-only sections even in executables. 34484 34485 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 34486 RELOC, unsigned HOST_WIDE_INT ALIGN) 34487 Return the section into which EXP should be placed. You can assume 34488 that EXP is either a 'VAR_DECL' node or a constant of some sort. 34489 RELOC indicates whether the initial value of EXP requires link-time 34490 relocations. Bit 0 is set when variable contains local relocations 34491 only, while bit 1 is set for global relocations. ALIGN is the 34492 constant alignment in bits. 34493 34494 The default version of this function takes care of putting 34495 read-only variables in 'readonly_data_section'. 34496 34497 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 34498 34499 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 34500 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 34501 called for 'FUNCTION_DECL's as well as for variables and constants. 34502 34503 In the case of a 'FUNCTION_DECL', RELOC will be zero if the 34504 function has been determined to be likely to be called, and nonzero 34505 if it is unlikely to be called. 34506 34507 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 34508 Build up a unique section name, expressed as a 'STRING_CST' node, 34509 and assign it to 'DECL_SECTION_NAME (DECL)'. As with 34510 'TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 34511 value of EXP requires link-time relocations. 34512 34513 The default version of this function appends the symbol name to the 34514 ELF section name that would normally be used for the symbol. For 34515 example, the function 'foo' would be placed in '.text.foo'. 34516 Whatever the actual target object format, this is often good 34517 enough. 34518 34519 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 34520 DECL) 34521 Return the readonly data section associated with 'DECL_SECTION_NAME 34522 (DECL)'. The default version of this function selects 34523 '.gnu.linkonce.r.name' if the function's section is 34524 '.gnu.linkonce.t.name', '.rodata.name' if function is in 34525 '.text.name', and the normal readonly-data section otherwise. 34526 34527 -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX 34528 Usually, the compiler uses the prefix '".rodata"' to construct 34529 section names for mergeable constant data. Define this macro to 34530 override the string if a different section name should be used. 34531 34532 -- Target Hook: section * TARGET_ASM_TM_CLONE_TABLE_SECTION (void) 34533 Return the section that should be used for transactional memory 34534 clone tables. 34535 34536 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (machine_mode 34537 MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 34538 Return the section into which a constant X, of mode MODE, should be 34539 placed. You can assume that X is some kind of constant in RTL. 34540 The argument MODE is redundant except in the case of a 'const_int' 34541 rtx. ALIGN is the constant alignment in bits. 34542 34543 The default version of this function takes care of putting symbolic 34544 constants in 'flag_pic' mode in 'data_section' and everything else 34545 in 'readonly_data_section'. 34546 34547 -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, tree 34548 ID) 34549 Define this hook if you need to postprocess the assembler name 34550 generated by target-independent code. The ID provided to this hook 34551 will be the computed name (e.g., the macro 'DECL_NAME' of the DECL 34552 in C, or the mangled name of the DECL in C++). The return value of 34553 the hook is an 'IDENTIFIER_NODE' for the appropriate mangled name 34554 on your target system. The default implementation of this hook 34555 just returns the ID provided. 34556 34557 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 34558 int NEW_DECL_P) 34559 Define this hook if references to a symbol or a constant must be 34560 treated differently depending on something about the variable or 34561 function named by the symbol (such as what section it is in). 34562 34563 The hook is executed immediately after rtl has been created for 34564 DECL, which may be a variable or function declaration or an entry 34565 in the constant pool. In either case, RTL is the rtl in question. 34566 Do _not_ use 'DECL_RTL (DECL)' in this hook; that field may not 34567 have been initialized yet. 34568 34569 In the case of a constant, it is safe to assume that the rtl is a 34570 'mem' whose address is a 'symbol_ref'. Most decls will also have 34571 this form, but that is not guaranteed. Global register variables, 34572 for instance, will have a 'reg' for their rtl. (Normally the right 34573 thing to do with such unusual rtl is leave it alone.) 34574 34575 The NEW_DECL_P argument will be true if this is the first time that 34576 'TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. It 34577 will be false for subsequent invocations, which will happen for 34578 duplicate declarations. Whether or not anything must be done for 34579 the duplicate declaration depends on whether the hook examines 34580 'DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 34581 called for a constant. 34582 34583 The usual thing for this hook to do is to record flags in the 34584 'symbol_ref', using 'SYMBOL_REF_FLAG' or 'SYMBOL_REF_FLAGS'. 34585 Historically, the name string was modified if it was necessary to 34586 encode more than one bit of information, but this practice is now 34587 discouraged; use 'SYMBOL_REF_FLAGS'. 34588 34589 The default definition of this hook, 'default_encode_section_info' 34590 in 'varasm.c', sets a number of commonly-useful bits in 34591 'SYMBOL_REF_FLAGS'. Check whether the default does what you need 34592 before overriding it. 34593 34594 -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char 34595 *NAME) 34596 Decode NAME and return the real name part, sans the characters that 34597 'TARGET_ENCODE_SECTION_INFO' may have added. 34598 34599 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP) 34600 Returns true if EXP should be placed into a "small data" section. 34601 The default version of this hook always returns false. 34602 34603 -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION 34604 Contains the value true if the target places read-only "small data" 34605 into a separate section. The default value is false. 34606 34607 -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void) 34608 It returns true if target wants profile code emitted before 34609 prologue. 34610 34611 The default version of this hook use the target macro 34612 'PROFILE_BEFORE_PROLOGUE'. 34613 34614 -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP) 34615 Returns true if EXP names an object for which name resolution rules 34616 must resolve to the current "module" (dynamic shared library or 34617 executable image). 34618 34619 The default version of this hook implements the name resolution 34620 rules for ELF, which has a looser model of global name binding than 34621 other currently supported object file formats. 34622 34623 -- Target Hook: bool TARGET_HAVE_TLS 34624 Contains the value true if the target supports thread-local 34625 storage. The default value is false. 34626 34627 34628File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 34629 3463017.19 Position Independent Code 34631=============================== 34632 34633This section describes macros that help implement generation of position 34634independent code. Simply defining these macros is not enough to 34635generate valid PIC; you must also add support to the hook 34636'TARGET_LEGITIMATE_ADDRESS_P' and to the macro 'PRINT_OPERAND_ADDRESS', 34637as well as 'LEGITIMIZE_ADDRESS'. You must modify the definition of 34638'movsi' to do something appropriate when the source operand contains a 34639symbolic address. You may also need to alter the handling of switch 34640statements so that they use relative addresses. 34641 34642 -- Macro: PIC_OFFSET_TABLE_REGNUM 34643 The register number of the register used to address a table of 34644 static data addresses in memory. In some cases this register is 34645 defined by a processor's "application binary interface" (ABI). 34646 When this macro is defined, RTL is generated for this register 34647 once, as with the stack pointer and frame pointer registers. If 34648 this macro is not defined, it is up to the machine-dependent files 34649 to allocate such a register (if necessary). Note that this 34650 register must be fixed when in use (e.g. when 'flag_pic' is true). 34651 34652 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 34653 A C expression that is nonzero if the register defined by 34654 'PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. If not defined, 34655 the default is zero. Do not define this macro if 34656 'PIC_OFFSET_TABLE_REGNUM' is not defined. 34657 34658 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 34659 A C expression that is nonzero if X is a legitimate immediate 34660 operand on the target machine when generating position independent 34661 code. You can assume that X satisfies 'CONSTANT_P', so you need 34662 not check this. You can also assume FLAG_PIC is true, so you need 34663 not check it either. You need not define this macro if all 34664 constants (including 'SYMBOL_REF') can be immediate operands when 34665 generating position independent code. 34666 34667 34668File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 34669 3467017.20 Defining the Output Assembler Language 34671============================================ 34672 34673This section describes macros whose principal purpose is to describe how 34674to write instructions in assembler language--rather than what the 34675instructions do. 34676 34677* Menu: 34678 34679* File Framework:: Structural information for the assembler file. 34680* Data Output:: Output of constants (numbers, strings, addresses). 34681* Uninitialized Data:: Output of uninitialized variables. 34682* Label Output:: Output and generation of labels. 34683* Initialization:: General principles of initialization 34684 and termination routines. 34685* Macros for Initialization:: 34686 Specific macros that control the handling of 34687 initialization and termination routines. 34688* Instruction Output:: Output of actual instructions. 34689* Dispatch Tables:: Output of jump tables. 34690* Exception Region Output:: Output of exception region code. 34691* Alignment Output:: Pseudo ops for alignment and skipping data. 34692 34693 34694File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 34695 3469617.20.1 The Overall Framework of an Assembler File 34697-------------------------------------------------- 34698 34699This describes the overall framework of an assembly file. 34700 34701 -- Target Hook: void TARGET_ASM_FILE_START (void) 34702 Output to 'asm_out_file' any text which the assembler expects to 34703 find at the beginning of a file. The default behavior is 34704 controlled by two flags, documented below. Unless your target's 34705 assembler is quite unusual, if you override the default, you should 34706 call 'default_file_start' at some point in your target hook. This 34707 lets other target files rely on these variables. 34708 34709 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 34710 If this flag is true, the text of the macro 'ASM_APP_OFF' will be 34711 printed as the very first line in the assembly file, unless 34712 '-fverbose-asm' is in effect. (If that macro has been defined to 34713 the empty string, this variable has no effect.) With the normal 34714 definition of 'ASM_APP_OFF', the effect is to notify the GNU 34715 assembler that it need not bother stripping comments or extra 34716 whitespace from its input. This allows it to work a bit faster. 34717 34718 The default is false. You should not set it to true unless you 34719 have verified that your port does not generate any extra whitespace 34720 or comments that will cause GAS to issue errors in NO_APP mode. 34721 34722 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 34723 If this flag is true, 'output_file_directive' will be called for 34724 the primary source file, immediately after printing 'ASM_APP_OFF' 34725 (if that is enabled). Most ELF assemblers expect this to be done. 34726 The default is false. 34727 34728 -- Target Hook: void TARGET_ASM_FILE_END (void) 34729 Output to 'asm_out_file' any text which the assembler expects to 34730 find at the end of a file. The default is to output nothing. 34731 34732 -- Function: void file_end_indicate_exec_stack () 34733 Some systems use a common convention, the '.note.GNU-stack' special 34734 section, to indicate whether or not an object file relies on the 34735 stack being executable. If your system uses this convention, you 34736 should define 'TARGET_ASM_FILE_END' to this function. If you need 34737 to do other things in that hook, have your hook function call this 34738 function. 34739 34740 -- Target Hook: void TARGET_ASM_LTO_START (void) 34741 Output to 'asm_out_file' any text which the assembler expects to 34742 find at the start of an LTO section. The default is to output 34743 nothing. 34744 34745 -- Target Hook: void TARGET_ASM_LTO_END (void) 34746 Output to 'asm_out_file' any text which the assembler expects to 34747 find at the end of an LTO section. The default is to output 34748 nothing. 34749 34750 -- Target Hook: void TARGET_ASM_CODE_END (void) 34751 Output to 'asm_out_file' any text which is needed before emitting 34752 unwind info and debug info at the end of a file. Some targets emit 34753 here PIC setup thunks that cannot be emitted at the end of file, 34754 because they couldn't have unwind info then. The default is to 34755 output nothing. 34756 34757 -- Macro: ASM_COMMENT_START 34758 A C string constant describing how to begin a comment in the target 34759 assembler language. The compiler assumes that the comment will end 34760 at the end of the line. 34761 34762 -- Macro: ASM_APP_ON 34763 A C string constant for text to be output before each 'asm' 34764 statement or group of consecutive ones. Normally this is '"#APP"', 34765 which is a comment that has no effect on most assemblers but tells 34766 the GNU assembler that it must check the lines that follow for all 34767 valid assembler constructs. 34768 34769 -- Macro: ASM_APP_OFF 34770 A C string constant for text to be output after each 'asm' 34771 statement or group of consecutive ones. Normally this is 34772 '"#NO_APP"', which tells the GNU assembler to resume making the 34773 time-saving assumptions that are valid for ordinary compiler 34774 output. 34775 34776 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 34777 A C statement to output COFF information or DWARF debugging 34778 information which indicates that filename NAME is the current 34779 source file to the stdio stream STREAM. 34780 34781 This macro need not be defined if the standard form of output for 34782 the file format in use is appropriate. 34783 34784 -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE, 34785 const char *NAME) 34786 Output COFF information or DWARF debugging information which 34787 indicates that filename NAME is the current source file to the 34788 stdio stream FILE. 34789 34790 This target hook need not be defined if the standard form of output 34791 for the file format in use is appropriate. 34792 34793 -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME) 34794 Output a string based on NAME, suitable for the '#ident' directive, 34795 or the equivalent directive or pragma in non-C-family languages. 34796 If this hook is not defined, nothing is output for the '#ident' 34797 directive. 34798 34799 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 34800 A C statement to output the string STRING to the stdio stream 34801 STREAM. If you do not call the function 'output_quoted_string' in 34802 your config files, GCC will only call it to output filenames to the 34803 assembler source. So you can use it to canonicalize the format of 34804 the filename using this macro. 34805 34806 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 34807 unsigned int FLAGS, tree DECL) 34808 Output assembly directives to switch to section NAME. The section 34809 should have attributes as specified by FLAGS, which is a bit mask 34810 of the 'SECTION_*' flags defined in 'output.h'. If DECL is 34811 non-NULL, it is the 'VAR_DECL' or 'FUNCTION_DECL' with which this 34812 section is associated. 34813 34814 -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum 34815 node_frequency FREQ, bool STARTUP, bool EXIT) 34816 Return preferred text (sub)section for function DECL. Main purpose 34817 of this function is to separate cold, normal and hot functions. 34818 STARTUP is true when function is known to be used only at startup 34819 (from static constructors or it is 'main()'). EXIT is true when 34820 function is known to be used only at exit (from static 34821 destructors). Return NULL if function should go to default text 34822 section. 34823 34824 -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE 34825 *FILE, tree DECL, bool NEW_IS_COLD) 34826 Used by the target to emit any assembler directives or additional 34827 labels needed when a function is partitioned between different 34828 sections. Output should be written to FILE. The function decl is 34829 available as DECL and the new section is 'cold' if NEW_IS_COLD is 34830 'true'. 34831 34832 -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 34833 This flag is true if the target supports 34834 'TARGET_ASM_NAMED_SECTION'. It must not be modified by 34835 command-line option processing. 34836 34837 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 34838 This flag is true if we can create zeroed data by switching to a 34839 BSS section and then using 'ASM_OUTPUT_SKIP' to allocate the space. 34840 This is true on most ELF targets. 34841 34842 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 34843 const char *NAME, int RELOC) 34844 Choose a set of section attributes for use by 34845 'TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 34846 section name, and whether or not the declaration's initializer may 34847 contain runtime relocations. DECL may be null, in which case 34848 read-write data should be assumed. 34849 34850 The default version of this function handles choosing code vs data, 34851 read-only vs read-write data, and 'flag_pic'. You should only need 34852 to override this if your target has special flags that might be set 34853 via '__attribute__'. 34854 34855 -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type 34856 TYPE, const char *TEXT) 34857 Provides the target with the ability to record the gcc command line 34858 switches that have been passed to the compiler, and options that 34859 are enabled. The TYPE argument specifies what is being recorded. 34860 It can take the following values: 34861 34862 'SWITCH_TYPE_PASSED' 34863 TEXT is a command line switch that has been set by the user. 34864 34865 'SWITCH_TYPE_ENABLED' 34866 TEXT is an option which has been enabled. This might be as a 34867 direct result of a command line switch, or because it is 34868 enabled by default or because it has been enabled as a side 34869 effect of a different command line switch. For example, the 34870 '-O2' switch enables various different individual optimization 34871 passes. 34872 34873 'SWITCH_TYPE_DESCRIPTIVE' 34874 TEXT is either NULL or some descriptive text which should be 34875 ignored. If TEXT is NULL then it is being used to warn the 34876 target hook that either recording is starting or ending. The 34877 first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL, 34878 the warning is for start up and the second time the warning is 34879 for wind down. This feature is to allow the target hook to 34880 make any necessary preparations before it starts to record 34881 switches and to perform any necessary tidying up after it has 34882 finished recording switches. 34883 34884 'SWITCH_TYPE_LINE_START' 34885 This option can be ignored by this target hook. 34886 34887 'SWITCH_TYPE_LINE_END' 34888 This option can be ignored by this target hook. 34889 34890 The hook's return value must be zero. Other return values may be 34891 supported in the future. 34892 34893 By default this hook is set to NULL, but an example implementation 34894 is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES, 34895 it records the switches as ASCII text inside a new, string 34896 mergeable section in the assembler output file. The name of the 34897 new section is provided by the 34898 'TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook. 34899 34900 -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION 34901 This is the name of the section that will be created by the example 34902 ELF implementation of the 'TARGET_ASM_RECORD_GCC_SWITCHES' target 34903 hook. 34904 34905 34906File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 34907 3490817.20.2 Output of Data 34909---------------------- 34910 34911 -- Target Hook: const char * TARGET_ASM_BYTE_OP 34912 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 34913 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 34914 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 34915 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 34916 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 34917 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 34918 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 34919 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 34920 These hooks specify assembly directives for creating certain kinds 34921 of integer object. The 'TARGET_ASM_BYTE_OP' directive creates a 34922 byte-sized object, the 'TARGET_ASM_ALIGNED_HI_OP' one creates an 34923 aligned two-byte object, and so on. Any of the hooks may be 34924 'NULL', indicating that no suitable directive is available. 34925 34926 The compiler will print these strings at the start of a new line, 34927 followed immediately by the object's initial value. In most cases, 34928 the string should contain a tab, a pseudo-op, and then another tab. 34929 34930 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 34931 ALIGNED_P) 34932 The 'assemble_integer' function uses this hook to output an integer 34933 object. X is the object's value, SIZE is its size in bytes and 34934 ALIGNED_P indicates whether it is aligned. The function should 34935 return 'true' if it was able to output the object. If it returns 34936 false, 'assemble_integer' will try to split the object into smaller 34937 parts. 34938 34939 The default implementation of this hook will use the 34940 'TARGET_ASM_BYTE_OP' family of strings, returning 'false' when the 34941 relevant string is 'NULL'. 34942 34943 -- Target Hook: void TARGET_ASM_DECL_END (void) 34944 Define this hook if the target assembler requires a special marker 34945 to terminate an initialized variable declaration. 34946 34947 -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE, 34948 rtx X) 34949 A target hook to recognize RTX patterns that 'output_addr_const' 34950 can't deal with, and output assembly code to FILE corresponding to 34951 the pattern X. This may be used to allow machine-dependent 34952 'UNSPEC's to appear within constants. 34953 34954 If target hook fails to recognize a pattern, it must return 34955 'false', so that a standard error message is printed. If it prints 34956 an error message itself, by calling, for example, 34957 'output_operand_lossage', it may just return 'true'. 34958 34959 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 34960 A C statement to output to the stdio stream STREAM an assembler 34961 instruction to assemble a string constant containing the LEN bytes 34962 at PTR. PTR will be a C expression of type 'char *' and LEN a C 34963 expression of type 'int'. 34964 34965 If the assembler has a '.ascii' pseudo-op as found in the Berkeley 34966 Unix assembler, do not define the macro 'ASM_OUTPUT_ASCII'. 34967 34968 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 34969 A C statement to output word N of a function descriptor for DECL. 34970 This must be defined if 'TARGET_VTABLE_USES_DESCRIPTORS' is 34971 defined, and is otherwise unused. 34972 34973 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 34974 You may define this macro as a C expression. You should define the 34975 expression to have a nonzero value if GCC should output the 34976 constant pool for a function before the code for the function, or a 34977 zero value if GCC should output the constant pool after the 34978 function. If you do not define this macro, the usual case, GCC 34979 will output the constant pool before the function. 34980 34981 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 34982 A C statement to output assembler commands to define the start of 34983 the constant pool for a function. FUNNAME is a string giving the 34984 name of the function. Should the return type of the function be 34985 required, it can be obtained via FUNDECL. SIZE is the size, in 34986 bytes, of the constant pool that will be written immediately after 34987 this call. 34988 34989 If no constant-pool prefix is required, the usual case, this macro 34990 need not be defined. 34991 34992 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO, 34993 JUMPTO) 34994 A C statement (with or without semicolon) to output a constant in 34995 the constant pool, if it needs special treatment. (This macro need 34996 not do anything for RTL expressions that can be output normally.) 34997 34998 The argument FILE is the standard I/O stream to output the 34999 assembler code on. X is the RTL expression for the constant to 35000 output, and MODE is the machine mode (in case X is a 'const_int'). 35001 ALIGN is the required alignment for the value X; you should output 35002 an assembler directive to force this much alignment. 35003 35004 The argument LABELNO is a number to use in an internal label for 35005 the address of this pool entry. The definition of this macro is 35006 responsible for outputting the label definition at the proper 35007 place. Here is how to do this: 35008 35009 (*targetm.asm_out.internal_label) (FILE, "LC", LABELNO); 35010 35011 When you output a pool entry specially, you should end with a 35012 'goto' to the label JUMPTO. This will prevent the same pool entry 35013 from being output a second time in the usual manner. 35014 35015 You need not define this macro if it would do nothing. 35016 35017 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 35018 A C statement to output assembler commands to at the end of the 35019 constant pool for a function. FUNNAME is a string giving the name 35020 of the function. Should the return type of the function be 35021 required, you can obtain it via FUNDECL. SIZE is the size, in 35022 bytes, of the constant pool that GCC wrote immediately before this 35023 call. 35024 35025 If no constant-pool epilogue is required, the usual case, you need 35026 not define this macro. 35027 35028 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR) 35029 Define this macro as a C expression which is nonzero if C is used 35030 as a logical line separator by the assembler. STR points to the 35031 position in the string where C was found; this can be used if a 35032 line separator uses multiple characters. 35033 35034 If you do not define this macro, the default is that only the 35035 character ';' is treated as a logical line separator. 35036 35037 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 35038 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 35039 These target hooks are C string constants, describing the syntax in 35040 the assembler for grouping arithmetic expressions. If not 35041 overridden, they default to normal parentheses, which is correct 35042 for most assemblers. 35043 35044 These macros are provided by 'real.h' for writing the definitions of 35045'ASM_OUTPUT_DOUBLE' and the like: 35046 35047 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 35048 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 35049 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 35050 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 35051 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 35052 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 35053 These translate X, of type 'REAL_VALUE_TYPE', to the target's 35054 floating point representation, and store its bit pattern in the 35055 variable L. For 'REAL_VALUE_TO_TARGET_SINGLE' and 35056 'REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 35057 'long int'. For the others, it should be an array of 'long int'. 35058 The number of elements in this array is determined by the size of 35059 the desired target floating point data type: 32 bits of it go in 35060 each 'long int' array element. Each array element holds 32 bits of 35061 the result, even if 'long int' is wider than 32 bits on the host 35062 machine. 35063 35064 The array element values are designed so that you can print them 35065 out using 'fprintf' in the order they should appear in the target 35066 machine's memory. 35067 35068 35069File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 35070 3507117.20.3 Output of Uninitialized Variables 35072----------------------------------------- 35073 35074Each of the macros in this section is used to do the whole job of 35075outputting a single uninitialized variable. 35076 35077 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 35078 A C statement (sans semicolon) to output to the stdio stream STREAM 35079 the assembler definition of a common-label named NAME whose size is 35080 SIZE bytes. The variable ROUNDED is the size rounded up to 35081 whatever alignment the caller wants. It is possible that SIZE may 35082 be zero, for instance if a struct with no other member than a 35083 zero-length array is defined. In this case, the backend must 35084 output a symbol definition that allocates at least one byte, both 35085 so that the address of the resulting object does not compare equal 35086 to any other, and because some object formats cannot even express 35087 the concept of a zero-sized common symbol, as that is how they 35088 represent an ordinary undefined external. 35089 35090 Use the expression 'assemble_name (STREAM, NAME)' to output the 35091 name itself; before and after that, output the additional assembler 35092 syntax for defining the name, and a newline. 35093 35094 This macro controls how the assembler definitions of uninitialized 35095 common global variables are output. 35096 35097 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 35098 Like 'ASM_OUTPUT_COMMON' except takes the required alignment as a 35099 separate, explicit argument. If you define this macro, it is used 35100 in place of 'ASM_OUTPUT_COMMON', and gives you more flexibility in 35101 handling the required alignment of the variable. The alignment is 35102 specified as the number of bits. 35103 35104 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 35105 ALIGNMENT) 35106 Like 'ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 35107 to be output, if there is one, or 'NULL_TREE' if there is no 35108 corresponding variable. If you define this macro, GCC will use it 35109 in place of both 'ASM_OUTPUT_COMMON' and 35110 'ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 35111 see the variable's decl in order to chose what to output. 35112 35113 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 35114 A C statement (sans semicolon) to output to the stdio stream STREAM 35115 the assembler definition of uninitialized global DECL named NAME 35116 whose size is SIZE bytes. The variable ALIGNMENT is the alignment 35117 specified as the number of bits. 35118 35119 Try to use function 'asm_output_aligned_bss' defined in file 35120 'varasm.c' when defining this macro. If unable, use the expression 35121 'assemble_name (STREAM, NAME)' to output the name itself; before 35122 and after that, output the additional assembler syntax for defining 35123 the name, and a newline. 35124 35125 There are two ways of handling global BSS. One is to define this 35126 macro. The other is to have 'TARGET_ASM_SELECT_SECTION' return a 35127 switchable BSS section (*note 35128 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 35129 both. 35130 35131 Some languages do not have 'common' data, and require a non-common 35132 form of global BSS in order to handle uninitialized globals 35133 efficiently. C++ is one example of this. However, if the target 35134 does not support global BSS, the front end may choose to make 35135 globals common in order to save space in the object file. 35136 35137 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 35138 A C statement (sans semicolon) to output to the stdio stream STREAM 35139 the assembler definition of a local-common-label named NAME whose 35140 size is SIZE bytes. The variable ROUNDED is the size rounded up to 35141 whatever alignment the caller wants. 35142 35143 Use the expression 'assemble_name (STREAM, NAME)' to output the 35144 name itself; before and after that, output the additional assembler 35145 syntax for defining the name, and a newline. 35146 35147 This macro controls how the assembler definitions of uninitialized 35148 static variables are output. 35149 35150 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 35151 Like 'ASM_OUTPUT_LOCAL' except takes the required alignment as a 35152 separate, explicit argument. If you define this macro, it is used 35153 in place of 'ASM_OUTPUT_LOCAL', and gives you more flexibility in 35154 handling the required alignment of the variable. The alignment is 35155 specified as the number of bits. 35156 35157 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 35158 ALIGNMENT) 35159 Like 'ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to 35160 be output, if there is one, or 'NULL_TREE' if there is no 35161 corresponding variable. If you define this macro, GCC will use it 35162 in place of both 'ASM_OUTPUT_DECL' and 'ASM_OUTPUT_ALIGNED_DECL'. 35163 Define this macro when you need to see the variable's decl in order 35164 to chose what to output. 35165 35166 35167File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 35168 3516917.20.4 Output and Generation of Labels 35170--------------------------------------- 35171 35172This is about outputting labels. 35173 35174 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 35175 A C statement (sans semicolon) to output to the stdio stream STREAM 35176 the assembler definition of a label named NAME. Use the expression 35177 'assemble_name (STREAM, NAME)' to output the name itself; before 35178 and after that, output the additional assembler syntax for defining 35179 the name, and a newline. A default definition of this macro is 35180 provided which is correct for most systems. 35181 35182 -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL) 35183 A C statement (sans semicolon) to output to the stdio stream STREAM 35184 the assembler definition of a label named NAME of a function. Use 35185 the expression 'assemble_name (STREAM, NAME)' to output the name 35186 itself; before and after that, output the additional assembler 35187 syntax for defining the name, and a newline. A default definition 35188 of this macro is provided which is correct for most systems. 35189 35190 If this macro is not defined, then the function name is defined in 35191 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 35192 35193 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 35194 Identical to 'ASM_OUTPUT_LABEL', except that NAME is known to refer 35195 to a compiler-generated label. The default definition uses 35196 'assemble_name_raw', which is like 'assemble_name' except that it 35197 is more efficient. 35198 35199 -- Macro: SIZE_ASM_OP 35200 A C string containing the appropriate assembler directive to 35201 specify the size of a symbol, without any arguments. On systems 35202 that use ELF, the default (in 'config/elfos.h') is '"\t.size\t"'; 35203 on other systems, the default is not to define this macro. 35204 35205 Define this macro only if it is correct to use the default 35206 definitions of 'ASM_OUTPUT_SIZE_DIRECTIVE' and 35207 'ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 35208 custom definitions of those macros, or if you do not need explicit 35209 symbol sizes at all, do not define this macro. 35210 35211 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 35212 A C statement (sans semicolon) to output to the stdio stream STREAM 35213 a directive telling the assembler that the size of the symbol NAME 35214 is SIZE. SIZE is a 'HOST_WIDE_INT'. If you define 'SIZE_ASM_OP', 35215 a default definition of this macro is provided. 35216 35217 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 35218 A C statement (sans semicolon) to output to the stdio stream STREAM 35219 a directive telling the assembler to calculate the size of the 35220 symbol NAME by subtracting its address from the current address. 35221 35222 If you define 'SIZE_ASM_OP', a default definition of this macro is 35223 provided. The default assumes that the assembler recognizes a 35224 special '.' symbol as referring to the current address, and can 35225 calculate the difference between this and another symbol. If your 35226 assembler does not recognize '.' or cannot do calculations with it, 35227 you will need to redefine 'ASM_OUTPUT_MEASURED_SIZE' to use some 35228 other technique. 35229 35230 -- Macro: NO_DOLLAR_IN_LABEL 35231 Define this macro if the assembler does not accept the character 35232 '$' in label names. By default constructors and destructors in G++ 35233 have '$' in the identifiers. If this macro is defined, '.' is used 35234 instead. 35235 35236 -- Macro: NO_DOT_IN_LABEL 35237 Define this macro if the assembler does not accept the character 35238 '.' in label names. By default constructors and destructors in G++ 35239 have names that use '.'. If this macro is defined, these names are 35240 rewritten to avoid '.'. 35241 35242 -- Macro: TYPE_ASM_OP 35243 A C string containing the appropriate assembler directive to 35244 specify the type of a symbol, without any arguments. On systems 35245 that use ELF, the default (in 'config/elfos.h') is '"\t.type\t"'; 35246 on other systems, the default is not to define this macro. 35247 35248 Define this macro only if it is correct to use the default 35249 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 35250 need your own custom definition of this macro, or if you do not 35251 need explicit symbol types at all, do not define this macro. 35252 35253 -- Macro: TYPE_OPERAND_FMT 35254 A C string which specifies (using 'printf' syntax) the format of 35255 the second operand to 'TYPE_ASM_OP'. On systems that use ELF, the 35256 default (in 'config/elfos.h') is '"@%s"'; on other systems, the 35257 default is not to define this macro. 35258 35259 Define this macro only if it is correct to use the default 35260 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 35261 need your own custom definition of this macro, or if you do not 35262 need explicit symbol types at all, do not define this macro. 35263 35264 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 35265 A C statement (sans semicolon) to output to the stdio stream STREAM 35266 a directive telling the assembler that the type of the symbol NAME 35267 is TYPE. TYPE is a C string; currently, that string is always 35268 either '"function"' or '"object"', but you should not count on 35269 this. 35270 35271 If you define 'TYPE_ASM_OP' and 'TYPE_OPERAND_FMT', a default 35272 definition of this macro is provided. 35273 35274 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 35275 A C statement (sans semicolon) to output to the stdio stream STREAM 35276 any text necessary for declaring the name NAME of a function which 35277 is being defined. This macro is responsible for outputting the 35278 label definition (perhaps using 'ASM_OUTPUT_FUNCTION_LABEL'). The 35279 argument DECL is the 'FUNCTION_DECL' tree node representing the 35280 function. 35281 35282 If this macro is not defined, then the function name is defined in 35283 the usual manner as a label (by means of 35284 'ASM_OUTPUT_FUNCTION_LABEL'). 35285 35286 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 35287 of this macro. 35288 35289 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 35290 A C statement (sans semicolon) to output to the stdio stream STREAM 35291 any text necessary for declaring the size of a function which is 35292 being defined. The argument NAME is the name of the function. The 35293 argument DECL is the 'FUNCTION_DECL' tree node representing the 35294 function. 35295 35296 If this macro is not defined, then the function size is not 35297 defined. 35298 35299 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 35300 this macro. 35301 35302 -- Macro: ASM_DECLARE_COLD_FUNCTION_NAME (STREAM, NAME, DECL) 35303 A C statement (sans semicolon) to output to the stdio stream STREAM 35304 any text necessary for declaring the name NAME of a cold function 35305 partition which is being defined. This macro is responsible for 35306 outputting the label definition (perhaps using 35307 'ASM_OUTPUT_FUNCTION_LABEL'). The argument DECL is the 35308 'FUNCTION_DECL' tree node representing the function. 35309 35310 If this macro is not defined, then the cold partition name is 35311 defined in the usual manner as a label (by means of 35312 'ASM_OUTPUT_LABEL'). 35313 35314 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 35315 of this macro. 35316 35317 -- Macro: ASM_DECLARE_COLD_FUNCTION_SIZE (STREAM, NAME, DECL) 35318 A C statement (sans semicolon) to output to the stdio stream STREAM 35319 any text necessary for declaring the size of a cold function 35320 partition which is being defined. The argument NAME is the name of 35321 the cold partition of the function. The argument DECL is the 35322 'FUNCTION_DECL' tree node representing the function. 35323 35324 If this macro is not defined, then the partition size is not 35325 defined. 35326 35327 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 35328 this macro. 35329 35330 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 35331 A C statement (sans semicolon) to output to the stdio stream STREAM 35332 any text necessary for declaring the name NAME of an initialized 35333 variable which is being defined. This macro must output the label 35334 definition (perhaps using 'ASM_OUTPUT_LABEL'). The argument DECL 35335 is the 'VAR_DECL' tree node representing the variable. 35336 35337 If this macro is not defined, then the variable name is defined in 35338 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 35339 35340 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' and/or 35341 'ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 35342 35343 -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE, 35344 const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE) 35345 A target hook to output to the stdio stream FILE any text necessary 35346 for declaring the name NAME of a constant which is being defined. 35347 This target hook is responsible for outputting the label definition 35348 (perhaps using 'assemble_label'). The argument EXP is the value of 35349 the constant, and SIZE is the size of the constant in bytes. The 35350 NAME will be an internal label. 35351 35352 The default version of this target hook, define the NAME in the 35353 usual manner as a label (by means of 'assemble_label'). 35354 35355 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in this target 35356 hook. 35357 35358 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 35359 A C statement (sans semicolon) to output to the stdio stream STREAM 35360 any text necessary for claiming a register REGNO for a global 35361 variable DECL with name NAME. 35362 35363 If you don't define this macro, that is equivalent to defining it 35364 to do nothing. 35365 35366 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 35367 A C statement (sans semicolon) to finish up declaring a variable 35368 name once the compiler has processed its initializer fully and thus 35369 has had a chance to determine the size of an array when controlled 35370 by an initializer. This is used on systems where it's necessary to 35371 declare something about the size of the object. 35372 35373 If you don't define this macro, that is equivalent to defining it 35374 to do nothing. 35375 35376 You may wish to use 'ASM_OUTPUT_SIZE_DIRECTIVE' and/or 35377 'ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 35378 35379 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 35380 char *NAME) 35381 This target hook is a function to output to the stdio stream STREAM 35382 some commands that will make the label NAME global; that is, 35383 available for reference from other files. 35384 35385 The default implementation relies on a proper definition of 35386 'GLOBAL_ASM_OP'. 35387 35388 -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, tree 35389 DECL) 35390 This target hook is a function to output to the stdio stream STREAM 35391 some commands that will make the name associated with DECL global; 35392 that is, available for reference from other files. 35393 35394 The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL 35395 target hook. 35396 35397 -- Target Hook: void TARGET_ASM_ASSEMBLE_UNDEFINED_DECL (FILE *STREAM, 35398 const char *NAME, const_tree DECL) 35399 This target hook is a function to output to the stdio stream STREAM 35400 some commands that will declare the name associated with DECL which 35401 is not defined in the current translation unit. Most assemblers do 35402 not require anything to be output in this case. 35403 35404 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 35405 A C statement (sans semicolon) to output to the stdio stream STREAM 35406 some commands that will make the label NAME weak; that is, 35407 available for reference from other files but only used if no other 35408 definition is available. Use the expression 'assemble_name 35409 (STREAM, NAME)' to output the name itself; before and after that, 35410 output the additional assembler syntax for making that name weak, 35411 and a newline. 35412 35413 If you don't define this macro or 'ASM_WEAKEN_DECL', GCC will not 35414 support weak symbols and you should not define the 'SUPPORTS_WEAK' 35415 macro. 35416 35417 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 35418 Combines (and replaces) the function of 'ASM_WEAKEN_LABEL' and 35419 'ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 35420 or variable decl. If VALUE is not 'NULL', this C statement should 35421 output to the stdio stream STREAM assembler code which defines 35422 (equates) the weak symbol NAME to have the value VALUE. If VALUE 35423 is 'NULL', it should output commands to make NAME weak. 35424 35425 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 35426 Outputs a directive that enables NAME to be used to refer to symbol 35427 VALUE with weak-symbol semantics. 'decl' is the declaration of 35428 'name'. 35429 35430 -- Macro: SUPPORTS_WEAK 35431 A preprocessor constant expression which evaluates to true if the 35432 target supports weak symbols. 35433 35434 If you don't define this macro, 'defaults.h' provides a default 35435 definition. If either 'ASM_WEAKEN_LABEL' or 'ASM_WEAKEN_DECL' is 35436 defined, the default definition is '1'; otherwise, it is '0'. 35437 35438 -- Macro: TARGET_SUPPORTS_WEAK 35439 A C expression which evaluates to true if the target supports weak 35440 symbols. 35441 35442 If you don't define this macro, 'defaults.h' provides a default 35443 definition. The default definition is '(SUPPORTS_WEAK)'. Define 35444 this macro if you want to control weak symbol support with a 35445 compiler flag such as '-melf'. 35446 35447 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 35448 A C statement (sans semicolon) to mark DECL to be emitted as a 35449 public symbol such that extra copies in multiple translation units 35450 will be discarded by the linker. Define this macro if your object 35451 file format provides support for this concept, such as the 'COMDAT' 35452 section flags in the Microsoft Windows PE/COFF format, and this 35453 support requires changes to DECL, such as putting it in a separate 35454 section. 35455 35456 -- Macro: SUPPORTS_ONE_ONLY 35457 A C expression which evaluates to true if the target supports 35458 one-only semantics. 35459 35460 If you don't define this macro, 'varasm.c' provides a default 35461 definition. If 'MAKE_DECL_ONE_ONLY' is defined, the default 35462 definition is '1'; otherwise, it is '0'. Define this macro if you 35463 want to control one-only symbol support with a compiler flag, or if 35464 setting the 'DECL_ONE_ONLY' flag is enough to mark a declaration to 35465 be emitted as one-only. 35466 35467 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int 35468 VISIBILITY) 35469 This target hook is a function to output to ASM_OUT_FILE some 35470 commands that will make the symbol(s) associated with DECL have 35471 hidden, protected or internal visibility as specified by 35472 VISIBILITY. 35473 35474 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 35475 A C expression that evaluates to true if the target's linker 35476 expects that weak symbols do not appear in a static archive's table 35477 of contents. The default is '0'. 35478 35479 Leaving weak symbols out of an archive's table of contents means 35480 that, if a symbol will only have a definition in one translation 35481 unit and will have undefined references from other translation 35482 units, that symbol should not be weak. Defining this macro to be 35483 nonzero will thus have the effect that certain symbols that would 35484 normally be weak (explicit template instantiations, and vtables for 35485 polymorphic classes with noninline key methods) will instead be 35486 nonweak. 35487 35488 The C++ ABI requires this macro to be zero. Define this macro for 35489 targets where full C++ ABI compliance is impossible and where 35490 linker restrictions require weak symbols to be left out of a static 35491 archive's table of contents. 35492 35493 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 35494 A C statement (sans semicolon) to output to the stdio stream STREAM 35495 any text necessary for declaring the name of an external symbol 35496 named NAME which is referenced in this compilation but not defined. 35497 The value of DECL is the tree node for the declaration. 35498 35499 This macro need not be defined if it does not need to output 35500 anything. The GNU assembler and most Unix assemblers don't require 35501 anything. 35502 35503 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 35504 This target hook is a function to output to ASM_OUT_FILE an 35505 assembler pseudo-op to declare a library function name external. 35506 The name of the library function is given by SYMREF, which is a 35507 'symbol_ref'. 35508 35509 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char 35510 *SYMBOL) 35511 This target hook is a function to output to ASM_OUT_FILE an 35512 assembler directive to annotate SYMBOL as used. The Darwin target 35513 uses the .no_dead_code_strip directive. 35514 35515 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 35516 A C statement (sans semicolon) to output to the stdio stream STREAM 35517 a reference in assembler syntax to a label named NAME. This should 35518 add '_' to the front of the name, if that is customary on your 35519 operating system, as it is in most Berkeley Unix systems. This 35520 macro is used in 'assemble_name'. 35521 35522 -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME) 35523 Given a symbol NAME, perform same mangling as 'varasm.c''s 35524 'assemble_name', but in memory rather than to a file stream, 35525 returning result as an 'IDENTIFIER_NODE'. Required for correct LTO 35526 symtabs. The default implementation calls the 35527 'TARGET_STRIP_NAME_ENCODING' hook and then prepends the 35528 'USER_LABEL_PREFIX', if any. 35529 35530 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 35531 A C statement (sans semicolon) to output a reference to 35532 'SYMBOL_REF' SYM. If not defined, 'assemble_name' will be used to 35533 output the name of the symbol. This macro may be used to modify 35534 the way a symbol is referenced depending on information encoded by 35535 'TARGET_ENCODE_SECTION_INFO'. 35536 35537 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 35538 A C statement (sans semicolon) to output a reference to BUF, the 35539 result of 'ASM_GENERATE_INTERNAL_LABEL'. If not defined, 35540 'assemble_name' will be used to output the name of the symbol. 35541 This macro is not used by 'output_asm_label', or the '%l' specifier 35542 that calls it; the intention is that this macro should be set when 35543 it is necessary to output a label differently when its address is 35544 being taken. 35545 35546 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 35547 char *PREFIX, unsigned long LABELNO) 35548 A function to output to the stdio stream STREAM a label whose name 35549 is made from the string PREFIX and the number LABELNO. 35550 35551 It is absolutely essential that these labels be distinct from the 35552 labels used for user-level functions and variables. Otherwise, 35553 certain programs will have name conflicts with internal labels. 35554 35555 It is desirable to exclude internal labels from the symbol table of 35556 the object file. Most assemblers have a naming convention for 35557 labels that should be excluded; on many systems, the letter 'L' at 35558 the beginning of a label has this effect. You should find out what 35559 convention your system uses, and follow it. 35560 35561 The default version of this function utilizes 35562 'ASM_GENERATE_INTERNAL_LABEL'. 35563 35564 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 35565 A C statement to output to the stdio stream STREAM a debug info 35566 label whose name is made from the string PREFIX and the number NUM. 35567 This is useful for VLIW targets, where debug info labels may need 35568 to be treated differently than branch target labels. On some 35569 systems, branch target labels must be at the beginning of 35570 instruction bundles, but debug info labels can occur in the middle 35571 of instruction bundles. 35572 35573 If this macro is not defined, then 35574 '(*targetm.asm_out.internal_label)' will be used. 35575 35576 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 35577 A C statement to store into the string STRING a label whose name is 35578 made from the string PREFIX and the number NUM. 35579 35580 This string, when output subsequently by 'assemble_name', should 35581 produce the output that '(*targetm.asm_out.internal_label)' would 35582 produce with the same PREFIX and NUM. 35583 35584 If the string begins with '*', then 'assemble_name' will output the 35585 rest of the string unchanged. It is often convenient for 35586 'ASM_GENERATE_INTERNAL_LABEL' to use '*' in this way. If the 35587 string doesn't start with '*', then 'ASM_OUTPUT_LABELREF' gets to 35588 output the string, and may change it. (Of course, 35589 'ASM_OUTPUT_LABELREF' is also part of your machine description, so 35590 you should know what it does on your machine.) 35591 35592 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 35593 A C expression to assign to OUTVAR (which is a variable of type 35594 'char *') a newly allocated string made from the string NAME and 35595 the number NUMBER, with some suitable punctuation added. Use 35596 'alloca' to get space for the string. 35597 35598 The string will be used as an argument to 'ASM_OUTPUT_LABELREF' to 35599 produce an assembler label for an internal static variable whose 35600 name is NAME. Therefore, the string must be such as to result in 35601 valid assembler code. The argument NUMBER is different each time 35602 this macro is executed; it prevents conflicts between 35603 similarly-named internal static variables in different scopes. 35604 35605 Ideally this string should not be a valid C identifier, to prevent 35606 any conflict with the user's own symbols. Most assemblers allow 35607 periods or percent signs in assembler symbols; putting at least one 35608 of these between the name and the number will suffice. 35609 35610 If this macro is not defined, a default definition will be provided 35611 which is correct for most systems. 35612 35613 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 35614 A C statement to output to the stdio stream STREAM assembler code 35615 which defines (equates) the symbol NAME to have the value VALUE. 35616 35617 If 'SET_ASM_OP' is defined, a default definition is provided which 35618 is correct for most systems. 35619 35620 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 35621 DECL_OF_VALUE) 35622 A C statement to output to the stdio stream STREAM assembler code 35623 which defines (equates) the symbol whose tree node is DECL_OF_NAME 35624 to have the value of the tree node DECL_OF_VALUE. This macro will 35625 be used in preference to 'ASM_OUTPUT_DEF' if it is defined and if 35626 the tree nodes are available. 35627 35628 If 'SET_ASM_OP' is defined, a default definition is provided which 35629 is correct for most systems. 35630 35631 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 35632 A C statement that evaluates to true if the assembler code which 35633 defines (equates) the symbol whose tree node is DECL_OF_NAME to 35634 have the value of the tree node DECL_OF_VALUE should be emitted 35635 near the end of the current compilation unit. The default is to 35636 not defer output of defines. This macro affects defines output by 35637 'ASM_OUTPUT_DEF' and 'ASM_OUTPUT_DEF_FROM_DECLS'. 35638 35639 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 35640 A C statement to output to the stdio stream STREAM assembler code 35641 which defines (equates) the weak symbol NAME to have the value 35642 VALUE. If VALUE is 'NULL', it defines NAME as an undefined weak 35643 symbol. 35644 35645 Define this macro if the target only supports weak aliases; define 35646 'ASM_OUTPUT_DEF' instead if possible. 35647 35648 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 35649 SEL_NAME) 35650 Define this macro to override the default assembler names used for 35651 Objective-C methods. 35652 35653 The default name is a unique method number followed by the name of 35654 the class (e.g. '_1_Foo'). For methods in categories, the name of 35655 the category is also included in the assembler name (e.g. 35656 '_1_Foo_Bar'). 35657 35658 These names are safe on most systems, but make debugging difficult 35659 since the method's selector is not present in the name. Therefore, 35660 particular systems define other ways of computing names. 35661 35662 BUF is an expression of type 'char *' which gives you a buffer in 35663 which to store the name; its length is as long as CLASS_NAME, 35664 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 35665 35666 The argument IS_INST specifies whether the method is an instance 35667 method or a class method; CLASS_NAME is the name of the class; 35668 CAT_NAME is the name of the category (or 'NULL' if the method is 35669 not in a category); and SEL_NAME is the name of the selector. 35670 35671 On systems where the assembler can handle quoted names, you can use 35672 this macro to provide more human-readable names. 35673 35674 35675File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 35676 3567717.20.5 How Initialization Functions Are Handled 35678------------------------------------------------ 35679 35680The compiled code for certain languages includes "constructors" (also 35681called "initialization routines")--functions to initialize data in the 35682program when the program is started. These functions need to be called 35683before the program is "started"--that is to say, before 'main' is 35684called. 35685 35686 Compiling some languages generates "destructors" (also called 35687"termination routines") that should be called when the program 35688terminates. 35689 35690 To make the initialization and termination functions work, the compiler 35691must output something in the assembler code to cause those functions to 35692be called at the appropriate time. When you port the compiler to a new 35693system, you need to specify how to do this. 35694 35695 There are two major ways that GCC currently supports the execution of 35696initialization and termination functions. Each way has two variants. 35697Much of the structure is common to all four variations. 35698 35699 The linker must build two lists of these functions--a list of 35700initialization functions, called '__CTOR_LIST__', and a list of 35701termination functions, called '__DTOR_LIST__'. 35702 35703 Each list always begins with an ignored function pointer (which may 35704hold 0, -1, or a count of the function pointers after it, depending on 35705the environment). This is followed by a series of zero or more function 35706pointers to constructors (or destructors), followed by a function 35707pointer containing zero. 35708 35709 Depending on the operating system and its executable file format, 35710either 'crtstuff.c' or 'libgcc2.c' traverses these lists at startup time 35711and exit time. Constructors are called in reverse order of the list; 35712destructors in forward order. 35713 35714 The best way to handle static constructors works only for object file 35715formats which provide arbitrarily-named sections. A section is set 35716aside for a list of constructors, and another for a list of destructors. 35717Traditionally these are called '.ctors' and '.dtors'. Each object file 35718that defines an initialization function also puts a word in the 35719constructor section to point to that function. The linker accumulates 35720all these words into one contiguous '.ctors' section. Termination 35721functions are handled similarly. 35722 35723 This method will be chosen as the default by 'target-def.h' if 35724'TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 35725arbitrary sections, but does support special designated constructor and 35726destructor sections may define 'CTORS_SECTION_ASM_OP' and 35727'DTORS_SECTION_ASM_OP' to achieve the same effect. 35728 35729 When arbitrary sections are available, there are two variants, 35730depending upon how the code in 'crtstuff.c' is called. On systems that 35731support a ".init" section which is executed at program startup, parts of 35732'crtstuff.c' are compiled into that section. The program is linked by 35733the 'gcc' driver like this: 35734 35735 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 35736 35737 The prologue of a function ('__init') appears in the '.init' section of 35738'crti.o'; the epilogue appears in 'crtn.o'. Likewise for the function 35739'__fini' in the ".fini" section. Normally these files are provided by 35740the operating system or by the GNU C library, but are provided by GCC 35741for a few targets. 35742 35743 The objects 'crtbegin.o' and 'crtend.o' are (for most targets) compiled 35744from 'crtstuff.c'. They contain, among other things, code fragments 35745within the '.init' and '.fini' sections that branch to routines in the 35746'.text' section. The linker will pull all parts of a section together, 35747which results in a complete '__init' function that invokes the routines 35748we need at startup. 35749 35750 To use this variant, you must define the 'INIT_SECTION_ASM_OP' macro 35751properly. 35752 35753 If no init section is available, when GCC compiles any function called 35754'main' (or more accurately, any function designated as a program entry 35755point by the language front end calling 'expand_main_function'), it 35756inserts a procedure call to '__main' as the first executable code after 35757the function prologue. The '__main' function is defined in 'libgcc2.c' 35758and runs the global constructors. 35759 35760 In file formats that don't support arbitrary sections, there are again 35761two variants. In the simplest variant, the GNU linker (GNU 'ld') and an 35762'a.out' format must be used. In this case, 'TARGET_ASM_CONSTRUCTOR' is 35763defined to produce a '.stabs' entry of type 'N_SETT', referencing the 35764name '__CTOR_LIST__', and with the address of the void function 35765containing the initialization code as its value. The GNU linker 35766recognizes this as a request to add the value to a "set"; the values are 35767accumulated, and are eventually placed in the executable as a vector in 35768the format described above, with a leading (ignored) count and a 35769trailing zero element. 'TARGET_ASM_DESTRUCTOR' is handled similarly. 35770Since no init section is available, the absence of 'INIT_SECTION_ASM_OP' 35771causes the compilation of 'main' to call '__main' as above, starting the 35772initialization process. 35773 35774 The last variant uses neither arbitrary sections nor the GNU linker. 35775This is preferable when you want to do dynamic linking and when using 35776file formats which the GNU linker does not support, such as 'ECOFF'. In 35777this case, 'TARGET_HAVE_CTORS_DTORS' is false, initialization and 35778termination functions are recognized simply by their names. This 35779requires an extra program in the linkage step, called 'collect2'. This 35780program pretends to be the linker, for use with GCC; it does its job by 35781running the ordinary linker, but also arranges to include the vectors of 35782initialization and termination functions. These functions are called 35783via '__main' as described above. In order to use this method, 35784'use_collect2' must be defined in the target in 'config.gcc'. 35785 35786 The following section describes the specific macros that control and 35787customize the handling of initialization and termination functions. 35788 35789 35790File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 35791 3579217.20.6 Macros Controlling Initialization Routines 35793-------------------------------------------------- 35794 35795Here are the macros that control how the compiler handles initialization 35796and termination functions: 35797 35798 -- Macro: INIT_SECTION_ASM_OP 35799 If defined, a C string constant, including spacing, for the 35800 assembler operation to identify the following data as 35801 initialization code. If not defined, GCC will assume such a 35802 section does not exist. When you are using special sections for 35803 initialization and termination functions, this macro also controls 35804 how 'crtstuff.c' and 'libgcc2.c' arrange to run the initialization 35805 functions. 35806 35807 -- Macro: HAS_INIT_SECTION 35808 If defined, 'main' will not call '__main' as described above. This 35809 macro should be defined for systems that control start-up code on a 35810 symbol-by-symbol basis, such as OSF/1, and should not be defined 35811 explicitly for systems that support 'INIT_SECTION_ASM_OP'. 35812 35813 -- Macro: LD_INIT_SWITCH 35814 If defined, a C string constant for a switch that tells the linker 35815 that the following symbol is an initialization routine. 35816 35817 -- Macro: LD_FINI_SWITCH 35818 If defined, a C string constant for a switch that tells the linker 35819 that the following symbol is a finalization routine. 35820 35821 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 35822 If defined, a C statement that will write a function that can be 35823 automatically called when a shared library is loaded. The function 35824 should call FUNC, which takes no arguments. If not defined, and 35825 the object format requires an explicit initialization function, 35826 then a function called '_GLOBAL__DI' will be generated. 35827 35828 This function and the following one are used by collect2 when 35829 linking a shared library that needs constructors or destructors, or 35830 has DWARF2 exception tables embedded in the code. 35831 35832 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 35833 If defined, a C statement that will write a function that can be 35834 automatically called when a shared library is unloaded. The 35835 function should call FUNC, which takes no arguments. If not 35836 defined, and the object format requires an explicit finalization 35837 function, then a function called '_GLOBAL__DD' will be generated. 35838 35839 -- Macro: INVOKE__main 35840 If defined, 'main' will call '__main' despite the presence of 35841 'INIT_SECTION_ASM_OP'. This macro should be defined for systems 35842 where the init section is not actually run automatically, but is 35843 still useful for collecting the lists of constructors and 35844 destructors. 35845 35846 -- Macro: SUPPORTS_INIT_PRIORITY 35847 If nonzero, the C++ 'init_priority' attribute is supported and the 35848 compiler should emit instructions to control the order of 35849 initialization of objects. If zero, the compiler will issue an 35850 error message upon encountering an 'init_priority' attribute. 35851 35852 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 35853 This value is true if the target supports some "native" method of 35854 collecting constructors and destructors to be run at startup and 35855 exit. It is false if we must use 'collect2'. 35856 35857 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 35858 If defined, a function that outputs assembler code to arrange to 35859 call the function referenced by SYMBOL at initialization time. 35860 35861 Assume that SYMBOL is a 'SYMBOL_REF' for a function taking no 35862 arguments and with no return value. If the target supports 35863 initialization priorities, PRIORITY is a value between 0 and 35864 'MAX_INIT_PRIORITY'; otherwise it must be 'DEFAULT_INIT_PRIORITY'. 35865 35866 If this macro is not defined by the target, a suitable default will 35867 be chosen if (1) the target supports arbitrary section names, (2) 35868 the target defines 'CTORS_SECTION_ASM_OP', or (3) 'USE_COLLECT2' is 35869 not defined. 35870 35871 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 35872 This is like 'TARGET_ASM_CONSTRUCTOR' but used for termination 35873 functions rather than initialization functions. 35874 35875 If 'TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 35876generated for the generated object file will have static linkage. 35877 35878 If your system uses 'collect2' as the means of processing constructors, 35879then that program normally uses 'nm' to scan an object file for 35880constructor functions to be called. 35881 35882 On certain kinds of systems, you can define this macro to make 35883'collect2' work faster (and, in some cases, make it work at all): 35884 35885 -- Macro: OBJECT_FORMAT_COFF 35886 Define this macro if the system uses COFF (Common Object File 35887 Format) object files, so that 'collect2' can assume this format and 35888 scan object files directly for dynamic constructor/destructor 35889 functions. 35890 35891 This macro is effective only in a native compiler; 'collect2' as 35892 part of a cross compiler always uses 'nm' for the target machine. 35893 35894 -- Macro: REAL_NM_FILE_NAME 35895 Define this macro as a C string constant containing the file name 35896 to use to execute 'nm'. The default is to search the path normally 35897 for 'nm'. 35898 35899 -- Macro: NM_FLAGS 35900 'collect2' calls 'nm' to scan object files for static constructors 35901 and destructors and LTO info. By default, '-n' is passed. Define 35902 'NM_FLAGS' to a C string constant if other options are needed to 35903 get the same output format as GNU 'nm -n' produces. 35904 35905 If your system supports shared libraries and has a program to list the 35906dynamic dependencies of a given library or executable, you can define 35907these macros to enable support for running initialization and 35908termination functions in shared libraries: 35909 35910 -- Macro: LDD_SUFFIX 35911 Define this macro to a C string constant containing the name of the 35912 program which lists dynamic dependencies, like 'ldd' under SunOS 4. 35913 35914 -- Macro: PARSE_LDD_OUTPUT (PTR) 35915 Define this macro to be C code that extracts filenames from the 35916 output of the program denoted by 'LDD_SUFFIX'. PTR is a variable 35917 of type 'char *' that points to the beginning of a line of output 35918 from 'LDD_SUFFIX'. If the line lists a dynamic dependency, the 35919 code must advance PTR to the beginning of the filename on that 35920 line. Otherwise, it must set PTR to 'NULL'. 35921 35922 -- Macro: SHLIB_SUFFIX 35923 Define this macro to a C string constant containing the default 35924 shared library extension of the target (e.g., '".so"'). 'collect2' 35925 strips version information after this suffix when generating global 35926 constructor and destructor names. This define is only needed on 35927 targets that use 'collect2' to process constructors and 35928 destructors. 35929 35930 35931File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 35932 3593317.20.7 Output of Assembler Instructions 35934---------------------------------------- 35935 35936This describes assembler instruction output. 35937 35938 -- Macro: REGISTER_NAMES 35939 A C initializer containing the assembler's names for the machine 35940 registers, each one as a C string constant. This is what 35941 translates register numbers in the compiler into assembler 35942 language. 35943 35944 -- Macro: ADDITIONAL_REGISTER_NAMES 35945 If defined, a C initializer for an array of structures containing a 35946 name and a register number. This macro defines additional names 35947 for hard registers, thus allowing the 'asm' option in declarations 35948 to refer to registers using alternate names. 35949 35950 -- Macro: OVERLAPPING_REGISTER_NAMES 35951 If defined, a C initializer for an array of structures containing a 35952 name, a register number and a count of the number of consecutive 35953 machine registers the name overlaps. This macro defines additional 35954 names for hard registers, thus allowing the 'asm' option in 35955 declarations to refer to registers using alternate names. Unlike 35956 'ADDITIONAL_REGISTER_NAMES', this macro should be used when the 35957 register name implies multiple underlying registers. 35958 35959 This macro should be used when it is important that a clobber in an 35960 'asm' statement clobbers all the underlying values implied by the 35961 register name. For example, on ARM, clobbering the 35962 double-precision VFP register "d0" implies clobbering both 35963 single-precision registers "s0" and "s1". 35964 35965 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 35966 Define this macro if you are using an unusual assembler that 35967 requires different names for the machine instructions. 35968 35969 The definition is a C statement or statements which output an 35970 assembler instruction opcode to the stdio stream STREAM. The 35971 macro-operand PTR is a variable of type 'char *' which points to 35972 the opcode name in its "internal" form--the form that is written in 35973 the machine description. The definition should output the opcode 35974 name to STREAM, performing any translation you desire, and 35975 increment the variable PTR to point at the end of the opcode so 35976 that it will not be output twice. 35977 35978 In fact, your macro definition may process less than the entire 35979 opcode name, or more than the opcode name; but if you want to 35980 process text that includes '%'-sequences to substitute operands, 35981 you must take care of the substitution yourself. Just be sure to 35982 increment PTR over whatever text should not be output normally. 35983 35984 If you need to look at the operand values, they can be found as the 35985 elements of 'recog_data.operand'. 35986 35987 If the macro definition does nothing, the instruction is output in 35988 the usual way. 35989 35990 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 35991 If defined, a C statement to be executed just prior to the output 35992 of assembler code for INSN, to modify the extracted operands so 35993 they will be output differently. 35994 35995 Here the argument OPVEC is the vector containing the operands 35996 extracted from INSN, and NOPERANDS is the number of elements of the 35997 vector which contain meaningful data for this insn. The contents 35998 of this vector are what will be used to convert the insn template 35999 into assembler code, so you can change the assembler output by 36000 changing the contents of the vector. 36001 36002 This macro is useful when various assembler syntaxes share a single 36003 file of instruction patterns; by defining this macro differently, 36004 you can cause a large class of instructions to be output 36005 differently (such as with rearranged operands). Naturally, 36006 variations in assembler syntax affecting individual insn patterns 36007 ought to be handled by writing conditional output routines in those 36008 patterns. 36009 36010 If this macro is not defined, it is equivalent to a null statement. 36011 36012 -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, 36013 rtx_insn *INSN, rtx *OPVEC, int NOPERANDS) 36014 If defined, this target hook is a function which is executed just 36015 after the output of assembler code for INSN, to change the mode of 36016 the assembler if necessary. 36017 36018 Here the argument OPVEC is the vector containing the operands 36019 extracted from INSN, and NOPERANDS is the number of elements of the 36020 vector which contain meaningful data for this insn. The contents 36021 of this vector are what was used to convert the insn template into 36022 assembler code, so you can change the assembler mode by checking 36023 the contents of the vector. 36024 36025 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 36026 A C compound statement to output to stdio stream STREAM the 36027 assembler syntax for an instruction operand X. X is an RTL 36028 expression. 36029 36030 CODE is a value that can be used to specify one of several ways of 36031 printing the operand. It is used when identical operands must be 36032 printed differently depending on the context. CODE comes from the 36033 '%' specification that was used to request printing of the operand. 36034 If the specification was just '%DIGIT' then CODE is 0; if the 36035 specification was '%LTR DIGIT' then CODE is the ASCII code for LTR. 36036 36037 If X is a register, this macro should print the register's name. 36038 The names can be found in an array 'reg_names' whose type is 'char 36039 *[]'. 'reg_names' is initialized from 'REGISTER_NAMES'. 36040 36041 When the machine description has a specification '%PUNCT' (a '%' 36042 followed by a punctuation character), this macro is called with a 36043 null pointer for X and the punctuation character for CODE. 36044 36045 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 36046 A C expression which evaluates to true if CODE is a valid 36047 punctuation character for use in the 'PRINT_OPERAND' macro. If 36048 'PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 36049 punctuation characters (except for the standard one, '%') are used 36050 in this way. 36051 36052 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 36053 A C compound statement to output to stdio stream STREAM the 36054 assembler syntax for an instruction operand that is a memory 36055 reference whose address is X. X is an RTL expression. 36056 36057 On some machines, the syntax for a symbolic address depends on the 36058 section that the address refers to. On these machines, define the 36059 hook 'TARGET_ENCODE_SECTION_INFO' to store the information into the 36060 'symbol_ref', and then check for it here. *Note Assembler 36061 Format::. 36062 36063 -- Macro: DBR_OUTPUT_SEQEND (FILE) 36064 A C statement, to be executed after all slot-filler instructions 36065 have been output. If necessary, call 'dbr_sequence_length' to 36066 determine the number of slots filled in a sequence (zero if not 36067 currently outputting a sequence), to decide how many no-ops to 36068 output, or whatever. 36069 36070 Don't define this macro if it has nothing to do, but it is helpful 36071 in reading assembly output if the extent of the delay sequence is 36072 made explicit (e.g. with white space). 36073 36074 Note that output routines for instructions with delay slots must be 36075prepared to deal with not being output as part of a sequence (i.e. when 36076the scheduling pass is not run, or when no slot fillers could be found.) 36077The variable 'final_sequence' is null when not processing a sequence, 36078otherwise it contains the 'sequence' rtx being output. 36079 36080 -- Macro: REGISTER_PREFIX 36081 -- Macro: LOCAL_LABEL_PREFIX 36082 -- Macro: USER_LABEL_PREFIX 36083 -- Macro: IMMEDIATE_PREFIX 36084 If defined, C string expressions to be used for the '%R', '%L', 36085 '%U', and '%I' options of 'asm_fprintf' (see 'final.c'). These are 36086 useful when a single 'md' file must support multiple assembler 36087 formats. In that case, the various 'tm.h' files can define these 36088 macros differently. 36089 36090 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 36091 If defined this macro should expand to a series of 'case' 36092 statements which will be parsed inside the 'switch' statement of 36093 the 'asm_fprintf' function. This allows targets to define extra 36094 printf formats which may useful when generating their assembler 36095 statements. Note that uppercase letters are reserved for future 36096 generic extensions to asm_fprintf, and so are not available to 36097 target specific code. The output file is given by the parameter 36098 FILE. The varargs input pointer is ARGPTR and the rest of the 36099 format string, starting the character after the one that is being 36100 switched upon, is pointed to by FORMAT. 36101 36102 -- Macro: ASSEMBLER_DIALECT 36103 If your target supports multiple dialects of assembler language 36104 (such as different opcodes), define this macro as a C expression 36105 that gives the numeric index of the assembler language dialect to 36106 use, with zero as the first variant. 36107 36108 If this macro is defined, you may use constructs of the form 36109 '{option0|option1|option2...}' 36110 in the output templates of patterns (*note Output Template::) or in 36111 the first argument of 'asm_fprintf'. This construct outputs 36112 'option0', 'option1', 'option2', etc., if the value of 36113 'ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 36114 within these strings retain their usual meaning. If there are 36115 fewer alternatives within the braces than the value of 36116 'ASSEMBLER_DIALECT', the construct outputs nothing. If it's needed 36117 to print curly braces or '|' character in assembler output 36118 directly, '%{', '%}' and '%|' can be used. 36119 36120 If you do not define this macro, the characters '{', '|' and '}' do 36121 not have any special meaning when used in templates or operands to 36122 'asm_fprintf'. 36123 36124 Define the macros 'REGISTER_PREFIX', 'LOCAL_LABEL_PREFIX', 36125 'USER_LABEL_PREFIX' and 'IMMEDIATE_PREFIX' if you can express the 36126 variations in assembler language syntax with that mechanism. 36127 Define 'ASSEMBLER_DIALECT' and use the '{option0|option1}' syntax 36128 if the syntax variant are larger and involve such things as 36129 different opcodes or operand order. 36130 36131 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 36132 A C expression to output to STREAM some assembler code which will 36133 push hard register number REGNO onto the stack. The code need not 36134 be optimal, since this macro is used only when profiling. 36135 36136 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 36137 A C expression to output to STREAM some assembler code which will 36138 pop hard register number REGNO off of the stack. The code need not 36139 be optimal, since this macro is used only when profiling. 36140 36141 36142File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 36143 3614417.20.8 Output of Dispatch Tables 36145--------------------------------- 36146 36147This concerns dispatch tables. 36148 36149 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 36150 A C statement to output to the stdio stream STREAM an assembler 36151 pseudo-instruction to generate a difference between two labels. 36152 VALUE and REL are the numbers of two internal labels. The 36153 definitions of these labels are output using 36154 '(*targetm.asm_out.internal_label)', and they must be printed in 36155 the same way here. For example, 36156 36157 fprintf (STREAM, "\t.word L%d-L%d\n", 36158 VALUE, REL) 36159 36160 You must provide this macro on machines where the addresses in a 36161 dispatch table are relative to the table's own address. If 36162 defined, GCC will also use this macro on all machines when 36163 producing PIC. BODY is the body of the 'ADDR_DIFF_VEC'; it is 36164 provided so that the mode and flags can be read. 36165 36166 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 36167 This macro should be provided on machines where the addresses in a 36168 dispatch table are absolute. 36169 36170 The definition should be a C statement to output to the stdio 36171 stream STREAM an assembler pseudo-instruction to generate a 36172 reference to a label. VALUE is the number of an internal label 36173 whose definition is output using 36174 '(*targetm.asm_out.internal_label)'. For example, 36175 36176 fprintf (STREAM, "\t.word L%d\n", VALUE) 36177 36178 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 36179 Define this if the label before a jump-table needs to be output 36180 specially. The first three arguments are the same as for 36181 '(*targetm.asm_out.internal_label)'; the fourth argument is the 36182 jump-table which follows (a 'jump_table_data' containing an 36183 'addr_vec' or 'addr_diff_vec'). 36184 36185 This feature is used on system V to output a 'swbeg' statement for 36186 the table. 36187 36188 If this macro is not defined, these labels are output with 36189 '(*targetm.asm_out.internal_label)'. 36190 36191 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 36192 Define this if something special must be output at the end of a 36193 jump-table. The definition should be a C statement to be executed 36194 after the assembler code for the table is written. It should write 36195 the appropriate code to stdio stream STREAM. The argument TABLE is 36196 the jump-table insn, and NUM is the label-number of the preceding 36197 label. 36198 36199 If this macro is not defined, nothing special is output at the end 36200 of the jump-table. 36201 36202 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree 36203 DECL, int FOR_EH, int EMPTY) 36204 This target hook emits a label at the beginning of each FDE. It 36205 should be defined on targets where FDEs need special labels, and it 36206 should write the appropriate label, for the FDE associated with the 36207 function declaration DECL, to the stdio stream STREAM. The third 36208 argument, FOR_EH, is a boolean: true if this is for an exception 36209 table. The fourth argument, EMPTY, is a boolean: true if this is a 36210 placeholder label for an omitted FDE. 36211 36212 The default is that FDEs are not given nonlocal labels. 36213 36214 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM) 36215 This target hook emits a label at the beginning of the exception 36216 table. It should be defined on targets where it is desirable for 36217 the table to be broken up according to function. 36218 36219 The default is that no label is emitted. 36220 36221 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx 36222 PERSONALITY) 36223 If the target implements 'TARGET_ASM_UNWIND_EMIT', this hook may be 36224 used to emit a directive to install a personality hook into the 36225 unwind info. This hook should not be used if dwarf2 unwind info is 36226 used. 36227 36228 -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx_insn 36229 *INSN) 36230 This target hook emits assembly directives required to unwind the 36231 given instruction. This is only used when 36232 'TARGET_EXCEPT_UNWIND_INFO' returns 'UI_TARGET'. 36233 36234 -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN 36235 True if the 'TARGET_ASM_UNWIND_EMIT' hook should be called before 36236 the assembly for INSN has been emitted, false if the hook should be 36237 called afterward. 36238 36239 36240File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 36241 3624217.20.9 Assembler Commands for Exception Regions 36243------------------------------------------------ 36244 36245This describes commands marking the start and the end of an exception 36246region. 36247 36248 -- Macro: EH_FRAME_SECTION_NAME 36249 If defined, a C string constant for the name of the section 36250 containing exception handling frame unwind information. If not 36251 defined, GCC will provide a default definition if the target 36252 supports named sections. 'crtstuff.c' uses this macro to switch to 36253 the appropriate section. 36254 36255 You should define this symbol if your target supports DWARF 2 frame 36256 unwind information and the default definition does not work. 36257 36258 -- Macro: EH_FRAME_THROUGH_COLLECT2 36259 If defined, DWARF 2 frame unwind information will identified by 36260 specially named labels. The collect2 process will locate these 36261 labels and generate code to register the frames. 36262 36263 This might be necessary, for instance, if the system linker will 36264 not place the eh_frames in-between the sentinals from 'crtstuff.c', 36265 or if the system linker does garbage collection and sections cannot 36266 be marked as not to be collected. 36267 36268 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 36269 Define this macro to 1 if your target is such that no frame unwind 36270 information encoding used with non-PIC code will ever require a 36271 runtime relocation, but the linker may not support merging 36272 read-only and read-write sections into a single read-write section. 36273 36274 -- Macro: MASK_RETURN_ADDR 36275 An rtx used to mask the return address found via 'RETURN_ADDR_RTX', 36276 so that it does not contain any extraneous set bits in it. 36277 36278 -- Macro: DWARF2_UNWIND_INFO 36279 Define this macro to 0 if your target supports DWARF 2 frame unwind 36280 information, but it does not yet work with exception handling. 36281 Otherwise, if your target supports this information (if it defines 36282 'INCOMING_RETURN_ADDR_RTX' and 'OBJECT_FORMAT_ELF'), GCC will 36283 provide a default definition of 1. 36284 36285 -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO 36286 (struct gcc_options *OPTS) 36287 This hook defines the mechanism that will be used for exception 36288 handling by the target. If the target has ABI specified unwind 36289 tables, the hook should return 'UI_TARGET'. If the target is to 36290 use the 'setjmp'/'longjmp'-based exception handling scheme, the 36291 hook should return 'UI_SJLJ'. If the target supports DWARF 2 frame 36292 unwind information, the hook should return 'UI_DWARF2'. 36293 36294 A target may, if exceptions are disabled, choose to return 36295 'UI_NONE'. This may end up simplifying other parts of 36296 target-specific code. The default implementation of this hook 36297 never returns 'UI_NONE'. 36298 36299 Note that the value returned by this hook should be constant. It 36300 should not depend on anything except the command-line switches 36301 described by OPTS. In particular, the setting 'UI_SJLJ' must be 36302 fixed at compiler start-up as C pre-processor macros and builtin 36303 functions related to exception handling are set up depending on 36304 this setting. 36305 36306 The default implementation of the hook first honors the 36307 '--enable-sjlj-exceptions' configure option, then 36308 'DWARF2_UNWIND_INFO', and finally defaults to 'UI_SJLJ'. If 36309 'DWARF2_UNWIND_INFO' depends on command-line options, the target 36310 must define this hook so that OPTS is used correctly. 36311 36312 -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT 36313 This variable should be set to 'true' if the target ABI requires 36314 unwinding tables even when exceptions are not used. It must not be 36315 modified by command-line option processing. 36316 36317 -- Macro: DONT_USE_BUILTIN_SETJMP 36318 Define this macro to 1 if the 'setjmp'/'longjmp'-based scheme 36319 should use the 'setjmp'/'longjmp' functions from the C library 36320 instead of the '__builtin_setjmp'/'__builtin_longjmp' machinery. 36321 36322 -- Macro: JMP_BUF_SIZE 36323 This macro has no effect unless 'DONT_USE_BUILTIN_SETJMP' is also 36324 defined. Define this macro if the default size of 'jmp_buf' buffer 36325 for the 'setjmp'/'longjmp'-based exception handling mechanism is 36326 not large enough, or if it is much too large. The default size is 36327 'FIRST_PSEUDO_REGISTER * sizeof(void *)'. 36328 36329 -- Macro: DWARF_CIE_DATA_ALIGNMENT 36330 This macro need only be defined if the target might save registers 36331 in the function prologue at an offset to the stack pointer that is 36332 not aligned to 'UNITS_PER_WORD'. The definition should be the 36333 negative minimum alignment if 'STACK_GROWS_DOWNWARD' is true, and 36334 the positive minimum alignment otherwise. *Note SDB and DWARF::. 36335 Only applicable if the target supports DWARF 2 frame unwind 36336 information. 36337 36338 -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 36339 Contains the value true if the target should add a zero word onto 36340 the end of a Dwarf-2 frame info section when used for exception 36341 handling. Default value is false if 'EH_FRAME_SECTION_NAME' is 36342 defined, and true otherwise. 36343 36344 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 36345 Given a register, this hook should return a parallel of registers 36346 to represent where to find the register pieces. Define this hook 36347 if the register and its mode are represented in Dwarf in 36348 non-contiguous locations, or if the register should be represented 36349 in more than one register in Dwarf. Otherwise, this hook should 36350 return 'NULL_RTX'. If not defined, the default is to return 36351 'NULL_RTX'. 36352 36353 -- Target Hook: machine_mode TARGET_DWARF_FRAME_REG_MODE (int REGNO) 36354 Given a register, this hook should return the mode which the 36355 corresponding Dwarf frame register should have. This is normally 36356 used to return a smaller mode than the raw mode to prevent call 36357 clobbered parts of a register altering the frame register size 36358 36359 -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS) 36360 If some registers are represented in Dwarf-2 unwind information in 36361 multiple pieces, define this hook to fill in information about the 36362 sizes of those pieces in the table used by the unwinder at runtime. 36363 It will be called by 'expand_builtin_init_dwarf_reg_sizes' after 36364 filling in a single size corresponding to each hard register; 36365 ADDRESS is the address of the table. 36366 36367 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 36368 This hook is used to output a reference from a frame unwinding 36369 table to the type_info object identified by SYM. It should return 36370 'true' if the reference was output. Returning 'false' will cause 36371 the reference to be output using the normal Dwarf2 routines. 36372 36373 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 36374 This flag should be set to 'true' on targets that use an ARM EABI 36375 based unwinding library, and 'false' on other targets. This 36376 effects the format of unwinding tables, and how the unwinder in 36377 entered after running a cleanup. The default is 'false'. 36378 36379 36380File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 36381 3638217.20.10 Assembler Commands for Alignment 36383----------------------------------------- 36384 36385This describes commands for alignment. 36386 36387 -- Macro: JUMP_ALIGN (LABEL) 36388 The alignment (log base 2) to put in front of LABEL, which is a 36389 common destination of jumps and has no fallthru incoming edge. 36390 36391 This macro need not be defined if you don't want any special 36392 alignment to be done at such a time. Most machine descriptions do 36393 not currently define the macro. 36394 36395 Unless it's necessary to inspect the LABEL parameter, it is better 36396 to set the variable ALIGN_JUMPS in the target's 36397 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 36398 user's selection in ALIGN_JUMPS in a 'JUMP_ALIGN' implementation. 36399 36400 -- Target Hook: int TARGET_ASM_JUMP_ALIGN_MAX_SKIP (rtx_insn *LABEL) 36401 The maximum number of bytes to skip before LABEL when applying 36402 'JUMP_ALIGN'. This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is 36403 defined. 36404 36405 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 36406 The alignment (log base 2) to put in front of LABEL, which follows 36407 a 'BARRIER'. 36408 36409 This macro need not be defined if you don't want any special 36410 alignment to be done at such a time. Most machine descriptions do 36411 not currently define the macro. 36412 36413 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP 36414 (rtx_insn *LABEL) 36415 The maximum number of bytes to skip before LABEL when applying 36416 'LABEL_ALIGN_AFTER_BARRIER'. This works only if 36417 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 36418 36419 -- Macro: LOOP_ALIGN (LABEL) 36420 The alignment (log base 2) to put in front of LABEL that heads a 36421 frequently executed basic block (usually the header of a loop). 36422 36423 This macro need not be defined if you don't want any special 36424 alignment to be done at such a time. Most machine descriptions do 36425 not currently define the macro. 36426 36427 Unless it's necessary to inspect the LABEL parameter, it is better 36428 to set the variable 'align_loops' in the target's 36429 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 36430 user's selection in 'align_loops' in a 'LOOP_ALIGN' implementation. 36431 36432 -- Target Hook: int TARGET_ASM_LOOP_ALIGN_MAX_SKIP (rtx_insn *LABEL) 36433 The maximum number of bytes to skip when applying 'LOOP_ALIGN' to 36434 LABEL. This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 36435 36436 -- Macro: LABEL_ALIGN (LABEL) 36437 The alignment (log base 2) to put in front of LABEL. If 36438 'LABEL_ALIGN_AFTER_BARRIER' / 'LOOP_ALIGN' specify a different 36439 alignment, the maximum of the specified values is used. 36440 36441 Unless it's necessary to inspect the LABEL parameter, it is better 36442 to set the variable 'align_labels' in the target's 36443 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 36444 user's selection in 'align_labels' in a 'LABEL_ALIGN' 36445 implementation. 36446 36447 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_MAX_SKIP (rtx_insn *LABEL) 36448 The maximum number of bytes to skip when applying 'LABEL_ALIGN' to 36449 LABEL. This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 36450 36451 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 36452 A C statement to output to the stdio stream STREAM an assembler 36453 instruction to advance the location counter by NBYTES bytes. Those 36454 bytes should be zero when loaded. NBYTES will be a C expression of 36455 type 'unsigned HOST_WIDE_INT'. 36456 36457 -- Macro: ASM_NO_SKIP_IN_TEXT 36458 Define this macro if 'ASM_OUTPUT_SKIP' should not be used in the 36459 text section because it fails to put zeros in the bytes that are 36460 skipped. This is true on many Unix systems, where the pseudo-op to 36461 skip bytes produces no-op instructions rather than zeros when used 36462 in the text section. 36463 36464 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 36465 A C statement to output to the stdio stream STREAM an assembler 36466 command to advance the location counter to a multiple of 2 to the 36467 POWER bytes. POWER will be a C expression of type 'int'. 36468 36469 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 36470 Like 'ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 36471 for padding, if necessary. 36472 36473 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 36474 A C statement to output to the stdio stream STREAM an assembler 36475 command to advance the location counter to a multiple of 2 to the 36476 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 36477 satisfy the alignment request. POWER and MAX_SKIP will be a C 36478 expression of type 'int'. 36479 36480 36481File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 36482 3648317.21 Controlling Debugging Information Format 36484============================================== 36485 36486This describes how to specify debugging information. 36487 36488* Menu: 36489 36490* All Debuggers:: Macros that affect all debugging formats uniformly. 36491* DBX Options:: Macros enabling specific options in DBX format. 36492* DBX Hooks:: Hook macros for varying DBX format. 36493* File Names and DBX:: Macros controlling output of file names in DBX format. 36494* SDB and DWARF:: Macros for SDB (COFF) and DWARF formats. 36495* VMS Debug:: Macros for VMS debug format. 36496 36497 36498File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 36499 3650017.21.1 Macros Affecting All Debugging Formats 36501---------------------------------------------- 36502 36503These macros affect all debugging formats. 36504 36505 -- Macro: DBX_REGISTER_NUMBER (REGNO) 36506 A C expression that returns the DBX register number for the 36507 compiler register number REGNO. In the default macro provided, the 36508 value of this expression will be REGNO itself. But sometimes there 36509 are some registers that the compiler knows about and DBX does not, 36510 or vice versa. In such cases, some register may need to have one 36511 number in the compiler and another for DBX. 36512 36513 If two registers have consecutive numbers inside GCC, and they can 36514 be used as a pair to hold a multiword value, then they _must_ have 36515 consecutive numbers after renumbering with 'DBX_REGISTER_NUMBER'. 36516 Otherwise, debuggers will be unable to access such a pair, because 36517 they expect register pairs to be consecutive in their own numbering 36518 scheme. 36519 36520 If you find yourself defining 'DBX_REGISTER_NUMBER' in way that 36521 does not preserve register pairs, then what you must do instead is 36522 redefine the actual register numbering scheme. 36523 36524 -- Macro: DEBUGGER_AUTO_OFFSET (X) 36525 A C expression that returns the integer offset value for an 36526 automatic variable having address X (an RTL expression). The 36527 default computation assumes that X is based on the frame-pointer 36528 and gives the offset from the frame-pointer. This is required for 36529 targets that produce debugging output for DBX or COFF-style 36530 debugging output for SDB and allow the frame-pointer to be 36531 eliminated when the '-g' options is used. 36532 36533 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 36534 A C expression that returns the integer offset value for an 36535 argument having address X (an RTL expression). The nominal offset 36536 is OFFSET. 36537 36538 -- Macro: PREFERRED_DEBUGGING_TYPE 36539 A C expression that returns the type of debugging output GCC should 36540 produce when the user specifies just '-g'. Define this if you have 36541 arranged for GCC to support more than one format of debugging 36542 output. Currently, the allowable values are 'DBX_DEBUG', 36543 'SDB_DEBUG', 'DWARF_DEBUG', 'DWARF2_DEBUG', 'XCOFF_DEBUG', 36544 'VMS_DEBUG', and 'VMS_AND_DWARF2_DEBUG'. 36545 36546 When the user specifies '-ggdb', GCC normally also uses the value 36547 of this macro to select the debugging output format, but with two 36548 exceptions. If 'DWARF2_DEBUGGING_INFO' is defined, GCC uses the 36549 value 'DWARF2_DEBUG'. Otherwise, if 'DBX_DEBUGGING_INFO' is 36550 defined, GCC uses 'DBX_DEBUG'. 36551 36552 The value of this macro only affects the default debugging output; 36553 the user can always get a specific type of output by using 36554 '-gstabs', '-gcoff', '-gdwarf-2', '-gxcoff', or '-gvms'. 36555 36556 36557File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 36558 3655917.21.2 Specific Options for DBX Output 36560--------------------------------------- 36561 36562These are specific options for DBX output. 36563 36564 -- Macro: DBX_DEBUGGING_INFO 36565 Define this macro if GCC should produce debugging output for DBX in 36566 response to the '-g' option. 36567 36568 -- Macro: XCOFF_DEBUGGING_INFO 36569 Define this macro if GCC should produce XCOFF format debugging 36570 output in response to the '-g' option. This is a variant of DBX 36571 format. 36572 36573 -- Macro: DEFAULT_GDB_EXTENSIONS 36574 Define this macro to control whether GCC should by default generate 36575 GDB's extended version of DBX debugging information (assuming 36576 DBX-format debugging information is enabled at all). If you don't 36577 define the macro, the default is 1: always generate the extended 36578 information if there is any occasion to. 36579 36580 -- Macro: DEBUG_SYMS_TEXT 36581 Define this macro if all '.stabs' commands should be output while 36582 in the text section. 36583 36584 -- Macro: ASM_STABS_OP 36585 A C string constant, including spacing, naming the assembler pseudo 36586 op to use instead of '"\t.stabs\t"' to define an ordinary debugging 36587 symbol. If you don't define this macro, '"\t.stabs\t"' is used. 36588 This macro applies only to DBX debugging information format. 36589 36590 -- Macro: ASM_STABD_OP 36591 A C string constant, including spacing, naming the assembler pseudo 36592 op to use instead of '"\t.stabd\t"' to define a debugging symbol 36593 whose value is the current location. If you don't define this 36594 macro, '"\t.stabd\t"' is used. This macro applies only to DBX 36595 debugging information format. 36596 36597 -- Macro: ASM_STABN_OP 36598 A C string constant, including spacing, naming the assembler pseudo 36599 op to use instead of '"\t.stabn\t"' to define a debugging symbol 36600 with no name. If you don't define this macro, '"\t.stabn\t"' is 36601 used. This macro applies only to DBX debugging information format. 36602 36603 -- Macro: DBX_NO_XREFS 36604 Define this macro if DBX on your system does not support the 36605 construct 'xsTAGNAME'. On some systems, this construct is used to 36606 describe a forward reference to a structure named TAGNAME. On 36607 other systems, this construct is not supported at all. 36608 36609 -- Macro: DBX_CONTIN_LENGTH 36610 A symbol name in DBX-format debugging information is normally 36611 continued (split into two separate '.stabs' directives) when it 36612 exceeds a certain length (by default, 80 characters). On some 36613 operating systems, DBX requires this splitting; on others, 36614 splitting must not be done. You can inhibit splitting by defining 36615 this macro with the value zero. You can override the default 36616 splitting-length by defining this macro as an expression for the 36617 length you desire. 36618 36619 -- Macro: DBX_CONTIN_CHAR 36620 Normally continuation is indicated by adding a '\' character to the 36621 end of a '.stabs' string when a continuation follows. To use a 36622 different character instead, define this macro as a character 36623 constant for the character you want to use. Do not define this 36624 macro if backslash is correct for your system. 36625 36626 -- Macro: DBX_STATIC_STAB_DATA_SECTION 36627 Define this macro if it is necessary to go to the data section 36628 before outputting the '.stabs' pseudo-op for a non-global static 36629 variable. 36630 36631 -- Macro: DBX_TYPE_DECL_STABS_CODE 36632 The value to use in the "code" field of the '.stabs' directive for 36633 a typedef. The default is 'N_LSYM'. 36634 36635 -- Macro: DBX_STATIC_CONST_VAR_CODE 36636 The value to use in the "code" field of the '.stabs' directive for 36637 a static variable located in the text section. DBX format does not 36638 provide any "right" way to do this. The default is 'N_FUN'. 36639 36640 -- Macro: DBX_REGPARM_STABS_CODE 36641 The value to use in the "code" field of the '.stabs' directive for 36642 a parameter passed in registers. DBX format does not provide any 36643 "right" way to do this. The default is 'N_RSYM'. 36644 36645 -- Macro: DBX_REGPARM_STABS_LETTER 36646 The letter to use in DBX symbol data to identify a symbol as a 36647 parameter passed in registers. DBX format does not customarily 36648 provide any way to do this. The default is ''P''. 36649 36650 -- Macro: DBX_FUNCTION_FIRST 36651 Define this macro if the DBX information for a function and its 36652 arguments should precede the assembler code for the function. 36653 Normally, in DBX format, the debugging information entirely follows 36654 the assembler code. 36655 36656 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 36657 Define this macro, with value 1, if the value of a symbol 36658 describing the scope of a block ('N_LBRAC' or 'N_RBRAC') should be 36659 relative to the start of the enclosing function. Normally, GCC 36660 uses an absolute address. 36661 36662 -- Macro: DBX_LINES_FUNCTION_RELATIVE 36663 Define this macro, with value 1, if the value of a symbol 36664 indicating the current line number ('N_SLINE') should be relative 36665 to the start of the enclosing function. Normally, GCC uses an 36666 absolute address. 36667 36668 -- Macro: DBX_USE_BINCL 36669 Define this macro if GCC should generate 'N_BINCL' and 'N_EINCL' 36670 stabs for included header files, as on Sun systems. This macro 36671 also directs GCC to output a type number as a pair of a file number 36672 and a type number within the file. Normally, GCC does not generate 36673 'N_BINCL' or 'N_EINCL' stabs, and it outputs a single number for a 36674 type number. 36675 36676 36677File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 36678 3667917.21.3 Open-Ended Hooks for DBX Format 36680--------------------------------------- 36681 36682These are hooks for DBX format. 36683 36684 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 36685 A C statement to output DBX debugging information before code for 36686 line number LINE of the current source file to the stdio stream 36687 STREAM. COUNTER is the number of time the macro was invoked, 36688 including the current invocation; it is intended to generate unique 36689 labels in the assembly output. 36690 36691 This macro should not be defined if the default output is correct, 36692 or if it can be made correct by defining 36693 'DBX_LINES_FUNCTION_RELATIVE'. 36694 36695 -- Macro: NO_DBX_FUNCTION_END 36696 Some stabs encapsulation formats (in particular ECOFF), cannot 36697 handle the '.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 36698 extension construct. On those machines, define this macro to turn 36699 this feature off without disturbing the rest of the gdb extensions. 36700 36701 -- Macro: NO_DBX_BNSYM_ENSYM 36702 Some assemblers cannot handle the '.stabd BNSYM/ENSYM,0,0' gdb dbx 36703 extension construct. On those machines, define this macro to turn 36704 this feature off without disturbing the rest of the gdb extensions. 36705 36706 36707File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info 36708 3670917.21.4 File Names in DBX Format 36710-------------------------------- 36711 36712This describes file names in DBX format. 36713 36714 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 36715 A C statement to output DBX debugging information to the stdio 36716 stream STREAM, which indicates that file NAME is the main source 36717 file--the file specified as the input file for compilation. This 36718 macro is called only once, at the beginning of compilation. 36719 36720 This macro need not be defined if the standard form of output for 36721 DBX debugging information is appropriate. 36722 36723 It may be necessary to refer to a label equal to the beginning of 36724 the text section. You can use 'assemble_name (stream, 36725 ltext_label_name)' to do so. If you do this, you must also set the 36726 variable USED_LTEXT_LABEL_NAME to 'true'. 36727 36728 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 36729 Define this macro, with value 1, if GCC should not emit an 36730 indication of the current directory for compilation and current 36731 source language at the beginning of the file. 36732 36733 -- Macro: NO_DBX_GCC_MARKER 36734 Define this macro, with value 1, if GCC should not emit an 36735 indication that this object file was compiled by GCC. The default 36736 is to emit an 'N_OPT' stab at the beginning of every source file, 36737 with 'gcc2_compiled.' for the string and value 0. 36738 36739 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 36740 A C statement to output DBX debugging information at the end of 36741 compilation of the main source file NAME. Output should be written 36742 to the stdio stream STREAM. 36743 36744 If you don't define this macro, nothing special is output at the 36745 end of compilation, which is correct for most machines. 36746 36747 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 36748 Define this macro _instead of_ defining 36749 'DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 36750 the end of compilation is an 'N_SO' stab with an empty string, 36751 whose value is the highest absolute text address in the file. 36752 36753 36754File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 36755 3675617.21.5 Macros for SDB and DWARF Output 36757--------------------------------------- 36758 36759Here are macros for SDB and DWARF output. 36760 36761 -- Macro: SDB_DEBUGGING_INFO 36762 Define this macro to 1 if GCC should produce COFF-style debugging 36763 output for SDB in response to the '-g' option. 36764 36765 -- Macro: DWARF2_DEBUGGING_INFO 36766 Define this macro if GCC should produce dwarf version 2 format 36767 debugging output in response to the '-g' option. 36768 36769 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree 36770 FUNCTION) 36771 Define this to enable the dwarf attribute 36772 'DW_AT_calling_convention' to be emitted for each function. 36773 Instead of an integer return the enum value for the 'DW_CC_' 36774 tag. 36775 36776 To support optional call frame debugging information, you must also 36777 define 'INCOMING_RETURN_ADDR_RTX' and either set 36778 'RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 36779 prologue, or call 'dwarf2out_def_cfa' and 'dwarf2out_reg_save' as 36780 appropriate from 'TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 36781 36782 -- Macro: DWARF2_FRAME_INFO 36783 Define this macro to a nonzero value if GCC should always output 36784 Dwarf 2 frame information. If 'TARGET_EXCEPT_UNWIND_INFO' (*note 36785 Exception Region Output::) returns 'UI_DWARF2', and exceptions are 36786 enabled, GCC will output this information not matter how you define 36787 'DWARF2_FRAME_INFO'. 36788 36789 -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void) 36790 This hook defines the mechanism that will be used for describing 36791 frame unwind information to the debugger. Normally the hook will 36792 return 'UI_DWARF2' if DWARF 2 debug information is enabled, and 36793 return 'UI_NONE' otherwise. 36794 36795 A target may return 'UI_DWARF2' even when DWARF 2 debug information 36796 is disabled in order to always output DWARF 2 frame information. 36797 36798 A target may return 'UI_TARGET' if it has ABI specified unwind 36799 tables. This will suppress generation of the normal debug frame 36800 unwind information. 36801 36802 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 36803 Define this macro to be a nonzero value if the assembler can 36804 generate Dwarf 2 line debug info sections. This will result in 36805 much more compact line number tables, and hence is desirable if it 36806 works. 36807 36808 -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS 36809 True if the '.debug_pubtypes' and '.debug_pubnames' sections should 36810 be emitted. These sections are not used on most platforms, and in 36811 particular GDB does not use them. 36812 36813 -- Target Hook: bool TARGET_FORCE_AT_COMP_DIR 36814 True if the 'DW_AT_comp_dir' attribute should be emitted for each 36815 compilation unit. This attribute is required for the darwin linker 36816 to emit debug information. 36817 36818 -- Target Hook: bool TARGET_DELAY_SCHED2 36819 True if sched2 is not to be run at its normal place. This usually 36820 means it will be run as part of machine-specific reorg. 36821 36822 -- Target Hook: bool TARGET_DELAY_VARTRACK 36823 True if vartrack is not to be run at its normal place. This 36824 usually means it will be run as part of machine-specific reorg. 36825 36826 -- Target Hook: bool TARGET_NO_REGISTER_ALLOCATION 36827 True if register allocation and the passes following it should not 36828 be run. Usually true only for virtual assembler targets. 36829 36830 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 36831 A C statement to issue assembly directives that create a difference 36832 LAB1 minus LAB2, using an integer of the given SIZE. 36833 36834 -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2) 36835 A C statement to issue assembly directives that create a difference 36836 between the two given labels in system defined units, e.g. 36837 instruction slots on IA64 VMS, using an integer of the given size. 36838 36839 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, SECTION) 36840 A C statement to issue assembly directives that create a 36841 section-relative reference to the given LABEL, using an integer of 36842 the given SIZE. The label is known to be defined in the given 36843 SECTION. 36844 36845 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 36846 A C statement to issue assembly directives that create a 36847 self-relative reference to the given LABEL, using an integer of the 36848 given SIZE. 36849 36850 -- Macro: ASM_OUTPUT_DWARF_DATAREL (STREAM, SIZE, LABEL) 36851 A C statement to issue assembly directives that create a reference 36852 to the given LABEL relative to the dbase, using an integer of the 36853 given SIZE. 36854 36855 -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL) 36856 A C statement to issue assembly directives that create a reference 36857 to the DWARF table identifier LABEL from the current section. This 36858 is used on some systems to avoid garbage collecting a DWARF table 36859 which is referenced by a function. 36860 36861 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 36862 SIZE, rtx X) 36863 If defined, this target hook is a function which outputs a 36864 DTP-relative reference to the given TLS symbol of the specified 36865 size. 36866 36867 -- Macro: PUT_SDB_... 36868 Define these macros to override the assembler syntax for the 36869 special SDB assembler directives. See 'sdbout.c' for a list of 36870 these macros and their arguments. If the standard syntax is used, 36871 you need not define them yourself. 36872 36873 -- Macro: SDB_DELIM 36874 Some assemblers do not support a semicolon as a delimiter, even 36875 between SDB assembler directives. In that case, define this macro 36876 to be the delimiter to use (usually '\n'). It is not necessary to 36877 define a new set of 'PUT_SDB_OP' macros if this is the only change 36878 required. 36879 36880 -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES 36881 Define this macro to allow references to unknown structure, union, 36882 or enumeration tags to be emitted. Standard COFF does not allow 36883 handling of unknown references, MIPS ECOFF has support for it. 36884 36885 -- Macro: SDB_ALLOW_FORWARD_REFERENCES 36886 Define this macro to allow references to structure, union, or 36887 enumeration tags that have not yet been seen to be handled. Some 36888 assemblers choke if forward tags are used, while some require it. 36889 36890 -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE) 36891 A C statement to output SDB debugging information before code for 36892 line number LINE of the current source file to the stdio stream 36893 STREAM. The default is to emit an '.ln' directive. 36894 36895 36896File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info 36897 3689817.21.6 Macros for VMS Debug Format 36899----------------------------------- 36900 36901Here are macros for VMS debug format. 36902 36903 -- Macro: VMS_DEBUGGING_INFO 36904 Define this macro if GCC should produce debugging output for VMS in 36905 response to the '-g' option. The default behavior for VMS is to 36906 generate minimal debug info for a traceback in the absence of '-g' 36907 unless explicitly overridden with '-g0'. This behavior is 36908 controlled by 'TARGET_OPTION_OPTIMIZATION' and 36909 'TARGET_OPTION_OVERRIDE'. 36910 36911 36912File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 36913 3691417.22 Cross Compilation and Floating Point 36915========================================== 36916 36917While all modern machines use twos-complement representation for 36918integers, there are a variety of representations for floating point 36919numbers. This means that in a cross-compiler the representation of 36920floating point numbers in the compiled program may be different from 36921that used in the machine doing the compilation. 36922 36923 Because different representation systems may offer different amounts of 36924range and precision, all floating point constants must be represented in 36925the target machine's format. Therefore, the cross compiler cannot 36926safely use the host machine's floating point arithmetic; it must emulate 36927the target's arithmetic. To ensure consistency, GCC always uses 36928emulation to work with floating point values, even when the host and 36929target floating point formats are identical. 36930 36931 The following macros are provided by 'real.h' for the compiler to use. 36932All parts of the compiler which generate or optimize floating-point 36933calculations must use these macros. They may evaluate their operands 36934more than once, so operands must not have side effects. 36935 36936 -- Macro: REAL_VALUE_TYPE 36937 The C data type to be used to hold a floating point value in the 36938 target machine's format. Typically this is a 'struct' containing 36939 an array of 'HOST_WIDE_INT', but all code should treat it as an 36940 opaque quantity. 36941 36942 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 36943 Truncates X to a signed integer, rounding toward zero. 36944 36945 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 36946 (REAL_VALUE_TYPE X) 36947 Truncates X to an unsigned integer, rounding toward zero. If X is 36948 negative, returns zero. 36949 36950 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, 36951 machine_mode MODE) 36952 Converts STRING into a floating point number in the target 36953 machine's representation for mode MODE. This routine can handle 36954 both decimal and hexadecimal floating point constants, using the 36955 syntax defined by the C language for both. 36956 36957 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 36958 Returns 1 if X is negative (including negative zero), 0 otherwise. 36959 36960 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 36961 Determines whether X represents infinity (positive or negative). 36962 36963 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 36964 Determines whether X represents a "NaN" (not-a-number). 36965 36966 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 36967 Returns the negative of the floating point value X. 36968 36969 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 36970 Returns the absolute value of X. 36971 36972 36973File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 36974 3697517.23 Mode Switching Instructions 36976================================= 36977 36978The following macros control mode switching optimizations: 36979 36980 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 36981 Define this macro if the port needs extra instructions inserted for 36982 mode switching in an optimizing compilation. 36983 36984 For an example, the SH4 can perform both single and double 36985 precision floating point operations, but to perform a single 36986 precision operation, the FPSCR PR bit has to be cleared, while for 36987 a double precision operation, this bit has to be set. Changing the 36988 PR bit requires a general purpose register as a scratch register, 36989 hence these FPSCR sets have to be inserted before reload, i.e. you 36990 can't put this into instruction emitting or 36991 'TARGET_MACHINE_DEPENDENT_REORG'. 36992 36993 You can have multiple entities that are mode-switched, and select 36994 at run time which entities actually need it. 36995 'OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY that 36996 needs mode-switching. If you define this macro, you also have to 36997 define 'NUM_MODES_FOR_MODE_SWITCHING', 'TARGET_MODE_NEEDED', 36998 'TARGET_MODE_PRIORITY' and 'TARGET_MODE_EMIT'. 36999 'TARGET_MODE_AFTER', 'TARGET_MODE_ENTRY', and 'TARGET_MODE_EXIT' 37000 are optional. 37001 37002 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 37003 If you define 'OPTIMIZE_MODE_SWITCHING', you have to define this as 37004 initializer for an array of integers. Each initializer element N 37005 refers to an entity that needs mode switching, and specifies the 37006 number of different modes that might need to be set for this 37007 entity. The position of the initializer in the 37008 initializer--starting counting at zero--determines the integer that 37009 is used to refer to the mode-switched entity in question. In 37010 macros that take mode arguments / yield a mode result, modes are 37011 represented as numbers 0 ... N - 1. N is used to specify that no 37012 mode switch is needed / supplied. 37013 37014 -- Target Hook: void TARGET_MODE_EMIT (int ENTITY, int MODE, int 37015 PREV_MODE, HARD_REG_SET REGS_LIVE) 37016 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE is 37017 the set of hard registers live at the point where the insn(s) are 37018 to be inserted. PREV_MOXDE indicates the mode to switch from. 37019 Sets of a lower numbered entity will be emitted before sets of a 37020 higher numbered entity to a mode of the same or lower priority. 37021 37022 -- Target Hook: int TARGET_MODE_NEEDED (int ENTITY, rtx_insn *INSN) 37023 ENTITY is an integer specifying a mode-switched entity. If 37024 'OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 37025 return an integer value not larger than the corresponding element 37026 in 'NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 37027 must be switched into prior to the execution of INSN. 37028 37029 -- Target Hook: int TARGET_MODE_AFTER (int ENTITY, int MODE, rtx_insn 37030 *INSN) 37031 ENTITY is an integer specifying a mode-switched entity. If this 37032 macro is defined, it is evaluated for every INSN during mode 37033 switching. It determines the mode that an insn results in (if 37034 different from the incoming mode). 37035 37036 -- Target Hook: int TARGET_MODE_ENTRY (int ENTITY) 37037 If this macro is defined, it is evaluated for every ENTITY that 37038 needs mode switching. It should evaluate to an integer, which is a 37039 mode that ENTITY is assumed to be switched to at function entry. 37040 If 'TARGET_MODE_ENTRY' is defined then 'TARGET_MODE_EXIT' must be 37041 defined. 37042 37043 -- Target Hook: int TARGET_MODE_EXIT (int ENTITY) 37044 If this macro is defined, it is evaluated for every ENTITY that 37045 needs mode switching. It should evaluate to an integer, which is a 37046 mode that ENTITY is assumed to be switched to at function exit. If 37047 'TARGET_MODE_EXIT' is defined then 'TARGET_MODE_ENTRY' must be 37048 defined. 37049 37050 -- Target Hook: int TARGET_MODE_PRIORITY (int ENTITY, int N) 37051 This macro specifies the order in which modes for ENTITY are 37052 processed. 0 is the highest priority, 37053 'NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 37054 of the macro should be an integer designating a mode for ENTITY. 37055 For any fixed ENTITY, 'mode_priority' (ENTITY, N) shall be a 37056 bijection in 0 ... 'num_modes_for_mode_switching[ENTITY] - 1'. 37057 37058 37059File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros 37060 3706117.24 Defining target-specific uses of '__attribute__' 37062====================================================== 37063 37064Target-specific attributes may be defined for functions, data and types. 37065These are described using the following target hooks; they also need to 37066be documented in 'extend.texi'. 37067 37068 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 37069 If defined, this target hook points to an array of 'struct 37070 attribute_spec' (defined in 'tree-core.h') specifying the machine 37071 specific attributes for this target and some of the restrictions on 37072 the entities to which these attributes are applied and the 37073 arguments they take. 37074 37075 -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree 37076 NAME) 37077 If defined, this target hook is a function which returns true if 37078 the machine-specific attribute named NAME expects an identifier 37079 given as its first argument to be passed on as a plain identifier, 37080 not subjected to name lookup. If this is not defined, the default 37081 is false for all machine-specific attributes. 37082 37083 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1, 37084 const_tree TYPE2) 37085 If defined, this target hook is a function which returns zero if 37086 the attributes on TYPE1 and TYPE2 are incompatible, one if they are 37087 compatible, and two if they are nearly compatible (which causes a 37088 warning to be generated). If this is not defined, machine-specific 37089 attributes are supposed always to be compatible. 37090 37091 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 37092 If defined, this target hook is a function which assigns default 37093 attributes to the newly defined TYPE. 37094 37095 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 37096 TYPE2) 37097 Define this target hook if the merging of type attributes needs 37098 special handling. If defined, the result is a list of the combined 37099 'TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 37100 'comptypes' has already been called and returned 1. This function 37101 may call 'merge_attributes' to handle machine-independent merging. 37102 37103 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 37104 NEWDECL) 37105 Define this target hook if the merging of decl attributes needs 37106 special handling. If defined, the result is a list of the combined 37107 'DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 37108 declaration of OLDDECL. Examples of when this is needed are when 37109 one attribute overrides another, or when an attribute is nullified 37110 by a subsequent definition. This function may call 37111 'merge_attributes' to handle machine-independent merging. 37112 37113 If the only target-specific handling you require is 'dllimport' for 37114 Microsoft Windows targets, you should define the macro 37115 'TARGET_DLLIMPORT_DECL_ATTRIBUTES' to '1'. The compiler will then 37116 define a function called 'merge_dllimport_decl_attributes' which 37117 can then be defined as the expansion of 37118 'TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 37119 'handle_dll_attribute' in the attribute table for your port to 37120 perform initial processing of the 'dllimport' and 'dllexport' 37121 attributes. This is done in 'i386/cygwin.h' and 'i386/i386.c', for 37122 example. 37123 37124 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree 37125 DECL) 37126 DECL is a variable or function with '__attribute__((dllimport))' 37127 specified. Use this hook if the target needs to add extra 37128 validation checks to 'handle_dll_attribute'. 37129 37130 -- Macro: TARGET_DECLSPEC 37131 Define this macro to a nonzero value if you want to treat 37132 '__declspec(X)' as equivalent to '__attribute((X))'. By default, 37133 this behavior is enabled only for targets that define 37134 'TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 37135 '__declspec' is via a built-in macro, but you should not rely on 37136 this implementation detail. 37137 37138 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 37139 *ATTR_PTR) 37140 Define this target hook if you want to be able to add attributes to 37141 a decl when it is being created. This is normally useful for back 37142 ends which wish to implement a pragma by using the attributes which 37143 correspond to the pragma's effect. The NODE argument is the decl 37144 which is being created. The ATTR_PTR argument is a pointer to the 37145 attribute list for this decl. The list itself should not be 37146 modified, since it may be shared with other decls, but attributes 37147 may be chained on the head of the list and '*ATTR_PTR' modified to 37148 point to the new attributes, or a copy of the list may be made if 37149 further changes are needed. 37150 37151 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree 37152 FNDECL) 37153 This target hook returns 'true' if it is OK to inline FNDECL into 37154 the current function, despite its having target-specific 37155 attributes, 'false' otherwise. By default, if a function has a 37156 target specific attribute attached to it, it will not be inlined. 37157 37158 -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, tree 37159 NAME, tree ARGS, int FLAGS) 37160 This hook is called to parse 'attribute(target("..."))', which 37161 allows setting target-specific options on individual functions. 37162 These function-specific options may differ from the options 37163 specified on the command line. The hook should return 'true' if 37164 the options are valid. 37165 37166 The hook should set the 'DECL_FUNCTION_SPECIFIC_TARGET' field in 37167 the function declaration to hold a pointer to a target-specific 37168 'struct cl_target_option' structure. 37169 37170 -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR, 37171 struct gcc_options *OPTS) 37172 This hook is called to save any additional target-specific 37173 information in the 'struct cl_target_option' structure for 37174 function-specific options from the 'struct gcc_options' structure. 37175 *Note Option file format::. 37176 37177 -- Target Hook: void TARGET_OPTION_RESTORE (struct gcc_options *OPTS, 37178 struct cl_target_option *PTR) 37179 This hook is called to restore any additional target-specific 37180 information in the 'struct cl_target_option' structure for 37181 function-specific options to the 'struct gcc_options' structure. 37182 37183 -- Target Hook: void TARGET_OPTION_POST_STREAM_IN (struct 37184 cl_target_option *PTR) 37185 This hook is called to update target-specific information in the 37186 'struct cl_target_option' structure after it is streamed in from 37187 LTO bytecode. 37188 37189 -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT, 37190 struct cl_target_option *PTR) 37191 This hook is called to print any additional target-specific 37192 information in the 'struct cl_target_option' structure for 37193 function-specific options. 37194 37195 -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree 37196 POP_TARGET) 37197 This target hook parses the options for '#pragma GCC target', which 37198 sets the target-specific options for functions that occur later in 37199 the input stream. The options accepted should be the same as those 37200 handled by the 'TARGET_OPTION_VALID_ATTRIBUTE_P' hook. 37201 37202 -- Target Hook: void TARGET_OPTION_OVERRIDE (void) 37203 Sometimes certain combinations of command options do not make sense 37204 on a particular target machine. You can override the hook 37205 'TARGET_OPTION_OVERRIDE' to take account of this. This hooks is 37206 called once just after all the command options have been parsed. 37207 37208 Don't use this hook to turn on various extra optimizations for 37209 '-O'. That is what 'TARGET_OPTION_OPTIMIZATION' is for. 37210 37211 If you need to do something whenever the optimization level is 37212 changed via the optimize attribute or pragma, see 37213 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' 37214 37215 -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree 37216 DECL2) 37217 This target hook returns 'true' if DECL1 and DECL2 are versions of 37218 the same function. DECL1 and DECL2 are function versions if and 37219 only if they have the same function signature and different target 37220 specific attributes, that is, they are compiled for different 37221 target machines. 37222 37223 -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE) 37224 This target hook returns 'false' if the CALLER function cannot 37225 inline CALLEE, based on target specific information. By default, 37226 inlining is not allowed if the callee function has function 37227 specific target options and the caller does not use the same 37228 options. 37229 37230 -- Target Hook: void TARGET_RELAYOUT_FUNCTION (tree FNDECL) 37231 This target hook fixes function FNDECL after attributes are 37232 processed. Default does nothing. On ARM, the default function's 37233 alignment is updated with the attribute target. 37234 37235 37236File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros 37237 3723817.25 Emulating TLS 37239=================== 37240 37241For targets whose psABI does not provide Thread Local Storage via 37242specific relocations and instruction sequences, an emulation layer is 37243used. A set of target hooks allows this emulation layer to be 37244configured for the requirements of a particular target. For instance 37245the psABI may in fact specify TLS support in terms of an emulation 37246layer. 37247 37248 The emulation layer works by creating a control object for every TLS 37249object. To access the TLS object, a lookup function is provided which, 37250when given the address of the control object, will return the address of 37251the current thread's instance of the TLS object. 37252 37253 -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS 37254 Contains the name of the helper function that uses a TLS control 37255 object to locate a TLS instance. The default causes libgcc's 37256 emulated TLS helper function to be used. 37257 37258 -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON 37259 Contains the name of the helper function that should be used at 37260 program startup to register TLS objects that are implicitly 37261 initialized to zero. If this is 'NULL', all TLS objects will have 37262 explicit initializers. The default causes libgcc's emulated TLS 37263 registration function to be used. 37264 37265 -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION 37266 Contains the name of the section in which TLS control variables 37267 should be placed. The default of 'NULL' allows these to be placed 37268 in any section. 37269 37270 -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION 37271 Contains the name of the section in which TLS initializers should 37272 be placed. The default of 'NULL' allows these to be placed in any 37273 section. 37274 37275 -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX 37276 Contains the prefix to be prepended to TLS control variable names. 37277 The default of 'NULL' uses a target-specific prefix. 37278 37279 -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX 37280 Contains the prefix to be prepended to TLS initializer objects. 37281 The default of 'NULL' uses a target-specific prefix. 37282 37283 -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME) 37284 Specifies a function that generates the FIELD_DECLs for a TLS 37285 control object type. TYPE is the RECORD_TYPE the fields are for 37286 and NAME should be filled with the structure tag, if the default of 37287 '__emutls_object' is unsuitable. The default creates a type 37288 suitable for libgcc's emulated TLS function. 37289 37290 -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree 37291 TMPL_ADDR) 37292 Specifies a function that generates the CONSTRUCTOR to initialize a 37293 TLS control object. VAR is the TLS control object, DECL is the TLS 37294 object and TMPL_ADDR is the address of the initializer. The 37295 default initializes libgcc's emulated TLS control object. 37296 37297 -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED 37298 Specifies whether the alignment of TLS control variable objects is 37299 fixed and should not be increased as some backends may do to 37300 optimize single objects. The default is false. 37301 37302 -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS 37303 Specifies whether a DWARF 'DW_OP_form_tls_address' location 37304 descriptor may be used to describe emulated TLS control objects. 37305 37306 37307File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros 37308 3730917.26 Defining coprocessor specifics for MIPS targets. 37310====================================================== 37311 37312The MIPS specification allows MIPS implementations to have as many as 4 37313coprocessors, each with as many as 32 private registers. GCC supports 37314accessing these registers and transferring values between the registers 37315and memory using asm-ized variables. For example: 37316 37317 register unsigned int cp0count asm ("c0r1"); 37318 unsigned int d; 37319 37320 d = cp0count + 3; 37321 37322 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 37323names may be added as described below, or the default names may be 37324overridden entirely in 'SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 37325 37326 Coprocessor registers are assumed to be epilogue-used; sets to them 37327will be preserved even if it does not appear that the register is used 37328again later in the function. 37329 37330 Another note: according to the MIPS spec, coprocessor 1 (if present) is 37331the FPU. One accesses COP1 registers through standard mips 37332floating-point support; they are not included in this mechanism. 37333 37334 37335File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 37336 3733717.27 Parameters for Precompiled Header Validity Checking 37338========================================================= 37339 37340 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ) 37341 This hook returns a pointer to the data needed by 37342 'TARGET_PCH_VALID_P' and sets '*SZ' to the size of the data in 37343 bytes. 37344 37345 -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA, 37346 size_t SZ) 37347 This hook checks whether the options used to create a PCH file are 37348 compatible with the current settings. It returns 'NULL' if so and 37349 a suitable error message if not. Error messages will be presented 37350 to the user and must be localized using '_(MSG)'. 37351 37352 DATA is the data that was returned by 'TARGET_GET_PCH_VALIDITY' 37353 when the PCH file was created and SZ is the size of that data in 37354 bytes. It's safe to assume that the data was created by the same 37355 version of the compiler, so no format checking is needed. 37356 37357 The default definition of 'default_pch_valid_p' should be suitable 37358 for most targets. 37359 37360 -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int 37361 PCH_FLAGS) 37362 If this hook is nonnull, the default implementation of 37363 'TARGET_PCH_VALID_P' will use it to check for compatible values of 37364 'target_flags'. PCH_FLAGS specifies the value that 'target_flags' 37365 had when the PCH file was created. The return value is the same as 37366 for 'TARGET_PCH_VALID_P'. 37367 37368 -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void) 37369 Called before writing out a PCH file. If the target has some 37370 garbage-collected data that needs to be in a particular state on 37371 PCH loads, it can use this hook to enforce that state. Very few 37372 targets need to do anything here. 37373 37374 37375File: gccint.info, Node: C++ ABI, Next: Named Address Spaces, Prev: PCH Target, Up: Target Macros 37376 3737717.28 C++ ABI parameters 37378======================== 37379 37380 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 37381 Define this hook to override the integer type used for guard 37382 variables. These are used to implement one-time construction of 37383 static objects. The default is long_long_integer_type_node. 37384 37385 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 37386 This hook determines how guard variables are used. It should 37387 return 'false' (the default) if the first byte should be used. A 37388 return value of 'true' indicates that only the least significant 37389 bit should be used. 37390 37391 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 37392 This hook returns the size of the cookie to use when allocating an 37393 array whose elements have the indicated TYPE. Assumes that it is 37394 already known that a cookie is needed. The default is 'max(sizeof 37395 (size_t), alignof(type))', as defined in section 2.7 of the 37396 IA64/Generic C++ ABI. 37397 37398 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 37399 This hook should return 'true' if the element size should be stored 37400 in array cookies. The default is to return 'false'. 37401 37402 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 37403 IMPORT_EXPORT) 37404 If defined by a backend this hook allows the decision made to 37405 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 37406 contain 1 if the class is going to be exported, -1 if it is going 37407 to be imported and 0 otherwise. This function should return the 37408 modified value and perform any other actions necessary to support 37409 the backend's targeted operating system. 37410 37411 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 37412 This hook should return 'true' if constructors and destructors 37413 return the address of the object created/destroyed. The default is 37414 to return 'false'. 37415 37416 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 37417 This hook returns true if the key method for a class (i.e., the 37418 method which, if defined in the current translation unit, causes 37419 the virtual table to be emitted) may be an inline function. Under 37420 the standard Itanium C++ ABI the key method may be an inline 37421 function so long as the function is not declared inline in the 37422 class definition. Under some variants of the ABI, an inline 37423 function can never be the key method. The default is to return 37424 'true'. 37425 37426 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 37427 DECL) 37428 DECL is a virtual table, virtual table table, typeinfo object, or 37429 other similar implicit class data object that will be emitted with 37430 external linkage in this translation unit. No ELF visibility has 37431 been explicitly specified. If the target needs to specify a 37432 visibility other than that of the containing class, use this hook 37433 to set 'DECL_VISIBILITY' and 'DECL_VISIBILITY_SPECIFIED'. 37434 37435 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 37436 This hook returns true (the default) if virtual tables and other 37437 similar implicit class data objects are always COMDAT if they have 37438 external linkage. If this hook returns false, then class data for 37439 classes whose virtual table will be emitted in only one translation 37440 unit will not be COMDAT. 37441 37442 -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void) 37443 This hook returns true (the default) if the RTTI information for 37444 the basic types which is defined in the C++ runtime should always 37445 be COMDAT, false if it should not be COMDAT. 37446 37447 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 37448 This hook returns true if '__aeabi_atexit' (as defined by the ARM 37449 EABI) should be used to register static destructors when 37450 '-fuse-cxa-atexit' is in effect. The default is to return false to 37451 use '__cxa_atexit'. 37452 37453 -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void) 37454 This hook returns true if the target 'atexit' function can be used 37455 in the same manner as '__cxa_atexit' to register C++ static 37456 destructors. This requires that 'atexit'-registered functions in 37457 shared libraries are run in the correct order when the libraries 37458 are unloaded. The default is to return false. 37459 37460 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 37461 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has just 37462 been defined. Use this hook to make adjustments to the class (eg, 37463 tweak visibility or perform any other required target 37464 modifications). 37465 37466 -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL) 37467 Return target-specific mangling context of DECL or 'NULL_TREE'. 37468 37469 37470File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: C++ ABI, Up: Target Macros 37471 3747217.29 Adding support for named address spaces 37473============================================= 37474 37475The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards 37476committee, 'Programming Languages - C - Extensions to support embedded 37477processors', specifies a syntax for embedded processors to specify 37478alternate address spaces. You can configure a GCC port to support 37479section 5.1 of the draft report to add support for address spaces other 37480than the default address space. These address spaces are new keywords 37481that are similar to the 'volatile' and 'const' type attributes. 37482 37483 Pointers to named address spaces can have a different size than 37484pointers to the generic address space. 37485 37486 For example, the SPU port uses the '__ea' address space to refer to 37487memory in the host processor, rather than memory local to the SPU 37488processor. Access to memory in the '__ea' address space involves 37489issuing DMA operations to move data between the host processor and the 37490local processor memory address space. Pointers in the '__ea' address 37491space are either 32 bits or 64 bits based on the '-mea32' or '-mea64' 37492switches (native SPU pointers are always 32 bits). 37493 37494 Internally, address spaces are represented as a small integer in the 37495range 0 to 15 with address space 0 being reserved for the generic 37496address space. 37497 37498 To register a named address space qualifier keyword with the C front 37499end, the target may call the 'c_register_addr_space' routine. For 37500example, the SPU port uses the following to declare '__ea' as the 37501keyword for named address space #1: 37502 #define ADDR_SPACE_EA 1 37503 c_register_addr_space ("__ea", ADDR_SPACE_EA); 37504 37505 -- Target Hook: machine_mode TARGET_ADDR_SPACE_POINTER_MODE 37506 (addr_space_t ADDRESS_SPACE) 37507 Define this to return the machine mode to use for pointers to 37508 ADDRESS_SPACE if the target supports named address spaces. The 37509 default version of this hook returns 'ptr_mode'. 37510 37511 -- Target Hook: machine_mode TARGET_ADDR_SPACE_ADDRESS_MODE 37512 (addr_space_t ADDRESS_SPACE) 37513 Define this to return the machine mode to use for addresses in 37514 ADDRESS_SPACE if the target supports named address spaces. The 37515 default version of this hook returns 'Pmode'. 37516 37517 -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE (machine_mode 37518 MODE, addr_space_t AS) 37519 Define this to return nonzero if the port can handle pointers with 37520 machine mode MODE to address space AS. This target hook is the 37521 same as the 'TARGET_VALID_POINTER_MODE' target hook, except that it 37522 includes explicit named address space support. The default version 37523 of this hook returns true for the modes returned by either the 37524 'TARGET_ADDR_SPACE_POINTER_MODE' or 37525 'TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given address 37526 space. 37527 37528 -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P 37529 (machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS) 37530 Define this to return true if EXP is a valid address for mode MODE 37531 in the named address space AS. The STRICT parameter says whether 37532 strict addressing is in effect after reload has finished. This 37533 target hook is the same as the 'TARGET_LEGITIMATE_ADDRESS_P' target 37534 hook, except that it includes explicit named address space support. 37535 37536 -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx 37537 OLDX, machine_mode MODE, addr_space_t AS) 37538 Define this to modify an invalid address X to be a valid address 37539 with mode MODE in the named address space AS. This target hook is 37540 the same as the 'TARGET_LEGITIMIZE_ADDRESS' target hook, except 37541 that it includes explicit named address space support. 37542 37543 -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET, 37544 addr_space_t SUPERSET) 37545 Define this to return whether the SUBSET named address space is 37546 contained within the SUPERSET named address space. Pointers to a 37547 named address space that is a subset of another named address space 37548 will be converted automatically without a cast if used together in 37549 arithmetic operations. Pointers to a superset address space can be 37550 converted to pointers to a subset address space via explicit casts. 37551 37552 -- Target Hook: bool TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID (addr_space_t 37553 AS) 37554 Define this to modify the default handling of address 0 for the 37555 address space. Return true if 0 should be considered a valid 37556 address. 37557 37558 -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE, 37559 tree TO_TYPE) 37560 Define this to convert the pointer expression represented by the 37561 RTL OP with type FROM_TYPE that points to a named address space to 37562 a new pointer expression with type TO_TYPE that points to a 37563 different named address space. When this hook it called, it is 37564 guaranteed that one of the two address spaces is a subset of the 37565 other, as determined by the 'TARGET_ADDR_SPACE_SUBSET_P' target 37566 hook. 37567 37568 -- Target Hook: int TARGET_ADDR_SPACE_DEBUG (addr_space_t AS) 37569 Define this to define how the address space is encoded in dwarf. 37570 The result is the value to be used with 'DW_AT_address_class'. 37571 37572 37573File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros 37574 3757517.30 Miscellaneous Parameters 37576============================== 37577 37578Here are several miscellaneous parameters. 37579 37580 -- Macro: HAS_LONG_COND_BRANCH 37581 Define this boolean macro to indicate whether or not your 37582 architecture has conditional branches that can span all of memory. 37583 It is used in conjunction with an optimization that partitions hot 37584 and cold basic blocks into separate sections of the executable. If 37585 this macro is set to false, gcc will convert any conditional 37586 branches that attempt to cross between sections into unconditional 37587 branches or indirect jumps. 37588 37589 -- Macro: HAS_LONG_UNCOND_BRANCH 37590 Define this boolean macro to indicate whether or not your 37591 architecture has unconditional branches that can span all of 37592 memory. It is used in conjunction with an optimization that 37593 partitions hot and cold basic blocks into separate sections of the 37594 executable. If this macro is set to false, gcc will convert any 37595 unconditional branches that attempt to cross between sections into 37596 indirect jumps. 37597 37598 -- Macro: CASE_VECTOR_MODE 37599 An alias for a machine mode name. This is the machine mode that 37600 elements of a jump-table should have. 37601 37602 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 37603 Optional: return the preferred mode for an 'addr_diff_vec' when the 37604 minimum and maximum offset are known. If you define this, it 37605 enables extra code in branch shortening to deal with 37606 'addr_diff_vec'. To make this work, you also have to define 37607 'INSN_ALIGN' and make the alignment for 'addr_diff_vec' explicit. 37608 The BODY argument is provided so that the offset_unsigned and scale 37609 flags can be updated. 37610 37611 -- Macro: CASE_VECTOR_PC_RELATIVE 37612 Define this macro to be a C expression to indicate when jump-tables 37613 should contain relative addresses. You need not define this macro 37614 if jump-tables never contain relative addresses, or jump-tables 37615 should contain relative addresses only when '-fPIC' or '-fPIC' is 37616 in effect. 37617 37618 -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void) 37619 This function return the smallest number of different values for 37620 which it is best to use a jump-table instead of a tree of 37621 conditional branches. The default is four for machines with a 37622 'casesi' instruction and five otherwise. This is best for most 37623 machines. 37624 37625 -- Macro: WORD_REGISTER_OPERATIONS 37626 Define this macro to 1 if operations between registers with 37627 integral mode smaller than a word are always performed on the 37628 entire register. Most RISC machines have this property and most 37629 CISC machines do not. 37630 37631 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 37632 Define this macro to be a C expression indicating when insns that 37633 read memory in MEM_MODE, an integral mode narrower than a word, set 37634 the bits outside of MEM_MODE to be either the sign-extension or the 37635 zero-extension of the data read. Return 'SIGN_EXTEND' for values 37636 of MEM_MODE for which the insn sign-extends, 'ZERO_EXTEND' for 37637 which it zero-extends, and 'UNKNOWN' for other modes. 37638 37639 This macro is not called with MEM_MODE non-integral or with a width 37640 greater than or equal to 'BITS_PER_WORD', so you may return any 37641 value in this case. Do not define this macro if it would always 37642 return 'UNKNOWN'. On machines where this macro is defined, you 37643 will normally define it as the constant 'SIGN_EXTEND' or 37644 'ZERO_EXTEND'. 37645 37646 You may return a non-'UNKNOWN' value even if for some hard 37647 registers the sign extension is not performed, if for the 37648 'REGNO_REG_CLASS' of these hard registers 37649 'CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is 37650 MEM_MODE and the TO mode is any integral mode larger than this but 37651 not larger than 'word_mode'. 37652 37653 You must return 'UNKNOWN' if for some hard registers that allow 37654 this mode, 'CANNOT_CHANGE_MODE_CLASS' says that they cannot change 37655 to 'word_mode', but that they can change to another integral mode 37656 that is larger then MEM_MODE but still smaller than 'word_mode'. 37657 37658 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 37659 Define this macro to 1 if loading short immediate values into 37660 registers sign extends. 37661 37662 -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL 37663 (machine_mode MODE) 37664 When '-ffast-math' is in effect, GCC tries to optimize divisions by 37665 the same divisor, by turning them into multiplications by the 37666 reciprocal. This target hook specifies the minimum number of 37667 divisions that should be there for GCC to perform the optimization 37668 for a variable of mode MODE. The default implementation returns 3 37669 if the machine has an instruction for the division, and 2 if it 37670 does not. 37671 37672 -- Macro: MOVE_MAX 37673 The maximum number of bytes that a single instruction can move 37674 quickly between memory and registers or between two memory 37675 locations. 37676 37677 -- Macro: MAX_MOVE_MAX 37678 The maximum number of bytes that a single instruction can move 37679 quickly between memory and registers or between two memory 37680 locations. If this is undefined, the default is 'MOVE_MAX'. 37681 Otherwise, it is the constant value that is the largest value that 37682 'MOVE_MAX' can have at run-time. 37683 37684 -- Macro: SHIFT_COUNT_TRUNCATED 37685 A C expression that is nonzero if on this machine the number of 37686 bits actually used for the count of a shift operation is equal to 37687 the number of bits needed to represent the size of the object being 37688 shifted. When this macro is nonzero, the compiler will assume that 37689 it is safe to omit a sign-extend, zero-extend, and certain bitwise 37690 'and' instructions that truncates the count of a shift operation. 37691 On machines that have instructions that act on bit-fields at 37692 variable positions, which may include 'bit test' instructions, a 37693 nonzero 'SHIFT_COUNT_TRUNCATED' also enables deletion of 37694 truncations of the values that serve as arguments to bit-field 37695 instructions. 37696 37697 If both types of instructions truncate the count (for shifts) and 37698 position (for bit-field operations), or if no variable-position 37699 bit-field instructions exist, you should define this macro. 37700 37701 However, on some machines, such as the 80386 and the 680x0, 37702 truncation only applies to shift operations and not the (real or 37703 pretended) bit-field operations. Define 'SHIFT_COUNT_TRUNCATED' to 37704 be zero on such machines. Instead, add patterns to the 'md' file 37705 that include the implied truncation of the shift instructions. 37706 37707 You need not define this macro if it would always have the value of 37708 zero. 37709 37710 -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK 37711 (machine_mode MODE) 37712 This function describes how the standard shift patterns for MODE 37713 deal with shifts by negative amounts or by more than the width of 37714 the mode. *Note shift patterns::. 37715 37716 On many machines, the shift patterns will apply a mask M to the 37717 shift count, meaning that a fixed-width shift of X by Y is 37718 equivalent to an arbitrary-width shift of X by Y & M. If this is 37719 true for mode MODE, the function should return M, otherwise it 37720 should return 0. A return value of 0 indicates that no particular 37721 behavior is guaranteed. 37722 37723 Note that, unlike 'SHIFT_COUNT_TRUNCATED', this function does _not_ 37724 apply to general shift rtxes; it applies only to instructions that 37725 are generated by the named shift patterns. 37726 37727 The default implementation of this function returns 37728 'GET_MODE_BITSIZE (MODE) - 1' if 'SHIFT_COUNT_TRUNCATED' and 0 37729 otherwise. This definition is always safe, but if 37730 'SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 37731 nevertheless truncate the shift count, you may get better code by 37732 overriding it. 37733 37734 -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC) 37735 A C expression which is nonzero if on this machine it is safe to 37736 "convert" an integer of INPREC bits to one of OUTPREC bits (where 37737 OUTPREC is smaller than INPREC) by merely operating on it as if it 37738 had only OUTPREC bits. 37739 37740 On many machines, this expression can be 1. 37741 37742 When 'TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for 37743 modes for which 'MODES_TIEABLE_P' is 0, suboptimal code can result. 37744 If this is the case, making 'TRULY_NOOP_TRUNCATION' return 0 in 37745 such cases may improve things. 37746 37747 -- Target Hook: int TARGET_MODE_REP_EXTENDED (machine_mode MODE, 37748 machine_mode REP_MODE) 37749 The representation of an integral mode can be such that the values 37750 are always extended to a wider integral mode. Return 'SIGN_EXTEND' 37751 if values of MODE are represented in sign-extended form to 37752 REP_MODE. Return 'UNKNOWN' otherwise. (Currently, none of the 37753 targets use zero-extended representation this way so unlike 37754 'LOAD_EXTEND_OP', 'TARGET_MODE_REP_EXTENDED' is expected to return 37755 either 'SIGN_EXTEND' or 'UNKNOWN'. Also no target extends MODE to 37756 REP_MODE so that REP_MODE is not the next widest integral mode and 37757 currently we take advantage of this fact.) 37758 37759 Similarly to 'LOAD_EXTEND_OP' you may return a non-'UNKNOWN' value 37760 even if the extension is not performed on certain hard registers as 37761 long as for the 'REGNO_REG_CLASS' of these hard registers 37762 'CANNOT_CHANGE_MODE_CLASS' returns nonzero. 37763 37764 Note that 'TARGET_MODE_REP_EXTENDED' and 'LOAD_EXTEND_OP' describe 37765 two related properties. If you define 'TARGET_MODE_REP_EXTENDED 37766 (mode, word_mode)' you probably also want to define 'LOAD_EXTEND_OP 37767 (mode)' to return the same type of extension. 37768 37769 In order to enforce the representation of 'mode', 37770 'TRULY_NOOP_TRUNCATION' should return false when truncating to 37771 'mode'. 37772 37773 -- Macro: STORE_FLAG_VALUE 37774 A C expression describing the value returned by a comparison 37775 operator with an integral mode and stored by a store-flag 37776 instruction ('cstoreMODE4') when the condition is true. This 37777 description must apply to _all_ the 'cstoreMODE4' patterns and all 37778 the comparison operators whose results have a 'MODE_INT' mode. 37779 37780 A value of 1 or -1 means that the instruction implementing the 37781 comparison operator returns exactly 1 or -1 when the comparison is 37782 true and 0 when the comparison is false. Otherwise, the value 37783 indicates which bits of the result are guaranteed to be 1 when the 37784 comparison is true. This value is interpreted in the mode of the 37785 comparison operation, which is given by the mode of the first 37786 operand in the 'cstoreMODE4' pattern. Either the low bit or the 37787 sign bit of 'STORE_FLAG_VALUE' be on. Presently, only those bits 37788 are used by the compiler. 37789 37790 If 'STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 37791 generate code that depends only on the specified bits. It can also 37792 replace comparison operators with equivalent operations if they 37793 cause the required bits to be set, even if the remaining bits are 37794 undefined. For example, on a machine whose comparison operators 37795 return an 'SImode' value and where 'STORE_FLAG_VALUE' is defined as 37796 '0x80000000', saying that just the sign bit is relevant, the 37797 expression 37798 37799 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 37800 37801 can be converted to 37802 37803 (ashift:SI X (const_int N)) 37804 37805 where N is the appropriate shift count to move the bit being tested 37806 into the sign bit. 37807 37808 There is no way to describe a machine that always sets the 37809 low-order bit for a true value, but does not guarantee the value of 37810 any other bits, but we do not know of any machine that has such an 37811 instruction. If you are trying to port GCC to such a machine, 37812 include an instruction to perform a logical-and of the result with 37813 1 in the pattern for the comparison operators and let us know at 37814 <gcc@gcc.gnu.org>. 37815 37816 Often, a machine will have multiple instructions that obtain a 37817 value from a comparison (or the condition codes). Here are rules 37818 to guide the choice of value for 'STORE_FLAG_VALUE', and hence the 37819 instructions to be used: 37820 37821 * Use the shortest sequence that yields a valid definition for 37822 'STORE_FLAG_VALUE'. It is more efficient for the compiler to 37823 "normalize" the value (convert it to, e.g., 1 or 0) than for 37824 the comparison operators to do so because there may be 37825 opportunities to combine the normalization with other 37826 operations. 37827 37828 * For equal-length sequences, use a value of 1 or -1, with -1 37829 being slightly preferred on machines with expensive jumps and 37830 1 preferred on other machines. 37831 37832 * As a second choice, choose a value of '0x80000001' if 37833 instructions exist that set both the sign and low-order bits 37834 but do not define the others. 37835 37836 * Otherwise, use a value of '0x80000000'. 37837 37838 Many machines can produce both the value chosen for 37839 'STORE_FLAG_VALUE' and its negation in the same number of 37840 instructions. On those machines, you should also define a pattern 37841 for those cases, e.g., one matching 37842 37843 (set A (neg:M (ne:M B C))) 37844 37845 Some machines can also perform 'and' or 'plus' operations on 37846 condition code values with less instructions than the corresponding 37847 'cstoreMODE4' insn followed by 'and' or 'plus'. On those machines, 37848 define the appropriate patterns. Use the names 'incscc' and 37849 'decscc', respectively, for the patterns which perform 'plus' or 37850 'minus' operations on condition code values. See 'rs6000.md' for 37851 some examples. The GNU Superoptimizer can be used to find such 37852 instruction sequences on other machines. 37853 37854 If this macro is not defined, the default value, 1, is used. You 37855 need not define 'STORE_FLAG_VALUE' if the machine has no store-flag 37856 instructions, or if the value generated by these instructions is 1. 37857 37858 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 37859 A C expression that gives a nonzero 'REAL_VALUE_TYPE' value that is 37860 returned when comparison operators with floating-point results are 37861 true. Define this macro on machines that have comparison 37862 operations that return floating-point values. If there are no such 37863 operations, do not define this macro. 37864 37865 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 37866 A C expression that gives a rtx representing the nonzero true 37867 element for vector comparisons. The returned rtx should be valid 37868 for the inner mode of MODE which is guaranteed to be a vector mode. 37869 Define this macro on machines that have vector comparison 37870 operations that return a vector result. If there are no such 37871 operations, do not define this macro. Typically, this macro is 37872 defined as 'const1_rtx' or 'constm1_rtx'. This macro may return 37873 'NULL_RTX' to prevent the compiler optimizing such vector 37874 comparison operations for the given mode. 37875 37876 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 37877 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 37878 A C expression that indicates whether the architecture defines a 37879 value for 'clz' or 'ctz' with a zero operand. A result of '0' 37880 indicates the value is undefined. If the value is defined for only 37881 the RTL expression, the macro should evaluate to '1'; if the value 37882 applies also to the corresponding optab entry (which is normally 37883 the case if it expands directly into the corresponding RTL), then 37884 the macro should evaluate to '2'. In the cases where the value is 37885 defined, VALUE should be set to this value. 37886 37887 If this macro is not defined, the value of 'clz' or 'ctz' at zero 37888 is assumed to be undefined. 37889 37890 This macro must be defined if the target's expansion for 'ffs' 37891 relies on a particular value to get correct results. Otherwise it 37892 is not necessary, though it may be used to optimize some corner 37893 cases, and to provide a default expansion for the 'ffs' optab. 37894 37895 Note that regardless of this macro the "definedness" of 'clz' and 37896 'ctz' at zero do _not_ extend to the builtin functions visible to 37897 the user. Thus one may be free to adjust the value at will to 37898 match the target expansion of these operations without fear of 37899 breaking the API. 37900 37901 -- Macro: Pmode 37902 An alias for the machine mode for pointers. On most machines, 37903 define this to be the integer mode corresponding to the width of a 37904 hardware pointer; 'SImode' on 32-bit machine or 'DImode' on 64-bit 37905 machines. On some machines you must define this to be one of the 37906 partial integer modes, such as 'PSImode'. 37907 37908 The width of 'Pmode' must be at least as large as the value of 37909 'POINTER_SIZE'. If it is not equal, you must define the macro 37910 'POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 37911 'Pmode'. 37912 37913 -- Macro: FUNCTION_MODE 37914 An alias for the machine mode used for memory references to 37915 functions being called, in 'call' RTL expressions. On most CISC 37916 machines, where an instruction can begin at any byte address, this 37917 should be 'QImode'. On most RISC machines, where all instructions 37918 have fixed size and alignment, this should be a mode with the same 37919 size and alignment as the machine instruction words - typically 37920 'SImode' or 'HImode'. 37921 37922 -- Macro: STDC_0_IN_SYSTEM_HEADERS 37923 In normal operation, the preprocessor expands '__STDC__' to the 37924 constant 1, to signify that GCC conforms to ISO Standard C. On 37925 some hosts, like Solaris, the system compiler uses a different 37926 convention, where '__STDC__' is normally 0, but is 1 if the user 37927 specifies strict conformance to the C Standard. 37928 37929 Defining 'STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 37930 convention when processing system header files, but when processing 37931 user files '__STDC__' will always expand to 1. 37932 37933 -- C Target Hook: const char * TARGET_C_PREINCLUDE (void) 37934 Define this hook to return the name of a header file to be included 37935 at the start of all compilations, as if it had been included with 37936 '#include <FILE>'. If this hook returns 'NULL', or is not defined, 37937 or the header is not found, or if the user specifies 37938 '-ffreestanding' or '-nostdinc', no header is included. 37939 37940 This hook can be used together with a header provided by the system 37941 C library to implement ISO C requirements for certain macros to be 37942 predefined that describe properties of the whole implementation 37943 rather than just the compiler. 37944 37945 -- C Target Hook: bool TARGET_CXX_IMPLICIT_EXTERN_C (const char*) 37946 Define this hook to add target-specific C++ implicit extern C 37947 functions. If this function returns true for the name of a 37948 file-scope function, that function implicitly gets extern "C" 37949 linkage rather than whatever language linkage the declaration would 37950 normally have. An example of such function is WinMain on Win32 37951 targets. 37952 37953 -- Macro: NO_IMPLICIT_EXTERN_C 37954 Define this macro if the system header files support C++ as well as 37955 C. This macro inhibits the usual method of using system header 37956 files in C++, which is to pretend that the file's contents are 37957 enclosed in 'extern "C" {...}'. 37958 37959 -- Macro: REGISTER_TARGET_PRAGMAS () 37960 Define this macro if you want to implement any target-specific 37961 pragmas. If defined, it is a C expression which makes a series of 37962 calls to 'c_register_pragma' or 'c_register_pragma_with_expansion' 37963 for each pragma. The macro may also do any setup required for the 37964 pragmas. 37965 37966 The primary reason to define this macro is to provide compatibility 37967 with other compilers for the same target. In general, we 37968 discourage definition of target-specific pragmas for GCC. 37969 37970 If the pragma can be implemented by attributes then you should 37971 consider defining the target hook 'TARGET_INSERT_ATTRIBUTES' as 37972 well. 37973 37974 Preprocessor macros that appear on pragma lines are not expanded. 37975 All '#pragma' directives that do not match any registered pragma 37976 are silently ignored, unless the user specifies 37977 '-Wunknown-pragmas'. 37978 37979 -- Function: void c_register_pragma (const char *SPACE, const char 37980 *NAME, void (*CALLBACK) (struct cpp_reader *)) 37981 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 37982 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 37983 37984 Each call to 'c_register_pragma' or 37985 'c_register_pragma_with_expansion' establishes one pragma. The 37986 CALLBACK routine will be called when the preprocessor encounters a 37987 pragma of the form 37988 37989 #pragma [SPACE] NAME ... 37990 37991 SPACE is the case-sensitive namespace of the pragma, or 'NULL' to 37992 put the pragma in the global namespace. The callback routine 37993 receives PFILE as its first argument, which can be passed on to 37994 cpplib's functions if necessary. You can lex tokens after the NAME 37995 by calling 'pragma_lex'. Tokens that are not read by the callback 37996 will be silently ignored. The end of the line is indicated by a 37997 token of type 'CPP_EOF'. Macro expansion occurs on the arguments 37998 of pragmas registered with 'c_register_pragma_with_expansion' but 37999 not on the arguments of pragmas registered with 38000 'c_register_pragma'. 38001 38002 Note that the use of 'pragma_lex' is specific to the C and C++ 38003 compilers. It will not work in the Java or Fortran compilers, or 38004 any other language compilers for that matter. Thus if 'pragma_lex' 38005 is going to be called from target-specific code, it must only be 38006 done so when building the C and C++ compilers. This can be done by 38007 defining the variables 'c_target_objs' and 'cxx_target_objs' in the 38008 target entry in the 'config.gcc' file. These variables should name 38009 the target-specific, language-specific object file which contains 38010 the code that uses 'pragma_lex'. Note it will also be necessary to 38011 add a rule to the makefile fragment pointed to by 'tmake_file' that 38012 shows how to build this object file. 38013 38014 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 38015 Define this macro if macros should be expanded in the arguments of 38016 '#pragma pack'. 38017 38018 -- Macro: TARGET_DEFAULT_PACK_STRUCT 38019 If your target requires a structure packing default other than 0 38020 (meaning the machine default), define this macro to the necessary 38021 value (in bytes). This must be a value that would also be valid to 38022 use with '#pragma pack()' (that is, a small power of two). 38023 38024 -- Macro: DOLLARS_IN_IDENTIFIERS 38025 Define this macro to control use of the character '$' in identifier 38026 names for the C family of languages. 0 means '$' is not allowed by 38027 default; 1 means it is allowed. 1 is the default; there is no need 38028 to define this macro in that case. 38029 38030 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 38031 Define this macro as a C expression that is nonzero if it is safe 38032 for the delay slot scheduler to place instructions in the delay 38033 slot of INSN, even if they appear to use a resource set or 38034 clobbered in INSN. INSN is always a 'jump_insn' or an 'insn'; GCC 38035 knows that every 'call_insn' has this behavior. On machines where 38036 some 'insn' or 'jump_insn' is really a function call and hence has 38037 this behavior, you should define this macro. 38038 38039 You need not define this macro if it would always return zero. 38040 38041 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 38042 Define this macro as a C expression that is nonzero if it is safe 38043 for the delay slot scheduler to place instructions in the delay 38044 slot of INSN, even if they appear to set or clobber a resource 38045 referenced in INSN. INSN is always a 'jump_insn' or an 'insn'. On 38046 machines where some 'insn' or 'jump_insn' is really a function call 38047 and its operands are registers whose use is actually in the 38048 subroutine it calls, you should define this macro. Doing so allows 38049 the delay slot scheduler to move instructions which copy arguments 38050 into the argument registers into the delay slot of INSN. 38051 38052 You need not define this macro if it would always return zero. 38053 38054 -- Macro: MULTIPLE_SYMBOL_SPACES 38055 Define this macro as a C expression that is nonzero if, in some 38056 cases, global symbols from one translation unit may not be bound to 38057 undefined symbols in another translation unit without user 38058 intervention. For instance, under Microsoft Windows symbols must 38059 be explicitly imported from shared libraries (DLLs). 38060 38061 You need not define this macro if it would always evaluate to zero. 38062 38063 -- Target Hook: rtx_insn * TARGET_MD_ASM_ADJUST (vec<rtx>& OUTPUTS, 38064 vec<rtx>& INPUTS, vec<const char *>& CONSTRAINTS, vec<rtx>& 38065 CLOBBERS, HARD_REG_SET& CLOBBERED_REGS) 38066 This target hook may add "clobbers" to CLOBBERS and CLOBBERED_REGS 38067 for any hard regs the port wishes to automatically clobber for an 38068 asm. The OUTPUTS and INPUTS may be inspected to avoid clobbering a 38069 register that is already used by the asm. 38070 38071 It may modify the OUTPUTS, INPUTS, and CONSTRAINTS as necessary for 38072 other pre-processing. In this case the return value is a sequence 38073 of insns to emit after the asm. 38074 38075 -- Macro: MATH_LIBRARY 38076 Define this macro as a C string constant for the linker argument to 38077 link in the system math library, minus the initial '"-l"', or '""' 38078 if the target does not have a separate math library. 38079 38080 You need only define this macro if the default of '"m"' is wrong. 38081 38082 -- Macro: LIBRARY_PATH_ENV 38083 Define this macro as a C string constant for the environment 38084 variable that specifies where the linker should look for libraries. 38085 38086 You need only define this macro if the default of '"LIBRARY_PATH"' 38087 is wrong. 38088 38089 -- Macro: TARGET_POSIX_IO 38090 Define this macro if the target supports the following POSIX file 38091 functions, access, mkdir and file locking with fcntl / F_SETLKW. 38092 Defining 'TARGET_POSIX_IO' will enable the test coverage code to 38093 use file locking when exiting a program, which avoids race 38094 conditions if the program has forked. It will also create 38095 directories at run-time for cross-profiling. 38096 38097 -- Macro: MAX_CONDITIONAL_EXECUTE 38098 38099 A C expression for the maximum number of instructions to execute 38100 via conditional execution instructions instead of a branch. A 38101 value of 'BRANCH_COST'+1 is the default if the machine does not use 38102 cc0, and 1 if it does use cc0. 38103 38104 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 38105 Used if the target needs to perform machine-dependent modifications 38106 on the conditionals used for turning basic blocks into 38107 conditionally executed code. CE_INFO points to a data structure, 38108 'struct ce_if_block', which contains information about the 38109 currently processed blocks. TRUE_EXPR and FALSE_EXPR are the tests 38110 that are used for converting the then-block and the else-block, 38111 respectively. Set either TRUE_EXPR or FALSE_EXPR to a null pointer 38112 if the tests cannot be converted. 38113 38114 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 38115 FALSE_EXPR) 38116 Like 'IFCVT_MODIFY_TESTS', but used when converting more 38117 complicated if-statements into conditions combined by 'and' and 38118 'or' operations. BB contains the basic block that contains the 38119 test that is currently being processed and about to be turned into 38120 a condition. 38121 38122 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 38123 A C expression to modify the PATTERN of an INSN that is to be 38124 converted to conditional execution format. CE_INFO points to a 38125 data structure, 'struct ce_if_block', which contains information 38126 about the currently processed blocks. 38127 38128 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 38129 A C expression to perform any final machine dependent modifications 38130 in converting code to conditional execution. The involved basic 38131 blocks can be found in the 'struct ce_if_block' structure that is 38132 pointed to by CE_INFO. 38133 38134 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 38135 A C expression to cancel any machine dependent modifications in 38136 converting code to conditional execution. The involved basic 38137 blocks can be found in the 'struct ce_if_block' structure that is 38138 pointed to by CE_INFO. 38139 38140 -- Macro: IFCVT_MACHDEP_INIT (CE_INFO) 38141 A C expression to initialize any machine specific data for 38142 if-conversion of the if-block in the 'struct ce_if_block' structure 38143 that is pointed to by CE_INFO. 38144 38145 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void) 38146 If non-null, this hook performs a target-specific pass over the 38147 instruction stream. The compiler will run it at all optimization 38148 levels, just before the point at which it normally does 38149 delayed-branch scheduling. 38150 38151 The exact purpose of the hook varies from target to target. Some 38152 use it to do transformations that are necessary for correctness, 38153 such as laying out in-function constant pools or avoiding hardware 38154 hazards. Others use it as an opportunity to do some 38155 machine-dependent optimizations. 38156 38157 You need not implement the hook if it has nothing to do. The 38158 default definition is null. 38159 38160 -- Target Hook: void TARGET_INIT_BUILTINS (void) 38161 Define this hook if you have any machine-specific built-in 38162 functions that need to be defined. It should be a function that 38163 performs the necessary setup. 38164 38165 Machine specific built-in functions can be useful to expand special 38166 machine instructions that would otherwise not normally be generated 38167 because they have no equivalent in the source language (for 38168 example, SIMD vector instructions or prefetch instructions). 38169 38170 To create a built-in function, call the function 38171 'lang_hooks.builtin_function' which is defined by the language 38172 front end. You can use any type nodes set up by 38173 'build_common_tree_nodes'; only language front ends that use those 38174 two functions will call 'TARGET_INIT_BUILTINS'. 38175 38176 -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool 38177 INITIALIZE_P) 38178 Define this hook if you have any machine-specific built-in 38179 functions that need to be defined. It should be a function that 38180 returns the builtin function declaration for the builtin function 38181 code CODE. If there is no such builtin and it cannot be 38182 initialized at this time if INITIALIZE_P is true the function 38183 should return 'NULL_TREE'. If CODE is out of range the function 38184 should return 'error_mark_node'. 38185 38186 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 38187 SUBTARGET, machine_mode MODE, int IGNORE) 38188 38189 Expand a call to a machine specific built-in function that was set 38190 up by 'TARGET_INIT_BUILTINS'. EXP is the expression for the 38191 function call; the result should go to TARGET if that is 38192 convenient, and have mode MODE if that is convenient. SUBTARGET 38193 may be used as the target for computing one of EXP's operands. 38194 IGNORE is nonzero if the value is to be ignored. This function 38195 should return the result of the call to the built-in function. 38196 38197 -- Target Hook: tree TARGET_BUILTIN_CHKP_FUNCTION (unsigned FCODE) 38198 This hook allows target to redefine built-in functions used by 38199 Pointer Bounds Checker for code instrumentation. Hook should 38200 return fndecl of function implementing generic builtin whose code 38201 is passed in FCODE. Currently following built-in functions are 38202 obtained using this hook: 38203 -- Built-in Function: __bounds_type __chkp_bndmk (const void *LB, 38204 size_t SIZE) 38205 Function code - BUILT_IN_CHKP_BNDMK. This built-in function is 38206 used by Pointer Bounds Checker to create bound values. LB 38207 holds low bound of the resulting bounds. SIZE holds size of 38208 created bounds. 38209 38210 -- Built-in Function: void __chkp_bndstx (const void *PTR, 38211 __bounds_type B, const void **LOC) 38212 Function code - 'BUILT_IN_CHKP_BNDSTX'. This built-in 38213 function is used by Pointer Bounds Checker to store bounds B 38214 for pointer PTR when PTR is stored by address LOC. 38215 38216 -- Built-in Function: __bounds_type __chkp_bndldx (const void 38217 **LOC, const void *PTR) 38218 Function code - 'BUILT_IN_CHKP_BNDLDX'. This built-in 38219 function is used by Pointer Bounds Checker to get bounds of 38220 pointer PTR loaded by address LOC. 38221 38222 -- Built-in Function: void __chkp_bndcl (const void *PTR, 38223 __bounds_type B) 38224 Function code - 'BUILT_IN_CHKP_BNDCL'. This built-in function 38225 is used by Pointer Bounds Checker to perform check for pointer 38226 PTR against lower bound of bounds B. 38227 38228 -- Built-in Function: void __chkp_bndcu (const void *PTR, 38229 __bounds_type B) 38230 Function code - 'BUILT_IN_CHKP_BNDCU'. This built-in function 38231 is used by Pointer Bounds Checker to perform check for pointer 38232 PTR against upper bound of bounds B. 38233 38234 -- Built-in Function: __bounds_type __chkp_bndret (void *PTR) 38235 Function code - 'BUILT_IN_CHKP_BNDRET'. This built-in 38236 function is used by Pointer Bounds Checker to obtain bounds 38237 returned by a call statement. PTR passed to built-in is 38238 'SSA_NAME' returned by the call. 38239 38240 -- Built-in Function: __bounds_type __chkp_intersect 38241 (__bounds_type B1, __bounds_type B2) 38242 Function code - 'BUILT_IN_CHKP_INTERSECT'. This built-in 38243 function returns intersection of bounds B1 and B2. 38244 38245 -- Built-in Function: __bounds_type __chkp_narrow (const void 38246 *PTR, __bounds_type B, size_t S) 38247 Function code - 'BUILT_IN_CHKP_NARROW'. This built-in 38248 function returns intersection of bounds B and [PTR, PTR + S - 38249 '1']. 38250 38251 -- Built-in Function: size_t __chkp_sizeof (const void *PTR) 38252 Function code - 'BUILT_IN_CHKP_SIZEOF'. This built-in 38253 function returns size of object referenced by PTR. PTR is 38254 always 'ADDR_EXPR' of 'VAR_DECL'. This built-in is used by 38255 Pointer Bounds Checker when bounds of object cannot be 38256 computed statically (e.g. object has incomplete type). 38257 38258 -- Built-in Function: const void *__chkp_extract_lower 38259 (__bounds_type B) 38260 Function code - 'BUILT_IN_CHKP_EXTRACT_LOWER'. This built-in 38261 function returns lower bound of bounds B. 38262 38263 -- Built-in Function: const void *__chkp_extract_upper 38264 (__bounds_type B) 38265 Function code - 'BUILT_IN_CHKP_EXTRACT_UPPER'. This built-in 38266 function returns upper bound of bounds B. 38267 -- Target Hook: tree TARGET_CHKP_BOUND_TYPE (void) 38268 Return type to be used for bounds 38269 -- Target Hook: enum machine_mode TARGET_CHKP_BOUND_MODE (void) 38270 Return mode to be used for bounds. 38271 -- Target Hook: tree TARGET_CHKP_MAKE_BOUNDS_CONSTANT (HOST_WIDE_INT 38272 LB, HOST_WIDE_INT UB) 38273 Return constant used to statically initialize constant bounds with 38274 specified lower bound LB and upper bounds UB. 38275 -- Target Hook: int TARGET_CHKP_INITIALIZE_BOUNDS (tree VAR, tree LB, 38276 tree UB, tree *STMTS) 38277 Generate a list of statements STMTS to initialize pointer bounds 38278 variable VAR with bounds LB and UB. Return the number of generated 38279 statements. 38280 38281 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int 38282 LOC, tree FNDECL, void *ARGLIST) 38283 Select a replacement for a machine specific built-in function that 38284 was set up by 'TARGET_INIT_BUILTINS'. This is done _before_ 38285 regular type checking, and so allows the target to implement a 38286 crude form of function overloading. FNDECL is the declaration of 38287 the built-in function. ARGLIST is the list of arguments passed to 38288 the built-in function. The result is a complete expression that 38289 implements the operation, usually another 'CALL_EXPR'. ARGLIST 38290 really has type 'VEC(tree,gc)*' 38291 38292 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, tree 38293 *ARGP, bool IGNORE) 38294 Fold a call to a machine specific built-in function that was set up 38295 by 'TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 38296 built-in function. N_ARGS is the number of arguments passed to the 38297 function; the arguments themselves are pointed to by ARGP. The 38298 result is another tree, valid for both GIMPLE and GENERIC, 38299 containing a simplified expression for the call's result. If 38300 IGNORE is true the value will be ignored. 38301 38302 -- Target Hook: bool TARGET_GIMPLE_FOLD_BUILTIN (gimple_stmt_iterator 38303 *GSI) 38304 Fold a call to a machine specific built-in function that was set up 38305 by 'TARGET_INIT_BUILTINS'. GSI points to the gimple statement 38306 holding the function call. Returns true if any change was made to 38307 the GIMPLE stream. 38308 38309 -- Target Hook: int TARGET_COMPARE_VERSION_PRIORITY (tree DECL1, tree 38310 DECL2) 38311 This hook is used to compare the target attributes in two functions 38312 to determine which function's features get higher priority. This 38313 is used during function multi-versioning to figure out the order in 38314 which two versions must be dispatched. A function version with a 38315 higher priority is checked for dispatching earlier. DECL1 and 38316 DECL2 are the two function decls that will be compared. 38317 38318 -- Target Hook: tree TARGET_GET_FUNCTION_VERSIONS_DISPATCHER (void 38319 *DECL) 38320 This hook is used to get the dispatcher function for a set of 38321 function versions. The dispatcher function is called to invoke the 38322 right function version at run-time. DECL is one version from a set 38323 of semantically identical versions. 38324 38325 -- Target Hook: tree TARGET_GENERATE_VERSION_DISPATCHER_BODY (void 38326 *ARG) 38327 This hook is used to generate the dispatcher logic to invoke the 38328 right function version at run-time for a given set of function 38329 versions. ARG points to the callgraph node of the dispatcher 38330 function whose body must be generated. 38331 38332 -- Target Hook: bool TARGET_CAN_USE_DOLOOP_P (const widest_int 38333 &ITERATIONS, const widest_int &ITERATIONS_MAX, unsigned int 38334 LOOP_DEPTH, bool ENTERED_AT_TOP) 38335 Return true if it is possible to use low-overhead loops 38336 ('doloop_end' and 'doloop_begin') for a particular loop. 38337 ITERATIONS gives the exact number of iterations, or 0 if not known. 38338 ITERATIONS_MAX gives the maximum number of iterations, or 0 if not 38339 known. LOOP_DEPTH is the nesting depth of the loop, with 1 for 38340 innermost loops, 2 for loops that contain innermost loops, and so 38341 on. ENTERED_AT_TOP is true if the loop is only entered from the 38342 top. 38343 38344 This hook is only used if 'doloop_end' is available. The default 38345 implementation returns true. You can use 38346 'can_use_doloop_if_innermost' if the loop must be the innermost, 38347 and if there are no other restrictions. 38348 38349 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const 38350 rtx_insn *INSN) 38351 38352 Take an instruction in INSN and return NULL if it is valid within a 38353 low-overhead loop, otherwise return a string explaining why doloop 38354 could not be applied. 38355 38356 Many targets use special registers for low-overhead looping. For 38357 any instruction that clobbers these this function should return a 38358 string indicating the reason why the doloop could not be applied. 38359 By default, the RTL loop optimizer does not use a present doloop 38360 pattern for loops containing function calls or branch on table 38361 instructions. 38362 38363 -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx_insn *INSN) 38364 Take an instruction in INSN and return 'false' if the instruction 38365 is not appropriate as a combination of two or more instructions. 38366 The default is to accept all instructions. 38367 38368 -- Target Hook: bool TARGET_CAN_FOLLOW_JUMP (const rtx_insn *FOLLOWER, 38369 const rtx_insn *FOLLOWEE) 38370 FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if 38371 FOLLOWER may be modified to follow FOLLOWEE; false, if it can't. 38372 For example, on some targets, certain kinds of branches can't be 38373 made to follow through a hot/cold partitioning. 38374 38375 -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE) 38376 This target hook returns 'true' if X is considered to be 38377 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 38378 PA doesn't consider PLUS to be commutative inside a MEM. 38379 OUTER_CODE is the rtx code of the enclosing rtl, if known, 38380 otherwise it is UNKNOWN. 38381 38382 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 38383 38384 When the initial value of a hard register has been copied in a 38385 pseudo register, it is often not necessary to actually allocate 38386 another register to this pseudo register, because the original hard 38387 register or a stack slot it has been saved into can be used. 38388 'TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 38389 allocation once for each hard register that had its initial value 38390 copied by using 'get_func_hard_reg_initial_val' or 38391 'get_hard_reg_initial_val'. Possible values are 'NULL_RTX', if you 38392 don't want to do any special allocation, a 'REG' rtx--that would 38393 typically be the hard register itself, if it is known not to be 38394 clobbered--or a 'MEM'. If you are returning a 'MEM', this is only 38395 a hint for the allocator; it might decide to use another register 38396 anyways. You may use 'current_function_is_leaf' or 'REG_N_SETS' in 38397 the hook to determine if the hard register in question will not be 38398 clobbered. The default value of this hook is 'NULL', which 38399 disables any special allocation. 38400 38401 -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned 38402 FLAGS) 38403 This target hook returns nonzero if X, an 'unspec' or 38404 'unspec_volatile' operation, might cause a trap. Targets can use 38405 this hook to enhance precision of analysis for 'unspec' and 38406 'unspec_volatile' operations. You may call 'may_trap_p_1' to 38407 analyze inner elements of X in which case FLAGS should be passed 38408 along. 38409 38410 -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) 38411 The compiler invokes this hook whenever it changes its current 38412 function context ('cfun'). You can define this function if the 38413 back end needs to perform any initialization or reset actions on a 38414 per-function basis. For example, it may be used to implement 38415 function attributes that affect register usage or code generation 38416 patterns. The argument DECL is the declaration for the new 38417 function context, and may be null to indicate that the compiler has 38418 left a function context and is returning to processing at the top 38419 level. The default hook function does nothing. 38420 38421 GCC sets 'cfun' to a dummy function context during initialization 38422 of some parts of the back end. The hook function is not invoked in 38423 this situation; you need not worry about the hook being invoked 38424 recursively, or when the back end is in a partially-initialized 38425 state. 'cfun' might be 'NULL' to indicate processing at top level, 38426 outside of any function scope. 38427 38428 -- Macro: TARGET_OBJECT_SUFFIX 38429 Define this macro to be a C string representing the suffix for 38430 object files on your target machine. If you do not define this 38431 macro, GCC will use '.o' as the suffix for object files. 38432 38433 -- Macro: TARGET_EXECUTABLE_SUFFIX 38434 Define this macro to be a C string representing the suffix to be 38435 automatically added to executable files on your target machine. If 38436 you do not define this macro, GCC will use the null string as the 38437 suffix for executable files. 38438 38439 -- Macro: COLLECT_EXPORT_LIST 38440 If defined, 'collect2' will scan the individual object files 38441 specified on its command line and create an export list for the 38442 linker. Define this macro for systems like AIX, where the linker 38443 discards object files that are not referenced from 'main' and uses 38444 export lists. 38445 38446 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) 38447 Define this macro to a C expression representing a variant of the 38448 method call MDECL, if Java Native Interface (JNI) methods must be 38449 invoked differently from other methods on your target. For 38450 example, on 32-bit Microsoft Windows, JNI methods must be invoked 38451 using the 'stdcall' calling convention and this macro is then 38452 defined as this expression: 38453 38454 build_type_attribute_variant (MDECL, 38455 build_tree_list 38456 (get_identifier ("stdcall"), 38457 NULL)) 38458 38459 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 38460 This target hook returns 'true' past the point in which new jump 38461 instructions could be created. On machines that require a register 38462 for every jump such as the SHmedia ISA of SH5, this point would 38463 typically be reload, so this target hook should be defined to a 38464 function such as: 38465 38466 static bool 38467 cannot_modify_jumps_past_reload_p () 38468 { 38469 return (reload_completed || reload_in_progress); 38470 } 38471 38472 -- Target Hook: reg_class_t TARGET_BRANCH_TARGET_REGISTER_CLASS (void) 38473 This target hook returns a register class for which branch target 38474 register optimizations should be applied. All registers in this 38475 class should be usable interchangeably. After reload, registers in 38476 this class will be re-allocated and loads will be hoisted out of 38477 loops and be subjected to inter-block scheduling. 38478 38479 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool 38480 AFTER_PROLOGUE_EPILOGUE_GEN) 38481 Branch target register optimization will by default exclude 38482 callee-saved registers that are not already live during the current 38483 function; if this target hook returns true, they will be included. 38484 The target code must than make sure that all target registers in 38485 the class returned by 'TARGET_BRANCH_TARGET_REGISTER_CLASS' that 38486 might need saving are saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates 38487 if prologues and epilogues have already been generated. Note, even 38488 if you only return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, 38489 you still are likely to have to make special provisions in 38490 'INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved 38491 target registers. 38492 38493 -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void) 38494 This target hook returns true if the target supports conditional 38495 execution. This target hook is required only when the target has 38496 several different modes and they have different conditional 38497 execution capability, such as ARM. 38498 38499 -- Target Hook: rtx TARGET_GEN_CCMP_FIRST (rtx *PREP_SEQ, rtx *GEN_SEQ, 38500 int CODE, tree OP0, tree OP1) 38501 This function prepares to emit a comparison insn for the first 38502 compare in a sequence of conditional comparisions. It returns an 38503 appropriate comparison with 'CC' for passing to 'gen_ccmp_next' or 38504 'cbranch_optab'. The insns to prepare the compare are saved in 38505 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will be 38506 emitted when all the compares in the the conditional comparision 38507 are generated without error. CODE is the 'rtx_code' of the compare 38508 for OP0 and OP1. 38509 38510 -- Target Hook: rtx TARGET_GEN_CCMP_NEXT (rtx *PREP_SEQ, rtx *GEN_SEQ, 38511 rtx PREV, int CMP_CODE, tree OP0, tree OP1, int BIT_CODE) 38512 This function prepares to emit a conditional comparison within a 38513 sequence of conditional comparisons. It returns an appropriate 38514 comparison with 'CC' for passing to 'gen_ccmp_next' or 38515 'cbranch_optab'. The insns to prepare the compare are saved in 38516 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will be 38517 emitted when all the compares in the conditional comparision are 38518 generated without error. The PREV expression is the result of a 38519 prior call to 'gen_ccmp_first' or 'gen_ccmp_next'. It may return 38520 'NULL' if the combination of PREV and this comparison is not 38521 supported, otherwise the result must be appropriate for passing to 38522 'gen_ccmp_next' or 'cbranch_optab'. CODE is the 'rtx_code' of the 38523 compare for OP0 and OP1. BIT_CODE is 'AND' or 'IOR', which is the 38524 op on the compares. 38525 38526 -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL, 38527 struct loop *LOOP) 38528 This target hook returns a new value for the number of times LOOP 38529 should be unrolled. The parameter NUNROLL is the number of times 38530 the loop is to be unrolled. The parameter LOOP is a pointer to the 38531 loop, which is going to be checked for unrolling. This target hook 38532 is required only when the target has special constraints like 38533 maximum number of memory accesses. 38534 38535 -- Macro: POWI_MAX_MULTS 38536 If defined, this macro is interpreted as a signed integer C 38537 expression that specifies the maximum number of floating point 38538 multiplications that should be emitted when expanding 38539 exponentiation by an integer constant inline. When this value is 38540 defined, exponentiation requiring more than this number of 38541 multiplications is implemented by calling the system library's 38542 'pow', 'powf' or 'powl' routines. The default value places no 38543 upper bound on the multiplication count. 38544 38545 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 38546 *IPREFIX, int STDINC) 38547 This target hook should register any extra include files for the 38548 target. The parameter STDINC indicates if normal include files are 38549 present. The parameter SYSROOT is the system root directory. The 38550 parameter IPREFIX is the prefix for the gcc directory. 38551 38552 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 38553 char *IPREFIX, int STDINC) 38554 This target hook should register any extra include files for the 38555 target before any standard headers. The parameter STDINC indicates 38556 if normal include files are present. The parameter SYSROOT is the 38557 system root directory. The parameter IPREFIX is the prefix for the 38558 gcc directory. 38559 38560 -- Macro: void TARGET_OPTF (char *PATH) 38561 This target hook should register special include paths for the 38562 target. The parameter PATH is the include to register. On Darwin 38563 systems, this is used for Framework includes, which have semantics 38564 that are different from '-I'. 38565 38566 -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 38567 This target macro returns 'true' if it is safe to use a local alias 38568 for a virtual function FNDECL when constructing thunks, 'false' 38569 otherwise. By default, the macro returns 'true' for all functions, 38570 if a target supports aliases (i.e. defines 'ASM_OUTPUT_DEF'), 38571 'false' otherwise, 38572 38573 -- Macro: TARGET_FORMAT_TYPES 38574 If defined, this macro is the name of a global variable containing 38575 target-specific format checking information for the '-Wformat' 38576 option. The default is to have no target-specific format checks. 38577 38578 -- Macro: TARGET_N_FORMAT_TYPES 38579 If defined, this macro is the number of entries in 38580 'TARGET_FORMAT_TYPES'. 38581 38582 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES 38583 If defined, this macro is the name of a global variable containing 38584 target-specific format overrides for the '-Wformat' option. The 38585 default is to have no target-specific format overrides. If 38586 defined, 'TARGET_FORMAT_TYPES' must be defined, too. 38587 38588 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT 38589 If defined, this macro specifies the number of entries in 38590 'TARGET_OVERRIDES_FORMAT_ATTRIBUTES'. 38591 38592 -- Macro: TARGET_OVERRIDES_FORMAT_INIT 38593 If defined, this macro specifies the optional initialization 38594 routine for target specific customizations of the system printf and 38595 scanf formatter settings. 38596 38597 -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 38598 (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL) 38599 If defined, this macro returns the diagnostic message when it is 38600 illegal to pass argument VAL to function FUNCDECL with prototype 38601 TYPELIST. 38602 38603 -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree 38604 FROMTYPE, const_tree TOTYPE) 38605 If defined, this macro returns the diagnostic message when it is 38606 invalid to convert from FROMTYPE to TOTYPE, or 'NULL' if validity 38607 should be determined by the front end. 38608 38609 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, 38610 const_tree TYPE) 38611 If defined, this macro returns the diagnostic message when it is 38612 invalid to apply operation OP (where unary plus is denoted by 38613 'CONVERT_EXPR') to an operand of type TYPE, or 'NULL' if validity 38614 should be determined by the front end. 38615 38616 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, 38617 const_tree TYPE1, const_tree TYPE2) 38618 If defined, this macro returns the diagnostic message when it is 38619 invalid to apply operation OP to operands of types TYPE1 and TYPE2, 38620 or 'NULL' if validity should be determined by the front end. 38621 38622 -- Target Hook: const char * TARGET_INVALID_PARAMETER_TYPE (const_tree 38623 TYPE) 38624 If defined, this macro returns the diagnostic message when it is 38625 invalid for functions to include parameters of type TYPE, or 'NULL' 38626 if validity should be determined by the front end. This is 38627 currently used only by the C and C++ front ends. 38628 38629 -- Target Hook: const char * TARGET_INVALID_RETURN_TYPE (const_tree 38630 TYPE) 38631 If defined, this macro returns the diagnostic message when it is 38632 invalid for functions to have return type TYPE, or 'NULL' if 38633 validity should be determined by the front end. This is currently 38634 used only by the C and C++ front ends. 38635 38636 -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE) 38637 If defined, this target hook returns the type to which values of 38638 TYPE should be promoted when they appear in expressions, analogous 38639 to the integer promotions, or 'NULL_TREE' to use the front end's 38640 normal promotion rules. This hook is useful when there are 38641 target-specific types with special promotion rules. This is 38642 currently used only by the C and C++ front ends. 38643 38644 -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR) 38645 If defined, this hook returns the result of converting EXPR to 38646 TYPE. It should return the converted expression, or 'NULL_TREE' to 38647 apply the front end's normal conversion rules. This hook is useful 38648 when there are target-specific types with special conversion rules. 38649 This is currently used only by the C and C++ front ends. 38650 38651 -- Macro: TARGET_USE_JCR_SECTION 38652 This macro determines whether to use the JCR section to register 38653 Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1 38654 if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true, else 38655 0. 38656 38657 -- Macro: OBJC_JBLEN 38658 This macro determines the size of the objective C jump buffer for 38659 the NeXT runtime. By default, OBJC_JBLEN is defined to an 38660 innocuous value. 38661 38662 -- Macro: LIBGCC2_UNWIND_ATTRIBUTE 38663 Define this macro if any target-specific attributes need to be 38664 attached to the functions in 'libgcc' that provide low-level 38665 support for call stack unwinding. It is used in declarations in 38666 'unwind-generic.h' and the associated definitions of those 38667 functions. 38668 38669 -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void) 38670 Define this macro to update the current function stack boundary if 38671 necessary. 38672 38673 -- Target Hook: rtx TARGET_GET_DRAP_RTX (void) 38674 This hook should return an rtx for Dynamic Realign Argument Pointer 38675 (DRAP) if a different argument pointer register is needed to access 38676 the function's argument list due to stack realignment. Return 38677 'NULL' if no DRAP is needed. 38678 38679 -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void) 38680 When optimization is disabled, this hook indicates whether or not 38681 arguments should be allocated to stack slots. Normally, GCC 38682 allocates stacks slots for arguments when not optimizing in order 38683 to make debugging easier. However, when a function is declared 38684 with '__attribute__((naked))', there is no stack frame, and the 38685 compiler cannot safely move arguments from the registers in which 38686 they are passed to the stack. Therefore, this hook should return 38687 true in general, but false for naked functions. The default 38688 implementation always returns true. 38689 38690 -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR 38691 On some architectures it can take multiple instructions to 38692 synthesize a constant. If there is another constant already in a 38693 register that is close enough in value then it is preferable that 38694 the new constant is computed from this register using immediate 38695 addition or subtraction. We accomplish this through CSE. Besides 38696 the value of the constant we also add a lower and an upper constant 38697 anchor to the available expressions. These are then queried when 38698 encountering new constants. The anchors are computed by rounding 38699 the constant up and down to a multiple of the value of 38700 'TARGET_CONST_ANCHOR'. 'TARGET_CONST_ANCHOR' should be the maximum 38701 positive value accepted by immediate-add plus one. We currently 38702 assume that the value of 'TARGET_CONST_ANCHOR' is a power of 2. 38703 For example, on MIPS, where add-immediate takes a 16-bit signed 38704 value, 'TARGET_CONST_ANCHOR' is set to '0x8000'. The default value 38705 is zero, which disables this optimization. 38706 38707 -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void) 38708 Return the offset bitwise ored into shifted address to get 38709 corresponding Address Sanitizer shadow memory address. NULL if 38710 Address Sanitizer is not supported by the target. 38711 38712 -- Target Hook: unsigned HOST_WIDE_INT TARGET_MEMMODEL_CHECK (unsigned 38713 HOST_WIDE_INT VAL) 38714 Validate target specific memory model mask bits. When NULL no 38715 target specific memory model bits are allowed. 38716 38717 -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 38718 This value should be set if the result written by 38719 'atomic_test_and_set' is not exactly 1, i.e. the 'bool' 'true'. 38720 38721 -- Target Hook: bool TARGET_HAS_IFUNC_P (void) 38722 It returns true if the target supports GNU indirect functions. The 38723 support includes the assembler, linker and dynamic linker. The 38724 default value of this hook is based on target's libc. 38725 38726 -- Target Hook: unsigned int TARGET_ATOMIC_ALIGN_FOR_MODE (machine_mode 38727 MODE) 38728 If defined, this function returns an appropriate alignment in bits 38729 for an atomic object of machine_mode MODE. If 0 is returned then 38730 the default alignment for the specified mode is used. 38731 38732 -- Target Hook: void TARGET_ATOMIC_ASSIGN_EXPAND_FENV (tree *HOLD, tree 38733 *CLEAR, tree *UPDATE) 38734 ISO C11 requires atomic compound assignments that may raise 38735 floating-point exceptions to raise exceptions corresponding to the 38736 arithmetic operation whose result was successfully stored in a 38737 compare-and-exchange sequence. This requires code equivalent to 38738 calls to 'feholdexcept', 'feclearexcept' and 'feupdateenv' to be 38739 generated at appropriate points in the compare-and-exchange 38740 sequence. This hook should set '*HOLD' to an expression equivalent 38741 to the call to 'feholdexcept', '*CLEAR' to an expression equivalent 38742 to the call to 'feclearexcept' and '*UPDATE' to an expression 38743 equivalent to the call to 'feupdateenv'. The three expressions are 38744 'NULL_TREE' on entry to the hook and may be left as 'NULL_TREE' if 38745 no code is required in a particular place. The default 38746 implementation leaves all three expressions as 'NULL_TREE'. The 38747 '__atomic_feraiseexcept' function from 'libatomic' may be of use as 38748 part of the code generated in '*UPDATE'. 38749 38750 -- Target Hook: void TARGET_RECORD_OFFLOAD_SYMBOL (tree) 38751 Used when offloaded functions are seen in the compilation unit and 38752 no named sections are available. It is called once for each symbol 38753 that must be recorded in the offload function and variable table. 38754 38755 -- Target Hook: char * TARGET_OFFLOAD_OPTIONS (void) 38756 Used when writing out the list of options into an LTO file. It 38757 should translate any relevant target-specific options (such as the 38758 ABI in use) into one of the '-foffload' options that exist as a 38759 common interface to express such options. It should return a 38760 string containing these options, separated by spaces, which the 38761 caller will free. 38762 38763 -- Macro: TARGET_SUPPORTS_WIDE_INT 38764 38765 On older ports, large integers are stored in 'CONST_DOUBLE' rtl 38766 objects. Newer ports define 'TARGET_SUPPORTS_WIDE_INT' to be 38767 nonzero to indicate that large integers are stored in 38768 'CONST_WIDE_INT' rtl objects. The 'CONST_WIDE_INT' allows very 38769 large integer constants to be represented. 'CONST_DOUBLE' is 38770 limited to twice the size of the host's 'HOST_WIDE_INT' 38771 representation. 38772 38773 Converting a port mostly requires looking for the places where 38774 'CONST_DOUBLE's are used with 'VOIDmode' and replacing that code 38775 with code that accesses 'CONST_WIDE_INT's. '"grep -i 38776 const_double"' at the port level gets you to 95% of the changes 38777 that need to be made. There are a few places that require a deeper 38778 look. 38779 38780 * There is no equivalent to 'hval' and 'lval' for 38781 'CONST_WIDE_INT's. This would be difficult to express in the 38782 md language since there are a variable number of elements. 38783 38784 Most ports only check that 'hval' is either 0 or -1 to see if 38785 the value is small. As mentioned above, this will no longer 38786 be necessary since small constants are always 'CONST_INT'. Of 38787 course there are still a few exceptions, the alpha's 38788 constraint used by the zap instruction certainly requires 38789 careful examination by C code. However, all the current code 38790 does is pass the hval and lval to C code, so evolving the c 38791 code to look at the 'CONST_WIDE_INT' is not really a large 38792 change. 38793 38794 * Because there is no standard template that ports use to 38795 materialize constants, there is likely to be some futzing that 38796 is unique to each port in this code. 38797 38798 * The rtx costs may have to be adjusted to properly account for 38799 larger constants that are represented as 'CONST_WIDE_INT'. 38800 38801 All and all it does not take long to convert ports that the 38802 maintainer is familiar with. 38803 38804 38805File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 38806 3880718 Host Configuration 38808********************* 38809 38810Most details about the machine and system on which the compiler is 38811actually running are detected by the 'configure' script. Some things 38812are impossible for 'configure' to detect; these are described in two 38813ways, either by macros defined in a file named 'xm-MACHINE.h' or by hook 38814functions in the file specified by the OUT_HOST_HOOK_OBJ variable in 38815'config.gcc'. (The intention is that very few hosts will need a header 38816file but nearly every fully supported host will need to override some 38817hooks.) 38818 38819 If you need to define only a few macros, and they have simple 38820definitions, consider using the 'xm_defines' variable in your 38821'config.gcc' entry instead of creating a host configuration header. 38822*Note System Config::. 38823 38824* Menu: 38825 38826* Host Common:: Things every host probably needs implemented. 38827* Filesystem:: Your host can't have the letter 'a' in filenames? 38828* Host Misc:: Rare configuration options for hosts. 38829 38830 38831File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 38832 3883318.1 Host Common 38834================ 38835 38836Some things are just not portable, even between similar operating 38837systems, and are too difficult for autoconf to detect. They get 38838implemented using hook functions in the file specified by the 38839HOST_HOOK_OBJ variable in 'config.gcc'. 38840 38841 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 38842 This host hook is used to set up handling for extra signals. The 38843 most common thing to do in this hook is to detect stack overflow. 38844 38845 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 38846 FD) 38847 This host hook returns the address of some space that is likely to 38848 be free in some subsequent invocation of the compiler. We intend 38849 to load the PCH data at this address such that the data need not be 38850 relocated. The area should be able to hold SIZE bytes. If the 38851 host uses 'mmap', FD is an open file descriptor that can be used 38852 for probing. 38853 38854 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, size_t 38855 SIZE, int FD, size_t OFFSET) 38856 This host hook is called when a PCH file is about to be loaded. We 38857 want to load SIZE bytes from FD at OFFSET into memory at ADDRESS. 38858 The given address will be the result of a previous invocation of 38859 'HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we couldn't allocate 38860 SIZE bytes at ADDRESS. Return 0 if the memory is allocated but the 38861 data is not loaded. Return 1 if the hook has performed everything. 38862 38863 If the implementation uses reserved address space, free any 38864 reserved space beyond SIZE, regardless of the return value. If no 38865 PCH will be loaded, this hook may be called with SIZE zero, in 38866 which case all reserved address space should be freed. 38867 38868 Do not try to handle values of ADDRESS that could not have been 38869 returned by this executable; just return -1. Such values usually 38870 indicate an out-of-date PCH file (built by some other GCC 38871 executable), and such a PCH file won't work. 38872 38873 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 38874 This host hook returns the alignment required for allocating 38875 virtual memory. Usually this is the same as getpagesize, but on 38876 some hosts the alignment for reserving memory differs from the 38877 pagesize for committing memory. 38878 38879 38880File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 38881 3888218.2 Host Filesystem 38883==================== 38884 38885GCC needs to know a number of things about the semantics of the host 38886machine's filesystem. Filesystems with Unix and MS-DOS semantics are 38887automatically detected. For other systems, you can define the following 38888macros in 'xm-MACHINE.h'. 38889 38890'HAVE_DOS_BASED_FILE_SYSTEM' 38891 This macro is automatically defined by 'system.h' if the host file 38892 system obeys the semantics defined by MS-DOS instead of Unix. DOS 38893 file systems are case insensitive, file specifications may begin 38894 with a drive letter, and both forward slash and backslash ('/' and 38895 '\') are directory separators. 38896 38897'DIR_SEPARATOR' 38898'DIR_SEPARATOR_2' 38899 If defined, these macros expand to character constants specifying 38900 separators for directory names within a file specification. 38901 'system.h' will automatically give them appropriate values on Unix 38902 and MS-DOS file systems. If your file system is neither of these, 38903 define one or both appropriately in 'xm-MACHINE.h'. 38904 38905 However, operating systems like VMS, where constructing a pathname 38906 is more complicated than just stringing together directory names 38907 separated by a special character, should not define either of these 38908 macros. 38909 38910'PATH_SEPARATOR' 38911 If defined, this macro should expand to a character constant 38912 specifying the separator for elements of search paths. The default 38913 value is a colon (':'). DOS-based systems usually, but not always, 38914 use semicolon (';'). 38915 38916'VMS' 38917 Define this macro if the host system is VMS. 38918 38919'HOST_OBJECT_SUFFIX' 38920 Define this macro to be a C string representing the suffix for 38921 object files on your host machine. If you do not define this 38922 macro, GCC will use '.o' as the suffix for object files. 38923 38924'HOST_EXECUTABLE_SUFFIX' 38925 Define this macro to be a C string representing the suffix for 38926 executable files on your host machine. If you do not define this 38927 macro, GCC will use the null string as the suffix for executable 38928 files. 38929 38930'HOST_BIT_BUCKET' 38931 A pathname defined by the host operating system, which can be 38932 opened as a file and written to, but all the information written is 38933 discarded. This is commonly known as a "bit bucket" or "null 38934 device". If you do not define this macro, GCC will use '/dev/null' 38935 as the bit bucket. If the host does not support a bit bucket, 38936 define this macro to an invalid filename. 38937 38938'UPDATE_PATH_HOST_CANONICALIZE (PATH)' 38939 If defined, a C statement (sans semicolon) that performs 38940 host-dependent canonicalization when a path used in a compilation 38941 driver or preprocessor is canonicalized. PATH is a malloc-ed path 38942 to be canonicalized. If the C statement does canonicalize PATH 38943 into a different buffer, the old path should be freed and the new 38944 buffer should have been allocated with malloc. 38945 38946'DUMPFILE_FORMAT' 38947 Define this macro to be a C string representing the format to use 38948 for constructing the index part of debugging dump file names. The 38949 resultant string must fit in fifteen bytes. The full filename will 38950 be the concatenation of: the prefix of the assembler file name, the 38951 string resulting from applying this format to an index number, and 38952 a string unique to each dump file kind, e.g. 'rtl'. 38953 38954 If you do not define this macro, GCC will use '.%02d.'. You should 38955 define this macro if using the default will create an invalid file 38956 name. 38957 38958'DELETE_IF_ORDINARY' 38959 Define this macro to be a C statement (sans semicolon) that 38960 performs host-dependent removal of ordinary temp files in the 38961 compilation driver. 38962 38963 If you do not define this macro, GCC will use the default version. 38964 You should define this macro if the default version does not 38965 reliably remove the temp file as, for example, on VMS which allows 38966 multiple versions of a file. 38967 38968'HOST_LACKS_INODE_NUMBERS' 38969 Define this macro if the host filesystem does not report meaningful 38970 inode numbers in struct stat. 38971 38972 38973File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 38974 3897518.3 Host Misc 38976============== 38977 38978'FATAL_EXIT_CODE' 38979 A C expression for the status code to be returned when the compiler 38980 exits after serious errors. The default is the system-provided 38981 macro 'EXIT_FAILURE', or '1' if the system doesn't define that 38982 macro. Define this macro only if these defaults are incorrect. 38983 38984'SUCCESS_EXIT_CODE' 38985 A C expression for the status code to be returned when the compiler 38986 exits without serious errors. (Warnings are not serious errors.) 38987 The default is the system-provided macro 'EXIT_SUCCESS', or '0' if 38988 the system doesn't define that macro. Define this macro only if 38989 these defaults are incorrect. 38990 38991'USE_C_ALLOCA' 38992 Define this macro if GCC should use the C implementation of 38993 'alloca' provided by 'libiberty.a'. This only affects how some 38994 parts of the compiler itself allocate memory. It does not change 38995 code generation. 38996 38997 When GCC is built with a compiler other than itself, the C 'alloca' 38998 is always used. This is because most other implementations have 38999 serious bugs. You should define this macro only on a system where 39000 no stack-based 'alloca' can possibly work. For instance, if a 39001 system has a small limit on the size of the stack, GCC's builtin 39002 'alloca' will not work reliably. 39003 39004'COLLECT2_HOST_INITIALIZATION' 39005 If defined, a C statement (sans semicolon) that performs 39006 host-dependent initialization when 'collect2' is being initialized. 39007 39008'GCC_DRIVER_HOST_INITIALIZATION' 39009 If defined, a C statement (sans semicolon) that performs 39010 host-dependent initialization when a compilation driver is being 39011 initialized. 39012 39013'HOST_LONG_LONG_FORMAT' 39014 If defined, the string used to indicate an argument of type 'long 39015 long' to functions like 'printf'. The default value is '"ll"'. 39016 39017'HOST_LONG_FORMAT' 39018 If defined, the string used to indicate an argument of type 'long' 39019 to functions like 'printf'. The default value is '"l"'. 39020 39021'HOST_PTR_PRINTF' 39022 If defined, the string used to indicate an argument of type 'void 39023 *' to functions like 'printf'. The default value is '"%p"'. 39024 39025 In addition, if 'configure' generates an incorrect definition of any of 39026the macros in 'auto-host.h', you can override that definition in a host 39027configuration header. If you need to do this, first see if it is 39028possible to fix 'configure'. 39029 39030 39031File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 39032 3903319 Makefile Fragments 39034********************* 39035 39036When you configure GCC using the 'configure' script, it will construct 39037the file 'Makefile' from the template file 'Makefile.in'. When it does 39038this, it can incorporate makefile fragments from the 'config' directory. 39039These are used to set Makefile parameters that are not amenable to being 39040calculated by autoconf. The list of fragments to incorporate is set by 39041'config.gcc' (and occasionally 'config.build' and 'config.host'); *Note 39042System Config::. 39043 39044 Fragments are named either 't-TARGET' or 'x-HOST', depending on whether 39045they are relevant to configuring GCC to produce code for a particular 39046target, or to configuring GCC to run on a particular host. Here TARGET 39047and HOST are mnemonics which usually have some relationship to the 39048canonical system name, but no formal connection. 39049 39050 If these files do not exist, it means nothing needs to be added for a 39051given target or host. Most targets need a few 't-TARGET' fragments, but 39052needing 'x-HOST' fragments is rare. 39053 39054* Menu: 39055 39056* Target Fragment:: Writing 't-TARGET' files. 39057* Host Fragment:: Writing 'x-HOST' files. 39058 39059 39060File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 39061 3906219.1 Target Makefile Fragments 39063============================== 39064 39065Target makefile fragments can set these Makefile variables. 39066 39067'LIBGCC2_CFLAGS' 39068 Compiler flags to use when compiling 'libgcc2.c'. 39069 39070'LIB2FUNCS_EXTRA' 39071 A list of source file names to be compiled or assembled and 39072 inserted into 'libgcc.a'. 39073 39074'CRTSTUFF_T_CFLAGS' 39075 Special flags used when compiling 'crtstuff.c'. *Note 39076 Initialization::. 39077 39078'CRTSTUFF_T_CFLAGS_S' 39079 Special flags used when compiling 'crtstuff.c' for shared linking. 39080 Used if you use 'crtbeginS.o' and 'crtendS.o' in 'EXTRA-PARTS'. 39081 *Note Initialization::. 39082 39083'MULTILIB_OPTIONS' 39084 For some targets, invoking GCC in different ways produces objects 39085 that can not be linked together. For example, for some targets GCC 39086 produces both big and little endian code. For these targets, you 39087 must arrange for multiple versions of 'libgcc.a' to be compiled, 39088 one for each set of incompatible options. When GCC invokes the 39089 linker, it arranges to link in the right version of 'libgcc.a', 39090 based on the command line options used. 39091 39092 The 'MULTILIB_OPTIONS' macro lists the set of options for which 39093 special versions of 'libgcc.a' must be built. Write options that 39094 are mutually incompatible side by side, separated by a slash. 39095 Write options that may be used together separated by a space. The 39096 build procedure will build all combinations of compatible options. 39097 39098 For example, if you set 'MULTILIB_OPTIONS' to 'm68000/m68020 39099 msoft-float', 'Makefile' will build special versions of 'libgcc.a' 39100 using the following sets of options: '-m68000', '-m68020', 39101 '-msoft-float', '-m68000 -msoft-float', and '-m68020 -msoft-float'. 39102 39103'MULTILIB_DIRNAMES' 39104 If 'MULTILIB_OPTIONS' is used, this variable specifies the 39105 directory names that should be used to hold the various libraries. 39106 Write one element in 'MULTILIB_DIRNAMES' for each element in 39107 'MULTILIB_OPTIONS'. If 'MULTILIB_DIRNAMES' is not used, the 39108 default value will be 'MULTILIB_OPTIONS', with all slashes treated 39109 as spaces. 39110 39111 'MULTILIB_DIRNAMES' describes the multilib directories using GCC 39112 conventions and is applied to directories that are part of the GCC 39113 installation. When multilib-enabled, the compiler will add a 39114 subdirectory of the form PREFIX/MULTILIB before each directory in 39115 the search path for libraries and crt files. 39116 39117 For example, if 'MULTILIB_OPTIONS' is set to 'm68000/m68020 39118 msoft-float', then the default value of 'MULTILIB_DIRNAMES' is 39119 'm68000 m68020 msoft-float'. You may specify a different value if 39120 you desire a different set of directory names. 39121 39122'MULTILIB_MATCHES' 39123 Sometimes the same option may be written in two different ways. If 39124 an option is listed in 'MULTILIB_OPTIONS', GCC needs to know about 39125 any synonyms. In that case, set 'MULTILIB_MATCHES' to a list of 39126 items of the form 'option=option' to describe all relevant 39127 synonyms. For example, 'm68000=mc68000 m68020=mc68020'. 39128 39129'MULTILIB_EXCEPTIONS' 39130 Sometimes when there are multiple sets of 'MULTILIB_OPTIONS' being 39131 specified, there are combinations that should not be built. In 39132 that case, set 'MULTILIB_EXCEPTIONS' to be all of the switch 39133 exceptions in shell case syntax that should not be built. 39134 39135 For example the ARM processor cannot execute both hardware floating 39136 point instructions and the reduced size THUMB instructions at the 39137 same time, so there is no need to build libraries with both of 39138 these options enabled. Therefore 'MULTILIB_EXCEPTIONS' is set to: 39139 *mthumb/*mhard-float* 39140 39141'MULTILIB_REQUIRED' 39142 Sometimes when there are only a few combinations are required, it 39143 would be a big effort to come up with a 'MULTILIB_EXCEPTIONS' list 39144 to cover all undesired ones. In such a case, just listing all the 39145 required combinations in 'MULTILIB_REQUIRED' would be more 39146 straightforward. 39147 39148 The way to specify the entries in 'MULTILIB_REQUIRED' is same with 39149 the way used for 'MULTILIB_EXCEPTIONS', only this time what are 39150 required will be specified. Suppose there are multiple sets of 39151 'MULTILIB_OPTIONS' and only two combinations are required, one for 39152 ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU, 39153 the 'MULTILIB_REQUIRED' can be set to: 39154 MULTILIB_REQUIRED = mthumb/march=armv7-m 39155 MULTILIB_REQUIRED += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16 39156 39157 The 'MULTILIB_REQUIRED' can be used together with 39158 'MULTILIB_EXCEPTIONS'. The option combinations generated from 39159 'MULTILIB_OPTIONS' will be filtered by 'MULTILIB_EXCEPTIONS' and 39160 then by 'MULTILIB_REQUIRED'. 39161 39162'MULTILIB_REUSE' 39163 Sometimes it is desirable to reuse one existing multilib for 39164 different sets of options. Such kind of reuse can minimize the 39165 number of multilib variants. And for some targets it is better to 39166 reuse an existing multilib than to fall back to default multilib 39167 when there is no corresponding multilib. This can be done by 39168 adding reuse rules to 'MULTILIB_REUSE'. 39169 39170 A reuse rule is comprised of two parts connected by equality sign. 39171 The left part is option set used to build multilib and the right 39172 part is option set that will reuse this multilib. The order of 39173 options in the left part matters and should be same with those 39174 specified in 'MULTILIB_REQUIRED' or aligned with order in 39175 'MULTILIB_OPTIONS'. There is no such limitation for options in 39176 right part as we don't build multilib from them. But the equality 39177 sign in both parts should be replaced with period. 39178 39179 The 'MULTILIB_REUSE' is different from 'MULTILIB_MATCHES' in that 39180 it sets up relations between two option sets rather than two 39181 options. Here is an example to demo how we reuse libraries built 39182 in Thumb mode for applications built in ARM mode: 39183 MULTILIB_REUSE = mthumb/march.armv7-r=marm/march.armv7-r 39184 39185 Before the advent of 'MULTILIB_REUSE', GCC select multilib by 39186 comparing command line options with options used to build multilib. 39187 The 'MULTILIB_REUSE' is complementary to that way. Only when the 39188 original comparison matches nothing it will work to see if it is OK 39189 to reuse some existing multilib. 39190 39191'MULTILIB_EXTRA_OPTS' 39192 Sometimes it is desirable that when building multiple versions of 39193 'libgcc.a' certain options should always be passed on to the 39194 compiler. In that case, set 'MULTILIB_EXTRA_OPTS' to be the list 39195 of options to be used for all builds. If you set this, you should 39196 probably set 'CRTSTUFF_T_CFLAGS' to a dash followed by it. 39197 39198'MULTILIB_OSDIRNAMES' 39199 If 'MULTILIB_OPTIONS' is used, this variable specifies a list of 39200 subdirectory names, that are used to modify the search path 39201 depending on the chosen multilib. Unlike 'MULTILIB_DIRNAMES', 39202 'MULTILIB_OSDIRNAMES' describes the multilib directories using 39203 operating systems conventions, and is applied to the directories 39204 such as 'lib' or those in the 'LIBRARY_PATH' environment variable. 39205 The format is either the same as of 'MULTILIB_DIRNAMES', or a set 39206 of mappings. When it is the same as 'MULTILIB_DIRNAMES', it 39207 describes the multilib directories using operating system 39208 conventions, rather than GCC conventions. When it is a set of 39209 mappings of the form GCCDIR=OSDIR, the left side gives the GCC 39210 convention and the right gives the equivalent OS defined location. 39211 If the OSDIR part begins with a '!', GCC will not search in the 39212 non-multilib directory and use exclusively the multilib directory. 39213 Otherwise, the compiler will examine the search path for libraries 39214 and crt files twice; the first time it will add MULTILIB to each 39215 directory in the search path, the second it will not. 39216 39217 For configurations that support both multilib and multiarch, 39218 'MULTILIB_OSDIRNAMES' also encodes the multiarch name, thus 39219 subsuming 'MULTIARCH_DIRNAME'. The multiarch name is appended to 39220 each directory name, separated by a colon (e.g. 39221 '../lib32:i386-linux-gnu'). 39222 39223 Each multiarch subdirectory will be searched before the 39224 corresponding OS multilib directory, for example 39225 '/lib/i386-linux-gnu' before '/lib/../lib32'. The multiarch name 39226 will also be used to modify the system header search path, as 39227 explained for 'MULTIARCH_DIRNAME'. 39228 39229'MULTIARCH_DIRNAME' 39230 This variable specifies the multiarch name for configurations that 39231 are multiarch-enabled but not multilibbed configurations. 39232 39233 The multiarch name is used to augment the search path for 39234 libraries, crt files and system header files with additional 39235 locations. The compiler will add a multiarch subdirectory of the 39236 form PREFIX/MULTIARCH before each directory in the library and crt 39237 search path. It will also add two directories 39238 'LOCAL_INCLUDE_DIR'/MULTIARCH and 39239 'NATIVE_SYSTEM_HEADER_DIR'/MULTIARCH) to the system header search 39240 path, respectively before 'LOCAL_INCLUDE_DIR' and 39241 'NATIVE_SYSTEM_HEADER_DIR'. 39242 39243 'MULTIARCH_DIRNAME' is not used for configurations that support 39244 both multilib and multiarch. In that case, multiarch names are 39245 encoded in 'MULTILIB_OSDIRNAMES' instead. 39246 39247 More documentation about multiarch can be found at 39248 <https://wiki.debian.org/Multiarch>. 39249 39250'SPECS' 39251 Unfortunately, setting 'MULTILIB_EXTRA_OPTS' is not enough, since 39252 it does not affect the build of target libraries, at least not the 39253 build of the default multilib. One possible work-around is to use 39254 'DRIVER_SELF_SPECS' to bring options from the 'specs' file as if 39255 they had been passed in the compiler driver command line. However, 39256 you don't want to be adding these options after the toolchain is 39257 installed, so you can instead tweak the 'specs' file that will be 39258 used during the toolchain build, while you still install the 39259 original, built-in 'specs'. The trick is to set 'SPECS' to some 39260 other filename (say 'specs.install'), that will then be created out 39261 of the built-in specs, and introduce a 'Makefile' rule to generate 39262 the 'specs' file that's going to be used at build time out of your 39263 'specs.install'. 39264 39265'T_CFLAGS' 39266 These are extra flags to pass to the C compiler. They are used 39267 both when building GCC, and when compiling things with the 39268 just-built GCC. This variable is deprecated and should not be 39269 used. 39270 39271 39272File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 39273 3927419.2 Host Makefile Fragments 39275============================ 39276 39277The use of 'x-HOST' fragments is discouraged. You should only use it 39278for makefile dependencies. 39279 39280 39281File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 39282 3928320 'collect2' 39284************* 39285 39286GCC uses a utility called 'collect2' on nearly all systems to arrange to 39287call various initialization functions at start time. 39288 39289 The program 'collect2' works by linking the program once and looking 39290through the linker output file for symbols with particular names 39291indicating they are constructor functions. If it finds any, it creates 39292a new temporary '.c' file containing a table of them, compiles it, and 39293links the program a second time including that file. 39294 39295 The actual calls to the constructors are carried out by a subroutine 39296called '__main', which is called (automatically) at the beginning of the 39297body of 'main' (provided 'main' was compiled with GNU CC). Calling 39298'__main' is necessary, even when compiling C code, to allow linking C 39299and C++ object code together. (If you use '-nostdlib', you get an 39300unresolved reference to '__main', since it's defined in the standard GCC 39301library. Include '-lgcc' at the end of your compiler command line to 39302resolve this reference.) 39303 39304 The program 'collect2' is installed as 'ld' in the directory where the 39305passes of the compiler are installed. When 'collect2' needs to find the 39306_real_ 'ld', it tries the following file names: 39307 39308 * a hard coded linker file name, if GCC was configured with the 39309 '--with-ld' option. 39310 39311 * 'real-ld' in the directories listed in the compiler's search 39312 directories. 39313 39314 * 'real-ld' in the directories listed in the environment variable 39315 'PATH'. 39316 39317 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 39318 if specified. 39319 39320 * 'ld' in the compiler's search directories, except that 'collect2' 39321 will not execute itself recursively. 39322 39323 * 'ld' in 'PATH'. 39324 39325 "The compiler's search directories" means all the directories where 39326'gcc' searches for passes of the compiler. This includes directories 39327that you specify with '-B'. 39328 39329 Cross-compilers search a little differently: 39330 39331 * 'real-ld' in the compiler's search directories. 39332 39333 * 'TARGET-real-ld' in 'PATH'. 39334 39335 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 39336 if specified. 39337 39338 * 'ld' in the compiler's search directories. 39339 39340 * 'TARGET-ld' in 'PATH'. 39341 39342 'collect2' explicitly avoids running 'ld' using the file name under 39343which 'collect2' itself was invoked. In fact, it remembers up a list of 39344such names--in case one copy of 'collect2' finds another copy (or 39345version) of 'collect2' installed as 'ld' in a second place in the search 39346path. 39347 39348 'collect2' searches for the utilities 'nm' and 'strip' using the same 39349algorithm as above for 'ld'. 39350 39351 39352File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 39353 3935421 Standard Header File Directories 39355*********************************** 39356 39357'GCC_INCLUDE_DIR' means the same thing for native and cross. It is 39358where GCC stores its private include files, and also where GCC stores 39359the fixed include files. A cross compiled GCC runs 'fixincludes' on the 39360header files in '$(tooldir)/include'. (If the cross compilation header 39361files need to be fixed, they must be installed before GCC is built. If 39362the cross compilation header files are already suitable for GCC, nothing 39363special need be done). 39364 39365 'GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 39366is where 'g++' looks first for header files. The C++ library installs 39367only target independent header files in that directory. 39368 39369 'LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 39370install anything there. It is normally '/usr/local/include'. This is 39371where local additions to a packaged system should place header files. 39372 39373 'CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 39374install anything there. 39375 39376 'TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 39377the place for other packages to install header files that GCC will use. 39378For a cross-compiler, this is the equivalent of '/usr/include'. When 39379you build a cross-compiler, 'fixincludes' processes any header files in 39380this directory. 39381 39382 39383File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top 39384 3938522 Memory Management and Type Information 39386***************************************** 39387 39388GCC uses some fairly sophisticated memory management techniques, which 39389involve determining information about GCC's data structures from GCC's 39390source code and using this information to perform garbage collection and 39391implement precompiled headers. 39392 39393 A full C++ parser would be too complicated for this task, so a limited 39394subset of C++ is interpreted and special markers are used to determine 39395what parts of the source to look at. All 'struct', 'union' and 39396'template' structure declarations that define data structures that are 39397allocated under control of the garbage collector must be marked. All 39398global variables that hold pointers to garbage-collected memory must 39399also be marked. Finally, all global variables that need to be saved and 39400restored by a precompiled header must be marked. (The precompiled 39401header mechanism can only save static variables if they're scalar. 39402Complex data structures must be allocated in garbage-collected memory to 39403be saved in a precompiled header.) 39404 39405 The full format of a marker is 39406 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 39407but in most cases no options are needed. The outer double parentheses 39408are still necessary, though: 'GTY(())'. Markers can appear: 39409 39410 * In a structure definition, before the open brace; 39411 * In a global variable declaration, after the keyword 'static' or 39412 'extern'; and 39413 * In a structure field definition, before the name of the field. 39414 39415 Here are some examples of marking simple data structures and globals. 39416 39417 struct GTY(()) TAG 39418 { 39419 FIELDS... 39420 }; 39421 39422 typedef struct GTY(()) TAG 39423 { 39424 FIELDS... 39425 } *TYPENAME; 39426 39427 static GTY(()) struct TAG *LIST; /* points to GC memory */ 39428 static GTY(()) int COUNTER; /* save counter in a PCH */ 39429 39430 The parser understands simple typedefs such as 'typedef struct TAG 39431*NAME;' and 'typedef int NAME;'. These don't need to be marked. 39432 39433 Since 'gengtype''s understanding of C++ is limited, there are several 39434constructs and declarations that are not supported inside 39435classes/structures marked for automatic GC code generation. The 39436following C++ constructs produce a 'gengtype' error on 39437structures/classes marked for automatic GC code generation: 39438 39439 * Type definitions inside classes/structures are not supported. 39440 * Enumerations inside classes/structures are not supported. 39441 39442 If you have a class or structure using any of the above constructs, you 39443need to mark that class as 'GTY ((user))' and provide your own marking 39444routines (see section *note User GC:: for details). 39445 39446 It is always valid to include function definitions inside classes. 39447Those are always ignored by 'gengtype', as it only cares about data 39448members. 39449 39450* Menu: 39451 39452* GTY Options:: What goes inside a 'GTY(())'. 39453* Inheritance and GTY:: Adding GTY to a class hierarchy. 39454* User GC:: Adding user-provided GC marking routines. 39455* GGC Roots:: Making global variables GGC roots. 39456* Files:: How the generated files work. 39457* Invoking the garbage collector:: How to invoke the garbage collector. 39458* Troubleshooting:: When something does not work as expected. 39459 39460 39461File: gccint.info, Node: GTY Options, Next: Inheritance and GTY, Up: Type Information 39462 3946322.1 The Inside of a 'GTY(())' 39464============================== 39465 39466Sometimes the C code is not enough to fully describe the type structure. 39467Extra information can be provided with 'GTY' options and additional 39468markers. Some options take a parameter, which may be either a string or 39469a type name, depending on the parameter. If an option takes no 39470parameter, it is acceptable either to omit the parameter entirely, or to 39471provide an empty string as a parameter. For example, 'GTY ((skip))' and 39472'GTY ((skip ("")))' are equivalent. 39473 39474 When the parameter is a string, often it is a fragment of C code. Four 39475special escapes may be used in these strings, to refer to pieces of the 39476data structure being marked: 39477 39478'%h' 39479 The current structure. 39480'%1' 39481 The structure that immediately contains the current structure. 39482'%0' 39483 The outermost structure that contains the current structure. 39484'%a' 39485 A partial expression of the form '[i1][i2]...' that indexes the 39486 array item currently being marked. 39487 39488 For instance, suppose that you have a structure of the form 39489 struct A { 39490 ... 39491 }; 39492 struct B { 39493 struct A foo[12]; 39494 }; 39495and 'b' is a variable of type 'struct B'. When marking 'b.foo[11]', 39496'%h' would expand to 'b.foo[11]', '%0' and '%1' would both expand to 39497'b', and '%a' would expand to '[11]'. 39498 39499 As in ordinary C, adjacent strings will be concatenated; this is 39500helpful when you have a complicated expression. 39501 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 39502 " ? TYPE_NEXT_VARIANT (&%h.generic)" 39503 " : TREE_CHAIN (&%h.generic)"))) 39504 39505 The available options are: 39506 39507'length ("EXPRESSION")' 39508 39509 There are two places the type machinery will need to be explicitly 39510 told the length of an array of non-atomic objects. The first case 39511 is when a structure ends in a variable-length array, like this: 39512 struct GTY(()) rtvec_def { 39513 int num_elem; /* number of elements */ 39514 rtx GTY ((length ("%h.num_elem"))) elem[1]; 39515 }; 39516 39517 In this case, the 'length' option is used to override the specified 39518 array length (which should usually be '1'). The parameter of the 39519 option is a fragment of C code that calculates the length. 39520 39521 The second case is when a structure or a global variable contains a 39522 pointer to an array, like this: 39523 struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter; 39524 In this case, 'iter' has been allocated by writing something like 39525 x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse); 39526 and the 'collapse' provides the length of the field. 39527 39528 This second use of 'length' also works on global variables, like: 39529 static GTY((length("reg_known_value_size"))) rtx *reg_known_value; 39530 39531 Note that the 'length' option is only meant for use with arrays of 39532 non-atomic objects, that is, objects that contain pointers pointing 39533 to other GTY-managed objects. For other GC-allocated arrays and 39534 strings you should use 'atomic'. 39535 39536'skip' 39537 39538 If 'skip' is applied to a field, the type machinery will ignore it. 39539 This is somewhat dangerous; the only safe use is in a union when 39540 one field really isn't ever used. 39541 39542 Use this to mark types that need to be marked by user gc routines, 39543 but are not refered to in a template argument. So if you have some 39544 user gc type T1 and a non user gc type T2 you can give T2 the 39545 for_user option so that the marking functions for T1 can call non 39546 mangled functions to mark T2. 39547 39548'desc ("EXPRESSION")' 39549'tag ("CONSTANT")' 39550'default' 39551 39552 The type machinery needs to be told which field of a 'union' is 39553 currently active. This is done by giving each field a constant 39554 'tag' value, and then specifying a discriminator using 'desc'. The 39555 value of the expression given by 'desc' is compared against each 39556 'tag' value, each of which should be different. If no 'tag' is 39557 matched, the field marked with 'default' is used if there is one, 39558 otherwise no field in the union will be marked. 39559 39560 In the 'desc' option, the "current structure" is the union that it 39561 discriminates. Use '%1' to mean the structure containing it. 39562 There are no escapes available to the 'tag' option, since it is a 39563 constant. 39564 39565 For example, 39566 struct GTY(()) tree_binding 39567 { 39568 struct tree_common common; 39569 union tree_binding_u { 39570 tree GTY ((tag ("0"))) scope; 39571 struct cp_binding_level * GTY ((tag ("1"))) level; 39572 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 39573 tree value; 39574 }; 39575 39576 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 39577 'struct tree_binding *' is presumed to be 0 or 1. If 1, the type 39578 mechanism will treat the field 'level' as being present and if 0, 39579 will treat the field 'scope' as being present. 39580 39581 The 'desc' and 'tag' options can also be used for inheritance to 39582 denote which subclass an instance is. See *note Inheritance and 39583 GTY:: for more information. 39584 39585'cache' 39586 39587 When the 'cache' option is applied to a global variable 39588 gt_clear_cache is called on that variable between the mark and 39589 sweep phases of garbage collection. The gt_clear_cache function is 39590 free to mark blocks as used, or to clear pointers in the variable. 39591 39592'deletable' 39593 39594 'deletable', when applied to a global variable, indicates that when 39595 garbage collection runs, there's no need to mark anything pointed 39596 to by this variable, it can just be set to 'NULL' instead. This is 39597 used to keep a list of free structures around for re-use. 39598 39599'maybe_undef' 39600 39601 When applied to a field, 'maybe_undef' indicates that it's OK if 39602 the structure that this fields points to is never defined, so long 39603 as this field is always 'NULL'. This is used to avoid requiring 39604 backends to define certain optional structures. It doesn't work 39605 with language frontends. 39606 39607'nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 39608 39609 The type machinery expects all pointers to point to the start of an 39610 object. Sometimes for abstraction purposes it's convenient to have 39611 a pointer which points inside an object. So long as it's possible 39612 to convert the original object to and from the pointer, such 39613 pointers can still be used. TYPE is the type of the original 39614 object, the TO EXPRESSION returns the pointer given the original 39615 object, and the FROM EXPRESSION returns the original object given 39616 the pointer. The pointer will be available using the '%h' escape. 39617 39618'chain_next ("EXPRESSION")' 39619'chain_prev ("EXPRESSION")' 39620'chain_circular ("EXPRESSION")' 39621 39622 It's helpful for the type machinery to know if objects are often 39623 chained together in long lists; this lets it generate code that 39624 uses less stack space by iterating along the list instead of 39625 recursing down it. 'chain_next' is an expression for the next item 39626 in the list, 'chain_prev' is an expression for the previous item. 39627 For singly linked lists, use only 'chain_next'; for doubly linked 39628 lists, use both. The machinery requires that taking the next item 39629 of the previous item gives the original item. 'chain_circular' is 39630 similar to 'chain_next', but can be used for circular single linked 39631 lists. 39632 39633'reorder ("FUNCTION NAME")' 39634 39635 Some data structures depend on the relative ordering of pointers. 39636 If the precompiled header machinery needs to change that ordering, 39637 it will call the function referenced by the 'reorder' option, 39638 before changing the pointers in the object that's pointed to by the 39639 field the option applies to. The function must take four 39640 arguments, with the signature 39641 'void *, void *, gt_pointer_operator, void *'. The first parameter 39642 is a pointer to the structure that contains the object being 39643 updated, or the object itself if there is no containing structure. 39644 The second parameter is a cookie that should be ignored. The third 39645 parameter is a routine that, given a pointer, will update it to its 39646 correct new value. The fourth parameter is a cookie that must be 39647 passed to the second parameter. 39648 39649 PCH cannot handle data structures that depend on the absolute 39650 values of pointers. 'reorder' functions can be expensive. When 39651 possible, it is better to depend on properties of the data, like an 39652 ID number or the hash of a string instead. 39653 39654'atomic' 39655 39656 The 'atomic' option can only be used with pointers. It informs the 39657 GC machinery that the memory that the pointer points to does not 39658 contain any pointers, and hence it should be treated by the GC and 39659 PCH machinery as an "atomic" block of memory that does not need to 39660 be examined when scanning memory for pointers. In particular, the 39661 machinery will not scan that memory for pointers to mark them as 39662 reachable (when marking pointers for GC) or to relocate them (when 39663 writing a PCH file). 39664 39665 The 'atomic' option differs from the 'skip' option. 'atomic' keeps 39666 the memory under Garbage Collection, but makes the GC ignore the 39667 contents of the memory. 'skip' is more drastic in that it causes 39668 the pointer and the memory to be completely ignored by the Garbage 39669 Collector. So, memory marked as 'atomic' is automatically freed 39670 when no longer reachable, while memory marked as 'skip' is not. 39671 39672 The 'atomic' option must be used with great care, because all sorts 39673 of problem can occur if used incorrectly, that is, if the memory 39674 the pointer points to does actually contain a pointer. 39675 39676 Here is an example of how to use it: 39677 struct GTY(()) my_struct { 39678 int number_of_elements; 39679 unsigned int * GTY ((atomic)) elements; 39680 }; 39681 In this case, 'elements' is a pointer under GC, and the memory it 39682 points to needs to be allocated using the Garbage Collector, and 39683 will be freed automatically by the Garbage Collector when it is no 39684 longer referenced. But the memory that the pointer points to is an 39685 array of 'unsigned int' elements, and the GC must not try to scan 39686 it to find pointers to mark or relocate, which is why it is marked 39687 with the 'atomic' option. 39688 39689 Note that, currently, global variables can not be marked with 39690 'atomic'; only fields of a struct can. This is a known limitation. 39691 It would be useful to be able to mark global pointers with 'atomic' 39692 to make the PCH machinery aware of them so that they are saved and 39693 restored correctly to PCH files. 39694 39695'special ("NAME")' 39696 39697 The 'special' option is used to mark types that have to be dealt 39698 with by special case machinery. The parameter is the name of the 39699 special case. See 'gengtype.c' for further details. Avoid adding 39700 new special cases unless there is no other alternative. 39701 39702'user' 39703 39704 The 'user' option indicates that the code to mark structure fields 39705 is completely handled by user-provided routines. See section *note 39706 User GC:: for details on what functions need to be provided. 39707 39708 39709File: gccint.info, Node: Inheritance and GTY, Next: User GC, Prev: GTY Options, Up: Type Information 39710 3971122.2 Support for inheritance 39712============================ 39713 39714gengtype has some support for simple class hierarchies. You can use 39715this to have gengtype autogenerate marking routines, provided: 39716 39717 * There must be a concrete base class, with a discriminator 39718 expression that can be used to identify which subclass an instance 39719 is. 39720 * Only single inheritance is used. 39721 * None of the classes within the hierarchy are templates. 39722 39723 If your class hierarchy does not fit in this pattern, you must use 39724*note User GC:: instead. 39725 39726 The base class and its discriminator must be identified using the 39727"desc" option. Each concrete subclass must use the "tag" option to 39728identify which value of the discriminator it corresponds to. 39729 39730 Every class in the hierarchy must have a 'GTY(())' marker, as gengtype 39731will only attempt to parse classes that have such a marker (1). 39732 39733 class GTY((desc("%h.kind"), tag("0"))) example_base 39734 { 39735 public: 39736 int kind; 39737 tree a; 39738 }; 39739 39740 class GTY((tag("1"))) some_subclass : public example_base 39741 { 39742 public: 39743 tree b; 39744 }; 39745 39746 class GTY((tag("2"))) some_other_subclass : public example_base 39747 { 39748 public: 39749 tree c; 39750 }; 39751 39752 The generated marking routines for the above will contain a "switch" on 39753"kind", visiting all appropriate fields. For example, if kind is 2, it 39754will cast to "some_other_subclass" and visit fields a, b, and c. 39755 39756 ---------- Footnotes ---------- 39757 39758 (1) Classes lacking such a marker will not be identified as being 39759part of the hierarchy, and so the marking routines will not handle them, 39760leading to a assertion failure within the marking routines due to an 39761unknown tag value (assuming that assertions are enabled). 39762 39763 39764File: gccint.info, Node: User GC, Next: GGC Roots, Prev: Inheritance and GTY, Up: Type Information 39765 3976622.3 Support for user-provided GC marking routines 39767================================================== 39768 39769The garbage collector supports types for which no automatic marking code 39770is generated. For these types, the user is required to provide three 39771functions: one to act as a marker for garbage collection, and two 39772functions to act as marker and pointer walker for pre-compiled headers. 39773 39774 Given a structure 'struct GTY((user)) my_struct', the following 39775functions should be defined to mark 'my_struct': 39776 39777 void gt_ggc_mx (my_struct *p) 39778 { 39779 /* This marks field 'fld'. */ 39780 gt_ggc_mx (p->fld); 39781 } 39782 39783 void gt_pch_nx (my_struct *p) 39784 { 39785 /* This marks field 'fld'. */ 39786 gt_pch_nx (tp->fld); 39787 } 39788 39789 void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie) 39790 { 39791 /* For every field 'fld', call the given pointer operator. */ 39792 op (&(tp->fld), cookie); 39793 } 39794 39795 In general, each marker 'M' should call 'M' for every pointer field in 39796the structure. Fields that are not allocated in GC or are not pointers 39797must be ignored. 39798 39799 For embedded lists (e.g., structures with a 'next' or 'prev' pointer), 39800the marker must follow the chain and mark every element in it. 39801 39802 Note that the rules for the pointer walker 'gt_pch_nx (my_struct *, 39803gt_pointer_operator, void *)' are slightly different. In this case, the 39804operation 'op' must be applied to the _address_ of every pointer field. 39805 3980622.3.1 User-provided marking routines for template types 39807-------------------------------------------------------- 39808 39809When a template type 'TP' is marked with 'GTY', all instances of that 39810type are considered user-provided types. This means that the individual 39811instances of 'TP' do not need to be marked with 'GTY'. The user needs 39812to provide template functions to mark all the fields of the type. 39813 39814 The following code snippets represent all the functions that need to be 39815provided. Note that type 'TP' may reference to more than one type. In 39816these snippets, there is only one type 'T', but there could be more. 39817 39818 template<typename T> 39819 void gt_ggc_mx (TP<T> *tp) 39820 { 39821 extern void gt_ggc_mx (T&); 39822 39823 /* This marks field 'fld' of type 'T'. */ 39824 gt_ggc_mx (tp->fld); 39825 } 39826 39827 template<typename T> 39828 void gt_pch_nx (TP<T> *tp) 39829 { 39830 extern void gt_pch_nx (T&); 39831 39832 /* This marks field 'fld' of type 'T'. */ 39833 gt_pch_nx (tp->fld); 39834 } 39835 39836 template<typename T> 39837 void gt_pch_nx (TP<T *> *tp, gt_pointer_operator op, void *cookie) 39838 { 39839 /* For every field 'fld' of 'tp' with type 'T *', call the given 39840 pointer operator. */ 39841 op (&(tp->fld), cookie); 39842 } 39843 39844 template<typename T> 39845 void gt_pch_nx (TP<T> *tp, gt_pointer_operator, void *cookie) 39846 { 39847 extern void gt_pch_nx (T *, gt_pointer_operator, void *); 39848 39849 /* For every field 'fld' of 'tp' with type 'T', call the pointer 39850 walker for all the fields of T. */ 39851 gt_pch_nx (&(tp->fld), op, cookie); 39852 } 39853 39854 Support for user-defined types is currently limited. The following 39855restrictions apply: 39856 39857 1. Type 'TP' and all the argument types 'T' must be marked with 'GTY'. 39858 39859 2. Type 'TP' can only have type names in its argument list. 39860 39861 3. The pointer walker functions are different for 'TP<T>' and 'TP<T 39862 *>'. In the case of 'TP<T>', references to 'T' must be handled by 39863 calling 'gt_pch_nx' (which will, in turn, walk all the pointers 39864 inside fields of 'T'). In the case of 'TP<T *>', references to 'T 39865 *' must be handled by calling the 'op' function on the address of 39866 the pointer (see the code snippets above). 39867 39868 39869File: gccint.info, Node: GGC Roots, Next: Files, Prev: User GC, Up: Type Information 39870 3987122.4 Marking Roots for the Garbage Collector 39872============================================ 39873 39874In addition to keeping track of types, the type machinery also locates 39875the global variables ("roots") that the garbage collector starts at. 39876Roots must be declared using one of the following syntaxes: 39877 39878 * 'extern GTY(([OPTIONS])) TYPE NAME;' 39879 * 'static GTY(([OPTIONS])) TYPE NAME;' 39880The syntax 39881 * 'GTY(([OPTIONS])) TYPE NAME;' 39882is _not_ accepted. There should be an 'extern' declaration of such a 39883variable in a header somewhere--mark that, not the definition. Or, if 39884the variable is only used in one file, make it 'static'. 39885 39886 39887File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information 39888 3988922.5 Source Files Containing Type Information 39890============================================= 39891 39892Whenever you add 'GTY' markers to a source file that previously had 39893none, or create a new source file containing 'GTY' markers, there are 39894three things you need to do: 39895 39896 1. You need to add the file to the list of source files the type 39897 machinery scans. There are four cases: 39898 39899 a. For a back-end file, this is usually done automatically; if 39900 not, you should add it to 'target_gtfiles' in the appropriate 39901 port's entries in 'config.gcc'. 39902 39903 b. For files shared by all front ends, add the filename to the 39904 'GTFILES' variable in 'Makefile.in'. 39905 39906 c. For files that are part of one front end, add the filename to 39907 the 'gtfiles' variable defined in the appropriate 39908 'config-lang.in'. Headers should appear before non-headers in 39909 this list. 39910 39911 d. For files that are part of some but not all front ends, add 39912 the filename to the 'gtfiles' variable of _all_ the front ends 39913 that use it. 39914 39915 2. If the file was a header file, you'll need to check that it's 39916 included in the right place to be visible to the generated files. 39917 For a back-end header file, this should be done automatically. For 39918 a front-end header file, it needs to be included by the same file 39919 that includes 'gtype-LANG.h'. For other header files, it needs to 39920 be included in 'gtype-desc.c', which is a generated file, so add it 39921 to 'ifiles' in 'open_base_file' in 'gengtype.c'. 39922 39923 For source files that aren't header files, the machinery will 39924 generate a header file that should be included in the source file 39925 you just changed. The file will be called 'gt-PATH.h' where PATH 39926 is the pathname relative to the 'gcc' directory with slashes 39927 replaced by -, so for example the header file to be included in 39928 'cp/parser.c' is called 'gt-cp-parser.c'. The generated header 39929 file should be included after everything else in the source file. 39930 Don't forget to mention this file as a dependency in the 39931 'Makefile'! 39932 39933 For language frontends, there is another file that needs to be included 39934somewhere. It will be called 'gtype-LANG.h', where LANG is the name of 39935the subdirectory the language is contained in. 39936 39937 Plugins can add additional root tables. Run the 'gengtype' utility in 39938plugin mode as 'gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C' 39939with your plugin files PLUGIN*.C using 'GTY' to generate the PLUGINOUT.H 39940file. The GCC build tree is needed to be present in that mode. 39941 39942 39943File: gccint.info, Node: Invoking the garbage collector, Next: Troubleshooting, Prev: Files, Up: Type Information 39944 3994522.6 How to invoke the garbage collector 39946======================================== 39947 39948The GCC garbage collector GGC is only invoked explicitly. In contrast 39949with many other garbage collectors, it is not implicitly invoked by 39950allocation routines when a lot of memory has been consumed. So the only 39951way to have GGC reclaim storage is to call the 'ggc_collect' function 39952explicitly. This call is an expensive operation, as it may have to scan 39953the entire heap. Beware that local variables (on the GCC call stack) 39954are not followed by such an invocation (as many other garbage collectors 39955do): you should reference all your data from static or external 'GTY'-ed 39956variables, and it is advised to call 'ggc_collect' with a shallow call 39957stack. The GGC is an exact mark and sweep garbage collector (so it does 39958not scan the call stack for pointers). In practice GCC passes don't 39959often call 'ggc_collect' themselves, because it is called by the pass 39960manager between passes. 39961 39962 At the time of the 'ggc_collect' call all pointers in the GC-marked 39963structures must be valid or 'NULL'. In practice this means that there 39964should not be uninitialized pointer fields in the structures even if 39965your code never reads or writes those fields at a particular instance. 39966One way to ensure this is to use cleared versions of allocators unless 39967all the fields are initialized manually immediately after allocation. 39968 39969 39970File: gccint.info, Node: Troubleshooting, Prev: Invoking the garbage collector, Up: Type Information 39971 3997222.7 Troubleshooting the garbage collector 39973========================================== 39974 39975With the current garbage collector implementation, most issues should 39976show up as GCC compilation errors. Some of the most commonly 39977encountered issues are described below. 39978 39979 * Gengtype does not produce allocators for a 'GTY'-marked type. 39980 Gengtype checks if there is at least one possible path from GC 39981 roots to at least one instance of each type before outputting 39982 allocators. If there is no such path, the 'GTY' markers will be 39983 ignored and no allocators will be output. Solve this by making 39984 sure that there exists at least one such path. If creating it is 39985 unfeasible or raises a "code smell", consider if you really must 39986 use GC for allocating such type. 39987 39988 * Link-time errors about undefined 'gt_ggc_r_foo_bar' and 39989 similarly-named symbols. Check if your 'foo_bar' source file has 39990 '#include "gt-foo_bar.h"' as its very last line. 39991 39992 39993File: gccint.info, Node: Plugins, Next: LTO, Prev: Type Information, Up: Top 39994 3999523 Plugins 39996********** 39997 39998GCC plugins are loadable modules that provide extra features to the 39999compiler. Like GCC itself they can be distributed in source and binary 40000forms. 40001 40002 GCC plugins provide developers with a rich subset of the GCC API to 40003allow them to extend GCC as they see fit. Whether it is writing an 40004additional optimization pass, transforming code, or analyzing 40005information, plugins can be quite useful. 40006 40007* Menu: 40008 40009* Plugins loading:: How can we load plugins. 40010* Plugin API:: The APIs for plugins. 40011* Plugins pass:: How a plugin interact with the pass manager. 40012* Plugins GC:: How a plugin Interact with GCC Garbage Collector. 40013* Plugins description:: Giving information about a plugin itself. 40014* Plugins attr:: Registering custom attributes or pragmas. 40015* Plugins recording:: Recording information about pass execution. 40016* Plugins gate:: Controlling which passes are being run. 40017* Plugins tracking:: Keeping track of available passes. 40018* Plugins building:: How can we build a plugin. 40019 40020 40021File: gccint.info, Node: Plugins loading, Next: Plugin API, Up: Plugins 40022 4002323.1 Loading Plugins 40024==================== 40025 40026Plugins are supported on platforms that support '-ldl -rdynamic'. They 40027are loaded by the compiler using 'dlopen' and invoked at pre-determined 40028locations in the compilation process. 40029 40030 Plugins are loaded with 40031 40032 '-fplugin=/path/to/NAME.so' '-fplugin-arg-NAME-KEY1[=VALUE1]' 40033 40034 The plugin arguments are parsed by GCC and passed to respective plugins 40035as key-value pairs. Multiple plugins can be invoked by specifying 40036multiple '-fplugin' arguments. 40037 40038 A plugin can be simply given by its short name (no dots or slashes). 40039When simply passing '-fplugin=NAME', the plugin is loaded from the 40040'plugin' directory, so '-fplugin=NAME' is the same as '-fplugin=`gcc 40041-print-file-name=plugin`/NAME.so', using backquote shell syntax to query 40042the 'plugin' directory. 40043 40044 40045File: gccint.info, Node: Plugin API, Next: Plugins pass, Prev: Plugins loading, Up: Plugins 40046 4004723.2 Plugin API 40048=============== 40049 40050Plugins are activated by the compiler at specific events as defined in 40051'gcc-plugin.h'. For each event of interest, the plugin should call 40052'register_callback' specifying the name of the event and address of the 40053callback function that will handle that event. 40054 40055 The header 'gcc-plugin.h' must be the first gcc header to be included. 40056 4005723.2.1 Plugin license check 40058--------------------------- 40059 40060Every plugin should define the global symbol 'plugin_is_GPL_compatible' 40061to assert that it has been licensed under a GPL-compatible license. If 40062this symbol does not exist, the compiler will emit a fatal error and 40063exit with the error message: 40064 40065 fatal error: plugin NAME is not licensed under a GPL-compatible license 40066 NAME: undefined symbol: plugin_is_GPL_compatible 40067 compilation terminated 40068 40069 The declared type of the symbol should be int, to match a forward 40070declaration in 'gcc-plugin.h' that suppresses C++ mangling. It does not 40071need to be in any allocated section, though. The compiler merely 40072asserts that the symbol exists in the global scope. Something like this 40073is enough: 40074 40075 int plugin_is_GPL_compatible; 40076 4007723.2.2 Plugin initialization 40078---------------------------- 40079 40080Every plugin should export a function called 'plugin_init' that is 40081called right after the plugin is loaded. This function is responsible 40082for registering all the callbacks required by the plugin and do any 40083other required initialization. 40084 40085 This function is called from 'compile_file' right before invoking the 40086parser. The arguments to 'plugin_init' are: 40087 40088 * 'plugin_info': Plugin invocation information. 40089 * 'version': GCC version. 40090 40091 The 'plugin_info' struct is defined as follows: 40092 40093 struct plugin_name_args 40094 { 40095 char *base_name; /* Short name of the plugin 40096 (filename without .so suffix). */ 40097 const char *full_name; /* Path to the plugin as specified with 40098 -fplugin=. */ 40099 int argc; /* Number of arguments specified with 40100 -fplugin-arg-.... */ 40101 struct plugin_argument *argv; /* Array of ARGC key-value pairs. */ 40102 const char *version; /* Version string provided by plugin. */ 40103 const char *help; /* Help string provided by plugin. */ 40104 } 40105 40106 If initialization fails, 'plugin_init' must return a non-zero value. 40107Otherwise, it should return 0. 40108 40109 The version of the GCC compiler loading the plugin is described by the 40110following structure: 40111 40112 struct plugin_gcc_version 40113 { 40114 const char *basever; 40115 const char *datestamp; 40116 const char *devphase; 40117 const char *revision; 40118 const char *configuration_arguments; 40119 }; 40120 40121 The function 'plugin_default_version_check' takes two pointers to such 40122structure and compare them field by field. It can be used by the 40123plugin's 'plugin_init' function. 40124 40125 The version of GCC used to compile the plugin can be found in the 40126symbol 'gcc_version' defined in the header 'plugin-version.h'. The 40127recommended version check to perform looks like 40128 40129 #include "plugin-version.h" 40130 ... 40131 40132 int 40133 plugin_init (struct plugin_name_args *plugin_info, 40134 struct plugin_gcc_version *version) 40135 { 40136 if (!plugin_default_version_check (version, &gcc_version)) 40137 return 1; 40138 40139 } 40140 40141 but you can also check the individual fields if you want a less strict 40142check. 40143 4014423.2.3 Plugin callbacks 40145----------------------- 40146 40147Callback functions have the following prototype: 40148 40149 /* The prototype for a plugin callback function. 40150 gcc_data - event-specific data provided by GCC 40151 user_data - plugin-specific data provided by the plug-in. */ 40152 typedef void (*plugin_callback_func)(void *gcc_data, void *user_data); 40153 40154 Callbacks can be invoked at the following pre-determined events: 40155 40156 enum plugin_event 40157 { 40158 PLUGIN_START_PARSE_FUNCTION, /* Called before parsing the body of a function. */ 40159 PLUGIN_FINISH_PARSE_FUNCTION, /* After finishing parsing a function. */ 40160 PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */ 40161 PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */ 40162 PLUGIN_FINISH_DECL, /* After finishing parsing a declaration. */ 40163 PLUGIN_FINISH_UNIT, /* Useful for summary processing. */ 40164 PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */ 40165 PLUGIN_FINISH, /* Called before GCC exits. */ 40166 PLUGIN_INFO, /* Information about the plugin. */ 40167 PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */ 40168 PLUGIN_GGC_MARKING, /* Extend the GGC marking. */ 40169 PLUGIN_GGC_END, /* Called at end of GGC. */ 40170 PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */ 40171 PLUGIN_ATTRIBUTES, /* Called during attribute registration */ 40172 PLUGIN_START_UNIT, /* Called before processing a translation unit. */ 40173 PLUGIN_PRAGMAS, /* Called during pragma registration. */ 40174 /* Called before first pass from all_passes. */ 40175 PLUGIN_ALL_PASSES_START, 40176 /* Called after last pass from all_passes. */ 40177 PLUGIN_ALL_PASSES_END, 40178 /* Called before first ipa pass. */ 40179 PLUGIN_ALL_IPA_PASSES_START, 40180 /* Called after last ipa pass. */ 40181 PLUGIN_ALL_IPA_PASSES_END, 40182 /* Allows to override pass gate decision for current_pass. */ 40183 PLUGIN_OVERRIDE_GATE, 40184 /* Called before executing a pass. */ 40185 PLUGIN_PASS_EXECUTION, 40186 /* Called before executing subpasses of a GIMPLE_PASS in 40187 execute_ipa_pass_list. */ 40188 PLUGIN_EARLY_GIMPLE_PASSES_START, 40189 /* Called after executing subpasses of a GIMPLE_PASS in 40190 execute_ipa_pass_list. */ 40191 PLUGIN_EARLY_GIMPLE_PASSES_END, 40192 /* Called when a pass is first instantiated. */ 40193 PLUGIN_NEW_PASS, 40194 /* Called when a file is #include-d or given via the #line directive. 40195 This could happen many times. The event data is the included file path, 40196 as a const char* pointer. */ 40197 PLUGIN_INCLUDE_FILE, 40198 40199 PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback 40200 array. */ 40201 }; 40202 40203 In addition, plugins can also look up the enumerator of a named event, 40204and / or generate new events dynamically, by calling the function 40205'get_named_event_id'. 40206 40207 To register a callback, the plugin calls 'register_callback' with the 40208arguments: 40209 40210 * 'char *name': Plugin name. 40211 * 'int event': The event code. 40212 * 'plugin_callback_func callback': The function that handles 'event'. 40213 * 'void *user_data': Pointer to plugin-specific data. 40214 40215 For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, and 40216PLUGIN_REGISTER_GGC_ROOTS pseudo-events the 'callback' should be null, 40217and the 'user_data' is specific. 40218 40219 When the PLUGIN_PRAGMAS event is triggered (with a null pointer as data 40220from GCC), plugins may register their own pragmas. Notice that pragmas 40221are not available from 'lto1', so plugins used with '-flto' option to 40222GCC during link-time optimization cannot use pragmas and do not even see 40223functions like 'c_register_pragma' or 'pragma_lex'. 40224 40225 The PLUGIN_INCLUDE_FILE event, with a 'const char*' file path as GCC 40226data, is triggered for processing of '#include' or '#line' directives. 40227 40228 The PLUGIN_FINISH event is the last time that plugins can call GCC 40229functions, notably emit diagnostics with 'warning', 'error' etc. 40230 40231 40232File: gccint.info, Node: Plugins pass, Next: Plugins GC, Prev: Plugin API, Up: Plugins 40233 4023423.3 Interacting with the pass manager 40235====================================== 40236 40237There needs to be a way to add/reorder/remove passes dynamically. This 40238is useful for both analysis plugins (plugging in after a certain pass 40239such as CFG or an IPA pass) and optimization plugins. 40240 40241 Basic support for inserting new passes or replacing existing passes is 40242provided. A plugin registers a new pass with GCC by calling 40243'register_callback' with the 'PLUGIN_PASS_MANAGER_SETUP' event and a 40244pointer to a 'struct register_pass_info' object defined as follows 40245 40246 enum pass_positioning_ops 40247 { 40248 PASS_POS_INSERT_AFTER, // Insert after the reference pass. 40249 PASS_POS_INSERT_BEFORE, // Insert before the reference pass. 40250 PASS_POS_REPLACE // Replace the reference pass. 40251 }; 40252 40253 struct register_pass_info 40254 { 40255 struct opt_pass *pass; /* New pass provided by the plugin. */ 40256 const char *reference_pass_name; /* Name of the reference pass for hooking 40257 up the new pass. */ 40258 int ref_pass_instance_number; /* Insert the pass at the specified 40259 instance number of the reference pass. */ 40260 /* Do it for every instance if it is 0. */ 40261 enum pass_positioning_ops pos_op; /* how to insert the new pass. */ 40262 }; 40263 40264 40265 /* Sample plugin code that registers a new pass. */ 40266 int 40267 plugin_init (struct plugin_name_args *plugin_info, 40268 struct plugin_gcc_version *version) 40269 { 40270 struct register_pass_info pass_info; 40271 40272 ... 40273 40274 /* Code to fill in the pass_info object with new pass information. */ 40275 40276 ... 40277 40278 /* Register the new pass. */ 40279 register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info); 40280 40281 ... 40282 } 40283 40284 40285File: gccint.info, Node: Plugins GC, Next: Plugins description, Prev: Plugins pass, Up: Plugins 40286 4028723.4 Interacting with the GCC Garbage Collector 40288=============================================== 40289 40290Some plugins may want to be informed when GGC (the GCC Garbage 40291Collector) is running. They can register callbacks for the 40292'PLUGIN_GGC_START' and 'PLUGIN_GGC_END' events (for which the callback 40293is called with a null 'gcc_data') to be notified of the start or end of 40294the GCC garbage collection. 40295 40296 Some plugins may need to have GGC mark additional data. This can be 40297done by registering a callback (called with a null 'gcc_data') for the 40298'PLUGIN_GGC_MARKING' event. Such callbacks can call the 'ggc_set_mark' 40299routine, preferably through the 'ggc_mark' macro (and conversely, these 40300routines should usually not be used in plugins outside of the 40301'PLUGIN_GGC_MARKING' event). Plugins that wish to hold weak references 40302to gc data may also use this event to drop weak references when the 40303object is about to be collected. The 'ggc_marked_p' function can be 40304used to tell if an object is marked, or is about to be collected. The 40305'gt_clear_cache' overloads which some types define may also be of use in 40306managing weak references. 40307 40308 Some plugins may need to add extra GGC root tables, e.g. to handle 40309their own 'GTY'-ed data. This can be done with the 40310'PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the 40311extra root table (of type 'struct ggc_root_tab*') as 'user_data'. 40312Running the 'gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility 40313generates these extra root tables. 40314 40315 You should understand the details of memory management inside GCC 40316before using 'PLUGIN_GGC_MARKING' or 'PLUGIN_REGISTER_GGC_ROOTS'. 40317 40318 40319File: gccint.info, Node: Plugins description, Next: Plugins attr, Prev: Plugins GC, Up: Plugins 40320 4032123.5 Giving information about a plugin 40322====================================== 40323 40324A plugin should give some information to the user about itself. This 40325uses the following structure: 40326 40327 struct plugin_info 40328 { 40329 const char *version; 40330 const char *help; 40331 }; 40332 40333 Such a structure is passed as the 'user_data' by the plugin's init 40334routine using 'register_callback' with the 'PLUGIN_INFO' pseudo-event 40335and a null callback. 40336 40337 40338File: gccint.info, Node: Plugins attr, Next: Plugins recording, Prev: Plugins description, Up: Plugins 40339 4034023.6 Registering custom attributes or pragmas 40341============================================= 40342 40343For analysis (or other) purposes it is useful to be able to add custom 40344attributes or pragmas. 40345 40346 The 'PLUGIN_ATTRIBUTES' callback is called during attribute 40347registration. Use the 'register_attribute' function to register custom 40348attributes. 40349 40350 /* Attribute handler callback */ 40351 static tree 40352 handle_user_attribute (tree *node, tree name, tree args, 40353 int flags, bool *no_add_attrs) 40354 { 40355 return NULL_TREE; 40356 } 40357 40358 /* Attribute definition */ 40359 static struct attribute_spec user_attr = 40360 { "user", 1, 1, false, false, false, handle_user_attribute, false }; 40361 40362 /* Plugin callback called during attribute registration. 40363 Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL) 40364 */ 40365 static void 40366 register_attributes (void *event_data, void *data) 40367 { 40368 warning (0, G_("Callback to register attributes")); 40369 register_attribute (&user_attr); 40370 } 40371 40372 40373 The PLUGIN_PRAGMAS callback is called once during pragmas registration. 40374Use the 'c_register_pragma', 'c_register_pragma_with_data', 40375'c_register_pragma_with_expansion', 40376'c_register_pragma_with_expansion_and_data' functions to register custom 40377pragmas and their handlers (which often want to call 'pragma_lex') from 40378'c-family/c-pragma.h'. 40379 40380 /* Plugin callback called during pragmas registration. Registered with 40381 register_callback (plugin_name, PLUGIN_PRAGMAS, 40382 register_my_pragma, NULL); 40383 */ 40384 static void 40385 register_my_pragma (void *event_data, void *data) 40386 { 40387 warning (0, G_("Callback to register pragmas")); 40388 c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello); 40389 } 40390 40391 It is suggested to pass '"GCCPLUGIN"' (or a short name identifying your 40392plugin) as the "space" argument of your pragma. 40393 40394 Pragmas registered with 'c_register_pragma_with_expansion' or 40395'c_register_pragma_with_expansion_and_data' support preprocessor 40396expansions. For example: 40397 40398 #define NUMBER 10 40399 #pragma GCCPLUGIN foothreshold (NUMBER) 40400 40401 40402File: gccint.info, Node: Plugins recording, Next: Plugins gate, Prev: Plugins attr, Up: Plugins 40403 4040423.7 Recording information about pass execution 40405=============================================== 40406 40407The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass 40408(the same as current_pass) as 'gcc_data' to the callback. You can also 40409inspect cfun to find out about which function this pass is executed for. 40410Note that this event will only be invoked if the gate check (if 40411applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use 40412other hooks, like 'PLUGIN_ALL_PASSES_START', 'PLUGIN_ALL_PASSES_END', 40413'PLUGIN_ALL_IPA_PASSES_START', 'PLUGIN_ALL_IPA_PASSES_END', 40414'PLUGIN_EARLY_GIMPLE_PASSES_START', and/or 40415'PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your 40416plugin(s) in order to get context for the pass execution. 40417 40418 40419File: gccint.info, Node: Plugins gate, Next: Plugins tracking, Prev: Plugins recording, Up: Plugins 40420 4042123.8 Controlling which passes are being run 40422=========================================== 40423 40424After the original gate function for a pass is called, its result - the 40425gate status - is stored as an integer. Then the event 40426'PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in 40427the 'gcc_data' parameter to the callback function. A nonzero value of 40428the gate status means that the pass is to be executed. You can both 40429read and write the gate status via the passed pointer. 40430 40431 40432File: gccint.info, Node: Plugins tracking, Next: Plugins building, Prev: Plugins gate, Up: Plugins 40433 4043423.9 Keeping track of available passes 40435====================================== 40436 40437When your plugin is loaded, you can inspect the various pass lists to 40438determine what passes are available. However, other plugins might add 40439new passes. Also, future changes to GCC might cause generic passes to 40440be added after plugin loading. When a pass is first added to one of the 40441pass lists, the event 'PLUGIN_NEW_PASS' is invoked, with the callback 40442parameter 'gcc_data' pointing to the new pass. 40443 40444 40445File: gccint.info, Node: Plugins building, Prev: Plugins tracking, Up: Plugins 40446 4044723.10 Building GCC plugins 40448========================== 40449 40450If plugins are enabled, GCC installs the headers needed to build a 40451plugin (somewhere in the installation tree, e.g. under '/usr/local'). 40452In particular a 'plugin/include' directory is installed, containing all 40453the header files needed to build plugins. 40454 40455 On most systems, you can query this 'plugin' directory by invoking 'gcc 40456-print-file-name=plugin' (replace if needed 'gcc' with the appropriate 40457program path). 40458 40459 Inside plugins, this 'plugin' directory name can be queried by calling 40460'default_plugin_dir_name ()'. 40461 40462 Plugins may know, when they are compiled, the GCC version for which 40463'plugin-version.h' is provided. The constant macros 40464'GCCPLUGIN_VERSION_MAJOR', 'GCCPLUGIN_VERSION_MINOR', 40465'GCCPLUGIN_VERSION_PATCHLEVEL', 'GCCPLUGIN_VERSION' are integer numbers, 40466so a plugin could ensure it is built for GCC 4.7 with 40467 #if GCCPLUGIN_VERSION != 4007 40468 #error this GCC plugin is for GCC 4.7 40469 #endif 40470 40471 The following GNU Makefile excerpt shows how to build a simple plugin: 40472 40473 HOST_GCC=g++ 40474 TARGET_GCC=gcc 40475 PLUGIN_SOURCE_FILES= plugin1.c plugin2.cc 40476 GCCPLUGINS_DIR:= $(shell $(TARGET_GCC) -print-file-name=plugin) 40477 CXXFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -fno-rtti -O2 40478 40479 plugin.so: $(PLUGIN_SOURCE_FILES) 40480 $(HOST_GCC) -shared $(CXXFLAGS) $^ -o $@ 40481 40482 A single source file plugin may be built with 'g++ -I`gcc 40483-print-file-name=plugin`/include -fPIC -shared -fno-rtti -O2 plugin.c -o 40484plugin.so', using backquote shell syntax to query the 'plugin' 40485directory. 40486 40487 When a plugin needs to use 'gengtype', be sure that both 'gengtype' and 40488'gtype.state' have the same version as the GCC for which the plugin is 40489built. 40490 40491 40492File: gccint.info, Node: LTO, Next: Match and Simplify, Prev: Plugins, Up: Top 40493 4049424 Link Time Optimization 40495************************* 40496 40497Link Time Optimization (LTO) gives GCC the capability of dumping its 40498internal representation (GIMPLE) to disk, so that all the different 40499compilation units that make up a single executable can be optimized as a 40500single module. This expands the scope of inter-procedural optimizations 40501to encompass the whole program (or, rather, everything that is visible 40502at link time). 40503 40504* Menu: 40505 40506* LTO Overview:: Overview of LTO. 40507* LTO object file layout:: LTO file sections in ELF. 40508* IPA:: Using summary information in IPA passes. 40509* WHOPR:: Whole program assumptions, 40510 linker plugin and symbol visibilities. 40511* Internal flags:: Internal flags controlling 'lto1'. 40512 40513 40514File: gccint.info, Node: LTO Overview, Next: LTO object file layout, Up: LTO 40515 4051624.1 Design Overview 40517==================== 40518 40519Link time optimization is implemented as a GCC front end for a bytecode 40520representation of GIMPLE that is emitted in special sections of '.o' 40521files. Currently, LTO support is enabled in most ELF-based systems, as 40522well as darwin, cygwin and mingw systems. 40523 40524 Since GIMPLE bytecode is saved alongside final object code, object 40525files generated with LTO support are larger than regular object files. 40526This "fat" object format makes it easy to integrate LTO into existing 40527build systems, as one can, for instance, produce archives of the files. 40528Additionally, one might be able to ship one set of fat objects which 40529could be used both for development and the production of optimized 40530builds. A, perhaps surprising, side effect of this feature is that any 40531mistake in the toolchain leads to LTO information not being used (e.g. 40532an older 'libtool' calling 'ld' directly). This is both an advantage, 40533as the system is more robust, and a disadvantage, as the user is not 40534informed that the optimization has been disabled. 40535 40536 The current implementation only produces "fat" objects, effectively 40537doubling compilation time and increasing file sizes up to 5x the 40538original size. This hides the problem that some tools, such as 'ar' and 40539'nm', need to understand symbol tables of LTO sections. These tools 40540were extended to use the plugin infrastructure, and with these problems 40541solved, GCC will also support "slim" objects consisting of the 40542intermediate code alone. 40543 40544 At the highest level, LTO splits the compiler in two. The first half 40545(the "writer") produces a streaming representation of all the internal 40546data structures needed to optimize and generate code. This includes 40547declarations, types, the callgraph and the GIMPLE representation of 40548function bodies. 40549 40550 When '-flto' is given during compilation of a source file, the pass 40551manager executes all the passes in 'all_lto_gen_passes'. Currently, 40552this phase is composed of two IPA passes: 40553 40554 * 'pass_ipa_lto_gimple_out' This pass executes the function 40555 'lto_output' in 'lto-streamer-out.c', which traverses the call 40556 graph encoding every reachable declaration, type and function. 40557 This generates a memory representation of all the file sections 40558 described below. 40559 40560 * 'pass_ipa_lto_finish_out' This pass executes the function 40561 'produce_asm_for_decls' in 'lto-streamer-out.c', which takes the 40562 memory image built in the previous pass and encodes it in the 40563 corresponding ELF file sections. 40564 40565 The second half of LTO support is the "reader". This is implemented as 40566the GCC front end 'lto1' in 'lto/lto.c'. When 'collect2' detects a link 40567set of '.o'/'.a' files with LTO information and the '-flto' is enabled, 40568it invokes 'lto1' which reads the set of files and aggregates them into 40569a single translation unit for optimization. The main entry point for 40570the reader is 'lto/lto.c':'lto_main'. 40571 4057224.1.1 LTO modes of operation 40573----------------------------- 40574 40575One of the main goals of the GCC link-time infrastructure was to allow 40576effective compilation of large programs. For this reason GCC implements 40577two link-time compilation modes. 40578 40579 1. _LTO mode_, in which the whole program is read into the compiler at 40580 link-time and optimized in a similar way as if it were a single 40581 source-level compilation unit. 40582 40583 2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs 40584 and/or a distributed compilation environment to quickly link large 40585 applications. WHOPR stands for WHOle Program optimizeR (not to be 40586 confused with the semantics of '-fwhole-program'). It partitions 40587 the aggregated callgraph from many different '.o' files and 40588 distributes the compilation of the sub-graphs to different CPUs. 40589 40590 Note that distributed compilation is not implemented yet, but since 40591 the parallelism is facilitated via generating a 'Makefile', it 40592 would be easy to implement. 40593 40594 WHOPR splits LTO into three main stages: 40595 1. Local generation (LGEN) This stage executes in parallel. Every 40596 file in the program is compiled into the intermediate language and 40597 packaged together with the local call-graph and summary 40598 information. This stage is the same for both the LTO and WHOPR 40599 compilation mode. 40600 40601 2. Whole Program Analysis (WPA) WPA is performed sequentially. The 40602 global call-graph is generated, and a global analysis procedure 40603 makes transformation decisions. The global call-graph is 40604 partitioned to facilitate parallel optimization during phase 3. 40605 The results of the WPA stage are stored into new object files which 40606 contain the partitions of program expressed in the intermediate 40607 language and the optimization decisions. 40608 40609 3. Local transformations (LTRANS) This stage executes in parallel. 40610 All the decisions made during phase 2 are implemented locally in 40611 each partitioned object file, and the final object code is 40612 generated. Optimizations which cannot be decided efficiently 40613 during the phase 2 may be performed on the local call-graph 40614 partitions. 40615 40616 WHOPR can be seen as an extension of the usual LTO mode of compilation. 40617In LTO, WPA and LTRANS are executed within a single execution of the 40618compiler, after the whole program has been read into memory. 40619 40620 When compiling in WHOPR mode, the callgraph is partitioned during the 40621WPA stage. The whole program is split into a given number of partitions 40622of roughly the same size. The compiler tries to minimize the number of 40623references which cross partition boundaries. The main advantage of 40624WHOPR is to allow the parallel execution of LTRANS stages, which are the 40625most time-consuming part of the compilation process. Additionally, it 40626avoids the need to load the whole program into memory. 40627 40628 40629File: gccint.info, Node: LTO object file layout, Next: IPA, Prev: LTO Overview, Up: LTO 40630 4063124.2 LTO file sections 40632====================== 40633 40634LTO information is stored in several ELF sections inside object files. 40635Data structures and enum codes for sections are defined in 40636'lto-streamer.h'. 40637 40638 These sections are emitted from 'lto-streamer-out.c' and mapped in all 40639at once from 'lto/lto.c':'lto_file_read'. The individual functions 40640dealing with the reading/writing of each section are described below. 40641 40642 * Command line options ('.gnu.lto_.opts') 40643 40644 This section contains the command line options used to generate the 40645 object files. This is used at link time to determine the 40646 optimization level and other settings when they are not explicitly 40647 specified at the linker command line. 40648 40649 Currently, GCC does not support combining LTO object files compiled 40650 with different set of the command line options into a single 40651 binary. At link time, the options given on the command line and 40652 the options saved on all the files in a link-time set are applied 40653 globally. No attempt is made at validating the combination of 40654 flags (other than the usual validation done by option processing). 40655 This is implemented in 'lto/lto.c':'lto_read_all_file_options'. 40656 40657 * Symbol table ('.gnu.lto_.symtab') 40658 40659 This table replaces the ELF symbol table for functions and 40660 variables represented in the LTO IL. Symbols used and exported by 40661 the optimized assembly code of "fat" objects might not match the 40662 ones used and exported by the intermediate code. This table is 40663 necessary because the intermediate code is less optimized and thus 40664 requires a separate symbol table. 40665 40666 Additionally, the binary code in the "fat" object will lack a call 40667 to a function, since the call was optimized out at compilation time 40668 after the intermediate language was streamed out. In some special 40669 cases, the same optimization may not happen during link-time 40670 optimization. This would lead to an undefined symbol if only one 40671 symbol table was used. 40672 40673 The symbol table is emitted in 40674 'lto-streamer-out.c':'produce_symtab'. 40675 40676 * Global declarations and types ('.gnu.lto_.decls') 40677 40678 This section contains an intermediate language dump of all 40679 declarations and types required to represent the callgraph, static 40680 variables and top-level debug info. 40681 40682 The contents of this section are emitted in 40683 'lto-streamer-out.c':'produce_asm_for_decls'. Types and symbols 40684 are emitted in a topological order that preserves the sharing of 40685 pointers when the file is read back in 40686 ('lto.c':'read_cgraph_and_symbols'). 40687 40688 * The callgraph ('.gnu.lto_.cgraph') 40689 40690 This section contains the basic data structure used by the GCC 40691 inter-procedural optimization infrastructure. This section stores 40692 an annotated multi-graph which represents the functions and call 40693 sites as well as the variables, aliases and top-level 'asm' 40694 statements. 40695 40696 This section is emitted in 'lto-streamer-out.c':'output_cgraph' and 40697 read in 'lto-cgraph.c':'input_cgraph'. 40698 40699 * IPA references ('.gnu.lto_.refs') 40700 40701 This section contains references between function and static 40702 variables. It is emitted by 'lto-cgraph.c':'output_refs' and read 40703 by 'lto-cgraph.c':'input_refs'. 40704 40705 * Function bodies ('.gnu.lto_.function_body.<name>') 40706 40707 This section contains function bodies in the intermediate language 40708 representation. Every function body is in a separate section to 40709 allow copying of the section independently to different object 40710 files or reading the function on demand. 40711 40712 Functions are emitted in 'lto-streamer-out.c':'output_function' and 40713 read in 'lto-streamer-in.c':'input_function'. 40714 40715 * Static variable initializers ('.gnu.lto_.vars') 40716 40717 This section contains all the symbols in the global variable pool. 40718 It is emitted by 'lto-cgraph.c':'output_varpool' and read in 40719 'lto-cgraph.c':'input_cgraph'. 40720 40721 * Summaries and optimization summaries used by IPA passes 40722 ('.gnu.lto_.<xxx>', where '<xxx>' is one of 'jmpfuncs', 'pureconst' 40723 or 'reference') 40724 40725 These sections are used by IPA passes that need to emit summary 40726 information during LTO generation to be read and aggregated at link 40727 time. Each pass is responsible for implementing two pass manager 40728 hooks: one for writing the summary and another for reading it in. 40729 The format of these sections is entirely up to each individual 40730 pass. The only requirement is that the writer and reader hooks 40731 agree on the format. 40732 40733 40734File: gccint.info, Node: IPA, Next: WHOPR, Prev: LTO object file layout, Up: LTO 40735 4073624.3 Using summary information in IPA passes 40737============================================ 40738 40739Programs are represented internally as a _callgraph_ (a multi-graph 40740where nodes are functions and edges are call sites) and a _varpool_ (a 40741list of static and external variables in the program). 40742 40743 The inter-procedural optimization is organized as a sequence of 40744individual passes, which operate on the callgraph and the varpool. To 40745make the implementation of WHOPR possible, every inter-procedural 40746optimization pass is split into several stages that are executed at 40747different times during WHOPR compilation: 40748 40749 * LGEN time 40750 1. _Generate summary_ ('generate_summary' in 'struct 40751 ipa_opt_pass_d'). This stage analyzes every function body and 40752 variable initializer is examined and stores relevant 40753 information into a pass-specific data structure. 40754 40755 2. _Write summary_ ('write_summary' in 'struct ipa_opt_pass_d'). 40756 This stage writes all the pass-specific information generated 40757 by 'generate_summary'. Summaries go into their own 40758 'LTO_section_*' sections that have to be declared in 40759 'lto-streamer.h':'enum lto_section_type'. A new section is 40760 created by calling 'create_output_block' and data can be 40761 written using the 'lto_output_*' routines. 40762 40763 * WPA time 40764 1. _Read summary_ ('read_summary' in 'struct ipa_opt_pass_d'). 40765 This stage reads all the pass-specific information in exactly 40766 the same order that it was written by 'write_summary'. 40767 40768 2. _Execute_ ('execute' in 'struct opt_pass'). This performs 40769 inter-procedural propagation. This must be done without 40770 actual access to the individual function bodies or variable 40771 initializers. Typically, this results in a transitive closure 40772 operation over the summary information of all the nodes in the 40773 callgraph. 40774 40775 3. _Write optimization summary_ ('write_optimization_summary' in 40776 'struct ipa_opt_pass_d'). This writes the result of the 40777 inter-procedural propagation into the object file. This can 40778 use the same data structures and helper routines used in 40779 'write_summary'. 40780 40781 * LTRANS time 40782 1. _Read optimization summary_ ('read_optimization_summary' in 40783 'struct ipa_opt_pass_d'). The counterpart to 40784 'write_optimization_summary'. This reads the interprocedural 40785 optimization decisions in exactly the same format emitted by 40786 'write_optimization_summary'. 40787 40788 2. _Transform_ ('function_transform' and 'variable_transform' in 40789 'struct ipa_opt_pass_d'). The actual function bodies and 40790 variable initializers are updated based on the information 40791 passed down from the _Execute_ stage. 40792 40793 The implementation of the inter-procedural passes are shared between 40794LTO, WHOPR and classic non-LTO compilation. 40795 40796 * During the traditional file-by-file mode every pass executes its 40797 own _Generate summary_, _Execute_, and _Transform_ stages within 40798 the single execution context of the compiler. 40799 40800 * In LTO compilation mode, every pass uses _Generate summary_ and 40801 _Write summary_ stages at compilation time, while the _Read 40802 summary_, _Execute_, and _Transform_ stages are executed at link 40803 time. 40804 40805 * In WHOPR mode all stages are used. 40806 40807 To simplify development, the GCC pass manager differentiates between 40808normal inter-procedural passes and small inter-procedural passes. A 40809_small inter-procedural pass_ ('SIMPLE_IPA_PASS') is a pass that does 40810everything at once and thus it can not be executed during WPA in WHOPR 40811mode. It defines only the _Execute_ stage and during this stage it 40812accesses and modifies the function bodies. Such passes are useful for 40813optimization at LGEN or LTRANS time and are used, for example, to 40814implement early optimization before writing object files. The simple 40815inter-procedural passes can also be used for easier prototyping and 40816development of a new inter-procedural pass. 40817 4081824.3.1 Virtual clones 40819--------------------- 40820 40821One of the main challenges of introducing the WHOPR compilation mode was 40822addressing the interactions between optimization passes. In LTO 40823compilation mode, the passes are executed in a sequence, each of which 40824consists of analysis (or _Generate summary_), propagation (or _Execute_) 40825and _Transform_ stages. Once the work of one pass is finished, the next 40826pass sees the updated program representation and can execute. This 40827makes the individual passes dependent on each other. 40828 40829 In WHOPR mode all passes first execute their _Generate summary_ stage. 40830Then summary writing marks the end of the LGEN stage. At WPA time, the 40831summaries are read back into memory and all passes run the _Execute_ 40832stage. Optimization summaries are streamed and sent to LTRANS, where 40833all the passes execute the _Transform_ stage. 40834 40835 Most optimization passes split naturally into analysis, propagation and 40836transformation stages. But some do not. The main problem arises when 40837one pass performs changes and the following pass gets confused by seeing 40838different callgraphs between the _Transform_ stage and the _Generate 40839summary_ or _Execute_ stage. This means that the passes are required to 40840communicate their decisions with each other. 40841 40842 To facilitate this communication, the GCC callgraph infrastructure 40843implements _virtual clones_, a method of representing the changes 40844performed by the optimization passes in the callgraph without needing to 40845update function bodies. 40846 40847 A _virtual clone_ in the callgraph is a function that has no associated 40848body, just a description of how to create its body based on a different 40849function (which itself may be a virtual clone). 40850 40851 The description of function modifications includes adjustments to the 40852function's signature (which allows, for example, removing or adding 40853function arguments), substitutions to perform on the function body, and, 40854for inlined functions, a pointer to the function that it will be inlined 40855into. 40856 40857 It is also possible to redirect any edge of the callgraph from a 40858function to its virtual clone. This implies updating of the call site 40859to adjust for the new function signature. 40860 40861 Most of the transformations performed by inter-procedural optimizations 40862can be represented via virtual clones. For instance, a constant 40863propagation pass can produce a virtual clone of the function which 40864replaces one of its arguments by a constant. The inliner can represent 40865its decisions by producing a clone of a function whose body will be 40866later integrated into a given function. 40867 40868 Using _virtual clones_, the program can be easily updated during the 40869_Execute_ stage, solving most of pass interactions problems that would 40870otherwise occur during _Transform_. 40871 40872 Virtual clones are later materialized in the LTRANS stage and turned 40873into real functions. Passes executed after the virtual clone were 40874introduced also perform their _Transform_ stage on new functions, so for 40875a pass there is no significant difference between operating on a real 40876function or a virtual clone introduced before its _Execute_ stage. 40877 40878 Optimization passes then work on virtual clones introduced before their 40879_Execute_ stage as if they were real functions. The only difference is 40880that clones are not visible during the _Generate Summary_ stage. 40881 40882 To keep function summaries updated, the callgraph interface allows an 40883optimizer to register a callback that is called every time a new clone 40884is introduced as well as when the actual function or variable is 40885generated or when a function or variable is removed. These hooks are 40886registered in the _Generate summary_ stage and allow the pass to keep 40887its information intact until the _Execute_ stage. The same hooks can 40888also be registered during the _Execute_ stage to keep the optimization 40889summaries updated for the _Transform_ stage. 40890 4089124.3.2 IPA references 40892--------------------- 40893 40894GCC represents IPA references in the callgraph. For a function or 40895variable 'A', the _IPA reference_ is a list of all locations where the 40896address of 'A' is taken and, when 'A' is a variable, a list of all 40897direct stores and reads to/from 'A'. References represent an oriented 40898multi-graph on the union of nodes of the callgraph and the varpool. See 40899'ipa-reference.c':'ipa_reference_write_optimization_summary' and 40900'ipa-reference.c':'ipa_reference_read_optimization_summary' for details. 40901 4090224.3.3 Jump functions 40903--------------------- 40904 40905Suppose that an optimization pass sees a function 'A' and it knows the 40906values of (some of) its arguments. The _jump function_ describes the 40907value of a parameter of a given function call in function 'A' based on 40908this knowledge. 40909 40910 Jump functions are used by several optimizations, such as the 40911inter-procedural constant propagation pass and the devirtualization 40912pass. The inliner also uses jump functions to perform inlining of 40913callbacks. 40914 40915 40916File: gccint.info, Node: WHOPR, Next: Internal flags, Prev: IPA, Up: LTO 40917 4091824.4 Whole program assumptions, linker plugin and symbol visibilities 40919===================================================================== 40920 40921Link-time optimization gives relatively minor benefits when used alone. 40922The problem is that propagation of inter-procedural information does not 40923work well across functions and variables that are called or referenced 40924by other compilation units (such as from a dynamically linked library). 40925We say that such functions and variables are _externally visible_. 40926 40927 To make the situation even more difficult, many applications organize 40928themselves as a set of shared libraries, and the default ELF visibility 40929rules allow one to overwrite any externally visible symbol with a 40930different symbol at runtime. This basically disables any optimizations 40931across such functions and variables, because the compiler cannot be sure 40932that the function body it is seeing is the same function body that will 40933be used at runtime. Any function or variable not declared 'static' in 40934the sources degrades the quality of inter-procedural optimization. 40935 40936 To avoid this problem the compiler must assume that it sees the whole 40937program when doing link-time optimization. Strictly speaking, the whole 40938program is rarely visible even at link-time. Standard system libraries 40939are usually linked dynamically or not provided with the link-time 40940information. In GCC, the whole program option ('-fwhole-program') 40941asserts that every function and variable defined in the current 40942compilation unit is static, except for function 'main' (note: at link 40943time, the current unit is the union of all objects compiled with LTO). 40944Since some functions and variables need to be referenced externally, for 40945example by another DSO or from an assembler file, GCC also provides the 40946function and variable attribute 'externally_visible' which can be used 40947to disable the effect of '-fwhole-program' on a specific symbol. 40948 40949 The whole program mode assumptions are slightly more complex in C++, 40950where inline functions in headers are put into _COMDAT_ sections. 40951COMDAT function and variables can be defined by multiple object files 40952and their bodies are unified at link-time and dynamic link-time. COMDAT 40953functions are changed to local only when their address is not taken and 40954thus un-sharing them with a library is not harmful. COMDAT variables 40955always remain externally visible, however for readonly variables it is 40956assumed that their initializers cannot be overwritten by a different 40957value. 40958 40959 GCC provides the function and variable attribute 'visibility' that can 40960be used to specify the visibility of externally visible symbols (or 40961alternatively an '-fdefault-visibility' command line option). ELF 40962defines the 'default', 'protected', 'hidden' and 'internal' 40963visibilities. 40964 40965 The most commonly used is visibility is 'hidden'. It specifies that 40966the symbol cannot be referenced from outside of the current shared 40967library. Unfortunately, this information cannot be used directly by the 40968link-time optimization in the compiler since the whole shared library 40969also might contain non-LTO objects and those are not visible to the 40970compiler. 40971 40972 GCC solves this problem using linker plugins. A _linker plugin_ is an 40973interface to the linker that allows an external program to claim the 40974ownership of a given object file. The linker then performs the linking 40975procedure by querying the plugin about the symbol table of the claimed 40976objects and once the linking decisions are complete, the plugin is 40977allowed to provide the final object file before the actual linking is 40978made. The linker plugin obtains the symbol resolution information which 40979specifies which symbols provided by the claimed objects are bound from 40980the rest of a binary being linked. 40981 40982 GCC is designed to be independent of the rest of the toolchain and aims 40983to support linkers without plugin support. For this reason it does not 40984use the linker plugin by default. Instead, the object files are 40985examined by 'collect2' before being passed to the linker and objects 40986found to have LTO sections are passed to 'lto1' first. This mode does 40987not work for library archives. The decision on what object files from 40988the archive are needed depends on the actual linking and thus GCC would 40989have to implement the linker itself. The resolution information is 40990missing too and thus GCC needs to make an educated guess based on 40991'-fwhole-program'. Without the linker plugin GCC also assumes that 40992symbols are declared 'hidden' and not referred by non-LTO code by 40993default. 40994 40995 40996File: gccint.info, Node: Internal flags, Prev: WHOPR, Up: LTO 40997 4099824.5 Internal flags controlling 'lto1' 40999====================================== 41000 41001The following flags are passed into 'lto1' and are not meant to be used 41002directly from the command line. 41003 41004 * -fwpa This option runs the serial part of the link-time optimizer 41005 performing the inter-procedural propagation (WPA mode). The 41006 compiler reads in summary information from all inputs and performs 41007 an analysis based on summary information only. It generates object 41008 files for subsequent runs of the link-time optimizer where 41009 individual object files are optimized using both summary 41010 information from the WPA mode and the actual function bodies. It 41011 then drives the LTRANS phase. 41012 41013 * -fltrans This option runs the link-time optimizer in the 41014 local-transformation (LTRANS) mode, which reads in output from a 41015 previous run of the LTO in WPA mode. In the LTRANS mode, LTO 41016 optimizes an object and produces the final assembly. 41017 41018 * -fltrans-output-list=FILE This option specifies a file to which the 41019 names of LTRANS output files are written. This option is only 41020 meaningful in conjunction with '-fwpa'. 41021 41022 * -fresolution=FILE This option specifies the linker resolution file. 41023 This option is only meaningful in conjunction with '-fwpa' and as 41024 option to pass through to the LTO linker plugin. 41025 41026 41027File: gccint.info, Node: Match and Simplify, Next: Funding, Prev: LTO, Up: Top 41028 4102925 Match and Simplify 41030********************* 41031 41032The GIMPLE and GENERIC pattern matching project match-and-simplify tries 41033to address several issues. 41034 41035 1. unify expression simplifications currently spread and duplicated 41036 over separate files like fold-const.c, gimple-fold.c and builtins.c 41037 2. allow for a cheap way to implement building and simplifying 41038 non-trivial GIMPLE expressions, avoiding the need to go through 41039 building and simplifying GENERIC via fold_buildN and then 41040 gimplifying via force_gimple_operand 41041 41042 To address these the project introduces a simple domain specific 41043language to write expression simplifications from which code targeting 41044GIMPLE and GENERIC is auto-generated. The GENERIC variant follows the 41045fold_buildN API while for the GIMPLE variant and to address 2) new APIs 41046are introduced. 41047 41048* Menu: 41049 41050* GIMPLE API:: 41051* The Language:: 41052 41053 41054File: gccint.info, Node: GIMPLE API, Next: The Language, Up: Match and Simplify 41055 4105625.1 GIMPLE API 41057=============== 41058 41059 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 41060 gimple_seq *, tree (*)(tree)) 41061 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 41062 tree, gimple_seq *, tree (*)(tree)) 41063 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 41064 tree, tree, gimple_seq *, tree (*)(tree)) 41065 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 41066 tree, gimple_seq *, tree (*)(tree)) 41067 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 41068 tree, tree, gimple_seq *, tree (*)(tree)) 41069 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 41070 tree, tree, tree, gimple_seq *, tree (*)(tree)) 41071 The main GIMPLE API entry to the expression simplifications 41072 mimicing that of the GENERIC fold_{unary,binary,ternary} functions. 41073 41074 thus providing n-ary overloads for operation or function. The 41075additional arguments are a gimple_seq where built statements are 41076inserted on (if 'NULL' then simplifications requiring new statements are 41077not performed) and a valueization hook that can be used to tie 41078simplifications to a SSA lattice. 41079 41080 In addition to those APIs 'fold_stmt' is overloaded with a valueization 41081hook: 41082 41083 -- bool: fold_stmt (gimple_stmt_iterator *, tree (*)(tree)); 41084 41085 Ontop of these a 'fold_buildN'-like API for GIMPLE is introduced: 41086 41087 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 41088 tree_code, tree, tree, tree (*valueize) (tree) = NULL); 41089 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 41090 tree_code, tree, tree, tree, tree (*valueize) (tree) = NULL); 41091 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 41092 tree_code, tree, tree, tree, tree, tree (*valueize) (tree) = 41093 NULL); 41094 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 41095 built_in_function, tree, tree, tree (*valueize) (tree) = 41096 NULL); 41097 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 41098 built_in_function, tree, tree, tree, tree (*valueize) (tree) = 41099 NULL); 41100 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 41101 built_in_function, tree, tree, tree, tree, tree (*valueize) 41102 (tree) = NULL); 41103 -- GIMPLE function: tree gimple_convert (gimple_seq *, location_t, 41104 tree, tree); 41105 41106 which is supposed to replace 'force_gimple_operand (fold_buildN (...), 41107...)' and calls to 'fold_convert'. Overloads without the 'location_t' 41108argument exist. Built statements are inserted on the provided sequence 41109and simplification is performed using the optional valueization hook. 41110 41111 41112File: gccint.info, Node: The Language, Prev: GIMPLE API, Up: Match and Simplify 41113 4111425.2 The Language 41115================= 41116 41117The language to write expression simplifications in resembles other 41118domain-specific languages GCC uses. Thus it is lispy. Lets start with 41119an example from the match.pd file: 41120 41121 (simplify 41122 (bit_and @0 integer_all_onesp) 41123 @0) 41124 41125 This example contains all required parts of an expression 41126simplification. A simplification is wrapped inside a '(simplify ...)' 41127expression. That contains at least two operands - an expression that is 41128matched with the GIMPLE or GENERIC IL and a replacement expression that 41129is returned if the match was successful. 41130 41131 Expressions have an operator ID, 'bit_and' in this case. Expressions 41132can be lower-case tree codes with '_expr' stripped off or builtin 41133function code names in all-caps, like 'BUILT_IN_SQRT'. 41134 41135 '@n' denotes a so-called capture. It captures the operand and lets you 41136refer to it in other places of the match-and-simplify. In the above 41137example it is refered to in the replacement expression. Captures are 41138'@' followed by a number or an identifier. 41139 41140 (simplify 41141 (bit_xor @0 @0) 41142 { build_zero_cst (type); }) 41143 41144 In this example '@0' is mentioned twice which constrains the matched 41145expression to have two equal operands. This example also introduces 41146operands written in C code. These can be used in the expression 41147replacements and are supposed to evaluate to a tree node which has to be 41148a valid GIMPLE operand (so you cannot generate expressions in C code). 41149 41150 (simplify 41151 (trunc_mod integer_zerop@0 @1) 41152 (if (!integer_zerop (@1)) 41153 @0)) 41154 41155 Here '@0' captures the first operand of the trunc_mod expression which 41156is also predicated with 'integer_zerop'. Expression operands may be 41157either expressions, predicates or captures. Captures can be 41158unconstrained or capture expresions or predicates. 41159 41160 This example introduces an optional operand of simplify, the 41161if-expression. This condition is evaluated after the expression matched 41162in the IL and is required to evaluate to true to enable the replacement 41163expression in the second operand position. The expression operand of 41164the 'if' is a standard C expression which may contain references to 41165captures. The 'if' has an optional third operand which may contain the 41166replacement expression that is enabled when the condition evaluates to 41167false. 41168 41169 A 'if' expression can be used to specify a common condition for 41170multiple simplify patterns, avoiding the need to repeat that multiple 41171times: 41172 41173 (if (!TYPE_SATURATING (type) 41174 && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) 41175 (simplify 41176 (minus (plus @0 @1) @0) 41177 @1) 41178 (simplify 41179 (minus (minus @0 @1) @0) 41180 (negate @1))) 41181 41182 Note that 'if's in outer position do not have the optional else clause 41183but instead have multiple then clauses. 41184 41185 Ifs can be nested. 41186 41187 There exists a 'switch' expression which can be used to chain 41188conditions avoiding nesting 'if's too much: 41189 41190 (simplify 41191 (simple_comparison @0 REAL_CST@1) 41192 (switch 41193 /* a CMP (-0) -> a CMP 0 */ 41194 (if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1))) 41195 (cmp @0 { build_real (TREE_TYPE (@1), dconst0); })) 41196 /* x != NaN is always true, other ops are always false. */ 41197 (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1)) 41198 && ! HONOR_SNANS (@1)) 41199 { constant_boolean_node (cmp == NE_EXPR, type); }))) 41200 41201 Is equal to 41202 41203 (simplify 41204 (simple_comparison @0 REAL_CST@1) 41205 (switch 41206 /* a CMP (-0) -> a CMP 0 */ 41207 (if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1))) 41208 (cmp @0 { build_real (TREE_TYPE (@1), dconst0); }) 41209 /* x != NaN is always true, other ops are always false. */ 41210 (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1)) 41211 && ! HONOR_SNANS (@1)) 41212 { constant_boolean_node (cmp == NE_EXPR, type); })))) 41213 41214 which has the second 'if' in the else operand of the first. The 41215'switch' expression takes 'if' expressions as operands (which may not 41216have else clauses) and as a last operand a replacement expression which 41217should be enabled by default if no other condition evaluated to true. 41218 41219 Captures can also be used for capturing results of sub-expressions. 41220 41221 #if GIMPLE 41222 (simplify 41223 (pointer_plus (addr@2 @0) INTEGER_CST_P@1) 41224 (if (is_gimple_min_invariant (@2))) 41225 { 41226 HOST_WIDE_INT off; 41227 tree base = get_addr_base_and_unit_offset (@0, &off); 41228 off += tree_to_uhwi (@1); 41229 /* Now with that we should be able to simply write 41230 (addr (mem_ref (addr @base) (plus @off @1))) */ 41231 build1 (ADDR_EXPR, type, 41232 build2 (MEM_REF, TREE_TYPE (TREE_TYPE (@2)), 41233 build_fold_addr_expr (base), 41234 build_int_cst (ptr_type_node, off))); 41235 }) 41236 #endif 41237 41238 In the above example, '@2' captures the result of the expression '(addr 41239@0)'. For outermost expression only its type can be captured, and the 41240keyword 'type' is reserved for this purpose. The above example also 41241gives a way to conditionalize patterns to only apply to 'GIMPLE' or 41242'GENERIC' by means of using the pre-defined preprocessor macros 'GIMPLE' 41243and 'GENERIC' and using preprocessor directives. 41244 41245 (simplify 41246 (bit_and:c integral_op_p@0 (bit_ior:c (bit_not @0) @1)) 41247 (bit_and @1 @0)) 41248 41249 Here we introduce flags on match expressions. The flag used above, 41250'c', denotes that the expression should be also matched commutated. 41251Thus the above match expression is really the following four match 41252expressions: 41253 41254 (bit_and integral_op_p@0 (bit_ior (bit_not @0) @1)) 41255 (bit_and (bit_ior (bit_not @0) @1) integral_op_p@0) 41256 (bit_and integral_op_p@0 (bit_ior @1 (bit_not @0))) 41257 (bit_and (bit_ior @1 (bit_not @0)) integral_op_p@0) 41258 41259 Usual canonicalizations you know from GENERIC expressions are applied 41260before matching, so for example constant operands always come second in 41261commutative expressions. 41262 41263 The second supported flag is 's' which tells the code generator to fail 41264the pattern if the expression marked with 's' does have more than one 41265use. For example in 41266 41267 (simplify 41268 (pointer_plus (pointer_plus:s @0 @1) @3) 41269 (pointer_plus @0 (plus @1 @3))) 41270 41271 this avoids the association if '(pointer_plus @0 @1)' is used outside 41272of the matched expression and thus it would stay live and not trivially 41273removed by dead code elimination. 41274 41275 More features exist to avoid too much repetition. 41276 41277 (for op (plus pointer_plus minus bit_ior bit_xor) 41278 (simplify 41279 (op @0 integer_zerop) 41280 @0)) 41281 41282 A 'for' expression can be used to repeat a pattern for each operator 41283specified, substituting 'op'. 'for' can be nested and a 'for' can have 41284multiple operators to iterate. 41285 41286 (for opa (plus minus) 41287 opb (minus plus) 41288 (for opc (plus minus) 41289 (simplify... 41290 41291 In this example the pattern will be repeated four times with 'opa, opb, 41292opc' being 'plus, minus, plus', 'plus, minus, minus', 'minus, plus, 41293plus', 'minus, plus, minus'. 41294 41295 To avoid repeating operator lists in 'for' you can name them via 41296 41297 (define_operator_list pmm plus minus mult) 41298 41299 and use them in 'for' operator lists where they get expanded. 41300 41301 (for opa (pmm trunc_div) 41302 (simplify... 41303 41304 So this example iterates over 'plus', 'minus', 'mult' and 'trunc_div'. 41305 41306 Using operator lists can also remove the need to explicitely write a 41307'for'. All operator list uses that appear in a 'simplify' or 'match' 41308pattern in operator positions will implicitely be added to a new 'for'. 41309For example 41310 41311 (define_operator_list SQRT BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 41312 (define_operator_list POW BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 41313 (simplify 41314 (SQRT (POW @0 @1)) 41315 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); }))) 41316 41317 is the same as 41318 41319 (for SQRT (BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 41320 POW (BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 41321 (simplify 41322 (SQRT (POW @0 @1)) 41323 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); })))) 41324 41325 'for's and operator lists can include the special identifier 'null' 41326that matches nothing and can never be generated. This can be used to 41327pad an operator list so that it has a standard form, even if there isn't 41328a suitable operator for every form. 41329 41330 Another building block are 'with' expressions in the result expression 41331which nest the generated code in a new C block followed by its argument: 41332 41333 (simplify 41334 (convert (mult @0 @1)) 41335 (with { tree utype = unsigned_type_for (type); } 41336 (convert (mult (convert:utype @0) (convert:utype @1))))) 41337 41338 This allows code nested in the 'with' to refer to the declared 41339variables. In the above case we use the feature to specify the type of 41340a generated expression with the ':type' syntax where 'type' needs to be 41341an identifier that refers to the desired type. Usually the types of the 41342generated result expressions are determined from the context, but 41343sometimes like in the above case it is required that you specify them 41344explicitely. 41345 41346 As intermediate conversions are often optional there is a way to avoid 41347the need to repeat patterns both with and without such conversions. 41348Namely you can mark a conversion as being optional with a '?': 41349 41350 (simplify 41351 (eq (convert@0 @1) (convert? @2)) 41352 (eq @1 (convert @2))) 41353 41354 which will match both '(eq (convert @1) (convert @2))' and '(eq 41355(convert @1) @2)'. The optional converts are supposed to be all either 41356present or not, thus '(eq (convert? @1) (convert? @2))' will result in 41357two patterns only. If you want to match all four combinations you have 41358access to two additional conditional converts as in '(eq (convert1? @1) 41359(convert2? @2))'. 41360 41361 Predicates available from the GCC middle-end need to be made available 41362explicitely via 'define_predicates': 41363 41364 (define_predicates 41365 integer_onep integer_zerop integer_all_onesp) 41366 41367 You can also define predicates using the pattern matching language and 41368the 'match' form: 41369 41370 (match negate_expr_p 41371 INTEGER_CST 41372 (if (TYPE_OVERFLOW_WRAPS (type) 41373 || may_negate_without_overflow_p (t)))) 41374 (match negate_expr_p 41375 (negate @0)) 41376 41377 This shows that for 'match' expressions there is 't' available which 41378captures the outermost expression (something not possible in the 41379'simplify' context). As you can see 'match' has an identifier as first 41380operand which is how you refer to the predicate in patterns. Multiple 41381'match' for the same identifier add additional cases where the predicate 41382matches. 41383 41384 Predicates can also match an expression in which case you need to 41385provide a template specifying the identifier and where to get its 41386operands from: 41387 41388 (match (logical_inverted_value @0) 41389 (eq @0 integer_zerop)) 41390 (match (logical_inverted_value @0) 41391 (bit_not truth_valued_p@0)) 41392 41393 You can use the above predicate like 41394 41395 (simplify 41396 (bit_and @0 (logical_inverted_value @0)) 41397 { build_zero_cst (type); }) 41398 41399 Which will match a bitwise and of an operand with its logical inverted 41400value. 41401 41402 41403File: gccint.info, Node: Funding, Next: GNU Project, Prev: Match and Simplify, Up: Top 41404 41405Funding Free Software 41406********************* 41407 41408If you want to have more free software a few years from now, it makes 41409sense for you to help encourage people to contribute funds for its 41410development. The most effective approach known is to encourage 41411commercial redistributors to donate. 41412 41413 Users of free software systems can boost the pace of development by 41414encouraging for-a-fee distributors to donate part of their selling price 41415to free software developers--the Free Software Foundation, and others. 41416 41417 The way to convince distributors to do this is to demand it and expect 41418it from them. So when you compare distributors, judge them partly by 41419how much they give to free software development. Show distributors they 41420must compete to be the one who gives the most. 41421 41422 To make this approach work, you must insist on numbers that you can 41423compare, such as, "We will donate ten dollars to the Frobnitz project 41424for each disk sold." Don't be satisfied with a vague promise, such as 41425"A portion of the profits are donated," since it doesn't give a basis 41426for comparison. 41427 41428 Even a precise fraction "of the profits from this disk" is not very 41429meaningful, since creative accounting and unrelated business decisions 41430can greatly alter what fraction of the sales price counts as profit. If 41431the price you pay is $50, ten percent of the profit is probably less 41432than a dollar; it might be a few cents, or nothing at all. 41433 41434 Some redistributors do development work themselves. This is useful 41435too; but to keep everyone honest, you need to inquire how much they do, 41436and what kind. Some kinds of development make much more long-term 41437difference than others. For example, maintaining a separate version of 41438a program contributes very little; maintaining the standard version of a 41439program for the whole community contributes much. Easy new ports 41440contribute little, since someone else would surely do them; difficult 41441ports such as adding a new CPU to the GNU Compiler Collection contribute 41442more; major new features or packages contribute the most. 41443 41444 By establishing the idea that supporting further development is "the 41445proper thing to do" when distributing free software for a fee, we can 41446assure a steady flow of resources into making more free software. 41447 41448 Copyright (C) 1994 Free Software Foundation, Inc. 41449 Verbatim copying and redistribution of this section is permitted 41450 without royalty; alteration is not permitted. 41451 41452 41453File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 41454 41455The GNU Project and GNU/Linux 41456***************************** 41457 41458The GNU Project was launched in 1984 to develop a complete Unix-like 41459operating system which is free software: the GNU system. (GNU is a 41460recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 41461Variants of the GNU operating system, which use the kernel Linux, are 41462now widely used; though these systems are often referred to as "Linux", 41463they are more accurately called GNU/Linux systems. 41464 41465 For more information, see: 41466 <http://www.gnu.org/> 41467 <http://www.gnu.org/gnu/linux-and-gnu.html> 41468 41469 41470File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 41471 41472GNU General Public License 41473************************** 41474 41475 Version 3, 29 June 2007 41476 41477 Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> 41478 41479 Everyone is permitted to copy and distribute verbatim copies of this 41480 license document, but changing it is not allowed. 41481 41482Preamble 41483======== 41484 41485The GNU General Public License is a free, copyleft license for software 41486and other kinds of works. 41487 41488 The licenses for most software and other practical works are designed 41489to take away your freedom to share and change the works. By contrast, 41490the GNU General Public License is intended to guarantee your freedom to 41491share and change all versions of a program-to make sure it remains free 41492software for all its users. We, the Free Software Foundation, use the 41493GNU General Public License for most of our software; it applies also to 41494any other work released this way by its authors. You can apply it to 41495your programs, too. 41496 41497 When we speak of free software, we are referring to freedom, not price. 41498Our General Public Licenses are designed to make sure that you have the 41499freedom to distribute copies of free software (and charge for them if 41500you wish), that you receive source code or can get it if you want it, 41501that you can change the software or use pieces of it in new free 41502programs, and that you know you can do these things. 41503 41504 To protect your rights, we need to prevent others from denying you 41505these rights or asking you to surrender the rights. Therefore, you have 41506certain responsibilities if you distribute copies of the software, or if 41507you modify it: responsibilities to respect the freedom of others. 41508 41509 For example, if you distribute copies of such a program, whether gratis 41510or for a fee, you must pass on to the recipients the same freedoms that 41511you received. You must make sure that they, too, receive or can get the 41512source code. And you must show them these terms so they know their 41513rights. 41514 41515 Developers that use the GNU GPL protect your rights with two steps: (1) 41516assert copyright on the software, and (2) offer you this License giving 41517you legal permission to copy, distribute and/or modify it. 41518 41519 For the developers' and authors' protection, the GPL clearly explains 41520that there is no warranty for this free software. For both users' and 41521authors' sake, the GPL requires that modified versions be marked as 41522changed, so that their problems will not be attributed erroneously to 41523authors of previous versions. 41524 41525 Some devices are designed to deny users access to install or run 41526modified versions of the software inside them, although the manufacturer 41527can do so. This is fundamentally incompatible with the aim of 41528protecting users' freedom to change the software. The systematic 41529pattern of such abuse occurs in the area of products for individuals to 41530use, which is precisely where it is most unacceptable. Therefore, we 41531have designed this version of the GPL to prohibit the practice for those 41532products. If such problems arise substantially in other domains, we 41533stand ready to extend this provision to those domains in future versions 41534of the GPL, as needed to protect the freedom of users. 41535 41536 Finally, every program is threatened constantly by software patents. 41537States should not allow patents to restrict development and use of 41538software on general-purpose computers, but in those that do, we wish to 41539avoid the special danger that patents applied to a free program could 41540make it effectively proprietary. To prevent this, the GPL assures that 41541patents cannot be used to render the program non-free. 41542 41543 The precise terms and conditions for copying, distribution and 41544modification follow. 41545 41546TERMS AND CONDITIONS 41547==================== 41548 41549 0. Definitions. 41550 41551 "This License" refers to version 3 of the GNU General Public 41552 License. 41553 41554 "Copyright" also means copyright-like laws that apply to other 41555 kinds of works, such as semiconductor masks. 41556 41557 "The Program" refers to any copyrightable work licensed under this 41558 License. Each licensee is addressed as "you". "Licensees" and 41559 "recipients" may be individuals or organizations. 41560 41561 To "modify" a work means to copy from or adapt all or part of the 41562 work in a fashion requiring copyright permission, other than the 41563 making of an exact copy. The resulting work is called a "modified 41564 version" of the earlier work or a work "based on" the earlier work. 41565 41566 A "covered work" means either the unmodified Program or a work 41567 based on the Program. 41568 41569 To "propagate" a work means to do anything with it that, without 41570 permission, would make you directly or secondarily liable for 41571 infringement under applicable copyright law, except executing it on 41572 a computer or modifying a private copy. Propagation includes 41573 copying, distribution (with or without modification), making 41574 available to the public, and in some countries other activities as 41575 well. 41576 41577 To "convey" a work means any kind of propagation that enables other 41578 parties to make or receive copies. Mere interaction with a user 41579 through a computer network, with no transfer of a copy, is not 41580 conveying. 41581 41582 An interactive user interface displays "Appropriate Legal Notices" 41583 to the extent that it includes a convenient and prominently visible 41584 feature that (1) displays an appropriate copyright notice, and (2) 41585 tells the user that there is no warranty for the work (except to 41586 the extent that warranties are provided), that licensees may convey 41587 the work under this License, and how to view a copy of this 41588 License. If the interface presents a list of user commands or 41589 options, such as a menu, a prominent item in the list meets this 41590 criterion. 41591 41592 1. Source Code. 41593 41594 The "source code" for a work means the preferred form of the work 41595 for making modifications to it. "Object code" means any non-source 41596 form of a work. 41597 41598 A "Standard Interface" means an interface that either is an 41599 official standard defined by a recognized standards body, or, in 41600 the case of interfaces specified for a particular programming 41601 language, one that is widely used among developers working in that 41602 language. 41603 41604 The "System Libraries" of an executable work include anything, 41605 other than the work as a whole, that (a) is included in the normal 41606 form of packaging a Major Component, but which is not part of that 41607 Major Component, and (b) serves only to enable use of the work with 41608 that Major Component, or to implement a Standard Interface for 41609 which an implementation is available to the public in source code 41610 form. A "Major Component", in this context, means a major 41611 essential component (kernel, window system, and so on) of the 41612 specific operating system (if any) on which the executable work 41613 runs, or a compiler used to produce the work, or an object code 41614 interpreter used to run it. 41615 41616 The "Corresponding Source" for a work in object code form means all 41617 the source code needed to generate, install, and (for an executable 41618 work) run the object code and to modify the work, including scripts 41619 to control those activities. However, it does not include the 41620 work's System Libraries, or general-purpose tools or generally 41621 available free programs which are used unmodified in performing 41622 those activities but which are not part of the work. For example, 41623 Corresponding Source includes interface definition files associated 41624 with source files for the work, and the source code for shared 41625 libraries and dynamically linked subprograms that the work is 41626 specifically designed to require, such as by intimate data 41627 communication or control flow between those subprograms and other 41628 parts of the work. 41629 41630 The Corresponding Source need not include anything that users can 41631 regenerate automatically from other parts of the Corresponding 41632 Source. 41633 41634 The Corresponding Source for a work in source code form is that 41635 same work. 41636 41637 2. Basic Permissions. 41638 41639 All rights granted under this License are granted for the term of 41640 copyright on the Program, and are irrevocable provided the stated 41641 conditions are met. This License explicitly affirms your unlimited 41642 permission to run the unmodified Program. The output from running 41643 a covered work is covered by this License only if the output, given 41644 its content, constitutes a covered work. This License acknowledges 41645 your rights of fair use or other equivalent, as provided by 41646 copyright law. 41647 41648 You may make, run and propagate covered works that you do not 41649 convey, without conditions so long as your license otherwise 41650 remains in force. You may convey covered works to others for the 41651 sole purpose of having them make modifications exclusively for you, 41652 or provide you with facilities for running those works, provided 41653 that you comply with the terms of this License in conveying all 41654 material for which you do not control copyright. Those thus making 41655 or running the covered works for you must do so exclusively on your 41656 behalf, under your direction and control, on terms that prohibit 41657 them from making any copies of your copyrighted material outside 41658 their relationship with you. 41659 41660 Conveying under any other circumstances is permitted solely under 41661 the conditions stated below. Sublicensing is not allowed; section 41662 10 makes it unnecessary. 41663 41664 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 41665 41666 No covered work shall be deemed part of an effective technological 41667 measure under any applicable law fulfilling obligations under 41668 article 11 of the WIPO copyright treaty adopted on 20 December 41669 1996, or similar laws prohibiting or restricting circumvention of 41670 such measures. 41671 41672 When you convey a covered work, you waive any legal power to forbid 41673 circumvention of technological measures to the extent such 41674 circumvention is effected by exercising rights under this License 41675 with respect to the covered work, and you disclaim any intention to 41676 limit operation or modification of the work as a means of 41677 enforcing, against the work's users, your or third parties' legal 41678 rights to forbid circumvention of technological measures. 41679 41680 4. Conveying Verbatim Copies. 41681 41682 You may convey verbatim copies of the Program's source code as you 41683 receive it, in any medium, provided that you conspicuously and 41684 appropriately publish on each copy an appropriate copyright notice; 41685 keep intact all notices stating that this License and any 41686 non-permissive terms added in accord with section 7 apply to the 41687 code; keep intact all notices of the absence of any warranty; and 41688 give all recipients a copy of this License along with the Program. 41689 41690 You may charge any price or no price for each copy that you convey, 41691 and you may offer support or warranty protection for a fee. 41692 41693 5. Conveying Modified Source Versions. 41694 41695 You may convey a work based on the Program, or the modifications to 41696 produce it from the Program, in the form of source code under the 41697 terms of section 4, provided that you also meet all of these 41698 conditions: 41699 41700 a. The work must carry prominent notices stating that you 41701 modified it, and giving a relevant date. 41702 41703 b. The work must carry prominent notices stating that it is 41704 released under this License and any conditions added under 41705 section 7. This requirement modifies the requirement in 41706 section 4 to "keep intact all notices". 41707 41708 c. You must license the entire work, as a whole, under this 41709 License to anyone who comes into possession of a copy. This 41710 License will therefore apply, along with any applicable 41711 section 7 additional terms, to the whole of the work, and all 41712 its parts, regardless of how they are packaged. This License 41713 gives no permission to license the work in any other way, but 41714 it does not invalidate such permission if you have separately 41715 received it. 41716 41717 d. If the work has interactive user interfaces, each must display 41718 Appropriate Legal Notices; however, if the Program has 41719 interactive interfaces that do not display Appropriate Legal 41720 Notices, your work need not make them do so. 41721 41722 A compilation of a covered work with other separate and independent 41723 works, which are not by their nature extensions of the covered 41724 work, and which are not combined with it such as to form a larger 41725 program, in or on a volume of a storage or distribution medium, is 41726 called an "aggregate" if the compilation and its resulting 41727 copyright are not used to limit the access or legal rights of the 41728 compilation's users beyond what the individual works permit. 41729 Inclusion of a covered work in an aggregate does not cause this 41730 License to apply to the other parts of the aggregate. 41731 41732 6. Conveying Non-Source Forms. 41733 41734 You may convey a covered work in object code form under the terms 41735 of sections 4 and 5, provided that you also convey the 41736 machine-readable Corresponding Source under the terms of this 41737 License, in one of these ways: 41738 41739 a. Convey the object code in, or embodied in, a physical product 41740 (including a physical distribution medium), accompanied by the 41741 Corresponding Source fixed on a durable physical medium 41742 customarily used for software interchange. 41743 41744 b. Convey the object code in, or embodied in, a physical product 41745 (including a physical distribution medium), accompanied by a 41746 written offer, valid for at least three years and valid for as 41747 long as you offer spare parts or customer support for that 41748 product model, to give anyone who possesses the object code 41749 either (1) a copy of the Corresponding Source for all the 41750 software in the product that is covered by this License, on a 41751 durable physical medium customarily used for software 41752 interchange, for a price no more than your reasonable cost of 41753 physically performing this conveying of source, or (2) access 41754 to copy the Corresponding Source from a network server at no 41755 charge. 41756 41757 c. Convey individual copies of the object code with a copy of the 41758 written offer to provide the Corresponding Source. This 41759 alternative is allowed only occasionally and noncommercially, 41760 and only if you received the object code with such an offer, 41761 in accord with subsection 6b. 41762 41763 d. Convey the object code by offering access from a designated 41764 place (gratis or for a charge), and offer equivalent access to 41765 the Corresponding Source in the same way through the same 41766 place at no further charge. You need not require recipients 41767 to copy the Corresponding Source along with the object code. 41768 If the place to copy the object code is a network server, the 41769 Corresponding Source may be on a different server (operated by 41770 you or a third party) that supports equivalent copying 41771 facilities, provided you maintain clear directions next to the 41772 object code saying where to find the Corresponding Source. 41773 Regardless of what server hosts the Corresponding Source, you 41774 remain obligated to ensure that it is available for as long as 41775 needed to satisfy these requirements. 41776 41777 e. Convey the object code using peer-to-peer transmission, 41778 provided you inform other peers where the object code and 41779 Corresponding Source of the work are being offered to the 41780 general public at no charge under subsection 6d. 41781 41782 A separable portion of the object code, whose source code is 41783 excluded from the Corresponding Source as a System Library, need 41784 not be included in conveying the object code work. 41785 41786 A "User Product" is either (1) a "consumer product", which means 41787 any tangible personal property which is normally used for personal, 41788 family, or household purposes, or (2) anything designed or sold for 41789 incorporation into a dwelling. In determining whether a product is 41790 a consumer product, doubtful cases shall be resolved in favor of 41791 coverage. For a particular product received by a particular user, 41792 "normally used" refers to a typical or common use of that class of 41793 product, regardless of the status of the particular user or of the 41794 way in which the particular user actually uses, or expects or is 41795 expected to use, the product. A product is a consumer product 41796 regardless of whether the product has substantial commercial, 41797 industrial or non-consumer uses, unless such uses represent the 41798 only significant mode of use of the product. 41799 41800 "Installation Information" for a User Product means any methods, 41801 procedures, authorization keys, or other information required to 41802 install and execute modified versions of a covered work in that 41803 User Product from a modified version of its Corresponding Source. 41804 The information must suffice to ensure that the continued 41805 functioning of the modified object code is in no case prevented or 41806 interfered with solely because modification has been made. 41807 41808 If you convey an object code work under this section in, or with, 41809 or specifically for use in, a User Product, and the conveying 41810 occurs as part of a transaction in which the right of possession 41811 and use of the User Product is transferred to the recipient in 41812 perpetuity or for a fixed term (regardless of how the transaction 41813 is characterized), the Corresponding Source conveyed under this 41814 section must be accompanied by the Installation Information. But 41815 this requirement does not apply if neither you nor any third party 41816 retains the ability to install modified object code on the User 41817 Product (for example, the work has been installed in ROM). 41818 41819 The requirement to provide Installation Information does not 41820 include a requirement to continue to provide support service, 41821 warranty, or updates for a work that has been modified or installed 41822 by the recipient, or for the User Product in which it has been 41823 modified or installed. Access to a network may be denied when the 41824 modification itself materially and adversely affects the operation 41825 of the network or violates the rules and protocols for 41826 communication across the network. 41827 41828 Corresponding Source conveyed, and Installation Information 41829 provided, in accord with this section must be in a format that is 41830 publicly documented (and with an implementation available to the 41831 public in source code form), and must require no special password 41832 or key for unpacking, reading or copying. 41833 41834 7. Additional Terms. 41835 41836 "Additional permissions" are terms that supplement the terms of 41837 this License by making exceptions from one or more of its 41838 conditions. Additional permissions that are applicable to the 41839 entire Program shall be treated as though they were included in 41840 this License, to the extent that they are valid under applicable 41841 law. If additional permissions apply only to part of the Program, 41842 that part may be used separately under those permissions, but the 41843 entire Program remains governed by this License without regard to 41844 the additional permissions. 41845 41846 When you convey a copy of a covered work, you may at your option 41847 remove any additional permissions from that copy, or from any part 41848 of it. (Additional permissions may be written to require their own 41849 removal in certain cases when you modify the work.) You may place 41850 additional permissions on material, added by you to a covered work, 41851 for which you have or can give appropriate copyright permission. 41852 41853 Notwithstanding any other provision of this License, for material 41854 you add to a covered work, you may (if authorized by the copyright 41855 holders of that material) supplement the terms of this License with 41856 terms: 41857 41858 a. Disclaiming warranty or limiting liability differently from 41859 the terms of sections 15 and 16 of this License; or 41860 41861 b. Requiring preservation of specified reasonable legal notices 41862 or author attributions in that material or in the Appropriate 41863 Legal Notices displayed by works containing it; or 41864 41865 c. Prohibiting misrepresentation of the origin of that material, 41866 or requiring that modified versions of such material be marked 41867 in reasonable ways as different from the original version; or 41868 41869 d. Limiting the use for publicity purposes of names of licensors 41870 or authors of the material; or 41871 41872 e. Declining to grant rights under trademark law for use of some 41873 trade names, trademarks, or service marks; or 41874 41875 f. Requiring indemnification of licensors and authors of that 41876 material by anyone who conveys the material (or modified 41877 versions of it) with contractual assumptions of liability to 41878 the recipient, for any liability that these contractual 41879 assumptions directly impose on those licensors and authors. 41880 41881 All other non-permissive additional terms are considered "further 41882 restrictions" within the meaning of section 10. If the Program as 41883 you received it, or any part of it, contains a notice stating that 41884 it is governed by this License along with a term that is a further 41885 restriction, you may remove that term. If a license document 41886 contains a further restriction but permits relicensing or conveying 41887 under this License, you may add to a covered work material governed 41888 by the terms of that license document, provided that the further 41889 restriction does not survive such relicensing or conveying. 41890 41891 If you add terms to a covered work in accord with this section, you 41892 must place, in the relevant source files, a statement of the 41893 additional terms that apply to those files, or a notice indicating 41894 where to find the applicable terms. 41895 41896 Additional terms, permissive or non-permissive, may be stated in 41897 the form of a separately written license, or stated as exceptions; 41898 the above requirements apply either way. 41899 41900 8. Termination. 41901 41902 You may not propagate or modify a covered work except as expressly 41903 provided under this License. Any attempt otherwise to propagate or 41904 modify it is void, and will automatically terminate your rights 41905 under this License (including any patent licenses granted under the 41906 third paragraph of section 11). 41907 41908 However, if you cease all violation of this License, then your 41909 license from a particular copyright holder is reinstated (a) 41910 provisionally, unless and until the copyright holder explicitly and 41911 finally terminates your license, and (b) permanently, if the 41912 copyright holder fails to notify you of the violation by some 41913 reasonable means prior to 60 days after the cessation. 41914 41915 Moreover, your license from a particular copyright holder is 41916 reinstated permanently if the copyright holder notifies you of the 41917 violation by some reasonable means, this is the first time you have 41918 received notice of violation of this License (for any work) from 41919 that copyright holder, and you cure the violation prior to 30 days 41920 after your receipt of the notice. 41921 41922 Termination of your rights under this section does not terminate 41923 the licenses of parties who have received copies or rights from you 41924 under this License. If your rights have been terminated and not 41925 permanently reinstated, you do not qualify to receive new licenses 41926 for the same material under section 10. 41927 41928 9. Acceptance Not Required for Having Copies. 41929 41930 You are not required to accept this License in order to receive or 41931 run a copy of the Program. Ancillary propagation of a covered work 41932 occurring solely as a consequence of using peer-to-peer 41933 transmission to receive a copy likewise does not require 41934 acceptance. However, nothing other than this License grants you 41935 permission to propagate or modify any covered work. These actions 41936 infringe copyright if you do not accept this License. Therefore, 41937 by modifying or propagating a covered work, you indicate your 41938 acceptance of this License to do so. 41939 41940 10. Automatic Licensing of Downstream Recipients. 41941 41942 Each time you convey a covered work, the recipient automatically 41943 receives a license from the original licensors, to run, modify and 41944 propagate that work, subject to this License. You are not 41945 responsible for enforcing compliance by third parties with this 41946 License. 41947 41948 An "entity transaction" is a transaction transferring control of an 41949 organization, or substantially all assets of one, or subdividing an 41950 organization, or merging organizations. If propagation of a 41951 covered work results from an entity transaction, each party to that 41952 transaction who receives a copy of the work also receives whatever 41953 licenses to the work the party's predecessor in interest had or 41954 could give under the previous paragraph, plus a right to possession 41955 of the Corresponding Source of the work from the predecessor in 41956 interest, if the predecessor has it or can get it with reasonable 41957 efforts. 41958 41959 You may not impose any further restrictions on the exercise of the 41960 rights granted or affirmed under this License. For example, you 41961 may not impose a license fee, royalty, or other charge for exercise 41962 of rights granted under this License, and you may not initiate 41963 litigation (including a cross-claim or counterclaim in a lawsuit) 41964 alleging that any patent claim is infringed by making, using, 41965 selling, offering for sale, or importing the Program or any portion 41966 of it. 41967 41968 11. Patents. 41969 41970 A "contributor" is a copyright holder who authorizes use under this 41971 License of the Program or a work on which the Program is based. 41972 The work thus licensed is called the contributor's "contributor 41973 version". 41974 41975 A contributor's "essential patent claims" are all patent claims 41976 owned or controlled by the contributor, whether already acquired or 41977 hereafter acquired, that would be infringed by some manner, 41978 permitted by this License, of making, using, or selling its 41979 contributor version, but do not include claims that would be 41980 infringed only as a consequence of further modification of the 41981 contributor version. For purposes of this definition, "control" 41982 includes the right to grant patent sublicenses in a manner 41983 consistent with the requirements of this License. 41984 41985 Each contributor grants you a non-exclusive, worldwide, 41986 royalty-free patent license under the contributor's essential 41987 patent claims, to make, use, sell, offer for sale, import and 41988 otherwise run, modify and propagate the contents of its contributor 41989 version. 41990 41991 In the following three paragraphs, a "patent license" is any 41992 express agreement or commitment, however denominated, not to 41993 enforce a patent (such as an express permission to practice a 41994 patent or covenant not to sue for patent infringement). To "grant" 41995 such a patent license to a party means to make such an agreement or 41996 commitment not to enforce a patent against the party. 41997 41998 If you convey a covered work, knowingly relying on a patent 41999 license, and the Corresponding Source of the work is not available 42000 for anyone to copy, free of charge and under the terms of this 42001 License, through a publicly available network server or other 42002 readily accessible means, then you must either (1) cause the 42003 Corresponding Source to be so available, or (2) arrange to deprive 42004 yourself of the benefit of the patent license for this particular 42005 work, or (3) arrange, in a manner consistent with the requirements 42006 of this License, to extend the patent license to downstream 42007 recipients. "Knowingly relying" means you have actual knowledge 42008 that, but for the patent license, your conveying the covered work 42009 in a country, or your recipient's use of the covered work in a 42010 country, would infringe one or more identifiable patents in that 42011 country that you have reason to believe are valid. 42012 42013 If, pursuant to or in connection with a single transaction or 42014 arrangement, you convey, or propagate by procuring conveyance of, a 42015 covered work, and grant a patent license to some of the parties 42016 receiving the covered work authorizing them to use, propagate, 42017 modify or convey a specific copy of the covered work, then the 42018 patent license you grant is automatically extended to all 42019 recipients of the covered work and works based on it. 42020 42021 A patent license is "discriminatory" if it does not include within 42022 the scope of its coverage, prohibits the exercise of, or is 42023 conditioned on the non-exercise of one or more of the rights that 42024 are specifically granted under this License. You may not convey a 42025 covered work if you are a party to an arrangement with a third 42026 party that is in the business of distributing software, under which 42027 you make payment to the third party based on the extent of your 42028 activity of conveying the work, and under which the third party 42029 grants, to any of the parties who would receive the covered work 42030 from you, a discriminatory patent license (a) in connection with 42031 copies of the covered work conveyed by you (or copies made from 42032 those copies), or (b) primarily for and in connection with specific 42033 products or compilations that contain the covered work, unless you 42034 entered into that arrangement, or that patent license was granted, 42035 prior to 28 March 2007. 42036 42037 Nothing in this License shall be construed as excluding or limiting 42038 any implied license or other defenses to infringement that may 42039 otherwise be available to you under applicable patent law. 42040 42041 12. No Surrender of Others' Freedom. 42042 42043 If conditions are imposed on you (whether by court order, agreement 42044 or otherwise) that contradict the conditions of this License, they 42045 do not excuse you from the conditions of this License. If you 42046 cannot convey a covered work so as to satisfy simultaneously your 42047 obligations under this License and any other pertinent obligations, 42048 then as a consequence you may not convey it at all. For example, 42049 if you agree to terms that obligate you to collect a royalty for 42050 further conveying from those to whom you convey the Program, the 42051 only way you could satisfy both those terms and this License would 42052 be to refrain entirely from conveying the Program. 42053 42054 13. Use with the GNU Affero General Public License. 42055 42056 Notwithstanding any other provision of this License, you have 42057 permission to link or combine any covered work with a work licensed 42058 under version 3 of the GNU Affero General Public License into a 42059 single combined work, and to convey the resulting work. The terms 42060 of this License will continue to apply to the part which is the 42061 covered work, but the special requirements of the GNU Affero 42062 General Public License, section 13, concerning interaction through 42063 a network will apply to the combination as such. 42064 42065 14. Revised Versions of this License. 42066 42067 The Free Software Foundation may publish revised and/or new 42068 versions of the GNU General Public License from time to time. Such 42069 new versions will be similar in spirit to the present version, but 42070 may differ in detail to address new problems or concerns. 42071 42072 Each version is given a distinguishing version number. If the 42073 Program specifies that a certain numbered version of the GNU 42074 General Public License "or any later version" applies to it, you 42075 have the option of following the terms and conditions either of 42076 that numbered version or of any later version published by the Free 42077 Software Foundation. If the Program does not specify a version 42078 number of the GNU General Public License, you may choose any 42079 version ever published by the Free Software Foundation. 42080 42081 If the Program specifies that a proxy can decide which future 42082 versions of the GNU General Public License can be used, that 42083 proxy's public statement of acceptance of a version permanently 42084 authorizes you to choose that version for the Program. 42085 42086 Later license versions may give you additional or different 42087 permissions. However, no additional obligations are imposed on any 42088 author or copyright holder as a result of your choosing to follow a 42089 later version. 42090 42091 15. Disclaimer of Warranty. 42092 42093 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 42094 APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE 42095 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" 42096 WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 42097 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 42098 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE 42099 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. 42100 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL 42101 NECESSARY SERVICING, REPAIR OR CORRECTION. 42102 42103 16. Limitation of Liability. 42104 42105 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 42106 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES 42107 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR 42108 DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 42109 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE 42110 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA 42111 BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 42112 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 42113 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF 42114 THE POSSIBILITY OF SUCH DAMAGES. 42115 42116 17. Interpretation of Sections 15 and 16. 42117 42118 If the disclaimer of warranty and limitation of liability provided 42119 above cannot be given local legal effect according to their terms, 42120 reviewing courts shall apply local law that most closely 42121 approximates an absolute waiver of all civil liability in 42122 connection with the Program, unless a warranty or assumption of 42123 liability accompanies a copy of the Program in return for a fee. 42124 42125END OF TERMS AND CONDITIONS 42126=========================== 42127 42128How to Apply These Terms to Your New Programs 42129============================================= 42130 42131If you develop a new program, and you want it to be of the greatest 42132possible use to the public, the best way to achieve this is to make it 42133free software which everyone can redistribute and change under these 42134terms. 42135 42136 To do so, attach the following notices to the program. It is safest to 42137attach them to the start of each source file to most effectively state 42138the exclusion of warranty; and each file should have at least the 42139"copyright" line and a pointer to where the full notice is found. 42140 42141 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 42142 Copyright (C) YEAR NAME OF AUTHOR 42143 42144 This program is free software: you can redistribute it and/or modify 42145 it under the terms of the GNU General Public License as published by 42146 the Free Software Foundation, either version 3 of the License, or (at 42147 your option) any later version. 42148 42149 This program is distributed in the hope that it will be useful, but 42150 WITHOUT ANY WARRANTY; without even the implied warranty of 42151 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 42152 General Public License for more details. 42153 42154 You should have received a copy of the GNU General Public License 42155 along with this program. If not, see <http://www.gnu.org/licenses/>. 42156 42157 Also add information on how to contact you by electronic and paper 42158mail. 42159 42160 If the program does terminal interaction, make it output a short notice 42161like this when it starts in an interactive mode: 42162 42163 PROGRAM Copyright (C) YEAR NAME OF AUTHOR 42164 This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'. 42165 This is free software, and you are welcome to redistribute it 42166 under certain conditions; type 'show c' for details. 42167 42168 The hypothetical commands 'show w' and 'show c' should show the 42169appropriate parts of the General Public License. Of course, your 42170program's commands might be different; for a GUI interface, you would 42171use an "about box". 42172 42173 You should also get your employer (if you work as a programmer) or 42174school, if any, to sign a "copyright disclaimer" for the program, if 42175necessary. For more information on this, and how to apply and follow 42176the GNU GPL, see <http://www.gnu.org/licenses/>. 42177 42178 The GNU General Public License does not permit incorporating your 42179program into proprietary programs. If your program is a subroutine 42180library, you may consider it more useful to permit linking proprietary 42181applications with the library. If this is what you want to do, use the 42182GNU Lesser General Public License instead of this License. But first, 42183please read <http://www.gnu.org/philosophy/why-not-lgpl.html>. 42184 42185 42186File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 42187 42188GNU Free Documentation License 42189****************************** 42190 42191 Version 1.3, 3 November 2008 42192 42193 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. 42194 <http://fsf.org/> 42195 42196 Everyone is permitted to copy and distribute verbatim copies 42197 of this license document, but changing it is not allowed. 42198 42199 0. PREAMBLE 42200 42201 The purpose of this License is to make a manual, textbook, or other 42202 functional and useful document "free" in the sense of freedom: to 42203 assure everyone the effective freedom to copy and redistribute it, 42204 with or without modifying it, either commercially or 42205 noncommercially. Secondarily, this License preserves for the 42206 author and publisher a way to get credit for their work, while not 42207 being considered responsible for modifications made by others. 42208 42209 This License is a kind of "copyleft", which means that derivative 42210 works of the document must themselves be free in the same sense. 42211 It complements the GNU General Public License, which is a copyleft 42212 license designed for free software. 42213 42214 We have designed this License in order to use it for manuals for 42215 free software, because free software needs free documentation: a 42216 free program should come with manuals providing the same freedoms 42217 that the software does. But this License is not limited to 42218 software manuals; it can be used for any textual work, regardless 42219 of subject matter or whether it is published as a printed book. We 42220 recommend this License principally for works whose purpose is 42221 instruction or reference. 42222 42223 1. APPLICABILITY AND DEFINITIONS 42224 42225 This License applies to any manual or other work, in any medium, 42226 that contains a notice placed by the copyright holder saying it can 42227 be distributed under the terms of this License. Such a notice 42228 grants a world-wide, royalty-free license, unlimited in duration, 42229 to use that work under the conditions stated herein. The 42230 "Document", below, refers to any such manual or work. Any member 42231 of the public is a licensee, and is addressed as "you". You accept 42232 the license if you copy, modify or distribute the work in a way 42233 requiring permission under copyright law. 42234 42235 A "Modified Version" of the Document means any work containing the 42236 Document or a portion of it, either copied verbatim, or with 42237 modifications and/or translated into another language. 42238 42239 A "Secondary Section" is a named appendix or a front-matter section 42240 of the Document that deals exclusively with the relationship of the 42241 publishers or authors of the Document to the Document's overall 42242 subject (or to related matters) and contains nothing that could 42243 fall directly within that overall subject. (Thus, if the Document 42244 is in part a textbook of mathematics, a Secondary Section may not 42245 explain any mathematics.) The relationship could be a matter of 42246 historical connection with the subject or with related matters, or 42247 of legal, commercial, philosophical, ethical or political position 42248 regarding them. 42249 42250 The "Invariant Sections" are certain Secondary Sections whose 42251 titles are designated, as being those of Invariant Sections, in the 42252 notice that says that the Document is released under this License. 42253 If a section does not fit the above definition of Secondary then it 42254 is not allowed to be designated as Invariant. The Document may 42255 contain zero Invariant Sections. If the Document does not identify 42256 any Invariant Sections then there are none. 42257 42258 The "Cover Texts" are certain short passages of text that are 42259 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 42260 that says that the Document is released under this License. A 42261 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 42262 be at most 25 words. 42263 42264 A "Transparent" copy of the Document means a machine-readable copy, 42265 represented in a format whose specification is available to the 42266 general public, that is suitable for revising the document 42267 straightforwardly with generic text editors or (for images composed 42268 of pixels) generic paint programs or (for drawings) some widely 42269 available drawing editor, and that is suitable for input to text 42270 formatters or for automatic translation to a variety of formats 42271 suitable for input to text formatters. A copy made in an otherwise 42272 Transparent file format whose markup, or absence of markup, has 42273 been arranged to thwart or discourage subsequent modification by 42274 readers is not Transparent. An image format is not Transparent if 42275 used for any substantial amount of text. A copy that is not 42276 "Transparent" is called "Opaque". 42277 42278 Examples of suitable formats for Transparent copies include plain 42279 ASCII without markup, Texinfo input format, LaTeX input format, 42280 SGML or XML using a publicly available DTD, and standard-conforming 42281 simple HTML, PostScript or PDF designed for human modification. 42282 Examples of transparent image formats include PNG, XCF and JPG. 42283 Opaque formats include proprietary formats that can be read and 42284 edited only by proprietary word processors, SGML or XML for which 42285 the DTD and/or processing tools are not generally available, and 42286 the machine-generated HTML, PostScript or PDF produced by some word 42287 processors for output purposes only. 42288 42289 The "Title Page" means, for a printed book, the title page itself, 42290 plus such following pages as are needed to hold, legibly, the 42291 material this License requires to appear in the title page. For 42292 works in formats which do not have any title page as such, "Title 42293 Page" means the text near the most prominent appearance of the 42294 work's title, preceding the beginning of the body of the text. 42295 42296 The "publisher" means any person or entity that distributes copies 42297 of the Document to the public. 42298 42299 A section "Entitled XYZ" means a named subunit of the Document 42300 whose title either is precisely XYZ or contains XYZ in parentheses 42301 following text that translates XYZ in another language. (Here XYZ 42302 stands for a specific section name mentioned below, such as 42303 "Acknowledgements", "Dedications", "Endorsements", or "History".) 42304 To "Preserve the Title" of such a section when you modify the 42305 Document means that it remains a section "Entitled XYZ" according 42306 to this definition. 42307 42308 The Document may include Warranty Disclaimers next to the notice 42309 which states that this License applies to the Document. These 42310 Warranty Disclaimers are considered to be included by reference in 42311 this License, but only as regards disclaiming warranties: any other 42312 implication that these Warranty Disclaimers may have is void and 42313 has no effect on the meaning of this License. 42314 42315 2. VERBATIM COPYING 42316 42317 You may copy and distribute the Document in any medium, either 42318 commercially or noncommercially, provided that this License, the 42319 copyright notices, and the license notice saying this License 42320 applies to the Document are reproduced in all copies, and that you 42321 add no other conditions whatsoever to those of this License. You 42322 may not use technical measures to obstruct or control the reading 42323 or further copying of the copies you make or distribute. However, 42324 you may accept compensation in exchange for copies. If you 42325 distribute a large enough number of copies you must also follow the 42326 conditions in section 3. 42327 42328 You may also lend copies, under the same conditions stated above, 42329 and you may publicly display copies. 42330 42331 3. COPYING IN QUANTITY 42332 42333 If you publish printed copies (or copies in media that commonly 42334 have printed covers) of the Document, numbering more than 100, and 42335 the Document's license notice requires Cover Texts, you must 42336 enclose the copies in covers that carry, clearly and legibly, all 42337 these Cover Texts: Front-Cover Texts on the front cover, and 42338 Back-Cover Texts on the back cover. Both covers must also clearly 42339 and legibly identify you as the publisher of these copies. The 42340 front cover must present the full title with all words of the title 42341 equally prominent and visible. You may add other material on the 42342 covers in addition. Copying with changes limited to the covers, as 42343 long as they preserve the title of the Document and satisfy these 42344 conditions, can be treated as verbatim copying in other respects. 42345 42346 If the required texts for either cover are too voluminous to fit 42347 legibly, you should put the first ones listed (as many as fit 42348 reasonably) on the actual cover, and continue the rest onto 42349 adjacent pages. 42350 42351 If you publish or distribute Opaque copies of the Document 42352 numbering more than 100, you must either include a machine-readable 42353 Transparent copy along with each Opaque copy, or state in or with 42354 each Opaque copy a computer-network location from which the general 42355 network-using public has access to download using public-standard 42356 network protocols a complete Transparent copy of the Document, free 42357 of added material. If you use the latter option, you must take 42358 reasonably prudent steps, when you begin distribution of Opaque 42359 copies in quantity, to ensure that this Transparent copy will 42360 remain thus accessible at the stated location until at least one 42361 year after the last time you distribute an Opaque copy (directly or 42362 through your agents or retailers) of that edition to the public. 42363 42364 It is requested, but not required, that you contact the authors of 42365 the Document well before redistributing any large number of copies, 42366 to give them a chance to provide you with an updated version of the 42367 Document. 42368 42369 4. MODIFICATIONS 42370 42371 You may copy and distribute a Modified Version of the Document 42372 under the conditions of sections 2 and 3 above, provided that you 42373 release the Modified Version under precisely this License, with the 42374 Modified Version filling the role of the Document, thus licensing 42375 distribution and modification of the Modified Version to whoever 42376 possesses a copy of it. In addition, you must do these things in 42377 the Modified Version: 42378 42379 A. Use in the Title Page (and on the covers, if any) a title 42380 distinct from that of the Document, and from those of previous 42381 versions (which should, if there were any, be listed in the 42382 History section of the Document). You may use the same title 42383 as a previous version if the original publisher of that 42384 version gives permission. 42385 42386 B. List on the Title Page, as authors, one or more persons or 42387 entities responsible for authorship of the modifications in 42388 the Modified Version, together with at least five of the 42389 principal authors of the Document (all of its principal 42390 authors, if it has fewer than five), unless they release you 42391 from this requirement. 42392 42393 C. State on the Title page the name of the publisher of the 42394 Modified Version, as the publisher. 42395 42396 D. Preserve all the copyright notices of the Document. 42397 42398 E. Add an appropriate copyright notice for your modifications 42399 adjacent to the other copyright notices. 42400 42401 F. Include, immediately after the copyright notices, a license 42402 notice giving the public permission to use the Modified 42403 Version under the terms of this License, in the form shown in 42404 the Addendum below. 42405 42406 G. Preserve in that license notice the full lists of Invariant 42407 Sections and required Cover Texts given in the Document's 42408 license notice. 42409 42410 H. Include an unaltered copy of this License. 42411 42412 I. Preserve the section Entitled "History", Preserve its Title, 42413 and add to it an item stating at least the title, year, new 42414 authors, and publisher of the Modified Version as given on the 42415 Title Page. If there is no section Entitled "History" in the 42416 Document, create one stating the title, year, authors, and 42417 publisher of the Document as given on its Title Page, then add 42418 an item describing the Modified Version as stated in the 42419 previous sentence. 42420 42421 J. Preserve the network location, if any, given in the Document 42422 for public access to a Transparent copy of the Document, and 42423 likewise the network locations given in the Document for 42424 previous versions it was based on. These may be placed in the 42425 "History" section. You may omit a network location for a work 42426 that was published at least four years before the Document 42427 itself, or if the original publisher of the version it refers 42428 to gives permission. 42429 42430 K. For any section Entitled "Acknowledgements" or "Dedications", 42431 Preserve the Title of the section, and preserve in the section 42432 all the substance and tone of each of the contributor 42433 acknowledgements and/or dedications given therein. 42434 42435 L. Preserve all the Invariant Sections of the Document, unaltered 42436 in their text and in their titles. Section numbers or the 42437 equivalent are not considered part of the section titles. 42438 42439 M. Delete any section Entitled "Endorsements". Such a section 42440 may not be included in the Modified Version. 42441 42442 N. Do not retitle any existing section to be Entitled 42443 "Endorsements" or to conflict in title with any Invariant 42444 Section. 42445 42446 O. Preserve any Warranty Disclaimers. 42447 42448 If the Modified Version includes new front-matter sections or 42449 appendices that qualify as Secondary Sections and contain no 42450 material copied from the Document, you may at your option designate 42451 some or all of these sections as invariant. To do this, add their 42452 titles to the list of Invariant Sections in the Modified Version's 42453 license notice. These titles must be distinct from any other 42454 section titles. 42455 42456 You may add a section Entitled "Endorsements", provided it contains 42457 nothing but endorsements of your Modified Version by various 42458 parties--for example, statements of peer review or that the text 42459 has been approved by an organization as the authoritative 42460 definition of a standard. 42461 42462 You may add a passage of up to five words as a Front-Cover Text, 42463 and a passage of up to 25 words as a Back-Cover Text, to the end of 42464 the list of Cover Texts in the Modified Version. Only one passage 42465 of Front-Cover Text and one of Back-Cover Text may be added by (or 42466 through arrangements made by) any one entity. If the Document 42467 already includes a cover text for the same cover, previously added 42468 by you or by arrangement made by the same entity you are acting on 42469 behalf of, you may not add another; but you may replace the old 42470 one, on explicit permission from the previous publisher that added 42471 the old one. 42472 42473 The author(s) and publisher(s) of the Document do not by this 42474 License give permission to use their names for publicity for or to 42475 assert or imply endorsement of any Modified Version. 42476 42477 5. COMBINING DOCUMENTS 42478 42479 You may combine the Document with other documents released under 42480 this License, under the terms defined in section 4 above for 42481 modified versions, provided that you include in the combination all 42482 of the Invariant Sections of all of the original documents, 42483 unmodified, and list them all as Invariant Sections of your 42484 combined work in its license notice, and that you preserve all 42485 their Warranty Disclaimers. 42486 42487 The combined work need only contain one copy of this License, and 42488 multiple identical Invariant Sections may be replaced with a single 42489 copy. If there are multiple Invariant Sections with the same name 42490 but different contents, make the title of each such section unique 42491 by adding at the end of it, in parentheses, the name of the 42492 original author or publisher of that section if known, or else a 42493 unique number. Make the same adjustment to the section titles in 42494 the list of Invariant Sections in the license notice of the 42495 combined work. 42496 42497 In the combination, you must combine any sections Entitled 42498 "History" in the various original documents, forming one section 42499 Entitled "History"; likewise combine any sections Entitled 42500 "Acknowledgements", and any sections Entitled "Dedications". You 42501 must delete all sections Entitled "Endorsements." 42502 42503 6. COLLECTIONS OF DOCUMENTS 42504 42505 You may make a collection consisting of the Document and other 42506 documents released under this License, and replace the individual 42507 copies of this License in the various documents with a single copy 42508 that is included in the collection, provided that you follow the 42509 rules of this License for verbatim copying of each of the documents 42510 in all other respects. 42511 42512 You may extract a single document from such a collection, and 42513 distribute it individually under this License, provided you insert 42514 a copy of this License into the extracted document, and follow this 42515 License in all other respects regarding verbatim copying of that 42516 document. 42517 42518 7. AGGREGATION WITH INDEPENDENT WORKS 42519 42520 A compilation of the Document or its derivatives with other 42521 separate and independent documents or works, in or on a volume of a 42522 storage or distribution medium, is called an "aggregate" if the 42523 copyright resulting from the compilation is not used to limit the 42524 legal rights of the compilation's users beyond what the individual 42525 works permit. When the Document is included in an aggregate, this 42526 License does not apply to the other works in the aggregate which 42527 are not themselves derivative works of the Document. 42528 42529 If the Cover Text requirement of section 3 is applicable to these 42530 copies of the Document, then if the Document is less than one half 42531 of the entire aggregate, the Document's Cover Texts may be placed 42532 on covers that bracket the Document within the aggregate, or the 42533 electronic equivalent of covers if the Document is in electronic 42534 form. Otherwise they must appear on printed covers that bracket 42535 the whole aggregate. 42536 42537 8. TRANSLATION 42538 42539 Translation is considered a kind of modification, so you may 42540 distribute translations of the Document under the terms of section 42541 4. Replacing Invariant Sections with translations requires special 42542 permission from their copyright holders, but you may include 42543 translations of some or all Invariant Sections in addition to the 42544 original versions of these Invariant Sections. You may include a 42545 translation of this License, and all the license notices in the 42546 Document, and any Warranty Disclaimers, provided that you also 42547 include the original English version of this License and the 42548 original versions of those notices and disclaimers. In case of a 42549 disagreement between the translation and the original version of 42550 this License or a notice or disclaimer, the original version will 42551 prevail. 42552 42553 If a section in the Document is Entitled "Acknowledgements", 42554 "Dedications", or "History", the requirement (section 4) to 42555 Preserve its Title (section 1) will typically require changing the 42556 actual title. 42557 42558 9. TERMINATION 42559 42560 You may not copy, modify, sublicense, or distribute the Document 42561 except as expressly provided under this License. Any attempt 42562 otherwise to copy, modify, sublicense, or distribute it is void, 42563 and will automatically terminate your rights under this License. 42564 42565 However, if you cease all violation of this License, then your 42566 license from a particular copyright holder is reinstated (a) 42567 provisionally, unless and until the copyright holder explicitly and 42568 finally terminates your license, and (b) permanently, if the 42569 copyright holder fails to notify you of the violation by some 42570 reasonable means prior to 60 days after the cessation. 42571 42572 Moreover, your license from a particular copyright holder is 42573 reinstated permanently if the copyright holder notifies you of the 42574 violation by some reasonable means, this is the first time you have 42575 received notice of violation of this License (for any work) from 42576 that copyright holder, and you cure the violation prior to 30 days 42577 after your receipt of the notice. 42578 42579 Termination of your rights under this section does not terminate 42580 the licenses of parties who have received copies or rights from you 42581 under this License. If your rights have been terminated and not 42582 permanently reinstated, receipt of a copy of some or all of the 42583 same material does not give you any rights to use it. 42584 42585 10. FUTURE REVISIONS OF THIS LICENSE 42586 42587 The Free Software Foundation may publish new, revised versions of 42588 the GNU Free Documentation License from time to time. Such new 42589 versions will be similar in spirit to the present version, but may 42590 differ in detail to address new problems or concerns. See 42591 <http://www.gnu.org/copyleft/>. 42592 42593 Each version of the License is given a distinguishing version 42594 number. If the Document specifies that a particular numbered 42595 version of this License "or any later version" applies to it, you 42596 have the option of following the terms and conditions either of 42597 that specified version or of any later version that has been 42598 published (not as a draft) by the Free Software Foundation. If the 42599 Document does not specify a version number of this License, you may 42600 choose any version ever published (not as a draft) by the Free 42601 Software Foundation. If the Document specifies that a proxy can 42602 decide which future versions of this License can be used, that 42603 proxy's public statement of acceptance of a version permanently 42604 authorizes you to choose that version for the Document. 42605 42606 11. RELICENSING 42607 42608 "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 42609 World Wide Web server that publishes copyrightable works and also 42610 provides prominent facilities for anybody to edit those works. A 42611 public wiki that anybody can edit is an example of such a server. 42612 A "Massive Multiauthor Collaboration" (or "MMC") contained in the 42613 site means any set of copyrightable works thus published on the MMC 42614 site. 42615 42616 "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 42617 license published by Creative Commons Corporation, a not-for-profit 42618 corporation with a principal place of business in San Francisco, 42619 California, as well as future copyleft versions of that license 42620 published by that same organization. 42621 42622 "Incorporate" means to publish or republish a Document, in whole or 42623 in part, as part of another Document. 42624 42625 An MMC is "eligible for relicensing" if it is licensed under this 42626 License, and if all works that were first published under this 42627 License somewhere other than this MMC, and subsequently 42628 incorporated in whole or in part into the MMC, (1) had no cover 42629 texts or invariant sections, and (2) were thus incorporated prior 42630 to November 1, 2008. 42631 42632 The operator of an MMC Site may republish an MMC contained in the 42633 site under CC-BY-SA on the same site at any time before August 1, 42634 2009, provided the MMC is eligible for relicensing. 42635 42636ADDENDUM: How to use this License for your documents 42637==================================================== 42638 42639To use this License in a document you have written, include a copy of 42640the License in the document and put the following copyright and license 42641notices just after the title page: 42642 42643 Copyright (C) YEAR YOUR NAME. 42644 Permission is granted to copy, distribute and/or modify this document 42645 under the terms of the GNU Free Documentation License, Version 1.3 42646 or any later version published by the Free Software Foundation; 42647 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 42648 Texts. A copy of the license is included in the section entitled ``GNU 42649 Free Documentation License''. 42650 42651 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 42652replace the "with...Texts." line with this: 42653 42654 with the Invariant Sections being LIST THEIR TITLES, with 42655 the Front-Cover Texts being LIST, and with the Back-Cover Texts 42656 being LIST. 42657 42658 If you have Invariant Sections without Cover Texts, or some other 42659combination of the three, merge those two alternatives to suit the 42660situation. 42661 42662 If your document contains nontrivial examples of program code, we 42663recommend releasing these examples in parallel under your choice of free 42664software license, such as the GNU General Public License, to permit 42665their use in free software. 42666 42667 42668File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 42669 42670Contributors to GCC 42671******************* 42672 42673The GCC project would like to thank its many contributors. Without them 42674the project would not have been nearly as successful as it has been. 42675Any omissions in this list are accidental. Feel free to contact 42676<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or 42677some of your contributions are not listed. Please keep this list in 42678alphabetical order. 42679 42680 * Analog Devices helped implement the support for complex data types 42681 and iterators. 42682 42683 * John David Anglin for threading-related fixes and improvements to 42684 libstdc++-v3, and the HP-UX port. 42685 42686 * James van Artsdalen wrote the code that makes efficient use of the 42687 Intel 80387 register stack. 42688 42689 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 42690 Series port. 42691 42692 * Alasdair Baird for various bug fixes. 42693 42694 * Giovanni Bajo for analyzing lots of complicated C++ problem 42695 reports. 42696 42697 * Peter Barada for his work to improve code generation for new 42698 ColdFire cores. 42699 42700 * Gerald Baumgartner added the signature extension to the C++ front 42701 end. 42702 42703 * Godmar Back for his Java improvements and encouragement. 42704 42705 * Scott Bambrough for help porting the Java compiler. 42706 42707 * Wolfgang Bangerth for processing tons of bug reports. 42708 42709 * Jon Beniston for his Microsoft Windows port of Java and port to 42710 Lattice Mico32. 42711 42712 * Daniel Berlin for better DWARF 2 support, faster/better 42713 optimizations, improved alias analysis, plus migrating GCC to 42714 Bugzilla. 42715 42716 * Geoff Berry for his Java object serialization work and various 42717 patches. 42718 42719 * David Binderman tests weekly snapshots of GCC trunk against Fedora 42720 Rawhide for several architectures. 42721 42722 * Laurynas Biveinis for memory management work and DJGPP port fixes. 42723 42724 * Uros Bizjak for the implementation of x87 math built-in functions 42725 and for various middle end and i386 back end improvements and bug 42726 fixes. 42727 42728 * Eric Blake for helping to make GCJ and libgcj conform to the 42729 specifications. 42730 42731 * Janne Blomqvist for contributions to GNU Fortran. 42732 42733 * Segher Boessenkool for various fixes. 42734 42735 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 42736 other Java work. 42737 42738 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 42739 miscellaneous clean-ups. 42740 42741 * Steven Bosscher for integrating the GNU Fortran front end into GCC 42742 and for contributing to the tree-ssa branch. 42743 42744 * Eric Botcazou for fixing middle- and backend bugs left and right. 42745 42746 * Per Bothner for his direction via the steering committee and 42747 various improvements to the infrastructure for supporting new 42748 languages. Chill front end implementation. Initial 42749 implementations of cpplib, fix-header, config.guess, libio, and 42750 past C++ library (libg++) maintainer. Dreaming up, designing and 42751 implementing much of GCJ. 42752 42753 * Devon Bowen helped port GCC to the Tahoe. 42754 42755 * Don Bowman for mips-vxworks contributions. 42756 42757 * James Bowman for the FT32 port. 42758 42759 * Dave Brolley for work on cpplib and Chill. 42760 42761 * Paul Brook for work on the ARM architecture and maintaining GNU 42762 Fortran. 42763 42764 * Robert Brown implemented the support for Encore 32000 systems. 42765 42766 * Christian Bruel for improvements to local store elimination. 42767 42768 * Herman A.J. ten Brugge for various fixes. 42769 42770 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 42771 FAQ. 42772 42773 * Joe Buck for his direction via the steering committee from its 42774 creation to 2013. 42775 42776 * Craig Burley for leadership of the G77 Fortran effort. 42777 42778 * Stephan Buys for contributing Doxygen notes for libstdc++. 42779 42780 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 42781 to the C++ strings, streambufs and formatted I/O, hard detective 42782 work on the frustrating localization issues, and keeping up with 42783 the problem reports. 42784 42785 * John Carr for his alias work, SPARC hacking, infrastructure 42786 improvements, previous contributions to the steering committee, 42787 loop optimizations, etc. 42788 42789 * Stephane Carrez for 68HC11 and 68HC12 ports. 42790 42791 * Steve Chamberlain for support for the Renesas SH and H8 processors 42792 and the PicoJava processor, and for GCJ config fixes. 42793 42794 * Glenn Chambers for help with the GCJ FAQ. 42795 42796 * John-Marc Chandonia for various libgcj patches. 42797 42798 * Denis Chertykov for contributing and maintaining the AVR port, the 42799 first GCC port for an 8-bit architecture. 42800 42801 * Scott Christley for his Objective-C contributions. 42802 42803 * Eric Christopher for his Java porting help and clean-ups. 42804 42805 * Branko Cibej for more warning contributions. 42806 42807 * The GNU Classpath project for all of their merged runtime code. 42808 42809 * Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work, 42810 '--help', and other random hacking. 42811 42812 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 42813 42814 * R. Kelley Cook for making GCC buildable from a read-only directory 42815 as well as other miscellaneous build process and documentation 42816 clean-ups. 42817 42818 * Ralf Corsepius for SH testing and minor bug fixing. 42819 42820 * Stan Cox for care and feeding of the x86 port and lots of behind 42821 the scenes hacking. 42822 42823 * Alex Crain provided changes for the 3b1. 42824 42825 * Ian Dall for major improvements to the NS32k port. 42826 42827 * Paul Dale for his work to add uClinux platform support to the m68k 42828 backend. 42829 42830 * Dario Dariol contributed the four varieties of sample programs that 42831 print a copy of their source. 42832 42833 * Russell Davidson for fstream and stringstream fixes in libstdc++. 42834 42835 * Bud Davis for work on the G77 and GNU Fortran compilers. 42836 42837 * Mo DeJong for GCJ and libgcj bug fixes. 42838 42839 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 42840 various bug fixes, and the M32C, MeP, MSP430, and RL78 ports. 42841 42842 * Arnaud Desitter for helping to debug GNU Fortran. 42843 42844 * Gabriel Dos Reis for contributions to G++, contributions and 42845 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 42846 including 'valarray<>', 'complex<>', maintaining the numerics 42847 library (including that pesky '<limits>' :-) and keeping up-to-date 42848 anything to do with numbers. 42849 42850 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 42851 ISO C99 support, CFG dumping support, etc., plus support of the C++ 42852 runtime libraries including for all kinds of C interface issues, 42853 contributing and maintaining 'complex<>', sanity checking and 42854 disbursement, configuration architecture, libio maintenance, and 42855 early math work. 42856 42857 * Franc,ois Dumont for his work on libstdc++-v3, especially 42858 maintaining and improving 'debug-mode' and associative and 42859 unordered containers. 42860 42861 * Zdenek Dvorak for a new loop unroller and various fixes. 42862 42863 * Michael Eager for his work on the Xilinx MicroBlaze port. 42864 42865 * Richard Earnshaw for his ongoing work with the ARM. 42866 42867 * David Edelsohn for his direction via the steering committee, 42868 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 42869 loop changes, doing the entire AIX port of libstdc++ with his bare 42870 hands, and for ensuring GCC properly keeps working on AIX. 42871 42872 * Kevin Ediger for the floating point formatting of num_put::do_put 42873 in libstdc++. 42874 42875 * Phil Edwards for libstdc++ work including configuration hackery, 42876 documentation maintainer, chief breaker of the web pages, the 42877 occasional iostream bug fix, and work on shared library symbol 42878 versioning. 42879 42880 * Paul Eggert for random hacking all over GCC. 42881 42882 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 42883 configuration support for locales and fstream-related fixes. 42884 42885 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 42886 iostreams. 42887 42888 * Christian Ehrhardt for dealing with bug reports. 42889 42890 * Ben Elliston for his work to move the Objective-C runtime into its 42891 own subdirectory and for his work on autoconf. 42892 42893 * Revital Eres for work on the PowerPC 750CL port. 42894 42895 * Marc Espie for OpenBSD support. 42896 42897 * Doug Evans for much of the global optimization framework, arc, 42898 m32r, and SPARC work. 42899 42900 * Christopher Faylor for his work on the Cygwin port and for caring 42901 and feeding the gcc.gnu.org box and saving its users tons of spam. 42902 42903 * Fred Fish for BeOS support and Ada fixes. 42904 42905 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 42906 42907 * Peter Gerwinski for various bug fixes and the Pascal front end. 42908 42909 * Kaveh R. Ghazi for his direction via the steering committee, 42910 amazing work to make '-W -Wall -W* -Werror' useful, and testing GCC 42911 on a plethora of platforms. Kaveh extends his gratitude to the 42912 CAIP Center at Rutgers University for providing him with computing 42913 resources to work on Free Software from the late 1980s to 2010. 42914 42915 * John Gilmore for a donation to the FSF earmarked improving GNU 42916 Java. 42917 42918 * Judy Goldberg for c++ contributions. 42919 42920 * Torbjorn Granlund for various fixes and the c-torture testsuite, 42921 multiply- and divide-by-constant optimization, improved long long 42922 support, improved leaf function register allocation, and his 42923 direction via the steering committee. 42924 42925 * Jonny Grant for improvements to 'collect2's' '--help' 42926 documentation. 42927 42928 * Anthony Green for his '-Os' contributions, the moxie port, and Java 42929 front end work. 42930 42931 * Stu Grossman for gdb hacking, allowing GCJ developers to debug Java 42932 code. 42933 42934 * Michael K. Gschwind contributed the port to the PDP-11. 42935 42936 * Richard Biener for his ongoing middle-end contributions and bug 42937 fixes and for release management. 42938 42939 * Ron Guilmette implemented the 'protoize' and 'unprotoize' tools, 42940 the support for DWARF 1 symbolic debugging information, and much of 42941 the support for System V Release 4. He has also worked heavily on 42942 the Intel 386 and 860 support. 42943 42944 * Sumanth Gundapaneni for contributing the CR16 port. 42945 42946 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 42947 GCSE. 42948 42949 * Bruno Haible for improvements in the runtime overhead for EH, new 42950 warnings and assorted bug fixes. 42951 42952 * Andrew Haley for his amazing Java compiler and library efforts. 42953 42954 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 42955 series 300. 42956 42957 * Michael Hayes for various thankless work he's done trying to get 42958 the c30/c40 ports functional. Lots of loop and unroll improvements 42959 and fixes. 42960 42961 * Dara Hazeghi for wading through myriads of target-specific bug 42962 reports. 42963 42964 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 42965 42966 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 42967 work, loop opts, and generally fixing lots of old problems we've 42968 ignored for years, flow rewrite and lots of further stuff, 42969 including reviewing tons of patches. 42970 42971 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 42972 various fixes. 42973 42974 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 42975 contributed the support for the Sony NEWS machine. 42976 42977 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 42978 various fixes. 42979 42980 * Katherine Holcomb for work on GNU Fortran. 42981 42982 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 42983 of testing and bug fixing, particularly of GCC configury code. 42984 42985 * Steve Holmgren for MachTen patches. 42986 42987 * Mat Hostetter for work on the TILE-Gx and TILEPro ports. 42988 42989 * Jan Hubicka for his x86 port improvements. 42990 42991 * Falk Hueffner for working on C and optimization bug reports. 42992 42993 * Bernardo Innocenti for his m68k work, including merging of ColdFire 42994 improvements and uClinux support. 42995 42996 * Christian Iseli for various bug fixes. 42997 42998 * Kamil Iskra for general m68k hacking. 42999 43000 * Lee Iverson for random fixes and MIPS testing. 43001 43002 * Balaji V. Iyer for Cilk+ development and merging. 43003 43004 * Andreas Jaeger for testing and benchmarking of GCC and various bug 43005 fixes. 43006 43007 * Martin Jambor for his work on inter-procedural optimizations, the 43008 switch conversion pass, and scalar replacement of aggregates. 43009 43010 * Jakub Jelinek for his SPARC work and sibling call optimizations as 43011 well as lots of bug fixes and test cases, and for improving the 43012 Java build system. 43013 43014 * Janis Johnson for ia64 testing and fixes, her quality improvement 43015 sidetracks, and web page maintenance. 43016 43017 * Kean Johnston for SCO OpenServer support and various fixes. 43018 43019 * Tim Josling for the sample language treelang based originally on 43020 Richard Kenner's "toy" language. 43021 43022 * Nicolai Josuttis for additional libstdc++ documentation. 43023 43024 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 43025 target. 43026 43027 * Steven G. Kargl for work on GNU Fortran. 43028 43029 * David Kashtan of SRI adapted GCC to VMS. 43030 43031 * Ryszard Kabatek for many, many libstdc++ bug fixes and 43032 optimizations of strings, especially member functions, and for 43033 auto_ptr fixes. 43034 43035 * Geoffrey Keating for his ongoing work to make the PPC work for 43036 GNU/Linux and his automatic regression tester. 43037 43038 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 43039 work in just about every part of libstdc++. 43040 43041 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 43042 MIL-STD-1750A. 43043 43044 * Richard Kenner of the New York University Ultracomputer Research 43045 Laboratory wrote the machine descriptions for the AMD 29000, the 43046 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 43047 support for instruction attributes. He also made changes to better 43048 support RISC processors including changes to common subexpression 43049 elimination, strength reduction, function calling sequence 43050 handling, and condition code support, in addition to generalizing 43051 the code for frame pointer elimination and delay slot scheduling. 43052 Richard Kenner was also the head maintainer of GCC for several 43053 years. 43054 43055 * Mumit Khan for various contributions to the Cygwin and Mingw32 43056 ports and maintaining binary releases for Microsoft Windows hosts, 43057 and for massive libstdc++ porting work to Cygwin/Mingw32. 43058 43059 * Robin Kirkham for cpu32 support. 43060 43061 * Mark Klein for PA improvements. 43062 43063 * Thomas Koenig for various bug fixes. 43064 43065 * Bruce Korb for the new and improved fixincludes code. 43066 43067 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 43068 effort. 43069 43070 * Maxim Kuvyrkov for contributions to the instruction scheduler, the 43071 Android and m68k/Coldfire ports, and optimizations. 43072 43073 * Charles LaBrec contributed the support for the Integrated Solutions 43074 68020 system. 43075 43076 * Asher Langton and Mike Kumbera for contributing Cray pointer 43077 support to GNU Fortran, and for other GNU Fortran improvements. 43078 43079 * Jeff Law for his direction via the steering committee, coordinating 43080 the entire egcs project and GCC 2.95, rolling out snapshots and 43081 releases, handling merges from GCC2, reviewing tons of patches that 43082 might have fallen through the cracks else, and random but extensive 43083 hacking. 43084 43085 * Walter Lee for work on the TILE-Gx and TILEPro ports. 43086 43087 * Marc Lehmann for his direction via the steering committee and 43088 helping with analysis and improvements of x86 performance. 43089 43090 * Victor Leikehman for work on GNU Fortran. 43091 43092 * Ted Lemon wrote parts of the RTL reader and printer. 43093 43094 * Kriang Lerdsuwanakij for C++ improvements including template as 43095 template parameter support, and many C++ fixes. 43096 43097 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 43098 and random work on the Java front end. 43099 43100 * Alain Lichnewsky ported GCC to the MIPS CPU. 43101 43102 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 43103 and patches. 43104 43105 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 43106 43107 * Chen Liqin for various S+core related fixes/improvement, and for 43108 maintaining the S+core port. 43109 43110 * Weiwen Liu for testing and various bug fixes. 43111 43112 * Manuel Lo'pez-Iba'n~ez for improving '-Wconversion' and many other 43113 diagnostics fixes and improvements. 43114 43115 * Dave Love for his ongoing work with the Fortran front end and 43116 runtime libraries. 43117 43118 * Martin von Lo"wis for internal consistency checking infrastructure, 43119 various C++ improvements including namespace support, and tons of 43120 assistance with libstdc++/compiler merges. 43121 43122 * H.J. Lu for his previous contributions to the steering committee, 43123 many x86 bug reports, prototype patches, and keeping the GNU/Linux 43124 ports working. 43125 43126 * Greg McGary for random fixes and (someday) bounded pointers. 43127 43128 * Andrew MacLeod for his ongoing work in building a real EH system, 43129 various code generation improvements, work on the global optimizer, 43130 etc. 43131 43132 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 43133 hacking improvements to compile-time performance, overall knowledge 43134 and direction in the area of instruction scheduling, and design and 43135 implementation of the automaton based instruction scheduler. 43136 43137 * Bob Manson for his behind the scenes work on dejagnu. 43138 43139 * John Marino for contributing the DragonFly BSD port. 43140 43141 * Philip Martin for lots of libstdc++ string and vector iterator 43142 fixes and improvements, and string clean up and testsuites. 43143 43144 * Michael Matz for his work on dominance tree discovery, the x86-64 43145 port, link-time optimization framework and general optimization 43146 improvements. 43147 43148 * All of the Mauve project contributors, for Java test code. 43149 43150 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 43151 43152 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 43153 43154 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 43155 powerpc, haifa, ECOFF debug support, and other assorted hacking. 43156 43157 * Jason Merrill for his direction via the steering committee and 43158 leading the G++ effort. 43159 43160 * Martin Michlmayr for testing GCC on several architectures using the 43161 entire Debian archive. 43162 43163 * David Miller for his direction via the steering committee, lots of 43164 SPARC work, improvements in jump.c and interfacing with the Linux 43165 kernel developers. 43166 43167 * Gary Miller ported GCC to Charles River Data Systems machines. 43168 43169 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 43170 the entire libstdc++ testsuite namespace-compatible. 43171 43172 * Mark Mitchell for his direction via the steering committee, 43173 mountains of C++ work, load/store hoisting out of loops, alias 43174 analysis improvements, ISO C 'restrict' support, and serving as 43175 release manager from 2000 to 2011. 43176 43177 * Alan Modra for various GNU/Linux bits and testing. 43178 43179 * Toon Moene for his direction via the steering committee, Fortran 43180 maintenance, and his ongoing work to make us make Fortran run fast. 43181 43182 * Jason Molenda for major help in the care and feeding of all the 43183 services on the gcc.gnu.org (formerly egcs.cygnus.com) 43184 machine--mail, web services, ftp services, etc etc. Doing all this 43185 work on scrap paper and the backs of envelopes would have been... 43186 difficult. 43187 43188 * Catherine Moore for fixing various ugly problems we have sent her 43189 way, including the haifa bug which was killing the Alpha & PowerPC 43190 Linux kernels. 43191 43192 * Mike Moreton for his various Java patches. 43193 43194 * David Mosberger-Tang for various Alpha improvements, and for the 43195 initial IA-64 port. 43196 43197 * Stephen Moshier contributed the floating point emulator that 43198 assists in cross-compilation and permits support for floating point 43199 numbers wider than 64 bits and for ISO C99 support. 43200 43201 * Bill Moyer for his behind the scenes work on various issues. 43202 43203 * Philippe De Muyter for his work on the m68k port. 43204 43205 * Joseph S. Myers for his work on the PDP-11 port, format checking 43206 and ISO C99 support, and continuous emphasis on (and contributions 43207 to) documentation. 43208 43209 * Nathan Myers for his work on libstdc++-v3: architecture and 43210 authorship through the first three snapshots, including 43211 implementation of locale infrastructure, string, shadow C headers, 43212 and the initial project documentation (DESIGN, CHECKLIST, and so 43213 forth). Later, more work on MT-safe string and shadow headers. 43214 43215 * Felix Natter for documentation on porting libstdc++. 43216 43217 * Nathanael Nerode for cleaning up the configuration/build process. 43218 43219 * NeXT, Inc. donated the front end that supports the Objective-C 43220 language. 43221 43222 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the 43223 search engine setup, various documentation fixes and other small 43224 fixes. 43225 43226 * Geoff Noer for his work on getting cygwin native builds working. 43227 43228 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 43229 tracking web pages, GIMPLE tuples, and assorted fixes. 43230 43231 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 43232 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and related 43233 infrastructure improvements. 43234 43235 * Alexandre Oliva for various build infrastructure improvements, 43236 scripts and amazing testing work, including keeping libtool issues 43237 sane and happy. 43238 43239 * Stefan Olsson for work on mt_alloc. 43240 43241 * Melissa O'Neill for various NeXT fixes. 43242 43243 * Rainer Orth for random MIPS work, including improvements to GCC's 43244 o32 ABI support, improvements to dejagnu's MIPS support, Java 43245 configuration clean-ups and porting work, and maintaining the IRIX, 43246 Solaris 2, and Tru64 UNIX ports. 43247 43248 * Hartmut Penner for work on the s390 port. 43249 43250 * Paul Petersen wrote the machine description for the Alliant FX/8. 43251 43252 * Alexandre Petit-Bianco for implementing much of the Java compiler 43253 and continued Java maintainership. 43254 43255 * Matthias Pfaller for major improvements to the NS32k port. 43256 43257 * Gerald Pfeifer for his direction via the steering committee, 43258 pointing out lots of problems we need to solve, maintenance of the 43259 web pages, and taking care of documentation maintenance in general. 43260 43261 * Andrew Pinski for processing bug reports by the dozen. 43262 43263 * Ovidiu Predescu for his work on the Objective-C front end and 43264 runtime libraries. 43265 43266 * Jerry Quinn for major performance improvements in C++ formatted 43267 I/O. 43268 43269 * Ken Raeburn for various improvements to checker, MIPS ports and 43270 various cleanups in the compiler. 43271 43272 * Rolf W. Rasmussen for hacking on AWT. 43273 43274 * David Reese of Sun Microsystems contributed to the Solaris on 43275 PowerPC port. 43276 43277 * Volker Reichelt for keeping up with the problem reports. 43278 43279 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 43280 hacking and developing and maintaining the Epiphany port. 43281 43282 * Loren J. Rittle for improvements to libstdc++-v3 including the 43283 FreeBSD port, threading fixes, thread-related configury changes, 43284 critical threading documentation, and solutions to really tricky 43285 I/O problems, as well as keeping GCC properly working on FreeBSD 43286 and continuous testing. 43287 43288 * Craig Rodrigues for processing tons of bug reports. 43289 43290 * Ola Ro"nnerup for work on mt_alloc. 43291 43292 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 43293 43294 * David Ronis inspired and encouraged Craig to rewrite the G77 43295 documentation in texinfo format by contributing a first pass at a 43296 translation of the old 'g77-0.5.16/f/DOC' file. 43297 43298 * Ken Rose for fixes to GCC's delay slot filling code. 43299 43300 * Ira Rosen for her contributions to the auto-vectorizer. 43301 43302 * Paul Rubin wrote most of the preprocessor. 43303 43304 * Pe'tur Runo'lfsson for major performance improvements in C++ 43305 formatted I/O and large file support in C++ filebuf. 43306 43307 * Chip Salzenberg for libstdc++ patches and improvements to locales, 43308 traits, Makefiles, libio, libtool hackery, and "long long" support. 43309 43310 * Juha Sarlin for improvements to the H8 code generator. 43311 43312 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 43313 300. 43314 43315 * Roger Sayle for improvements to constant folding and GCC's RTL 43316 optimizers as well as for fixing numerous bugs. 43317 43318 * Bradley Schatz for his work on the GCJ FAQ. 43319 43320 * Peter Schauer wrote the code to allow debugging to work on the 43321 Alpha. 43322 43323 * William Schelter did most of the work on the Intel 80386 support. 43324 43325 * Tobias Schlu"ter for work on GNU Fortran. 43326 43327 * Bernd Schmidt for various code generation improvements and major 43328 work in the reload pass, serving as release manager for GCC 2.95.3, 43329 and work on the Blackfin and C6X ports. 43330 43331 * Peter Schmid for constant testing of libstdc++--especially 43332 application testing, going above and beyond what was requested for 43333 the release criteria--and libstdc++ header file tweaks. 43334 43335 * Jason Schroeder for jcf-dump patches. 43336 43337 * Andreas Schwab for his work on the m68k port. 43338 43339 * Lars Segerlund for work on GNU Fortran. 43340 43341 * Dodji Seketeli for numerous C++ bug fixes and debug info 43342 improvements. 43343 43344 * Tim Shen for major work on '<regex>'. 43345 43346 * Joel Sherrill for his direction via the steering committee, RTEMS 43347 contributions and RTEMS testing. 43348 43349 * Nathan Sidwell for many C++ fixes/improvements. 43350 43351 * Jeffrey Siegal for helping RMS with the original design of GCC, 43352 some code which handles the parse tree and RTL data structures, 43353 constant folding and help with the original VAX & m68k ports. 43354 43355 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 43356 from the LWG (thereby keeping GCC in line with updates from the 43357 ISO). 43358 43359 * Franz Sirl for his ongoing work with making the PPC port stable for 43360 GNU/Linux. 43361 43362 * Andrey Slepuhin for assorted AIX hacking. 43363 43364 * Trevor Smigiel for contributing the SPU port. 43365 43366 * Christopher Smith did the port for Convex machines. 43367 43368 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 43369 Retired from GCC maintainership August 2010, having mentored two 43370 new maintainers into the role. 43371 43372 * Randy Smith finished the Sun FPA support. 43373 43374 * Ed Smith-Rowland for his continuous work on libstdc++-v3, special 43375 functions, '<random>', and various improvements to C++11 features. 43376 43377 * Scott Snyder for queue, iterator, istream, and string fixes and 43378 libstdc++ testsuite entries. Also for providing the patch to G77 43379 to add rudimentary support for 'INTEGER*1', 'INTEGER*2', and 43380 'LOGICAL*1'. 43381 43382 * Zdenek Sojka for running automated regression testing of GCC and 43383 reporting numerous bugs. 43384 43385 * Jayant Sonar for contributing the CR16 port. 43386 43387 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 43388 43389 * Richard Stallman, for writing the original GCC and launching the 43390 GNU project. 43391 43392 * Jan Stein of the Chalmers Computer Society provided support for 43393 Genix, as well as part of the 32000 machine description. 43394 43395 * Nigel Stephens for various mips16 related fixes/improvements. 43396 43397 * Jonathan Stone wrote the machine description for the Pyramid 43398 computer. 43399 43400 * Graham Stott for various infrastructure improvements. 43401 43402 * John Stracke for his Java HTTP protocol fixes. 43403 43404 * Mike Stump for his Elxsi port, G++ contributions over the years and 43405 more recently his vxworks contributions 43406 43407 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 43408 43409 * Shigeya Suzuki for this fixes for the bsdi platforms. 43410 43411 * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64 43412 support, general configury hacking, fixincludes, etc. 43413 43414 * Holger Teutsch provided the support for the Clipper CPU. 43415 43416 * Gary Thomas for his ongoing work to make the PPC work for 43417 GNU/Linux. 43418 43419 * Philipp Thomas for random bug fixes throughout the compiler 43420 43421 * Jason Thorpe for thread support in libstdc++ on NetBSD. 43422 43423 * Kresten Krab Thorup wrote the run time support for the Objective-C 43424 language and the fantastic Java bytecode interpreter. 43425 43426 * Michael Tiemann for random bug fixes, the first instruction 43427 scheduler, initial C++ support, function integration, NS32k, SPARC 43428 and M88k machine description work, delay slot scheduling. 43429 43430 * Andreas Tobler for his work porting libgcj to Darwin. 43431 43432 * Teemu Torma for thread safe exception handling support. 43433 43434 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 43435 definitions, and of the VAX machine description. 43436 43437 * Daniel Towner and Hariharan Sandanagobalane contributed and 43438 maintain the picoChip port. 43439 43440 * Tom Tromey for internationalization support and for his many Java 43441 contributions and libgcj maintainership. 43442 43443 * Lassi Tuura for improvements to config.guess to determine HP 43444 processor types. 43445 43446 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 43447 43448 * Andy Vaught for the design and initial implementation of the GNU 43449 Fortran front end. 43450 43451 * Brent Verner for work with the libstdc++ cshadow files and their 43452 associated configure steps. 43453 43454 * Todd Vierling for contributions for NetBSD ports. 43455 43456 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 43457 guidance. 43458 43459 * Dean Wakerley for converting the install documentation from HTML to 43460 texinfo in time for GCC 3.0. 43461 43462 * Krister Walfridsson for random bug fixes. 43463 43464 * Feng Wang for contributions to GNU Fortran. 43465 43466 * Stephen M. Webb for time and effort on making libstdc++ shadow 43467 files work with the tricky Solaris 8+ headers, and for pushing the 43468 build-time header tree. Also, for starting and driving the 43469 '<regex>' effort. 43470 43471 * John Wehle for various improvements for the x86 code generator, 43472 related infrastructure improvements to help x86 code generation, 43473 value range propagation and other work, WE32k port. 43474 43475 * Ulrich Weigand for work on the s390 port. 43476 43477 * Zack Weinberg for major work on cpplib and various other bug fixes. 43478 43479 * Matt Welsh for help with Linux Threads support in GCJ. 43480 43481 * Urban Widmark for help fixing java.io. 43482 43483 * Mark Wielaard for new Java library code and his work integrating 43484 with Classpath. 43485 43486 * Dale Wiles helped port GCC to the Tahoe. 43487 43488 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 43489 43490 * Jim Wilson for his direction via the steering committee, tackling 43491 hard problems in various places that nobody else wanted to work on, 43492 strength reduction and other loop optimizations. 43493 43494 * Paul Woegerer and Tal Agmon for the CRX port. 43495 43496 * Carlo Wood for various fixes. 43497 43498 * Tom Wood for work on the m88k port. 43499 43500 * Chung-Ju Wu for his work on the Andes NDS32 port. 43501 43502 * Canqun Yang for work on GNU Fortran. 43503 43504 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 43505 description for the Tron architecture (specifically, the Gmicro). 43506 43507 * Kevin Zachmann helped port GCC to the Tahoe. 43508 43509 * Ayal Zaks for Swing Modulo Scheduling (SMS). 43510 43511 * Xiaoqiang Zhang for work on GNU Fortran. 43512 43513 * Gilles Zunino for help porting Java to Irix. 43514 43515 The following people are recognized for their contributions to GNAT, 43516the Ada front end of GCC: 43517 * Bernard Banner 43518 43519 * Romain Berrendonner 43520 43521 * Geert Bosch 43522 43523 * Emmanuel Briot 43524 43525 * Joel Brobecker 43526 43527 * Ben Brosgol 43528 43529 * Vincent Celier 43530 43531 * Arnaud Charlet 43532 43533 * Chien Chieng 43534 43535 * Cyrille Comar 43536 43537 * Cyrille Crozes 43538 43539 * Robert Dewar 43540 43541 * Gary Dismukes 43542 43543 * Robert Duff 43544 43545 * Ed Falis 43546 43547 * Ramon Fernandez 43548 43549 * Sam Figueroa 43550 43551 * Vasiliy Fofanov 43552 43553 * Michael Friess 43554 43555 * Franco Gasperoni 43556 43557 * Ted Giering 43558 43559 * Matthew Gingell 43560 43561 * Laurent Guerby 43562 43563 * Jerome Guitton 43564 43565 * Olivier Hainque 43566 43567 * Jerome Hugues 43568 43569 * Hristian Kirtchev 43570 43571 * Jerome Lambourg 43572 43573 * Bruno Leclerc 43574 43575 * Albert Lee 43576 43577 * Sean McNeil 43578 43579 * Javier Miranda 43580 43581 * Laurent Nana 43582 43583 * Pascal Obry 43584 43585 * Dong-Ik Oh 43586 43587 * Laurent Pautet 43588 43589 * Brett Porter 43590 43591 * Thomas Quinot 43592 43593 * Nicolas Roche 43594 43595 * Pat Rogers 43596 43597 * Jose Ruiz 43598 43599 * Douglas Rupp 43600 43601 * Sergey Rybin 43602 43603 * Gail Schenker 43604 43605 * Ed Schonberg 43606 43607 * Nicolas Setton 43608 43609 * Samuel Tardieu 43610 43611 The following people are recognized for their contributions of new 43612features, bug reports, testing and integration of classpath/libgcj for 43613GCC version 4.1: 43614 * Lillian Angel for 'JTree' implementation and lots Free Swing 43615 additions and bug fixes. 43616 43617 * Wolfgang Baer for 'GapContent' bug fixes. 43618 43619 * Anthony Balkissoon for 'JList', Free Swing 1.5 updates and mouse 43620 event fixes, lots of Free Swing work including 'JTable' editing. 43621 43622 * Stuart Ballard for RMI constant fixes. 43623 43624 * Goffredo Baroncelli for 'HTTPURLConnection' fixes. 43625 43626 * Gary Benson for 'MessageFormat' fixes. 43627 43628 * Daniel Bonniot for 'Serialization' fixes. 43629 43630 * Chris Burdess for lots of gnu.xml and http protocol fixes, 'StAX' 43631 and 'DOM xml:id' support. 43632 43633 * Ka-Hing Cheung for 'TreePath' and 'TreeSelection' fixes. 43634 43635 * Archie Cobbs for build fixes, VM interface updates, 43636 'URLClassLoader' updates. 43637 43638 * Kelley Cook for build fixes. 43639 43640 * Martin Cordova for Suggestions for better 'SocketTimeoutException'. 43641 43642 * David Daney for 'BitSet' bug fixes, 'HttpURLConnection' rewrite and 43643 improvements. 43644 43645 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 43646 2D support. Lots of imageio framework additions, lots of AWT and 43647 Free Swing bug fixes. 43648 43649 * Jeroen Frijters for 'ClassLoader' and nio cleanups, serialization 43650 fixes, better 'Proxy' support, bug fixes and IKVM integration. 43651 43652 * Santiago Gala for 'AccessControlContext' fixes. 43653 43654 * Nicolas Geoffray for 'VMClassLoader' and 'AccessController' 43655 improvements. 43656 43657 * David Gilbert for 'basic' and 'metal' icon and plaf support and 43658 lots of documenting, Lots of Free Swing and metal theme additions. 43659 'MetalIconFactory' implementation. 43660 43661 * Anthony Green for 'MIDI' framework, 'ALSA' and 'DSSI' providers. 43662 43663 * Andrew Haley for 'Serialization' and 'URLClassLoader' fixes, gcj 43664 build speedups. 43665 43666 * Kim Ho for 'JFileChooser' implementation. 43667 43668 * Andrew John Hughes for 'Locale' and net fixes, URI RFC2986 updates, 43669 'Serialization' fixes, 'Properties' XML support and generic branch 43670 work, VMIntegration guide update. 43671 43672 * Bastiaan Huisman for 'TimeZone' bug fixing. 43673 43674 * Andreas Jaeger for mprec updates. 43675 43676 * Paul Jenner for better '-Werror' support. 43677 43678 * Ito Kazumitsu for 'NetworkInterface' implementation and updates. 43679 43680 * Roman Kennke for 'BoxLayout', 'GrayFilter' and 'SplitPane', plus 43681 bug fixes all over. Lots of Free Swing work including styled text. 43682 43683 * Simon Kitching for 'String' cleanups and optimization suggestions. 43684 43685 * Michael Koch for configuration fixes, 'Locale' updates, bug and 43686 build fixes. 43687 43688 * Guilhem Lavaux for configuration, thread and channel fixes and 43689 Kaffe integration. JCL native 'Pointer' updates. Logger bug 43690 fixes. 43691 43692 * David Lichteblau for JCL support library global/local reference 43693 cleanups. 43694 43695 * Aaron Luchko for JDWP updates and documentation fixes. 43696 43697 * Ziga Mahkovec for 'Graphics2D' upgraded to Cairo 0.5 and new regex 43698 features. 43699 43700 * Sven de Marothy for BMP imageio support, CSS and 'TextLayout' 43701 fixes. 'GtkImage' rewrite, 2D, awt, free swing and date/time fixes 43702 and implementing the Qt4 peers. 43703 43704 * Casey Marshall for crypto algorithm fixes, 'FileChannel' lock, 43705 'SystemLogger' and 'FileHandler' rotate implementations, NIO 43706 'FileChannel.map' support, security and policy updates. 43707 43708 * Bryce McKinlay for RMI work. 43709 43710 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 43711 testing and documenting. 43712 43713 * Kalle Olavi Niemitalo for build fixes. 43714 43715 * Rainer Orth for build fixes. 43716 43717 * Andrew Overholt for 'File' locking fixes. 43718 43719 * Ingo Proetel for 'Image', 'Logger' and 'URLClassLoader' updates. 43720 43721 * Olga Rodimina for 'MenuSelectionManager' implementation. 43722 43723 * Jan Roehrich for 'BasicTreeUI' and 'JTree' fixes. 43724 43725 * Julian Scheid for documentation updates and gjdoc support. 43726 43727 * Christian Schlichtherle for zip fixes and cleanups. 43728 43729 * Robert Schuster for documentation updates and beans fixes, 43730 'TreeNode' enumerations and 'ActionCommand' and various fixes, XML 43731 and URL, AWT and Free Swing bug fixes. 43732 43733 * Keith Seitz for lots of JDWP work. 43734 43735 * Christian Thalinger for 64-bit cleanups, Configuration and VM 43736 interface fixes and 'CACAO' integration, 'fdlibm' updates. 43737 43738 * Gael Thomas for 'VMClassLoader' boot packages support suggestions. 43739 43740 * Andreas Tobler for Darwin and Solaris testing and fixing, 'Qt4' 43741 support for Darwin/OS X, 'Graphics2D' support, 'gtk+' updates. 43742 43743 * Dalibor Topic for better 'DEBUG' support, build cleanups and Kaffe 43744 integration. 'Qt4' build infrastructure, 'SHA1PRNG' and 43745 'GdkPixbugDecoder' updates. 43746 43747 * Tom Tromey for Eclipse integration, generics work, lots of bug 43748 fixes and gcj integration including coordinating The Big Merge. 43749 43750 * Mark Wielaard for bug fixes, packaging and release management, 43751 'Clipboard' implementation, system call interrupts and network 43752 timeouts and 'GdkPixpufDecoder' fixes. 43753 43754 In addition to the above, all of which also contributed time and energy 43755in testing GCC, we would like to thank the following for their 43756contributions to testing: 43757 43758 * Michael Abd-El-Malek 43759 43760 * Thomas Arend 43761 43762 * Bonzo Armstrong 43763 43764 * Steven Ashe 43765 43766 * Chris Baldwin 43767 43768 * David Billinghurst 43769 43770 * Jim Blandy 43771 43772 * Stephane Bortzmeyer 43773 43774 * Horst von Brand 43775 43776 * Frank Braun 43777 43778 * Rodney Brown 43779 43780 * Sidney Cadot 43781 43782 * Bradford Castalia 43783 43784 * Robert Clark 43785 43786 * Jonathan Corbet 43787 43788 * Ralph Doncaster 43789 43790 * Richard Emberson 43791 43792 * Levente Farkas 43793 43794 * Graham Fawcett 43795 43796 * Mark Fernyhough 43797 43798 * Robert A. French 43799 43800 * Jo"rgen Freyh 43801 43802 * Mark K. Gardner 43803 43804 * Charles-Antoine Gauthier 43805 43806 * Yung Shing Gene 43807 43808 * David Gilbert 43809 43810 * Simon Gornall 43811 43812 * Fred Gray 43813 43814 * John Griffin 43815 43816 * Patrik Hagglund 43817 43818 * Phil Hargett 43819 43820 * Amancio Hasty 43821 43822 * Takafumi Hayashi 43823 43824 * Bryan W. Headley 43825 43826 * Kevin B. Hendricks 43827 43828 * Joep Jansen 43829 43830 * Christian Joensson 43831 43832 * Michel Kern 43833 43834 * David Kidd 43835 43836 * Tobias Kuipers 43837 43838 * Anand Krishnaswamy 43839 43840 * A. O. V. Le Blanc 43841 43842 * llewelly 43843 43844 * Damon Love 43845 43846 * Brad Lucier 43847 43848 * Matthias Klose 43849 43850 * Martin Knoblauch 43851 43852 * Rick Lutowski 43853 43854 * Jesse Macnish 43855 43856 * Stefan Morrell 43857 43858 * Anon A. Mous 43859 43860 * Matthias Mueller 43861 43862 * Pekka Nikander 43863 43864 * Rick Niles 43865 43866 * Jon Olson 43867 43868 * Magnus Persson 43869 43870 * Chris Pollard 43871 43872 * Richard Polton 43873 43874 * Derk Reefman 43875 43876 * David Rees 43877 43878 * Paul Reilly 43879 43880 * Tom Reilly 43881 43882 * Torsten Rueger 43883 43884 * Danny Sadinoff 43885 43886 * Marc Schifer 43887 43888 * Erik Schnetter 43889 43890 * Wayne K. Schroll 43891 43892 * David Schuler 43893 43894 * Vin Shelton 43895 43896 * Tim Souder 43897 43898 * Adam Sulmicki 43899 43900 * Bill Thorson 43901 43902 * George Talbot 43903 43904 * Pedro A. M. Vazquez 43905 43906 * Gregory Warnes 43907 43908 * Ian Watson 43909 43910 * David E. Young 43911 43912 * And many others 43913 43914 And finally we'd like to thank everyone who uses the compiler, provides 43915feedback and generally reminds us why we're doing this work in the first 43916place. 43917 43918 43919File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 43920 43921Option Index 43922************ 43923 43924GCC's command line options are indexed here without any initial '-' or 43925'--'. Where an option has both positive and negative forms (such as 43926'-fOPTION' and '-fno-OPTION'), relevant entries in the manual are 43927indexed under the most appropriate form; it may sometimes be useful to 43928look up both forms. 43929 43930�[index�] 43931* Menu: 43932 43933* fltrans: Internal flags. (line 18) 43934* fltrans-output-list: Internal flags. (line 23) 43935* fresolution: Internal flags. (line 27) 43936* fwpa: Internal flags. (line 9) 43937* msoft-float: Soft float library routines. 43938 (line 6) 43939 43940 43941File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 43942 43943Concept Index 43944************* 43945 43946�[index�] 43947* Menu: 43948 43949* ! in constraint: Multi-Alternative. (line 48) 43950* # in constraint: Modifiers. (line 78) 43951* # in template: Output Template. (line 66) 43952* #pragma: Misc. (line 387) 43953* $ in constraint: Multi-Alternative. (line 57) 43954* % in constraint: Modifiers. (line 52) 43955* % in GTY option: GTY Options. (line 18) 43956* % in template: Output Template. (line 6) 43957* & in constraint: Modifiers. (line 25) 43958* (gimple_stmt_iterator: GIMPLE API. (line 30) 43959* (nil): RTL Objects. (line 73) 43960* * in constraint: Modifiers. (line 83) 43961* * in template: Output Statement. (line 29) 43962* *gimple_build_asm_vec: GIMPLE_ASM. (line 6) 43963* *gimple_build_assign: GIMPLE_ASSIGN. (line 6) 43964* *gimple_build_assign <1>: GIMPLE_ASSIGN. (line 18) 43965* *gimple_build_assign <2>: GIMPLE_ASSIGN. (line 29) 43966* *gimple_build_assign <3>: GIMPLE_ASSIGN. (line 35) 43967* *gimple_build_bind: GIMPLE_BIND. (line 6) 43968* *gimple_build_call: GIMPLE_CALL. (line 6) 43969* *gimple_build_call_from_tree: GIMPLE_CALL. (line 15) 43970* *gimple_build_call_vec: GIMPLE_CALL. (line 23) 43971* *gimple_build_catch: GIMPLE_CATCH. (line 6) 43972* *gimple_build_cond: GIMPLE_COND. (line 6) 43973* *gimple_build_cond_from_tree: GIMPLE_COND. (line 14) 43974* *gimple_build_debug_bind: GIMPLE_DEBUG. (line 6) 43975* *gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 6) 43976* *gimple_build_goto: GIMPLE_GOTO. (line 6) 43977* *gimple_build_label: GIMPLE_LABEL. (line 6) 43978* *gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD. 43979 (line 6) 43980* *gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE. 43981 (line 6) 43982* *gimple_build_omp_continue: GIMPLE_OMP_CONTINUE. 43983 (line 6) 43984* *gimple_build_omp_critical: GIMPLE_OMP_CRITICAL. 43985 (line 6) 43986* *gimple_build_omp_for: GIMPLE_OMP_FOR. (line 6) 43987* *gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL. 43988 (line 6) 43989* *gimple_build_omp_sections: GIMPLE_OMP_SECTIONS. 43990 (line 6) 43991* *gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 6) 43992* *gimple_build_resx: GIMPLE_RESX. (line 6) 43993* *gimple_build_return: GIMPLE_RETURN. (line 6) 43994* *gimple_build_switch: GIMPLE_SWITCH. (line 6) 43995* *gimple_build_try: GIMPLE_TRY. (line 6) 43996* + in constraint: Modifiers. (line 12) 43997* -fsection-anchors: Special Accessors. (line 117) 43998* -fsection-anchors <1>: Anchored Addresses. (line 6) 43999* /c in RTL dump: Flags. (line 221) 44000* /f in RTL dump: Flags. (line 229) 44001* /i in RTL dump: Flags. (line 274) 44002* /j in RTL dump: Flags. (line 286) 44003* /s in RTL dump: Flags. (line 245) 44004* /u in RTL dump: Flags. (line 296) 44005* /v in RTL dump: Flags. (line 328) 44006* 0 in constraint: Simple Constraints. (line 128) 44007* < in constraint: Simple Constraints. (line 47) 44008* = in constraint: Modifiers. (line 8) 44009* > in constraint: Simple Constraints. (line 59) 44010* ? in constraint: Multi-Alternative. (line 42) 44011* \: Output Template. (line 46) 44012* ^ in constraint: Multi-Alternative. (line 53) 44013* __absvdi2: Integer library routines. 44014 (line 106) 44015* __absvsi2: Integer library routines. 44016 (line 105) 44017* __addda3: Fixed-point fractional library routines. 44018 (line 52) 44019* __adddf3: Soft float library routines. 44020 (line 22) 44021* __adddq3: Fixed-point fractional library routines. 44022 (line 39) 44023* __addha3: Fixed-point fractional library routines. 44024 (line 49) 44025* __addhq3: Fixed-point fractional library routines. 44026 (line 37) 44027* __addqq3: Fixed-point fractional library routines. 44028 (line 35) 44029* __addsa3: Fixed-point fractional library routines. 44030 (line 51) 44031* __addsf3: Soft float library routines. 44032 (line 21) 44033* __addsq3: Fixed-point fractional library routines. 44034 (line 38) 44035* __addta3: Fixed-point fractional library routines. 44036 (line 53) 44037* __addtf3: Soft float library routines. 44038 (line 23) 44039* __adduda3: Fixed-point fractional library routines. 44040 (line 59) 44041* __addudq3: Fixed-point fractional library routines. 44042 (line 47) 44043* __adduha3: Fixed-point fractional library routines. 44044 (line 55) 44045* __adduhq3: Fixed-point fractional library routines. 44046 (line 43) 44047* __adduqq3: Fixed-point fractional library routines. 44048 (line 41) 44049* __addusa3: Fixed-point fractional library routines. 44050 (line 57) 44051* __addusq3: Fixed-point fractional library routines. 44052 (line 45) 44053* __adduta3: Fixed-point fractional library routines. 44054 (line 61) 44055* __addvdi3: Integer library routines. 44056 (line 110) 44057* __addvsi3: Integer library routines. 44058 (line 109) 44059* __addxf3: Soft float library routines. 44060 (line 25) 44061* __ashlda3: Fixed-point fractional library routines. 44062 (line 358) 44063* __ashldi3: Integer library routines. 44064 (line 13) 44065* __ashldq3: Fixed-point fractional library routines. 44066 (line 346) 44067* __ashlha3: Fixed-point fractional library routines. 44068 (line 356) 44069* __ashlhq3: Fixed-point fractional library routines. 44070 (line 344) 44071* __ashlqq3: Fixed-point fractional library routines. 44072 (line 343) 44073* __ashlsa3: Fixed-point fractional library routines. 44074 (line 357) 44075* __ashlsi3: Integer library routines. 44076 (line 12) 44077* __ashlsq3: Fixed-point fractional library routines. 44078 (line 345) 44079* __ashlta3: Fixed-point fractional library routines. 44080 (line 359) 44081* __ashlti3: Integer library routines. 44082 (line 14) 44083* __ashluda3: Fixed-point fractional library routines. 44084 (line 365) 44085* __ashludq3: Fixed-point fractional library routines. 44086 (line 354) 44087* __ashluha3: Fixed-point fractional library routines. 44088 (line 361) 44089* __ashluhq3: Fixed-point fractional library routines. 44090 (line 350) 44091* __ashluqq3: Fixed-point fractional library routines. 44092 (line 348) 44093* __ashlusa3: Fixed-point fractional library routines. 44094 (line 363) 44095* __ashlusq3: Fixed-point fractional library routines. 44096 (line 352) 44097* __ashluta3: Fixed-point fractional library routines. 44098 (line 367) 44099* __ashrda3: Fixed-point fractional library routines. 44100 (line 378) 44101* __ashrdi3: Integer library routines. 44102 (line 18) 44103* __ashrdq3: Fixed-point fractional library routines. 44104 (line 374) 44105* __ashrha3: Fixed-point fractional library routines. 44106 (line 376) 44107* __ashrhq3: Fixed-point fractional library routines. 44108 (line 372) 44109* __ashrqq3: Fixed-point fractional library routines. 44110 (line 371) 44111* __ashrsa3: Fixed-point fractional library routines. 44112 (line 377) 44113* __ashrsi3: Integer library routines. 44114 (line 17) 44115* __ashrsq3: Fixed-point fractional library routines. 44116 (line 373) 44117* __ashrta3: Fixed-point fractional library routines. 44118 (line 379) 44119* __ashrti3: Integer library routines. 44120 (line 19) 44121* __bid_adddd3: Decimal float library routines. 44122 (line 23) 44123* __bid_addsd3: Decimal float library routines. 44124 (line 19) 44125* __bid_addtd3: Decimal float library routines. 44126 (line 27) 44127* __bid_divdd3: Decimal float library routines. 44128 (line 66) 44129* __bid_divsd3: Decimal float library routines. 44130 (line 62) 44131* __bid_divtd3: Decimal float library routines. 44132 (line 70) 44133* __bid_eqdd2: Decimal float library routines. 44134 (line 258) 44135* __bid_eqsd2: Decimal float library routines. 44136 (line 256) 44137* __bid_eqtd2: Decimal float library routines. 44138 (line 260) 44139* __bid_extendddtd2: Decimal float library routines. 44140 (line 91) 44141* __bid_extendddtf: Decimal float library routines. 44142 (line 139) 44143* __bid_extendddxf: Decimal float library routines. 44144 (line 133) 44145* __bid_extenddfdd: Decimal float library routines. 44146 (line 146) 44147* __bid_extenddftd: Decimal float library routines. 44148 (line 106) 44149* __bid_extendsddd2: Decimal float library routines. 44150 (line 87) 44151* __bid_extendsddf: Decimal float library routines. 44152 (line 127) 44153* __bid_extendsdtd2: Decimal float library routines. 44154 (line 89) 44155* __bid_extendsdtf: Decimal float library routines. 44156 (line 137) 44157* __bid_extendsdxf: Decimal float library routines. 44158 (line 131) 44159* __bid_extendsfdd: Decimal float library routines. 44160 (line 102) 44161* __bid_extendsfsd: Decimal float library routines. 44162 (line 144) 44163* __bid_extendsftd: Decimal float library routines. 44164 (line 104) 44165* __bid_extendtftd: Decimal float library routines. 44166 (line 148) 44167* __bid_extendxftd: Decimal float library routines. 44168 (line 108) 44169* __bid_fixdddi: Decimal float library routines. 44170 (line 169) 44171* __bid_fixddsi: Decimal float library routines. 44172 (line 161) 44173* __bid_fixsddi: Decimal float library routines. 44174 (line 167) 44175* __bid_fixsdsi: Decimal float library routines. 44176 (line 159) 44177* __bid_fixtddi: Decimal float library routines. 44178 (line 171) 44179* __bid_fixtdsi: Decimal float library routines. 44180 (line 163) 44181* __bid_fixunsdddi: Decimal float library routines. 44182 (line 186) 44183* __bid_fixunsddsi: Decimal float library routines. 44184 (line 177) 44185* __bid_fixunssddi: Decimal float library routines. 44186 (line 184) 44187* __bid_fixunssdsi: Decimal float library routines. 44188 (line 175) 44189* __bid_fixunstddi: Decimal float library routines. 44190 (line 188) 44191* __bid_fixunstdsi: Decimal float library routines. 44192 (line 179) 44193* __bid_floatdidd: Decimal float library routines. 44194 (line 204) 44195* __bid_floatdisd: Decimal float library routines. 44196 (line 202) 44197* __bid_floatditd: Decimal float library routines. 44198 (line 206) 44199* __bid_floatsidd: Decimal float library routines. 44200 (line 195) 44201* __bid_floatsisd: Decimal float library routines. 44202 (line 193) 44203* __bid_floatsitd: Decimal float library routines. 44204 (line 197) 44205* __bid_floatunsdidd: Decimal float library routines. 44206 (line 222) 44207* __bid_floatunsdisd: Decimal float library routines. 44208 (line 220) 44209* __bid_floatunsditd: Decimal float library routines. 44210 (line 224) 44211* __bid_floatunssidd: Decimal float library routines. 44212 (line 213) 44213* __bid_floatunssisd: Decimal float library routines. 44214 (line 211) 44215* __bid_floatunssitd: Decimal float library routines. 44216 (line 215) 44217* __bid_gedd2: Decimal float library routines. 44218 (line 276) 44219* __bid_gesd2: Decimal float library routines. 44220 (line 274) 44221* __bid_getd2: Decimal float library routines. 44222 (line 278) 44223* __bid_gtdd2: Decimal float library routines. 44224 (line 303) 44225* __bid_gtsd2: Decimal float library routines. 44226 (line 301) 44227* __bid_gttd2: Decimal float library routines. 44228 (line 305) 44229* __bid_ledd2: Decimal float library routines. 44230 (line 294) 44231* __bid_lesd2: Decimal float library routines. 44232 (line 292) 44233* __bid_letd2: Decimal float library routines. 44234 (line 296) 44235* __bid_ltdd2: Decimal float library routines. 44236 (line 285) 44237* __bid_ltsd2: Decimal float library routines. 44238 (line 283) 44239* __bid_lttd2: Decimal float library routines. 44240 (line 287) 44241* __bid_muldd3: Decimal float library routines. 44242 (line 52) 44243* __bid_mulsd3: Decimal float library routines. 44244 (line 48) 44245* __bid_multd3: Decimal float library routines. 44246 (line 56) 44247* __bid_nedd2: Decimal float library routines. 44248 (line 267) 44249* __bid_negdd2: Decimal float library routines. 44250 (line 77) 44251* __bid_negsd2: Decimal float library routines. 44252 (line 75) 44253* __bid_negtd2: Decimal float library routines. 44254 (line 79) 44255* __bid_nesd2: Decimal float library routines. 44256 (line 265) 44257* __bid_netd2: Decimal float library routines. 44258 (line 269) 44259* __bid_subdd3: Decimal float library routines. 44260 (line 37) 44261* __bid_subsd3: Decimal float library routines. 44262 (line 33) 44263* __bid_subtd3: Decimal float library routines. 44264 (line 41) 44265* __bid_truncdddf: Decimal float library routines. 44266 (line 152) 44267* __bid_truncddsd2: Decimal float library routines. 44268 (line 93) 44269* __bid_truncddsf: Decimal float library routines. 44270 (line 123) 44271* __bid_truncdfsd: Decimal float library routines. 44272 (line 110) 44273* __bid_truncsdsf: Decimal float library routines. 44274 (line 150) 44275* __bid_trunctddd2: Decimal float library routines. 44276 (line 97) 44277* __bid_trunctddf: Decimal float library routines. 44278 (line 129) 44279* __bid_trunctdsd2: Decimal float library routines. 44280 (line 95) 44281* __bid_trunctdsf: Decimal float library routines. 44282 (line 125) 44283* __bid_trunctdtf: Decimal float library routines. 44284 (line 154) 44285* __bid_trunctdxf: Decimal float library routines. 44286 (line 135) 44287* __bid_trunctfdd: Decimal float library routines. 44288 (line 118) 44289* __bid_trunctfsd: Decimal float library routines. 44290 (line 114) 44291* __bid_truncxfdd: Decimal float library routines. 44292 (line 116) 44293* __bid_truncxfsd: Decimal float library routines. 44294 (line 112) 44295* __bid_unorddd2: Decimal float library routines. 44296 (line 234) 44297* __bid_unordsd2: Decimal float library routines. 44298 (line 232) 44299* __bid_unordtd2: Decimal float library routines. 44300 (line 236) 44301* __bswapdi2: Integer library routines. 44302 (line 161) 44303* __bswapsi2: Integer library routines. 44304 (line 160) 44305* __builtin_classify_type: Varargs. (line 48) 44306* __builtin_next_arg: Varargs. (line 39) 44307* __builtin_saveregs: Varargs. (line 22) 44308* __chkp_bndcl: Misc. (line 650) 44309* __chkp_bndcu: Misc. (line 656) 44310* __chkp_bndldx: Misc. (line 644) 44311* __chkp_bndmk: Misc. (line 631) 44312* __chkp_bndret: Misc. (line 662) 44313* __chkp_bndstx: Misc. (line 638) 44314* __chkp_intersect: Misc. (line 668) 44315* __chkp_narrow: Misc. (line 673) 44316* __chkp_sizeof: Misc. (line 679) 44317* __clear_cache: Miscellaneous routines. 44318 (line 9) 44319* __clzdi2: Integer library routines. 44320 (line 130) 44321* __clzsi2: Integer library routines. 44322 (line 129) 44323* __clzti2: Integer library routines. 44324 (line 131) 44325* __cmpda2: Fixed-point fractional library routines. 44326 (line 458) 44327* __cmpdf2: Soft float library routines. 44328 (line 163) 44329* __cmpdi2: Integer library routines. 44330 (line 86) 44331* __cmpdq2: Fixed-point fractional library routines. 44332 (line 447) 44333* __cmpha2: Fixed-point fractional library routines. 44334 (line 456) 44335* __cmphq2: Fixed-point fractional library routines. 44336 (line 445) 44337* __cmpqq2: Fixed-point fractional library routines. 44338 (line 444) 44339* __cmpsa2: Fixed-point fractional library routines. 44340 (line 457) 44341* __cmpsf2: Soft float library routines. 44342 (line 162) 44343* __cmpsq2: Fixed-point fractional library routines. 44344 (line 446) 44345* __cmpta2: Fixed-point fractional library routines. 44346 (line 459) 44347* __cmptf2: Soft float library routines. 44348 (line 164) 44349* __cmpti2: Integer library routines. 44350 (line 87) 44351* __cmpuda2: Fixed-point fractional library routines. 44352 (line 464) 44353* __cmpudq2: Fixed-point fractional library routines. 44354 (line 454) 44355* __cmpuha2: Fixed-point fractional library routines. 44356 (line 461) 44357* __cmpuhq2: Fixed-point fractional library routines. 44358 (line 451) 44359* __cmpuqq2: Fixed-point fractional library routines. 44360 (line 449) 44361* __cmpusa2: Fixed-point fractional library routines. 44362 (line 463) 44363* __cmpusq2: Fixed-point fractional library routines. 44364 (line 452) 44365* __cmputa2: Fixed-point fractional library routines. 44366 (line 466) 44367* __CTOR_LIST__: Initialization. (line 25) 44368* __ctzdi2: Integer library routines. 44369 (line 137) 44370* __ctzsi2: Integer library routines. 44371 (line 136) 44372* __ctzti2: Integer library routines. 44373 (line 138) 44374* __divda3: Fixed-point fractional library routines. 44375 (line 234) 44376* __divdc3: Soft float library routines. 44377 (line 250) 44378* __divdf3: Soft float library routines. 44379 (line 47) 44380* __divdi3: Integer library routines. 44381 (line 24) 44382* __divdq3: Fixed-point fractional library routines. 44383 (line 229) 44384* __divha3: Fixed-point fractional library routines. 44385 (line 231) 44386* __divhq3: Fixed-point fractional library routines. 44387 (line 227) 44388* __divqq3: Fixed-point fractional library routines. 44389 (line 225) 44390* __divsa3: Fixed-point fractional library routines. 44391 (line 233) 44392* __divsc3: Soft float library routines. 44393 (line 248) 44394* __divsf3: Soft float library routines. 44395 (line 46) 44396* __divsi3: Integer library routines. 44397 (line 23) 44398* __divsq3: Fixed-point fractional library routines. 44399 (line 228) 44400* __divta3: Fixed-point fractional library routines. 44401 (line 235) 44402* __divtc3: Soft float library routines. 44403 (line 252) 44404* __divtf3: Soft float library routines. 44405 (line 48) 44406* __divti3: Integer library routines. 44407 (line 25) 44408* __divxc3: Soft float library routines. 44409 (line 254) 44410* __divxf3: Soft float library routines. 44411 (line 50) 44412* __dpd_adddd3: Decimal float library routines. 44413 (line 21) 44414* __dpd_addsd3: Decimal float library routines. 44415 (line 17) 44416* __dpd_addtd3: Decimal float library routines. 44417 (line 25) 44418* __dpd_divdd3: Decimal float library routines. 44419 (line 64) 44420* __dpd_divsd3: Decimal float library routines. 44421 (line 60) 44422* __dpd_divtd3: Decimal float library routines. 44423 (line 68) 44424* __dpd_eqdd2: Decimal float library routines. 44425 (line 257) 44426* __dpd_eqsd2: Decimal float library routines. 44427 (line 255) 44428* __dpd_eqtd2: Decimal float library routines. 44429 (line 259) 44430* __dpd_extendddtd2: Decimal float library routines. 44431 (line 90) 44432* __dpd_extendddtf: Decimal float library routines. 44433 (line 138) 44434* __dpd_extendddxf: Decimal float library routines. 44435 (line 132) 44436* __dpd_extenddfdd: Decimal float library routines. 44437 (line 145) 44438* __dpd_extenddftd: Decimal float library routines. 44439 (line 105) 44440* __dpd_extendsddd2: Decimal float library routines. 44441 (line 86) 44442* __dpd_extendsddf: Decimal float library routines. 44443 (line 126) 44444* __dpd_extendsdtd2: Decimal float library routines. 44445 (line 88) 44446* __dpd_extendsdtf: Decimal float library routines. 44447 (line 136) 44448* __dpd_extendsdxf: Decimal float library routines. 44449 (line 130) 44450* __dpd_extendsfdd: Decimal float library routines. 44451 (line 101) 44452* __dpd_extendsfsd: Decimal float library routines. 44453 (line 143) 44454* __dpd_extendsftd: Decimal float library routines. 44455 (line 103) 44456* __dpd_extendtftd: Decimal float library routines. 44457 (line 147) 44458* __dpd_extendxftd: Decimal float library routines. 44459 (line 107) 44460* __dpd_fixdddi: Decimal float library routines. 44461 (line 168) 44462* __dpd_fixddsi: Decimal float library routines. 44463 (line 160) 44464* __dpd_fixsddi: Decimal float library routines. 44465 (line 166) 44466* __dpd_fixsdsi: Decimal float library routines. 44467 (line 158) 44468* __dpd_fixtddi: Decimal float library routines. 44469 (line 170) 44470* __dpd_fixtdsi: Decimal float library routines. 44471 (line 162) 44472* __dpd_fixunsdddi: Decimal float library routines. 44473 (line 185) 44474* __dpd_fixunsddsi: Decimal float library routines. 44475 (line 176) 44476* __dpd_fixunssddi: Decimal float library routines. 44477 (line 183) 44478* __dpd_fixunssdsi: Decimal float library routines. 44479 (line 174) 44480* __dpd_fixunstddi: Decimal float library routines. 44481 (line 187) 44482* __dpd_fixunstdsi: Decimal float library routines. 44483 (line 178) 44484* __dpd_floatdidd: Decimal float library routines. 44485 (line 203) 44486* __dpd_floatdisd: Decimal float library routines. 44487 (line 201) 44488* __dpd_floatditd: Decimal float library routines. 44489 (line 205) 44490* __dpd_floatsidd: Decimal float library routines. 44491 (line 194) 44492* __dpd_floatsisd: Decimal float library routines. 44493 (line 192) 44494* __dpd_floatsitd: Decimal float library routines. 44495 (line 196) 44496* __dpd_floatunsdidd: Decimal float library routines. 44497 (line 221) 44498* __dpd_floatunsdisd: Decimal float library routines. 44499 (line 219) 44500* __dpd_floatunsditd: Decimal float library routines. 44501 (line 223) 44502* __dpd_floatunssidd: Decimal float library routines. 44503 (line 212) 44504* __dpd_floatunssisd: Decimal float library routines. 44505 (line 210) 44506* __dpd_floatunssitd: Decimal float library routines. 44507 (line 214) 44508* __dpd_gedd2: Decimal float library routines. 44509 (line 275) 44510* __dpd_gesd2: Decimal float library routines. 44511 (line 273) 44512* __dpd_getd2: Decimal float library routines. 44513 (line 277) 44514* __dpd_gtdd2: Decimal float library routines. 44515 (line 302) 44516* __dpd_gtsd2: Decimal float library routines. 44517 (line 300) 44518* __dpd_gttd2: Decimal float library routines. 44519 (line 304) 44520* __dpd_ledd2: Decimal float library routines. 44521 (line 293) 44522* __dpd_lesd2: Decimal float library routines. 44523 (line 291) 44524* __dpd_letd2: Decimal float library routines. 44525 (line 295) 44526* __dpd_ltdd2: Decimal float library routines. 44527 (line 284) 44528* __dpd_ltsd2: Decimal float library routines. 44529 (line 282) 44530* __dpd_lttd2: Decimal float library routines. 44531 (line 286) 44532* __dpd_muldd3: Decimal float library routines. 44533 (line 50) 44534* __dpd_mulsd3: Decimal float library routines. 44535 (line 46) 44536* __dpd_multd3: Decimal float library routines. 44537 (line 54) 44538* __dpd_nedd2: Decimal float library routines. 44539 (line 266) 44540* __dpd_negdd2: Decimal float library routines. 44541 (line 76) 44542* __dpd_negsd2: Decimal float library routines. 44543 (line 74) 44544* __dpd_negtd2: Decimal float library routines. 44545 (line 78) 44546* __dpd_nesd2: Decimal float library routines. 44547 (line 264) 44548* __dpd_netd2: Decimal float library routines. 44549 (line 268) 44550* __dpd_subdd3: Decimal float library routines. 44551 (line 35) 44552* __dpd_subsd3: Decimal float library routines. 44553 (line 31) 44554* __dpd_subtd3: Decimal float library routines. 44555 (line 39) 44556* __dpd_truncdddf: Decimal float library routines. 44557 (line 151) 44558* __dpd_truncddsd2: Decimal float library routines. 44559 (line 92) 44560* __dpd_truncddsf: Decimal float library routines. 44561 (line 122) 44562* __dpd_truncdfsd: Decimal float library routines. 44563 (line 109) 44564* __dpd_truncsdsf: Decimal float library routines. 44565 (line 149) 44566* __dpd_trunctddd2: Decimal float library routines. 44567 (line 96) 44568* __dpd_trunctddf: Decimal float library routines. 44569 (line 128) 44570* __dpd_trunctdsd2: Decimal float library routines. 44571 (line 94) 44572* __dpd_trunctdsf: Decimal float library routines. 44573 (line 124) 44574* __dpd_trunctdtf: Decimal float library routines. 44575 (line 153) 44576* __dpd_trunctdxf: Decimal float library routines. 44577 (line 134) 44578* __dpd_trunctfdd: Decimal float library routines. 44579 (line 117) 44580* __dpd_trunctfsd: Decimal float library routines. 44581 (line 113) 44582* __dpd_truncxfdd: Decimal float library routines. 44583 (line 115) 44584* __dpd_truncxfsd: Decimal float library routines. 44585 (line 111) 44586* __dpd_unorddd2: Decimal float library routines. 44587 (line 233) 44588* __dpd_unordsd2: Decimal float library routines. 44589 (line 231) 44590* __dpd_unordtd2: Decimal float library routines. 44591 (line 235) 44592* __DTOR_LIST__: Initialization. (line 25) 44593* __eqdf2: Soft float library routines. 44594 (line 193) 44595* __eqsf2: Soft float library routines. 44596 (line 192) 44597* __eqtf2: Soft float library routines. 44598 (line 194) 44599* __extenddftf2: Soft float library routines. 44600 (line 67) 44601* __extenddfxf2: Soft float library routines. 44602 (line 68) 44603* __extendsfdf2: Soft float library routines. 44604 (line 64) 44605* __extendsftf2: Soft float library routines. 44606 (line 65) 44607* __extendsfxf2: Soft float library routines. 44608 (line 66) 44609* __ffsdi2: Integer library routines. 44610 (line 143) 44611* __ffsti2: Integer library routines. 44612 (line 144) 44613* __fixdfdi: Soft float library routines. 44614 (line 87) 44615* __fixdfsi: Soft float library routines. 44616 (line 80) 44617* __fixdfti: Soft float library routines. 44618 (line 93) 44619* __fixsfdi: Soft float library routines. 44620 (line 86) 44621* __fixsfsi: Soft float library routines. 44622 (line 79) 44623* __fixsfti: Soft float library routines. 44624 (line 92) 44625* __fixtfdi: Soft float library routines. 44626 (line 88) 44627* __fixtfsi: Soft float library routines. 44628 (line 81) 44629* __fixtfti: Soft float library routines. 44630 (line 94) 44631* __fixunsdfdi: Soft float library routines. 44632 (line 107) 44633* __fixunsdfsi: Soft float library routines. 44634 (line 100) 44635* __fixunsdfti: Soft float library routines. 44636 (line 114) 44637* __fixunssfdi: Soft float library routines. 44638 (line 106) 44639* __fixunssfsi: Soft float library routines. 44640 (line 99) 44641* __fixunssfti: Soft float library routines. 44642 (line 113) 44643* __fixunstfdi: Soft float library routines. 44644 (line 108) 44645* __fixunstfsi: Soft float library routines. 44646 (line 101) 44647* __fixunstfti: Soft float library routines. 44648 (line 115) 44649* __fixunsxfdi: Soft float library routines. 44650 (line 109) 44651* __fixunsxfsi: Soft float library routines. 44652 (line 102) 44653* __fixunsxfti: Soft float library routines. 44654 (line 116) 44655* __fixxfdi: Soft float library routines. 44656 (line 89) 44657* __fixxfsi: Soft float library routines. 44658 (line 82) 44659* __fixxfti: Soft float library routines. 44660 (line 95) 44661* __floatdidf: Soft float library routines. 44662 (line 127) 44663* __floatdisf: Soft float library routines. 44664 (line 126) 44665* __floatditf: Soft float library routines. 44666 (line 128) 44667* __floatdixf: Soft float library routines. 44668 (line 129) 44669* __floatsidf: Soft float library routines. 44670 (line 121) 44671* __floatsisf: Soft float library routines. 44672 (line 120) 44673* __floatsitf: Soft float library routines. 44674 (line 122) 44675* __floatsixf: Soft float library routines. 44676 (line 123) 44677* __floattidf: Soft float library routines. 44678 (line 133) 44679* __floattisf: Soft float library routines. 44680 (line 132) 44681* __floattitf: Soft float library routines. 44682 (line 134) 44683* __floattixf: Soft float library routines. 44684 (line 135) 44685* __floatundidf: Soft float library routines. 44686 (line 145) 44687* __floatundisf: Soft float library routines. 44688 (line 144) 44689* __floatunditf: Soft float library routines. 44690 (line 146) 44691* __floatundixf: Soft float library routines. 44692 (line 147) 44693* __floatunsidf: Soft float library routines. 44694 (line 139) 44695* __floatunsisf: Soft float library routines. 44696 (line 138) 44697* __floatunsitf: Soft float library routines. 44698 (line 140) 44699* __floatunsixf: Soft float library routines. 44700 (line 141) 44701* __floatuntidf: Soft float library routines. 44702 (line 151) 44703* __floatuntisf: Soft float library routines. 44704 (line 150) 44705* __floatuntitf: Soft float library routines. 44706 (line 152) 44707* __floatuntixf: Soft float library routines. 44708 (line 153) 44709* __fractdadf: Fixed-point fractional library routines. 44710 (line 643) 44711* __fractdadi: Fixed-point fractional library routines. 44712 (line 640) 44713* __fractdadq: Fixed-point fractional library routines. 44714 (line 623) 44715* __fractdaha2: Fixed-point fractional library routines. 44716 (line 624) 44717* __fractdahi: Fixed-point fractional library routines. 44718 (line 638) 44719* __fractdahq: Fixed-point fractional library routines. 44720 (line 621) 44721* __fractdaqi: Fixed-point fractional library routines. 44722 (line 637) 44723* __fractdaqq: Fixed-point fractional library routines. 44724 (line 620) 44725* __fractdasa2: Fixed-point fractional library routines. 44726 (line 625) 44727* __fractdasf: Fixed-point fractional library routines. 44728 (line 642) 44729* __fractdasi: Fixed-point fractional library routines. 44730 (line 639) 44731* __fractdasq: Fixed-point fractional library routines. 44732 (line 622) 44733* __fractdata2: Fixed-point fractional library routines. 44734 (line 626) 44735* __fractdati: Fixed-point fractional library routines. 44736 (line 641) 44737* __fractdauda: Fixed-point fractional library routines. 44738 (line 634) 44739* __fractdaudq: Fixed-point fractional library routines. 44740 (line 630) 44741* __fractdauha: Fixed-point fractional library routines. 44742 (line 632) 44743* __fractdauhq: Fixed-point fractional library routines. 44744 (line 628) 44745* __fractdauqq: Fixed-point fractional library routines. 44746 (line 627) 44747* __fractdausa: Fixed-point fractional library routines. 44748 (line 633) 44749* __fractdausq: Fixed-point fractional library routines. 44750 (line 629) 44751* __fractdauta: Fixed-point fractional library routines. 44752 (line 635) 44753* __fractdfda: Fixed-point fractional library routines. 44754 (line 1032) 44755* __fractdfdq: Fixed-point fractional library routines. 44756 (line 1029) 44757* __fractdfha: Fixed-point fractional library routines. 44758 (line 1030) 44759* __fractdfhq: Fixed-point fractional library routines. 44760 (line 1027) 44761* __fractdfqq: Fixed-point fractional library routines. 44762 (line 1026) 44763* __fractdfsa: Fixed-point fractional library routines. 44764 (line 1031) 44765* __fractdfsq: Fixed-point fractional library routines. 44766 (line 1028) 44767* __fractdfta: Fixed-point fractional library routines. 44768 (line 1033) 44769* __fractdfuda: Fixed-point fractional library routines. 44770 (line 1040) 44771* __fractdfudq: Fixed-point fractional library routines. 44772 (line 1037) 44773* __fractdfuha: Fixed-point fractional library routines. 44774 (line 1038) 44775* __fractdfuhq: Fixed-point fractional library routines. 44776 (line 1035) 44777* __fractdfuqq: Fixed-point fractional library routines. 44778 (line 1034) 44779* __fractdfusa: Fixed-point fractional library routines. 44780 (line 1039) 44781* __fractdfusq: Fixed-point fractional library routines. 44782 (line 1036) 44783* __fractdfuta: Fixed-point fractional library routines. 44784 (line 1041) 44785* __fractdida: Fixed-point fractional library routines. 44786 (line 982) 44787* __fractdidq: Fixed-point fractional library routines. 44788 (line 979) 44789* __fractdiha: Fixed-point fractional library routines. 44790 (line 980) 44791* __fractdihq: Fixed-point fractional library routines. 44792 (line 977) 44793* __fractdiqq: Fixed-point fractional library routines. 44794 (line 976) 44795* __fractdisa: Fixed-point fractional library routines. 44796 (line 981) 44797* __fractdisq: Fixed-point fractional library routines. 44798 (line 978) 44799* __fractdita: Fixed-point fractional library routines. 44800 (line 983) 44801* __fractdiuda: Fixed-point fractional library routines. 44802 (line 990) 44803* __fractdiudq: Fixed-point fractional library routines. 44804 (line 987) 44805* __fractdiuha: Fixed-point fractional library routines. 44806 (line 988) 44807* __fractdiuhq: Fixed-point fractional library routines. 44808 (line 985) 44809* __fractdiuqq: Fixed-point fractional library routines. 44810 (line 984) 44811* __fractdiusa: Fixed-point fractional library routines. 44812 (line 989) 44813* __fractdiusq: Fixed-point fractional library routines. 44814 (line 986) 44815* __fractdiuta: Fixed-point fractional library routines. 44816 (line 991) 44817* __fractdqda: Fixed-point fractional library routines. 44818 (line 551) 44819* __fractdqdf: Fixed-point fractional library routines. 44820 (line 573) 44821* __fractdqdi: Fixed-point fractional library routines. 44822 (line 570) 44823* __fractdqha: Fixed-point fractional library routines. 44824 (line 549) 44825* __fractdqhi: Fixed-point fractional library routines. 44826 (line 568) 44827* __fractdqhq2: Fixed-point fractional library routines. 44828 (line 547) 44829* __fractdqqi: Fixed-point fractional library routines. 44830 (line 567) 44831* __fractdqqq2: Fixed-point fractional library routines. 44832 (line 546) 44833* __fractdqsa: Fixed-point fractional library routines. 44834 (line 550) 44835* __fractdqsf: Fixed-point fractional library routines. 44836 (line 572) 44837* __fractdqsi: Fixed-point fractional library routines. 44838 (line 569) 44839* __fractdqsq2: Fixed-point fractional library routines. 44840 (line 548) 44841* __fractdqta: Fixed-point fractional library routines. 44842 (line 552) 44843* __fractdqti: Fixed-point fractional library routines. 44844 (line 571) 44845* __fractdquda: Fixed-point fractional library routines. 44846 (line 563) 44847* __fractdqudq: Fixed-point fractional library routines. 44848 (line 558) 44849* __fractdquha: Fixed-point fractional library routines. 44850 (line 560) 44851* __fractdquhq: Fixed-point fractional library routines. 44852 (line 555) 44853* __fractdquqq: Fixed-point fractional library routines. 44854 (line 553) 44855* __fractdqusa: Fixed-point fractional library routines. 44856 (line 562) 44857* __fractdqusq: Fixed-point fractional library routines. 44858 (line 556) 44859* __fractdquta: Fixed-point fractional library routines. 44860 (line 565) 44861* __fracthada2: Fixed-point fractional library routines. 44862 (line 579) 44863* __fracthadf: Fixed-point fractional library routines. 44864 (line 597) 44865* __fracthadi: Fixed-point fractional library routines. 44866 (line 594) 44867* __fracthadq: Fixed-point fractional library routines. 44868 (line 577) 44869* __fracthahi: Fixed-point fractional library routines. 44870 (line 592) 44871* __fracthahq: Fixed-point fractional library routines. 44872 (line 575) 44873* __fracthaqi: Fixed-point fractional library routines. 44874 (line 591) 44875* __fracthaqq: Fixed-point fractional library routines. 44876 (line 574) 44877* __fracthasa2: Fixed-point fractional library routines. 44878 (line 578) 44879* __fracthasf: Fixed-point fractional library routines. 44880 (line 596) 44881* __fracthasi: Fixed-point fractional library routines. 44882 (line 593) 44883* __fracthasq: Fixed-point fractional library routines. 44884 (line 576) 44885* __fracthata2: Fixed-point fractional library routines. 44886 (line 580) 44887* __fracthati: Fixed-point fractional library routines. 44888 (line 595) 44889* __fracthauda: Fixed-point fractional library routines. 44890 (line 588) 44891* __fracthaudq: Fixed-point fractional library routines. 44892 (line 584) 44893* __fracthauha: Fixed-point fractional library routines. 44894 (line 586) 44895* __fracthauhq: Fixed-point fractional library routines. 44896 (line 582) 44897* __fracthauqq: Fixed-point fractional library routines. 44898 (line 581) 44899* __fracthausa: Fixed-point fractional library routines. 44900 (line 587) 44901* __fracthausq: Fixed-point fractional library routines. 44902 (line 583) 44903* __fracthauta: Fixed-point fractional library routines. 44904 (line 589) 44905* __fracthida: Fixed-point fractional library routines. 44906 (line 950) 44907* __fracthidq: Fixed-point fractional library routines. 44908 (line 947) 44909* __fracthiha: Fixed-point fractional library routines. 44910 (line 948) 44911* __fracthihq: Fixed-point fractional library routines. 44912 (line 945) 44913* __fracthiqq: Fixed-point fractional library routines. 44914 (line 944) 44915* __fracthisa: Fixed-point fractional library routines. 44916 (line 949) 44917* __fracthisq: Fixed-point fractional library routines. 44918 (line 946) 44919* __fracthita: Fixed-point fractional library routines. 44920 (line 951) 44921* __fracthiuda: Fixed-point fractional library routines. 44922 (line 958) 44923* __fracthiudq: Fixed-point fractional library routines. 44924 (line 955) 44925* __fracthiuha: Fixed-point fractional library routines. 44926 (line 956) 44927* __fracthiuhq: Fixed-point fractional library routines. 44928 (line 953) 44929* __fracthiuqq: Fixed-point fractional library routines. 44930 (line 952) 44931* __fracthiusa: Fixed-point fractional library routines. 44932 (line 957) 44933* __fracthiusq: Fixed-point fractional library routines. 44934 (line 954) 44935* __fracthiuta: Fixed-point fractional library routines. 44936 (line 959) 44937* __fracthqda: Fixed-point fractional library routines. 44938 (line 505) 44939* __fracthqdf: Fixed-point fractional library routines. 44940 (line 521) 44941* __fracthqdi: Fixed-point fractional library routines. 44942 (line 518) 44943* __fracthqdq2: Fixed-point fractional library routines. 44944 (line 502) 44945* __fracthqha: Fixed-point fractional library routines. 44946 (line 503) 44947* __fracthqhi: Fixed-point fractional library routines. 44948 (line 516) 44949* __fracthqqi: Fixed-point fractional library routines. 44950 (line 515) 44951* __fracthqqq2: Fixed-point fractional library routines. 44952 (line 500) 44953* __fracthqsa: Fixed-point fractional library routines. 44954 (line 504) 44955* __fracthqsf: Fixed-point fractional library routines. 44956 (line 520) 44957* __fracthqsi: Fixed-point fractional library routines. 44958 (line 517) 44959* __fracthqsq2: Fixed-point fractional library routines. 44960 (line 501) 44961* __fracthqta: Fixed-point fractional library routines. 44962 (line 506) 44963* __fracthqti: Fixed-point fractional library routines. 44964 (line 519) 44965* __fracthquda: Fixed-point fractional library routines. 44966 (line 513) 44967* __fracthqudq: Fixed-point fractional library routines. 44968 (line 510) 44969* __fracthquha: Fixed-point fractional library routines. 44970 (line 511) 44971* __fracthquhq: Fixed-point fractional library routines. 44972 (line 508) 44973* __fracthquqq: Fixed-point fractional library routines. 44974 (line 507) 44975* __fracthqusa: Fixed-point fractional library routines. 44976 (line 512) 44977* __fracthqusq: Fixed-point fractional library routines. 44978 (line 509) 44979* __fracthquta: Fixed-point fractional library routines. 44980 (line 514) 44981* __fractqida: Fixed-point fractional library routines. 44982 (line 932) 44983* __fractqidq: Fixed-point fractional library routines. 44984 (line 929) 44985* __fractqiha: Fixed-point fractional library routines. 44986 (line 930) 44987* __fractqihq: Fixed-point fractional library routines. 44988 (line 927) 44989* __fractqiqq: Fixed-point fractional library routines. 44990 (line 926) 44991* __fractqisa: Fixed-point fractional library routines. 44992 (line 931) 44993* __fractqisq: Fixed-point fractional library routines. 44994 (line 928) 44995* __fractqita: Fixed-point fractional library routines. 44996 (line 933) 44997* __fractqiuda: Fixed-point fractional library routines. 44998 (line 941) 44999* __fractqiudq: Fixed-point fractional library routines. 45000 (line 937) 45001* __fractqiuha: Fixed-point fractional library routines. 45002 (line 939) 45003* __fractqiuhq: Fixed-point fractional library routines. 45004 (line 935) 45005* __fractqiuqq: Fixed-point fractional library routines. 45006 (line 934) 45007* __fractqiusa: Fixed-point fractional library routines. 45008 (line 940) 45009* __fractqiusq: Fixed-point fractional library routines. 45010 (line 936) 45011* __fractqiuta: Fixed-point fractional library routines. 45012 (line 942) 45013* __fractqqda: Fixed-point fractional library routines. 45014 (line 481) 45015* __fractqqdf: Fixed-point fractional library routines. 45016 (line 499) 45017* __fractqqdi: Fixed-point fractional library routines. 45018 (line 496) 45019* __fractqqdq2: Fixed-point fractional library routines. 45020 (line 478) 45021* __fractqqha: Fixed-point fractional library routines. 45022 (line 479) 45023* __fractqqhi: Fixed-point fractional library routines. 45024 (line 494) 45025* __fractqqhq2: Fixed-point fractional library routines. 45026 (line 476) 45027* __fractqqqi: Fixed-point fractional library routines. 45028 (line 493) 45029* __fractqqsa: Fixed-point fractional library routines. 45030 (line 480) 45031* __fractqqsf: Fixed-point fractional library routines. 45032 (line 498) 45033* __fractqqsi: Fixed-point fractional library routines. 45034 (line 495) 45035* __fractqqsq2: Fixed-point fractional library routines. 45036 (line 477) 45037* __fractqqta: Fixed-point fractional library routines. 45038 (line 482) 45039* __fractqqti: Fixed-point fractional library routines. 45040 (line 497) 45041* __fractqquda: Fixed-point fractional library routines. 45042 (line 490) 45043* __fractqqudq: Fixed-point fractional library routines. 45044 (line 486) 45045* __fractqquha: Fixed-point fractional library routines. 45046 (line 488) 45047* __fractqquhq: Fixed-point fractional library routines. 45048 (line 484) 45049* __fractqquqq: Fixed-point fractional library routines. 45050 (line 483) 45051* __fractqqusa: Fixed-point fractional library routines. 45052 (line 489) 45053* __fractqqusq: Fixed-point fractional library routines. 45054 (line 485) 45055* __fractqquta: Fixed-point fractional library routines. 45056 (line 491) 45057* __fractsada2: Fixed-point fractional library routines. 45058 (line 603) 45059* __fractsadf: Fixed-point fractional library routines. 45060 (line 619) 45061* __fractsadi: Fixed-point fractional library routines. 45062 (line 616) 45063* __fractsadq: Fixed-point fractional library routines. 45064 (line 601) 45065* __fractsaha2: Fixed-point fractional library routines. 45066 (line 602) 45067* __fractsahi: Fixed-point fractional library routines. 45068 (line 614) 45069* __fractsahq: Fixed-point fractional library routines. 45070 (line 599) 45071* __fractsaqi: Fixed-point fractional library routines. 45072 (line 613) 45073* __fractsaqq: Fixed-point fractional library routines. 45074 (line 598) 45075* __fractsasf: Fixed-point fractional library routines. 45076 (line 618) 45077* __fractsasi: Fixed-point fractional library routines. 45078 (line 615) 45079* __fractsasq: Fixed-point fractional library routines. 45080 (line 600) 45081* __fractsata2: Fixed-point fractional library routines. 45082 (line 604) 45083* __fractsati: Fixed-point fractional library routines. 45084 (line 617) 45085* __fractsauda: Fixed-point fractional library routines. 45086 (line 611) 45087* __fractsaudq: Fixed-point fractional library routines. 45088 (line 608) 45089* __fractsauha: Fixed-point fractional library routines. 45090 (line 609) 45091* __fractsauhq: Fixed-point fractional library routines. 45092 (line 606) 45093* __fractsauqq: Fixed-point fractional library routines. 45094 (line 605) 45095* __fractsausa: Fixed-point fractional library routines. 45096 (line 610) 45097* __fractsausq: Fixed-point fractional library routines. 45098 (line 607) 45099* __fractsauta: Fixed-point fractional library routines. 45100 (line 612) 45101* __fractsfda: Fixed-point fractional library routines. 45102 (line 1016) 45103* __fractsfdq: Fixed-point fractional library routines. 45104 (line 1013) 45105* __fractsfha: Fixed-point fractional library routines. 45106 (line 1014) 45107* __fractsfhq: Fixed-point fractional library routines. 45108 (line 1011) 45109* __fractsfqq: Fixed-point fractional library routines. 45110 (line 1010) 45111* __fractsfsa: Fixed-point fractional library routines. 45112 (line 1015) 45113* __fractsfsq: Fixed-point fractional library routines. 45114 (line 1012) 45115* __fractsfta: Fixed-point fractional library routines. 45116 (line 1017) 45117* __fractsfuda: Fixed-point fractional library routines. 45118 (line 1024) 45119* __fractsfudq: Fixed-point fractional library routines. 45120 (line 1021) 45121* __fractsfuha: Fixed-point fractional library routines. 45122 (line 1022) 45123* __fractsfuhq: Fixed-point fractional library routines. 45124 (line 1019) 45125* __fractsfuqq: Fixed-point fractional library routines. 45126 (line 1018) 45127* __fractsfusa: Fixed-point fractional library routines. 45128 (line 1023) 45129* __fractsfusq: Fixed-point fractional library routines. 45130 (line 1020) 45131* __fractsfuta: Fixed-point fractional library routines. 45132 (line 1025) 45133* __fractsida: Fixed-point fractional library routines. 45134 (line 966) 45135* __fractsidq: Fixed-point fractional library routines. 45136 (line 963) 45137* __fractsiha: Fixed-point fractional library routines. 45138 (line 964) 45139* __fractsihq: Fixed-point fractional library routines. 45140 (line 961) 45141* __fractsiqq: Fixed-point fractional library routines. 45142 (line 960) 45143* __fractsisa: Fixed-point fractional library routines. 45144 (line 965) 45145* __fractsisq: Fixed-point fractional library routines. 45146 (line 962) 45147* __fractsita: Fixed-point fractional library routines. 45148 (line 967) 45149* __fractsiuda: Fixed-point fractional library routines. 45150 (line 974) 45151* __fractsiudq: Fixed-point fractional library routines. 45152 (line 971) 45153* __fractsiuha: Fixed-point fractional library routines. 45154 (line 972) 45155* __fractsiuhq: Fixed-point fractional library routines. 45156 (line 969) 45157* __fractsiuqq: Fixed-point fractional library routines. 45158 (line 968) 45159* __fractsiusa: Fixed-point fractional library routines. 45160 (line 973) 45161* __fractsiusq: Fixed-point fractional library routines. 45162 (line 970) 45163* __fractsiuta: Fixed-point fractional library routines. 45164 (line 975) 45165* __fractsqda: Fixed-point fractional library routines. 45166 (line 527) 45167* __fractsqdf: Fixed-point fractional library routines. 45168 (line 545) 45169* __fractsqdi: Fixed-point fractional library routines. 45170 (line 542) 45171* __fractsqdq2: Fixed-point fractional library routines. 45172 (line 524) 45173* __fractsqha: Fixed-point fractional library routines. 45174 (line 525) 45175* __fractsqhi: Fixed-point fractional library routines. 45176 (line 540) 45177* __fractsqhq2: Fixed-point fractional library routines. 45178 (line 523) 45179* __fractsqqi: Fixed-point fractional library routines. 45180 (line 539) 45181* __fractsqqq2: Fixed-point fractional library routines. 45182 (line 522) 45183* __fractsqsa: Fixed-point fractional library routines. 45184 (line 526) 45185* __fractsqsf: Fixed-point fractional library routines. 45186 (line 544) 45187* __fractsqsi: Fixed-point fractional library routines. 45188 (line 541) 45189* __fractsqta: Fixed-point fractional library routines. 45190 (line 528) 45191* __fractsqti: Fixed-point fractional library routines. 45192 (line 543) 45193* __fractsquda: Fixed-point fractional library routines. 45194 (line 536) 45195* __fractsqudq: Fixed-point fractional library routines. 45196 (line 532) 45197* __fractsquha: Fixed-point fractional library routines. 45198 (line 534) 45199* __fractsquhq: Fixed-point fractional library routines. 45200 (line 530) 45201* __fractsquqq: Fixed-point fractional library routines. 45202 (line 529) 45203* __fractsqusa: Fixed-point fractional library routines. 45204 (line 535) 45205* __fractsqusq: Fixed-point fractional library routines. 45206 (line 531) 45207* __fractsquta: Fixed-point fractional library routines. 45208 (line 537) 45209* __fracttada2: Fixed-point fractional library routines. 45210 (line 650) 45211* __fracttadf: Fixed-point fractional library routines. 45212 (line 671) 45213* __fracttadi: Fixed-point fractional library routines. 45214 (line 668) 45215* __fracttadq: Fixed-point fractional library routines. 45216 (line 647) 45217* __fracttaha2: Fixed-point fractional library routines. 45218 (line 648) 45219* __fracttahi: Fixed-point fractional library routines. 45220 (line 666) 45221* __fracttahq: Fixed-point fractional library routines. 45222 (line 645) 45223* __fracttaqi: Fixed-point fractional library routines. 45224 (line 665) 45225* __fracttaqq: Fixed-point fractional library routines. 45226 (line 644) 45227* __fracttasa2: Fixed-point fractional library routines. 45228 (line 649) 45229* __fracttasf: Fixed-point fractional library routines. 45230 (line 670) 45231* __fracttasi: Fixed-point fractional library routines. 45232 (line 667) 45233* __fracttasq: Fixed-point fractional library routines. 45234 (line 646) 45235* __fracttati: Fixed-point fractional library routines. 45236 (line 669) 45237* __fracttauda: Fixed-point fractional library routines. 45238 (line 661) 45239* __fracttaudq: Fixed-point fractional library routines. 45240 (line 656) 45241* __fracttauha: Fixed-point fractional library routines. 45242 (line 658) 45243* __fracttauhq: Fixed-point fractional library routines. 45244 (line 653) 45245* __fracttauqq: Fixed-point fractional library routines. 45246 (line 651) 45247* __fracttausa: Fixed-point fractional library routines. 45248 (line 660) 45249* __fracttausq: Fixed-point fractional library routines. 45250 (line 654) 45251* __fracttauta: Fixed-point fractional library routines. 45252 (line 663) 45253* __fracttida: Fixed-point fractional library routines. 45254 (line 998) 45255* __fracttidq: Fixed-point fractional library routines. 45256 (line 995) 45257* __fracttiha: Fixed-point fractional library routines. 45258 (line 996) 45259* __fracttihq: Fixed-point fractional library routines. 45260 (line 993) 45261* __fracttiqq: Fixed-point fractional library routines. 45262 (line 992) 45263* __fracttisa: Fixed-point fractional library routines. 45264 (line 997) 45265* __fracttisq: Fixed-point fractional library routines. 45266 (line 994) 45267* __fracttita: Fixed-point fractional library routines. 45268 (line 999) 45269* __fracttiuda: Fixed-point fractional library routines. 45270 (line 1007) 45271* __fracttiudq: Fixed-point fractional library routines. 45272 (line 1003) 45273* __fracttiuha: Fixed-point fractional library routines. 45274 (line 1005) 45275* __fracttiuhq: Fixed-point fractional library routines. 45276 (line 1001) 45277* __fracttiuqq: Fixed-point fractional library routines. 45278 (line 1000) 45279* __fracttiusa: Fixed-point fractional library routines. 45280 (line 1006) 45281* __fracttiusq: Fixed-point fractional library routines. 45282 (line 1002) 45283* __fracttiuta: Fixed-point fractional library routines. 45284 (line 1008) 45285* __fractudada: Fixed-point fractional library routines. 45286 (line 865) 45287* __fractudadf: Fixed-point fractional library routines. 45288 (line 888) 45289* __fractudadi: Fixed-point fractional library routines. 45290 (line 885) 45291* __fractudadq: Fixed-point fractional library routines. 45292 (line 861) 45293* __fractudaha: Fixed-point fractional library routines. 45294 (line 863) 45295* __fractudahi: Fixed-point fractional library routines. 45296 (line 883) 45297* __fractudahq: Fixed-point fractional library routines. 45298 (line 859) 45299* __fractudaqi: Fixed-point fractional library routines. 45300 (line 882) 45301* __fractudaqq: Fixed-point fractional library routines. 45302 (line 858) 45303* __fractudasa: Fixed-point fractional library routines. 45304 (line 864) 45305* __fractudasf: Fixed-point fractional library routines. 45306 (line 887) 45307* __fractudasi: Fixed-point fractional library routines. 45308 (line 884) 45309* __fractudasq: Fixed-point fractional library routines. 45310 (line 860) 45311* __fractudata: Fixed-point fractional library routines. 45312 (line 866) 45313* __fractudati: Fixed-point fractional library routines. 45314 (line 886) 45315* __fractudaudq: Fixed-point fractional library routines. 45316 (line 874) 45317* __fractudauha2: Fixed-point fractional library routines. 45318 (line 876) 45319* __fractudauhq: Fixed-point fractional library routines. 45320 (line 870) 45321* __fractudauqq: Fixed-point fractional library routines. 45322 (line 868) 45323* __fractudausa2: Fixed-point fractional library routines. 45324 (line 878) 45325* __fractudausq: Fixed-point fractional library routines. 45326 (line 872) 45327* __fractudauta2: Fixed-point fractional library routines. 45328 (line 880) 45329* __fractudqda: Fixed-point fractional library routines. 45330 (line 772) 45331* __fractudqdf: Fixed-point fractional library routines. 45332 (line 798) 45333* __fractudqdi: Fixed-point fractional library routines. 45334 (line 794) 45335* __fractudqdq: Fixed-point fractional library routines. 45336 (line 767) 45337* __fractudqha: Fixed-point fractional library routines. 45338 (line 769) 45339* __fractudqhi: Fixed-point fractional library routines. 45340 (line 792) 45341* __fractudqhq: Fixed-point fractional library routines. 45342 (line 764) 45343* __fractudqqi: Fixed-point fractional library routines. 45344 (line 790) 45345* __fractudqqq: Fixed-point fractional library routines. 45346 (line 762) 45347* __fractudqsa: Fixed-point fractional library routines. 45348 (line 771) 45349* __fractudqsf: Fixed-point fractional library routines. 45350 (line 797) 45351* __fractudqsi: Fixed-point fractional library routines. 45352 (line 793) 45353* __fractudqsq: Fixed-point fractional library routines. 45354 (line 765) 45355* __fractudqta: Fixed-point fractional library routines. 45356 (line 774) 45357* __fractudqti: Fixed-point fractional library routines. 45358 (line 795) 45359* __fractudquda: Fixed-point fractional library routines. 45360 (line 786) 45361* __fractudquha: Fixed-point fractional library routines. 45362 (line 782) 45363* __fractudquhq2: Fixed-point fractional library routines. 45364 (line 778) 45365* __fractudquqq2: Fixed-point fractional library routines. 45366 (line 776) 45367* __fractudqusa: Fixed-point fractional library routines. 45368 (line 784) 45369* __fractudqusq2: Fixed-point fractional library routines. 45370 (line 780) 45371* __fractudquta: Fixed-point fractional library routines. 45372 (line 788) 45373* __fractuhada: Fixed-point fractional library routines. 45374 (line 806) 45375* __fractuhadf: Fixed-point fractional library routines. 45376 (line 829) 45377* __fractuhadi: Fixed-point fractional library routines. 45378 (line 826) 45379* __fractuhadq: Fixed-point fractional library routines. 45380 (line 802) 45381* __fractuhaha: Fixed-point fractional library routines. 45382 (line 804) 45383* __fractuhahi: Fixed-point fractional library routines. 45384 (line 824) 45385* __fractuhahq: Fixed-point fractional library routines. 45386 (line 800) 45387* __fractuhaqi: Fixed-point fractional library routines. 45388 (line 823) 45389* __fractuhaqq: Fixed-point fractional library routines. 45390 (line 799) 45391* __fractuhasa: Fixed-point fractional library routines. 45392 (line 805) 45393* __fractuhasf: Fixed-point fractional library routines. 45394 (line 828) 45395* __fractuhasi: Fixed-point fractional library routines. 45396 (line 825) 45397* __fractuhasq: Fixed-point fractional library routines. 45398 (line 801) 45399* __fractuhata: Fixed-point fractional library routines. 45400 (line 807) 45401* __fractuhati: Fixed-point fractional library routines. 45402 (line 827) 45403* __fractuhauda2: Fixed-point fractional library routines. 45404 (line 819) 45405* __fractuhaudq: Fixed-point fractional library routines. 45406 (line 815) 45407* __fractuhauhq: Fixed-point fractional library routines. 45408 (line 811) 45409* __fractuhauqq: Fixed-point fractional library routines. 45410 (line 809) 45411* __fractuhausa2: Fixed-point fractional library routines. 45412 (line 817) 45413* __fractuhausq: Fixed-point fractional library routines. 45414 (line 813) 45415* __fractuhauta2: Fixed-point fractional library routines. 45416 (line 821) 45417* __fractuhqda: Fixed-point fractional library routines. 45418 (line 709) 45419* __fractuhqdf: Fixed-point fractional library routines. 45420 (line 730) 45421* __fractuhqdi: Fixed-point fractional library routines. 45422 (line 727) 45423* __fractuhqdq: Fixed-point fractional library routines. 45424 (line 706) 45425* __fractuhqha: Fixed-point fractional library routines. 45426 (line 707) 45427* __fractuhqhi: Fixed-point fractional library routines. 45428 (line 725) 45429* __fractuhqhq: Fixed-point fractional library routines. 45430 (line 704) 45431* __fractuhqqi: Fixed-point fractional library routines. 45432 (line 724) 45433* __fractuhqqq: Fixed-point fractional library routines. 45434 (line 703) 45435* __fractuhqsa: Fixed-point fractional library routines. 45436 (line 708) 45437* __fractuhqsf: Fixed-point fractional library routines. 45438 (line 729) 45439* __fractuhqsi: Fixed-point fractional library routines. 45440 (line 726) 45441* __fractuhqsq: Fixed-point fractional library routines. 45442 (line 705) 45443* __fractuhqta: Fixed-point fractional library routines. 45444 (line 710) 45445* __fractuhqti: Fixed-point fractional library routines. 45446 (line 728) 45447* __fractuhquda: Fixed-point fractional library routines. 45448 (line 720) 45449* __fractuhqudq2: Fixed-point fractional library routines. 45450 (line 715) 45451* __fractuhquha: Fixed-point fractional library routines. 45452 (line 717) 45453* __fractuhquqq2: Fixed-point fractional library routines. 45454 (line 711) 45455* __fractuhqusa: Fixed-point fractional library routines. 45456 (line 719) 45457* __fractuhqusq2: Fixed-point fractional library routines. 45458 (line 713) 45459* __fractuhquta: Fixed-point fractional library routines. 45460 (line 722) 45461* __fractunsdadi: Fixed-point fractional library routines. 45462 (line 1562) 45463* __fractunsdahi: Fixed-point fractional library routines. 45464 (line 1560) 45465* __fractunsdaqi: Fixed-point fractional library routines. 45466 (line 1559) 45467* __fractunsdasi: Fixed-point fractional library routines. 45468 (line 1561) 45469* __fractunsdati: Fixed-point fractional library routines. 45470 (line 1563) 45471* __fractunsdida: Fixed-point fractional library routines. 45472 (line 1714) 45473* __fractunsdidq: Fixed-point fractional library routines. 45474 (line 1711) 45475* __fractunsdiha: Fixed-point fractional library routines. 45476 (line 1712) 45477* __fractunsdihq: Fixed-point fractional library routines. 45478 (line 1709) 45479* __fractunsdiqq: Fixed-point fractional library routines. 45480 (line 1708) 45481* __fractunsdisa: Fixed-point fractional library routines. 45482 (line 1713) 45483* __fractunsdisq: Fixed-point fractional library routines. 45484 (line 1710) 45485* __fractunsdita: Fixed-point fractional library routines. 45486 (line 1715) 45487* __fractunsdiuda: Fixed-point fractional library routines. 45488 (line 1726) 45489* __fractunsdiudq: Fixed-point fractional library routines. 45490 (line 1721) 45491* __fractunsdiuha: Fixed-point fractional library routines. 45492 (line 1723) 45493* __fractunsdiuhq: Fixed-point fractional library routines. 45494 (line 1718) 45495* __fractunsdiuqq: Fixed-point fractional library routines. 45496 (line 1716) 45497* __fractunsdiusa: Fixed-point fractional library routines. 45498 (line 1725) 45499* __fractunsdiusq: Fixed-point fractional library routines. 45500 (line 1719) 45501* __fractunsdiuta: Fixed-point fractional library routines. 45502 (line 1728) 45503* __fractunsdqdi: Fixed-point fractional library routines. 45504 (line 1546) 45505* __fractunsdqhi: Fixed-point fractional library routines. 45506 (line 1544) 45507* __fractunsdqqi: Fixed-point fractional library routines. 45508 (line 1543) 45509* __fractunsdqsi: Fixed-point fractional library routines. 45510 (line 1545) 45511* __fractunsdqti: Fixed-point fractional library routines. 45512 (line 1547) 45513* __fractunshadi: Fixed-point fractional library routines. 45514 (line 1552) 45515* __fractunshahi: Fixed-point fractional library routines. 45516 (line 1550) 45517* __fractunshaqi: Fixed-point fractional library routines. 45518 (line 1549) 45519* __fractunshasi: Fixed-point fractional library routines. 45520 (line 1551) 45521* __fractunshati: Fixed-point fractional library routines. 45522 (line 1553) 45523* __fractunshida: Fixed-point fractional library routines. 45524 (line 1670) 45525* __fractunshidq: Fixed-point fractional library routines. 45526 (line 1667) 45527* __fractunshiha: Fixed-point fractional library routines. 45528 (line 1668) 45529* __fractunshihq: Fixed-point fractional library routines. 45530 (line 1665) 45531* __fractunshiqq: Fixed-point fractional library routines. 45532 (line 1664) 45533* __fractunshisa: Fixed-point fractional library routines. 45534 (line 1669) 45535* __fractunshisq: Fixed-point fractional library routines. 45536 (line 1666) 45537* __fractunshita: Fixed-point fractional library routines. 45538 (line 1671) 45539* __fractunshiuda: Fixed-point fractional library routines. 45540 (line 1682) 45541* __fractunshiudq: Fixed-point fractional library routines. 45542 (line 1677) 45543* __fractunshiuha: Fixed-point fractional library routines. 45544 (line 1679) 45545* __fractunshiuhq: Fixed-point fractional library routines. 45546 (line 1674) 45547* __fractunshiuqq: Fixed-point fractional library routines. 45548 (line 1672) 45549* __fractunshiusa: Fixed-point fractional library routines. 45550 (line 1681) 45551* __fractunshiusq: Fixed-point fractional library routines. 45552 (line 1675) 45553* __fractunshiuta: Fixed-point fractional library routines. 45554 (line 1684) 45555* __fractunshqdi: Fixed-point fractional library routines. 45556 (line 1536) 45557* __fractunshqhi: Fixed-point fractional library routines. 45558 (line 1534) 45559* __fractunshqqi: Fixed-point fractional library routines. 45560 (line 1533) 45561* __fractunshqsi: Fixed-point fractional library routines. 45562 (line 1535) 45563* __fractunshqti: Fixed-point fractional library routines. 45564 (line 1537) 45565* __fractunsqida: Fixed-point fractional library routines. 45566 (line 1648) 45567* __fractunsqidq: Fixed-point fractional library routines. 45568 (line 1645) 45569* __fractunsqiha: Fixed-point fractional library routines. 45570 (line 1646) 45571* __fractunsqihq: Fixed-point fractional library routines. 45572 (line 1643) 45573* __fractunsqiqq: Fixed-point fractional library routines. 45574 (line 1642) 45575* __fractunsqisa: Fixed-point fractional library routines. 45576 (line 1647) 45577* __fractunsqisq: Fixed-point fractional library routines. 45578 (line 1644) 45579* __fractunsqita: Fixed-point fractional library routines. 45580 (line 1649) 45581* __fractunsqiuda: Fixed-point fractional library routines. 45582 (line 1660) 45583* __fractunsqiudq: Fixed-point fractional library routines. 45584 (line 1655) 45585* __fractunsqiuha: Fixed-point fractional library routines. 45586 (line 1657) 45587* __fractunsqiuhq: Fixed-point fractional library routines. 45588 (line 1652) 45589* __fractunsqiuqq: Fixed-point fractional library routines. 45590 (line 1650) 45591* __fractunsqiusa: Fixed-point fractional library routines. 45592 (line 1659) 45593* __fractunsqiusq: Fixed-point fractional library routines. 45594 (line 1653) 45595* __fractunsqiuta: Fixed-point fractional library routines. 45596 (line 1662) 45597* __fractunsqqdi: Fixed-point fractional library routines. 45598 (line 1531) 45599* __fractunsqqhi: Fixed-point fractional library routines. 45600 (line 1529) 45601* __fractunsqqqi: Fixed-point fractional library routines. 45602 (line 1528) 45603* __fractunsqqsi: Fixed-point fractional library routines. 45604 (line 1530) 45605* __fractunsqqti: Fixed-point fractional library routines. 45606 (line 1532) 45607* __fractunssadi: Fixed-point fractional library routines. 45608 (line 1557) 45609* __fractunssahi: Fixed-point fractional library routines. 45610 (line 1555) 45611* __fractunssaqi: Fixed-point fractional library routines. 45612 (line 1554) 45613* __fractunssasi: Fixed-point fractional library routines. 45614 (line 1556) 45615* __fractunssati: Fixed-point fractional library routines. 45616 (line 1558) 45617* __fractunssida: Fixed-point fractional library routines. 45618 (line 1692) 45619* __fractunssidq: Fixed-point fractional library routines. 45620 (line 1689) 45621* __fractunssiha: Fixed-point fractional library routines. 45622 (line 1690) 45623* __fractunssihq: Fixed-point fractional library routines. 45624 (line 1687) 45625* __fractunssiqq: Fixed-point fractional library routines. 45626 (line 1686) 45627* __fractunssisa: Fixed-point fractional library routines. 45628 (line 1691) 45629* __fractunssisq: Fixed-point fractional library routines. 45630 (line 1688) 45631* __fractunssita: Fixed-point fractional library routines. 45632 (line 1693) 45633* __fractunssiuda: Fixed-point fractional library routines. 45634 (line 1704) 45635* __fractunssiudq: Fixed-point fractional library routines. 45636 (line 1699) 45637* __fractunssiuha: Fixed-point fractional library routines. 45638 (line 1701) 45639* __fractunssiuhq: Fixed-point fractional library routines. 45640 (line 1696) 45641* __fractunssiuqq: Fixed-point fractional library routines. 45642 (line 1694) 45643* __fractunssiusa: Fixed-point fractional library routines. 45644 (line 1703) 45645* __fractunssiusq: Fixed-point fractional library routines. 45646 (line 1697) 45647* __fractunssiuta: Fixed-point fractional library routines. 45648 (line 1706) 45649* __fractunssqdi: Fixed-point fractional library routines. 45650 (line 1541) 45651* __fractunssqhi: Fixed-point fractional library routines. 45652 (line 1539) 45653* __fractunssqqi: Fixed-point fractional library routines. 45654 (line 1538) 45655* __fractunssqsi: Fixed-point fractional library routines. 45656 (line 1540) 45657* __fractunssqti: Fixed-point fractional library routines. 45658 (line 1542) 45659* __fractunstadi: Fixed-point fractional library routines. 45660 (line 1567) 45661* __fractunstahi: Fixed-point fractional library routines. 45662 (line 1565) 45663* __fractunstaqi: Fixed-point fractional library routines. 45664 (line 1564) 45665* __fractunstasi: Fixed-point fractional library routines. 45666 (line 1566) 45667* __fractunstati: Fixed-point fractional library routines. 45668 (line 1568) 45669* __fractunstida: Fixed-point fractional library routines. 45670 (line 1737) 45671* __fractunstidq: Fixed-point fractional library routines. 45672 (line 1733) 45673* __fractunstiha: Fixed-point fractional library routines. 45674 (line 1735) 45675* __fractunstihq: Fixed-point fractional library routines. 45676 (line 1731) 45677* __fractunstiqq: Fixed-point fractional library routines. 45678 (line 1730) 45679* __fractunstisa: Fixed-point fractional library routines. 45680 (line 1736) 45681* __fractunstisq: Fixed-point fractional library routines. 45682 (line 1732) 45683* __fractunstita: Fixed-point fractional library routines. 45684 (line 1738) 45685* __fractunstiuda: Fixed-point fractional library routines. 45686 (line 1752) 45687* __fractunstiudq: Fixed-point fractional library routines. 45688 (line 1746) 45689* __fractunstiuha: Fixed-point fractional library routines. 45690 (line 1748) 45691* __fractunstiuhq: Fixed-point fractional library routines. 45692 (line 1742) 45693* __fractunstiuqq: Fixed-point fractional library routines. 45694 (line 1740) 45695* __fractunstiusa: Fixed-point fractional library routines. 45696 (line 1750) 45697* __fractunstiusq: Fixed-point fractional library routines. 45698 (line 1744) 45699* __fractunstiuta: Fixed-point fractional library routines. 45700 (line 1754) 45701* __fractunsudadi: Fixed-point fractional library routines. 45702 (line 1628) 45703* __fractunsudahi: Fixed-point fractional library routines. 45704 (line 1624) 45705* __fractunsudaqi: Fixed-point fractional library routines. 45706 (line 1622) 45707* __fractunsudasi: Fixed-point fractional library routines. 45708 (line 1626) 45709* __fractunsudati: Fixed-point fractional library routines. 45710 (line 1630) 45711* __fractunsudqdi: Fixed-point fractional library routines. 45712 (line 1602) 45713* __fractunsudqhi: Fixed-point fractional library routines. 45714 (line 1598) 45715* __fractunsudqqi: Fixed-point fractional library routines. 45716 (line 1596) 45717* __fractunsudqsi: Fixed-point fractional library routines. 45718 (line 1600) 45719* __fractunsudqti: Fixed-point fractional library routines. 45720 (line 1604) 45721* __fractunsuhadi: Fixed-point fractional library routines. 45722 (line 1612) 45723* __fractunsuhahi: Fixed-point fractional library routines. 45724 (line 1608) 45725* __fractunsuhaqi: Fixed-point fractional library routines. 45726 (line 1606) 45727* __fractunsuhasi: Fixed-point fractional library routines. 45728 (line 1610) 45729* __fractunsuhati: Fixed-point fractional library routines. 45730 (line 1614) 45731* __fractunsuhqdi: Fixed-point fractional library routines. 45732 (line 1583) 45733* __fractunsuhqhi: Fixed-point fractional library routines. 45734 (line 1581) 45735* __fractunsuhqqi: Fixed-point fractional library routines. 45736 (line 1580) 45737* __fractunsuhqsi: Fixed-point fractional library routines. 45738 (line 1582) 45739* __fractunsuhqti: Fixed-point fractional library routines. 45740 (line 1584) 45741* __fractunsuqqdi: Fixed-point fractional library routines. 45742 (line 1576) 45743* __fractunsuqqhi: Fixed-point fractional library routines. 45744 (line 1572) 45745* __fractunsuqqqi: Fixed-point fractional library routines. 45746 (line 1570) 45747* __fractunsuqqsi: Fixed-point fractional library routines. 45748 (line 1574) 45749* __fractunsuqqti: Fixed-point fractional library routines. 45750 (line 1578) 45751* __fractunsusadi: Fixed-point fractional library routines. 45752 (line 1619) 45753* __fractunsusahi: Fixed-point fractional library routines. 45754 (line 1617) 45755* __fractunsusaqi: Fixed-point fractional library routines. 45756 (line 1616) 45757* __fractunsusasi: Fixed-point fractional library routines. 45758 (line 1618) 45759* __fractunsusati: Fixed-point fractional library routines. 45760 (line 1620) 45761* __fractunsusqdi: Fixed-point fractional library routines. 45762 (line 1592) 45763* __fractunsusqhi: Fixed-point fractional library routines. 45764 (line 1588) 45765* __fractunsusqqi: Fixed-point fractional library routines. 45766 (line 1586) 45767* __fractunsusqsi: Fixed-point fractional library routines. 45768 (line 1590) 45769* __fractunsusqti: Fixed-point fractional library routines. 45770 (line 1594) 45771* __fractunsutadi: Fixed-point fractional library routines. 45772 (line 1638) 45773* __fractunsutahi: Fixed-point fractional library routines. 45774 (line 1634) 45775* __fractunsutaqi: Fixed-point fractional library routines. 45776 (line 1632) 45777* __fractunsutasi: Fixed-point fractional library routines. 45778 (line 1636) 45779* __fractunsutati: Fixed-point fractional library routines. 45780 (line 1640) 45781* __fractuqqda: Fixed-point fractional library routines. 45782 (line 679) 45783* __fractuqqdf: Fixed-point fractional library routines. 45784 (line 702) 45785* __fractuqqdi: Fixed-point fractional library routines. 45786 (line 699) 45787* __fractuqqdq: Fixed-point fractional library routines. 45788 (line 675) 45789* __fractuqqha: Fixed-point fractional library routines. 45790 (line 677) 45791* __fractuqqhi: Fixed-point fractional library routines. 45792 (line 697) 45793* __fractuqqhq: Fixed-point fractional library routines. 45794 (line 673) 45795* __fractuqqqi: Fixed-point fractional library routines. 45796 (line 696) 45797* __fractuqqqq: Fixed-point fractional library routines. 45798 (line 672) 45799* __fractuqqsa: Fixed-point fractional library routines. 45800 (line 678) 45801* __fractuqqsf: Fixed-point fractional library routines. 45802 (line 701) 45803* __fractuqqsi: Fixed-point fractional library routines. 45804 (line 698) 45805* __fractuqqsq: Fixed-point fractional library routines. 45806 (line 674) 45807* __fractuqqta: Fixed-point fractional library routines. 45808 (line 680) 45809* __fractuqqti: Fixed-point fractional library routines. 45810 (line 700) 45811* __fractuqquda: Fixed-point fractional library routines. 45812 (line 692) 45813* __fractuqqudq2: Fixed-point fractional library routines. 45814 (line 686) 45815* __fractuqquha: Fixed-point fractional library routines. 45816 (line 688) 45817* __fractuqquhq2: Fixed-point fractional library routines. 45818 (line 682) 45819* __fractuqqusa: Fixed-point fractional library routines. 45820 (line 690) 45821* __fractuqqusq2: Fixed-point fractional library routines. 45822 (line 684) 45823* __fractuqquta: Fixed-point fractional library routines. 45824 (line 694) 45825* __fractusada: Fixed-point fractional library routines. 45826 (line 836) 45827* __fractusadf: Fixed-point fractional library routines. 45828 (line 857) 45829* __fractusadi: Fixed-point fractional library routines. 45830 (line 854) 45831* __fractusadq: Fixed-point fractional library routines. 45832 (line 833) 45833* __fractusaha: Fixed-point fractional library routines. 45834 (line 834) 45835* __fractusahi: Fixed-point fractional library routines. 45836 (line 852) 45837* __fractusahq: Fixed-point fractional library routines. 45838 (line 831) 45839* __fractusaqi: Fixed-point fractional library routines. 45840 (line 851) 45841* __fractusaqq: Fixed-point fractional library routines. 45842 (line 830) 45843* __fractusasa: Fixed-point fractional library routines. 45844 (line 835) 45845* __fractusasf: Fixed-point fractional library routines. 45846 (line 856) 45847* __fractusasi: Fixed-point fractional library routines. 45848 (line 853) 45849* __fractusasq: Fixed-point fractional library routines. 45850 (line 832) 45851* __fractusata: Fixed-point fractional library routines. 45852 (line 837) 45853* __fractusati: Fixed-point fractional library routines. 45854 (line 855) 45855* __fractusauda2: Fixed-point fractional library routines. 45856 (line 847) 45857* __fractusaudq: Fixed-point fractional library routines. 45858 (line 843) 45859* __fractusauha2: Fixed-point fractional library routines. 45860 (line 845) 45861* __fractusauhq: Fixed-point fractional library routines. 45862 (line 840) 45863* __fractusauqq: Fixed-point fractional library routines. 45864 (line 838) 45865* __fractusausq: Fixed-point fractional library routines. 45866 (line 841) 45867* __fractusauta2: Fixed-point fractional library routines. 45868 (line 849) 45869* __fractusqda: Fixed-point fractional library routines. 45870 (line 738) 45871* __fractusqdf: Fixed-point fractional library routines. 45872 (line 761) 45873* __fractusqdi: Fixed-point fractional library routines. 45874 (line 758) 45875* __fractusqdq: Fixed-point fractional library routines. 45876 (line 734) 45877* __fractusqha: Fixed-point fractional library routines. 45878 (line 736) 45879* __fractusqhi: Fixed-point fractional library routines. 45880 (line 756) 45881* __fractusqhq: Fixed-point fractional library routines. 45882 (line 732) 45883* __fractusqqi: Fixed-point fractional library routines. 45884 (line 755) 45885* __fractusqqq: Fixed-point fractional library routines. 45886 (line 731) 45887* __fractusqsa: Fixed-point fractional library routines. 45888 (line 737) 45889* __fractusqsf: Fixed-point fractional library routines. 45890 (line 760) 45891* __fractusqsi: Fixed-point fractional library routines. 45892 (line 757) 45893* __fractusqsq: Fixed-point fractional library routines. 45894 (line 733) 45895* __fractusqta: Fixed-point fractional library routines. 45896 (line 739) 45897* __fractusqti: Fixed-point fractional library routines. 45898 (line 759) 45899* __fractusquda: Fixed-point fractional library routines. 45900 (line 751) 45901* __fractusqudq2: Fixed-point fractional library routines. 45902 (line 745) 45903* __fractusquha: Fixed-point fractional library routines. 45904 (line 747) 45905* __fractusquhq2: Fixed-point fractional library routines. 45906 (line 743) 45907* __fractusquqq2: Fixed-point fractional library routines. 45908 (line 741) 45909* __fractusqusa: Fixed-point fractional library routines. 45910 (line 749) 45911* __fractusquta: Fixed-point fractional library routines. 45912 (line 753) 45913* __fractutada: Fixed-point fractional library routines. 45914 (line 899) 45915* __fractutadf: Fixed-point fractional library routines. 45916 (line 925) 45917* __fractutadi: Fixed-point fractional library routines. 45918 (line 921) 45919* __fractutadq: Fixed-point fractional library routines. 45920 (line 894) 45921* __fractutaha: Fixed-point fractional library routines. 45922 (line 896) 45923* __fractutahi: Fixed-point fractional library routines. 45924 (line 919) 45925* __fractutahq: Fixed-point fractional library routines. 45926 (line 891) 45927* __fractutaqi: Fixed-point fractional library routines. 45928 (line 917) 45929* __fractutaqq: Fixed-point fractional library routines. 45930 (line 889) 45931* __fractutasa: Fixed-point fractional library routines. 45932 (line 898) 45933* __fractutasf: Fixed-point fractional library routines. 45934 (line 924) 45935* __fractutasi: Fixed-point fractional library routines. 45936 (line 920) 45937* __fractutasq: Fixed-point fractional library routines. 45938 (line 892) 45939* __fractutata: Fixed-point fractional library routines. 45940 (line 901) 45941* __fractutati: Fixed-point fractional library routines. 45942 (line 922) 45943* __fractutauda2: Fixed-point fractional library routines. 45944 (line 915) 45945* __fractutaudq: Fixed-point fractional library routines. 45946 (line 909) 45947* __fractutauha2: Fixed-point fractional library routines. 45948 (line 911) 45949* __fractutauhq: Fixed-point fractional library routines. 45950 (line 905) 45951* __fractutauqq: Fixed-point fractional library routines. 45952 (line 903) 45953* __fractutausa2: Fixed-point fractional library routines. 45954 (line 913) 45955* __fractutausq: Fixed-point fractional library routines. 45956 (line 907) 45957* __gedf2: Soft float library routines. 45958 (line 205) 45959* __gesf2: Soft float library routines. 45960 (line 204) 45961* __getf2: Soft float library routines. 45962 (line 206) 45963* __gtdf2: Soft float library routines. 45964 (line 223) 45965* __gtsf2: Soft float library routines. 45966 (line 222) 45967* __gttf2: Soft float library routines. 45968 (line 224) 45969* __ledf2: Soft float library routines. 45970 (line 217) 45971* __lesf2: Soft float library routines. 45972 (line 216) 45973* __letf2: Soft float library routines. 45974 (line 218) 45975* __lshrdi3: Integer library routines. 45976 (line 30) 45977* __lshrsi3: Integer library routines. 45978 (line 29) 45979* __lshrti3: Integer library routines. 45980 (line 31) 45981* __lshruda3: Fixed-point fractional library routines. 45982 (line 396) 45983* __lshrudq3: Fixed-point fractional library routines. 45984 (line 390) 45985* __lshruha3: Fixed-point fractional library routines. 45986 (line 392) 45987* __lshruhq3: Fixed-point fractional library routines. 45988 (line 386) 45989* __lshruqq3: Fixed-point fractional library routines. 45990 (line 384) 45991* __lshrusa3: Fixed-point fractional library routines. 45992 (line 394) 45993* __lshrusq3: Fixed-point fractional library routines. 45994 (line 388) 45995* __lshruta3: Fixed-point fractional library routines. 45996 (line 398) 45997* __ltdf2: Soft float library routines. 45998 (line 211) 45999* __ltsf2: Soft float library routines. 46000 (line 210) 46001* __lttf2: Soft float library routines. 46002 (line 212) 46003* __main: Collect2. (line 15) 46004* __moddi3: Integer library routines. 46005 (line 36) 46006* __modsi3: Integer library routines. 46007 (line 35) 46008* __modti3: Integer library routines. 46009 (line 37) 46010* __morestack_current_segment: Miscellaneous routines. 46011 (line 45) 46012* __morestack_initial_sp: Miscellaneous routines. 46013 (line 46) 46014* __morestack_segments: Miscellaneous routines. 46015 (line 44) 46016* __mulda3: Fixed-point fractional library routines. 46017 (line 178) 46018* __muldc3: Soft float library routines. 46019 (line 239) 46020* __muldf3: Soft float library routines. 46021 (line 39) 46022* __muldi3: Integer library routines. 46023 (line 42) 46024* __muldq3: Fixed-point fractional library routines. 46025 (line 165) 46026* __mulha3: Fixed-point fractional library routines. 46027 (line 175) 46028* __mulhq3: Fixed-point fractional library routines. 46029 (line 163) 46030* __mulqq3: Fixed-point fractional library routines. 46031 (line 161) 46032* __mulsa3: Fixed-point fractional library routines. 46033 (line 177) 46034* __mulsc3: Soft float library routines. 46035 (line 237) 46036* __mulsf3: Soft float library routines. 46037 (line 38) 46038* __mulsi3: Integer library routines. 46039 (line 41) 46040* __mulsq3: Fixed-point fractional library routines. 46041 (line 164) 46042* __multa3: Fixed-point fractional library routines. 46043 (line 179) 46044* __multc3: Soft float library routines. 46045 (line 241) 46046* __multf3: Soft float library routines. 46047 (line 40) 46048* __multi3: Integer library routines. 46049 (line 43) 46050* __muluda3: Fixed-point fractional library routines. 46051 (line 185) 46052* __muludq3: Fixed-point fractional library routines. 46053 (line 173) 46054* __muluha3: Fixed-point fractional library routines. 46055 (line 181) 46056* __muluhq3: Fixed-point fractional library routines. 46057 (line 169) 46058* __muluqq3: Fixed-point fractional library routines. 46059 (line 167) 46060* __mulusa3: Fixed-point fractional library routines. 46061 (line 183) 46062* __mulusq3: Fixed-point fractional library routines. 46063 (line 171) 46064* __muluta3: Fixed-point fractional library routines. 46065 (line 187) 46066* __mulvdi3: Integer library routines. 46067 (line 114) 46068* __mulvsi3: Integer library routines. 46069 (line 113) 46070* __mulxc3: Soft float library routines. 46071 (line 243) 46072* __mulxf3: Soft float library routines. 46073 (line 42) 46074* __nedf2: Soft float library routines. 46075 (line 199) 46076* __negda2: Fixed-point fractional library routines. 46077 (line 306) 46078* __negdf2: Soft float library routines. 46079 (line 55) 46080* __negdi2: Integer library routines. 46081 (line 46) 46082* __negdq2: Fixed-point fractional library routines. 46083 (line 296) 46084* __negha2: Fixed-point fractional library routines. 46085 (line 304) 46086* __neghq2: Fixed-point fractional library routines. 46087 (line 294) 46088* __negqq2: Fixed-point fractional library routines. 46089 (line 293) 46090* __negsa2: Fixed-point fractional library routines. 46091 (line 305) 46092* __negsf2: Soft float library routines. 46093 (line 54) 46094* __negsq2: Fixed-point fractional library routines. 46095 (line 295) 46096* __negta2: Fixed-point fractional library routines. 46097 (line 307) 46098* __negtf2: Soft float library routines. 46099 (line 56) 46100* __negti2: Integer library routines. 46101 (line 47) 46102* __neguda2: Fixed-point fractional library routines. 46103 (line 311) 46104* __negudq2: Fixed-point fractional library routines. 46105 (line 302) 46106* __neguha2: Fixed-point fractional library routines. 46107 (line 308) 46108* __neguhq2: Fixed-point fractional library routines. 46109 (line 299) 46110* __neguqq2: Fixed-point fractional library routines. 46111 (line 297) 46112* __negusa2: Fixed-point fractional library routines. 46113 (line 310) 46114* __negusq2: Fixed-point fractional library routines. 46115 (line 300) 46116* __neguta2: Fixed-point fractional library routines. 46117 (line 313) 46118* __negvdi2: Integer library routines. 46119 (line 118) 46120* __negvsi2: Integer library routines. 46121 (line 117) 46122* __negxf2: Soft float library routines. 46123 (line 57) 46124* __nesf2: Soft float library routines. 46125 (line 198) 46126* __netf2: Soft float library routines. 46127 (line 200) 46128* __paritydi2: Integer library routines. 46129 (line 150) 46130* __paritysi2: Integer library routines. 46131 (line 149) 46132* __parityti2: Integer library routines. 46133 (line 151) 46134* __popcountdi2: Integer library routines. 46135 (line 156) 46136* __popcountsi2: Integer library routines. 46137 (line 155) 46138* __popcountti2: Integer library routines. 46139 (line 157) 46140* __powidf2: Soft float library routines. 46141 (line 232) 46142* __powisf2: Soft float library routines. 46143 (line 231) 46144* __powitf2: Soft float library routines. 46145 (line 233) 46146* __powixf2: Soft float library routines. 46147 (line 234) 46148* __satfractdadq: Fixed-point fractional library routines. 46149 (line 1160) 46150* __satfractdaha2: Fixed-point fractional library routines. 46151 (line 1161) 46152* __satfractdahq: Fixed-point fractional library routines. 46153 (line 1158) 46154* __satfractdaqq: Fixed-point fractional library routines. 46155 (line 1157) 46156* __satfractdasa2: Fixed-point fractional library routines. 46157 (line 1162) 46158* __satfractdasq: Fixed-point fractional library routines. 46159 (line 1159) 46160* __satfractdata2: Fixed-point fractional library routines. 46161 (line 1163) 46162* __satfractdauda: Fixed-point fractional library routines. 46163 (line 1173) 46164* __satfractdaudq: Fixed-point fractional library routines. 46165 (line 1168) 46166* __satfractdauha: Fixed-point fractional library routines. 46167 (line 1170) 46168* __satfractdauhq: Fixed-point fractional library routines. 46169 (line 1166) 46170* __satfractdauqq: Fixed-point fractional library routines. 46171 (line 1164) 46172* __satfractdausa: Fixed-point fractional library routines. 46173 (line 1172) 46174* __satfractdausq: Fixed-point fractional library routines. 46175 (line 1167) 46176* __satfractdauta: Fixed-point fractional library routines. 46177 (line 1174) 46178* __satfractdfda: Fixed-point fractional library routines. 46179 (line 1513) 46180* __satfractdfdq: Fixed-point fractional library routines. 46181 (line 1510) 46182* __satfractdfha: Fixed-point fractional library routines. 46183 (line 1511) 46184* __satfractdfhq: Fixed-point fractional library routines. 46185 (line 1508) 46186* __satfractdfqq: Fixed-point fractional library routines. 46187 (line 1507) 46188* __satfractdfsa: Fixed-point fractional library routines. 46189 (line 1512) 46190* __satfractdfsq: Fixed-point fractional library routines. 46191 (line 1509) 46192* __satfractdfta: Fixed-point fractional library routines. 46193 (line 1514) 46194* __satfractdfuda: Fixed-point fractional library routines. 46195 (line 1522) 46196* __satfractdfudq: Fixed-point fractional library routines. 46197 (line 1518) 46198* __satfractdfuha: Fixed-point fractional library routines. 46199 (line 1520) 46200* __satfractdfuhq: Fixed-point fractional library routines. 46201 (line 1516) 46202* __satfractdfuqq: Fixed-point fractional library routines. 46203 (line 1515) 46204* __satfractdfusa: Fixed-point fractional library routines. 46205 (line 1521) 46206* __satfractdfusq: Fixed-point fractional library routines. 46207 (line 1517) 46208* __satfractdfuta: Fixed-point fractional library routines. 46209 (line 1523) 46210* __satfractdida: Fixed-point fractional library routines. 46211 (line 1463) 46212* __satfractdidq: Fixed-point fractional library routines. 46213 (line 1460) 46214* __satfractdiha: Fixed-point fractional library routines. 46215 (line 1461) 46216* __satfractdihq: Fixed-point fractional library routines. 46217 (line 1458) 46218* __satfractdiqq: Fixed-point fractional library routines. 46219 (line 1457) 46220* __satfractdisa: Fixed-point fractional library routines. 46221 (line 1462) 46222* __satfractdisq: Fixed-point fractional library routines. 46223 (line 1459) 46224* __satfractdita: Fixed-point fractional library routines. 46225 (line 1464) 46226* __satfractdiuda: Fixed-point fractional library routines. 46227 (line 1471) 46228* __satfractdiudq: Fixed-point fractional library routines. 46229 (line 1468) 46230* __satfractdiuha: Fixed-point fractional library routines. 46231 (line 1469) 46232* __satfractdiuhq: Fixed-point fractional library routines. 46233 (line 1466) 46234* __satfractdiuqq: Fixed-point fractional library routines. 46235 (line 1465) 46236* __satfractdiusa: Fixed-point fractional library routines. 46237 (line 1470) 46238* __satfractdiusq: Fixed-point fractional library routines. 46239 (line 1467) 46240* __satfractdiuta: Fixed-point fractional library routines. 46241 (line 1472) 46242* __satfractdqda: Fixed-point fractional library routines. 46243 (line 1105) 46244* __satfractdqha: Fixed-point fractional library routines. 46245 (line 1103) 46246* __satfractdqhq2: Fixed-point fractional library routines. 46247 (line 1101) 46248* __satfractdqqq2: Fixed-point fractional library routines. 46249 (line 1100) 46250* __satfractdqsa: Fixed-point fractional library routines. 46251 (line 1104) 46252* __satfractdqsq2: Fixed-point fractional library routines. 46253 (line 1102) 46254* __satfractdqta: Fixed-point fractional library routines. 46255 (line 1106) 46256* __satfractdquda: Fixed-point fractional library routines. 46257 (line 1117) 46258* __satfractdqudq: Fixed-point fractional library routines. 46259 (line 1112) 46260* __satfractdquha: Fixed-point fractional library routines. 46261 (line 1114) 46262* __satfractdquhq: Fixed-point fractional library routines. 46263 (line 1109) 46264* __satfractdquqq: Fixed-point fractional library routines. 46265 (line 1107) 46266* __satfractdqusa: Fixed-point fractional library routines. 46267 (line 1116) 46268* __satfractdqusq: Fixed-point fractional library routines. 46269 (line 1110) 46270* __satfractdquta: Fixed-point fractional library routines. 46271 (line 1119) 46272* __satfracthada2: Fixed-point fractional library routines. 46273 (line 1126) 46274* __satfracthadq: Fixed-point fractional library routines. 46275 (line 1124) 46276* __satfracthahq: Fixed-point fractional library routines. 46277 (line 1122) 46278* __satfracthaqq: Fixed-point fractional library routines. 46279 (line 1121) 46280* __satfracthasa2: Fixed-point fractional library routines. 46281 (line 1125) 46282* __satfracthasq: Fixed-point fractional library routines. 46283 (line 1123) 46284* __satfracthata2: Fixed-point fractional library routines. 46285 (line 1127) 46286* __satfracthauda: Fixed-point fractional library routines. 46287 (line 1138) 46288* __satfracthaudq: Fixed-point fractional library routines. 46289 (line 1133) 46290* __satfracthauha: Fixed-point fractional library routines. 46291 (line 1135) 46292* __satfracthauhq: Fixed-point fractional library routines. 46293 (line 1130) 46294* __satfracthauqq: Fixed-point fractional library routines. 46295 (line 1128) 46296* __satfracthausa: Fixed-point fractional library routines. 46297 (line 1137) 46298* __satfracthausq: Fixed-point fractional library routines. 46299 (line 1131) 46300* __satfracthauta: Fixed-point fractional library routines. 46301 (line 1140) 46302* __satfracthida: Fixed-point fractional library routines. 46303 (line 1431) 46304* __satfracthidq: Fixed-point fractional library routines. 46305 (line 1428) 46306* __satfracthiha: Fixed-point fractional library routines. 46307 (line 1429) 46308* __satfracthihq: Fixed-point fractional library routines. 46309 (line 1426) 46310* __satfracthiqq: Fixed-point fractional library routines. 46311 (line 1425) 46312* __satfracthisa: Fixed-point fractional library routines. 46313 (line 1430) 46314* __satfracthisq: Fixed-point fractional library routines. 46315 (line 1427) 46316* __satfracthita: Fixed-point fractional library routines. 46317 (line 1432) 46318* __satfracthiuda: Fixed-point fractional library routines. 46319 (line 1439) 46320* __satfracthiudq: Fixed-point fractional library routines. 46321 (line 1436) 46322* __satfracthiuha: Fixed-point fractional library routines. 46323 (line 1437) 46324* __satfracthiuhq: Fixed-point fractional library routines. 46325 (line 1434) 46326* __satfracthiuqq: Fixed-point fractional library routines. 46327 (line 1433) 46328* __satfracthiusa: Fixed-point fractional library routines. 46329 (line 1438) 46330* __satfracthiusq: Fixed-point fractional library routines. 46331 (line 1435) 46332* __satfracthiuta: Fixed-point fractional library routines. 46333 (line 1440) 46334* __satfracthqda: Fixed-point fractional library routines. 46335 (line 1071) 46336* __satfracthqdq2: Fixed-point fractional library routines. 46337 (line 1068) 46338* __satfracthqha: Fixed-point fractional library routines. 46339 (line 1069) 46340* __satfracthqqq2: Fixed-point fractional library routines. 46341 (line 1066) 46342* __satfracthqsa: Fixed-point fractional library routines. 46343 (line 1070) 46344* __satfracthqsq2: Fixed-point fractional library routines. 46345 (line 1067) 46346* __satfracthqta: Fixed-point fractional library routines. 46347 (line 1072) 46348* __satfracthquda: Fixed-point fractional library routines. 46349 (line 1079) 46350* __satfracthqudq: Fixed-point fractional library routines. 46351 (line 1076) 46352* __satfracthquha: Fixed-point fractional library routines. 46353 (line 1077) 46354* __satfracthquhq: Fixed-point fractional library routines. 46355 (line 1074) 46356* __satfracthquqq: Fixed-point fractional library routines. 46357 (line 1073) 46358* __satfracthqusa: Fixed-point fractional library routines. 46359 (line 1078) 46360* __satfracthqusq: Fixed-point fractional library routines. 46361 (line 1075) 46362* __satfracthquta: Fixed-point fractional library routines. 46363 (line 1080) 46364* __satfractqida: Fixed-point fractional library routines. 46365 (line 1409) 46366* __satfractqidq: Fixed-point fractional library routines. 46367 (line 1406) 46368* __satfractqiha: Fixed-point fractional library routines. 46369 (line 1407) 46370* __satfractqihq: Fixed-point fractional library routines. 46371 (line 1404) 46372* __satfractqiqq: Fixed-point fractional library routines. 46373 (line 1403) 46374* __satfractqisa: Fixed-point fractional library routines. 46375 (line 1408) 46376* __satfractqisq: Fixed-point fractional library routines. 46377 (line 1405) 46378* __satfractqita: Fixed-point fractional library routines. 46379 (line 1410) 46380* __satfractqiuda: Fixed-point fractional library routines. 46381 (line 1421) 46382* __satfractqiudq: Fixed-point fractional library routines. 46383 (line 1416) 46384* __satfractqiuha: Fixed-point fractional library routines. 46385 (line 1418) 46386* __satfractqiuhq: Fixed-point fractional library routines. 46387 (line 1413) 46388* __satfractqiuqq: Fixed-point fractional library routines. 46389 (line 1411) 46390* __satfractqiusa: Fixed-point fractional library routines. 46391 (line 1420) 46392* __satfractqiusq: Fixed-point fractional library routines. 46393 (line 1414) 46394* __satfractqiuta: Fixed-point fractional library routines. 46395 (line 1423) 46396* __satfractqqda: Fixed-point fractional library routines. 46397 (line 1050) 46398* __satfractqqdq2: Fixed-point fractional library routines. 46399 (line 1047) 46400* __satfractqqha: Fixed-point fractional library routines. 46401 (line 1048) 46402* __satfractqqhq2: Fixed-point fractional library routines. 46403 (line 1045) 46404* __satfractqqsa: Fixed-point fractional library routines. 46405 (line 1049) 46406* __satfractqqsq2: Fixed-point fractional library routines. 46407 (line 1046) 46408* __satfractqqta: Fixed-point fractional library routines. 46409 (line 1051) 46410* __satfractqquda: Fixed-point fractional library routines. 46411 (line 1062) 46412* __satfractqqudq: Fixed-point fractional library routines. 46413 (line 1057) 46414* __satfractqquha: Fixed-point fractional library routines. 46415 (line 1059) 46416* __satfractqquhq: Fixed-point fractional library routines. 46417 (line 1054) 46418* __satfractqquqq: Fixed-point fractional library routines. 46419 (line 1052) 46420* __satfractqqusa: Fixed-point fractional library routines. 46421 (line 1061) 46422* __satfractqqusq: Fixed-point fractional library routines. 46423 (line 1055) 46424* __satfractqquta: Fixed-point fractional library routines. 46425 (line 1064) 46426* __satfractsada2: Fixed-point fractional library routines. 46427 (line 1147) 46428* __satfractsadq: Fixed-point fractional library routines. 46429 (line 1145) 46430* __satfractsaha2: Fixed-point fractional library routines. 46431 (line 1146) 46432* __satfractsahq: Fixed-point fractional library routines. 46433 (line 1143) 46434* __satfractsaqq: Fixed-point fractional library routines. 46435 (line 1142) 46436* __satfractsasq: Fixed-point fractional library routines. 46437 (line 1144) 46438* __satfractsata2: Fixed-point fractional library routines. 46439 (line 1148) 46440* __satfractsauda: Fixed-point fractional library routines. 46441 (line 1155) 46442* __satfractsaudq: Fixed-point fractional library routines. 46443 (line 1152) 46444* __satfractsauha: Fixed-point fractional library routines. 46445 (line 1153) 46446* __satfractsauhq: Fixed-point fractional library routines. 46447 (line 1150) 46448* __satfractsauqq: Fixed-point fractional library routines. 46449 (line 1149) 46450* __satfractsausa: Fixed-point fractional library routines. 46451 (line 1154) 46452* __satfractsausq: Fixed-point fractional library routines. 46453 (line 1151) 46454* __satfractsauta: Fixed-point fractional library routines. 46455 (line 1156) 46456* __satfractsfda: Fixed-point fractional library routines. 46457 (line 1497) 46458* __satfractsfdq: Fixed-point fractional library routines. 46459 (line 1494) 46460* __satfractsfha: Fixed-point fractional library routines. 46461 (line 1495) 46462* __satfractsfhq: Fixed-point fractional library routines. 46463 (line 1492) 46464* __satfractsfqq: Fixed-point fractional library routines. 46465 (line 1491) 46466* __satfractsfsa: Fixed-point fractional library routines. 46467 (line 1496) 46468* __satfractsfsq: Fixed-point fractional library routines. 46469 (line 1493) 46470* __satfractsfta: Fixed-point fractional library routines. 46471 (line 1498) 46472* __satfractsfuda: Fixed-point fractional library routines. 46473 (line 1505) 46474* __satfractsfudq: Fixed-point fractional library routines. 46475 (line 1502) 46476* __satfractsfuha: Fixed-point fractional library routines. 46477 (line 1503) 46478* __satfractsfuhq: Fixed-point fractional library routines. 46479 (line 1500) 46480* __satfractsfuqq: Fixed-point fractional library routines. 46481 (line 1499) 46482* __satfractsfusa: Fixed-point fractional library routines. 46483 (line 1504) 46484* __satfractsfusq: Fixed-point fractional library routines. 46485 (line 1501) 46486* __satfractsfuta: Fixed-point fractional library routines. 46487 (line 1506) 46488* __satfractsida: Fixed-point fractional library routines. 46489 (line 1447) 46490* __satfractsidq: Fixed-point fractional library routines. 46491 (line 1444) 46492* __satfractsiha: Fixed-point fractional library routines. 46493 (line 1445) 46494* __satfractsihq: Fixed-point fractional library routines. 46495 (line 1442) 46496* __satfractsiqq: Fixed-point fractional library routines. 46497 (line 1441) 46498* __satfractsisa: Fixed-point fractional library routines. 46499 (line 1446) 46500* __satfractsisq: Fixed-point fractional library routines. 46501 (line 1443) 46502* __satfractsita: Fixed-point fractional library routines. 46503 (line 1448) 46504* __satfractsiuda: Fixed-point fractional library routines. 46505 (line 1455) 46506* __satfractsiudq: Fixed-point fractional library routines. 46507 (line 1452) 46508* __satfractsiuha: Fixed-point fractional library routines. 46509 (line 1453) 46510* __satfractsiuhq: Fixed-point fractional library routines. 46511 (line 1450) 46512* __satfractsiuqq: Fixed-point fractional library routines. 46513 (line 1449) 46514* __satfractsiusa: Fixed-point fractional library routines. 46515 (line 1454) 46516* __satfractsiusq: Fixed-point fractional library routines. 46517 (line 1451) 46518* __satfractsiuta: Fixed-point fractional library routines. 46519 (line 1456) 46520* __satfractsqda: Fixed-point fractional library routines. 46521 (line 1086) 46522* __satfractsqdq2: Fixed-point fractional library routines. 46523 (line 1083) 46524* __satfractsqha: Fixed-point fractional library routines. 46525 (line 1084) 46526* __satfractsqhq2: Fixed-point fractional library routines. 46527 (line 1082) 46528* __satfractsqqq2: Fixed-point fractional library routines. 46529 (line 1081) 46530* __satfractsqsa: Fixed-point fractional library routines. 46531 (line 1085) 46532* __satfractsqta: Fixed-point fractional library routines. 46533 (line 1087) 46534* __satfractsquda: Fixed-point fractional library routines. 46535 (line 1097) 46536* __satfractsqudq: Fixed-point fractional library routines. 46537 (line 1092) 46538* __satfractsquha: Fixed-point fractional library routines. 46539 (line 1094) 46540* __satfractsquhq: Fixed-point fractional library routines. 46541 (line 1090) 46542* __satfractsquqq: Fixed-point fractional library routines. 46543 (line 1088) 46544* __satfractsqusa: Fixed-point fractional library routines. 46545 (line 1096) 46546* __satfractsqusq: Fixed-point fractional library routines. 46547 (line 1091) 46548* __satfractsquta: Fixed-point fractional library routines. 46549 (line 1098) 46550* __satfracttada2: Fixed-point fractional library routines. 46551 (line 1182) 46552* __satfracttadq: Fixed-point fractional library routines. 46553 (line 1179) 46554* __satfracttaha2: Fixed-point fractional library routines. 46555 (line 1180) 46556* __satfracttahq: Fixed-point fractional library routines. 46557 (line 1177) 46558* __satfracttaqq: Fixed-point fractional library routines. 46559 (line 1176) 46560* __satfracttasa2: Fixed-point fractional library routines. 46561 (line 1181) 46562* __satfracttasq: Fixed-point fractional library routines. 46563 (line 1178) 46564* __satfracttauda: Fixed-point fractional library routines. 46565 (line 1193) 46566* __satfracttaudq: Fixed-point fractional library routines. 46567 (line 1188) 46568* __satfracttauha: Fixed-point fractional library routines. 46569 (line 1190) 46570* __satfracttauhq: Fixed-point fractional library routines. 46571 (line 1185) 46572* __satfracttauqq: Fixed-point fractional library routines. 46573 (line 1183) 46574* __satfracttausa: Fixed-point fractional library routines. 46575 (line 1192) 46576* __satfracttausq: Fixed-point fractional library routines. 46577 (line 1186) 46578* __satfracttauta: Fixed-point fractional library routines. 46579 (line 1195) 46580* __satfracttida: Fixed-point fractional library routines. 46581 (line 1479) 46582* __satfracttidq: Fixed-point fractional library routines. 46583 (line 1476) 46584* __satfracttiha: Fixed-point fractional library routines. 46585 (line 1477) 46586* __satfracttihq: Fixed-point fractional library routines. 46587 (line 1474) 46588* __satfracttiqq: Fixed-point fractional library routines. 46589 (line 1473) 46590* __satfracttisa: Fixed-point fractional library routines. 46591 (line 1478) 46592* __satfracttisq: Fixed-point fractional library routines. 46593 (line 1475) 46594* __satfracttita: Fixed-point fractional library routines. 46595 (line 1480) 46596* __satfracttiuda: Fixed-point fractional library routines. 46597 (line 1488) 46598* __satfracttiudq: Fixed-point fractional library routines. 46599 (line 1484) 46600* __satfracttiuha: Fixed-point fractional library routines. 46601 (line 1486) 46602* __satfracttiuhq: Fixed-point fractional library routines. 46603 (line 1482) 46604* __satfracttiuqq: Fixed-point fractional library routines. 46605 (line 1481) 46606* __satfracttiusa: Fixed-point fractional library routines. 46607 (line 1487) 46608* __satfracttiusq: Fixed-point fractional library routines. 46609 (line 1483) 46610* __satfracttiuta: Fixed-point fractional library routines. 46611 (line 1489) 46612* __satfractudada: Fixed-point fractional library routines. 46613 (line 1358) 46614* __satfractudadq: Fixed-point fractional library routines. 46615 (line 1353) 46616* __satfractudaha: Fixed-point fractional library routines. 46617 (line 1355) 46618* __satfractudahq: Fixed-point fractional library routines. 46619 (line 1351) 46620* __satfractudaqq: Fixed-point fractional library routines. 46621 (line 1349) 46622* __satfractudasa: Fixed-point fractional library routines. 46623 (line 1357) 46624* __satfractudasq: Fixed-point fractional library routines. 46625 (line 1352) 46626* __satfractudata: Fixed-point fractional library routines. 46627 (line 1359) 46628* __satfractudaudq: Fixed-point fractional library routines. 46629 (line 1367) 46630* __satfractudauha2: Fixed-point fractional library routines. 46631 (line 1369) 46632* __satfractudauhq: Fixed-point fractional library routines. 46633 (line 1363) 46634* __satfractudauqq: Fixed-point fractional library routines. 46635 (line 1361) 46636* __satfractudausa2: Fixed-point fractional library routines. 46637 (line 1371) 46638* __satfractudausq: Fixed-point fractional library routines. 46639 (line 1365) 46640* __satfractudauta2: Fixed-point fractional library routines. 46641 (line 1373) 46642* __satfractudqda: Fixed-point fractional library routines. 46643 (line 1282) 46644* __satfractudqdq: Fixed-point fractional library routines. 46645 (line 1277) 46646* __satfractudqha: Fixed-point fractional library routines. 46647 (line 1279) 46648* __satfractudqhq: Fixed-point fractional library routines. 46649 (line 1274) 46650* __satfractudqqq: Fixed-point fractional library routines. 46651 (line 1272) 46652* __satfractudqsa: Fixed-point fractional library routines. 46653 (line 1281) 46654* __satfractudqsq: Fixed-point fractional library routines. 46655 (line 1275) 46656* __satfractudqta: Fixed-point fractional library routines. 46657 (line 1284) 46658* __satfractudquda: Fixed-point fractional library routines. 46659 (line 1296) 46660* __satfractudquha: Fixed-point fractional library routines. 46661 (line 1292) 46662* __satfractudquhq2: Fixed-point fractional library routines. 46663 (line 1288) 46664* __satfractudquqq2: Fixed-point fractional library routines. 46665 (line 1286) 46666* __satfractudqusa: Fixed-point fractional library routines. 46667 (line 1294) 46668* __satfractudqusq2: Fixed-point fractional library routines. 46669 (line 1290) 46670* __satfractudquta: Fixed-point fractional library routines. 46671 (line 1298) 46672* __satfractuhada: Fixed-point fractional library routines. 46673 (line 1310) 46674* __satfractuhadq: Fixed-point fractional library routines. 46675 (line 1305) 46676* __satfractuhaha: Fixed-point fractional library routines. 46677 (line 1307) 46678* __satfractuhahq: Fixed-point fractional library routines. 46679 (line 1302) 46680* __satfractuhaqq: Fixed-point fractional library routines. 46681 (line 1300) 46682* __satfractuhasa: Fixed-point fractional library routines. 46683 (line 1309) 46684* __satfractuhasq: Fixed-point fractional library routines. 46685 (line 1303) 46686* __satfractuhata: Fixed-point fractional library routines. 46687 (line 1312) 46688* __satfractuhauda2: Fixed-point fractional library routines. 46689 (line 1324) 46690* __satfractuhaudq: Fixed-point fractional library routines. 46691 (line 1320) 46692* __satfractuhauhq: Fixed-point fractional library routines. 46693 (line 1316) 46694* __satfractuhauqq: Fixed-point fractional library routines. 46695 (line 1314) 46696* __satfractuhausa2: Fixed-point fractional library routines. 46697 (line 1322) 46698* __satfractuhausq: Fixed-point fractional library routines. 46699 (line 1318) 46700* __satfractuhauta2: Fixed-point fractional library routines. 46701 (line 1326) 46702* __satfractuhqda: Fixed-point fractional library routines. 46703 (line 1231) 46704* __satfractuhqdq: Fixed-point fractional library routines. 46705 (line 1228) 46706* __satfractuhqha: Fixed-point fractional library routines. 46707 (line 1229) 46708* __satfractuhqhq: Fixed-point fractional library routines. 46709 (line 1226) 46710* __satfractuhqqq: Fixed-point fractional library routines. 46711 (line 1225) 46712* __satfractuhqsa: Fixed-point fractional library routines. 46713 (line 1230) 46714* __satfractuhqsq: Fixed-point fractional library routines. 46715 (line 1227) 46716* __satfractuhqta: Fixed-point fractional library routines. 46717 (line 1232) 46718* __satfractuhquda: Fixed-point fractional library routines. 46719 (line 1242) 46720* __satfractuhqudq2: Fixed-point fractional library routines. 46721 (line 1237) 46722* __satfractuhquha: Fixed-point fractional library routines. 46723 (line 1239) 46724* __satfractuhquqq2: Fixed-point fractional library routines. 46725 (line 1233) 46726* __satfractuhqusa: Fixed-point fractional library routines. 46727 (line 1241) 46728* __satfractuhqusq2: Fixed-point fractional library routines. 46729 (line 1235) 46730* __satfractuhquta: Fixed-point fractional library routines. 46731 (line 1244) 46732* __satfractunsdida: Fixed-point fractional library routines. 46733 (line 1841) 46734* __satfractunsdidq: Fixed-point fractional library routines. 46735 (line 1837) 46736* __satfractunsdiha: Fixed-point fractional library routines. 46737 (line 1839) 46738* __satfractunsdihq: Fixed-point fractional library routines. 46739 (line 1835) 46740* __satfractunsdiqq: Fixed-point fractional library routines. 46741 (line 1834) 46742* __satfractunsdisa: Fixed-point fractional library routines. 46743 (line 1840) 46744* __satfractunsdisq: Fixed-point fractional library routines. 46745 (line 1836) 46746* __satfractunsdita: Fixed-point fractional library routines. 46747 (line 1842) 46748* __satfractunsdiuda: Fixed-point fractional library routines. 46749 (line 1856) 46750* __satfractunsdiudq: Fixed-point fractional library routines. 46751 (line 1850) 46752* __satfractunsdiuha: Fixed-point fractional library routines. 46753 (line 1852) 46754* __satfractunsdiuhq: Fixed-point fractional library routines. 46755 (line 1846) 46756* __satfractunsdiuqq: Fixed-point fractional library routines. 46757 (line 1844) 46758* __satfractunsdiusa: Fixed-point fractional library routines. 46759 (line 1854) 46760* __satfractunsdiusq: Fixed-point fractional library routines. 46761 (line 1848) 46762* __satfractunsdiuta: Fixed-point fractional library routines. 46763 (line 1858) 46764* __satfractunshida: Fixed-point fractional library routines. 46765 (line 1793) 46766* __satfractunshidq: Fixed-point fractional library routines. 46767 (line 1789) 46768* __satfractunshiha: Fixed-point fractional library routines. 46769 (line 1791) 46770* __satfractunshihq: Fixed-point fractional library routines. 46771 (line 1787) 46772* __satfractunshiqq: Fixed-point fractional library routines. 46773 (line 1786) 46774* __satfractunshisa: Fixed-point fractional library routines. 46775 (line 1792) 46776* __satfractunshisq: Fixed-point fractional library routines. 46777 (line 1788) 46778* __satfractunshita: Fixed-point fractional library routines. 46779 (line 1794) 46780* __satfractunshiuda: Fixed-point fractional library routines. 46781 (line 1808) 46782* __satfractunshiudq: Fixed-point fractional library routines. 46783 (line 1802) 46784* __satfractunshiuha: Fixed-point fractional library routines. 46785 (line 1804) 46786* __satfractunshiuhq: Fixed-point fractional library routines. 46787 (line 1798) 46788* __satfractunshiuqq: Fixed-point fractional library routines. 46789 (line 1796) 46790* __satfractunshiusa: Fixed-point fractional library routines. 46791 (line 1806) 46792* __satfractunshiusq: Fixed-point fractional library routines. 46793 (line 1800) 46794* __satfractunshiuta: Fixed-point fractional library routines. 46795 (line 1810) 46796* __satfractunsqida: Fixed-point fractional library routines. 46797 (line 1767) 46798* __satfractunsqidq: Fixed-point fractional library routines. 46799 (line 1763) 46800* __satfractunsqiha: Fixed-point fractional library routines. 46801 (line 1765) 46802* __satfractunsqihq: Fixed-point fractional library routines. 46803 (line 1761) 46804* __satfractunsqiqq: Fixed-point fractional library routines. 46805 (line 1760) 46806* __satfractunsqisa: Fixed-point fractional library routines. 46807 (line 1766) 46808* __satfractunsqisq: Fixed-point fractional library routines. 46809 (line 1762) 46810* __satfractunsqita: Fixed-point fractional library routines. 46811 (line 1768) 46812* __satfractunsqiuda: Fixed-point fractional library routines. 46813 (line 1782) 46814* __satfractunsqiudq: Fixed-point fractional library routines. 46815 (line 1776) 46816* __satfractunsqiuha: Fixed-point fractional library routines. 46817 (line 1778) 46818* __satfractunsqiuhq: Fixed-point fractional library routines. 46819 (line 1772) 46820* __satfractunsqiuqq: Fixed-point fractional library routines. 46821 (line 1770) 46822* __satfractunsqiusa: Fixed-point fractional library routines. 46823 (line 1780) 46824* __satfractunsqiusq: Fixed-point fractional library routines. 46825 (line 1774) 46826* __satfractunsqiuta: Fixed-point fractional library routines. 46827 (line 1784) 46828* __satfractunssida: Fixed-point fractional library routines. 46829 (line 1818) 46830* __satfractunssidq: Fixed-point fractional library routines. 46831 (line 1815) 46832* __satfractunssiha: Fixed-point fractional library routines. 46833 (line 1816) 46834* __satfractunssihq: Fixed-point fractional library routines. 46835 (line 1813) 46836* __satfractunssiqq: Fixed-point fractional library routines. 46837 (line 1812) 46838* __satfractunssisa: Fixed-point fractional library routines. 46839 (line 1817) 46840* __satfractunssisq: Fixed-point fractional library routines. 46841 (line 1814) 46842* __satfractunssita: Fixed-point fractional library routines. 46843 (line 1819) 46844* __satfractunssiuda: Fixed-point fractional library routines. 46845 (line 1830) 46846* __satfractunssiudq: Fixed-point fractional library routines. 46847 (line 1825) 46848* __satfractunssiuha: Fixed-point fractional library routines. 46849 (line 1827) 46850* __satfractunssiuhq: Fixed-point fractional library routines. 46851 (line 1822) 46852* __satfractunssiuqq: Fixed-point fractional library routines. 46853 (line 1820) 46854* __satfractunssiusa: Fixed-point fractional library routines. 46855 (line 1829) 46856* __satfractunssiusq: Fixed-point fractional library routines. 46857 (line 1823) 46858* __satfractunssiuta: Fixed-point fractional library routines. 46859 (line 1832) 46860* __satfractunstida: Fixed-point fractional library routines. 46861 (line 1870) 46862* __satfractunstidq: Fixed-point fractional library routines. 46863 (line 1865) 46864* __satfractunstiha: Fixed-point fractional library routines. 46865 (line 1867) 46866* __satfractunstihq: Fixed-point fractional library routines. 46867 (line 1862) 46868* __satfractunstiqq: Fixed-point fractional library routines. 46869 (line 1860) 46870* __satfractunstisa: Fixed-point fractional library routines. 46871 (line 1869) 46872* __satfractunstisq: Fixed-point fractional library routines. 46873 (line 1863) 46874* __satfractunstita: Fixed-point fractional library routines. 46875 (line 1872) 46876* __satfractunstiuda: Fixed-point fractional library routines. 46877 (line 1886) 46878* __satfractunstiudq: Fixed-point fractional library routines. 46879 (line 1880) 46880* __satfractunstiuha: Fixed-point fractional library routines. 46881 (line 1882) 46882* __satfractunstiuhq: Fixed-point fractional library routines. 46883 (line 1876) 46884* __satfractunstiuqq: Fixed-point fractional library routines. 46885 (line 1874) 46886* __satfractunstiusa: Fixed-point fractional library routines. 46887 (line 1884) 46888* __satfractunstiusq: Fixed-point fractional library routines. 46889 (line 1878) 46890* __satfractunstiuta: Fixed-point fractional library routines. 46891 (line 1888) 46892* __satfractuqqda: Fixed-point fractional library routines. 46893 (line 1207) 46894* __satfractuqqdq: Fixed-point fractional library routines. 46895 (line 1202) 46896* __satfractuqqha: Fixed-point fractional library routines. 46897 (line 1204) 46898* __satfractuqqhq: Fixed-point fractional library routines. 46899 (line 1199) 46900* __satfractuqqqq: Fixed-point fractional library routines. 46901 (line 1197) 46902* __satfractuqqsa: Fixed-point fractional library routines. 46903 (line 1206) 46904* __satfractuqqsq: Fixed-point fractional library routines. 46905 (line 1200) 46906* __satfractuqqta: Fixed-point fractional library routines. 46907 (line 1209) 46908* __satfractuqquda: Fixed-point fractional library routines. 46909 (line 1221) 46910* __satfractuqqudq2: Fixed-point fractional library routines. 46911 (line 1215) 46912* __satfractuqquha: Fixed-point fractional library routines. 46913 (line 1217) 46914* __satfractuqquhq2: Fixed-point fractional library routines. 46915 (line 1211) 46916* __satfractuqqusa: Fixed-point fractional library routines. 46917 (line 1219) 46918* __satfractuqqusq2: Fixed-point fractional library routines. 46919 (line 1213) 46920* __satfractuqquta: Fixed-point fractional library routines. 46921 (line 1223) 46922* __satfractusada: Fixed-point fractional library routines. 46923 (line 1334) 46924* __satfractusadq: Fixed-point fractional library routines. 46925 (line 1331) 46926* __satfractusaha: Fixed-point fractional library routines. 46927 (line 1332) 46928* __satfractusahq: Fixed-point fractional library routines. 46929 (line 1329) 46930* __satfractusaqq: Fixed-point fractional library routines. 46931 (line 1328) 46932* __satfractusasa: Fixed-point fractional library routines. 46933 (line 1333) 46934* __satfractusasq: Fixed-point fractional library routines. 46935 (line 1330) 46936* __satfractusata: Fixed-point fractional library routines. 46937 (line 1335) 46938* __satfractusauda2: Fixed-point fractional library routines. 46939 (line 1345) 46940* __satfractusaudq: Fixed-point fractional library routines. 46941 (line 1341) 46942* __satfractusauha2: Fixed-point fractional library routines. 46943 (line 1343) 46944* __satfractusauhq: Fixed-point fractional library routines. 46945 (line 1338) 46946* __satfractusauqq: Fixed-point fractional library routines. 46947 (line 1336) 46948* __satfractusausq: Fixed-point fractional library routines. 46949 (line 1339) 46950* __satfractusauta2: Fixed-point fractional library routines. 46951 (line 1347) 46952* __satfractusqda: Fixed-point fractional library routines. 46953 (line 1255) 46954* __satfractusqdq: Fixed-point fractional library routines. 46955 (line 1250) 46956* __satfractusqha: Fixed-point fractional library routines. 46957 (line 1252) 46958* __satfractusqhq: Fixed-point fractional library routines. 46959 (line 1248) 46960* __satfractusqqq: Fixed-point fractional library routines. 46961 (line 1246) 46962* __satfractusqsa: Fixed-point fractional library routines. 46963 (line 1254) 46964* __satfractusqsq: Fixed-point fractional library routines. 46965 (line 1249) 46966* __satfractusqta: Fixed-point fractional library routines. 46967 (line 1256) 46968* __satfractusquda: Fixed-point fractional library routines. 46969 (line 1268) 46970* __satfractusqudq2: Fixed-point fractional library routines. 46971 (line 1262) 46972* __satfractusquha: Fixed-point fractional library routines. 46973 (line 1264) 46974* __satfractusquhq2: Fixed-point fractional library routines. 46975 (line 1260) 46976* __satfractusquqq2: Fixed-point fractional library routines. 46977 (line 1258) 46978* __satfractusqusa: Fixed-point fractional library routines. 46979 (line 1266) 46980* __satfractusquta: Fixed-point fractional library routines. 46981 (line 1270) 46982* __satfractutada: Fixed-point fractional library routines. 46983 (line 1385) 46984* __satfractutadq: Fixed-point fractional library routines. 46985 (line 1380) 46986* __satfractutaha: Fixed-point fractional library routines. 46987 (line 1382) 46988* __satfractutahq: Fixed-point fractional library routines. 46989 (line 1377) 46990* __satfractutaqq: Fixed-point fractional library routines. 46991 (line 1375) 46992* __satfractutasa: Fixed-point fractional library routines. 46993 (line 1384) 46994* __satfractutasq: Fixed-point fractional library routines. 46995 (line 1378) 46996* __satfractutata: Fixed-point fractional library routines. 46997 (line 1387) 46998* __satfractutauda2: Fixed-point fractional library routines. 46999 (line 1401) 47000* __satfractutaudq: Fixed-point fractional library routines. 47001 (line 1395) 47002* __satfractutauha2: Fixed-point fractional library routines. 47003 (line 1397) 47004* __satfractutauhq: Fixed-point fractional library routines. 47005 (line 1391) 47006* __satfractutauqq: Fixed-point fractional library routines. 47007 (line 1389) 47008* __satfractutausa2: Fixed-point fractional library routines. 47009 (line 1399) 47010* __satfractutausq: Fixed-point fractional library routines. 47011 (line 1393) 47012* __splitstack_find: Miscellaneous routines. 47013 (line 15) 47014* __ssaddda3: Fixed-point fractional library routines. 47015 (line 74) 47016* __ssadddq3: Fixed-point fractional library routines. 47017 (line 69) 47018* __ssaddha3: Fixed-point fractional library routines. 47019 (line 71) 47020* __ssaddhq3: Fixed-point fractional library routines. 47021 (line 67) 47022* __ssaddqq3: Fixed-point fractional library routines. 47023 (line 65) 47024* __ssaddsa3: Fixed-point fractional library routines. 47025 (line 73) 47026* __ssaddsq3: Fixed-point fractional library routines. 47027 (line 68) 47028* __ssaddta3: Fixed-point fractional library routines. 47029 (line 75) 47030* __ssashlda3: Fixed-point fractional library routines. 47031 (line 409) 47032* __ssashldq3: Fixed-point fractional library routines. 47033 (line 405) 47034* __ssashlha3: Fixed-point fractional library routines. 47035 (line 407) 47036* __ssashlhq3: Fixed-point fractional library routines. 47037 (line 403) 47038* __ssashlsa3: Fixed-point fractional library routines. 47039 (line 408) 47040* __ssashlsq3: Fixed-point fractional library routines. 47041 (line 404) 47042* __ssashlta3: Fixed-point fractional library routines. 47043 (line 410) 47044* __ssdivda3: Fixed-point fractional library routines. 47045 (line 268) 47046* __ssdivdq3: Fixed-point fractional library routines. 47047 (line 263) 47048* __ssdivha3: Fixed-point fractional library routines. 47049 (line 265) 47050* __ssdivhq3: Fixed-point fractional library routines. 47051 (line 261) 47052* __ssdivqq3: Fixed-point fractional library routines. 47053 (line 259) 47054* __ssdivsa3: Fixed-point fractional library routines. 47055 (line 267) 47056* __ssdivsq3: Fixed-point fractional library routines. 47057 (line 262) 47058* __ssdivta3: Fixed-point fractional library routines. 47059 (line 269) 47060* __ssmulda3: Fixed-point fractional library routines. 47061 (line 200) 47062* __ssmuldq3: Fixed-point fractional library routines. 47063 (line 195) 47064* __ssmulha3: Fixed-point fractional library routines. 47065 (line 197) 47066* __ssmulhq3: Fixed-point fractional library routines. 47067 (line 193) 47068* __ssmulqq3: Fixed-point fractional library routines. 47069 (line 191) 47070* __ssmulsa3: Fixed-point fractional library routines. 47071 (line 199) 47072* __ssmulsq3: Fixed-point fractional library routines. 47073 (line 194) 47074* __ssmulta3: Fixed-point fractional library routines. 47075 (line 201) 47076* __ssnegda2: Fixed-point fractional library routines. 47077 (line 323) 47078* __ssnegdq2: Fixed-point fractional library routines. 47079 (line 320) 47080* __ssnegha2: Fixed-point fractional library routines. 47081 (line 321) 47082* __ssneghq2: Fixed-point fractional library routines. 47083 (line 318) 47084* __ssnegqq2: Fixed-point fractional library routines. 47085 (line 317) 47086* __ssnegsa2: Fixed-point fractional library routines. 47087 (line 322) 47088* __ssnegsq2: Fixed-point fractional library routines. 47089 (line 319) 47090* __ssnegta2: Fixed-point fractional library routines. 47091 (line 324) 47092* __sssubda3: Fixed-point fractional library routines. 47093 (line 136) 47094* __sssubdq3: Fixed-point fractional library routines. 47095 (line 131) 47096* __sssubha3: Fixed-point fractional library routines. 47097 (line 133) 47098* __sssubhq3: Fixed-point fractional library routines. 47099 (line 129) 47100* __sssubqq3: Fixed-point fractional library routines. 47101 (line 127) 47102* __sssubsa3: Fixed-point fractional library routines. 47103 (line 135) 47104* __sssubsq3: Fixed-point fractional library routines. 47105 (line 130) 47106* __sssubta3: Fixed-point fractional library routines. 47107 (line 137) 47108* __subda3: Fixed-point fractional library routines. 47109 (line 114) 47110* __subdf3: Soft float library routines. 47111 (line 30) 47112* __subdq3: Fixed-point fractional library routines. 47113 (line 101) 47114* __subha3: Fixed-point fractional library routines. 47115 (line 111) 47116* __subhq3: Fixed-point fractional library routines. 47117 (line 99) 47118* __subqq3: Fixed-point fractional library routines. 47119 (line 97) 47120* __subsa3: Fixed-point fractional library routines. 47121 (line 113) 47122* __subsf3: Soft float library routines. 47123 (line 29) 47124* __subsq3: Fixed-point fractional library routines. 47125 (line 100) 47126* __subta3: Fixed-point fractional library routines. 47127 (line 115) 47128* __subtf3: Soft float library routines. 47129 (line 31) 47130* __subuda3: Fixed-point fractional library routines. 47131 (line 121) 47132* __subudq3: Fixed-point fractional library routines. 47133 (line 109) 47134* __subuha3: Fixed-point fractional library routines. 47135 (line 117) 47136* __subuhq3: Fixed-point fractional library routines. 47137 (line 105) 47138* __subuqq3: Fixed-point fractional library routines. 47139 (line 103) 47140* __subusa3: Fixed-point fractional library routines. 47141 (line 119) 47142* __subusq3: Fixed-point fractional library routines. 47143 (line 107) 47144* __subuta3: Fixed-point fractional library routines. 47145 (line 123) 47146* __subvdi3: Integer library routines. 47147 (line 122) 47148* __subvsi3: Integer library routines. 47149 (line 121) 47150* __subxf3: Soft float library routines. 47151 (line 33) 47152* __truncdfsf2: Soft float library routines. 47153 (line 75) 47154* __trunctfdf2: Soft float library routines. 47155 (line 72) 47156* __trunctfsf2: Soft float library routines. 47157 (line 74) 47158* __truncxfdf2: Soft float library routines. 47159 (line 71) 47160* __truncxfsf2: Soft float library routines. 47161 (line 73) 47162* __ucmpdi2: Integer library routines. 47163 (line 92) 47164* __ucmpti2: Integer library routines. 47165 (line 93) 47166* __udivdi3: Integer library routines. 47167 (line 52) 47168* __udivmoddi4: Integer library routines. 47169 (line 59) 47170* __udivmodti4: Integer library routines. 47171 (line 61) 47172* __udivsi3: Integer library routines. 47173 (line 50) 47174* __udivti3: Integer library routines. 47175 (line 54) 47176* __udivuda3: Fixed-point fractional library routines. 47177 (line 252) 47178* __udivudq3: Fixed-point fractional library routines. 47179 (line 246) 47180* __udivuha3: Fixed-point fractional library routines. 47181 (line 248) 47182* __udivuhq3: Fixed-point fractional library routines. 47183 (line 242) 47184* __udivuqq3: Fixed-point fractional library routines. 47185 (line 240) 47186* __udivusa3: Fixed-point fractional library routines. 47187 (line 250) 47188* __udivusq3: Fixed-point fractional library routines. 47189 (line 244) 47190* __udivuta3: Fixed-point fractional library routines. 47191 (line 254) 47192* __umoddi3: Integer library routines. 47193 (line 69) 47194* __umodsi3: Integer library routines. 47195 (line 67) 47196* __umodti3: Integer library routines. 47197 (line 71) 47198* __unorddf2: Soft float library routines. 47199 (line 172) 47200* __unordsf2: Soft float library routines. 47201 (line 171) 47202* __unordtf2: Soft float library routines. 47203 (line 173) 47204* __usadduda3: Fixed-point fractional library routines. 47205 (line 91) 47206* __usaddudq3: Fixed-point fractional library routines. 47207 (line 85) 47208* __usadduha3: Fixed-point fractional library routines. 47209 (line 87) 47210* __usadduhq3: Fixed-point fractional library routines. 47211 (line 81) 47212* __usadduqq3: Fixed-point fractional library routines. 47213 (line 79) 47214* __usaddusa3: Fixed-point fractional library routines. 47215 (line 89) 47216* __usaddusq3: Fixed-point fractional library routines. 47217 (line 83) 47218* __usadduta3: Fixed-point fractional library routines. 47219 (line 93) 47220* __usashluda3: Fixed-point fractional library routines. 47221 (line 427) 47222* __usashludq3: Fixed-point fractional library routines. 47223 (line 421) 47224* __usashluha3: Fixed-point fractional library routines. 47225 (line 423) 47226* __usashluhq3: Fixed-point fractional library routines. 47227 (line 417) 47228* __usashluqq3: Fixed-point fractional library routines. 47229 (line 415) 47230* __usashlusa3: Fixed-point fractional library routines. 47231 (line 425) 47232* __usashlusq3: Fixed-point fractional library routines. 47233 (line 419) 47234* __usashluta3: Fixed-point fractional library routines. 47235 (line 429) 47236* __usdivuda3: Fixed-point fractional library routines. 47237 (line 286) 47238* __usdivudq3: Fixed-point fractional library routines. 47239 (line 280) 47240* __usdivuha3: Fixed-point fractional library routines. 47241 (line 282) 47242* __usdivuhq3: Fixed-point fractional library routines. 47243 (line 276) 47244* __usdivuqq3: Fixed-point fractional library routines. 47245 (line 274) 47246* __usdivusa3: Fixed-point fractional library routines. 47247 (line 284) 47248* __usdivusq3: Fixed-point fractional library routines. 47249 (line 278) 47250* __usdivuta3: Fixed-point fractional library routines. 47251 (line 288) 47252* __usmuluda3: Fixed-point fractional library routines. 47253 (line 218) 47254* __usmuludq3: Fixed-point fractional library routines. 47255 (line 212) 47256* __usmuluha3: Fixed-point fractional library routines. 47257 (line 214) 47258* __usmuluhq3: Fixed-point fractional library routines. 47259 (line 208) 47260* __usmuluqq3: Fixed-point fractional library routines. 47261 (line 206) 47262* __usmulusa3: Fixed-point fractional library routines. 47263 (line 216) 47264* __usmulusq3: Fixed-point fractional library routines. 47265 (line 210) 47266* __usmuluta3: Fixed-point fractional library routines. 47267 (line 220) 47268* __usneguda2: Fixed-point fractional library routines. 47269 (line 337) 47270* __usnegudq2: Fixed-point fractional library routines. 47271 (line 332) 47272* __usneguha2: Fixed-point fractional library routines. 47273 (line 334) 47274* __usneguhq2: Fixed-point fractional library routines. 47275 (line 329) 47276* __usneguqq2: Fixed-point fractional library routines. 47277 (line 327) 47278* __usnegusa2: Fixed-point fractional library routines. 47279 (line 336) 47280* __usnegusq2: Fixed-point fractional library routines. 47281 (line 330) 47282* __usneguta2: Fixed-point fractional library routines. 47283 (line 339) 47284* __ussubuda3: Fixed-point fractional library routines. 47285 (line 154) 47286* __ussubudq3: Fixed-point fractional library routines. 47287 (line 148) 47288* __ussubuha3: Fixed-point fractional library routines. 47289 (line 150) 47290* __ussubuhq3: Fixed-point fractional library routines. 47291 (line 144) 47292* __ussubuqq3: Fixed-point fractional library routines. 47293 (line 142) 47294* __ussubusa3: Fixed-point fractional library routines. 47295 (line 152) 47296* __ussubusq3: Fixed-point fractional library routines. 47297 (line 146) 47298* __ussubuta3: Fixed-point fractional library routines. 47299 (line 156) 47300* abort: Portability. (line 20) 47301* abs: Arithmetic. (line 200) 47302* abs and attributes: Expressions. (line 83) 47303* absence_set: Processor pipeline description. 47304 (line 223) 47305* absM2 instruction pattern: Standard Names. (line 610) 47306* absolute value: Arithmetic. (line 200) 47307* ABS_EXPR: Unary and Binary Expressions. 47308 (line 6) 47309* access to operands: Accessors. (line 6) 47310* access to special operands: Special Accessors. (line 6) 47311* accessors: Accessors. (line 6) 47312* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 48) 47313* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 133) 47314* ACCUM_TYPE_SIZE: Type Layout. (line 87) 47315* acosM2 instruction pattern: Standard Names. (line 697) 47316* ADA_LONG_TYPE_SIZE: Type Layout. (line 25) 47317* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code. 47318 (line 6) 47319* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 14) 47320* addM3 instruction pattern: Standard Names. (line 295) 47321* addMODEcc instruction pattern: Standard Names. (line 1266) 47322* addptrM3 instruction pattern: Standard Names. (line 328) 47323* address constraints: Simple Constraints. (line 162) 47324* addressing modes: Addressing Modes. (line 6) 47325* address_operand: Machine-Independent Predicates. 47326 (line 62) 47327* address_operand <1>: Simple Constraints. (line 166) 47328* addr_diff_vec: Side Effects. (line 314) 47329* addr_diff_vec, length of: Insn Lengths. (line 26) 47330* ADDR_EXPR: Storage References. (line 6) 47331* addr_vec: Side Effects. (line 309) 47332* addr_vec, length of: Insn Lengths. (line 26) 47333* addvM4 instruction pattern: Standard Names. (line 311) 47334* ADJUST_FIELD_ALIGN: Storage Layout. (line 195) 47335* ADJUST_INSN_LENGTH: Insn Lengths. (line 41) 47336* ADJUST_REG_ALLOC_ORDER: Allocation Order. (line 22) 47337* aggregates as return values: Aggregate Return. (line 6) 47338* alias: Alias analysis. (line 6) 47339* allocate_stack instruction pattern: Standard Names. (line 1594) 47340* ALL_REGS: Register Classes. (line 17) 47341* alternate entry points: Insns. (line 146) 47342* anchored addresses: Anchored Addresses. (line 6) 47343* and: Arithmetic. (line 158) 47344* and and attributes: Expressions. (line 50) 47345* and, canonicalization of: Insn Canonicalizations. 47346 (line 51) 47347* andM3 instruction pattern: Standard Names. (line 301) 47348* ANNOTATE_EXPR: Unary and Binary Expressions. 47349 (line 6) 47350* annotations: Annotations. (line 6) 47351* APPLY_RESULT_SIZE: Scalar Return. (line 112) 47352* ARGS_GROW_DOWNWARD: Frame Layout. (line 30) 47353* argument passing: Interface. (line 36) 47354* arguments in registers: Register Arguments. (line 6) 47355* arguments on stack: Stack Arguments. (line 6) 47356* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 190) 47357* ARG_POINTER_REGNUM: Frame Registers. (line 40) 47358* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 47359* arg_pointer_rtx: Frame Registers. (line 104) 47360* arithmetic library: Soft float library routines. 47361 (line 6) 47362* arithmetic shift: Arithmetic. (line 173) 47363* arithmetic shift with signed saturation: Arithmetic. (line 173) 47364* arithmetic shift with unsigned saturation: Arithmetic. (line 173) 47365* arithmetic, in RTL: Arithmetic. (line 6) 47366* ARITHMETIC_TYPE_P: Types for C++. (line 59) 47367* array: Types. (line 6) 47368* ARRAY_RANGE_REF: Storage References. (line 6) 47369* ARRAY_REF: Storage References. (line 6) 47370* ARRAY_TYPE: Types. (line 6) 47371* ashift: Arithmetic. (line 173) 47372* ashift and attributes: Expressions. (line 83) 47373* ashiftrt: Arithmetic. (line 190) 47374* ashiftrt and attributes: Expressions. (line 83) 47375* ashlM3 instruction pattern: Standard Names. (line 579) 47376* ashrM3 instruction pattern: Standard Names. (line 591) 47377* asinM2 instruction pattern: Standard Names. (line 691) 47378* ASM_APP_OFF: File Framework. (line 76) 47379* ASM_APP_ON: File Framework. (line 69) 47380* ASM_COMMENT_START: File Framework. (line 64) 47381* ASM_DECLARE_COLD_FUNCTION_NAME: Label Output. (line 136) 47382* ASM_DECLARE_COLD_FUNCTION_SIZE: Label Output. (line 151) 47383* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 108) 47384* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 123) 47385* ASM_DECLARE_OBJECT_NAME: Label Output. (line 164) 47386* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 192) 47387* ASM_FINAL_SPEC: Driver. (line 81) 47388* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 200) 47389* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 426) 47390* asm_fprintf: Instruction Output. (line 150) 47391* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 160) 47392* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 410) 47393* asm_input: Side Effects. (line 296) 47394* asm_input and /v: Flags. (line 76) 47395* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 80) 47396* asm_noperands: Insns. (line 304) 47397* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 78) 47398* asm_operands and /v: Flags. (line 76) 47399* asm_operands, RTL sharing: Sharing. (line 45) 47400* asm_operands, usage: Assembler. (line 6) 47401* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 8) 47402* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 25) 47403* ASM_OUTPUT_ALIGN: Alignment Output. (line 85) 47404* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 45) 47405* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 29) 47406* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 36) 47407* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 89) 47408* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 82) 47409* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 90) 47410* ASM_OUTPUT_ASCII: Data Output. (line 54) 47411* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 50) 47412* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 37) 47413* ASM_OUTPUT_COMMON: Uninitialized Data. (line 9) 47414* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 398) 47415* ASM_OUTPUT_DEF: Label Output. (line 447) 47416* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 454) 47417* ASM_OUTPUT_DWARF_DATAREL: SDB and DWARF. (line 97) 47418* ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 77) 47419* ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 86) 47420* ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 92) 47421* ASM_OUTPUT_DWARF_TABLE_REF: SDB and DWARF. (line 102) 47422* ASM_OUTPUT_DWARF_VMS_DELTA: SDB and DWARF. (line 81) 47423* ASM_OUTPUT_EXTERNAL: Label Output. (line 327) 47424* ASM_OUTPUT_FDESC: Data Output. (line 63) 47425* ASM_OUTPUT_FUNCTION_LABEL: Label Output. (line 16) 47426* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 27) 47427* ASM_OUTPUT_LABEL: Label Output. (line 8) 47428* ASM_OUTPUT_LABELREF: Label Output. (line 349) 47429* ASM_OUTPUT_LABEL_REF: Label Output. (line 371) 47430* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 69) 47431* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 94) 47432* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 51) 47433* ASM_OUTPUT_OPCODE: Instruction Output. (line 35) 47434* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 112) 47435* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 76) 47436* ASM_OUTPUT_REG_POP: Instruction Output. (line 206) 47437* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 201) 47438* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 45) 47439* ASM_OUTPUT_SKIP: Alignment Output. (line 72) 47440* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 83) 47441* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 87) 47442* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 364) 47443* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 98) 47444* ASM_OUTPUT_WEAKREF: Label Output. (line 259) 47445* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 473) 47446* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 66) 47447* ASM_SPEC: Driver. (line 73) 47448* ASM_STABD_OP: DBX Options. (line 34) 47449* ASM_STABN_OP: DBX Options. (line 41) 47450* ASM_STABS_OP: DBX Options. (line 28) 47451* ASM_WEAKEN_DECL: Label Output. (line 251) 47452* ASM_WEAKEN_LABEL: Label Output. (line 238) 47453* assembler format: File Framework. (line 6) 47454* assembler instructions in RTL: Assembler. (line 6) 47455* ASSEMBLER_DIALECT: Instruction Output. (line 172) 47456* assemble_name: Label Output. (line 8) 47457* assemble_name_raw: Label Output. (line 27) 47458* assigning attribute values to insns: Tagging Insns. (line 6) 47459* ASSUME_EXTENDED_UNWIND_CONTEXT: Frame Registers. (line 165) 47460* asterisk in template: Output Statement. (line 29) 47461* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 88) 47462* atan2M3 instruction pattern: Standard Names. (line 792) 47463* atanM2 instruction pattern: Standard Names. (line 703) 47464* atomic: GTY Options. (line 195) 47465* atomic_addMODE instruction pattern: Standard Names. (line 1996) 47466* atomic_add_fetchMODE instruction pattern: Standard Names. (line 2025) 47467* atomic_andMODE instruction pattern: Standard Names. (line 1996) 47468* atomic_and_fetchMODE instruction pattern: Standard Names. (line 2025) 47469* atomic_compare_and_swapMODE instruction pattern: Standard Names. 47470 (line 1932) 47471* atomic_exchangeMODE instruction pattern: Standard Names. (line 1984) 47472* atomic_fetch_addMODE instruction pattern: Standard Names. (line 2010) 47473* atomic_fetch_andMODE instruction pattern: Standard Names. (line 2010) 47474* atomic_fetch_nandMODE instruction pattern: Standard Names. (line 2010) 47475* atomic_fetch_orMODE instruction pattern: Standard Names. (line 2010) 47476* atomic_fetch_subMODE instruction pattern: Standard Names. (line 2010) 47477* atomic_fetch_xorMODE instruction pattern: Standard Names. (line 2010) 47478* atomic_loadMODE instruction pattern: Standard Names. (line 1963) 47479* atomic_nandMODE instruction pattern: Standard Names. (line 1996) 47480* atomic_nand_fetchMODE instruction pattern: Standard Names. (line 2025) 47481* atomic_orMODE instruction pattern: Standard Names. (line 1996) 47482* atomic_or_fetchMODE instruction pattern: Standard Names. (line 2025) 47483* atomic_storeMODE instruction pattern: Standard Names. (line 1973) 47484* atomic_subMODE instruction pattern: Standard Names. (line 1996) 47485* atomic_sub_fetchMODE instruction pattern: Standard Names. (line 2025) 47486* atomic_test_and_set instruction pattern: Standard Names. (line 2042) 47487* atomic_xorMODE instruction pattern: Standard Names. (line 1996) 47488* atomic_xor_fetchMODE instruction pattern: Standard Names. (line 2025) 47489* attr: Expressions. (line 163) 47490* attr <1>: Tagging Insns. (line 54) 47491* attribute expressions: Expressions. (line 6) 47492* attribute specifications: Attr Example. (line 6) 47493* attribute specifications example: Attr Example. (line 6) 47494* attributes: Attributes. (line 6) 47495* attributes, defining: Defining Attributes. 47496 (line 6) 47497* attributes, target-specific: Target Attributes. (line 6) 47498* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 177) 47499* attr_flag: Expressions. (line 138) 47500* autoincrement addressing, availability: Portability. (line 20) 47501* autoincrement/decrement addressing: Simple Constraints. (line 30) 47502* automata_option: Processor pipeline description. 47503 (line 304) 47504* automaton based pipeline description: Processor pipeline description. 47505 (line 6) 47506* automaton based pipeline description <1>: Processor pipeline description. 47507 (line 49) 47508* automaton based scheduler: Processor pipeline description. 47509 (line 6) 47510* AVOID_CCMODE_COPIES: Values in Registers. 47511 (line 150) 47512* backslash: Output Template. (line 46) 47513* barrier: Insns. (line 176) 47514* barrier and /f: Flags. (line 107) 47515* barrier and /v: Flags. (line 44) 47516* BASE_REG_CLASS: Register Classes. (line 111) 47517* basic block: Basic Blocks. (line 6) 47518* Basic Statements: Basic Statements. (line 6) 47519* basic-block.h: Control Flow. (line 6) 47520* basic_block: Basic Blocks. (line 6) 47521* BASIC_BLOCK: Basic Blocks. (line 14) 47522* BB_HEAD, BB_END: Maintaining the CFG. 47523 (line 76) 47524* bb_seq: GIMPLE sequences. (line 72) 47525* BIGGEST_ALIGNMENT: Storage Layout. (line 162) 47526* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 188) 47527* BImode: Machine Modes. (line 22) 47528* BIND_EXPR: Unary and Binary Expressions. 47529 (line 6) 47530* BINFO_TYPE: Classes. (line 6) 47531* bit-fields: Bit-Fields. (line 6) 47532* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 398) 47533* BITS_BIG_ENDIAN: Storage Layout. (line 11) 47534* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 47535* BITS_PER_UNIT: Machine Modes. (line 354) 47536* BITS_PER_WORD: Storage Layout. (line 50) 47537* bitwise complement: Arithmetic. (line 154) 47538* bitwise exclusive-or: Arithmetic. (line 168) 47539* bitwise inclusive-or: Arithmetic. (line 163) 47540* bitwise logical-and: Arithmetic. (line 158) 47541* BIT_AND_EXPR: Unary and Binary Expressions. 47542 (line 6) 47543* BIT_IOR_EXPR: Unary and Binary Expressions. 47544 (line 6) 47545* BIT_NOT_EXPR: Unary and Binary Expressions. 47546 (line 6) 47547* BIT_XOR_EXPR: Unary and Binary Expressions. 47548 (line 6) 47549* BLKmode: Machine Modes. (line 185) 47550* BLKmode, and function return values: Calls. (line 23) 47551* blockage instruction pattern: Standard Names. (line 1795) 47552* Blocks: Blocks. (line 6) 47553* BLOCK_FOR_INSN, gimple_bb: Maintaining the CFG. 47554 (line 28) 47555* BLOCK_REG_PADDING: Register Arguments. (line 242) 47556* BND32mode: Machine Modes. (line 209) 47557* BND64mode: Machine Modes. (line 209) 47558* bool: Misc. (line 994) 47559* BOOLEAN_TYPE: Types. (line 6) 47560* BOOL_TYPE_SIZE: Type Layout. (line 43) 47561* branch prediction: Profile information. 47562 (line 24) 47563* BRANCH_COST: Costs. (line 104) 47564* break_out_memory_refs: Addressing Modes. (line 134) 47565* BREAK_STMT: Statements for C++. (line 6) 47566* BSS_SECTION_ASM_OP: Sections. (line 67) 47567* bswap: Arithmetic. (line 246) 47568* bswapM2 instruction pattern: Standard Names. (line 599) 47569* btruncM2 instruction pattern: Standard Names. (line 807) 47570* build0: Macros and Functions. 47571 (line 16) 47572* build1: Macros and Functions. 47573 (line 17) 47574* build2: Macros and Functions. 47575 (line 18) 47576* build3: Macros and Functions. 47577 (line 19) 47578* build4: Macros and Functions. 47579 (line 20) 47580* build5: Macros and Functions. 47581 (line 21) 47582* build6: Macros and Functions. 47583 (line 22) 47584* builtin_longjmp instruction pattern: Standard Names. (line 1692) 47585* builtin_setjmp_receiver instruction pattern: Standard Names. 47586 (line 1682) 47587* builtin_setjmp_setup instruction pattern: Standard Names. (line 1671) 47588* BYTES_BIG_ENDIAN: Storage Layout. (line 23) 47589* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 219) 47590* byte_mode: Machine Modes. (line 367) 47591* C statements for assembler output: Output Statement. (line 6) 47592* cache: GTY Options. (line 125) 47593* call: Flags. (line 221) 47594* call <1>: Side Effects. (line 92) 47595* call instruction pattern: Standard Names. (line 1337) 47596* call usage: Calls. (line 10) 47597* call, in call_insn: Flags. (line 33) 47598* call, in mem: Flags. (line 81) 47599* call-clobbered register: Register Basics. (line 35) 47600* call-clobbered register <1>: Register Basics. (line 46) 47601* call-clobbered register <2>: Register Basics. (line 53) 47602* call-saved register: Register Basics. (line 35) 47603* call-saved register <1>: Register Basics. (line 46) 47604* call-saved register <2>: Register Basics. (line 53) 47605* call-used register: Register Basics. (line 35) 47606* call-used register <1>: Register Basics. (line 46) 47607* call-used register <2>: Register Basics. (line 53) 47608* calling conventions: Stack and Calling. (line 6) 47609* calling functions in RTL: Calls. (line 6) 47610* CALL_EXPR: Unary and Binary Expressions. 47611 (line 6) 47612* call_insn: Insns. (line 95) 47613* call_insn and /c: Flags. (line 33) 47614* call_insn and /f: Flags. (line 107) 47615* call_insn and /i: Flags. (line 24) 47616* call_insn and /j: Flags. (line 161) 47617* call_insn and /s: Flags. (line 49) 47618* call_insn and /s <1>: Flags. (line 148) 47619* call_insn and /u: Flags. (line 19) 47620* call_insn and /u <1>: Flags. (line 39) 47621* call_insn and /u or /i: Flags. (line 29) 47622* call_insn and /v: Flags. (line 44) 47623* CALL_INSN_FUNCTION_USAGE: Insns. (line 101) 47624* call_pop instruction pattern: Standard Names. (line 1365) 47625* CALL_POPS_ARGS: Stack Arguments. (line 138) 47626* CALL_REALLY_USED_REGISTERS: Register Basics. (line 45) 47627* CALL_USED_REGISTERS: Register Basics. (line 34) 47628* call_used_regs: Register Basics. (line 59) 47629* call_value instruction pattern: Standard Names. (line 1357) 47630* call_value_pop instruction pattern: Standard Names. (line 1365) 47631* canadian: Configure Terms. (line 6) 47632* CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 533) 47633* CANNOT_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory. 47634 (line 276) 47635* canonicalization of instructions: Insn Canonicalizations. 47636 (line 6) 47637* canonicalize_funcptr_for_compare instruction pattern: Standard Names. 47638 (line 1526) 47639* can_create_pseudo_p: Standard Names. (line 75) 47640* can_fallthru: Basic Blocks. (line 67) 47641* caret: Multi-Alternative. (line 53) 47642* casesi instruction pattern: Standard Names. (line 1458) 47643* CASE_VECTOR_MODE: Misc. (line 26) 47644* CASE_VECTOR_PC_RELATIVE: Misc. (line 39) 47645* CASE_VECTOR_SHORTEN_MODE: Misc. (line 30) 47646* cbranchMODE4 instruction pattern: Standard Names. (line 1326) 47647* cc0: Regs and Memory. (line 303) 47648* cc0 <1>: CC0 Condition Codes. 47649 (line 6) 47650* cc0, RTL sharing: Sharing. (line 27) 47651* cc0_rtx: Regs and Memory. (line 329) 47652* CC1PLUS_SPEC: Driver. (line 63) 47653* CC1_SPEC: Driver. (line 55) 47654* CCmode: Machine Modes. (line 178) 47655* CCmode <1>: MODE_CC Condition Codes. 47656 (line 6) 47657* cc_status: CC0 Condition Codes. 47658 (line 6) 47659* CC_STATUS_MDEP: CC0 Condition Codes. 47660 (line 16) 47661* CC_STATUS_MDEP_INIT: CC0 Condition Codes. 47662 (line 22) 47663* CDImode: Machine Modes. (line 204) 47664* ceilM2 instruction pattern: Standard Names. (line 822) 47665* CEIL_DIV_EXPR: Unary and Binary Expressions. 47666 (line 6) 47667* CEIL_MOD_EXPR: Unary and Binary Expressions. 47668 (line 6) 47669* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 222) 47670* CFG verification: Maintaining the CFG. 47671 (line 117) 47672* CFG, Control Flow Graph: Control Flow. (line 6) 47673* cfghooks.h: Maintaining the CFG. 47674 (line 6) 47675* cgraph_finalize_function: Parsing pass. (line 51) 47676* chain_circular: GTY Options. (line 158) 47677* chain_next: GTY Options. (line 158) 47678* chain_prev: GTY Options. (line 158) 47679* change_address: Standard Names. (line 47) 47680* CHAR_TYPE_SIZE: Type Layout. (line 38) 47681* check_stack instruction pattern: Standard Names. (line 1612) 47682* CHImode: Machine Modes. (line 204) 47683* CILK_PLUS: Cilk Plus Transformation. 47684 (line 6) 47685* class definitions, register: Register Classes. (line 6) 47686* class preference constraints: Class Preferences. (line 6) 47687* class, scope: Classes. (line 6) 47688* classes of RTX codes: RTL Classes. (line 6) 47689* CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 47690* CLASSTYPE_HAS_MUTABLE: Classes. (line 85) 47691* CLASSTYPE_NON_POD_P: Classes. (line 90) 47692* CLASS_MAX_NREGS: Register Classes. (line 521) 47693* CLASS_TYPE_P: Types for C++. (line 63) 47694* Cleanups: Cleanups. (line 6) 47695* CLEANUP_DECL: Statements for C++. (line 6) 47696* CLEANUP_EXPR: Statements for C++. (line 6) 47697* CLEANUP_POINT_EXPR: Unary and Binary Expressions. 47698 (line 6) 47699* CLEANUP_STMT: Statements for C++. (line 6) 47700* clear_cache instruction pattern: Standard Names. (line 2102) 47701* CLEAR_INSN_CACHE: Trampolines. (line 98) 47702* CLEAR_RATIO: Costs. (line 204) 47703* clobber: Side Effects. (line 106) 47704* clrsb: Arithmetic. (line 215) 47705* clrsbM2 instruction pattern: Standard Names. (line 885) 47706* clz: Arithmetic. (line 222) 47707* clzM2 instruction pattern: Standard Names. (line 901) 47708* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 304) 47709* cmpmemM instruction pattern: Standard Names. (line 1066) 47710* cmpstrM instruction pattern: Standard Names. (line 1045) 47711* cmpstrnM instruction pattern: Standard Names. (line 1032) 47712* code generation RTL sequences: Expander Definitions. 47713 (line 6) 47714* code iterators in .md files: Code Iterators. (line 6) 47715* codes, RTL expression: RTL Objects. (line 47) 47716* code_label: Insns. (line 125) 47717* CODE_LABEL: Basic Blocks. (line 50) 47718* code_label and /i: Flags. (line 59) 47719* code_label and /v: Flags. (line 44) 47720* CODE_LABEL_NUMBER: Insns. (line 125) 47721* COImode: Machine Modes. (line 204) 47722* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 47723* COLLECT_EXPORT_LIST: Misc. (line 867) 47724* COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 47725 (line 43) 47726* COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 47727 (line 32) 47728* commit_edge_insertions: Maintaining the CFG. 47729 (line 105) 47730* compare: Arithmetic. (line 46) 47731* compare, canonicalization of: Insn Canonicalizations. 47732 (line 36) 47733* comparison_operator: Machine-Independent Predicates. 47734 (line 110) 47735* compiler passes and files: Passes. (line 6) 47736* complement, bitwise: Arithmetic. (line 154) 47737* COMPLEX_CST: Constant expressions. 47738 (line 6) 47739* COMPLEX_EXPR: Unary and Binary Expressions. 47740 (line 6) 47741* COMPLEX_TYPE: Types. (line 6) 47742* COMPONENT_REF: Storage References. (line 6) 47743* Compound Expressions: Compound Expressions. 47744 (line 6) 47745* Compound Lvalues: Compound Lvalues. (line 6) 47746* COMPOUND_EXPR: Unary and Binary Expressions. 47747 (line 6) 47748* COMPOUND_LITERAL_EXPR: Unary and Binary Expressions. 47749 (line 6) 47750* COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions. 47751 (line 377) 47752* COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions. 47753 (line 377) 47754* computed jump: Edges. (line 127) 47755* computing the length of an insn: Insn Lengths. (line 6) 47756* concat: Regs and Memory. (line 381) 47757* concatn: Regs and Memory. (line 387) 47758* cond: Comparisons. (line 90) 47759* cond and attributes: Expressions. (line 37) 47760* condition code register: Regs and Memory. (line 303) 47761* condition code status: Condition Code. (line 6) 47762* condition codes: Comparisons. (line 20) 47763* conditional execution: Conditional Execution. 47764 (line 6) 47765* Conditional Expressions: Conditional Expressions. 47766 (line 6) 47767* conditions, in patterns: Patterns. (line 43) 47768* cond_exec: Side Effects. (line 254) 47769* COND_EXPR: Unary and Binary Expressions. 47770 (line 6) 47771* configuration file: Filesystem. (line 6) 47772* configuration file <1>: Host Misc. (line 6) 47773* configure terms: Configure Terms. (line 6) 47774* CONJ_EXPR: Unary and Binary Expressions. 47775 (line 6) 47776* const: Constants. (line 140) 47777* const0_rtx: Constants. (line 21) 47778* CONST0_RTX: Constants. (line 160) 47779* const1_rtx: Constants. (line 21) 47780* CONST1_RTX: Constants. (line 160) 47781* const2_rtx: Constants. (line 21) 47782* CONST2_RTX: Constants. (line 160) 47783* constant attributes: Constant Attributes. 47784 (line 6) 47785* constant definitions: Constant Definitions. 47786 (line 6) 47787* constants in constraints: Simple Constraints. (line 68) 47788* CONSTANT_ADDRESS_P: Addressing Modes. (line 28) 47789* CONSTANT_ALIGNMENT: Storage Layout. (line 241) 47790* CONSTANT_P: Addressing Modes. (line 35) 47791* CONSTANT_POOL_ADDRESS_P: Flags. (line 10) 47792* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 68) 47793* constm1_rtx: Constants. (line 21) 47794* constraint modifier characters: Modifiers. (line 6) 47795* constraint, matching: Simple Constraints. (line 140) 47796* constraints: Constraints. (line 6) 47797* constraints, defining: Define Constraints. (line 6) 47798* constraints, machine specific: Machine Constraints. 47799 (line 6) 47800* constraints, testing: C Constraint Interface. 47801 (line 6) 47802* constraint_num: C Constraint Interface. 47803 (line 30) 47804* constraint_satisfied_p: C Constraint Interface. 47805 (line 42) 47806* CONSTRUCTOR: Unary and Binary Expressions. 47807 (line 6) 47808* constructors, automatic calls: Collect2. (line 15) 47809* constructors, output of: Initialization. (line 6) 47810* CONST_DECL: Declarations. (line 6) 47811* const_double: Constants. (line 37) 47812* const_double, RTL sharing: Sharing. (line 29) 47813* CONST_DOUBLE_LOW: Constants. (line 54) 47814* const_double_operand: Machine-Independent Predicates. 47815 (line 20) 47816* const_fixed: Constants. (line 93) 47817* const_int: Constants. (line 8) 47818* const_int and attribute tests: Expressions. (line 47) 47819* const_int and attributes: Expressions. (line 10) 47820* const_int, RTL sharing: Sharing. (line 23) 47821* const_int_operand: Machine-Independent Predicates. 47822 (line 15) 47823* const_string: Constants. (line 112) 47824* const_string and attributes: Expressions. (line 20) 47825* const_true_rtx: Constants. (line 31) 47826* const_vector: Constants. (line 100) 47827* const_vector, RTL sharing: Sharing. (line 32) 47828* CONST_WIDE_INT: Constants. (line 67) 47829* CONST_WIDE_INT_ELT: Constants. (line 89) 47830* CONST_WIDE_INT_NUNITS: Constants. (line 84) 47831* CONST_WIDE_INT_VEC: Constants. (line 80) 47832* container: Containers. (line 6) 47833* CONTINUE_STMT: Statements for C++. (line 6) 47834* contributors: Contributors. (line 6) 47835* controlling register usage: Register Basics. (line 73) 47836* controlling the compilation driver: Driver. (line 6) 47837* conventions, run-time: Interface. (line 6) 47838* conversions: Conversions. (line 6) 47839* CONVERT_EXPR: Unary and Binary Expressions. 47840 (line 6) 47841* copysignM3 instruction pattern: Standard Names. (line 865) 47842* copy_rtx: Addressing Modes. (line 189) 47843* copy_rtx_if_shared: Sharing. (line 64) 47844* cosM2 instruction pattern: Standard Names. (line 662) 47845* costs of instructions: Costs. (line 6) 47846* CPLUSPLUS_CPP_SPEC: Driver. (line 50) 47847* CPP_SPEC: Driver. (line 43) 47848* CP_INTEGRAL_TYPE: Types for C++. (line 55) 47849* cp_namespace_decls: Namespaces. (line 49) 47850* CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33) 47851* CP_TYPE_CONST_P: Types for C++. (line 24) 47852* cp_type_quals: Types for C++. (line 6) 47853* cp_type_quals <1>: Types for C++. (line 16) 47854* CP_TYPE_RESTRICT_P: Types for C++. (line 30) 47855* CP_TYPE_VOLATILE_P: Types for C++. (line 27) 47856* CQImode: Machine Modes. (line 204) 47857* cross compilation and floating point: Floating Point. (line 6) 47858* crtl->args.pops_args: Function Entry. (line 104) 47859* crtl->args.pretend_args_size: Function Entry. (line 110) 47860* crtl->outgoing_args_size: Stack Arguments. (line 48) 47861* CRTSTUFF_T_CFLAGS: Target Fragment. (line 15) 47862* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 19) 47863* CRT_CALL_STATIC_FUNCTION: Sections. (line 120) 47864* CSImode: Machine Modes. (line 204) 47865* cstoreMODE4 instruction pattern: Standard Names. (line 1287) 47866* CTImode: Machine Modes. (line 204) 47867* ctrapMM4 instruction pattern: Standard Names. (line 1764) 47868* ctz: Arithmetic. (line 230) 47869* ctzM2 instruction pattern: Standard Names. (line 916) 47870* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 305) 47871* CUMULATIVE_ARGS: Register Arguments. (line 140) 47872* current_function_is_leaf: Leaf Functions. (line 50) 47873* current_function_uses_only_leaf_regs: Leaf Functions. (line 50) 47874* current_insn_predicate: Conditional Execution. 47875 (line 27) 47876* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 136) 47877* c_register_pragma: Misc. (line 407) 47878* c_register_pragma_with_expansion: Misc. (line 409) 47879* DAmode: Machine Modes. (line 154) 47880* data bypass: Processor pipeline description. 47881 (line 105) 47882* data bypass <1>: Processor pipeline description. 47883 (line 196) 47884* data dependence delays: Processor pipeline description. 47885 (line 6) 47886* Data Dependency Analysis: Dependency analysis. 47887 (line 6) 47888* data structures: Per-Function Data. (line 6) 47889* DATA_ABI_ALIGNMENT: Storage Layout. (line 233) 47890* DATA_ALIGNMENT: Storage Layout. (line 220) 47891* DATA_SECTION_ASM_OP: Sections. (line 52) 47892* DBR_OUTPUT_SEQEND: Instruction Output. (line 133) 47893* dbr_sequence_length: Instruction Output. (line 133) 47894* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 100) 47895* DBX_CONTIN_CHAR: DBX Options. (line 63) 47896* DBX_CONTIN_LENGTH: DBX Options. (line 53) 47897* DBX_DEBUGGING_INFO: DBX Options. (line 8) 47898* DBX_FUNCTION_FIRST: DBX Options. (line 94) 47899* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 106) 47900* DBX_NO_XREFS: DBX Options. (line 47) 47901* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 8) 47902* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 33) 47903* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 47904 (line 41) 47905* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 8) 47906* DBX_REGISTER_NUMBER: All Debuggers. (line 8) 47907* DBX_REGPARM_STABS_CODE: DBX Options. (line 84) 47908* DBX_REGPARM_STABS_LETTER: DBX Options. (line 89) 47909* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 79) 47910* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 70) 47911* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 75) 47912* DBX_USE_BINCL: DBX Options. (line 112) 47913* DCmode: Machine Modes. (line 199) 47914* DDmode: Machine Modes. (line 93) 47915* De Morgan's law: Insn Canonicalizations. 47916 (line 51) 47917* dead_or_set_p: define_peephole. (line 65) 47918* DEBUGGER_ARG_OFFSET: All Debuggers. (line 36) 47919* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 27) 47920* debug_expr: Debug Information. (line 22) 47921* DEBUG_EXPR_DECL: Declarations. (line 6) 47922* debug_insn: Insns. (line 236) 47923* DEBUG_SYMS_TEXT: DBX Options. (line 24) 47924* decimal float library: Decimal float library routines. 47925 (line 6) 47926* declaration: Declarations. (line 6) 47927* declarations, RTL: RTL Declarations. (line 6) 47928* DECLARE_LIBRARY_RENAMES: Library Calls. (line 8) 47929* DECL_ALIGN: Declarations. (line 6) 47930* DECL_ANTICIPATED: Functions for C++. (line 42) 47931* DECL_ARGUMENTS: Function Basics. (line 36) 47932* DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158) 47933* DECL_ARTIFICIAL: Working with declarations. 47934 (line 24) 47935* DECL_ARTIFICIAL <1>: Function Basics. (line 6) 47936* DECL_ARTIFICIAL <2>: Function Properties. 47937 (line 47) 47938* DECL_ASSEMBLER_NAME: Function Basics. (line 6) 47939* DECL_ASSEMBLER_NAME <1>: Function Basics. (line 19) 47940* DECL_ATTRIBUTES: Attributes. (line 21) 47941* DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88) 47942* DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84) 47943* DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98) 47944* DECL_CONSTRUCTOR_P: Functions for C++. (line 77) 47945* DECL_CONST_MEMFUNC_P: Functions for C++. (line 71) 47946* DECL_CONTEXT: Namespaces. (line 31) 47947* DECL_CONV_FN_P: Functions for C++. (line 105) 47948* DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92) 47949* DECL_DESTRUCTOR_P: Functions for C++. (line 95) 47950* DECL_EXTERNAL: Declarations. (line 6) 47951* DECL_EXTERNAL <1>: Function Properties. 47952 (line 25) 47953* DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46) 47954* DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61) 47955* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6) 47956* DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties. 47957 (line 61) 47958* DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6) 47959* DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Properties. 47960 (line 55) 47961* DECL_GLOBAL_CTOR_P: Functions for C++. (line 108) 47962* DECL_GLOBAL_DTOR_P: Functions for C++. (line 112) 47963* DECL_INITIAL: Declarations. (line 6) 47964* DECL_INITIAL <1>: Function Basics. (line 51) 47965* DECL_LINKONCE_P: Functions for C++. (line 50) 47966* DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38) 47967* DECL_MAIN_P: Functions for C++. (line 34) 47968* DECL_NAME: Working with declarations. 47969 (line 7) 47970* DECL_NAME <1>: Function Basics. (line 6) 47971* DECL_NAME <2>: Function Basics. (line 9) 47972* DECL_NAME <3>: Namespaces. (line 20) 47973* DECL_NAMESPACE_ALIAS: Namespaces. (line 35) 47974* DECL_NAMESPACE_STD_P: Namespaces. (line 45) 47975* DECL_NONCONVERTING_P: Functions for C++. (line 80) 47976* DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68) 47977* DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138) 47978* DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102) 47979* DECL_PURE_P: Function Properties. 47980 (line 40) 47981* DECL_RESULT: Function Basics. (line 41) 47982* DECL_SAVED_TREE: Function Basics. (line 44) 47983* DECL_SIZE: Declarations. (line 6) 47984* DECL_STATIC_FUNCTION_P: Functions for C++. (line 65) 47985* DECL_STMT: Statements for C++. (line 6) 47986* DECL_STMT_DECL: Statements for C++. (line 6) 47987* DECL_THUNK_P: Functions for C++. (line 116) 47988* DECL_VIRTUAL_P: Function Properties. 47989 (line 44) 47990* DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74) 47991* decrement_and_branch_until_zero instruction pattern: Standard Names. 47992 (line 1495) 47993* default: GTY Options. (line 88) 47994* default_file_start: File Framework. (line 8) 47995* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 17) 47996* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34) 47997* DEFAULT_SIGNED_CHAR: Type Layout. (line 123) 47998* define_address_constraint: Define Constraints. (line 113) 47999* define_asm_attributes: Tagging Insns. (line 73) 48000* define_attr: Defining Attributes. 48001 (line 6) 48002* define_automaton: Processor pipeline description. 48003 (line 53) 48004* define_bypass: Processor pipeline description. 48005 (line 196) 48006* define_code_attr: Code Iterators. (line 6) 48007* define_code_iterator: Code Iterators. (line 6) 48008* define_cond_exec: Conditional Execution. 48009 (line 13) 48010* define_constants: Constant Definitions. 48011 (line 6) 48012* define_constraint: Define Constraints. (line 45) 48013* define_cpu_unit: Processor pipeline description. 48014 (line 68) 48015* define_c_enum: Constant Definitions. 48016 (line 49) 48017* define_delay: Delay Slots. (line 25) 48018* define_enum: Constant Definitions. 48019 (line 118) 48020* define_enum_attr: Defining Attributes. 48021 (line 83) 48022* define_enum_attr <1>: Constant Definitions. 48023 (line 136) 48024* define_expand: Expander Definitions. 48025 (line 11) 48026* define_insn: Patterns. (line 6) 48027* define_insn example: Example. (line 6) 48028* define_insn_and_split: Insn Splitting. (line 170) 48029* define_insn_reservation: Processor pipeline description. 48030 (line 105) 48031* define_int_attr: Int Iterators. (line 6) 48032* define_int_iterator: Int Iterators. (line 6) 48033* define_memory_constraint: Define Constraints. (line 80) 48034* define_mode_attr: Substitutions. (line 6) 48035* define_mode_iterator: Defining Mode Iterators. 48036 (line 6) 48037* define_peephole: define_peephole. (line 6) 48038* define_peephole2: define_peephole2. (line 6) 48039* define_predicate: Defining Predicates. 48040 (line 6) 48041* define_query_cpu_unit: Processor pipeline description. 48042 (line 90) 48043* define_register_constraint: Define Constraints. (line 26) 48044* define_reservation: Processor pipeline description. 48045 (line 185) 48046* define_special_memory_constraint: Define Constraints. (line 99) 48047* define_special_predicate: Defining Predicates. 48048 (line 6) 48049* define_split: Insn Splitting. (line 32) 48050* define_subst: Define Subst. (line 6) 48051* define_subst <1>: Define Subst Example. 48052 (line 6) 48053* define_subst <2>: Define Subst Pattern Matching. 48054 (line 6) 48055* define_subst <3>: Define Subst Output Template. 48056 (line 6) 48057* define_subst <4>: Define Subst. (line 14) 48058* define_subst <5>: Subst Iterators. (line 6) 48059* define_subst_attr: Subst Iterators. (line 6) 48060* define_subst_attr <1>: Subst Iterators. (line 26) 48061* defining attributes and their values: Defining Attributes. 48062 (line 6) 48063* defining constraints: Define Constraints. (line 6) 48064* defining jump instruction patterns: Jump Patterns. (line 6) 48065* defining looping instruction patterns: Looping Patterns. (line 6) 48066* defining peephole optimizers: Peephole Definitions. 48067 (line 6) 48068* defining predicates: Defining Predicates. 48069 (line 6) 48070* defining RTL sequences for code generation: Expander Definitions. 48071 (line 6) 48072* delay slots, defining: Delay Slots. (line 6) 48073* deletable: GTY Options. (line 132) 48074* DELETE_IF_ORDINARY: Filesystem. (line 79) 48075* Dependent Patterns: Dependent Patterns. (line 6) 48076* desc: GTY Options. (line 88) 48077* destructors, output of: Initialization. (line 6) 48078* deterministic finite state automaton: Processor pipeline description. 48079 (line 6) 48080* deterministic finite state automaton <1>: Processor pipeline description. 48081 (line 304) 48082* DFmode: Machine Modes. (line 76) 48083* digits in constraint: Simple Constraints. (line 128) 48084* DImode: Machine Modes. (line 45) 48085* directory options .md: Including Patterns. (line 47) 48086* DIR_SEPARATOR: Filesystem. (line 18) 48087* DIR_SEPARATOR_2: Filesystem. (line 19) 48088* disabling certain registers: Register Basics. (line 73) 48089* dispatch table: Dispatch Tables. (line 8) 48090* div: Arithmetic. (line 116) 48091* div and attributes: Expressions. (line 83) 48092* division: Arithmetic. (line 116) 48093* division <1>: Arithmetic. (line 130) 48094* division <2>: Arithmetic. (line 136) 48095* divM3 instruction pattern: Standard Names. (line 301) 48096* divmodM4 instruction pattern: Standard Names. (line 559) 48097* dollar sign: Multi-Alternative. (line 57) 48098* DOLLARS_IN_IDENTIFIERS: Misc. (line 452) 48099* doloop_begin instruction pattern: Standard Names. (line 1517) 48100* doloop_end instruction pattern: Standard Names. (line 1505) 48101* DONE: Expander Definitions. 48102 (line 77) 48103* DONT_USE_BUILTIN_SETJMP: Exception Region Output. 48104 (line 78) 48105* DOUBLE_TYPE_SIZE: Type Layout. (line 52) 48106* DO_BODY: Statements for C++. (line 6) 48107* DO_COND: Statements for C++. (line 6) 48108* DO_STMT: Statements for C++. (line 6) 48109* DQmode: Machine Modes. (line 118) 48110* driver: Driver. (line 6) 48111* DRIVER_SELF_SPECS: Driver. (line 8) 48112* dump examples: Dump examples. (line 6) 48113* dump setup: Dump setup. (line 6) 48114* dump types: Dump types. (line 6) 48115* dump verbosity: Dump output verbosity. 48116 (line 6) 48117* DUMPFILE_FORMAT: Filesystem. (line 67) 48118* dump_basic_block: Dump types. (line 29) 48119* dump_generic_expr: Dump types. (line 31) 48120* dump_gimple_stmt: Dump types. (line 33) 48121* dump_printf: Dump types. (line 6) 48122* DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 49) 48123* DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 12) 48124* DWARF2_FRAME_INFO: SDB and DWARF. (line 29) 48125* DWARF2_FRAME_REG_OUT: Frame Registers. (line 151) 48126* DWARF2_UNWIND_INFO: Exception Region Output. 48127 (line 39) 48128* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 148) 48129* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 48130 (line 90) 48131* DWARF_FRAME_REGISTERS: Frame Registers. (line 109) 48132* DWARF_FRAME_REGNUM: Frame Registers. (line 143) 48133* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 134) 48134* DWARF_ZERO_REG: Frame Layout. (line 159) 48135* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 86) 48136* E in constraint: Simple Constraints. (line 87) 48137* earlyclobber operand: Modifiers. (line 25) 48138* edge: Edges. (line 6) 48139* edge in the flow graph: Edges. (line 6) 48140* edge iterators: Edges. (line 15) 48141* edge splitting: Maintaining the CFG. 48142 (line 105) 48143* EDGE_ABNORMAL: Edges. (line 127) 48144* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171) 48145* EDGE_ABNORMAL, EDGE_EH: Edges. (line 95) 48146* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 121) 48147* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 85) 48148* EDOM, implicit usage: Library Calls. (line 59) 48149* EH_FRAME_SECTION_NAME: Exception Region Output. 48150 (line 9) 48151* EH_FRAME_THROUGH_COLLECT2: Exception Region Output. 48152 (line 19) 48153* eh_return instruction pattern: Standard Names. (line 1698) 48154* EH_RETURN_DATA_REGNO: Exception Handling. (line 6) 48155* EH_RETURN_HANDLER_RTX: Exception Handling. (line 38) 48156* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 21) 48157* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 48158 (line 29) 48159* EH_USES: Function Entry. (line 155) 48160* ei_edge: Edges. (line 43) 48161* ei_end_p: Edges. (line 27) 48162* ei_last: Edges. (line 23) 48163* ei_next: Edges. (line 35) 48164* ei_one_before_end_p: Edges. (line 31) 48165* ei_prev: Edges. (line 39) 48166* ei_safe_safe: Edges. (line 47) 48167* ei_start: Edges. (line 19) 48168* ELIMINABLE_REGS: Elimination. (line 46) 48169* ELSE_CLAUSE: Statements for C++. (line 6) 48170* Embedded C: Fixed-point fractional library routines. 48171 (line 6) 48172* Empty Statements: Empty Statements. (line 6) 48173* EMPTY_CLASS_EXPR: Statements for C++. (line 6) 48174* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 311) 48175* Emulated TLS: Emulated TLS. (line 6) 48176* enabled: Disable Insn Alternatives. 48177 (line 6) 48178* ENDFILE_SPEC: Driver. (line 155) 48179* endianness: Portability. (line 20) 48180* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 10) 48181* enum reg_class: Register Classes. (line 70) 48182* ENUMERAL_TYPE: Types. (line 6) 48183* enumerations: Constant Definitions. 48184 (line 49) 48185* epilogue: Function Entry. (line 6) 48186* epilogue instruction pattern: Standard Names. (line 1736) 48187* EPILOGUE_USES: Function Entry. (line 149) 48188* eq: Comparisons. (line 52) 48189* eq and attributes: Expressions. (line 83) 48190* equal: Comparisons. (line 52) 48191* eq_attr: Expressions. (line 104) 48192* EQ_EXPR: Unary and Binary Expressions. 48193 (line 6) 48194* errno, implicit usage: Library Calls. (line 71) 48195* EXACT_DIV_EXPR: Unary and Binary Expressions. 48196 (line 6) 48197* examining SSA_NAMEs: SSA. (line 182) 48198* exception handling: Edges. (line 95) 48199* exception handling <1>: Exception Handling. (line 6) 48200* exception_receiver instruction pattern: Standard Names. (line 1663) 48201* exclamation point: Multi-Alternative. (line 48) 48202* exclusion_set: Processor pipeline description. 48203 (line 223) 48204* exclusive-or, bitwise: Arithmetic. (line 168) 48205* EXIT_EXPR: Unary and Binary Expressions. 48206 (line 6) 48207* EXIT_IGNORE_STACK: Function Entry. (line 137) 48208* exp10M2 instruction pattern: Standard Names. (line 726) 48209* exp2M2 instruction pattern: Standard Names. (line 733) 48210* expander definitions: Expander Definitions. 48211 (line 6) 48212* expm1M2 instruction pattern: Standard Names. (line 716) 48213* expM2 instruction pattern: Standard Names. (line 709) 48214* expression: Expression trees. (line 6) 48215* expression codes: RTL Objects. (line 47) 48216* EXPR_FILENAME: Working with declarations. 48217 (line 14) 48218* EXPR_LINENO: Working with declarations. 48219 (line 20) 48220* expr_list: Insns. (line 540) 48221* EXPR_STMT: Statements for C++. (line 6) 48222* EXPR_STMT_EXPR: Statements for C++. (line 6) 48223* extendMN2 instruction pattern: Standard Names. (line 1124) 48224* extensible constraints: Simple Constraints. (line 171) 48225* EXTRA_SPECS: Driver. (line 182) 48226* extv instruction pattern: Standard Names. (line 1215) 48227* extvM instruction pattern: Standard Names. (line 1160) 48228* extvmisalignM instruction pattern: Standard Names. (line 1170) 48229* extzv instruction pattern: Standard Names. (line 1233) 48230* extzvM instruction pattern: Standard Names. (line 1184) 48231* extzvmisalignM instruction pattern: Standard Names. (line 1187) 48232* F in constraint: Simple Constraints. (line 92) 48233* FAIL: Expander Definitions. 48234 (line 83) 48235* fall-thru: Edges. (line 68) 48236* FATAL_EXIT_CODE: Host Misc. (line 6) 48237* FDL, GNU Free Documentation License: GNU Free Documentation License. 48238 (line 6) 48239* features, optional, in system conventions: Run-time Target. 48240 (line 59) 48241* ffs: Arithmetic. (line 210) 48242* ffsM2 instruction pattern: Standard Names. (line 872) 48243* FIELD_DECL: Declarations. (line 6) 48244* files and passes of the compiler: Passes. (line 6) 48245* files, generated: Files. (line 6) 48246* file_end_indicate_exec_stack: File Framework. (line 39) 48247* final_absence_set: Processor pipeline description. 48248 (line 223) 48249* FINAL_PRESCAN_INSN: Instruction Output. (line 60) 48250* final_presence_set: Processor pipeline description. 48251 (line 223) 48252* final_sequence: Instruction Output. (line 144) 48253* FIND_BASE_TERM: Addressing Modes. (line 117) 48254* finite state automaton minimization: Processor pipeline description. 48255 (line 304) 48256* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 113) 48257* FINI_SECTION_ASM_OP: Sections. (line 98) 48258* FIRST_PARM_OFFSET: Frame Layout. (line 61) 48259* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 48260* FIRST_PSEUDO_REGISTER: Register Basics. (line 8) 48261* FIRST_STACK_REG: Stack Registers. (line 26) 48262* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 48263* fix: Conversions. (line 66) 48264* fixed register: Register Basics. (line 15) 48265* fixed-point fractional library: Fixed-point fractional library routines. 48266 (line 6) 48267* FIXED_CONVERT_EXPR: Unary and Binary Expressions. 48268 (line 6) 48269* FIXED_CST: Constant expressions. 48270 (line 6) 48271* FIXED_POINT_TYPE: Types. (line 6) 48272* FIXED_REGISTERS: Register Basics. (line 14) 48273* fixed_regs: Register Basics. (line 59) 48274* fixMN2 instruction pattern: Standard Names. (line 1091) 48275* fixunsMN2 instruction pattern: Standard Names. (line 1100) 48276* fixuns_truncMN2 instruction pattern: Standard Names. (line 1115) 48277* fix_truncMN2 instruction pattern: Standard Names. (line 1111) 48278* FIX_TRUNC_EXPR: Unary and Binary Expressions. 48279 (line 6) 48280* flags in RTL expression: Flags. (line 6) 48281* float: Conversions. (line 58) 48282* floating point and cross compilation: Floating Point. (line 6) 48283* floatMN2 instruction pattern: Standard Names. (line 1083) 48284* floatunsMN2 instruction pattern: Standard Names. (line 1087) 48285* FLOAT_EXPR: Unary and Binary Expressions. 48286 (line 6) 48287* float_extend: Conversions. (line 33) 48288* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 32) 48289* FLOAT_STORE_FLAG_VALUE: Misc. (line 286) 48290* float_truncate: Conversions. (line 53) 48291* FLOAT_TYPE_SIZE: Type Layout. (line 48) 48292* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 41) 48293* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 48294 (line 224) 48295* floorM2 instruction pattern: Standard Names. (line 800) 48296* FLOOR_DIV_EXPR: Unary and Binary Expressions. 48297 (line 6) 48298* FLOOR_MOD_EXPR: Unary and Binary Expressions. 48299 (line 6) 48300* flow-insensitive alias analysis: Alias analysis. (line 6) 48301* flow-sensitive alias analysis: Alias analysis. (line 6) 48302* fma: Arithmetic. (line 112) 48303* fmaM4 instruction pattern: Standard Names. (line 338) 48304* fmaxM3 instruction pattern: Standard Names. (line 369) 48305* fminM3 instruction pattern: Standard Names. (line 369) 48306* fmodM3 instruction pattern: Standard Names. (line 632) 48307* fmsM4 instruction pattern: Standard Names. (line 345) 48308* fnmaM4 instruction pattern: Standard Names. (line 351) 48309* fnmsM4 instruction pattern: Standard Names. (line 357) 48310* FORCE_CODE_SECTION_ALIGN: Sections. (line 144) 48311* force_reg: Standard Names. (line 36) 48312* FOR_BODY: Statements for C++. (line 6) 48313* FOR_COND: Statements for C++. (line 6) 48314* FOR_EXPR: Statements for C++. (line 6) 48315* FOR_INIT_STMT: Statements for C++. (line 6) 48316* FOR_STMT: Statements for C++. (line 6) 48317* for_user: GTY Options. (line 82) 48318* fractional types: Fixed-point fractional library routines. 48319 (line 6) 48320* fractMN2 instruction pattern: Standard Names. (line 1133) 48321* fractunsMN2 instruction pattern: Standard Names. (line 1148) 48322* fract_convert: Conversions. (line 82) 48323* FRACT_TYPE_SIZE: Type Layout. (line 67) 48324* frame layout: Frame Layout. (line 6) 48325* FRAME_ADDR_RTX: Frame Layout. (line 110) 48326* FRAME_GROWS_DOWNWARD: Frame Layout. (line 26) 48327* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 48328 (line 69) 48329* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 208) 48330* frame_pointer_needed: Function Entry. (line 34) 48331* FRAME_POINTER_REGNUM: Frame Registers. (line 13) 48332* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 48333 (line 74) 48334* frame_pointer_rtx: Frame Registers. (line 104) 48335* frame_related: Flags. (line 229) 48336* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 48337 (line 107) 48338* frame_related, in mem: Flags. (line 85) 48339* frame_related, in reg: Flags. (line 94) 48340* frame_related, in symbol_ref: Flags. (line 165) 48341* frequency, count, BB_FREQ_BASE: Profile information. 48342 (line 30) 48343* ftruncM2 instruction pattern: Standard Names. (line 1106) 48344* function: Functions. (line 6) 48345* function <1>: Functions for C++. (line 6) 48346* function call conventions: Interface. (line 6) 48347* function entry and exit: Function Entry. (line 6) 48348* function entry point, alternate function entry point: Edges. 48349 (line 180) 48350* function properties: Function Properties. 48351 (line 6) 48352* function-call insns: Calls. (line 6) 48353* functions, leaf: Leaf Functions. (line 6) 48354* FUNCTION_ARG_OFFSET: Register Arguments. (line 210) 48355* FUNCTION_ARG_PADDING: Register Arguments. (line 217) 48356* FUNCTION_ARG_REGNO_P: Register Arguments. (line 265) 48357* FUNCTION_BOUNDARY: Storage Layout. (line 159) 48358* FUNCTION_DECL: Functions. (line 6) 48359* FUNCTION_DECL <1>: Functions for C++. (line 6) 48360* FUNCTION_MODE: Misc. (line 341) 48361* FUNCTION_PROFILER: Profiling. (line 8) 48362* FUNCTION_TYPE: Types. (line 6) 48363* FUNCTION_VALUE: Scalar Return. (line 52) 48364* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 78) 48365* fundamental type: Types. (line 6) 48366* G in constraint: Simple Constraints. (line 96) 48367* g in constraint: Simple Constraints. (line 118) 48368* garbage collector, invocation: Invoking the garbage collector. 48369 (line 6) 48370* garbage collector, troubleshooting: Troubleshooting. (line 6) 48371* GCC and portability: Portability. (line 6) 48372* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 48373* gcov_type: Profile information. 48374 (line 41) 48375* ge: Comparisons. (line 72) 48376* ge and attributes: Expressions. (line 83) 48377* gencodes: RTL passes. (line 18) 48378* general_operand: Machine-Independent Predicates. 48379 (line 104) 48380* GENERAL_REGS: Register Classes. (line 22) 48381* generated files: Files. (line 6) 48382* generating assembler output: Output Statement. (line 6) 48383* generating insns: RTL Template. (line 6) 48384* GENERIC: Parsing pass. (line 6) 48385* GENERIC <1>: GENERIC. (line 6) 48386* generic predicates: Machine-Independent Predicates. 48387 (line 6) 48388* genflags: RTL passes. (line 18) 48389* GEN_ERRNO_RTX: Library Calls. (line 71) 48390* get_attr: Expressions. (line 99) 48391* get_attr_length: Insn Lengths. (line 52) 48392* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 344) 48393* GET_CODE: RTL Objects. (line 47) 48394* get_frame_size: Elimination. (line 34) 48395* get_insns: Insns. (line 34) 48396* get_last_insn: Insns. (line 34) 48397* GET_MODE: Machine Modes. (line 291) 48398* GET_MODE_ALIGNMENT: Machine Modes. (line 331) 48399* GET_MODE_BITSIZE: Machine Modes. (line 315) 48400* GET_MODE_CLASS: Machine Modes. (line 305) 48401* GET_MODE_FBIT: Machine Modes. (line 322) 48402* GET_MODE_IBIT: Machine Modes. (line 318) 48403* GET_MODE_MASK: Machine Modes. (line 326) 48404* GET_MODE_NAME: Machine Modes. (line 302) 48405* GET_MODE_NUNITS: Machine Modes. (line 340) 48406* GET_MODE_SIZE: Machine Modes. (line 312) 48407* GET_MODE_UNIT_SIZE: Machine Modes. (line 334) 48408* GET_MODE_WIDER_MODE: Machine Modes. (line 308) 48409* GET_RTX_CLASS: RTL Classes. (line 6) 48410* GET_RTX_FORMAT: RTL Classes. (line 131) 48411* GET_RTX_LENGTH: RTL Classes. (line 128) 48412* get_thread_pointerMODE instruction pattern: Standard Names. 48413 (line 2073) 48414* geu: Comparisons. (line 72) 48415* geu and attributes: Expressions. (line 83) 48416* GE_EXPR: Unary and Binary Expressions. 48417 (line 6) 48418* GGC: Type Information. (line 6) 48419* ggc_collect: Invoking the garbage collector. 48420 (line 6) 48421* GIMPLE: Parsing pass. (line 13) 48422* GIMPLE <1>: Gimplification pass. 48423 (line 6) 48424* GIMPLE <2>: GIMPLE. (line 6) 48425* gimple: Tuple representation. 48426 (line 14) 48427* GIMPLE API: GIMPLE API. (line 6) 48428* GIMPLE class hierarchy: Class hierarchy of GIMPLE statements. 48429 (line 6) 48430* GIMPLE Exception Handling: GIMPLE Exception Handling. 48431 (line 6) 48432* GIMPLE instruction set: GIMPLE instruction set. 48433 (line 6) 48434* GIMPLE sequences: GIMPLE sequences. (line 6) 48435* GIMPLE statement iterators: Basic Blocks. (line 78) 48436* GIMPLE statement iterators <1>: Maintaining the CFG. 48437 (line 33) 48438* gimple_addresses_taken: Manipulating GIMPLE statements. 48439 (line 89) 48440* GIMPLE_ASM: GIMPLE_ASM. (line 6) 48441* gimple_asm_clobber_op: GIMPLE_ASM. (line 39) 48442* gimple_asm_input_op: GIMPLE_ASM. (line 23) 48443* gimple_asm_nclobbers: GIMPLE_ASM. (line 20) 48444* gimple_asm_ninputs: GIMPLE_ASM. (line 14) 48445* gimple_asm_noutputs: GIMPLE_ASM. (line 17) 48446* gimple_asm_output_op: GIMPLE_ASM. (line 31) 48447* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 43) 48448* gimple_asm_set_input_op: GIMPLE_ASM. (line 27) 48449* gimple_asm_set_output_op: GIMPLE_ASM. (line 35) 48450* gimple_asm_set_volatile: GIMPLE_ASM. (line 54) 48451* gimple_asm_string: GIMPLE_ASM. (line 47) 48452* gimple_asm_volatile_p: GIMPLE_ASM. (line 51) 48453* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6) 48454* gimple_assign_cast_p: Logical Operators. (line 158) 48455* gimple_assign_cast_p <1>: GIMPLE_ASSIGN. (line 104) 48456* gimple_assign_lhs: GIMPLE_ASSIGN. (line 62) 48457* gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 65) 48458* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 68) 48459* gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 71) 48460* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 75) 48461* gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 78) 48462* gimple_assign_rhs3: GIMPLE_ASSIGN. (line 82) 48463* gimple_assign_rhs3_ptr: GIMPLE_ASSIGN. (line 85) 48464* gimple_assign_rhs_class: GIMPLE_ASSIGN. (line 56) 48465* gimple_assign_rhs_code: GIMPLE_ASSIGN. (line 52) 48466* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 89) 48467* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 92) 48468* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 96) 48469* gimple_assign_set_rhs3: GIMPLE_ASSIGN. (line 100) 48470* gimple_bb: Manipulating GIMPLE statements. 48471 (line 17) 48472* GIMPLE_BIND: GIMPLE_BIND. (line 6) 48473* gimple_bind_add_seq: GIMPLE_BIND. (line 34) 48474* gimple_bind_add_stmt: GIMPLE_BIND. (line 31) 48475* gimple_bind_append_vars: GIMPLE_BIND. (line 18) 48476* gimple_bind_block: GIMPLE_BIND. (line 39) 48477* gimple_bind_body: GIMPLE_BIND. (line 22) 48478* gimple_bind_set_block: GIMPLE_BIND. (line 44) 48479* gimple_bind_set_body: GIMPLE_BIND. (line 26) 48480* gimple_bind_set_vars: GIMPLE_BIND. (line 14) 48481* gimple_bind_vars: GIMPLE_BIND. (line 11) 48482* gimple_block: Manipulating GIMPLE statements. 48483 (line 20) 48484* gimple_build: GIMPLE API. (line 34) 48485* gimple_build <1>: GIMPLE API. (line 36) 48486* gimple_build <2>: GIMPLE API. (line 38) 48487* gimple_build <3>: GIMPLE API. (line 41) 48488* gimple_build <4>: GIMPLE API. (line 44) 48489* gimple_build <5>: GIMPLE API. (line 47) 48490* gimple_build_nop: GIMPLE_NOP. (line 6) 48491* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 6) 48492* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 6) 48493* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 6) 48494* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 6) 48495* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS. 48496 (line 13) 48497* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR. 48498 (line 6) 48499* GIMPLE_CALL: GIMPLE_CALL. (line 6) 48500* gimple_call_arg: GIMPLE_CALL. (line 65) 48501* gimple_call_arg_ptr: GIMPLE_CALL. (line 69) 48502* gimple_call_chain: GIMPLE_CALL. (line 56) 48503* gimple_call_copy_skip_args: GIMPLE_CALL. (line 90) 48504* gimple_call_fn: GIMPLE_CALL. (line 37) 48505* gimple_call_fndecl: GIMPLE_CALL. (line 45) 48506* gimple_call_lhs: GIMPLE_CALL. (line 28) 48507* gimple_call_lhs_ptr: GIMPLE_CALL. (line 31) 48508* gimple_call_noreturn_p: GIMPLE_CALL. (line 87) 48509* gimple_call_num_args: GIMPLE_CALL. (line 62) 48510* gimple_call_return_type: GIMPLE_CALL. (line 53) 48511* gimple_call_set_arg: GIMPLE_CALL. (line 74) 48512* gimple_call_set_chain: GIMPLE_CALL. (line 59) 48513* gimple_call_set_fn: GIMPLE_CALL. (line 41) 48514* gimple_call_set_fndecl: GIMPLE_CALL. (line 50) 48515* gimple_call_set_lhs: GIMPLE_CALL. (line 34) 48516* gimple_call_set_tail: GIMPLE_CALL. (line 79) 48517* gimple_call_tail_p: GIMPLE_CALL. (line 84) 48518* GIMPLE_CATCH: GIMPLE_CATCH. (line 6) 48519* gimple_catch_handler: GIMPLE_CATCH. (line 19) 48520* gimple_catch_set_handler: GIMPLE_CATCH. (line 26) 48521* gimple_catch_set_types: GIMPLE_CATCH. (line 23) 48522* gimple_catch_types: GIMPLE_CATCH. (line 12) 48523* gimple_catch_types_ptr: GIMPLE_CATCH. (line 15) 48524* gimple_code: Manipulating GIMPLE statements. 48525 (line 14) 48526* GIMPLE_COND: GIMPLE_COND. (line 6) 48527* gimple_cond_code: GIMPLE_COND. (line 20) 48528* gimple_cond_false_label: GIMPLE_COND. (line 59) 48529* gimple_cond_lhs: GIMPLE_COND. (line 29) 48530* gimple_cond_make_false: GIMPLE_COND. (line 63) 48531* gimple_cond_make_true: GIMPLE_COND. (line 66) 48532* gimple_cond_rhs: GIMPLE_COND. (line 37) 48533* gimple_cond_set_code: GIMPLE_COND. (line 24) 48534* gimple_cond_set_false_label: GIMPLE_COND. (line 54) 48535* gimple_cond_set_lhs: GIMPLE_COND. (line 33) 48536* gimple_cond_set_rhs: GIMPLE_COND. (line 41) 48537* gimple_cond_set_true_label: GIMPLE_COND. (line 49) 48538* gimple_cond_true_label: GIMPLE_COND. (line 45) 48539* gimple_convert: GIMPLE API. (line 50) 48540* gimple_copy: Manipulating GIMPLE statements. 48541 (line 146) 48542* GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6) 48543* GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6) 48544* gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 46) 48545* gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 50) 48546* gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 43) 48547* gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 68) 48548* gimple_debug_bind_p: Logical Operators. (line 162) 48549* gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 64) 48550* gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 59) 48551* gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 55) 48552* gimple_def_ops: Manipulating GIMPLE statements. 48553 (line 93) 48554* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6) 48555* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 18) 48556* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 27) 48557* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 22) 48558* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 11) 48559* gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 14) 48560* gimple_eh_must_not_throw_fndecl: GIMPLE_EH_FILTER. (line 32) 48561* gimple_eh_must_not_throw_set_fndecl: GIMPLE_EH_FILTER. (line 36) 48562* gimple_expr_code: Manipulating GIMPLE statements. 48563 (line 30) 48564* gimple_expr_type: Manipulating GIMPLE statements. 48565 (line 23) 48566* GIMPLE_GOTO: GIMPLE_GOTO. (line 6) 48567* gimple_goto_dest: GIMPLE_GOTO. (line 9) 48568* gimple_goto_set_dest: GIMPLE_GOTO. (line 12) 48569* gimple_has_mem_ops: Manipulating GIMPLE statements. 48570 (line 71) 48571* gimple_has_ops: Manipulating GIMPLE statements. 48572 (line 68) 48573* gimple_has_volatile_ops: Manipulating GIMPLE statements. 48574 (line 133) 48575* GIMPLE_LABEL: GIMPLE_LABEL. (line 6) 48576* gimple_label_label: GIMPLE_LABEL. (line 10) 48577* gimple_label_set_label: GIMPLE_LABEL. (line 13) 48578* gimple_loaded_syms: Manipulating GIMPLE statements. 48579 (line 121) 48580* gimple_locus: Manipulating GIMPLE statements. 48581 (line 41) 48582* gimple_locus_empty_p: Manipulating GIMPLE statements. 48583 (line 47) 48584* gimple_modified_p: Manipulating GIMPLE statements. 48585 (line 129) 48586* GIMPLE_NOP: GIMPLE_NOP. (line 6) 48587* gimple_nop_p: GIMPLE_NOP. (line 9) 48588* gimple_no_warning_p: Manipulating GIMPLE statements. 48589 (line 50) 48590* gimple_num_ops: Logical Operators. (line 76) 48591* gimple_num_ops <1>: Manipulating GIMPLE statements. 48592 (line 74) 48593* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD. 48594 (line 6) 48595* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD. 48596 (line 16) 48597* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD. 48598 (line 24) 48599* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD. 48600 (line 12) 48601* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD. 48602 (line 20) 48603* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE. 48604 (line 6) 48605* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE. 48606 (line 11) 48607* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE. 48608 (line 15) 48609* gimple_omp_body: GIMPLE_OMP_PARALLEL. 48610 (line 23) 48611* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE. 48612 (line 6) 48613* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE. 48614 (line 12) 48615* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE. 48616 (line 17) 48617* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE. 48618 (line 26) 48619* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE. 48620 (line 31) 48621* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE. 48622 (line 21) 48623* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE. 48624 (line 35) 48625* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL. 48626 (line 6) 48627* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL. 48628 (line 12) 48629* gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL. 48630 (line 16) 48631* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL. 48632 (line 21) 48633* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6) 48634* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 17) 48635* gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 20) 48636* gimple_omp_for_cond: GIMPLE_OMP_FOR. (line 80) 48637* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 48) 48638* gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 51) 48639* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 58) 48640* gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 61) 48641* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 28) 48642* gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 31) 48643* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 38) 48644* gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 41) 48645* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 67) 48646* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 23) 48647* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 76) 48648* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 54) 48649* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 64) 48650* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 34) 48651* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 44) 48652* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 71) 48653* GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6) 48654* GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6) 48655* GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL. 48656 (line 6) 48657* gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL. 48658 (line 42) 48659* gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL. 48660 (line 47) 48661* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL. 48662 (line 30) 48663* gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL. 48664 (line 33) 48665* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL. 48666 (line 15) 48667* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL. 48668 (line 56) 48669* gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL. 48670 (line 61) 48671* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL. 48672 (line 52) 48673* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL. 48674 (line 37) 48675* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL. 48676 (line 19) 48677* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL. 48678 (line 65) 48679* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6) 48680* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 13) 48681* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 10) 48682* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6) 48683* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS. 48684 (line 6) 48685* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS. 48686 (line 29) 48687* gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS. 48688 (line 32) 48689* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS. 48690 (line 16) 48691* gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS. 48692 (line 20) 48693* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS. 48694 (line 35) 48695* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS. 48696 (line 24) 48697* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 11) 48698* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 15) 48699* gimple_omp_set_body: GIMPLE_OMP_PARALLEL. 48700 (line 26) 48701* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6) 48702* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 13) 48703* gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 16) 48704* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 19) 48705* gimple_op: Logical Operators. (line 79) 48706* gimple_op <1>: Manipulating GIMPLE statements. 48707 (line 80) 48708* gimple_ops: Logical Operators. (line 82) 48709* gimple_ops <1>: Manipulating GIMPLE statements. 48710 (line 77) 48711* gimple_op_ptr: Manipulating GIMPLE statements. 48712 (line 83) 48713* GIMPLE_PHI: GIMPLE_PHI. (line 6) 48714* gimple_phi_arg: GIMPLE_PHI. (line 24) 48715* gimple_phi_arg <1>: SSA. (line 62) 48716* gimple_phi_arg_def: SSA. (line 68) 48717* gimple_phi_arg_edge: SSA. (line 65) 48718* gimple_phi_capacity: GIMPLE_PHI. (line 6) 48719* gimple_phi_num_args: GIMPLE_PHI. (line 10) 48720* gimple_phi_num_args <1>: SSA. (line 58) 48721* gimple_phi_result: GIMPLE_PHI. (line 15) 48722* gimple_phi_result <1>: SSA. (line 55) 48723* gimple_phi_result_ptr: GIMPLE_PHI. (line 18) 48724* gimple_phi_set_arg: GIMPLE_PHI. (line 28) 48725* gimple_phi_set_result: GIMPLE_PHI. (line 21) 48726* gimple_plf: Manipulating GIMPLE statements. 48727 (line 64) 48728* GIMPLE_RESX: GIMPLE_RESX. (line 6) 48729* gimple_resx_region: GIMPLE_RESX. (line 12) 48730* gimple_resx_set_region: GIMPLE_RESX. (line 15) 48731* GIMPLE_RETURN: GIMPLE_RETURN. (line 6) 48732* gimple_return_retval: GIMPLE_RETURN. (line 9) 48733* gimple_return_set_retval: GIMPLE_RETURN. (line 12) 48734* gimple_seq_add_seq: GIMPLE sequences. (line 30) 48735* gimple_seq_add_stmt: GIMPLE sequences. (line 24) 48736* gimple_seq_alloc: GIMPLE sequences. (line 61) 48737* gimple_seq_copy: GIMPLE sequences. (line 65) 48738* gimple_seq_deep_copy: GIMPLE sequences. (line 36) 48739* gimple_seq_empty_p: GIMPLE sequences. (line 69) 48740* gimple_seq_first: GIMPLE sequences. (line 43) 48741* gimple_seq_init: GIMPLE sequences. (line 58) 48742* gimple_seq_last: GIMPLE sequences. (line 46) 48743* gimple_seq_reverse: GIMPLE sequences. (line 39) 48744* gimple_seq_set_first: GIMPLE sequences. (line 53) 48745* gimple_seq_set_last: GIMPLE sequences. (line 49) 48746* gimple_seq_singleton_p: GIMPLE sequences. (line 78) 48747* gimple_set_block: Manipulating GIMPLE statements. 48748 (line 38) 48749* gimple_set_def_ops: Manipulating GIMPLE statements. 48750 (line 96) 48751* gimple_set_has_volatile_ops: Manipulating GIMPLE statements. 48752 (line 136) 48753* gimple_set_locus: Manipulating GIMPLE statements. 48754 (line 44) 48755* gimple_set_op: Manipulating GIMPLE statements. 48756 (line 86) 48757* gimple_set_plf: Manipulating GIMPLE statements. 48758 (line 60) 48759* gimple_set_use_ops: Manipulating GIMPLE statements. 48760 (line 103) 48761* gimple_set_vdef_ops: Manipulating GIMPLE statements. 48762 (line 117) 48763* gimple_set_visited: Manipulating GIMPLE statements. 48764 (line 53) 48765* gimple_set_vuse_ops: Manipulating GIMPLE statements. 48766 (line 110) 48767* gimple_simplify: GIMPLE API. (line 6) 48768* gimple_simplify <1>: GIMPLE API. (line 8) 48769* gimple_simplify <2>: GIMPLE API. (line 10) 48770* gimple_simplify <3>: GIMPLE API. (line 12) 48771* gimple_simplify <4>: GIMPLE API. (line 14) 48772* gimple_simplify <5>: GIMPLE API. (line 16) 48773* gimple_statement_with_ops: Tuple representation. 48774 (line 96) 48775* gimple_stored_syms: Manipulating GIMPLE statements. 48776 (line 125) 48777* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6) 48778* gimple_switch_default_label: GIMPLE_SWITCH. (line 41) 48779* gimple_switch_index: GIMPLE_SWITCH. (line 24) 48780* gimple_switch_label: GIMPLE_SWITCH. (line 31) 48781* gimple_switch_num_labels: GIMPLE_SWITCH. (line 14) 48782* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 45) 48783* gimple_switch_set_index: GIMPLE_SWITCH. (line 27) 48784* gimple_switch_set_label: GIMPLE_SWITCH. (line 36) 48785* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 19) 48786* GIMPLE_TRY: GIMPLE_TRY. (line 6) 48787* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 19) 48788* gimple_try_cleanup: GIMPLE_TRY. (line 26) 48789* gimple_try_eval: GIMPLE_TRY. (line 22) 48790* gimple_try_kind: GIMPLE_TRY. (line 15) 48791* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 30) 48792* gimple_try_set_cleanup: GIMPLE_TRY. (line 38) 48793* gimple_try_set_eval: GIMPLE_TRY. (line 34) 48794* gimple_use_ops: Manipulating GIMPLE statements. 48795 (line 100) 48796* gimple_vdef_ops: Manipulating GIMPLE statements. 48797 (line 114) 48798* gimple_visited_p: Manipulating GIMPLE statements. 48799 (line 57) 48800* gimple_vuse_ops: Manipulating GIMPLE statements. 48801 (line 107) 48802* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 48803 (line 10) 48804* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 48805 (line 17) 48806* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 48807 (line 13) 48808* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 48809 (line 20) 48810* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR. 48811 (line 6) 48812* gimplification: Parsing pass. (line 13) 48813* gimplification <1>: Gimplification pass. 48814 (line 6) 48815* gimplifier: Parsing pass. (line 13) 48816* gimplify_assign: GIMPLE_ASSIGN. (line 41) 48817* gimplify_expr: Gimplification pass. 48818 (line 18) 48819* gimplify_function_tree: Gimplification pass. 48820 (line 18) 48821* GLOBAL_INIT_PRIORITY: Functions for C++. (line 141) 48822* global_regs: Register Basics. (line 59) 48823* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 90) 48824* greater than: Comparisons. (line 60) 48825* greater than <1>: Comparisons. (line 64) 48826* greater than <2>: Comparisons. (line 72) 48827* gsi_after_labels: Sequence iterators. (line 74) 48828* gsi_bb: Sequence iterators. (line 82) 48829* gsi_commit_edge_inserts: Sequence iterators. (line 193) 48830* gsi_commit_edge_inserts <1>: Maintaining the CFG. 48831 (line 105) 48832* gsi_commit_one_edge_insert: Sequence iterators. (line 188) 48833* gsi_end_p: Sequence iterators. (line 59) 48834* gsi_end_p <1>: Maintaining the CFG. 48835 (line 48) 48836* gsi_for_stmt: Sequence iterators. (line 156) 48837* gsi_insert_after: Sequence iterators. (line 145) 48838* gsi_insert_after <1>: Maintaining the CFG. 48839 (line 60) 48840* gsi_insert_before: Sequence iterators. (line 134) 48841* gsi_insert_before <1>: Maintaining the CFG. 48842 (line 66) 48843* gsi_insert_on_edge: Sequence iterators. (line 173) 48844* gsi_insert_on_edge <1>: Maintaining the CFG. 48845 (line 105) 48846* gsi_insert_on_edge_immediate: Sequence iterators. (line 183) 48847* gsi_insert_seq_after: Sequence iterators. (line 152) 48848* gsi_insert_seq_before: Sequence iterators. (line 141) 48849* gsi_insert_seq_on_edge: Sequence iterators. (line 177) 48850* gsi_last: Sequence iterators. (line 49) 48851* gsi_last <1>: Maintaining the CFG. 48852 (line 44) 48853* gsi_last_bb: Sequence iterators. (line 55) 48854* gsi_link_after: Sequence iterators. (line 113) 48855* gsi_link_before: Sequence iterators. (line 103) 48856* gsi_link_seq_after: Sequence iterators. (line 108) 48857* gsi_link_seq_before: Sequence iterators. (line 97) 48858* gsi_move_after: Sequence iterators. (line 159) 48859* gsi_move_before: Sequence iterators. (line 164) 48860* gsi_move_to_bb_end: Sequence iterators. (line 169) 48861* gsi_next: Sequence iterators. (line 65) 48862* gsi_next <1>: Maintaining the CFG. 48863 (line 52) 48864* gsi_one_before_end_p: Sequence iterators. (line 62) 48865* gsi_prev: Sequence iterators. (line 68) 48866* gsi_prev <1>: Maintaining the CFG. 48867 (line 56) 48868* gsi_remove: Sequence iterators. (line 88) 48869* gsi_remove <1>: Maintaining the CFG. 48870 (line 72) 48871* gsi_replace: Sequence iterators. (line 128) 48872* gsi_seq: Sequence iterators. (line 85) 48873* gsi_split_seq_after: Sequence iterators. (line 118) 48874* gsi_split_seq_before: Sequence iterators. (line 123) 48875* gsi_start: Sequence iterators. (line 39) 48876* gsi_start <1>: Maintaining the CFG. 48877 (line 40) 48878* gsi_start_bb: Sequence iterators. (line 45) 48879* gsi_stmt: Sequence iterators. (line 71) 48880* gsi_stmt_ptr: Sequence iterators. (line 79) 48881* gt: Comparisons. (line 60) 48882* gt and attributes: Expressions. (line 83) 48883* gtu: Comparisons. (line 64) 48884* gtu and attributes: Expressions. (line 83) 48885* GTY: Type Information. (line 6) 48886* GT_EXPR: Unary and Binary Expressions. 48887 (line 6) 48888* H in constraint: Simple Constraints. (line 96) 48889* HAmode: Machine Modes. (line 146) 48890* HANDLER: Statements for C++. (line 6) 48891* HANDLER_BODY: Statements for C++. (line 6) 48892* HANDLER_PARMS: Statements for C++. (line 6) 48893* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 442) 48894* hard registers: Regs and Memory. (line 9) 48895* HARD_FRAME_POINTER_IS_ARG_POINTER: Frame Registers. (line 57) 48896* HARD_FRAME_POINTER_IS_FRAME_POINTER: Frame Registers. (line 50) 48897* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 19) 48898* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 10) 48899* HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 52) 48900* HARD_REGNO_MODE_OK: Values in Registers. 48901 (line 57) 48902* HARD_REGNO_NREGS: Values in Registers. 48903 (line 10) 48904* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 48905 (line 24) 48906* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 48907 (line 42) 48908* HARD_REGNO_RENAME_OK: Values in Registers. 48909 (line 117) 48910* HAS_INIT_SECTION: Macros for Initialization. 48911 (line 18) 48912* HAS_LONG_COND_BRANCH: Misc. (line 8) 48913* HAS_LONG_UNCOND_BRANCH: Misc. (line 17) 48914* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 48915* HAVE_POST_DECREMENT: Addressing Modes. (line 11) 48916* HAVE_POST_INCREMENT: Addressing Modes. (line 10) 48917* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 17) 48918* HAVE_POST_MODIFY_REG: Addressing Modes. (line 23) 48919* HAVE_PRE_DECREMENT: Addressing Modes. (line 9) 48920* HAVE_PRE_INCREMENT: Addressing Modes. (line 8) 48921* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 16) 48922* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 22) 48923* HCmode: Machine Modes. (line 199) 48924* HFmode: Machine Modes. (line 61) 48925* high: Constants. (line 150) 48926* HImode: Machine Modes. (line 29) 48927* HImode, in insn: Insns. (line 268) 48928* HONOR_REG_ALLOC_ORDER: Allocation Order. (line 36) 48929* host configuration: Host Config. (line 6) 48930* host functions: Host Common. (line 6) 48931* host hooks: Host Common. (line 6) 48932* host makefile fragment: Host Fragment. (line 6) 48933* HOST_BIT_BUCKET: Filesystem. (line 51) 48934* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 48935* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 11) 48936* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 43) 48937* HOST_HOOKS_GT_PCH_GET_ADDRESS: Host Common. (line 15) 48938* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 24) 48939* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 48940* HOST_LONG_FORMAT: Host Misc. (line 45) 48941* HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 48942* HOST_OBJECT_SUFFIX: Filesystem. (line 40) 48943* HOST_PTR_PRINTF: Host Misc. (line 49) 48944* HOT_TEXT_SECTION_NAME: Sections. (line 42) 48945* HQmode: Machine Modes. (line 110) 48946* i in constraint: Simple Constraints. (line 68) 48947* I in constraint: Simple Constraints. (line 79) 48948* identifier: Identifiers. (line 6) 48949* IDENTIFIER_LENGTH: Identifiers. (line 22) 48950* IDENTIFIER_NODE: Identifiers. (line 6) 48951* IDENTIFIER_OPNAME_P: Identifiers. (line 27) 48952* IDENTIFIER_POINTER: Identifiers. (line 17) 48953* IDENTIFIER_TYPENAME_P: Identifiers. (line 33) 48954* IEEE 754-2008: Decimal float library routines. 48955 (line 6) 48956* IFCVT_MACHDEP_INIT: Misc. (line 568) 48957* IFCVT_MODIFY_CANCEL: Misc. (line 562) 48958* IFCVT_MODIFY_FINAL: Misc. (line 556) 48959* IFCVT_MODIFY_INSN: Misc. (line 550) 48960* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 542) 48961* IFCVT_MODIFY_TESTS: Misc. (line 532) 48962* IF_COND: Statements for C++. (line 6) 48963* IF_STMT: Statements for C++. (line 6) 48964* if_then_else: Comparisons. (line 80) 48965* if_then_else and attributes: Expressions. (line 32) 48966* if_then_else usage: Side Effects. (line 56) 48967* IMAGPART_EXPR: Unary and Binary Expressions. 48968 (line 6) 48969* Immediate Uses: SSA Operands. (line 258) 48970* immediate_operand: Machine-Independent Predicates. 48971 (line 10) 48972* IMMEDIATE_PREFIX: Instruction Output. (line 153) 48973* include: Including Patterns. (line 6) 48974* INCLUDE_DEFAULTS: Driver. (line 331) 48975* inclusive-or, bitwise: Arithmetic. (line 163) 48976* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 179) 48977* INCOMING_REGNO: Register Basics. (line 86) 48978* INCOMING_REG_PARM_STACK_SPACE: Stack Arguments. (line 73) 48979* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 135) 48980* INCOMING_STACK_BOUNDARY: Storage Layout. (line 154) 48981* INDEX_REG_CLASS: Register Classes. (line 140) 48982* indirect_jump instruction pattern: Standard Names. (line 1454) 48983* indirect_operand: Machine-Independent Predicates. 48984 (line 70) 48985* INDIRECT_REF: Storage References. (line 6) 48986* initialization routines: Initialization. (line 6) 48987* INITIAL_ELIMINATION_OFFSET: Elimination. (line 84) 48988* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 77) 48989* INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 34) 48990* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 106) 48991* INIT_CUMULATIVE_ARGS: Register Arguments. (line 161) 48992* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 189) 48993* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 183) 48994* INIT_ENVIRONMENT: Driver. (line 309) 48995* INIT_EXPANDERS: Per-Function Data. (line 36) 48996* INIT_EXPR: Unary and Binary Expressions. 48997 (line 6) 48998* init_machine_status: Per-Function Data. (line 42) 48999* init_one_libfunc: Library Calls. (line 15) 49000* INIT_SECTION_ASM_OP: Sections. (line 90) 49001* INIT_SECTION_ASM_OP <1>: Macros for Initialization. 49002 (line 9) 49003* inlining: Target Attributes. (line 95) 49004* insert_insn_on_edge: Maintaining the CFG. 49005 (line 105) 49006* insn: Insns. (line 63) 49007* insn and /f: Flags. (line 107) 49008* insn and /j: Flags. (line 157) 49009* insn and /s: Flags. (line 49) 49010* insn and /s <1>: Flags. (line 148) 49011* insn and /u: Flags. (line 39) 49012* insn and /v: Flags. (line 44) 49013* insn attributes: Insn Attributes. (line 6) 49014* insn canonicalization: Insn Canonicalizations. 49015 (line 6) 49016* insn includes: Including Patterns. (line 6) 49017* insn lengths, computing: Insn Lengths. (line 6) 49018* insn notes, notes: Basic Blocks. (line 52) 49019* insn splitting: Insn Splitting. (line 6) 49020* insn-attr.h: Defining Attributes. 49021 (line 34) 49022* insns: Insns. (line 6) 49023* insns, generating: RTL Template. (line 6) 49024* insns, recognizing: RTL Template. (line 6) 49025* INSN_ANNULLED_BRANCH_P: Flags. (line 39) 49026* INSN_CODE: Insns. (line 295) 49027* INSN_DELETED_P: Flags. (line 44) 49028* INSN_FROM_TARGET_P: Flags. (line 49) 49029* insn_list: Insns. (line 540) 49030* INSN_REFERENCES_ARE_DELAYED: Misc. (line 469) 49031* INSN_SETS_ARE_DELAYED: Misc. (line 458) 49032* INSN_UID: Insns. (line 23) 49033* INSN_VAR_LOCATION: Insns. (line 236) 49034* instruction attributes: Insn Attributes. (line 6) 49035* instruction latency time: Processor pipeline description. 49036 (line 6) 49037* instruction latency time <1>: Processor pipeline description. 49038 (line 105) 49039* instruction latency time <2>: Processor pipeline description. 49040 (line 196) 49041* instruction patterns: Patterns. (line 6) 49042* instruction splitting: Insn Splitting. (line 6) 49043* insv instruction pattern: Standard Names. (line 1239) 49044* insvM instruction pattern: Standard Names. (line 1191) 49045* insvmisalignM instruction pattern: Standard Names. (line 1201) 49046* int iterators in .md files: Int Iterators. (line 6) 49047* INT16_TYPE: Type Layout. (line 216) 49048* INT32_TYPE: Type Layout. (line 217) 49049* INT64_TYPE: Type Layout. (line 218) 49050* INT8_TYPE: Type Layout. (line 215) 49051* INTEGER_CST: Constant expressions. 49052 (line 6) 49053* INTEGER_TYPE: Types. (line 6) 49054* Interdependence of Patterns: Dependent Patterns. (line 6) 49055* interfacing to GCC output: Interface. (line 6) 49056* interlock delays: Processor pipeline description. 49057 (line 6) 49058* intermediate representation lowering: Parsing pass. (line 13) 49059* INTMAX_TYPE: Type Layout. (line 192) 49060* INTPTR_TYPE: Type Layout. (line 239) 49061* introduction: Top. (line 6) 49062* INT_FAST16_TYPE: Type Layout. (line 232) 49063* INT_FAST32_TYPE: Type Layout. (line 233) 49064* INT_FAST64_TYPE: Type Layout. (line 234) 49065* INT_FAST8_TYPE: Type Layout. (line 231) 49066* INT_LEAST16_TYPE: Type Layout. (line 224) 49067* INT_LEAST32_TYPE: Type Layout. (line 225) 49068* INT_LEAST64_TYPE: Type Layout. (line 226) 49069* INT_LEAST8_TYPE: Type Layout. (line 223) 49070* INT_TYPE_SIZE: Type Layout. (line 11) 49071* INVOKE__main: Macros for Initialization. 49072 (line 50) 49073* in_struct: Flags. (line 245) 49074* in_struct, in code_label and note: Flags. (line 59) 49075* in_struct, in insn and jump_insn and call_insn: Flags. (line 49) 49076* in_struct, in insn, call_insn, jump_insn and jump_table_data: Flags. 49077 (line 148) 49078* in_struct, in subreg: Flags. (line 187) 49079* ior: Arithmetic. (line 163) 49080* ior and attributes: Expressions. (line 50) 49081* ior, canonicalization of: Insn Canonicalizations. 49082 (line 51) 49083* iorM3 instruction pattern: Standard Names. (line 301) 49084* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 44) 49085* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 123) 49086* is_gimple_addressable: Logical Operators. (line 113) 49087* is_gimple_asm_val: Logical Operators. (line 117) 49088* is_gimple_assign: Logical Operators. (line 149) 49089* is_gimple_call: Logical Operators. (line 152) 49090* is_gimple_call_addr: Logical Operators. (line 120) 49091* is_gimple_constant: Logical Operators. (line 128) 49092* is_gimple_debug: Logical Operators. (line 155) 49093* is_gimple_ip_invariant: Logical Operators. (line 137) 49094* is_gimple_ip_invariant_address: Logical Operators. (line 142) 49095* is_gimple_mem_ref_addr: Logical Operators. (line 124) 49096* is_gimple_min_invariant: Logical Operators. (line 131) 49097* is_gimple_omp: Logical Operators. (line 166) 49098* is_gimple_val: Logical Operators. (line 107) 49099* iterators in .md files: Iterators. (line 6) 49100* IV analysis on GIMPLE: Scalar evolutions. (line 6) 49101* IV analysis on RTL: loop-iv. (line 6) 49102* JMP_BUF_SIZE: Exception Region Output. 49103 (line 83) 49104* jump: Flags. (line 286) 49105* jump instruction pattern: Standard Names. (line 1332) 49106* jump instruction patterns: Jump Patterns. (line 6) 49107* jump instructions and set: Side Effects. (line 56) 49108* jump, in call_insn: Flags. (line 161) 49109* jump, in insn: Flags. (line 157) 49110* jump, in mem: Flags. (line 70) 49111* Jumps: Jumps. (line 6) 49112* JUMP_ALIGN: Alignment Output. (line 8) 49113* jump_insn: Insns. (line 73) 49114* jump_insn and /f: Flags. (line 107) 49115* jump_insn and /s: Flags. (line 49) 49116* jump_insn and /s <1>: Flags. (line 148) 49117* jump_insn and /u: Flags. (line 39) 49118* jump_insn and /v: Flags. (line 44) 49119* JUMP_LABEL: Insns. (line 80) 49120* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 150) 49121* jump_table_data: Insns. (line 166) 49122* jump_table_data and /s: Flags. (line 148) 49123* jump_table_data and /v: Flags. (line 44) 49124* LABEL_ALIGN: Alignment Output. (line 57) 49125* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 26) 49126* LABEL_ALTERNATE_NAME: Edges. (line 180) 49127* LABEL_ALT_ENTRY_P: Insns. (line 146) 49128* LABEL_DECL: Declarations. (line 6) 49129* LABEL_KIND: Insns. (line 146) 49130* LABEL_NUSES: Insns. (line 142) 49131* LABEL_PRESERVE_P: Flags. (line 59) 49132* label_ref: Constants. (line 127) 49133* label_ref and /v: Flags. (line 65) 49134* label_ref, RTL sharing: Sharing. (line 35) 49135* LABEL_REF_NONLOCAL_P: Flags. (line 65) 49136* language-dependent trees: Language-dependent trees. 49137 (line 6) 49138* language-independent intermediate representation: Parsing pass. 49139 (line 13) 49140* lang_hooks.gimplify_expr: Gimplification pass. 49141 (line 18) 49142* lang_hooks.parse_file: Parsing pass. (line 6) 49143* large return values: Aggregate Return. (line 6) 49144* LAST_STACK_REG: Stack Registers. (line 30) 49145* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 49146* lceilMN2: Standard Names. (line 860) 49147* LCSSA: LCSSA. (line 6) 49148* LDD_SUFFIX: Macros for Initialization. 49149 (line 121) 49150* ldexpM3 instruction pattern: Standard Names. (line 653) 49151* LD_FINI_SWITCH: Macros for Initialization. 49152 (line 28) 49153* LD_INIT_SWITCH: Macros for Initialization. 49154 (line 24) 49155* le: Comparisons. (line 76) 49156* le and attributes: Expressions. (line 83) 49157* leaf functions: Leaf Functions. (line 6) 49158* leaf_function_p: Standard Names. (line 1416) 49159* LEAF_REGISTERS: Leaf Functions. (line 23) 49160* LEAF_REG_REMAP: Leaf Functions. (line 37) 49161* left rotate: Arithmetic. (line 195) 49162* left shift: Arithmetic. (line 173) 49163* LEGITIMATE_PIC_OPERAND_P: PIC. (line 31) 49164* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 150) 49165* length: GTY Options. (line 47) 49166* less than: Comparisons. (line 68) 49167* less than or equal: Comparisons. (line 76) 49168* leu: Comparisons. (line 76) 49169* leu and attributes: Expressions. (line 83) 49170* LE_EXPR: Unary and Binary Expressions. 49171 (line 6) 49172* lfloorMN2: Standard Names. (line 855) 49173* LIB2FUNCS_EXTRA: Target Fragment. (line 11) 49174* LIBCALL_VALUE: Scalar Return. (line 56) 49175* libgcc.a: Library Calls. (line 6) 49176* LIBGCC2_CFLAGS: Target Fragment. (line 8) 49177* LIBGCC2_GNU_PREFIX: Type Layout. (line 102) 49178* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 1090) 49179* LIBGCC_SPEC: Driver. (line 115) 49180* library subroutine names: Library Calls. (line 6) 49181* LIBRARY_PATH_ENV: Misc. (line 510) 49182* LIB_SPEC: Driver. (line 107) 49183* LIMIT_RELOAD_CLASS: Register Classes. (line 296) 49184* LINK_COMMAND_SPEC: Driver. (line 240) 49185* LINK_EH_SPEC: Driver. (line 142) 49186* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 232) 49187* LINK_LIBGCC_SPECIAL_1: Driver. (line 227) 49188* LINK_SPEC: Driver. (line 100) 49189* list: Containers. (line 6) 49190* Liveness representation: Liveness information. 49191 (line 6) 49192* load address instruction: Simple Constraints. (line 162) 49193* LOAD_EXTEND_OP: Misc. (line 59) 49194* load_multiple instruction pattern: Standard Names. (line 136) 49195* Local Register Allocator (LRA): RTL passes. (line 187) 49196* LOCAL_ALIGNMENT: Storage Layout. (line 254) 49197* LOCAL_CLASS_P: Classes. (line 73) 49198* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 291) 49199* LOCAL_INCLUDE_DIR: Driver. (line 316) 49200* LOCAL_LABEL_PREFIX: Instruction Output. (line 151) 49201* LOCAL_REGNO: Register Basics. (line 100) 49202* log10M2 instruction pattern: Standard Names. (line 757) 49203* log1pM2 instruction pattern: Standard Names. (line 747) 49204* log2M2 instruction pattern: Standard Names. (line 764) 49205* logbM2 instruction pattern: Standard Names. (line 771) 49206* Logical Operators: Logical Operators. (line 6) 49207* logical-and, bitwise: Arithmetic. (line 158) 49208* LOGICAL_OP_NON_SHORT_CIRCUIT: Costs. (line 273) 49209* logM2 instruction pattern: Standard Names. (line 740) 49210* LOG_LINKS: Insns. (line 314) 49211* longjmp and automatic variables: Interface. (line 52) 49212* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 92) 49213* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 57) 49214* LONG_FRACT_TYPE_SIZE: Type Layout. (line 72) 49215* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 97) 49216* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 77) 49217* LONG_LONG_TYPE_SIZE: Type Layout. (line 32) 49218* LONG_TYPE_SIZE: Type Layout. (line 21) 49219* Loop analysis: Loop representation. 49220 (line 6) 49221* Loop manipulation: Loop manipulation. (line 6) 49222* Loop querying: Loop querying. (line 6) 49223* Loop representation: Loop representation. 49224 (line 6) 49225* Loop-closed SSA form: LCSSA. (line 6) 49226* looping instruction patterns: Looping Patterns. (line 6) 49227* LOOP_ALIGN: Alignment Output. (line 40) 49228* LOOP_EXPR: Unary and Binary Expressions. 49229 (line 6) 49230* lowering, language-dependent intermediate representation: Parsing pass. 49231 (line 13) 49232* lo_sum: Arithmetic. (line 25) 49233* lrintMN2: Standard Names. (line 845) 49234* lroundMN2: Standard Names. (line 850) 49235* lshiftrt: Arithmetic. (line 190) 49236* lshiftrt and attributes: Expressions. (line 83) 49237* LSHIFT_EXPR: Unary and Binary Expressions. 49238 (line 6) 49239* lshrM3 instruction pattern: Standard Names. (line 591) 49240* lt: Comparisons. (line 68) 49241* lt and attributes: Expressions. (line 83) 49242* LTGT_EXPR: Unary and Binary Expressions. 49243 (line 6) 49244* lto: LTO. (line 6) 49245* ltrans: LTO. (line 6) 49246* ltu: Comparisons. (line 68) 49247* LT_EXPR: Unary and Binary Expressions. 49248 (line 6) 49249* m in constraint: Simple Constraints. (line 17) 49250* machine attributes: Target Attributes. (line 6) 49251* machine description macros: Target Macros. (line 6) 49252* machine descriptions: Machine Desc. (line 6) 49253* machine mode conversions: Conversions. (line 6) 49254* machine modes: Machine Modes. (line 6) 49255* machine specific constraints: Machine Constraints. 49256 (line 6) 49257* machine-independent predicates: Machine-Independent Predicates. 49258 (line 6) 49259* machine_mode: Machine Modes. (line 6) 49260* macros, target description: Target Macros. (line 6) 49261* maddMN4 instruction pattern: Standard Names. (line 512) 49262* makefile fragment: Fragments. (line 6) 49263* makefile targets: Makefile. (line 6) 49264* MAKE_DECL_ONE_ONLY: Label Output. (line 281) 49265* make_safe_from: Expander Definitions. 49266 (line 151) 49267* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 173) 49268* Manipulating GIMPLE statements: Manipulating GIMPLE statements. 49269 (line 6) 49270* marking roots: GGC Roots. (line 6) 49271* maskloadMN instruction pattern: Standard Names. (line 244) 49272* maskstoreMN instruction pattern: Standard Names. (line 251) 49273* MASK_RETURN_ADDR: Exception Region Output. 49274 (line 35) 49275* Match and Simplify: Match and Simplify. (line 6) 49276* matching constraint: Simple Constraints. (line 140) 49277* matching operands: Output Template. (line 49) 49278* match_dup: RTL Template. (line 73) 49279* match_dup <1>: define_peephole2. (line 28) 49280* match_dup and attributes: Insn Lengths. (line 16) 49281* match_operand: RTL Template. (line 16) 49282* match_operand and attributes: Expressions. (line 55) 49283* match_operator: RTL Template. (line 95) 49284* match_op_dup: RTL Template. (line 163) 49285* match_parallel: RTL Template. (line 172) 49286* match_par_dup: RTL Template. (line 219) 49287* match_scratch: RTL Template. (line 58) 49288* match_scratch <1>: define_peephole2. (line 28) 49289* match_test and attributes: Expressions. (line 64) 49290* math library: Soft float library routines. 49291 (line 6) 49292* math, in RTL: Arithmetic. (line 6) 49293* matherr: Library Calls. (line 59) 49294* MATH_LIBRARY: Misc. (line 503) 49295* maxM3 instruction pattern: Standard Names. (line 363) 49296* MAX_BITSIZE_MODE_ANY_INT: Machine Modes. (line 358) 49297* MAX_BITSIZE_MODE_ANY_MODE: Machine Modes. (line 364) 49298* MAX_BITS_PER_WORD: Storage Layout. (line 54) 49299* MAX_CONDITIONAL_EXECUTE: Misc. (line 525) 49300* MAX_FIXED_MODE_SIZE: Storage Layout. (line 436) 49301* MAX_MOVE_MAX: Misc. (line 105) 49302* MAX_OFILE_ALIGNMENT: Storage Layout. (line 208) 49303* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42) 49304* MAX_STACK_ALIGNMENT: Storage Layout. (line 202) 49305* maybe_undef: GTY Options. (line 139) 49306* may_trap_p, tree_could_trap_p: Edges. (line 114) 49307* mcount: Profiling. (line 12) 49308* MD_EXEC_PREFIX: Driver. (line 271) 49309* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 93) 49310* MD_HANDLE_UNWABI: Exception Handling. (line 112) 49311* MD_STARTFILE_PREFIX: Driver. (line 299) 49312* MD_STARTFILE_PREFIX_1: Driver. (line 304) 49313* mem: Regs and Memory. (line 370) 49314* mem and /c: Flags. (line 81) 49315* mem and /f: Flags. (line 85) 49316* mem and /j: Flags. (line 70) 49317* mem and /u: Flags. (line 134) 49318* mem and /v: Flags. (line 76) 49319* mem, RTL sharing: Sharing. (line 40) 49320* memory model: Memory model. (line 6) 49321* memory reference, nonoffsettable: Simple Constraints. (line 254) 49322* memory references in constraints: Simple Constraints. (line 17) 49323* memory_barrier instruction pattern: Standard Names. (line 1802) 49324* MEMORY_MOVE_COST: Costs. (line 53) 49325* memory_operand: Machine-Independent Predicates. 49326 (line 57) 49327* MEM_ADDR_SPACE: Special Accessors. (line 48) 49328* MEM_ALIAS_SET: Special Accessors. (line 9) 49329* MEM_ALIGN: Special Accessors. (line 45) 49330* MEM_EXPR: Special Accessors. (line 19) 49331* MEM_KEEP_ALIAS_SET_P: Flags. (line 70) 49332* MEM_NOTRAP_P: Flags. (line 81) 49333* MEM_OFFSET: Special Accessors. (line 31) 49334* MEM_OFFSET_KNOWN_P: Special Accessors. (line 27) 49335* MEM_POINTER: Flags. (line 85) 49336* MEM_READONLY_P: Flags. (line 134) 49337* MEM_REF: Storage References. (line 6) 49338* mem_signal_fenceMODE instruction pattern: Standard Names. (line 2061) 49339* MEM_SIZE: Special Accessors. (line 39) 49340* MEM_SIZE_KNOWN_P: Special Accessors. (line 35) 49341* mem_thread_fenceMODE instruction pattern: Standard Names. (line 2053) 49342* MEM_VOLATILE_P: Flags. (line 76) 49343* METHOD_TYPE: Types. (line 6) 49344* MINIMUM_ALIGNMENT: Storage Layout. (line 304) 49345* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 181) 49346* minM3 instruction pattern: Standard Names. (line 363) 49347* minus: Arithmetic. (line 38) 49348* minus and attributes: Expressions. (line 83) 49349* minus, canonicalization of: Insn Canonicalizations. 49350 (line 27) 49351* MINUS_EXPR: Unary and Binary Expressions. 49352 (line 6) 49353* MIN_UNITS_PER_WORD: Storage Layout. (line 64) 49354* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 49355* miscellaneous register hooks: Miscellaneous Register Hooks. 49356 (line 6) 49357* mnemonic attribute: Mnemonic Attribute. (line 6) 49358* mod: Arithmetic. (line 136) 49359* mod and attributes: Expressions. (line 83) 49360* mode classes: Machine Modes. (line 225) 49361* mode iterators in .md files: Mode Iterators. (line 6) 49362* mode switching: Mode Switching. (line 6) 49363* MODES_TIEABLE_P: Values in Registers. 49364 (line 127) 49365* MODE_ACCUM: Machine Modes. (line 255) 49366* MODE_BASE_REG_CLASS: Register Classes. (line 116) 49367* MODE_BASE_REG_REG_CLASS: Register Classes. (line 122) 49368* MODE_CC: Machine Modes. (line 274) 49369* MODE_CC <1>: MODE_CC Condition Codes. 49370 (line 6) 49371* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 129) 49372* MODE_COMPLEX_FLOAT: Machine Modes. (line 266) 49373* MODE_COMPLEX_INT: Machine Modes. (line 263) 49374* MODE_DECIMAL_FLOAT: Machine Modes. (line 243) 49375* MODE_FLOAT: Machine Modes. (line 239) 49376* MODE_FRACT: Machine Modes. (line 247) 49377* MODE_FUNCTION: Machine Modes. (line 270) 49378* MODE_INT: Machine Modes. (line 231) 49379* MODE_PARTIAL_INT: Machine Modes. (line 235) 49380* MODE_POINTER_BOUNDS: Machine Modes. (line 279) 49381* MODE_RANDOM: Machine Modes. (line 284) 49382* MODE_UACCUM: Machine Modes. (line 259) 49383* MODE_UFRACT: Machine Modes. (line 251) 49384* modifiers in constraints: Modifiers. (line 6) 49385* MODIFY_EXPR: Unary and Binary Expressions. 49386 (line 6) 49387* MODIFY_JNI_METHOD_CALL: Misc. (line 874) 49388* modM3 instruction pattern: Standard Names. (line 301) 49389* modulo scheduling: RTL passes. (line 123) 49390* MOVE_MAX: Misc. (line 100) 49391* MOVE_MAX_PIECES: Costs. (line 199) 49392* MOVE_RATIO: Costs. (line 148) 49393* movM instruction pattern: Standard Names. (line 11) 49394* movmemM instruction pattern: Standard Names. (line 959) 49395* movmisalignM instruction pattern: Standard Names. (line 125) 49396* movMODEcc instruction pattern: Standard Names. (line 1253) 49397* movstr instruction pattern: Standard Names. (line 994) 49398* movstrictM instruction pattern: Standard Names. (line 119) 49399* msubMN4 instruction pattern: Standard Names. (line 535) 49400* mulhisi3 instruction pattern: Standard Names. (line 488) 49401* mulM3 instruction pattern: Standard Names. (line 301) 49402* mulqihi3 instruction pattern: Standard Names. (line 492) 49403* mulsidi3 instruction pattern: Standard Names. (line 492) 49404* mult: Arithmetic. (line 93) 49405* mult and attributes: Expressions. (line 83) 49406* mult, canonicalization of: Insn Canonicalizations. 49407 (line 27) 49408* mult, canonicalization of <1>: Insn Canonicalizations. 49409 (line 91) 49410* MULTIARCH_DIRNAME: Target Fragment. (line 170) 49411* MULTILIB_DEFAULTS: Driver. (line 256) 49412* MULTILIB_DIRNAMES: Target Fragment. (line 44) 49413* MULTILIB_EXCEPTIONS: Target Fragment. (line 70) 49414* MULTILIB_EXTRA_OPTS: Target Fragment. (line 132) 49415* MULTILIB_MATCHES: Target Fragment. (line 63) 49416* MULTILIB_OPTIONS: Target Fragment. (line 24) 49417* MULTILIB_OSDIRNAMES: Target Fragment. (line 139) 49418* MULTILIB_REQUIRED: Target Fragment. (line 82) 49419* MULTILIB_REUSE: Target Fragment. (line 103) 49420* multiple alternative constraints: Multi-Alternative. (line 6) 49421* MULTIPLE_SYMBOL_SPACES: Misc. (line 482) 49422* multiplication: Arithmetic. (line 93) 49423* multiplication with signed saturation: Arithmetic. (line 93) 49424* multiplication with unsigned saturation: Arithmetic. (line 93) 49425* MULT_EXPR: Unary and Binary Expressions. 49426 (line 6) 49427* MULT_HIGHPART_EXPR: Unary and Binary Expressions. 49428 (line 6) 49429* mulvM4 instruction pattern: Standard Names. (line 317) 49430* n in constraint: Simple Constraints. (line 73) 49431* name: Identifiers. (line 6) 49432* named address spaces: Named Address Spaces. 49433 (line 6) 49434* named patterns and conditions: Patterns. (line 49) 49435* names, pattern: Standard Names. (line 6) 49436* namespace, scope: Namespaces. (line 6) 49437* NAMESPACE_DECL: Declarations. (line 6) 49438* NAMESPACE_DECL <1>: Namespaces. (line 6) 49439* NATIVE_SYSTEM_HEADER_COMPONENT: Driver. (line 326) 49440* ne: Comparisons. (line 56) 49441* ne and attributes: Expressions. (line 83) 49442* nearbyintM2 instruction pattern: Standard Names. (line 829) 49443* neg: Arithmetic. (line 82) 49444* neg and attributes: Expressions. (line 83) 49445* neg, canonicalization of: Insn Canonicalizations. 49446 (line 27) 49447* NEGATE_EXPR: Unary and Binary Expressions. 49448 (line 6) 49449* negation: Arithmetic. (line 82) 49450* negation with signed saturation: Arithmetic. (line 82) 49451* negation with unsigned saturation: Arithmetic. (line 82) 49452* negM2 instruction pattern: Standard Names. (line 603) 49453* negMODEcc instruction pattern: Standard Names. (line 1273) 49454* negvM3 instruction pattern: Standard Names. (line 606) 49455* nested functions, trampolines for: Trampolines. (line 6) 49456* nested_ptr: GTY Options. (line 147) 49457* next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks. (line 25) 49458* NEXT_INSN: Insns. (line 30) 49459* NEXT_OBJC_RUNTIME: Library Calls. (line 82) 49460* NE_EXPR: Unary and Binary Expressions. 49461 (line 6) 49462* nil: RTL Objects. (line 73) 49463* NM_FLAGS: Macros for Initialization. 49464 (line 110) 49465* nondeterministic finite state automaton: Processor pipeline description. 49466 (line 304) 49467* nonimmediate_operand: Machine-Independent Predicates. 49468 (line 100) 49469* nonlocal goto handler: Edges. (line 171) 49470* nonlocal_goto instruction pattern: Standard Names. (line 1636) 49471* nonlocal_goto_receiver instruction pattern: Standard Names. 49472 (line 1653) 49473* nonmemory_operand: Machine-Independent Predicates. 49474 (line 96) 49475* nonoffsettable memory reference: Simple Constraints. (line 254) 49476* NON_LVALUE_EXPR: Unary and Binary Expressions. 49477 (line 6) 49478* nop instruction pattern: Standard Names. (line 1449) 49479* NOP_EXPR: Unary and Binary Expressions. 49480 (line 6) 49481* normal predicates: Predicates. (line 31) 49482* not: Arithmetic. (line 154) 49483* not and attributes: Expressions. (line 50) 49484* not equal: Comparisons. (line 56) 49485* not, canonicalization of: Insn Canonicalizations. 49486 (line 27) 49487* note: Insns. (line 183) 49488* note and /i: Flags. (line 59) 49489* note and /v: Flags. (line 44) 49490* NOTE_INSN_BASIC_BLOCK: Basic Blocks. (line 50) 49491* NOTE_INSN_BASIC_BLOCK <1>: Basic Blocks. (line 52) 49492* NOTE_INSN_BLOCK_BEG: Insns. (line 208) 49493* NOTE_INSN_BLOCK_END: Insns. (line 208) 49494* NOTE_INSN_DELETED: Insns. (line 198) 49495* NOTE_INSN_DELETED_LABEL: Insns. (line 203) 49496* NOTE_INSN_EH_REGION_BEG: Insns. (line 214) 49497* NOTE_INSN_EH_REGION_END: Insns. (line 214) 49498* NOTE_INSN_FUNCTION_BEG: Insns. (line 221) 49499* NOTE_INSN_VAR_LOCATION: Insns. (line 225) 49500* NOTE_LINE_NUMBER: Insns. (line 183) 49501* NOTE_SOURCE_FILE: Insns. (line 183) 49502* NOTE_VAR_LOCATION: Insns. (line 225) 49503* NOTICE_UPDATE_CC: CC0 Condition Codes. 49504 (line 30) 49505* notMODEcc instruction pattern: Standard Names. (line 1280) 49506* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 25) 49507* NO_DBX_FUNCTION_END: DBX Hooks. (line 19) 49508* NO_DBX_GCC_MARKER: File Names and DBX. (line 27) 49509* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 22) 49510* NO_DOLLAR_IN_LABEL: Label Output. (line 64) 49511* NO_DOT_IN_LABEL: Label Output. (line 70) 49512* NO_FUNCTION_CSE: Costs. (line 268) 49513* NO_IMPLICIT_EXTERN_C: Misc. (line 381) 49514* NO_PROFILE_COUNTERS: Profiling. (line 27) 49515* NO_REGS: Register Classes. (line 17) 49516* Number of iterations analysis: Number of iterations. 49517 (line 6) 49518* NUM_MACHINE_MODES: Machine Modes. (line 297) 49519* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 49520* N_REG_CLASSES: Register Classes. (line 81) 49521* o in constraint: Simple Constraints. (line 23) 49522* OACC_CACHE: OpenACC. (line 6) 49523* OACC_DATA: OpenACC. (line 6) 49524* OACC_DECLARE: OpenACC. (line 6) 49525* OACC_ENTER_DATA: OpenACC. (line 6) 49526* OACC_EXIT_DATA: OpenACC. (line 6) 49527* OACC_HOST_DATA: OpenACC. (line 6) 49528* OACC_KERNELS: OpenACC. (line 6) 49529* OACC_LOOP: OpenACC. (line 6) 49530* OACC_PARALLEL: OpenACC. (line 6) 49531* OACC_UPDATE: OpenACC. (line 6) 49532* OBJC_GEN_METHOD_LABEL: Label Output. (line 482) 49533* OBJC_JBLEN: Misc. (line 1085) 49534* OBJECT_FORMAT_COFF: Macros for Initialization. 49535 (line 96) 49536* offsettable address: Simple Constraints. (line 23) 49537* OFFSET_TYPE: Types. (line 6) 49538* OImode: Machine Modes. (line 51) 49539* OMP_ATOMIC: OpenMP. (line 6) 49540* OMP_CLAUSE: OpenMP. (line 6) 49541* OMP_CONTINUE: OpenMP. (line 6) 49542* OMP_CRITICAL: OpenMP. (line 6) 49543* OMP_FOR: OpenMP. (line 6) 49544* OMP_MASTER: OpenMP. (line 6) 49545* OMP_ORDERED: OpenMP. (line 6) 49546* OMP_PARALLEL: OpenMP. (line 6) 49547* OMP_RETURN: OpenMP. (line 6) 49548* OMP_SECTION: OpenMP. (line 6) 49549* OMP_SECTIONS: OpenMP. (line 6) 49550* OMP_SINGLE: OpenMP. (line 6) 49551* one_cmplM2 instruction pattern: Standard Names. (line 956) 49552* operand access: Accessors. (line 6) 49553* Operand Access Routines: SSA Operands. (line 116) 49554* operand constraints: Constraints. (line 6) 49555* Operand Iterators: SSA Operands. (line 116) 49556* operand predicates: Predicates. (line 6) 49557* operand substitution: Output Template. (line 6) 49558* Operands: Operands. (line 6) 49559* operands: SSA Operands. (line 6) 49560* operands <1>: Patterns. (line 55) 49561* operator predicates: Predicates. (line 6) 49562* optc-gen.awk: Options. (line 6) 49563* OPTGROUP_ALL: Optimization groups. 49564 (line 25) 49565* OPTGROUP_INLINE: Optimization groups. 49566 (line 15) 49567* OPTGROUP_IPA: Optimization groups. 49568 (line 9) 49569* OPTGROUP_LOOP: Optimization groups. 49570 (line 12) 49571* OPTGROUP_OTHER: Optimization groups. 49572 (line 21) 49573* OPTGROUP_VEC: Optimization groups. 49574 (line 18) 49575* optimization dumps: Optimization info. (line 6) 49576* optimization groups: Optimization groups. 49577 (line 6) 49578* optimization info file names: Dump files and streams. 49579 (line 6) 49580* Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 49581* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 8) 49582* option specification files: Options. (line 6) 49583* optional hardware or system features: Run-time Target. (line 59) 49584* options, directory search: Including Patterns. (line 47) 49585* OPTION_DEFAULT_SPECS: Driver. (line 25) 49586* order of register allocation: Allocation Order. (line 6) 49587* ordered_comparison_operator: Machine-Independent Predicates. 49588 (line 115) 49589* ORDERED_EXPR: Unary and Binary Expressions. 49590 (line 6) 49591* Ordering of Patterns: Pattern Ordering. (line 6) 49592* ORIGINAL_REGNO: Special Accessors. (line 53) 49593* other register constraints: Simple Constraints. (line 171) 49594* outgoing_args_size: Stack Arguments. (line 48) 49595* OUTGOING_REGNO: Register Basics. (line 93) 49596* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 79) 49597* output of assembler code: File Framework. (line 6) 49598* output statements: Output Statement. (line 6) 49599* output templates: Output Template. (line 6) 49600* output_asm_insn: Output Statement. (line 52) 49601* OUTPUT_QUOTED_STRING: File Framework. (line 106) 49602* OVERLAPPING_REGISTER_NAMES: Instruction Output. (line 20) 49603* OVERLOAD: Functions for C++. (line 6) 49604* OVERRIDE_ABI_FORMAT: Register Arguments. (line 153) 49605* OVL_CURRENT: Functions for C++. (line 6) 49606* OVL_NEXT: Functions for C++. (line 6) 49607* p in constraint: Simple Constraints. (line 162) 49608* PAD_VARARGS_DOWN: Register Arguments. (line 234) 49609* parallel: Side Effects. (line 210) 49610* parameters, c++ abi: C++ ABI. (line 6) 49611* parameters, miscellaneous: Misc. (line 6) 49612* parameters, precompiled headers: PCH Target. (line 6) 49613* parity: Arithmetic. (line 242) 49614* parityM2 instruction pattern: Standard Names. (line 943) 49615* PARM_BOUNDARY: Storage Layout. (line 133) 49616* PARM_DECL: Declarations. (line 6) 49617* PARSE_LDD_OUTPUT: Macros for Initialization. 49618 (line 125) 49619* pass dumps: Passes. (line 6) 49620* passes and files of the compiler: Passes. (line 6) 49621* passing arguments: Interface. (line 36) 49622* pass_duplicate_computed_gotos: Edges. (line 161) 49623* PATH_SEPARATOR: Filesystem. (line 31) 49624* PATTERN: Insns. (line 284) 49625* pattern conditions: Patterns. (line 43) 49626* pattern names: Standard Names. (line 6) 49627* Pattern Ordering: Pattern Ordering. (line 6) 49628* patterns: Patterns. (line 6) 49629* pc: Regs and Memory. (line 357) 49630* pc and attributes: Insn Lengths. (line 20) 49631* pc, RTL sharing: Sharing. (line 25) 49632* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 330) 49633* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 64) 49634* PC_REGNUM: Register Basics. (line 107) 49635* pc_rtx: Regs and Memory. (line 362) 49636* PDImode: Machine Modes. (line 40) 49637* peephole optimization, RTL representation: Side Effects. (line 244) 49638* peephole optimizer definitions: Peephole Definitions. 49639 (line 6) 49640* per-function data: Per-Function Data. (line 6) 49641* percent sign: Output Template. (line 6) 49642* PHI nodes: SSA. (line 31) 49643* PIC: PIC. (line 6) 49644* PIC_OFFSET_TABLE_REGNUM: PIC. (line 15) 49645* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 25) 49646* pipeline hazard recognizer: Processor pipeline description. 49647 (line 6) 49648* pipeline hazard recognizer <1>: Processor pipeline description. 49649 (line 53) 49650* Plugins: Plugins. (line 6) 49651* plus: Arithmetic. (line 14) 49652* plus and attributes: Expressions. (line 83) 49653* plus, canonicalization of: Insn Canonicalizations. 49654 (line 27) 49655* PLUS_EXPR: Unary and Binary Expressions. 49656 (line 6) 49657* Pmode: Misc. (line 329) 49658* pmode_register_operand: Machine-Independent Predicates. 49659 (line 34) 49660* pointer: Types. (line 6) 49661* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 76) 49662* POINTER_PLUS_EXPR: Unary and Binary Expressions. 49663 (line 6) 49664* POINTER_SIZE: Storage Layout. (line 70) 49665* POINTER_TYPE: Types. (line 6) 49666* popcount: Arithmetic. (line 238) 49667* popcountM2 instruction pattern: Standard Names. (line 931) 49668* pops_args: Function Entry. (line 104) 49669* pop_operand: Machine-Independent Predicates. 49670 (line 87) 49671* portability: Portability. (line 6) 49672* position independent code: PIC. (line 6) 49673* POSTDECREMENT_EXPR: Unary and Binary Expressions. 49674 (line 6) 49675* POSTINCREMENT_EXPR: Unary and Binary Expressions. 49676 (line 6) 49677* post_dec: Incdec. (line 25) 49678* post_inc: Incdec. (line 30) 49679* POST_LINK_SPEC: Driver. (line 236) 49680* post_modify: Incdec. (line 33) 49681* post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks. 49682 (line 34) 49683* POWI_MAX_MULTS: Misc. (line 963) 49684* powM3 instruction pattern: Standard Names. (line 785) 49685* pragma: Misc. (line 387) 49686* PREDECREMENT_EXPR: Unary and Binary Expressions. 49687 (line 6) 49688* predefined macros: Run-time Target. (line 6) 49689* predicates: Predicates. (line 6) 49690* predicates and machine modes: Predicates. (line 31) 49691* predication: Conditional Execution. 49692 (line 6) 49693* predict.def: Profile information. 49694 (line 24) 49695* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 41) 49696* PREFERRED_RELOAD_CLASS: Register Classes. (line 249) 49697* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 147) 49698* prefetch: Side Effects. (line 324) 49699* prefetch and /v: Flags. (line 214) 49700* prefetch instruction pattern: Standard Names. (line 1779) 49701* PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 214) 49702* PREINCREMENT_EXPR: Unary and Binary Expressions. 49703 (line 6) 49704* presence_set: Processor pipeline description. 49705 (line 223) 49706* preserving SSA form: SSA. (line 74) 49707* pretend_args_size: Function Entry. (line 110) 49708* prev_active_insn: define_peephole. (line 60) 49709* PREV_INSN: Insns. (line 26) 49710* pre_dec: Incdec. (line 8) 49711* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 126) 49712* pre_inc: Incdec. (line 22) 49713* pre_modify: Incdec. (line 52) 49714* PRINT_OPERAND: Instruction Output. (line 95) 49715* PRINT_OPERAND_ADDRESS: Instruction Output. (line 122) 49716* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 115) 49717* probe_stack instruction pattern: Standard Names. (line 1628) 49718* probe_stack_address instruction pattern: Standard Names. (line 1621) 49719* processor functional units: Processor pipeline description. 49720 (line 6) 49721* processor functional units <1>: Processor pipeline description. 49722 (line 68) 49723* processor pipeline description: Processor pipeline description. 49724 (line 6) 49725* product: Arithmetic. (line 93) 49726* profile feedback: Profile information. 49727 (line 14) 49728* profile representation: Profile information. 49729 (line 6) 49730* PROFILE_BEFORE_PROLOGUE: Profiling. (line 34) 49731* PROFILE_HOOK: Profiling. (line 22) 49732* profiling, code generation: Profiling. (line 6) 49733* program counter: Regs and Memory. (line 358) 49734* prologue: Function Entry. (line 6) 49735* prologue instruction pattern: Standard Names. (line 1717) 49736* PROMOTE_MODE: Storage Layout. (line 87) 49737* pseudo registers: Regs and Memory. (line 9) 49738* PSImode: Machine Modes. (line 32) 49739* PTRDIFF_TYPE: Type Layout. (line 163) 49740* purge_dead_edges: Edges. (line 103) 49741* purge_dead_edges <1>: Maintaining the CFG. 49742 (line 81) 49743* push address instruction: Simple Constraints. (line 162) 49744* pushM1 instruction pattern: Standard Names. (line 288) 49745* PUSH_ARGS: Stack Arguments. (line 17) 49746* PUSH_ARGS_REVERSED: Stack Arguments. (line 25) 49747* push_operand: Machine-Independent Predicates. 49748 (line 80) 49749* push_reload: Addressing Modes. (line 176) 49750* PUSH_ROUNDING: Stack Arguments. (line 31) 49751* PUT_CODE: RTL Objects. (line 47) 49752* PUT_MODE: Machine Modes. (line 294) 49753* PUT_REG_NOTE_KIND: Insns. (line 346) 49754* PUT_SDB_...: SDB and DWARF. (line 114) 49755* QCmode: Machine Modes. (line 199) 49756* QFmode: Machine Modes. (line 57) 49757* QImode: Machine Modes. (line 25) 49758* QImode, in insn: Insns. (line 268) 49759* QQmode: Machine Modes. (line 106) 49760* qualified type: Types. (line 6) 49761* qualified type <1>: Types for C++. (line 6) 49762* querying function unit reservations: Processor pipeline description. 49763 (line 90) 49764* question mark: Multi-Alternative. (line 42) 49765* quotient: Arithmetic. (line 116) 49766* r in constraint: Simple Constraints. (line 64) 49767* RDIV_EXPR: Unary and Binary Expressions. 49768 (line 6) 49769* READONLY_DATA_SECTION_ASM_OP: Sections. (line 62) 49770* real operands: SSA Operands. (line 6) 49771* REALPART_EXPR: Unary and Binary Expressions. 49772 (line 6) 49773* REAL_CST: Constant expressions. 49774 (line 6) 49775* REAL_LIBGCC_SPEC: Driver. (line 124) 49776* REAL_NM_FILE_NAME: Macros for Initialization. 49777 (line 105) 49778* REAL_TYPE: Types. (line 6) 49779* REAL_VALUE_ABS: Floating Point. (line 58) 49780* REAL_VALUE_ATOF: Floating Point. (line 39) 49781* REAL_VALUE_FIX: Floating Point. (line 31) 49782* REAL_VALUE_ISINF: Floating Point. (line 49) 49783* REAL_VALUE_ISNAN: Floating Point. (line 52) 49784* REAL_VALUE_NEGATE: Floating Point. (line 55) 49785* REAL_VALUE_NEGATIVE: Floating Point. (line 46) 49786* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 147) 49787* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 145) 49788* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 146) 49789* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 143) 49790* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 144) 49791* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 142) 49792* REAL_VALUE_TYPE: Floating Point. (line 25) 49793* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 34) 49794* recognizing insns: RTL Template. (line 6) 49795* recog_data.operand: Instruction Output. (line 54) 49796* RECORD_TYPE: Types. (line 6) 49797* RECORD_TYPE <1>: Classes. (line 6) 49798* redirect_edge_and_branch: Profile information. 49799 (line 71) 49800* redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 49801 (line 90) 49802* reduc_plus_scal_M instruction pattern: Standard Names. (line 390) 49803* reduc_smax_scal_M instruction pattern: Standard Names. (line 380) 49804* reduc_smin_scal_M instruction pattern: Standard Names. (line 380) 49805* reduc_umax_scal_M instruction pattern: Standard Names. (line 385) 49806* reduc_umin_scal_M instruction pattern: Standard Names. (line 385) 49807* reference: Types. (line 6) 49808* REFERENCE_TYPE: Types. (line 6) 49809* reg: Regs and Memory. (line 9) 49810* reg and /f: Flags. (line 94) 49811* reg and /i: Flags. (line 89) 49812* reg and /v: Flags. (line 98) 49813* reg, RTL sharing: Sharing. (line 17) 49814* register allocation order: Allocation Order. (line 6) 49815* register class definitions: Register Classes. (line 6) 49816* register class preference constraints: Class Preferences. (line 6) 49817* register pairs: Values in Registers. 49818 (line 69) 49819* Register Transfer Language (RTL): RTL. (line 6) 49820* register usage: Registers. (line 6) 49821* registers arguments: Register Arguments. (line 6) 49822* registers in constraints: Simple Constraints. (line 64) 49823* REGISTER_MOVE_COST: Costs. (line 9) 49824* REGISTER_NAMES: Instruction Output. (line 8) 49825* register_operand: Machine-Independent Predicates. 49826 (line 29) 49827* REGISTER_PREFIX: Instruction Output. (line 150) 49828* REGISTER_TARGET_PRAGMAS: Misc. (line 387) 49829* REGMODE_NATURAL_SIZE: Values in Registers. 49830 (line 49) 49831* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 172) 49832* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 150) 49833* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 160) 49834* REGNO_OK_FOR_BASE_P: Register Classes. (line 146) 49835* REGNO_OK_FOR_INDEX_P: Register Classes. (line 186) 49836* REGNO_REG_CLASS: Register Classes. (line 105) 49837* regs_ever_live: Function Entry. (line 21) 49838* regular expressions: Processor pipeline description. 49839 (line 6) 49840* regular expressions <1>: Processor pipeline description. 49841 (line 105) 49842* REG_ALLOC_ORDER: Allocation Order. (line 8) 49843* REG_BR_PRED: Insns. (line 526) 49844* REG_BR_PROB: Insns. (line 519) 49845* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 49846 (line 82) 49847* REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 49848 (line 52) 49849* REG_CC_SETTER: Insns. (line 491) 49850* REG_CC_USER: Insns. (line 491) 49851* reg_class_contents: Register Basics. (line 59) 49852* REG_CLASS_CONTENTS: Register Classes. (line 91) 49853* reg_class_for_constraint: C Constraint Interface. 49854 (line 48) 49855* REG_CLASS_NAMES: Register Classes. (line 86) 49856* REG_CROSSING_JUMP: Insns. (line 405) 49857* REG_DEAD: Insns. (line 357) 49858* REG_DEAD, REG_UNUSED: Liveness information. 49859 (line 32) 49860* REG_DEP_ANTI: Insns. (line 513) 49861* REG_DEP_OUTPUT: Insns. (line 509) 49862* REG_DEP_TRUE: Insns. (line 506) 49863* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 109) 49864* REG_EQUAL: Insns. (line 420) 49865* REG_EQUIV: Insns. (line 420) 49866* REG_EXPR: Special Accessors. (line 58) 49867* REG_FRAME_RELATED_EXPR: Insns. (line 532) 49868* REG_FUNCTION_VALUE_P: Flags. (line 89) 49869* REG_INC: Insns. (line 373) 49870* reg_label and /v: Flags. (line 65) 49871* REG_LABEL_OPERAND: Insns. (line 387) 49872* REG_LABEL_TARGET: Insns. (line 396) 49873* reg_names: Register Basics. (line 59) 49874* reg_names <1>: Instruction Output. (line 107) 49875* REG_NONNEG: Insns. (line 379) 49876* REG_NOTES: Insns. (line 321) 49877* REG_NOTE_KIND: Insns. (line 346) 49878* REG_OFFSET: Special Accessors. (line 62) 49879* REG_OK_STRICT: Addressing Modes. (line 99) 49880* REG_PARM_STACK_SPACE: Stack Arguments. (line 58) 49881* REG_PARM_STACK_SPACE, and TARGET_FUNCTION_ARG: Register Arguments. 49882 (line 56) 49883* REG_POINTER: Flags. (line 94) 49884* REG_SETJMP: Insns. (line 414) 49885* REG_UNUSED: Insns. (line 366) 49886* REG_USERVAR_P: Flags. (line 98) 49887* REG_VALUE_IN_UNWIND_CONTEXT: Frame Registers. (line 158) 49888* REG_WORDS_BIG_ENDIAN: Storage Layout. (line 35) 49889* relative costs: Costs. (line 6) 49890* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 266) 49891* reloading: RTL passes. (line 170) 49892* reload_completed: Standard Names. (line 1416) 49893* reload_in instruction pattern: Standard Names. (line 98) 49894* reload_in_progress: Standard Names. (line 57) 49895* reload_out instruction pattern: Standard Names. (line 98) 49896* remainder: Arithmetic. (line 136) 49897* remainderM3 instruction pattern: Standard Names. (line 639) 49898* reorder: GTY Options. (line 173) 49899* representation of RTL: RTL. (line 6) 49900* reservation delays: Processor pipeline description. 49901 (line 6) 49902* restore_stack_block instruction pattern: Standard Names. (line 1542) 49903* restore_stack_function instruction pattern: Standard Names. 49904 (line 1542) 49905* restore_stack_nonlocal instruction pattern: Standard Names. 49906 (line 1542) 49907* rest_of_decl_compilation: Parsing pass. (line 51) 49908* rest_of_type_compilation: Parsing pass. (line 51) 49909* RESULT_DECL: Declarations. (line 6) 49910* return: Side Effects. (line 72) 49911* return instruction pattern: Standard Names. (line 1390) 49912* return values in registers: Scalar Return. (line 6) 49913* returning aggregate values: Aggregate Return. (line 6) 49914* returning structures and unions: Interface. (line 10) 49915* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 64) 49916* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 129) 49917* RETURN_ADDR_OFFSET: Exception Handling. (line 59) 49918* RETURN_ADDR_RTX: Frame Layout. (line 118) 49919* RETURN_EXPR: Statements for C++. (line 6) 49920* RETURN_STMT: Statements for C++. (line 6) 49921* return_val: Flags. (line 274) 49922* return_val, in call_insn: Flags. (line 24) 49923* return_val, in reg: Flags. (line 89) 49924* return_val, in symbol_ref: Flags. (line 202) 49925* reverse probability: Profile information. 49926 (line 66) 49927* REVERSE_CONDITION: MODE_CC Condition Codes. 49928 (line 92) 49929* REVERSIBLE_CC_MODE: MODE_CC Condition Codes. 49930 (line 77) 49931* right rotate: Arithmetic. (line 195) 49932* right shift: Arithmetic. (line 190) 49933* rintM2 instruction pattern: Standard Names. (line 837) 49934* RISC: Processor pipeline description. 49935 (line 6) 49936* RISC <1>: Processor pipeline description. 49937 (line 223) 49938* roots, marking: GGC Roots. (line 6) 49939* rotate: Arithmetic. (line 195) 49940* rotate <1>: Arithmetic. (line 195) 49941* rotatert: Arithmetic. (line 195) 49942* rotlM3 instruction pattern: Standard Names. (line 591) 49943* rotrM3 instruction pattern: Standard Names. (line 591) 49944* roundM2 instruction pattern: Standard Names. (line 814) 49945* ROUND_DIV_EXPR: Unary and Binary Expressions. 49946 (line 6) 49947* ROUND_MOD_EXPR: Unary and Binary Expressions. 49948 (line 6) 49949* ROUND_TYPE_ALIGN: Storage Layout. (line 427) 49950* RSHIFT_EXPR: Unary and Binary Expressions. 49951 (line 6) 49952* rsqrtM2 instruction pattern: Standard Names. (line 619) 49953* RTL addition: Arithmetic. (line 14) 49954* RTL addition with signed saturation: Arithmetic. (line 14) 49955* RTL addition with unsigned saturation: Arithmetic. (line 14) 49956* RTL classes: RTL Classes. (line 6) 49957* RTL comparison: Arithmetic. (line 46) 49958* RTL comparison operations: Comparisons. (line 6) 49959* RTL constant expression types: Constants. (line 6) 49960* RTL constants: Constants. (line 6) 49961* RTL declarations: RTL Declarations. (line 6) 49962* RTL difference: Arithmetic. (line 38) 49963* RTL expression: RTL Objects. (line 6) 49964* RTL expressions for arithmetic: Arithmetic. (line 6) 49965* RTL format: RTL Classes. (line 72) 49966* RTL format characters: RTL Classes. (line 77) 49967* RTL function-call insns: Calls. (line 6) 49968* RTL insn template: RTL Template. (line 6) 49969* RTL integers: RTL Objects. (line 6) 49970* RTL memory expressions: Regs and Memory. (line 6) 49971* RTL object types: RTL Objects. (line 6) 49972* RTL postdecrement: Incdec. (line 6) 49973* RTL postincrement: Incdec. (line 6) 49974* RTL predecrement: Incdec. (line 6) 49975* RTL preincrement: Incdec. (line 6) 49976* RTL register expressions: Regs and Memory. (line 6) 49977* RTL representation: RTL. (line 6) 49978* RTL side effect expressions: Side Effects. (line 6) 49979* RTL strings: RTL Objects. (line 6) 49980* RTL structure sharing assumptions: Sharing. (line 6) 49981* RTL subtraction: Arithmetic. (line 38) 49982* RTL subtraction with signed saturation: Arithmetic. (line 38) 49983* RTL subtraction with unsigned saturation: Arithmetic. (line 38) 49984* RTL sum: Arithmetic. (line 14) 49985* RTL vectors: RTL Objects. (line 6) 49986* RTL_CONST_CALL_P: Flags. (line 19) 49987* RTL_CONST_OR_PURE_CALL_P: Flags. (line 29) 49988* RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 33) 49989* RTL_PURE_CALL_P: Flags. (line 24) 49990* RTX (See RTL): RTL Objects. (line 6) 49991* RTX codes, classes of: RTL Classes. (line 6) 49992* RTX_FRAME_RELATED_P: Flags. (line 107) 49993* run-time conventions: Interface. (line 6) 49994* run-time target specification: Run-time Target. (line 6) 49995* s in constraint: Simple Constraints. (line 100) 49996* SAD_EXPR: Vectors. (line 6) 49997* same_type_p: Types. (line 86) 49998* SAmode: Machine Modes. (line 150) 49999* satfractMN2 instruction pattern: Standard Names. (line 1141) 50000* satfractunsMN2 instruction pattern: Standard Names. (line 1154) 50001* satisfies_constraint_M: C Constraint Interface. 50002 (line 36) 50003* sat_fract: Conversions. (line 90) 50004* SAVE_EXPR: Unary and Binary Expressions. 50005 (line 6) 50006* save_stack_block instruction pattern: Standard Names. (line 1542) 50007* save_stack_function instruction pattern: Standard Names. (line 1542) 50008* save_stack_nonlocal instruction pattern: Standard Names. (line 1542) 50009* SBSS_SECTION_ASM_OP: Sections. (line 75) 50010* Scalar evolutions: Scalar evolutions. (line 6) 50011* scalars, returned as values: Scalar Return. (line 6) 50012* scalbM3 instruction pattern: Standard Names. (line 646) 50013* SCHED_GROUP_P: Flags. (line 148) 50014* SCmode: Machine Modes. (line 199) 50015* scratch: Regs and Memory. (line 294) 50016* scratch operands: Regs and Memory. (line 294) 50017* scratch, RTL sharing: Sharing. (line 35) 50018* scratch_operand: Machine-Independent Predicates. 50019 (line 49) 50020* SDATA_SECTION_ASM_OP: Sections. (line 57) 50021* SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 132) 50022* SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 127) 50023* SDB_DEBUGGING_INFO: SDB and DWARF. (line 8) 50024* SDB_DELIM: SDB and DWARF. (line 120) 50025* SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 137) 50026* SDmode: Machine Modes. (line 88) 50027* sdot_prodM instruction pattern: Standard Names. (line 395) 50028* search options: Including Patterns. (line 47) 50029* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 391) 50030* SECONDARY_MEMORY_NEEDED: Register Classes. (line 447) 50031* SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 466) 50032* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 457) 50033* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 392) 50034* SECONDARY_RELOAD_CLASS: Register Classes. (line 390) 50035* SELECT_CC_MODE: MODE_CC Condition Codes. 50036 (line 6) 50037* sequence: Side Effects. (line 259) 50038* Sequence iterators: Sequence iterators. (line 6) 50039* set: Side Effects. (line 15) 50040* set and /f: Flags. (line 107) 50041* setmemM instruction pattern: Standard Names. (line 1005) 50042* SETUP_FRAME_ADDRESSES: Frame Layout. (line 96) 50043* SET_ASM_OP: Label Output. (line 451) 50044* SET_ASM_OP <1>: Label Output. (line 462) 50045* set_attr: Tagging Insns. (line 31) 50046* set_attr_alternative: Tagging Insns. (line 49) 50047* set_bb_seq: GIMPLE sequences. (line 75) 50048* SET_DEST: Side Effects. (line 69) 50049* SET_IS_RETURN_P: Flags. (line 157) 50050* SET_LABEL_KIND: Insns. (line 146) 50051* set_optab_libfunc: Library Calls. (line 15) 50052* SET_RATIO: Costs. (line 216) 50053* SET_SRC: Side Effects. (line 69) 50054* set_thread_pointerMODE instruction pattern: Standard Names. 50055 (line 2073) 50056* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6) 50057* SET_TYPE_STRUCTURAL_EQUALITY <1>: Types. (line 81) 50058* SFmode: Machine Modes. (line 69) 50059* sharing of RTL components: Sharing. (line 6) 50060* shift: Arithmetic. (line 173) 50061* SHIFT_COUNT_TRUNCATED: Misc. (line 112) 50062* SHLIB_SUFFIX: Macros for Initialization. 50063 (line 133) 50064* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 82) 50065* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 62) 50066* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 86) 50067* SHORT_TYPE_SIZE: Type Layout. (line 15) 50068* sibcall_epilogue instruction pattern: Standard Names. (line 1749) 50069* sibling call: Edges. (line 121) 50070* SIBLING_CALL_P: Flags. (line 161) 50071* signed division: Arithmetic. (line 116) 50072* signed division with signed saturation: Arithmetic. (line 116) 50073* signed maximum: Arithmetic. (line 141) 50074* signed minimum: Arithmetic. (line 141) 50075* significandM2 instruction pattern: Standard Names. (line 778) 50076* sign_extend: Conversions. (line 23) 50077* sign_extract: Bit-Fields. (line 8) 50078* sign_extract, canonicalization of: Insn Canonicalizations. 50079 (line 87) 50080* SIG_ATOMIC_TYPE: Type Layout. (line 214) 50081* SImode: Machine Modes. (line 37) 50082* simple constraints: Simple Constraints. (line 6) 50083* simple_return: Side Effects. (line 86) 50084* simple_return instruction pattern: Standard Names. (line 1405) 50085* sincosM3 instruction pattern: Standard Names. (line 674) 50086* sinM2 instruction pattern: Standard Names. (line 668) 50087* SIZETYPE: Type Layout. (line 153) 50088* SIZE_ASM_OP: Label Output. (line 33) 50089* SIZE_TYPE: Type Layout. (line 137) 50090* skip: GTY Options. (line 76) 50091* SLOW_BYTE_ACCESS: Costs. (line 117) 50092* SLOW_UNALIGNED_ACCESS: Costs. (line 132) 50093* smax: Arithmetic. (line 141) 50094* smin: Arithmetic. (line 141) 50095* sms, swing, software pipelining: RTL passes. (line 123) 50096* smulM3_highpart instruction pattern: Standard Names. (line 504) 50097* soft float library: Soft float library routines. 50098 (line 6) 50099* special: GTY Options. (line 236) 50100* special predicates: Predicates. (line 31) 50101* SPECS: Target Fragment. (line 191) 50102* speed of instructions: Costs. (line 6) 50103* splitting instructions: Insn Splitting. (line 6) 50104* split_block: Maintaining the CFG. 50105 (line 97) 50106* SQmode: Machine Modes. (line 114) 50107* sqrt: Arithmetic. (line 206) 50108* sqrtM2 instruction pattern: Standard Names. (line 613) 50109* square root: Arithmetic. (line 206) 50110* SSA: SSA. (line 6) 50111* ssaddM3 instruction pattern: Standard Names. (line 301) 50112* ssadM instruction pattern: Standard Names. (line 404) 50113* ssashlM3 instruction pattern: Standard Names. (line 579) 50114* SSA_NAME_DEF_STMT: SSA. (line 184) 50115* SSA_NAME_VERSION: SSA. (line 189) 50116* ssdivM3 instruction pattern: Standard Names. (line 301) 50117* ssmaddMN4 instruction pattern: Standard Names. (line 527) 50118* ssmsubMN4 instruction pattern: Standard Names. (line 551) 50119* ssmulM3 instruction pattern: Standard Names. (line 301) 50120* ssnegM2 instruction pattern: Standard Names. (line 603) 50121* sssubM3 instruction pattern: Standard Names. (line 301) 50122* ss_abs: Arithmetic. (line 200) 50123* ss_ashift: Arithmetic. (line 173) 50124* ss_div: Arithmetic. (line 116) 50125* ss_minus: Arithmetic. (line 38) 50126* ss_mult: Arithmetic. (line 93) 50127* ss_neg: Arithmetic. (line 82) 50128* ss_plus: Arithmetic. (line 14) 50129* ss_truncate: Conversions. (line 43) 50130* stack arguments: Stack Arguments. (line 6) 50131* stack frame layout: Frame Layout. (line 6) 50132* stack smashing protection: Stack Smashing Protection. 50133 (line 6) 50134* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 43) 50135* STACK_BOUNDARY: Storage Layout. (line 139) 50136* STACK_CHECK_BUILTIN: Stack Checking. (line 31) 50137* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 83) 50138* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 74) 50139* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 90) 50140* STACK_CHECK_MOVING_SP: Stack Checking. (line 53) 50141* STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 45) 50142* STACK_CHECK_PROTECT: Stack Checking. (line 62) 50143* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 38) 50144* STACK_DYNAMIC_OFFSET: Frame Layout. (line 69) 50145* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 50146 (line 83) 50147* STACK_GROWS_DOWNWARD: Frame Layout. (line 8) 50148* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 89) 50149* STACK_POINTER_OFFSET: Frame Layout. (line 53) 50150* STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 50151 (line 93) 50152* STACK_POINTER_REGNUM: Frame Registers. (line 8) 50153* STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 50154 (line 83) 50155* stack_pointer_rtx: Frame Registers. (line 104) 50156* stack_protect_set instruction pattern: Standard Names. (line 2083) 50157* stack_protect_test instruction pattern: Standard Names. (line 2093) 50158* STACK_PUSH_CODE: Frame Layout. (line 12) 50159* STACK_REGS: Stack Registers. (line 19) 50160* STACK_REG_COVER_CLASS: Stack Registers. (line 22) 50161* STACK_SAVEAREA_MODE: Storage Layout. (line 443) 50162* STACK_SIZE_MODE: Storage Layout. (line 454) 50163* STACK_SLOT_ALIGNMENT: Storage Layout. (line 275) 50164* standard pattern names: Standard Names. (line 6) 50165* STANDARD_STARTFILE_PREFIX: Driver. (line 278) 50166* STANDARD_STARTFILE_PREFIX_1: Driver. (line 285) 50167* STANDARD_STARTFILE_PREFIX_2: Driver. (line 292) 50168* STARTFILE_SPEC: Driver. (line 147) 50169* STARTING_FRAME_OFFSET: Frame Layout. (line 34) 50170* STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 50171 (line 74) 50172* Statement and operand traversals: Statement and operand traversals. 50173 (line 6) 50174* Statement Sequences: Statement Sequences. 50175 (line 6) 50176* Statements: Statements. (line 6) 50177* statements: Function Properties. 50178 (line 6) 50179* statements <1>: Statements for C++. (line 6) 50180* Static profile estimation: Profile information. 50181 (line 24) 50182* static single assignment: SSA. (line 6) 50183* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 77) 50184* STATIC_CHAIN_REGNUM: Frame Registers. (line 76) 50185* stdarg.h and register arguments: Register Arguments. (line 51) 50186* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 350) 50187* STMT_EXPR: Unary and Binary Expressions. 50188 (line 6) 50189* STMT_IS_FULL_EXPR_P: Statements for C++. (line 22) 50190* storage layout: Storage Layout. (line 6) 50191* STORE_FLAG_VALUE: Misc. (line 201) 50192* store_multiple instruction pattern: Standard Names. (line 159) 50193* strcpy: Storage Layout. (line 228) 50194* STRICT_ALIGNMENT: Storage Layout. (line 325) 50195* strict_low_part: RTL Declarations. (line 9) 50196* strict_memory_address_p: Addressing Modes. (line 186) 50197* STRING_CST: Constant expressions. 50198 (line 6) 50199* STRING_POOL_ADDRESS_P: Flags. (line 165) 50200* strlenM instruction pattern: Standard Names. (line 1076) 50201* structure value address: Aggregate Return. (line 6) 50202* structures, returning: Interface. (line 10) 50203* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 317) 50204* subM3 instruction pattern: Standard Names. (line 301) 50205* SUBOBJECT: Statements for C++. (line 6) 50206* SUBOBJECT_CLEANUP: Statements for C++. (line 6) 50207* subreg: Regs and Memory. (line 97) 50208* subreg and /s: Flags. (line 187) 50209* subreg and /u: Flags. (line 180) 50210* subreg and /u and /v: Flags. (line 170) 50211* subreg, in strict_low_part: RTL Declarations. (line 9) 50212* SUBREG_BYTE: Regs and Memory. (line 285) 50213* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 170) 50214* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 180) 50215* SUBREG_PROMOTED_VAR_P: Flags. (line 187) 50216* SUBREG_REG: Regs and Memory. (line 285) 50217* subst iterators in .md files: Subst Iterators. (line 6) 50218* subvM4 instruction pattern: Standard Names. (line 317) 50219* SUCCESS_EXIT_CODE: Host Misc. (line 12) 50220* SUPPORTS_INIT_PRIORITY: Macros for Initialization. 50221 (line 57) 50222* SUPPORTS_ONE_ONLY: Label Output. (line 290) 50223* SUPPORTS_WEAK: Label Output. (line 264) 50224* SWITCHABLE_TARGET: Run-time Target. (line 164) 50225* SWITCH_BODY: Statements for C++. (line 6) 50226* SWITCH_COND: Statements for C++. (line 6) 50227* SWITCH_STMT: Statements for C++. (line 6) 50228* symbolic label: Sharing. (line 20) 50229* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 117) 50230* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 99) 50231* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 92) 50232* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 113) 50233* SYMBOL_FLAG_LOCAL: Special Accessors. (line 95) 50234* SYMBOL_FLAG_SMALL: Special Accessors. (line 104) 50235* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 108) 50236* symbol_ref: Constants. (line 117) 50237* symbol_ref and /f: Flags. (line 165) 50238* symbol_ref and /i: Flags. (line 202) 50239* symbol_ref and /u: Flags. (line 10) 50240* symbol_ref and /v: Flags. (line 206) 50241* symbol_ref, RTL sharing: Sharing. (line 20) 50242* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 117) 50243* SYMBOL_REF_BLOCK: Special Accessors. (line 130) 50244* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 135) 50245* SYMBOL_REF_CONSTANT: Special Accessors. (line 78) 50246* SYMBOL_REF_DATA: Special Accessors. (line 82) 50247* SYMBOL_REF_DECL: Special Accessors. (line 67) 50248* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 99) 50249* SYMBOL_REF_FLAG: Flags. (line 206) 50250* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 277) 50251* SYMBOL_REF_FLAGS: Special Accessors. (line 86) 50252* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 92) 50253* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 113) 50254* SYMBOL_REF_LOCAL_P: Special Accessors. (line 95) 50255* SYMBOL_REF_SMALL_P: Special Accessors. (line 104) 50256* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 108) 50257* SYMBOL_REF_USED: Flags. (line 197) 50258* SYMBOL_REF_WEAK: Flags. (line 202) 50259* sync_addMODE instruction pattern: Standard Names. (line 1848) 50260* sync_andMODE instruction pattern: Standard Names. (line 1848) 50261* sync_compare_and_swapMODE instruction pattern: Standard Names. 50262 (line 1808) 50263* sync_iorMODE instruction pattern: Standard Names. (line 1848) 50264* sync_lock_releaseMODE instruction pattern: Standard Names. (line 1913) 50265* sync_lock_test_and_setMODE instruction pattern: Standard Names. 50266 (line 1887) 50267* sync_nandMODE instruction pattern: Standard Names. (line 1848) 50268* sync_new_addMODE instruction pattern: Standard Names. (line 1880) 50269* sync_new_andMODE instruction pattern: Standard Names. (line 1880) 50270* sync_new_iorMODE instruction pattern: Standard Names. (line 1880) 50271* sync_new_nandMODE instruction pattern: Standard Names. (line 1880) 50272* sync_new_subMODE instruction pattern: Standard Names. (line 1880) 50273* sync_new_xorMODE instruction pattern: Standard Names. (line 1880) 50274* sync_old_addMODE instruction pattern: Standard Names. (line 1863) 50275* sync_old_andMODE instruction pattern: Standard Names. (line 1863) 50276* sync_old_iorMODE instruction pattern: Standard Names. (line 1863) 50277* sync_old_nandMODE instruction pattern: Standard Names. (line 1863) 50278* sync_old_subMODE instruction pattern: Standard Names. (line 1863) 50279* sync_old_xorMODE instruction pattern: Standard Names. (line 1863) 50280* sync_subMODE instruction pattern: Standard Names. (line 1848) 50281* sync_xorMODE instruction pattern: Standard Names. (line 1848) 50282* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 176) 50283* SYSROOT_SUFFIX_SPEC: Driver. (line 171) 50284* t-TARGET: Target Fragment. (line 6) 50285* table jump: Basic Blocks. (line 67) 50286* tablejump instruction pattern: Standard Names. (line 1478) 50287* tag: GTY Options. (line 88) 50288* tagging insns: Tagging Insns. (line 6) 50289* tail calls: Tail Calls. (line 6) 50290* TAmode: Machine Modes. (line 158) 50291* tanM2 instruction pattern: Standard Names. (line 685) 50292* target attributes: Target Attributes. (line 6) 50293* target description macros: Target Macros. (line 6) 50294* target functions: Target Structure. (line 6) 50295* target hooks: Target Structure. (line 6) 50296* target makefile fragment: Target Fragment. (line 6) 50297* target specifications: Run-time Target. (line 6) 50298* targetm: Target Structure. (line 6) 50299* targets, makefile: Makefile. (line 6) 50300* TARGET_ABSOLUTE_BIGGEST_ALIGNMENT: Storage Layout. (line 168) 50301* TARGET_ADDRESS_COST: Costs. (line 323) 50302* TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces. 50303 (line 42) 50304* TARGET_ADDR_SPACE_CONVERT: Named Address Spaces. 50305 (line 89) 50306* TARGET_ADDR_SPACE_DEBUG: Named Address Spaces. 50307 (line 99) 50308* TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces. 50309 (line 59) 50310* TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces. 50311 (line 67) 50312* TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces. 50313 (line 36) 50314* TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces. 50315 (line 74) 50316* TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces. 50317 (line 48) 50318* TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID: Named Address Spaces. 50319 (line 83) 50320* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 402) 50321* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 810) 50322* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 1107) 50323* TARGET_ALWAYS_STRIP_DOTDOT: Driver. (line 250) 50324* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 95) 50325* TARGET_ARM_EABI_UNWINDER: Exception Region Output. 50326 (line 134) 50327* TARGET_ARRAY_MODE_SUPPORTED_P: Register Arguments. (line 345) 50328* TARGET_ASAN_SHADOW_OFFSET: Misc. (line 1135) 50329* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 9) 50330* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 7) 50331* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 8) 50332* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 10) 50333* TARGET_ASM_ASSEMBLE_UNDEFINED_DECL: Label Output. (line 231) 50334* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 301) 50335* TARGET_ASM_BYTE_OP: Data Output. (line 6) 50336* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 202) 50337* TARGET_ASM_CLOSE_PAREN: Data Output. (line 133) 50338* TARGET_ASM_CODE_END: File Framework. (line 57) 50339* TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 50340 (line 68) 50341* TARGET_ASM_DECLARE_CONSTANT_NAME: Label Output. (line 177) 50342* TARGET_ASM_DECL_END: Data Output. (line 38) 50343* TARGET_ASM_DESTRUCTOR: Macros for Initialization. 50344 (line 82) 50345* TARGET_ASM_EMIT_EXCEPT_PERSONALITY: Dispatch Tables. (line 80) 50346* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 73) 50347* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 61) 50348* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 337) 50349* TARGET_ASM_FILE_END: File Framework. (line 35) 50350* TARGET_ASM_FILE_START: File Framework. (line 8) 50351* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 16) 50352* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 29) 50353* TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 82) 50354* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 59) 50355* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 53) 50356* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 65) 50357* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 9) 50358* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 213) 50359* TARGET_ASM_FUNCTION_SECTION: File Framework. (line 121) 50360* TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework. 50361 (line 131) 50362* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 222) 50363* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 213) 50364* TARGET_ASM_INIT_SECTIONS: Sections. (line 159) 50365* TARGET_ASM_INTEGER: Data Output. (line 25) 50366* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 380) 50367* TARGET_ASM_JUMP_ALIGN_MAX_SKIP: Alignment Output. (line 21) 50368* TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. 50369 (line 34) 50370* TARGET_ASM_LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 68) 50371* TARGET_ASM_LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 53) 50372* TARGET_ASM_LTO_END: File Framework. (line 52) 50373* TARGET_ASM_LTO_START: File Framework. (line 47) 50374* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 343) 50375* TARGET_ASM_MERGEABLE_RODATA_PREFIX: Sections. (line 221) 50376* TARGET_ASM_NAMED_SECTION: File Framework. (line 113) 50377* TARGET_ASM_OPEN_PAREN: Data Output. (line 132) 50378* TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 42) 50379* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 42) 50380* TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 108) 50381* TARGET_ASM_OUTPUT_IDENT: File Framework. (line 100) 50382* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 160) 50383* TARGET_ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 91) 50384* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 162) 50385* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 207) 50386* TARGET_ASM_RELOC_RW_MASK: Sections. (line 168) 50387* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 230) 50388* TARGET_ASM_SELECT_SECTION: Sections. (line 179) 50389* TARGET_ASM_TM_CLONE_TABLE_SECTION: Sections. (line 226) 50390* TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 28) 50391* TARGET_ASM_TTYPE: Exception Region Output. 50392 (line 128) 50393* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 13) 50394* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 11) 50395* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 12) 50396* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 14) 50397* TARGET_ASM_UNIQUE_SECTION: Sections. (line 201) 50398* TARGET_ASM_UNWIND_EMIT: Dispatch Tables. (line 87) 50399* TARGET_ASM_UNWIND_EMIT_BEFORE_INSN: Dispatch Tables. (line 93) 50400* TARGET_ATOMIC_ALIGN_FOR_MODE: Misc. (line 1154) 50401* TARGET_ATOMIC_ASSIGN_EXPAND_FENV: Misc. (line 1160) 50402* TARGET_ATOMIC_TEST_AND_SET_TRUEVAL: Misc. (line 1145) 50403* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 10) 50404* TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P: Target Attributes. (line 17) 50405* TARGET_BINDS_LOCAL_P: Sections. (line 308) 50406* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 907) 50407* TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 900) 50408* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 285) 50409* TARGET_BUILTIN_CHKP_FUNCTION: Misc. (line 625) 50410* TARGET_BUILTIN_DECL: Misc. (line 604) 50411* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 261) 50412* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 103) 50413* TARGET_CALLEE_COPIES: Register Arguments. (line 127) 50414* TARGET_CALL_ARGS: Varargs. (line 123) 50415* TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS: Miscellaneous Register Hooks. 50416 (line 6) 50417* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 234) 50418* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 887) 50419* TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P: Register Classes. (line 597) 50420* TARGET_CANONICALIZE_COMPARISON: MODE_CC Condition Codes. 50421 (line 55) 50422* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 306) 50423* TARGET_CAN_ELIMINATE: Elimination. (line 73) 50424* TARGET_CAN_FOLLOW_JUMP: Misc. (line 796) 50425* TARGET_CAN_INLINE_P: Target Attributes. (line 165) 50426* TARGET_CAN_USE_DOLOOP_P: Misc. (line 760) 50427* TARGET_CASE_VALUES_THRESHOLD: Misc. (line 46) 50428* TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes. 50429 (line 120) 50430* TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 26) 50431* TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target. (line 119) 50432* TARGET_CHKP_BOUND_MODE: Misc. (line 697) 50433* TARGET_CHKP_BOUND_TYPE: Misc. (line 695) 50434* TARGET_CHKP_FUNCTION_VALUE_BOUNDS: Varargs. (line 182) 50435* TARGET_CHKP_INITIALIZE_BOUNDS: Misc. (line 703) 50436* TARGET_CHKP_MAKE_BOUNDS_CONSTANT: Misc. (line 699) 50437* TARGET_CLASS_LIKELY_SPILLED_P: Register Classes. (line 489) 50438* TARGET_CLASS_MAX_NREGS: Register Classes. (line 505) 50439* TARGET_COMMUTATIVE_P: Misc. (line 803) 50440* TARGET_COMPARE_VERSION_PRIORITY: Misc. (line 737) 50441* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 25) 50442* TARGET_CONDITIONAL_REGISTER_USAGE: Register Basics. (line 59) 50443* TARGET_CONST_ANCHOR: Misc. (line 1118) 50444* TARGET_CONST_NOT_OK_FOR_DEBUG_P: Addressing Modes. (line 230) 50445* TARGET_CONVERT_TO_TYPE: Misc. (line 1072) 50446* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 8) 50447* TARGET_CSTORE_MODE: Register Classes. (line 620) 50448* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 86) 50449* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 37) 50450* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 61) 50451* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 24) 50452* TARGET_CXX_DECL_MANGLING_CONTEXT: C++ ABI. (line 92) 50453* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 52) 50454* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 17) 50455* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 11) 50456* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 6) 50457* TARGET_CXX_IMPLICIT_EXTERN_C: Misc. (line 373) 50458* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 28) 50459* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 42) 50460* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 68) 50461* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 73) 50462* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 79) 50463* TARGET_C_PREINCLUDE: Misc. (line 361) 50464* TARGET_DEBUG_UNWIND_INFO: SDB and DWARF. (line 36) 50465* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 507) 50466* TARGET_DECLSPEC: Target Attributes. (line 72) 50467* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 446) 50468* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 129) 50469* TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 55) 50470* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 465) 50471* TARGET_DELAY_SCHED2: SDB and DWARF. (line 65) 50472* TARGET_DELAY_VARTRACK: SDB and DWARF. (line 69) 50473* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 221) 50474* TARGET_DIFFERENT_ADDR_DISPLACEMENT_P: Register Classes. (line 590) 50475* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 55) 50476* TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 16) 50477* TARGET_DWARF_FRAME_REG_MODE: Exception Region Output. 50478 (line 114) 50479* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 167) 50480* TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 50481 (line 105) 50482* TARGET_EDOM: Library Calls. (line 59) 50483* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 67) 50484* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 18) 50485* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 23) 50486* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 44) 50487* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 35) 50488* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 62) 50489* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 48) 50490* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 55) 50491* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 40) 50492* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 30) 50493* TARGET_ENCODE_SECTION_INFO: Sections. (line 251) 50494* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 50495 (line 82) 50496* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 127) 50497* TARGET_END_CALL_ARGS: Varargs. (line 137) 50498* TARGET_ENUM_VA_LIST_P: Register Arguments. (line 289) 50499* TARGET_EXCEPT_UNWIND_INFO: Exception Region Output. 50500 (line 46) 50501* TARGET_EXECUTABLE_SUFFIX: Misc. (line 861) 50502* TARGET_EXPAND_BUILTIN: Misc. (line 614) 50503* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 64) 50504* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 513) 50505* TARGET_EXPR: Unary and Binary Expressions. 50506 (line 6) 50507* TARGET_EXTRA_INCLUDES: Misc. (line 973) 50508* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 20) 50509* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 980) 50510* TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes. 50511 (line 105) 50512* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 510) 50513* target_flags: Run-time Target. (line 51) 50514* TARGET_FLAGS_REGNUM: MODE_CC Condition Codes. 50515 (line 133) 50516* TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P: Run-time Target. 50517 (line 183) 50518* TARGET_FLT_EVAL_METHOD: Type Layout. (line 110) 50519* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 301) 50520* TARGET_FOLD_BUILTIN: Misc. (line 720) 50521* TARGET_FORCE_AT_COMP_DIR: SDB and DWARF. (line 60) 50522* TARGET_FORMAT_TYPES: Misc. (line 1001) 50523* TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 8) 50524* TARGET_FUNCTION_ARG: Register Arguments. (line 10) 50525* TARGET_FUNCTION_ARG_ADVANCE: Register Arguments. (line 198) 50526* TARGET_FUNCTION_ARG_BOUNDARY: Register Arguments. (line 252) 50527* TARGET_FUNCTION_ARG_ROUND_BOUNDARY: Register Arguments. (line 258) 50528* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 93) 50529* TARGET_FUNCTION_INCOMING_ARG: Register Arguments. (line 71) 50530* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 6) 50531* TARGET_FUNCTION_VALUE: Scalar Return. (line 9) 50532* TARGET_FUNCTION_VALUE_REGNO_P: Scalar Return. (line 96) 50533* TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc. (line 753) 50534* TARGET_GEN_CCMP_FIRST: Misc. (line 927) 50535* TARGET_GEN_CCMP_NEXT: Misc. (line 938) 50536* TARGET_GET_DRAP_RTX: Misc. (line 1101) 50537* TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc. (line 746) 50538* TARGET_GET_PCH_VALIDITY: PCH Target. (line 6) 50539* TARGET_GET_RAW_ARG_MODE: Aggregate Return. (line 81) 50540* TARGET_GET_RAW_RESULT_MODE: Aggregate Return. (line 76) 50541* TARGET_GIMPLE_FOLD_BUILTIN: Misc. (line 730) 50542* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 311) 50543* TARGET_GOACC_DIM_LIMIT: Addressing Modes. (line 443) 50544* TARGET_GOACC_FORK_JOIN: Addressing Modes. (line 447) 50545* TARGET_GOACC_REDUCTION: Addressing Modes. (line 458) 50546* TARGET_GOACC_VALIDATE_DIMS: Addressing Modes. (line 430) 50547* TARGET_HANDLE_C_OPTION: Run-time Target. (line 73) 50548* TARGET_HANDLE_OPTION: Run-time Target. (line 59) 50549* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers. 50550 (line 141) 50551* TARGET_HAS_IFUNC_P: Misc. (line 1149) 50552* TARGET_HAS_NO_HW_DIVIDE: Library Calls. (line 52) 50553* TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 921) 50554* TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 50555 (line 63) 50556* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 139) 50557* TARGET_HAVE_SRODATA_SECTION: Sections. (line 297) 50558* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 144) 50559* TARGET_HAVE_TLS: Sections. (line 317) 50560* TARGET_INIT_BUILTINS: Misc. (line 588) 50561* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output. 50562 (line 120) 50563* TARGET_INIT_LIBFUNCS: Library Calls. (line 15) 50564* TARGET_INIT_PIC_REG: Register Arguments. (line 91) 50565* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 80) 50566* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 521) 50567* TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 1025) 50568* TARGET_INVALID_BINARY_OP: Misc. (line 1044) 50569* TARGET_INVALID_CONVERSION: Misc. (line 1031) 50570* TARGET_INVALID_PARAMETER_TYPE: Misc. (line 1050) 50571* TARGET_INVALID_RETURN_TYPE: Misc. (line 1057) 50572* TARGET_INVALID_UNARY_OP: Misc. (line 1037) 50573* TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 777) 50574* TARGET_IN_SMALL_DATA_P: Sections. (line 293) 50575* TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS: Register Classes. (line 557) 50576* TARGET_KEEP_LEAF_WHEN_PROFILED: Profiling. (line 39) 50577* TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 48) 50578* TARGET_LEGITIMATE_COMBINED_INSN: Misc. (line 791) 50579* TARGET_LEGITIMATE_CONSTANT_P: Addressing Modes. (line 213) 50580* TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 129) 50581* TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: Register Classes. (line 605) 50582* TARGET_LIBCALL_VALUE: Scalar Return. (line 65) 50583* TARGET_LIBC_HAS_FUNCTION: Library Calls. (line 77) 50584* TARGET_LIBFUNC_GNU_PREFIX: Library Calls. (line 24) 50585* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 463) 50586* TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P: Register Arguments. 50587 (line 369) 50588* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 131) 50589* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 469) 50590* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 42) 50591* TARGET_LOAD_BOUNDS_FOR_ARG: Varargs. (line 153) 50592* TARGET_LOAD_RETURNED_BOUNDS: Varargs. (line 172) 50593* TARGET_LOOP_UNROLL_ADJUST: Misc. (line 954) 50594* TARGET_LRA_P: Register Classes. (line 564) 50595* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 573) 50596* TARGET_MANGLE_ASSEMBLER_NAME: Label Output. (line 356) 50597* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 241) 50598* TARGET_MANGLE_TYPE: Storage Layout. (line 525) 50599* TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 38) 50600* TARGET_MD_ASM_ADJUST: Misc. (line 491) 50601* TARGET_MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 415) 50602* TARGET_MEMMODEL_CHECK: Misc. (line 1140) 50603* TARGET_MEMORY_MOVE_COST: Costs. (line 79) 50604* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 107) 50605* TARGET_MEM_REF: Storage References. (line 6) 50606* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 45) 50607* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 37) 50608* TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 32) 50609* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 90) 50610* TARGET_MODE_AFTER: Mode Switching. (line 57) 50611* TARGET_MODE_DEPENDENT_ADDRESS_P: Addressing Modes. (line 196) 50612* TARGET_MODE_EMIT: Mode Switching. (line 42) 50613* TARGET_MODE_ENTRY: Mode Switching. (line 64) 50614* TARGET_MODE_EXIT: Mode Switching. (line 71) 50615* TARGET_MODE_NEEDED: Mode Switching. (line 50) 50616* TARGET_MODE_PRIORITY: Mode Switching. (line 78) 50617* TARGET_MODE_REP_EXTENDED: Misc. (line 175) 50618* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 479) 50619* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 64) 50620* TARGET_MUST_PASS_IN_STACK, and TARGET_FUNCTION_ARG: Register Arguments. 50621 (line 56) 50622* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 408) 50623* TARGET_NO_REGISTER_ALLOCATION: SDB and DWARF. (line 73) 50624* TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P: Costs. (line 359) 50625* TARGET_N_FORMAT_TYPES: Misc. (line 1006) 50626* TARGET_OBJC_CONSTRUCT_STRING_OBJECT: Run-time Target. (line 88) 50627* TARGET_OBJC_DECLARE_CLASS_DEFINITION: Run-time Target. (line 109) 50628* TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target. 50629 (line 104) 50630* TARGET_OBJECT_SUFFIX: Misc. (line 856) 50631* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 45) 50632* TARGET_OFFLOAD_OPTIONS: Misc. (line 1183) 50633* TARGET_OMIT_STRUCT_RETURN_REG: Scalar Return. (line 117) 50634* TARGET_OPTAB_SUPPORTED_P: Costs. (line 278) 50635* TARGET_OPTF: Misc. (line 988) 50636* TARGET_OPTION_DEFAULT_PARAMS: Run-time Target. (line 160) 50637* TARGET_OPTION_FUNCTION_VERSIONS: Target Attributes. (line 157) 50638* TARGET_OPTION_INIT_STRUCT: Run-time Target. (line 156) 50639* TARGET_OPTION_OPTIMIZATION_TABLE: Run-time Target. (line 142) 50640* TARGET_OPTION_OVERRIDE: Target Attributes. (line 144) 50641* TARGET_OPTION_POST_STREAM_IN: Target Attributes. (line 125) 50642* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 137) 50643* TARGET_OPTION_PRINT: Target Attributes. (line 131) 50644* TARGET_OPTION_RESTORE: Target Attributes. (line 119) 50645* TARGET_OPTION_SAVE: Target Attributes. (line 112) 50646* TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 100) 50647* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 41) 50648* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 1010) 50649* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 1016) 50650* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 1020) 50651* TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 126) 50652* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 115) 50653* TARGET_PCH_VALID_P: PCH Target. (line 11) 50654* TARGET_POSIX_IO: Misc. (line 517) 50655* TARGET_PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 284) 50656* TARGET_PREFERRED_RELOAD_CLASS: Register Classes. (line 213) 50657* TARGET_PREFERRED_RENAME_CLASS: Register Classes. (line 201) 50658* TARGET_PREPARE_PCH_SAVE: PCH Target. (line 34) 50659* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 144) 50660* TARGET_PROFILE_BEFORE_PROLOGUE: Sections. (line 301) 50661* TARGET_PROMOTED_TYPE: Misc. (line 1064) 50662* TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 109) 50663* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 10) 50664* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 256) 50665* TARGET_RECORD_OFFLOAD_SYMBOL: Misc. (line 1178) 50666* TARGET_REF_MAY_ALIAS_ERRNO: Register Arguments. (line 322) 50667* TARGET_REGISTER_MOVE_COST: Costs. (line 31) 50668* TARGET_REGISTER_PRIORITY: Register Classes. (line 569) 50669* TARGET_REGISTER_USAGE_LEVELING_P: Register Classes. (line 580) 50670* TARGET_RELAYOUT_FUNCTION: Target Attributes. (line 172) 50671* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 709) 50672* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 15) 50673* TARGET_RETURN_IN_MSB: Scalar Return. (line 124) 50674* TARGET_RETURN_POPS_ARGS: Stack Arguments. (line 98) 50675* TARGET_RTX_COSTS: Costs. (line 292) 50676* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 329) 50677* TARGET_SCHED_ADJUST_COST: Scheduling. (line 35) 50678* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 50) 50679* TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 294) 50680* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 309) 50681* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 101) 50682* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 255) 50683* TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 172) 50684* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 156) 50685* TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 165) 50686* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 144) 50687* TARGET_SCHED_DISPATCH: Scheduling. (line 363) 50688* TARGET_SCHED_DISPATCH_DO: Scheduling. (line 368) 50689* TARGET_SCHED_EXPOSED_PIPELINE: Scheduling. (line 372) 50690* TARGET_SCHED_FINISH: Scheduling. (line 122) 50691* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 137) 50692* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling. (line 235) 50693* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling. (line 223) 50694* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 50695 (line 179) 50696* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 50697 (line 207) 50698* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling. (line 240) 50699* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling. (line 250) 50700* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling. (line 245) 50701* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling. (line 229) 50702* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 313) 50703* TARGET_SCHED_FUSION_PRIORITY: Scheduling. (line 382) 50704* TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 335) 50705* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 289) 50706* TARGET_SCHED_INIT: Scheduling. (line 111) 50707* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 161) 50708* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 153) 50709* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 129) 50710* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 298) 50711* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 11) 50712* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 267) 50713* TARGET_SCHED_MACRO_FUSION_P: Scheduling. (line 87) 50714* TARGET_SCHED_MACRO_FUSION_PAIR_P: Scheduling. (line 91) 50715* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 328) 50716* TARGET_SCHED_REASSOCIATION_WIDTH: Scheduling. (line 377) 50717* TARGET_SCHED_REORDER: Scheduling. (line 58) 50718* TARGET_SCHED_REORDER2: Scheduling. (line 75) 50719* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 305) 50720* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 347) 50721* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 354) 50722* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 316) 50723* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 22) 50724* TARGET_SECONDARY_RELOAD: Register Classes. (line 312) 50725* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 149) 50726* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 71) 50727* TARGET_SETUP_INCOMING_VARARG_BOUNDS: Varargs. (line 188) 50728* TARGET_SET_CURRENT_FUNCTION: Misc. (line 838) 50729* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 33) 50730* TARGET_SET_UP_BY_PROLOGUE: Tail Calls. (line 29) 50731* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 138) 50732* TARGET_SIMD_CLONE_ADJUST: Addressing Modes. (line 420) 50733* TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN: Addressing Modes. 50734 (line 412) 50735* TARGET_SIMD_CLONE_USABLE: Addressing Modes. (line 424) 50736* TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments. 50737 (line 377) 50738* TARGET_SPILL_CLASS: Register Classes. (line 613) 50739* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 273) 50740* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 50741 (line 16) 50742* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 50743 (line 6) 50744* TARGET_STATIC_CHAIN: Frame Registers. (line 90) 50745* TARGET_STORE_BOUNDS_FOR_ARG: Varargs. (line 163) 50746* TARGET_STORE_RETURNED_BOUNDS: Varargs. (line 177) 50747* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 107) 50748* TARGET_STRING_OBJECT_REF_TYPE_P: Run-time Target. (line 114) 50749* TARGET_STRIP_NAME_ENCODING: Sections. (line 288) 50750* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44) 50751* TARGET_SUPPORTS_SPLIT_STACK: Stack Smashing Protection. 50752 (line 25) 50753* TARGET_SUPPORTS_WEAK: Label Output. (line 272) 50754* TARGET_SUPPORTS_WIDE_INT: Misc. (line 1191) 50755* TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output. 50756 (line 99) 50757* TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 74) 50758* TARGET_TRAMPOLINE_INIT: Trampolines. (line 54) 50759* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 829) 50760* TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output. 50761 (line 73) 50762* TARGET_UNWIND_WORD_MODE: Storage Layout. (line 475) 50763* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 1097) 50764* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 123) 50765* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 53) 50766* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 248) 50767* TARGET_USE_BLOCKS_FOR_DECL_P: Addressing Modes. (line 255) 50768* TARGET_USE_BY_PIECES_INFRASTRUCTURE_P: Costs. (line 164) 50769* TARGET_USE_JCR_SECTION: Misc. (line 1079) 50770* TARGET_USE_PSEUDO_PIC_REG: Register Arguments. (line 87) 50771* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 66) 50772* TARGET_VALID_POINTER_MODE: Register Arguments. (line 317) 50773* TARGET_VECTORIZE_ADD_STMT_COST: Addressing Modes. (line 375) 50774* TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES: Addressing Modes. 50775 (line 352) 50776* TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 308) 50777* TARGET_VECTORIZE_BUILTIN_GATHER: Addressing Modes. (line 398) 50778* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 266) 50779* TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION: Addressing Modes. 50780 (line 328) 50781* TARGET_VECTORIZE_BUILTIN_SCATTER: Addressing Modes. (line 405) 50782* TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes. 50783 (line 292) 50784* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes. 50785 (line 320) 50786* TARGET_VECTORIZE_DESTROY_COST_DATA: Addressing Modes. (line 393) 50787* TARGET_VECTORIZE_FINISH_COST: Addressing Modes. (line 386) 50788* TARGET_VECTORIZE_GET_MASK_MODE: Addressing Modes. (line 360) 50789* TARGET_VECTORIZE_INIT_COST: Addressing Modes. (line 366) 50790* TARGET_VECTORIZE_PREFERRED_SIMD_MODE: Addressing Modes. (line 345) 50791* TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes. 50792 (line 335) 50793* TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes. 50794 (line 298) 50795* TARGET_VECTORIZE_VEC_PERM_CONST_OK: Addressing Modes. (line 304) 50796* TARGET_VECTOR_ALIGNMENT: Storage Layout. (line 268) 50797* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 340) 50798* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 309) 50799* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 303) 50800* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 292) 50801* TARGET_WANT_DEBUG_PUB_SECTIONS: SDB and DWARF. (line 55) 50802* TARGET_WARN_FUNC_RETURN: Tail Calls. (line 35) 50803* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 308) 50804* TCmode: Machine Modes. (line 199) 50805* TDmode: Machine Modes. (line 97) 50806* TEMPLATE_DECL: Declarations. (line 6) 50807* Temporaries: Temporaries. (line 6) 50808* termination routines: Initialization. (line 6) 50809* testing constraints: C Constraint Interface. 50810 (line 6) 50811* TEXT_SECTION_ASM_OP: Sections. (line 37) 50812* TFmode: Machine Modes. (line 101) 50813* The Language: The Language. (line 6) 50814* THEN_CLAUSE: Statements for C++. (line 6) 50815* THREAD_MODEL_SPEC: Driver. (line 162) 50816* THROW_EXPR: Unary and Binary Expressions. 50817 (line 6) 50818* THUNK_DECL: Declarations. (line 6) 50819* THUNK_DELTA: Declarations. (line 6) 50820* TImode: Machine Modes. (line 48) 50821* TImode, in insn: Insns. (line 268) 50822* TLS_COMMON_ASM_OP: Sections. (line 80) 50823* TLS_SECTION_ASM_FLAG: Sections. (line 85) 50824* tm.h macros: Target Macros. (line 6) 50825* TQFmode: Machine Modes. (line 65) 50826* TQmode: Machine Modes. (line 122) 50827* trampolines for nested functions: Trampolines. (line 6) 50828* TRAMPOLINE_ALIGNMENT: Trampolines. (line 48) 50829* TRAMPOLINE_SECTION: Trampolines. (line 39) 50830* TRAMPOLINE_SIZE: Trampolines. (line 44) 50831* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 110) 50832* trap instruction pattern: Standard Names. (line 1759) 50833* tree: Tree overview. (line 6) 50834* tree <1>: Macros and Functions. 50835 (line 6) 50836* Tree SSA: Tree SSA. (line 6) 50837* TREE_CHAIN: Macros and Functions. 50838 (line 6) 50839* TREE_CODE: Tree overview. (line 6) 50840* tree_fits_shwi_p: Constant expressions. 50841 (line 6) 50842* tree_fits_uhwi_p: Constant expressions. 50843 (line 6) 50844* TREE_INT_CST_ELT: Constant expressions. 50845 (line 6) 50846* tree_int_cst_equal: Constant expressions. 50847 (line 6) 50848* TREE_INT_CST_LOW: Constant expressions. 50849 (line 6) 50850* tree_int_cst_lt: Constant expressions. 50851 (line 6) 50852* TREE_INT_CST_NUNITS: Constant expressions. 50853 (line 6) 50854* TREE_LIST: Containers. (line 6) 50855* TREE_OPERAND: Expression trees. (line 6) 50856* TREE_PUBLIC: Function Basics. (line 6) 50857* TREE_PUBLIC <1>: Function Properties. 50858 (line 28) 50859* TREE_PURPOSE: Containers. (line 6) 50860* TREE_READONLY: Function Properties. 50861 (line 37) 50862* tree_size: Macros and Functions. 50863 (line 13) 50864* TREE_STATIC: Function Properties. 50865 (line 31) 50866* TREE_STRING_LENGTH: Constant expressions. 50867 (line 6) 50868* TREE_STRING_POINTER: Constant expressions. 50869 (line 6) 50870* TREE_THIS_VOLATILE: Function Properties. 50871 (line 34) 50872* tree_to_shwi: Constant expressions. 50873 (line 6) 50874* tree_to_uhwi: Constant expressions. 50875 (line 6) 50876* TREE_TYPE: Macros and Functions. 50877 (line 6) 50878* TREE_TYPE <1>: Types. (line 6) 50879* TREE_TYPE <2>: Working with declarations. 50880 (line 11) 50881* TREE_TYPE <3>: Expression trees. (line 6) 50882* TREE_TYPE <4>: Expression trees. (line 17) 50883* TREE_TYPE <5>: Function Basics. (line 47) 50884* TREE_TYPE <6>: Types for C++. (line 6) 50885* TREE_VALUE: Containers. (line 6) 50886* TREE_VEC: Containers. (line 6) 50887* TREE_VEC_ELT: Containers. (line 6) 50888* TREE_VEC_LENGTH: Containers. (line 6) 50889* TRULY_NOOP_TRUNCATION: Misc. (line 162) 50890* truncate: Conversions. (line 38) 50891* truncMN2 instruction pattern: Standard Names. (line 1119) 50892* TRUNC_DIV_EXPR: Unary and Binary Expressions. 50893 (line 6) 50894* TRUNC_MOD_EXPR: Unary and Binary Expressions. 50895 (line 6) 50896* TRUTH_ANDIF_EXPR: Unary and Binary Expressions. 50897 (line 6) 50898* TRUTH_AND_EXPR: Unary and Binary Expressions. 50899 (line 6) 50900* TRUTH_NOT_EXPR: Unary and Binary Expressions. 50901 (line 6) 50902* TRUTH_ORIF_EXPR: Unary and Binary Expressions. 50903 (line 6) 50904* TRUTH_OR_EXPR: Unary and Binary Expressions. 50905 (line 6) 50906* TRUTH_XOR_EXPR: Unary and Binary Expressions. 50907 (line 6) 50908* TRY_BLOCK: Statements for C++. (line 6) 50909* TRY_HANDLERS: Statements for C++. (line 6) 50910* TRY_STMTS: Statements for C++. (line 6) 50911* Tuple specific accessors: Tuple specific accessors. 50912 (line 6) 50913* tuples: Tuple representation. 50914 (line 6) 50915* type: Types. (line 6) 50916* type declaration: Declarations. (line 6) 50917* TYPENAME_TYPE: Types for C++. (line 6) 50918* TYPENAME_TYPE_FULLNAME: Types. (line 6) 50919* TYPENAME_TYPE_FULLNAME <1>: Types for C++. (line 6) 50920* TYPEOF_TYPE: Types for C++. (line 6) 50921* TYPE_ALIGN: Types. (line 6) 50922* TYPE_ALIGN <1>: Types. (line 30) 50923* TYPE_ALIGN <2>: Types for C++. (line 6) 50924* TYPE_ALIGN <3>: Types for C++. (line 44) 50925* TYPE_ARG_TYPES: Types. (line 6) 50926* TYPE_ARG_TYPES <1>: Types for C++. (line 6) 50927* TYPE_ASM_OP: Label Output. (line 76) 50928* TYPE_ATTRIBUTES: Attributes. (line 24) 50929* TYPE_BINFO: Classes. (line 6) 50930* TYPE_BUILT_IN: Types for C++. (line 66) 50931* TYPE_CANONICAL: Types. (line 6) 50932* TYPE_CANONICAL <1>: Types. (line 41) 50933* TYPE_CONTEXT: Types. (line 6) 50934* TYPE_CONTEXT <1>: Types for C++. (line 6) 50935* TYPE_DECL: Declarations. (line 6) 50936* TYPE_FIELDS: Types. (line 6) 50937* TYPE_FIELDS <1>: Types for C++. (line 6) 50938* TYPE_FIELDS <2>: Classes. (line 6) 50939* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 96) 50940* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 81) 50941* TYPE_HAS_MUTABLE_P: Classes. (line 86) 50942* TYPE_HAS_NEW_OPERATOR: Classes. (line 93) 50943* TYPE_MAIN_VARIANT: Types. (line 6) 50944* TYPE_MAIN_VARIANT <1>: Types. (line 19) 50945* TYPE_MAIN_VARIANT <2>: Types for C++. (line 6) 50946* TYPE_MAX_VALUE: Types. (line 6) 50947* TYPE_METHODS: Classes. (line 6) 50948* TYPE_METHOD_BASETYPE: Types. (line 6) 50949* TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6) 50950* TYPE_MIN_VALUE: Types. (line 6) 50951* TYPE_NAME: Types. (line 6) 50952* TYPE_NAME <1>: Types. (line 33) 50953* TYPE_NAME <2>: Types for C++. (line 6) 50954* TYPE_NAME <3>: Types for C++. (line 47) 50955* TYPE_NOTHROW_P: Functions for C++. (line 154) 50956* TYPE_OFFSET_BASETYPE: Types. (line 6) 50957* TYPE_OFFSET_BASETYPE <1>: Types for C++. (line 6) 50958* TYPE_OPERAND_FMT: Label Output. (line 87) 50959* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 104) 50960* TYPE_OVERLOADS_ARROW: Classes. (line 107) 50961* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 100) 50962* TYPE_POLYMORPHIC_P: Classes. (line 77) 50963* TYPE_PRECISION: Types. (line 6) 50964* TYPE_PRECISION <1>: Types for C++. (line 6) 50965* TYPE_PTRDATAMEM_P: Types for C++. (line 6) 50966* TYPE_PTRDATAMEM_P <1>: Types for C++. (line 69) 50967* TYPE_PTRFN_P: Types for C++. (line 76) 50968* TYPE_PTROBV_P: Types for C++. (line 6) 50969* TYPE_PTROB_P: Types for C++. (line 79) 50970* TYPE_PTR_P: Types for C++. (line 72) 50971* TYPE_QUAL_CONST: Types. (line 6) 50972* TYPE_QUAL_CONST <1>: Types for C++. (line 6) 50973* TYPE_QUAL_RESTRICT: Types. (line 6) 50974* TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6) 50975* TYPE_QUAL_VOLATILE: Types. (line 6) 50976* TYPE_QUAL_VOLATILE <1>: Types for C++. (line 6) 50977* TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149) 50978* TYPE_SIZE: Types. (line 6) 50979* TYPE_SIZE <1>: Types. (line 25) 50980* TYPE_SIZE <2>: Types for C++. (line 6) 50981* TYPE_SIZE <3>: Types for C++. (line 39) 50982* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6) 50983* TYPE_STRUCTURAL_EQUALITY_P <1>: Types. (line 77) 50984* TYPE_UNQUALIFIED: Types. (line 6) 50985* TYPE_UNQUALIFIED <1>: Types for C++. (line 6) 50986* TYPE_VFIELD: Classes. (line 6) 50987* uaddvM4 instruction pattern: Standard Names. (line 320) 50988* UDAmode: Machine Modes. (line 170) 50989* udiv: Arithmetic. (line 130) 50990* udivM3 instruction pattern: Standard Names. (line 301) 50991* udivmodM4 instruction pattern: Standard Names. (line 576) 50992* udot_prodM instruction pattern: Standard Names. (line 396) 50993* UDQmode: Machine Modes. (line 138) 50994* UHAmode: Machine Modes. (line 162) 50995* UHQmode: Machine Modes. (line 130) 50996* UINT16_TYPE: Type Layout. (line 220) 50997* UINT32_TYPE: Type Layout. (line 221) 50998* UINT64_TYPE: Type Layout. (line 222) 50999* UINT8_TYPE: Type Layout. (line 219) 51000* UINTMAX_TYPE: Type Layout. (line 203) 51001* UINTPTR_TYPE: Type Layout. (line 240) 51002* UINT_FAST16_TYPE: Type Layout. (line 236) 51003* UINT_FAST32_TYPE: Type Layout. (line 237) 51004* UINT_FAST64_TYPE: Type Layout. (line 238) 51005* UINT_FAST8_TYPE: Type Layout. (line 235) 51006* UINT_LEAST16_TYPE: Type Layout. (line 228) 51007* UINT_LEAST32_TYPE: Type Layout. (line 229) 51008* UINT_LEAST64_TYPE: Type Layout. (line 230) 51009* UINT_LEAST8_TYPE: Type Layout. (line 227) 51010* umaddMN4 instruction pattern: Standard Names. (line 523) 51011* umax: Arithmetic. (line 149) 51012* umaxM3 instruction pattern: Standard Names. (line 301) 51013* umin: Arithmetic. (line 149) 51014* uminM3 instruction pattern: Standard Names. (line 301) 51015* umod: Arithmetic. (line 136) 51016* umodM3 instruction pattern: Standard Names. (line 301) 51017* umsubMN4 instruction pattern: Standard Names. (line 547) 51018* umulhisi3 instruction pattern: Standard Names. (line 495) 51019* umulM3_highpart instruction pattern: Standard Names. (line 509) 51020* umulqihi3 instruction pattern: Standard Names. (line 495) 51021* umulsidi3 instruction pattern: Standard Names. (line 495) 51022* umulvM4 instruction pattern: Standard Names. (line 325) 51023* unchanging: Flags. (line 296) 51024* unchanging, in call_insn: Flags. (line 19) 51025* unchanging, in jump_insn, call_insn and insn: Flags. (line 39) 51026* unchanging, in mem: Flags. (line 134) 51027* unchanging, in subreg: Flags. (line 170) 51028* unchanging, in subreg <1>: Flags. (line 180) 51029* unchanging, in symbol_ref: Flags. (line 10) 51030* UNEQ_EXPR: Unary and Binary Expressions. 51031 (line 6) 51032* UNGE_EXPR: Unary and Binary Expressions. 51033 (line 6) 51034* UNGT_EXPR: Unary and Binary Expressions. 51035 (line 6) 51036* unions, returning: Interface. (line 10) 51037* UNION_TYPE: Types. (line 6) 51038* UNION_TYPE <1>: Classes. (line 6) 51039* UNITS_PER_WORD: Storage Layout. (line 60) 51040* UNKNOWN_TYPE: Types. (line 6) 51041* UNKNOWN_TYPE <1>: Types for C++. (line 6) 51042* UNLE_EXPR: Unary and Binary Expressions. 51043 (line 6) 51044* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 48) 51045* UNLT_EXPR: Unary and Binary Expressions. 51046 (line 6) 51047* UNORDERED_EXPR: Unary and Binary Expressions. 51048 (line 6) 51049* unshare_all_rtl: Sharing. (line 58) 51050* unsigned division: Arithmetic. (line 130) 51051* unsigned division with unsigned saturation: Arithmetic. (line 130) 51052* unsigned greater than: Comparisons. (line 64) 51053* unsigned greater than <1>: Comparisons. (line 72) 51054* unsigned less than: Comparisons. (line 68) 51055* unsigned less than <1>: Comparisons. (line 76) 51056* unsigned minimum and maximum: Arithmetic. (line 149) 51057* unsigned_fix: Conversions. (line 77) 51058* unsigned_float: Conversions. (line 62) 51059* unsigned_fract_convert: Conversions. (line 97) 51060* unsigned_sat_fract: Conversions. (line 103) 51061* unspec: Side Effects. (line 299) 51062* unspec <1>: Constant Definitions. 51063 (line 111) 51064* unspec_volatile: Side Effects. (line 299) 51065* unspec_volatile <1>: Constant Definitions. 51066 (line 99) 51067* untyped_call instruction pattern: Standard Names. (line 1375) 51068* untyped_return instruction pattern: Standard Names. (line 1438) 51069* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 51070* update_ssa: SSA. (line 74) 51071* update_stmt: Manipulating GIMPLE statements. 51072 (line 140) 51073* update_stmt <1>: SSA Operands. (line 6) 51074* update_stmt_if_modified: Manipulating GIMPLE statements. 51075 (line 143) 51076* UQQmode: Machine Modes. (line 126) 51077* usaddM3 instruction pattern: Standard Names. (line 301) 51078* usadM instruction pattern: Standard Names. (line 405) 51079* USAmode: Machine Modes. (line 166) 51080* usashlM3 instruction pattern: Standard Names. (line 579) 51081* usdivM3 instruction pattern: Standard Names. (line 301) 51082* use: Side Effects. (line 168) 51083* used: Flags. (line 314) 51084* used, in symbol_ref: Flags. (line 197) 51085* user: GTY Options. (line 243) 51086* user gc: User GC. (line 6) 51087* USER_LABEL_PREFIX: Instruction Output. (line 152) 51088* USE_C_ALLOCA: Host Misc. (line 19) 51089* USE_LD_AS_NEEDED: Driver. (line 135) 51090* USE_LOAD_POST_DECREMENT: Costs. (line 233) 51091* USE_LOAD_POST_INCREMENT: Costs. (line 228) 51092* USE_LOAD_PRE_DECREMENT: Costs. (line 243) 51093* USE_LOAD_PRE_INCREMENT: Costs. (line 238) 51094* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 193) 51095* USE_STORE_POST_DECREMENT: Costs. (line 253) 51096* USE_STORE_POST_INCREMENT: Costs. (line 248) 51097* USE_STORE_PRE_DECREMENT: Costs. (line 263) 51098* USE_STORE_PRE_INCREMENT: Costs. (line 258) 51099* USING_STMT: Statements for C++. (line 6) 51100* usmaddMN4 instruction pattern: Standard Names. (line 531) 51101* usmsubMN4 instruction pattern: Standard Names. (line 555) 51102* usmulhisi3 instruction pattern: Standard Names. (line 499) 51103* usmulM3 instruction pattern: Standard Names. (line 301) 51104* usmulqihi3 instruction pattern: Standard Names. (line 499) 51105* usmulsidi3 instruction pattern: Standard Names. (line 499) 51106* usnegM2 instruction pattern: Standard Names. (line 603) 51107* USQmode: Machine Modes. (line 134) 51108* ussubM3 instruction pattern: Standard Names. (line 301) 51109* usubvM4 instruction pattern: Standard Names. (line 325) 51110* us_ashift: Arithmetic. (line 173) 51111* us_minus: Arithmetic. (line 38) 51112* us_mult: Arithmetic. (line 93) 51113* us_neg: Arithmetic. (line 82) 51114* us_plus: Arithmetic. (line 14) 51115* us_truncate: Conversions. (line 48) 51116* UTAmode: Machine Modes. (line 174) 51117* UTQmode: Machine Modes. (line 142) 51118* V in constraint: Simple Constraints. (line 43) 51119* values, returned by functions: Scalar Return. (line 6) 51120* varargs implementation: Varargs. (line 6) 51121* variable: Declarations. (line 6) 51122* Variable Location Debug Information in RTL: Debug Information. 51123 (line 6) 51124* VAR_DECL: Declarations. (line 6) 51125* var_location: Debug Information. (line 14) 51126* vashlM3 instruction pattern: Standard Names. (line 595) 51127* vashrM3 instruction pattern: Standard Names. (line 595) 51128* VA_ARG_EXPR: Unary and Binary Expressions. 51129 (line 6) 51130* vcondMN instruction pattern: Standard Names. (line 227) 51131* vconduMN instruction pattern: Standard Names. (line 237) 51132* vcond_mask_MN instruction pattern: Standard Names. (line 240) 51133* vector: Containers. (line 6) 51134* vector operations: Vector Operations. (line 6) 51135* VECTOR_CST: Constant expressions. 51136 (line 6) 51137* VECTOR_STORE_FLAG_VALUE: Misc. (line 293) 51138* vec_cmpMN instruction pattern: Standard Names. (line 217) 51139* vec_cmpuMN instruction pattern: Standard Names. (line 224) 51140* vec_concat: Vector Operations. (line 28) 51141* vec_duplicate: Vector Operations. (line 33) 51142* vec_extractM instruction pattern: Standard Names. (line 207) 51143* vec_initM instruction pattern: Standard Names. (line 212) 51144* vec_load_lanesMN instruction pattern: Standard Names. (line 165) 51145* VEC_LSHIFT_EXPR: Vectors. (line 6) 51146* vec_merge: Vector Operations. (line 11) 51147* VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6) 51148* VEC_PACK_SAT_EXPR: Vectors. (line 6) 51149* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 440) 51150* vec_pack_ssat_M instruction pattern: Standard Names. (line 433) 51151* VEC_PACK_TRUNC_EXPR: Vectors. (line 6) 51152* vec_pack_trunc_M instruction pattern: Standard Names. (line 426) 51153* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 440) 51154* vec_pack_usat_M instruction pattern: Standard Names. (line 433) 51155* vec_permM instruction pattern: Standard Names. (line 258) 51156* vec_perm_constM instruction pattern: Standard Names. (line 274) 51157* VEC_RSHIFT_EXPR: Vectors. (line 6) 51158* vec_select: Vector Operations. (line 19) 51159* vec_setM instruction pattern: Standard Names. (line 202) 51160* vec_shr_M instruction pattern: Standard Names. (line 420) 51161* vec_store_lanesMN instruction pattern: Standard Names. (line 189) 51162* vec_unpacks_float_hi_M instruction pattern: Standard Names. 51163 (line 461) 51164* vec_unpacks_float_lo_M instruction pattern: Standard Names. 51165 (line 461) 51166* vec_unpacks_hi_M instruction pattern: Standard Names. (line 447) 51167* vec_unpacks_lo_M instruction pattern: Standard Names. (line 447) 51168* vec_unpacku_float_hi_M instruction pattern: Standard Names. 51169 (line 461) 51170* vec_unpacku_float_lo_M instruction pattern: Standard Names. 51171 (line 461) 51172* vec_unpacku_hi_M instruction pattern: Standard Names. (line 454) 51173* vec_unpacku_lo_M instruction pattern: Standard Names. (line 454) 51174* VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6) 51175* VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6) 51176* VEC_UNPACK_HI_EXPR: Vectors. (line 6) 51177* VEC_UNPACK_LO_EXPR: Vectors. (line 6) 51178* VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6) 51179* VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6) 51180* vec_widen_smult_even_M instruction pattern: Standard Names. 51181 (line 470) 51182* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 470) 51183* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 470) 51184* vec_widen_smult_odd_M instruction pattern: Standard Names. (line 470) 51185* vec_widen_sshiftl_hi_M instruction pattern: Standard Names. 51186 (line 481) 51187* vec_widen_sshiftl_lo_M instruction pattern: Standard Names. 51188 (line 481) 51189* vec_widen_umult_even_M instruction pattern: Standard Names. 51190 (line 470) 51191* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 470) 51192* vec_widen_umult_lo_M instruction pattern: Standard Names. (line 470) 51193* vec_widen_umult_odd_M instruction pattern: Standard Names. (line 470) 51194* vec_widen_ushiftl_hi_M instruction pattern: Standard Names. 51195 (line 481) 51196* vec_widen_ushiftl_lo_M instruction pattern: Standard Names. 51197 (line 481) 51198* verify_flow_info: Maintaining the CFG. 51199 (line 117) 51200* virtual operands: SSA Operands. (line 6) 51201* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 51202* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 51203* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 51204* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 51205* VLIW: Processor pipeline description. 51206 (line 6) 51207* VLIW <1>: Processor pipeline description. 51208 (line 223) 51209* vlshrM3 instruction pattern: Standard Names. (line 595) 51210* VMS: Filesystem. (line 37) 51211* VMS_DEBUGGING_INFO: VMS Debug. (line 8) 51212* void: Misc. (line 686) 51213* void <1>: Misc. (line 691) 51214* VOIDmode: Machine Modes. (line 192) 51215* VOID_TYPE: Types. (line 6) 51216* volatil: Flags. (line 328) 51217* volatil, in insn, call_insn, jump_insn, code_label, jump_table_data, barrier, and note: Flags. 51218 (line 44) 51219* volatil, in label_ref and reg_label: Flags. (line 65) 51220* volatil, in mem, asm_operands, and asm_input: Flags. (line 76) 51221* volatil, in reg: Flags. (line 98) 51222* volatil, in subreg: Flags. (line 170) 51223* volatil, in subreg <1>: Flags. (line 180) 51224* volatil, in symbol_ref: Flags. (line 206) 51225* volatile memory references: Flags. (line 329) 51226* volatile, in prefetch: Flags. (line 214) 51227* voting between constraint alternatives: Class Preferences. (line 6) 51228* vrotlM3 instruction pattern: Standard Names. (line 595) 51229* vrotrM3 instruction pattern: Standard Names. (line 595) 51230* walk_dominator_tree: SSA. (line 195) 51231* walk_gimple_op: Statement and operand traversals. 51232 (line 30) 51233* walk_gimple_seq: Statement and operand traversals. 51234 (line 47) 51235* walk_gimple_stmt: Statement and operand traversals. 51236 (line 10) 51237* WCHAR_TYPE: Type Layout. (line 171) 51238* WCHAR_TYPE_SIZE: Type Layout. (line 179) 51239* which_alternative: Output Statement. (line 58) 51240* WHILE_BODY: Statements for C++. (line 6) 51241* WHILE_COND: Statements for C++. (line 6) 51242* WHILE_STMT: Statements for C++. (line 6) 51243* whopr: LTO. (line 6) 51244* widen_ssumM3 instruction pattern: Standard Names. (line 413) 51245* widen_usumM3 instruction pattern: Standard Names. (line 414) 51246* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 116) 51247* window_save instruction pattern: Standard Names. (line 1730) 51248* WINT_TYPE: Type Layout. (line 184) 51249* WORDS_BIG_ENDIAN: Storage Layout. (line 28) 51250* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 215) 51251* word_mode: Machine Modes. (line 367) 51252* WORD_REGISTER_OPERATIONS: Misc. (line 53) 51253* wpa: LTO. (line 6) 51254* X in constraint: Simple Constraints. (line 122) 51255* x-HOST: Host Fragment. (line 6) 51256* XCmode: Machine Modes. (line 199) 51257* XCOFF_DEBUGGING_INFO: DBX Options. (line 12) 51258* XEXP: Accessors. (line 6) 51259* XFmode: Machine Modes. (line 82) 51260* XImode: Machine Modes. (line 54) 51261* XINT: Accessors. (line 6) 51262* xm-MACHINE.h: Filesystem. (line 6) 51263* xm-MACHINE.h <1>: Host Misc. (line 6) 51264* xor: Arithmetic. (line 168) 51265* xor, canonicalization of: Insn Canonicalizations. 51266 (line 78) 51267* xorM3 instruction pattern: Standard Names. (line 301) 51268* XSTR: Accessors. (line 6) 51269* XVEC: Accessors. (line 41) 51270* XVECEXP: Accessors. (line 48) 51271* XVECLEN: Accessors. (line 44) 51272* XWINT: Accessors. (line 6) 51273* zero_extend: Conversions. (line 28) 51274* zero_extendMN2 instruction pattern: Standard Names. (line 1129) 51275* zero_extract: Bit-Fields. (line 30) 51276* zero_extract, canonicalization of: Insn Canonicalizations. 51277 (line 87) 51278 51279 51280 51281Tag Table: 51282Node: Top1789 51283Node: Contributing4971 51284Node: Portability5700 51285Node: Interface7488 51286Node: Libgcc10529 51287Node: Integer library routines12356 51288Node: Soft float library routines19324 51289Node: Decimal float library routines31262 51290Node: Fixed-point fractional library routines47020 51291Node: Exception handling routines147416 51292Node: Miscellaneous routines148523 51293Node: Languages150643 51294Node: Source Tree152190 51295Node: Configure Terms152772 51296Node: Top Level155728 51297Node: gcc Directory159215 51298Node: Subdirectories160167 51299Node: Configuration162335 51300Node: Config Fragments163055 51301Node: System Config164280 51302Node: Configuration Files165216 51303Node: Build168033 51304Node: Makefile168445 51305Ref: Makefile-Footnote-1175249 51306Ref: Makefile-Footnote-2175396 51307Node: Library Files175470 51308Node: Headers176032 51309Node: Documentation178115 51310Node: Texinfo Manuals178974 51311Node: Man Page Generation181303 51312Node: Miscellaneous Docs183216 51313Node: Front End184603 51314Node: Front End Directory188277 51315Node: Front End Config189593 51316Node: Front End Makefile192409 51317Node: Back End196177 51318Node: Testsuites199958 51319Node: Test Idioms200889 51320Node: Test Directives204287 51321Node: Directives204814 51322Node: Selectors215111 51323Node: Effective-Target Keywords216467 51324Ref: arm_fp_ok223643 51325Ref: arm_neon_ok224572 51326Ref: arm_neonv2_ok224730 51327Ref: arm_neon_fp16_ok224902 51328Ref: arm_vfp3_ok225542 51329Node: Add Options237421 51330Node: Require Support238924 51331Node: Final Actions241431 51332Node: Ada Tests247090 51333Node: C Tests248421 51334Node: libgcj Tests252816 51335Node: LTO Testing253943 51336Node: gcov Testing255591 51337Node: profopt Testing258581 51338Node: compat Testing260296 51339Node: Torture Tests264536 51340Node: Options266151 51341Node: Option file format266592 51342Node: Option properties273581 51343Node: Passes287227 51344Node: Parsing pass288117 51345Node: Cilk Plus Transformation291650 51346Node: Gimplification pass295032 51347Node: Pass manager296877 51348Node: Tree SSA passes298723 51349Node: RTL passes319908 51350Node: Optimization info332212 51351Node: Dump setup333031 51352Node: Optimization groups334160 51353Node: Dump files and streams335049 51354Node: Dump output verbosity336247 51355Node: Dump types337303 51356Node: Dump examples338793 51357Node: GENERIC340139 51358Node: Deficiencies342015 51359Node: Tree overview342256 51360Node: Macros and Functions346380 51361Node: Identifiers347205 51362Node: Containers348814 51363Node: Types349971 51364Node: Declarations362045 51365Node: Working with declarations362540 51366Node: Internal structure368144 51367Node: Current structure hierarchy368528 51368Node: Adding new DECL node types370621 51369Node: Attributes374905 51370Node: Expression trees376149 51371Node: Constant expressions377903 51372Node: Storage References381199 51373Node: Unary and Binary Expressions384718 51374Node: Vectors404866 51375Node: Statements410061 51376Node: Basic Statements410593 51377Node: Blocks415100 51378Node: Statement Sequences416801 51379Node: Empty Statements417134 51380Node: Jumps417708 51381Node: Cleanups418361 51382Node: OpenMP420128 51383Node: OpenACC425973 51384Node: Functions427014 51385Node: Function Basics427485 51386Node: Function Properties431169 51387Node: Language-dependent trees433950 51388Node: C and C++ Trees434837 51389Node: Types for C++437741 51390Node: Namespaces442711 51391Node: Classes445817 51392Node: Functions for C++450874 51393Node: Statements for C++457125 51394Node: C++ Expressions465902 51395Node: Java Trees467407 51396Node: GIMPLE467520 51397Node: Tuple representation471185 51398Node: Class hierarchy of GIMPLE statements478145 51399Node: GIMPLE instruction set483133 51400Node: GIMPLE Exception Handling484765 51401Node: Temporaries486677 51402Ref: Temporaries-Footnote-1487995 51403Node: Operands488060 51404Node: Compound Expressions488821 51405Node: Compound Lvalues489055 51406Node: Conditional Expressions489817 51407Node: Logical Operators490476 51408Node: Manipulating GIMPLE statements497340 51409Node: Tuple specific accessors503276 51410Node: GIMPLE_ASM504055 51411Node: GIMPLE_ASSIGN506438 51412Node: GIMPLE_BIND511142 51413Node: GIMPLE_CALL512956 51414Node: GIMPLE_CATCH516984 51415Node: GIMPLE_COND518134 51416Node: GIMPLE_DEBUG520929 51417Node: GIMPLE_EH_FILTER524302 51418Node: GIMPLE_LABEL525865 51419Node: GIMPLE_GOTO526478 51420Node: GIMPLE_NOP527001 51421Node: GIMPLE_OMP_ATOMIC_LOAD527363 51422Node: GIMPLE_OMP_ATOMIC_STORE528359 51423Node: GIMPLE_OMP_CONTINUE529058 51424Node: GIMPLE_OMP_CRITICAL530537 51425Node: GIMPLE_OMP_FOR531531 51426Node: GIMPLE_OMP_MASTER534947 51427Node: GIMPLE_OMP_ORDERED535325 51428Node: GIMPLE_OMP_PARALLEL535719 51429Node: GIMPLE_OMP_RETURN538488 51430Node: GIMPLE_OMP_SECTION539133 51431Node: GIMPLE_OMP_SECTIONS539793 51432Node: GIMPLE_OMP_SINGLE541403 51433Node: GIMPLE_PHI542349 51434Node: GIMPLE_RESX543628 51435Node: GIMPLE_RETURN544347 51436Node: GIMPLE_SWITCH544921 51437Node: GIMPLE_TRY546796 51438Node: GIMPLE_WITH_CLEANUP_EXPR548568 51439Node: GIMPLE sequences549447 51440Node: Sequence iterators552653 51441Node: Adding a new GIMPLE statement code561110 51442Node: Statement and operand traversals562455 51443Node: Tree SSA565047 51444Node: Annotations566835 51445Node: SSA Operands567240 51446Node: SSA581315 51447Node: Alias analysis591021 51448Node: Memory model594795 51449Node: RTL596154 51450Node: RTL Objects598342 51451Node: RTL Classes602216 51452Node: Accessors607262 51453Node: Special Accessors609656 51454Node: Flags615443 51455Node: Machine Modes630207 51456Node: Constants643855 51457Node: Regs and Memory651942 51458Node: Arithmetic669830 51459Node: Comparisons679875 51460Node: Bit-Fields684167 51461Node: Vector Operations685719 51462Node: Conversions687600 51463Node: RTL Declarations692098 51464Node: Side Effects692919 51465Node: Incdec709930 51466Node: Assembler713266 51467Node: Debug Information714811 51468Node: Insns716008 51469Node: Calls742401 51470Node: Sharing744994 51471Node: Reading RTL748105 51472Node: Control Flow749096 51473Node: Basic Blocks750865 51474Node: Edges756319 51475Node: Profile information764948 51476Node: Maintaining the CFG769632 51477Node: Liveness information775494 51478Node: Loop Analysis and Representation777620 51479Node: Loop representation778656 51480Node: Loop querying786219 51481Node: Loop manipulation789040 51482Node: LCSSA791401 51483Node: Scalar evolutions793470 51484Node: loop-iv796714 51485Node: Number of iterations798636 51486Node: Dependency analysis801442 51487Node: Machine Desc807792 51488Node: Overview810355 51489Node: Patterns812395 51490Node: Example815903 51491Node: RTL Template817364 51492Node: Output Template828020 51493Node: Output Statement831983 51494Node: Predicates836322 51495Node: Machine-Independent Predicates839240 51496Node: Defining Predicates844184 51497Node: Constraints850147 51498Node: Simple Constraints851616 51499Node: Multi-Alternative864456 51500Node: Class Preferences867665 51501Node: Modifiers868557 51502Node: Machine Constraints873290 51503Node: Disable Insn Alternatives934128 51504Node: Define Constraints937620 51505Node: C Constraint Interface945015 51506Node: Standard Names948142 51507Ref: shift patterns973568 51508Ref: prologue instruction pattern1023865 51509Ref: window_save instruction pattern1024358 51510Ref: epilogue instruction pattern1024635 51511Node: Pattern Ordering1042205 51512Node: Dependent Patterns1043441 51513Node: Jump Patterns1045061 51514Ref: Jump Patterns-Footnote-11047208 51515Node: Looping Patterns1047256 51516Node: Insn Canonicalizations1051985 51517Node: Expander Definitions1056570 51518Node: Insn Splitting1064784 51519Node: Including Patterns1074387 51520Node: Peephole Definitions1076171 51521Node: define_peephole1077424 51522Node: define_peephole21083754 51523Node: Insn Attributes1086820 51524Node: Defining Attributes1088002 51525Ref: define_enum_attr1091495 51526Node: Expressions1092531 51527Node: Tagging Insns1099281 51528Node: Attr Example1103634 51529Node: Insn Lengths1106007 51530Node: Constant Attributes1109415 51531Node: Mnemonic Attribute1110591 51532Node: Delay Slots1112110 51533Node: Processor pipeline description1115333 51534Ref: Processor pipeline description-Footnote-11134150 51535Node: Conditional Execution1134474 51536Node: Define Subst1137957 51537Node: Define Subst Example1139993 51538Node: Define Subst Pattern Matching1142987 51539Node: Define Subst Output Template1144213 51540Node: Constant Definitions1146283 51541Ref: define_enum1150065 51542Node: Iterators1150553 51543Node: Mode Iterators1151131 51544Node: Defining Mode Iterators1152109 51545Node: Substitutions1153603 51546Node: Examples1155845 51547Node: Code Iterators1157293 51548Node: Int Iterators1159572 51549Node: Subst Iterators1162018 51550Node: Target Macros1163710 51551Node: Target Structure1166722 51552Node: Driver1168838 51553Node: Run-time Target1187808 51554Node: Per-Function Data1197519 51555Node: Storage Layout1200283 51556Node: Type Layout1226033 51557Node: Registers1239659 51558Node: Register Basics1240633 51559Node: Allocation Order1246071 51560Node: Values in Registers1248555 51561Node: Leaf Functions1256033 51562Node: Stack Registers1258892 51563Node: Register Classes1260164 51564Node: Stack and Calling1292806 51565Node: Frame Layout1293372 51566Node: Exception Handling1304219 51567Node: Stack Checking1310429 51568Node: Frame Registers1315270 51569Node: Elimination1323535 51570Node: Stack Arguments1327763 51571Node: Register Arguments1334945 51572Node: Scalar Return1355990 51573Node: Aggregate Return1362446 51574Node: Caller Saves1366635 51575Node: Function Entry1367377 51576Node: Profiling1378469 51577Node: Tail Calls1380579 51578Node: Stack Smashing Protection1382480 51579Node: Miscellaneous Register Hooks1384143 51580Node: Varargs1385009 51581Node: Trampolines1395118 51582Node: Library Calls1401161 51583Node: Addressing Modes1405845 51584Node: Anchored Addresses1429238 51585Node: Condition Code1431881 51586Node: CC0 Condition Codes1434208 51587Node: MODE_CC Condition Codes1437454 51588Node: Costs1444262 51589Node: Scheduling1462438 51590Node: Sections1485616 51591Node: PIC1501309 51592Node: Assembler Format1503368 51593Node: File Framework1504506 51594Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1511438 51595Node: Data Output1514708 51596Node: Uninitialized Data1522654 51597Node: Label Output1527665 51598Node: Initialization1552276 51599Node: Macros for Initialization1558237 51600Node: Instruction Output1564956 51601Node: Dispatch Tables1575585 51602Node: Exception Region Output1579985 51603Node: Alignment Output1587079 51604Node: Debugging Info1591682 51605Node: All Debuggers1592352 51606Node: DBX Options1595207 51607Node: DBX Hooks1600645 51608Node: File Names and DBX1601954 51609Node: SDB and DWARF1604066 51610Node: VMS Debug1610549 51611Node: Floating Point1611136 51612Node: Mode Switching1613891 51613Node: Target Attributes1618327 51614Node: Emulated TLS1627293 51615Node: MIPS Coprocessors1630683 51616Node: PCH Target1631842 51617Node: C++ ABI1633684 51618Node: Named Address Spaces1638478 51619Node: Misc1643747 51620Ref: TARGET_SHIFT_TRUNCATION_MASK1650494 51621Node: Host Config1706669 51622Node: Host Common1707737 51623Node: Filesystem1710111 51624Node: Host Misc1714226 51625Node: Fragments1716675 51626Node: Target Fragment1717870 51627Node: Host Fragment1728499 51628Node: Collect21728739 51629Node: Header Dirs1731375 51630Node: Type Information1732798 51631Node: GTY Options1736074 51632Node: Inheritance and GTY1747321 51633Ref: Inheritance and GTY-Footnote-11748886 51634Node: User GC1749156 51635Node: GGC Roots1752895 51636Node: Files1753608 51637Node: Invoking the garbage collector1756315 51638Node: Troubleshooting1757820 51639Node: Plugins1758895 51640Node: Plugins loading1760024 51641Node: Plugin API1760894 51642Node: Plugins pass1768620 51643Node: Plugins GC1770591 51644Node: Plugins description1772309 51645Node: Plugins attr1772845 51646Node: Plugins recording1775119 51647Node: Plugins gate1775969 51648Node: Plugins tracking1776560 51649Node: Plugins building1777148 51650Node: LTO1778938 51651Node: LTO Overview1779810 51652Node: LTO object file layout1785637 51653Node: IPA1790267 51654Node: WHOPR1799232 51655Node: Internal flags1803792 51656Node: Match and Simplify1805203 51657Node: GIMPLE API1806157 51658Node: The Language1808952 51659Node: Funding1820057 51660Node: GNU Project1822556 51661Node: Copying1823205 51662Node: GNU Free Documentation License1860717 51663Node: Contributors1885838 51664Node: Option Index1924647 51665Node: Concept Index1925524 51666 51667End Tag Table 51668